La VM de Vagrant desapareix quan es connecta la VPN: de qui és la ruta trencada

La màquina responia fa un minut, la VPN s'ha connectat i ara la mateixa adreça no respon. Tres fallades produeixen aquest símptoma i viuen en màquines diferents. L'amfitrió pot perdre la ruta cap a la xarxa privada, el rang NAT del convidat pot xocar amb un rang que el túnel ara anuncia, o un túnel complet pot prendre possessió de totes les rutes de l'amfitrió. Esbrineu quina ha passat abans de canviar cap configuració, perquè cada correcció viu en un lloc diferent.

Mireu la ruta, no la màquina

Mireu la decisió d'encaminament de l'amfitrió per a l'adreça del convidat mentre el túnel està actiu. Una ruta que encara apunta a l'adaptador només d'amfitrió no és el problema. Una ruta que ara apunta a l'adaptador de la VPN sí que és el problema, i l'ha canviat el client, no vosaltres. Que l'adaptador conservi la seva adreça us diu que la interfície ha sobreviscut, un fet diferent del fet que el camí sobrevisqui.

Una sessió SSH que cau exactament en el moment de connectar és un comportament esperat. El client recicla adaptadors i instal·la rutes, així que la connexió mor durant uns segons. La fallada és la connexió que no torna mai, no la que va parpellejar.

Captureu la taula abans del túnel i una altra vegada després, i llavors compareu aquestes dues sortides. La diferència és el diagnòstic, i també resulta ser l'evidència que demanarà el responsable de la xarxa.

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

Llegiu la taula de l'amfitrió abans i després

A Linux la preferència entre rutes superposades ve de la longitud del prefix i de la mètrica, així que una ruta VPN més específica guanya encara que sigui incorrecta. A Windows la mètrica de la interfície decideix l'empat, i l'adaptador del túnel sol arribar amb una mètrica més baixa que el virtual. En tots dos casos el símptoma visible és idèntic: els paquets surten per l'adaptador del túnel i desapareixen.

Imprimiu els adaptadors i les seves mètriques al costat de la ruta del prefix del convidat. Aquest parell de sortides respon la pregunta de la propietat d'una ullada.

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 ruta ha canviat però la mètrica de l'adaptador no, el client ha instal·lat una ruta competidora. Si la mètrica ha canviat, el client ha reordenat els adaptadors. Totes dues són reparables, i es reparen en llocs diferents.

Quan el rang NAT del convidat és la col·lisió

VirtualBox NAT fa servir 10.0.2.0/24 per defecte, i un túnel que empeny el mateix rang fa que el convidat enviï aquest trànsit a la seva passarel·la NAT en lloc de la destinació real. El paquet no surt mai de l'amfitrió, així que cap registre de tallafoc de l'altre costat el mostrarà. Docker Machine té la mateixa classe de conflicte en el seu pla només d'amfitrió, i canviar aquest pla pot requerir recrear la màquina amb els seus certificats.

Trieu el reemplaçament llistant què anuncia ja el túnel, després què fa servir la xarxa de l'oficina i després què ha reclamat cada adaptador virtual d'aquest amfitrió. La superposició és el que trenca l'encaminament, i el semblant és irrellevant. Un rang pot seure completament dins d'un altre mentre no s'assembla gens a primera vista.

Definiu el nou rang quan es crea la màquina, o canvieu-lo i recarregueu, i després torneu a provar la connexió que falla des del convidat. La taula del propi convidat és la vista que importa.

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

Restaureu el camí sense barallar-vos amb el client

Cada plataforma ofereix una manera de tornar a posar al davant el prefix només d'amfitrió. A macOS una ruta estàtica cap a la interfície només d'amfitrió funciona fins a la propera connexió. A Windows una mètrica d'interfície més baixa a l'adaptador virtual el manté preferit. A Linux una operació de substitució cobreix un sol prefix. Les tres són solucions provisionals, perquè un client que torna a imposar les seves rutes les desfarà.

Programeu la comprovació en lloc d'una reconnexió cega a l'arrencada. Un petit script que imprimeix la ruta del prefix del convidat després de cada connexió converteix un misteri en una línia d'un registre.

Si el perfil és un túnel complet, demaneu al responsable de la xarxa un túnel dividit o una excepció documentada. Afegir en silenci rutes que eludeixen una política de seguretat no és una correcció, és un segon problema que arriba més tard amb un auditor a coll.

Comproveu la correcció a les dues bandes

Verifiqueu tres camins després del canvi: amfitrió a convidat, convidat a l'amfitrió corporatiu i convidat a internet. Una correcció que en restaura un i en trenca un altre és un canvi de configuració disfressat de reparació. Captureu les mateixes sortides que vau recollir abans del canvi perquè la comparació sigui entre iguals.

Anoteu la interfície, la mètrica i la ruta que han canviat, juntament amb l'hora, perquè la propera ocasió sigui una consulta i no una reconstrucció. Aquesta nota val més que un llarg fil de tiquets.

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

Quan l'amfitrió torna a arribar al convidat i el convidat arriba a la LAN, heu restaurat el camí amb què vau començar. Quan només un dels dos funciona, la fallada restant és al territori de l'altre propietari, i la diferència us diu quin territori és.