VPN på, VM oåtkomlig? Rutten var förmodligen aldrig problemet

Anslut VPN, och utvecklings-VM:en som svarade för en minut sedan tystnar. Den uppenbara historien skriver sig själv: tunneln tog rutten, värden skickar nu gästtrafiken in i företagsnätet, och lösningen är att lägga till en statisk rutt eller byta adaptern till bryggläge. Den historien är ibland sann. Men det är inte den vanliga orsaken, och att agera på den först brukar förstöra något annat.

Host-only-nätverk är ett programvarunät som ägs av värden och delas med dess gäster, skilt från varje fysisk anslutning. Inget i VPN-klientens eget gränssnitt ändrar det nätet, så innan du rör det, ta reda på vilket av fyra lager som faktiskt misslyckades.

Rutten är oftast fortfarande lokal

Fråga kärnan i stället för routningstabellens förstasida. På Linux rapporterar ip route get 192.168.56.10 den exakta rutten, gränssnittet och källadressen som skulle användas, vilket är ett annat svar än att läsa en standardrutt och gissa. Om utdata namnger host-only-gränssnittet är tunneln inte inblandad i den vägen alls.

Två saker kan verkligen bryta det, och båda är adressproblem snarare än VPN-problem. Ett fjärrsubnät som överlappar host-only-prefixet gör att den mer specifika rutten vinner, och en VPN-klient som installerar en bred rutt med lägre metrik kan dra bort prefixet. Båda syns i samma kommando: gränssnittet som nämns i utdata blir tunneln, och rättelsen tillhör den som äger den adressplanen.

Ruttval och paketinsläpp är olika beslut

Det här är delen som den mentala modellen oftast missar. Även med en perfekt lokal rutt kan en VPN-klient neka paketet. Många klienter tillämpar en policy för lokal nätverksåtkomst som avgör vilka destinationer som är tillåtna utanför tunneln, och ett anslutet subnät uppdaterar inte den listan automatiskt.

Så felet ser identiskt ut med ett routningsproblem från applikationens sida, och helt annorlunda från klientens sida. Om ip route get namnger rätt gränssnitt och anslutningen ändå löper ut, sluta redigera rutter och läs i stället klientens dokumenterade lokala åtkomstbeteende. Vissa klienter erbjuder en tillåtelselista för lokala subnät, andra blockerar allt som inte är tunneln, och ytterligare andra blockerar bara när en kill switch är aktiverad.

Den skillnaden spelar roll eftersom rättelserna inte är utbytbara. Att lägga till en rutt kan inte tillfredsställa ett filter, och att stänga av ett filter för att nå en enda gäst är ett mycket större beslut än symptomet antyder.

Gästen har tre sätt att säga nej

En gäst som kan surfa på internet har inte bevisat något om tjänsten du vill ha. Lyssnaren kan vara bunden till 127.0.0.1 inne i gästen, och då kan ingen begäran från värden komma fram, hur bra vägen än är. Kontrollera med ss -ltn i gästen och titta på kolumnen för den lokala adressen, inte bara porten.

Nästa är gästens egen brandvägg. En utvecklingsavbild med en restriktiv standardinställning kan ta emot värdens paket och släppa dem vid tjänstegränsen, vilket ger en tidsgräns som ser exakt ut som ett routningssvart hål. Slutligen finns tjänstens egen konfiguration: en webbapp bunden till ett visst värdnamn, eller en tillåtelselista med klientadresser, vägrar en begäran från host-only-subnätet även när varje paket anländer.

Arbeta igenom de tre innan du överväger att ändra VM:ens nätverksläge. Var och en är en mindre ändring än att tänka om gästens anslutning, och var och en har ett tydligt test.

Vad en brygga egentligen är, och vad den kostar

Att byta adaptern till bryggläge är inte en reparation av host-only-vägen. Det är ett beslut att sätta gästen på ett annat nät, oftast det fysiska LAN:et, där den blir synlig för allt annat som bor där. Det kan vara precis vad du vill. Men det är inte vad den ursprungliga konfigurationen gjorde.

Använd det när gästen verkligen måste vara en jämlik part på det LAN:et och exponeringen är godkänd. Använd det inte för att en enda tjänst slutade svara, eftersom ändringen kan flytta gästen ut ur den isolering som gjorde det säkert att utveckla mot den.

Efter varje godkänd rättelse, testa i fast ordning: en ny begäran från värden till gästen, en nödvändig företagsresurs genom tunneln, och det avsedda nekade beteendet med tunneln nere. Om det sista inte längre gäller gick rättelsen längre än problemet.

VirtualBox avsnitt om host-only-nätverk beskriver programvarugränssnittet på värdsidan och hur det skiljer sig från en brygganslutning, vilket är referensen som är värd att läsa innan man antar att de två lägena kan bytas ut.