OpenVPN : comment router les sous-réseaux ?

chris4916

Je ne sais pas quelles recherches tu as fait sur le forum mais ce sujet peut éventuellement t'aider.

renz0fr

Merci, ce post est proche de mon cas en effet.
Plutôt que de m'arrêter au ping, j'ai tenté d'utiliser vnc à travers le tunnel et ça fonctionne :

(client) 192.168.2.144 –-> (tunnel) 10.0.8.6 --- 10.0.8.5 (tunnel) --- 192.168.1.1 (pfSense) ---> 192.168.1.11 (vnc server, NAT port 5900 configurée sur pfSense)

Finalement mon tunnel a l'air de fonctionner via la NAT.
Voici un scan fait depuis 192.168.2.144 :

$ nmap 192.168.1.11 -Pn

Starting Nmap 6.40 ( http://nmap.org ) at 2016-01-16 15:08 CET
Nmap scan report for 192.168.1.11
Host is up (0.087s latency).
Not shown: 998 filtered ports
PORT     STATE SERVICE
3389/tcp open  ms-wbt-server
5900/tcp open  vnc

Devrais-je faire une NAT des ports souhaités plutôt qu'un éventuel routage ?

jdh

Méconnaissance :

(client) 192.168.2.144 –-> (tunnel) 10.0.8.6 --- 10.0.8.5 (tunnel) --- 192.168.1.1 (pfSense) ---> 192.168.1.11

Schéma incorrect !

Le schéma correct est :
(client) 10.0.8.6 <– tunnel --> 10.0.8.5 (pfSense) 192.168.1.1 <-- LAN --> 192.168.1.11
En effet, n'importe quelle machine, avec plusieurs ip, établit une liaison avec une seule ip : celle du réseau emprunté.

Vous n'avez pas lu ce que j'ai écrit : "Par contre il est parfaitement inutile de s'intéresser à l'adresse locale de ce client : elle ne joue aucun rôle"

Le NAT ?
A quoi servirait de réaliser un NAT quelconque ? Grâce au VPN, le pc distant (en roadwarrior) voit le réseau LAN 'en direct' : tout est dit et fait !
Le NAT sert à autre chose !

Je repose la question : pourquoi ne pas mettre de 'push' dans la config serveur ?
C'est la manière normale de config d'un serveur, et le client ajoute automatiquement la route ainsi fournie par le serveur !
Si vous ne mettez pas de 'push route', il faut en ajouter une manuellement sur chaque client !
Il faut penser simple donc la config serveur permet d'automatiser ce qui est nécessaire au client !

renz0fr

Merci pour ces infos.
Je sais à quoi sert une NAT et le principe du VPN. J'ai fait l'erreur de penser que ma NAT avait un rôle ici, mais en effet je peux utiliser VNC à travers le VPN après avoir désactivé la NAT.
C'est que mon VPN fonctionne a priori, mais je n'ai pas accès au partage de fichiers cependant.

Je voudrais bien mettre un push dans la config serveur, mais j'avoue ne pas savoir quoi mettre. Mes essais ont été sans succès, avec bien souvent un message d'erreur sur le client.

chris4916

@renz0fr:

…/... je peux utiliser VNC à travers le VPN après avoir désactivé la NAT.
C'est que mon VPN fonctionne a priori, mais je n'ai pas accès au partage de fichiers cependant.

Je voudrais bien mettre un push dans la config serveur, mais j'avoue ne pas savoir quoi mettre. Mes essais ont été sans succès, avec bien souvent un message d'erreur sur le client.

Donc ton tunnel fonctionne et c'est le ping qui n'est pas autorisé, c'est ça ?
(j'ai un peu du mal à comprendre exactement ce qu'il en est)

Pour le partage: j'avais compris d'un post précédent que le partage était accédé par une machine distante , je veux dire une application tournant sur le site distant accédant un partage sur SON réseau local. Dans ce cas, la machine à l'autre bout du tunnel ne serait pas impactée.
Si au contraire tu veux accéder ua partage depuis la machine qui monte le tunnel, il faut comprendre comment, d'un point de vue réseau, ce partage est accédé.
Il est probablement nécessaire, au niveau du serveur VPN, d'activer "NetiBios over TCP/IP". J'ai des doutes sur l'impact de TAP vs. TUN dans ce cas.

Tu évoques des messages d'erreur coté client: il serait plus efficace de décrire ces messages plutôt qu'uniquement les évoquer ;)

Si tu veux absolument faire un push (mais je ne vois pas pourquoi puisque ta config fonctionne, si je comprends bien), tu peux le faire dans la fenêtre "advanced" avec, par exemple:

push "route 192.168.1.0 255.255.255.0";keepalive 10 60;

