Vagrant-VM försvinner när VPN:en ansluter: vems rutt gick sönder

Maskinen svarade för en minut sedan, VPN:en anslöt och nu går samma adress i timeout. Tre fel ger det symptomet, och de bor på olika maskiner. Värden kan tappa rutten till det privata nätet, gästens NAT-intervall kan kollidera med ett intervall som tunneln nu annonserar, eller en full tunnel kan ta över ägarskapet för varje rutt på värden. Ta reda på vilket som hände innan du ändrar någon konfiguration, för varje åtgärd bor någon annanstans.

Titta på rutten, inte på maskinen

Titta på värdens routingbeslut för gästadressen medan tunneln är uppe. En rutt som fortfarande pekar på endast-värd-adaptern är inte problemet. En rutt som nu pekar på VPN-adaptern är problemet, och det var klienten som ändrade den, inte du. Att adaptern behåller sin adress säger att gränssnittet överlevde, vilket är ett annat faktum än att vägen överlevde.

En SSH-session som faller precis i anslutningsögonblicket är förväntat beteende. Klienten återanvänder adaptrar och installerar rutter, så anslutningen dör i några sekunder. Felet är anslutningen som aldrig kommer tillbaka, inte den som bara blinkade.

Fånga tabellen före tunneln och igen efter den, och jämför sedan de två utskrifterna. Skillnaden är diagnosen, och den råkar också vara beviset som en nätverksägare kommer att begära.

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

Läs värdens tabell före och efter

På Linux kommer företrädet mellan överlappande rutter från prefixlängd och metrik, så en mer specifik VPN-rutt vinner även när den är fel. På Windows avgör gränssnittsmetriken oavgjort, och tunneladaptern kommer vanligtvis med lägre metrik än den virtuella. I båda fallen är det synliga symptomet identiskt: paketen lämnar via tunneladaptern och försvinner.

Skriv ut adaptrarna och deras metrik bredvid rutten för gästprefixet. Det paret utskrifter besvarar ägarskapsfrågan med en blick.

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

Om rutten ändrades men adapterns metrik inte, installerade klienten en konkurrerande rutt. Om metriken ändrades ordnade klienten om adaptrarna. Båda går att åtgärda, och de åtgärdas på olika ställen.

När gästens NAT-intervall är kollisionen

VirtualBox NAT använder 10.0.2.0/24 som standard, och en tunnel som trycker samma intervall får gästen att skicka den trafiken till sin NAT-gateway i stället för till den verkliga destinationen. Paketet lämnar aldrig värden, så ingen brandväggslogg på andra sidan kommer att visa det. Docker Machine har samma klass av konflikt i sin endast-värd-plan, och att ändra den planen kan kräva att maskinen återskapas tillsammans med sina certifikat.

Välj ersättningen genom att lista vad tunneln redan annonserar, sedan vad kontorsnätet använder, sedan vad varje virtuell adapter på den här värden har gjort anspråk på. Överlapp är det som bryter routingen, och likhet är irrelevant. Ett intervall kan ligga helt inuti ett annat medan det vid första anblicken inte alls liknar det.

Sätt det nya intervallet när maskinen skapas, eller ändra det och ladda om, och testa sedan den felande anslutningen igen från gästen. Gästens egen tabell är den vy som spelar roll.

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

Återställ vägen utan att slåss med klienten

Varje plattform erbjuder ett sätt att sätta endast-värd-prefixet främst igen. På macOS fungerar en statisk rutt till endast-värd-gränssnittet till nästa anslutning. På Windows håller en lägre gränssnittsmetrik på den virtuella adaptern den föredragen. På Linux täcker en ersättningsoperation ett enda prefix. Alla tre är workarounds, eftersom en klient som hävdar sina rutter igen kommer att upphäva dem.

Skripta kontrollen i stället för en blind återanslutning vid uppstart. Ett litet skript som skriver ut rutten för gästprefixet efter varje anslutning förvandlar ett mysterium till en rad i en logg.

Om profilen är en full tunnel, be nätverksägaren om delad tunnling eller ett dokumenterat undantag. Att i tysthet lägga till rutter som kringgår en säkerhetspolicy är ingen åtgärd, det är ett andra problem som kommer senare med en revisor i släptåg.

Kontrollera åtgärden på båda sidor

Verifiera tre vägar efter ändringen: värd till gäst, gäst till den företagsinterna värden och gäst till internet. En åtgärd som återställer en av dem och bryter en annan är en konfigurationsändring förklädd till reparation. Fånga samma utskrifter som du samlade in före ändringen, så att jämförelsen blir lik med lik.

Notera gränssnittet, metriken och rutten som ändrades, tillsammans med tiden, så att nästa förekomst är ett uppslag och inte en återuppbyggnad. Den anteckningen är värd mer än en lång ärendetrå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 värden når gästen igen och gästen når LAN:et har du återställt vägen du började med. När bara en av dem fungerar ligger det kvarvarande felet på den andra ägarens område, och skillnaden talar om vilket område det är.