Vagrant-VM forsvinder, når VPN'en forbinder: hvis rute gik i stykker

Maskinen svarede for et minut siden, VPN'en blev forbundet, og nu går den samme adresse i timeout. Tre fejl giver det symptom, og de bor på forskellige maskiner. Værten kan miste ruten til det private netværk, gæstens NAT-interval kan støde sammen med et interval, som tunnelen nu annoncerer, eller en fuld tunnel kan overtage ejerskabet af hver rute på værten. Find ud af, hvilken der skete, før du ændrer nogen konfiguration, for hver rettelse bor et andet sted.

Hold øje med ruten, ikke maskinen

Se på værtens routingbeslutning for gæsteadressen, mens tunnelen er oppe. En rute, der stadig peger på kun-vært-adapteren, er ikke problemet. En rute, der nu peger på VPN-adapteren, er problemet, og det var klienten, ikke dig, der ændrede den. At adapteren beholder sin adresse fortæller, at grænsefladen overlevede, hvilket er et andet faktum end at stien overlevede.

En SSH-session, der falder præcis i forbindelsesøjeblikket, er forventet adfærd. Klienten genbruger adaptere og installerer ruter, så forbindelsen dør i få sekunder. Fejlen er den forbindelse, der aldrig kommer tilbage, ikke den, der blinkede.

Tag tabellen før tunnelen og igen efter den, og sammenlign så de to output. Forskellen er diagnosen, og den er også det bevis, en netværksejer vil bede om.

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

Læs værtens tabel før og efter

På Linux kommer forrangen mellem overlappende ruter fra præfikslængde og metrik, så en mere specifik VPN-rute vinder, selv når den er forkert. På Windows afgør grænseflademetriken uafgjort, og tunneladapteren ankommer normalt med en lavere metrik end den virtuelle. I begge tilfælde er det synlige symptom identisk: pakker forlader via tunneladapteren og forsvinder.

Udskriv adapterne og deres metrik ved siden af ruten for gæstepræfikset. Det par output besvarer ejerskabsspørgsmålet med ét blik.

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

Hvis ruten ændrede sig, men adapterens metrik ikke gjorde, installerede klienten en konkurrerende rute. Hvis metrikken ændrede sig, omarrangerede klienten adapterne. Begge kan rettes, og de rettes forskellige steder.

Når gæstens NAT-interval er sammenstødet

VirtualBox NAT bruger 10.0.2.0/24 som standard, og en tunnel, der skubber det samme interval, får gæsten til at sende den trafik til sin NAT-gateway i stedet for til den rigtige destination. Pakken forlader aldrig værten, så ingen firewalllog i den anden ende vil vise den. Docker Machine har samme klasse konflikt i sin kun-vært-plan, og ændring af den plan kan kræve, at maskinen genskabes sammen med dens certifikater.

Vælg erstatningen ved at liste, hvad tunnelen allerede annoncerer, derefter hvad kontornetværket bruger, derefter hvad hver virtuel adapter på denne vært har gjort krav på. Overlap er det, der ødelægger routing, og lighed er irrelevant. Et interval kan ligge helt inde i et andet, mens det ved første øjekast slet ikke ligner.

Sæt det nye interval, når maskinen oprettes, eller ændr det og genindlæs, og test så den fejlende forbindelse igen fra gæsten. Gæstens egen tabel er den visning, der betyder noget.

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

Gendan stien uden at kæmpe med klienten

Hver platform tilbyder en måde at sætte kun-vært-præfikset forrest igen. På macOS virker en statisk rute til kun-vært-grænsefladen indtil næste forbindelse. På Windows holder en lavere grænseflademetrik på den virtuelle adapter den foretrukket. På Linux dækker en erstatningsoperation et enkelt præfiks. Alle tre er workarounds, fordi en klient, der igen hævder sine ruter, vil ophæve dem.

Skript tjekket i stedet for en blind genforbindelse ved opstart. Et lille script, der udskriver ruten for gæstepræfikset efter hver forbindelse, gør et mysterium til en linje i en log.

Hvis profilen er en fuld tunnel, bed netværksejeren om split tunnelling eller en dokumenteret undtagelse. Stille at tilføje ruter, der omgår en sikkerhedspolitik, er ikke en rettelse, det er et andet problem, der kommer senere med en revisor.

Kontroller rettelsen på begge sider

Verificer tre stier efter ændringen: vært til gæst, gæst til den korporative vært og gæst til internettet. En rettelse, der gendanner en af dem og ødelægger en anden, er en konfigurationsændring forklædt som en reparation. Tag de samme output, som du indsamlede før ændringen, så sammenligningen er lig med lig.

Noter grænsefladen, metrikken og ruten, der ændrede sig, sammen med tidspunktet, så den næste forekomst er et opslag i stedet for en genopbygning. Den note er mere værd end en lang ticketsnor.

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

Når værten igen når gæsten, og gæsten når LAN'et, har du gendannet den sti, du startede med. Når kun en af dem virker, er den resterende fejl på den anden ejers område, og forskellen fortæller dig, hvilket område det er.