Varför misslyckas din gäst-VPN bakom VirtualBox NAT?

En webbläsare inuti den virtuella maskinen fungerar, och VPN-klienten på samma gäst kan inte föra data. Gästen har uppenbarligen anslutning, så felet ligger i vad VPN:ens yttre protokoll kräver och vad den virtuella NAT:en kommer att släppa igenom. Tre villkor avgör resultatet: vilken process som äger VPN:en, hur det yttre utbytet ser ut på ledningen och om adapterns läge är det du tror. Att namnge villkoret du kan ändra är hela beslutet.

Hitta VPN-processen innan du skyller på nätverket

Avgör först om VPN:en körs inne i gästen eller på värden, eftersom de två arrangemangen misslyckas olika. En klient inne i gästen bygger sin egen yttre anslutning genom gästadaptern och eventuell översättning bakom den. En värd-VPN fångar gästens trafik enligt värdens och hypervisorns policy, vilket är en separat fångstpunkt med egna regler. De kan köra samtidigt och grumla bevisen, så identifiera den som ska bära denna trafik innan du rör någon av dem.

Skriv ner gästens adapterläge nu, innan du ändrar något. Det enda värdet förklarar det mesta av det som följer, och det är det första någon frågar dig om senare.

Det yttre utbytet avgör kompatibiliteten

VirtualBox nätverksguide listar NAT-begränsningar som spelar roll här: den släpper inte igenom andra protokoll än TCP och UDP, GRE nämns som ostött och PPTP ges som ett drabbat exempel. PPTP använder ett TCP-kontrollutbyte och GRE för data, så kontrollanslutningen kan lyckas medan datavägen inte kan korsa samma gräns. Det är två olika bevis, och bara ett av dem handlar om att föra trafik. Att tillåta TCP-port 47 i en brandväggsregel är inte samma sak som att tillåta IP-protokoll 47, och de två förväxlas ständigt.

Håll begränsningen knuten till detta NAT-arrangemang och inte till varje enhet som använder ordet NAT. En fysisk router kan släppa igenom GRE utan klagomål medan den virtuella NAT:en släpper det, och en annan hypervisor gör sitt eget val om vad den vidarebefordrar. Där organisationen erbjuder en godkänd transport inom TCP eller UDP, använd dess stödda klient och profil för den vägen. Kompatibilitet är ett krav bland flera, och det etablerar varken servertillit, kontobehörighet eller fungerande privata rutter.

Vad bryggning faktiskt ändrar

En brygga ger gästens MAC-adress till det fysiska segmentet i stället för att gömma den bakom översättning. Gästen tar då en adress från vilken DHCP-server som helst som betjänar segmentet, svarar ARP för den adressen och framträder för switchen uppströms som ännu en port. Det tar bort den virtuella översättningsvägen, vilket är precis anledningen till att ett gammalt recept rekommenderar det, och det ändrar tre andra saker samtidigt. Adresseringen kommer nu från det lokala segmentet i stället för hypervisorn, exponering betyder att gästen är synlig för det segmentet, och antagning beror på switchporten och dess policy. Var och en av dem kan vara ett skäl att avvisa ändringen, och ingen av dem handlar om VPN-protokollet.

Bryggning installerar inte ett saknat plugin, levererar inte en otillgänglig hemlig agent och reparerar inte en autentiseringsavvisning. Det gör inte heller ett föråldrat protokoll till ett bra val, och där operatören har en underhållen ersättare är beslutet den och inte att byta hypervisor. Portvidarebefordran är en helt tredje roll: den publicerar en inkommande tjänst och gör ingenting för en utgående klients yttre protokoll.

Två tunnlar, två bevisspår

En gäst-VPN behöver en användbar väg från gästens gränssnitt till dess motpart innan någon inre adress eller privat rutt spelar roll. Där en värd-VPN finns kan den vidarebefordra eller blockera det yttre utbytet enligt sin egen policy, och gästens inre tunnel börjar först efter att den yttre lyckas. Ingen av lagren kan läsas av från en enda ansluten ikon eller från värdens webbläsares offentliga adress.

Behåll det första felmeddelandet i stället för det sista, eftersom det tidigaste felet namnger lagret. Ändra ett stött nätverksarrangemang i taget, med samma gästprofil och samma inloggningsuppgifter, så att jämförelsen betyder något. Avgör utifrån felet vilket steg som bröts: lokal integration, transport, autentisering eller resursåtkomst efter att tunneln är uppe. Var och en har en annan ägare, och bara en är en hypervisorfråga.

Vilket villkor som faktiskt blockerar dig

Nu snävas beslutet in till tre frågor med olika svar. Om det yttre protokollet ligger utanför TCP och UDP är NAT-läget begränsningen, och vägen framåt är brygga eller en godkänd TCP/UDP-transport. Om det yttre utbytet slutförs och datavägen inte, är begränsningen densamma som i det andra beviset. Om tunneln kommer upp och resurser inte svarar har problemet redan passerat hypervisorn till routing eller policy.

Skriv ner svaret med adapterläget bredvid, annars upprepar nästa person samma eftermiddag. Testa den faktiska applikationen och namnuppslagningen inne i gästen efter varje korrigering, anslut sedan igen och prova felpolicyn. En fungerande webbsida genom tunneln bevisar bara att webbvägen fungerar, vilket är ett mindre påstående än det känns i stunden.