La VM Vagrant disparaît quand le VPN se connecte : à qui appartient la route cassée

La machine répondait il y a une minute, le VPN s'est connecté, et maintenant la même adresse expire. Trois défauts produisent ce symptôme, et ils vivent sur des machines différentes. L'hôte peut perdre la route vers le réseau privé, la plage NAT de l'invité peut entrer en collision avec une plage que le tunnel annonce désormais, ou un tunnel complet peut s'approprier l'ensemble des routes de l'hôte. Déterminez lequel s'est produit avant de changer une configuration, car chaque correctif vit ailleurs.

Regardez la route, pas la machine

Examinez la décision de routage de l'hôte pour l'adresse de l'invité pendant que le tunnel est actif. Une route qui pointe encore vers l'adaptateur hôte uniquement n'est pas le problème. Une route qui pointe maintenant vers l'adaptateur VPN est le problème, et c'est le client qui l'a changée, pas vous. Le fait que l'adaptateur conserve son adresse indique que l'interface a survécu, ce qui est un fait différent de la survie du chemin.

Une session SSH qui tombe exactement au moment de la connexion est un comportement attendu. Le client recycle les adaptateurs et installe des routes, donc la connexion meurt pendant quelques secondes. Le défaut est la connexion qui ne revient jamais, pas celle qui a clignoté.

Capturez la table avant le tunnel puis de nouveau après, et comparez ces deux sorties. La différence est le diagnostic, et elle se trouve aussi être la preuve qu'un responsable réseau demandera.

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

Lisez la table de l'hôte avant et après

Sous Linux, la préférence entre routes qui se chevauchent vient de la longueur du préfixe et de la métrique, donc une route VPN plus spécifique gagne même lorsqu'elle est fausse. Sous Windows, la métrique de l'interface tranche l'égalité, et l'adaptateur du tunnel arrive généralement avec une métrique plus basse que le virtuel. Dans les deux cas, le symptôme visible est identique : les paquets sortent par l'adaptateur du tunnel et disparaissent.

Affichez les adaptateurs et leurs métriques à côté de la route du préfixe de l'invité. Cette paire de sorties répond à la question de la propriété d'un seul coup d'œil.

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

Si la route a changé mais pas la métrique de l'adaptateur, le client a installé une route concurrente. Si la métrique a changé, le client a réordonné les adaptateurs. Les deux sont réparables, et ils se réparent à des endroits différents.

Quand la plage NAT de l'invité est la collision

VirtualBox NAT utilise 10.0.2.0/24 par défaut, et un tunnel qui pousse la même plage fait envoyer ce trafic par l'invité vers sa passerelle NAT au lieu de la destination réelle. Le paquet ne quitte jamais l'hôte, donc aucun journal de pare-feu de l'autre côté ne le montrera. Docker Machine a la même classe de conflit dans son plan hôte uniquement, et changer ce plan peut exiger de recréer la machine avec ses certificats.

Choisissez le remplacement en listant ce que le tunnel annonce déjà, puis ce que le réseau du bureau utilise, puis ce que chaque adaptateur virtuel de cet hôte a revendiqué. Le chevauchement est ce qui casse le routage, et la ressemblance est sans importance. Une plage peut tenir entièrement dans une autre tout en n'ayant à première vue aucun air de famille.

Définissez la nouvelle plage à la création de la machine, ou modifiez-la et rechargez, puis retestez la connexion défaillante depuis l'invité. La table de l'invité lui-même est la vue qui compte.

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

Restaurez le chemin sans combattre le client

Chaque plateforme offre un moyen de remettre le préfixe hôte uniquement devant. Sous macOS, une route statique vers l'interface hôte uniquement fonctionne jusqu'à la connexion suivante. Sous Windows, une métrique d'interface plus basse sur l'adaptateur virtuel le maintient préféré. Sous Linux, une opération de remplacement couvre un seul préfixe. Les trois sont des contournements, car un client qui réaffirme ses routes les annulera.

Scriptez la vérification plutôt qu'une reconnexion aveugle au démarrage. Un petit script qui affiche la route du préfixe de l'invité après chaque connexion transforme un mystère en une ligne de journal.

Si le profil est un tunnel complet, demandez au responsable réseau un tunnel divisé ou une exception documentée. Ajouter discrètement des routes qui contournent une politique de sécurité n'est pas un correctif, c'est un second problème qui arrive plus tard avec un auditeur au poignet.

Vérifiez le correctif des deux côtés

Vérifiez trois chemins après le changement : hôte vers invité, invité vers l'hôte d'entreprise et invité vers internet. Un correctif qui en restaure un et en casse un autre est un changement de configuration déguisé en réparation. Capturez les mêmes sorties que celles recueillies avant le changement pour que la comparaison soit à données égales.

Notez l'interface, la métrique et la route qui ont changé, avec l'heure, afin que la prochaine occurrence soit une recherche et non une reconstruction. Cette note vaut plus qu'un long fil de tickets.

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Quand l'hôte atteint de nouveau l'invité et que l'invité atteint le LAN, vous avez restauré le chemin de départ. Quand un seul des deux fonctionne, le défaut restant est sur le territoire de l'autre propriétaire, et la différence vous dit de quel territoire il s'agit.