Comportement de routage Ubuntu vs Windows VPN

Les réseaux de mon domicile et de mon lieu de travail sont identiques (sous-réseau 10.0.0.x).

Lorsque je configure une connexion VPN sur une machine Windows 7 (PPTP), je peux envoyer une requête ping à n'importe quel serveur situé sur mon lieu de travail sans aucune route statique.

D'autre part, lors de la configuration de la même connexion VPN sur mon ordinateur Ubuntu 14.04, je ne peux établir aucune connexion avec le réseau distant en utilisant un itinéraire statique créé pour un hôte spécifique sur l'autre réseau via le tunnel.

J'essayais de comprendre ce qui se passait sous Windows et j'ai trouvé ce qui suit:

Il existe une deuxième passerelle par défaut qui conduit tout le trafic vers le tunnel, voici la route print sortie:

Network Destination      Netmask         Gateway       Interface   Metric
        0.0.0.0          0.0.0.0       10.0.0.138         10.0.0.9   4255
        0.0.0.0          0.0.0.0         On-link    192.168.88.102     31
       10.0.0.0    255.255.255.0         On-link          10.0.0.9   4511
       10.0.0.9  255.255.255.255         On-link          10.0.0.9   4511
     10.0.0.255  255.255.255.255         On-link          10.0.0.9   4511
      127.0.0.0        255.0.0.0         On-link         127.0.0.1   4531
      127.0.0.1  255.255.255.255         On-link         127.0.0.1   4531
127.255.255.255  255.255.255.255         On-link         127.0.0.1   4531
 192.168.88.102  255.255.255.255         On-link    192.168.88.102    286
 x.x.x.x         255.255.255.255       10.0.0.138         10.0.0.9   4256
      224.0.0.0        240.0.0.0         On-link         127.0.0.1   4531
      224.0.0.0        240.0.0.0         On-link          10.0.0.9   4514
      224.0.0.0        240.0.0.0         On-link    192.168.88.102     31
255.255.255.255  255.255.255.255         On-link         127.0.0.1   4531
255.255.255.255  255.255.255.255         On-link          10.0.0.9   4511
255.255.255.255  255.255.255.255         On-link    192.168.88.102    286

192.168.88.102 est mon adresse IP sur le tunnel, 10.0.0.9 est mon adresse IP locale, 10.0.0.138 est mon routeur, et x.x.x.x est l'adresse IP publique du serveur VPN.

tracert sortie:

pour la première fois:

    tracert -d 10.0.0.83

    Tracing route to 10.0.0.83 over a maximum of 30 hops

    1  10.0.0.9  reports: Destination host unreachable.

    Trace complete.

et pour la deuxième fois:

    tracert -d 10.0.0.83

    Tracing route to 10.0.0.83 over a maximum of 30 hops

    1    42 ms    33 ms    53 ms  192.168.88.1
    2    35 ms    31 ms    33 ms  10.0.0.83

    Trace complete.

pertinent arp sortie:

adresse distante:

    arp -a | findstr 10.0.0.83
    10.0.0.83                                   static

adresse locale:

    arp -a | findstr 10.0.0.14
    10.0.0.14             b8-27-eb-37-38-a4     dynamic

sur Ubuntu, la liste de routage par défaut est la suivante:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.0.138      0.0.0.0         UG        0 0          0 wlan0
10.0.0.0        0.0.0.0         255.255.255.0   U         0 0          0 wlan0
192.168.88.1    0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
x.x.x.x         10.0.0.138      255.255.255.255 UGH       0 0          0 wlan0
x.x.x.x         10.0.0.138      255.255.255.255 UGH       0 0          0 wlan0

L'ajout d'une autre passerelle par défaut n'a pas fait l'affaire.

Quelle est l'explication de ce comportement et comment puis-je y arriver dans Ubuntu?

MODIFIER:

J'utilise le client VPN intégré d'Ubuntu (NetworkManager) qui s'exécute sous root selon syslog. Essayez également d’ajouter des itinéraires statiques dans le panneau de configuration des paramètres IPv4 du plug-in VPN, ce qui a semblé avoir réussi à les ajouter à la table de routage mais n’agissait pas comme Windows.

