VPN på, VM utilgjengelig? Ruten var sannsynligvis aldri problemet

Koble til VPN, og utviklings-VM-en som svarte for et minutt siden blir stille. Den opplagte historien skriver seg selv: tunnelen tok ruten, verten sender nå gjestetrafikk inn i bedriftsnettet, og løsningen er å legge til en statisk rute eller bytte adapteret til bromodus. Den historien er noen ganger sann. Men det er ikke den vanlige årsaken, og å handle på den først ødelegger vanligvis noe annet.

Host-only-nettverk er et programvarenettverk som eies av verten og deles med gjestene, atskilt fra enhver fysisk tilkobling. Ingenting i VPN-klientens eget grensesnitt endrer det nettverket, så før du rører det, finn ut hvilket av fire lag som faktisk sviktet.

Ruten er vanligvis fortsatt lokal

Spør kjernen i stedet for forsiden av rutetabellen. På Linux rapporterer ip route get 192.168.56.10 den nøyaktige ruten, grensesnittet og kildeadressen som ville blitt brukt, noe som er et annet svar enn å lese en standardrute og gjette. Hvis utdataene nevner host-only-grensesnittet, er tunnelen ikke involvert i den stien i det hele tatt.

To ting kan virkelig ødelegge det, og begge er adresseproblemer snarere enn VPN-problemer. Et eksternt subnett som overlapper host-only-prefikset gjør at den mer spesifikke ruten vinner, og en VPN-klient som installerer en bred rute med lavere metrikk kan trekke prefikset bort. Begge er synlige i samme kommando: grensesnittet som nevnes i utdataene vil være tunnelen, og rettelsen tilhører den som eier den adresseplanen.

Rutevalg og pakkeadgang er forskjellige beslutninger

Dette er delen den mentale modellen vanligvis overser. Selv med en perfekt lokal rute kan en VPN-klient avvise pakken. Mange klienter håndhever en lokal nettverkstilgangspolicy som avgjør hvilke mål som er tillatt utenfor tunnelen, og et tilkoblet subnett oppdaterer ikke den listen automatisk.

Så feilen ser identisk ut med et ruteproblem fra applikasjonens side, og helt annerledes fra klientens side. Hvis ip route get nevner riktig grensesnitt og tilkoblingen fortsatt utløper, slutt å redigere ruter og les i stedet klientens dokumenterte lokale tilgangsatferd. Noen klienter tilbyr en tillatelsesliste for lokale subnett, noen blokkerer alt som ikke er tunnelen, og noen blokkerer bare når en kill switch er aktivert.

Den forskjellen betyr noe fordi rettelsene ikke kan byttes. Å legge til en rute kan ikke tilfredsstille et filter, og å deaktivere et filter for å nå én gjest er en mye større beslutning enn symptomet antyder.

Gjesten har tre måter å si nei på

En gjest som kan surfe på internett har ikke bevist noe om tjenesten du vil ha. Lytteren kan være bundet til 127.0.0.1 inne i gjesten, og da kan ingen forespørsel fra verten komme frem, uansett hvor god stien er. Kontroller med ss -ltn i gjesten og se på kolonnen for den lokale adressen, ikke bare porten.

Neste er gjestens egen brannmur. Et utviklingsbilde med en restriktiv standard kan godta vertens pakker og droppe dem ved tjenestegrensen, noe som gir en tidsavbrudd som ser nøyaktig ut som et ruting-sort hull. Til slutt er det tjenestens egen konfigurasjon: en webapp bundet til et bestemt vertsnavn, eller en tillatelsesliste med klientadresser, vil avvise en forespørsel fra host-only-subnettet selv når hver pakke ankommer.

Gå gjennom de tre før du vurderer å endre nettverksmodusen til VM-en. Hver er en mindre endring enn å tenke nytt om gjestens tilkobling, og hver har en klar test.

Hva en bro egentlig er, og hva den koster

Å bytte adapteret til bromodus er ikke en reparasjon av host-only-stien. Det er en beslutning om å sette gjesten på et annet nettverk, vanligvis det fysiske LAN-et, der den blir synlig for alt annet som bor der. Det kan være nøyaktig det du vil. Men det er ikke det den opprinnelige konfigurasjonen gjorde.

Bruk det når gjesten virkelig må være en likeverdig part på det LAN-et og eksponeringen er godkjent. Ikke bruk det fordi en enkelt tjeneste sluttet å svare, siden endringen kan flytte gjesten ut av isolasjonen som gjorde det trygt å utvikle mot den.

Etter hver godkjent rettelse, test i fast rekkefølge: en ny forespørsel fra verten til gjesten, en påkrevd bedriftsressurs gjennom tunnelen, og den tiltenkte avviste atferden med tunnelen nede. Hvis den siste ikke lenger holder, gikk rettelsen utover problemet.

VirtualBox' avsnitt om host-only-nettverk beskriver programvaregrensesnittet på vertssiden og hvordan det skiller seg fra en brotilkobling, som er referansen det er verdt å lese før man antar at de to modusene kan byttes.