Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    OpenVPN : comment router les sous-réseaux ?

    Français
    4
    24
    6.6k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C
      chris4916
      last edited by

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

      Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

      1 Reply Last reply Reply Quote 0
      • R
        renz0fr
        last edited by

        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 ?

        1 Reply Last reply Reply Quote 0
        • J
          jdh
          last edited by

          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 !

          Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

          1 Reply Last reply Reply Quote 0
          • R
            renz0fr
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • C
              chris4916
              last edited by

              @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"

              Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

              1 Reply Last reply Reply Quote 0
              • R
                renz0fr
                last edited by

                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
                1 Reply Last reply Reply Quote 0
                • C
                  chris4916
                  last edited by

                  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.

                  Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

                  1 Reply Last reply Reply Quote 0
                  • R
                    renz0fr
                    last edited by

                    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 !

                    1 Reply Last reply Reply Quote 0
                    • C
                      chris4916
                      last edited by

                      @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  ;)

                      Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

                      1 Reply Last reply Reply Quote 0
                      • R
                        renz0fr
                        last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • R
                          renz0fr
                          last edited by

                          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 ?

                          1 Reply Last reply Reply Quote 0
                          • J
                            jdh
                            last edited by

                            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.)

                            Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                            1 Reply Last reply Reply Quote 0
                            • C
                              chris4916
                              last edited by

                              @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.  ;)

                              Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

                              1 Reply Last reply Reply Quote 0
                              • J
                                jdh
                                last edited by

                                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.

                                Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post