Vagrant-VM forsvinner når VPN-en kobler til: hvis rute ble brutt

Maskinen svarte for et minutt siden, VPN-en koblet til, og nå går samme adresse i timeout. Tre feil gir det symptomet, og de bor på forskjellige maskiner. Verten kan miste ruten til det private nettet, NAT-området til gjesten kan kollidere med et område som tunnelen nå annonserer, eller en full tunnel kan overta eierskapet til hver rute på verten. Finn ut hvilken som skjedde før du endrer noen konfigurasjon, for hver rettelse bor et annet sted.

Se på ruten, ikke på maskinen

Se på vertens rutingsbeslutning for gjesteadressen mens tunnelen er oppe. En rute som fortsatt peker på bare-vert-adapteren, er ikke problemet. En rute som nå peker på VPN-adapteren, er problemet, og det var klienten som endret den, ikke du. At adapteren beholder adressen, forteller at grensesnittet overlevde, noe som er et annet faktum enn at veien overlevde.

En SSH-økt som faller nøyaktig i tilkoblingsøyeblikket, er forventet atferd. Klienten resirkulerer adaptere og installerer ruter, så forbindelsen dør i noen sekunder. Feilen er forbindelsen som aldri kommer tilbake, ikke den som bare blinket.

Ta tabellen før tunnelen og igjen etter den, og sammenlign så de to utskriftene. Forskjellen er diagnosen, og den er også beviset en nettverkseier vil be om.

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

Les vertens tabell før og etter

På Linux kommer forrangen mellom overlappende ruter fra prefikslengde og metrikk, så en mer spesifikk VPN-rute vinner selv når den er feil. På Windows avgjør grensesnittmetrikken uavgjort, og tunneladapteren kommer vanligvis med lavere metrikk enn den virtuelle. I begge tilfeller er det synlige symptomet identisk: pakkene forlater via tunneladapteren og forsvinner.

Skriv ut adapterne og metrikkene deres ved siden av ruten for gjesteprefikset. Det paret med utskrifter besvarer eierskapsspørsmålet med ett blikk.

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 endret seg, men metrikken til adapteren ikke, installerte klienten en konkurrerende rute. Hvis metrikken endret seg, omorganiserte klienten adapterne. Begge kan rettes, og de rettes på forskjellige steder.

Når NAT-området til gjesten er kollisjonen

VirtualBox NAT bruker 10.0.2.0/24 som standard, og en tunnel som skyver samme område, får gjesten til å sende den trafikken til NAT-gatewayen sin i stedet for til den virkelige destinasjonen. Pakken forlater aldri verten, så ingen brannmurlogg på den andre siden vil vise den. Docker Machine har samme klasse konflikt i bare-vert-planen sin, og å endre den planen kan kreve at maskinen gjenskapes sammen med sertifikatene sine.

Velg erstatningen ved å liste opp hva tunnelen allerede annonserer, så hva kontornettet bruker, så hva hver virtuell adapter på denne verten har gjort krav på. Overlapp er det som bryter rutingen, og likhet er irrelevant. Ett område kan ligge helt inne i et annet mens det ved første øyekast ikke ligner i det hele tatt.

Sett det nye området når maskinen opprettes, eller endre det og last inn på nytt, og test så den feilende forbindelsen igjen fra gjesten. Gjestens egen tabell er visningen som betyr noe.

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

Gjenopprett veien uten å kjempe mot klienten

Hver plattform tilbyr en måte å sette bare-vert-prefikset foran igjen. På macOS virker en statisk rute til bare-vert-grensesnittet til neste tilkobling. På Windows holder en lavere grensesnittmetrikk på den virtuelle adapteren den foretrukket. På Linux dekker en erstatningsoperasjon ett prefiks. Alle tre er workarounds, fordi en klient som hevder rutene sine på nytt, vil oppheve dem.

Skript kontrollen i stedet for en blind gjenoppkobling ved oppstart. Et lite skript som skriver ut ruten for gjesteprefikset etter hver tilkobling, gjør et mysterium til en linje i en logg.

Hvis profilen er en full tunnel, be nettverkseieren om delt tunnel eller et dokumentert unntak. Å legge til ruter i det stille som omgår en sikkerhetspolicy, er ikke en rettelse, det er et andre problem som kommer senere med en revisor på slep.

Kontroller rettelsen på begge sider

Verifiser tre veier etter endringen: vert til gjest, gjest til den bedriftsmessige verten og gjest til internett. En rettelse som gjenoppretter en av dem og ødelegger en annen, er en konfigurasjonsendring forkledd som reparasjon. Ta de samme utskriftene som du samlet inn før endringen, så sammenligningen blir lik med lik.

Noter grensesnittet, metrikken og ruten som endret seg, sammen med tidspunktet, så neste forekomst er et oppslag og ikke en gjenoppbygging. Den noten er mer verdt enn en lang sakstråd.

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 verten når gjesten igjen og gjesten når LAN-et, har du gjenopprettet veien du startet med. Når bare én av dem virker, er den gjenværende feilen på den andre eierens område, og forskjellen forteller deg hvilket område det er.