Voici le Ubuntu /var/log/syslog à partir du moment où la connexion est établie:

     May 29 16:49:56 hostname wpa_supplicant[823]: wlan0: CTRL-EVENT-SCAN-STARTED 
     May 29 16:49:57 hostname wpa_supplicant[823]: nl80211: send_and_recv->nl_recvmsgs failed: -33
     May 29 16:50:15 hostname NetworkManager[757]: <info> Starting VPN service 'pptp'...
     May 29 16:50:15 hostname NetworkManager[757]: <info> VPN service 'pptp' started (org.freedesktop.NetworkManager.pptp), PID 5123
     May 29 16:50:15 hostname NetworkManager[757]: <info> VPN service 'pptp' appeared; activating connections
     May 29 16:50:15 hostname NetworkManager[757]: <info> VPN plugin state changed: starting (3)
     May 29 16:50:15 hostname pppd[5127]: Plugin /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so loaded.
     May 29 16:50:15 hostname NetworkManager[757]: <info> VPN connection 'VPN1' (Connect) reply received.
     May 29 16:50:15 hostname pppd[5127]: pppd 2.4.5 started by root, uid 0
     May 29 16:50:15 hostname pppd[5127]: Using interface ppp0
     May 29 16:50:15 hostname pppd[5127]: Connect: ppp0 <--> /dev/pts/7
     May 29 16:50:15 hostname NetworkManager[757]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
     May 29 16:50:15 hostname NetworkManager[757]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/ppp0, iface: ppp0): no ifupdown configuration found.
     May 29 16:50:15 hostname NetworkManager[757]: <warn> /sys/devices/virtual/net/ppp0: couldn't determine device driver; ignoring...
     May 29 16:50:15 hostname pptp[5132]: nm-pptp-service-5123 log[main:pptp.c:314]: The synchronous pptp option is NOT activated
     May 29 16:50:15 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
     May 29 16:50:15 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
     May 29 16:50:15 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
     May 29 16:50:16 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
     May 29 16:50:16 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
     May 29 16:50:16 hostname pptp[5147]: nm-pptp-service-5123 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 61002).
     May 29 16:50:16 hostname pppd[5127]: CHAP authentication succeeded
     May 29 16:50:16 hostname pppd[5127]: MPPE 128-bit stateless compression enabled
     May 29 16:50:18 hostname pppd[5127]: local  IP address 192.168.88.102
     May 29 16:50:18 hostname pppd[5127]: remote IP address 192.168.88.1
     May 29 16:50:18 hostname pppd[5127]: primary   DNS address 10.0.0.2
     May 29 16:50:18 hostname NetworkManager[757]: <info> VPN connection 'VPN1' (IP4 Config Get) reply received from old-style plugin.
     May 29 16:50:18 hostname NetworkManager[757]: <info> VPN Gateway: x.x.x.x
     May 29 16:50:18 hostname NetworkManager[757]: <info> Tunnel Device: ppp0
     May 29 16:50:18 hostname NetworkManager[757]: <info> IPv4 configuration:
     May 29 16:50:18 hostname NetworkManager[757]: <info>   Internal Address: 192.168.88.102
     May 29 16:50:18 hostname NetworkManager[757]: <info>   Internal Prefix: 32
     May 29 16:50:18 hostname NetworkManager[757]: <info>   Internal Point-to-Point Address: 192.168.88.1
     May 29 16:50:18 hostname NetworkManager[757]: <info>   Maximum Segment Size (MSS): 0
     May 29 16:50:18 hostname NetworkManager[757]: <info>   Forbid Default Route: yes
     May 29 16:50:18 hostname NetworkManager[757]: <info>   Internal DNS: 10.0.0.2
     May 29 16:50:18 hostname NetworkManager[757]: <info>   DNS Domain: '(none)'
     May 29 16:50:18 hostname NetworkManager[757]: <info> No IPv6 configuration
     May 29 16:50:19 hostname NetworkManager[757]: <info> VPN connection 'VPN1' (IP Config Get) complete.
     May 29 16:50:19 hostname NetworkManager[757]: <info> Policy set 'AO' (wlan0) as default for IPv4 routing and DNS.
     May 29 16:50:19 hostname NetworkManager[757]: <info> Writing DNS information to /sbin/resolvconf
     May 29 16:50:19 hostname dnsmasq[1565]: setting upstream servers from DBus
     May 29 16:50:19 hostname dnsmasq[1565]: using nameserver 10.0.0.2#53 for domain 88.168.192.in-addr.arpa
     May 29 16:50:19 hostname dnsmasq[1565]: using nameserver 10.0.0.138#53
     May 29 16:50:20 hostname NetworkManager[757]: <info> VPN plugin state changed: started (4)
     May 29 16:50:20 hostname dbus[691]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
     May 29 16:50:20 hostname dbus[691]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'