si cette route n'existe pas coté client une fois le tunnel établi.

Tu peux également le spécifier (ainsi que décrit dans le sujet que je t'ai indiqué dans mon message précédent) au niveau du "client overrides"

renz0fr

Oui, mon tunnel semble bien fonctionner finalement :)
Je m'étais bêtement arrêté au ping qui ne répondait pas.
Pour le partage, c'est bien la machine distante qui monte le tunnel et qui veut accéder au partage de fichiers qui est côté serveur vpn.
J'ai activé Enable NetBIOS over TCP/IP sans résultat pour le moment.
Mais si la machine distante n'est pas vraiment vue comme locale, je dois configurer le parefeu windows sur le serveur de fichiers ?

En ajoutant le push route que tu m'indiques, voici le message (qui semble indiquer que la route existe déjà) :

Sat Jan 16 16:32:44 2016 TUN/TAP device tun0 opened
Sat Jan 16 16:32:44 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Jan 16 16:32:44 2016 /sbin/ip link set dev tun0 up mtu 1500
Sat Jan 16 16:32:44 2016 /sbin/ip addr add dev tun0 local 10.0.8.6 peer 10.0.8.5
RTNETLINK answers: File exists
Sat Jan 16 16:32:44 2016 ERROR: Linux route add command failed: external program exited with error status: 2
Sat Jan 16 16:32:44 2016 Initialization Sequence Completed

Et quand je faisais des tests, je voyais donc cette ligne :

Sat Jan 16 16:32:44 2016 ERROR: Linux route add command failed: external program exited with error status: 2

J'ai aussi accès à l'admin web de pfSense depuis la machine distante, cependant dans ce cas isolé j'ai de nombreux timeouts et le vpn est relancé :

Sat Jan 16 16:24:18 2016 Initialization Sequence Completed
Sat Jan 16 16:26:08 2016 [veto_ServCert] Inactivity timeout (--ping-restart), restarting
Sat Jan 16 16:26:08 2016 SIGUSR1[soft,ping-restart] received, process restarting
Sat Jan 16 16:26:10 2016 UDPv4 link local (bound): [undef]
Sat Jan 16 16:26:10 2016 UDPv4 link remote: [AF_INET]90.*.*.*:1194
Sat Jan 16 16:26:11 2016 [veto_ServCert] Peer Connection Initiated with [AF_INET]90.*.*.*:1194
Sat Jan 16 16:26:14 2016 Preserving previous TUN/TAP instance: tun0
Sat Jan 16 16:26:14 2016 Initialization Sequence Completed

chris4916

distante vs. locale

Je savais que ça n'allait pas être simple. un glossaire s'impose ;D ;D ;D

Locale, c'est dans mon esprit, du point de vue de l’application.
C'est la machine depuis laquelle tu te connectes, donc en l’occurrence le road warrior quand tu accèdes via le VPN, à une application distante.
Pour l’application qui tourne sur le site central, le serveur de fichier est en revanche local.

Une fois ce point établi, relis mes messages précédents car je sens que ta réponse n'est pas claire de ce point de vue.

Il serait plus simple de nommer les sites selon l’extrémité du serveur VPN.

Donc dans ma compréhension, depuis le site "client", tu veux accéder à une application sur le site "serveur", laquelle application accède à un partage sur le même site "serveur". C'est du moins ce que je comprends de ton schéma et donc je ne vois pas pourquoi NetBeui traverserait le tunnel.
As-tu bien redémarré ton tunnel une fois activé Netbiois over TCP/IP ?
Un autre aspect, mais qui n'est directement lié au protocole, est celui de WINS. Lorsque tu dis ne pas arriver à accéder au partage, est-ce que c'est un problème d'accès d'un point de vue SMB ou un problème de résolution de nom parce que tu n'accèdes pas au serveur WINS ? Pour faire le tests, tente un accès au serveur en utilisant sont adresse IP 8)

Pour les time-out, n'hésite pas à tester un tunnel en TCP au lieu de UDP ;)

Pour la route: c'est sans surprise. Tu ne peux pas pousser plusieurs fois la même route d'où mon propos: fait un push route si la route n'existe pas une fois le tunnel établi.

renz0fr

En effet il y a eu confusion sur ces termes ::)
C'est pourquoi j'ai ajouté les notions de client et serveur vpn sur ma réponse… merci de ton indulgence.

Mais le besoin n'est pas exactement celui que tu cites. L'application est une sorte de poste à poste, et le site "client" a bel et bien besoin d'accéder directement au partage SMB du site "serveur".
Je tente tous les accès via les IP donc pas de soucis WINS pour le moment.
J'avais relancé le tunnel après le réglage, mais je pourrai tester à nouveau lundi.

