VPN aan, VM onbereikbaar? De route was waarschijnlijk nooit het probleem

Zet de VPN aan, en de ontwikkel-VM die een minuut geleden nog antwoordde, wordt stil. Het voor de hand liggende verhaal schrijft zichzelf: de tunnel pakte de route, de host stuurt het gastverkeer nu het bedrijfsnetwerk in, en de oplossing is een statische route toevoegen of de adapter naar bridgemodus omzetten. Dat verhaal klopt soms. Maar het is niet de gebruikelijke oorzaak, en daar als eerste naar handelen breekt meestal iets anders.

Host-only-netwerken is een softwarenetwerk dat eigendom is van de host en met zijn gasten wordt gedeeld, los van elke fysieke aansluiting. Niets in de eigen interface van een VPN-client verandert dat netwerk, dus zoek uit welke van de vier lagen echt heeft gefaald voordat je het aanraakt.

De route blijft meestal nog lokaal

Vraag het de kernel in plaats van de voorpagina van de routetabel. Op Linux meldt ip route get 192.168.56.10 de exacte route, interface en bronadres die gebruikt zouden worden, wat een ander antwoord is dan een standaardroute lezen en gokken. Als de uitvoer de host-only-interface noemt, is de tunnel helemaal niet bij dat pad betrokken.

Twee dingen kunnen het echt breken, en beide zijn adresproblemen en geen VPN-problemen. Een extern subnet dat overlapt met het host-only-prefix laat de specifiekere route winnen, en een VPN-client die een brede route met een lagere metriek installeert kan het prefix wegtrekken. Beide zijn zichtbaar in hetzelfde commando: de interface die in de uitvoer wordt genoemd is de tunnel, en de correctie hoort bij wie dat adresplan bezit.

Routeselectie en pakkettoelating zijn verschillende beslissingen

Dit is het deel dat het mentale model meestal mist. Zelfs met een perfecte lokale route kan een VPN-client het pakket weigeren. Veel clients hanteren een lokaal netwerktoegangsbeleid dat bepaalt welke bestemmingen buiten de tunnel zijn toegestaan, en een aangesloten subnet werkt die lijst niet automatisch bij.

De storing ziet er dus vanuit de applicatie identiek uit als een routeringsprobleem, en vanuit de client heel anders. Als ip route get de juiste interface noemt en de verbinding toch verloopt, stop dan met het bewerken van routes en lees in plaats daarvan het gedocumenteerde lokale toegangsgedrag van de client. Sommige clients bieden een allowlist voor lokale subnetten, andere blokkeren alles wat niet de tunnel is, en weer andere blokkeren alleen wanneer een kill switch is ingeschakeld.

Dat onderscheid is belangrijk omdat de oplossingen niet uitwisselbaar zijn. Een route toevoegen kan een filter niet bevredigen, en een filter uitschakelen om één gast te bereiken is een veel grotere beslissing dan het symptoom suggereert.

De gast heeft drie manieren om nee te zeggen

Een gast die op internet kan browsen heeft niets bewezen over de dienst die je wilt. De listener kan in de gast aan 127.0.0.1 gebonden zijn, en dan kan er geen verzoek van de host aankomen, hoe goed het pad ook is. Controleer met ss -ltn in de gast en kijk naar de kolom van het lokale adres, niet alleen naar de poort.

Daarna komt de eigen firewall van de gast. Een ontwikkelimage met een beperkende standaardinstelling kan de pakketten van de host aannemen en ze bij de dienstgrens laten vallen, wat een time-out oplevert die er precies als een routeringszwart gat uitziet. Ten slotte is er de eigen configuratie van de dienst: een webapp die aan een bepaalde hostnaam is gebonden, of een allowlist met clientadressen, weigert een verzoek uit het host-only-subnet, zelfs wanneer elk pakket aankomt.

Werk die drie af voordat je overweegt de netwerkmodus van de VM te wijzigen. Elk is een kleinere wijziging dan de aansluiting van de gast opnieuw ontwerpen, en elk heeft een duidelijke test.

Wat een bridge werkelijk is, en wat hij kost

De adapter naar bridgemodus omzetten is geen reparatie van het host-only-pad. Het is de beslissing om de gast op een ander netwerk te zetten, meestal het fysieke LAN, waar hij zichtbaar wordt voor alles wat daar leeft. Dat kan precies zijn wat je wilt. Maar het is niet wat de oorspronkelijke configuratie deed.

Gebruik het wanneer de gast echt een gelijkwaardige deelnemer op dat LAN moet zijn en de blootstelling is goedgekeurd. Gebruik het niet omdat één dienst niet meer antwoordt, want de wijziging kan de gast uit de isolatie halen die het veilig maakte om ertegen te ontwikkelen.

Test na elke goedgekeurde correctie in een vaste volgorde: een nieuw verzoek van de host naar de gast, een vereiste bedrijfsbron door de tunnel, en het bedoelde geweigerde gedrag met de tunnel uit. Als het laatste niet meer geldt, ging de correctie verder dan het probleem.

De sectie over host-only-netwerken van VirtualBox beschrijft de software-interface aan de hostkant en hoe die verschilt van een bridge-aansluiting, wat de referentie is die het lezen waard is voordat je aanneemt dat de twee modi uitwisselbaar zijn.