VPN tændt, VM utilgængelig? Ruten var sandsynligvis aldrig problemet

Tilslut VPN, og den udviklings-VM, der svarede for et minut siden, bliver stille. Den oplagte historie skriver sig selv: tunnelen tog ruten, værten sender nu gæstetrafik ind i virksomhedsnetværket, og løsningen er at tilføje en statisk rute eller skifte adapteren til brotilstand. Den historie er nogle gange sand. Men det er ikke den sædvanlige årsag, og at handle på den først ødelægger normalt noget andet.

Host-only-netværk er et softwarenetværk, som værten ejer og deler med sine gæster, adskilt fra enhver fysisk tilslutning. Intet i VPN-klientens egen grænseflade ændrer det netværk, så før du rører ved det, skal du finde ud af, hvilket af fire lag der faktisk fejlede.

Ruten er normalt stadig lokal

Spørg kernen i stedet for routingtabellens forside. På Linux rapporterer ip route get 192.168.56.10 den præcise rute, grænseflade og kildeadresse, der ville blive brugt, hvilket er et andet svar end at læse en standardrute og gætte. Hvis outputtet nævner host-only-grænsefladen, er tunnelen slet ikke involveret i den sti.

To ting kan virkelig ødelægge det, og begge er adresseproblemer snarere end VPN-problemer. Et fjernsubnet, der overlapper host-only-præfikset, gør den mere specifikke rute til vinderen, og en VPN-klient, der installerer en bred rute med lavere metrik, kan trække præfikset væk. Begge er synlige i samme kommando: grænsefladen nævnt i outputtet vil være tunnelen, og rettelsen hører til den, der ejer den adresseplan.

Rutevalg og pakkeadgang er forskellige beslutninger

Det er den del, den mentale model sædvanligvis overser. Selv med en perfekt lokal rute kan en VPN-klient afvise pakken. Mange klienter håndhæver en lokal netværksadgangspolitik, der afgør, hvilke destinationer der er tilladte uden for tunnelen, og et tilsluttet subnet opdaterer ikke den liste automatisk.

Så fejlen ser identisk ud med et routingproblem fra applikationens side og helt anderledes fra klientens side. Hvis ip route get nævner den rigtige grænseflade, og forbindelsen stadig udløber, skal du stoppe med at redigere ruter og i stedet læse klientens dokumenterede lokale adgangsadfærd. Nogle klienter giver en tilladelsesliste til lokale subnets, nogle blokerer alt, der ikke er tunnelen, og nogle blokerer kun, når en kill switch er aktiveret.

Den forskel betyder noget, fordi rettelserne ikke kan byttes. At tilføje en rute kan ikke tilfredsstille et filter, og at deaktivere et filter for at nå én gæst er en meget større beslutning, end symptomet antyder.

Gæsten har tre måder at sige nej på

En gæst, der kan browse internettet, har ikke bevist noget om den tjeneste, du vil have. Lytteren kan være bundet til 127.0.0.1 inde i gæsten, og i så fald kan ingen anmodning fra værten ankomme, uanset hvor god stien er. Kontroller med ss -ltn i gæsten, og se på kolonnen med den lokale adresse i stedet for kun porten.

Næste er gæstens egen firewall. Et udviklingsimage med en restriktiv standard kan acceptere værtens pakker og droppe dem ved tjenestegrænsen, hvilket giver en timeout, der ser præcis ud som et routing-sort hul. Endelig er der tjenestens egen konfiguration: en webapp bundet til et bestemt værtsnavn eller en tilladelsesliste med klientadresser vil afvise en anmodning fra host-only-subnettet, selv når hver pakke ankommer.

Gå gennem de tre, før du overvejer at ændre VM'ens netværkstilstand. Hver er en mindre ændring end at gentænke gæstens tilslutning, og hver har en klar test.

Hvad en bro egentlig er, og hvad den koster

At skifte adapteren til brotilstand er ikke en reparation af host-only-stien. Det er en beslutning om at sætte gæsten på et andet netværk, normalt det fysiske LAN, hvor den bliver synlig for alt andet, der bor der. Det kan være præcis, hvad du vil have. Men det er ikke, hvad den oprindelige konfiguration gjorde.

Brug det, når gæsten virkelig skal være en ligemand på det LAN, og eksponeringen er godkendt. Brug det ikke, fordi en enkelt tjeneste holdt op med at svare, da ændringen kan flytte gæsten ud af den isolation, der gjorde det sikkert at udvikle mod den.

Efter enhver godkendt rettelse skal du teste i en fast rækkefølge: en ny anmodning fra værten til gæsten, en påkrævet virksomhedsressource gennem tunnelen og den tilsigtede afviste adfærd med tunnelen nede. Hvis den sidste ikke længere holder, gik rettelsen ud over problemet.

VirtualBox' afsnit om host-only-netværk beskriver softwaregrænsefladen på værtssiden og hvordan den adskiller sig fra en brotilslutning, hvilket er den reference, der er værd at læse, før man antager, at de to tilstande kan byttes.