Pour les time-out, j'ai vu dans l'autre post que TCP était une alternative, je vais tester merci !

chris4916

@renz0fr:

Je tente tous les accès via les IP donc pas de soucis WINS pour le moment.

Il serait intéressant alors d'avoir le message d'erreur… une fois que ton tunnel est stable

Pour les time-out, j'ai vu dans l'autre post que TCP était une alternative, je vais tester merci !

UDP est plus rapide mais n'embarque pas, contrairement à TCP, de correction d'erreur, ce qui fait que TCP est moins sujet à déconnexion ;)

renz0fr

Finalement mon tunnel s'avère stable en UDP.
Pour le message d'erreur, j'avais ceci sous linux :

Impossible d'afficher « smb://192.168.1.12/ ».

Erreur : L'obtention de la liste des partages du serveur a échoué : Connexion terminée par expiration du délai d'attente

Suite à quoi j'ai lancé nmap sur l'ip du serveur :

$ nmap -Pn 192.168.1.12

Starting Nmap 6.40 ( http://nmap.org ) at 2016-01-18 16:39 CET
Nmap scan report for 192.168.1.12
Host is up (0.44s latency).
Not shown: 995 filtered ports
PORT     STATE SERVICE
1947/tcp open  sentinelsrm
6002/tcp open  X11:2
7001/tcp open  afs3-callback
7002/tcp open  afs3-prserver
8180/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 173.35 seconds

J'ai donc désactivé le pare-feu windows, et relancé nmap :

$ nmap -Pn 192.168.1.12

Starting Nmap 6.40 ( http://nmap.org ) at 2016-01-18 16:45 CET
Nmap scan report for 192.168.1.12
Host is up (0.25s latency).
Not shown: 975 closed ports
PORT      STATE    SERVICE
135/tcp   open     msrpc
139/tcp   open     netbios-ssn
445/tcp   open     microsoft-ds
554/tcp   open     rtsp
880/tcp   filtered unknown
1090/tcp  filtered ff-fms
1123/tcp  filtered murray
1947/tcp  open     sentinelsrm
2869/tcp  open     icslap
5357/tcp  open     wsdapi
6002/tcp  open     X11:2
7001/tcp  open     afs3-callback
7002/tcp  open     afs3-prserver
8093/tcp  filtered unknown
8180/tcp  open     unknown
10243/tcp open     unknown
15004/tcp filtered unknown
19315/tcp filtered keyshadow
40911/tcp filtered unknown
49152/tcp open     unknown
49153/tcp open     unknown
49154/tcp open     unknown
49155/tcp open     unknown
49156/tcp open     unknown
49160/tcp open     unknown

Nmap done: 1 IP address (1 host up) scanned in 97.84 seconds

Et cela fonctionne, j'ai accès au partage de fichiers !
Je vais tenter de configurer le pare-feu windows, en ajoutant 135, 139, 445.
C'est plutôt troublant car l'accès au partage était déjà coché dans les paramètres du pare-feu, j'imagine qu'il est autorisé de manière limitée. Je vais creuser ce point et je ferai un retour.

renz0fr

J'ai réussi à mettre en place ce que je voulais, mais j'ai quand même quelques déconnexions.
J'essaie donc de passer le VPN en TCP, tout a l'air de fonctionner, table de routage identique à l'UDP, mais rien ne passe comme si le parefeu bloquait (alors que la règle qui autorise est bien présente).
Où dois je regarder pour voir ce que le parefeu bloque ?

jdh

Si le trafic OpenVPN est par défaut sur 1194/udp, il y a des raisons … qu'il faudrait comprendre.
(Moi aussi, lors de mes premiers essais, il y a quelques années, j'ai imaginé que 443/tcp permettrait de mieux traverser les firewall avant d'observer les problèmes de perf ...)

A aucun moment, il ne vous vient à l'idée de fournir comme informations les fichiers de conf ?
(Ah j'oubliais le formulaire est trop compliqué ... Je note que ce fil dure depuis 15 jours.)

chris4916

@renz0fr:

J'ai réussi à mettre en place ce que je voulais, mais j'ai quand même quelques déconnexions.

C'est le risque avec UDP ;) même si c'est la solution préférée

Où dois je regarder pour voir ce que le parefeu bloque ?

Regarde dans l'onglet VPN des règles du firewall.
Tu peux aussi regarder dans le log du FW. ;)

jdh

l'accès au partage était déjà coché dans les paramètres du pare-feu, j'imagine qu'il est autorisé de manière limitée

Pourquoi un firewall clickodrome saurait ouvrir de façon limitée ? Me semble une mauvaise analyse des symptomes ou une erreur de mesure.