Marqué pour la migration vers le superutilisateur. Vérifiez que votre client ubuntu pptp ne supprime pas uniquement les itinéraires poussés en amont et qu'il dispose des autorisations lui permettant d'ajouter des itinéraires supplémentaires à la table de routage. Si vous souhaitez une aide plus spécifique, indiquez le nom du client PPTP que vous utilisez (il peut s'agir de networkmanager si vous utilisez le client intégré). Vérifiez votre syslog d'ubuntu ( /var/log/<files> ) pour voir s’il ya des erreurs signalées par pptp et ajouter le résultat approprié à votre question.

— Andrew Domaszek

Bonjour Andrew, merci pour la réponse rapide. J'ai édité la question. Ajouter des routes n’est pas un problème, mais les faire fonctionner comme des routes Windows me semble un problème. @ AndrewDomaszek

Si nm-pptp n'expose pas l'option use-routes de ppp, utilisez gsettings, gconf-editor ou dconf-editor comme utilisateur (ou root si vous établissez la connexion pour tous les utilisateurs), et définissez le paramètre use-routes option de yes.

— Andrew Domaszek

@AndrewDomaszek, je n'ai trouvé aucun schéma ni aucune documentation pointant vers use-routes option. Comme je l'ai mentionné dans la question, Windows crée deux routes par défaut. Lors du ping d'un serveur distant (qui a le même sous-réseau que le mien), il essaie d'abord de le trouver localement et, en cas d'échec, une demande au tunnel est envoyée (comme indiqué dans la table de routage par la deuxième passerelle par défaut). Ce n'est pas ce qui se passe dans Ubuntu.

D'après ce que je peux dire de votre sortie, aucun hôte n'a de route à atteindre. 10.0.0.83 à travers le VPN. Les deux ont une table de routage indiquant 10.0.0.83 est directement connecté via le réseau physique.

La sortie Windows suggère que la première trace a échoué en raison d'un délai d'attente ARP. Aucun hôte du réseau directement connecté ne prétend avoir réellement 10.0.0.83Par conséquent, vous voyez un message inaccessible de la machine Windows elle-même.

Ensuite, quelque chose de bizarre se produit, car la prochaine tentative semble être un routage via le VPN. Ceci est légèrement similaire à ce que vous vous attendriez à voir dans le cas d'un message de redirection ICMP, mais pas exactement le même.

Une trace de paquet de la communication réelle pourrait être révélatrice. Est-ce que quelque chose sur le LAN envoie un paquet à la machine Windows, ce qui pourrait expliquer ce changement de comportement?

— kasperd
source

Wireshark dump montre qu'une demande ARP a été faite pour 10.0.0.83 mais qu'elle n'a jamais été répondue. Après une courte période de temps, des paquets PPP encapsulés sont envoyés entre l'adresse VPN publique et l'adresse IP locale. Rien n'indique un comportement étrange ... Il s'agit totalement d'un mécanisme intégré à Windows. Est-il vraiment impossible d'imiter une telle chose sous Linux?

@ user2980615 Quels sont exactement les critères utilisés par Windows? Est-ce qu'il retombera toujours sur un itinéraire moins spécifique, si un itinéraire plus spécifique existe, mais donne un délai d'attente ARP? Il ne serait pas sage de le faire en général car cela pourrait facilement conduire à des boucles de routage. Je ne connais pas de moyen spécifique pour que Linux fasse cela. Au lieu de cela, ma recommandation serait de ne pas réutiliser l'espace d'adressage RFC1918 dans les réseaux qui doivent communiquer entre eux, puis d'utiliser des routes explicites, de sorte que ce type de repli ne soit pas nécessaire.

— kasperd

Il est plus facile pour moi d’établir quelques routes statiques entre moi et certains serveurs distants en plus de changer tout mon sous-réseau de réseau domestique. Je continuerai à chercher une solution intelligente à ce problème ...