Waarom mislukt je gast-VPN achter VirtualBox NAT?

Een browser in de virtuele machine werkt, en de VPN-client op dezelfde gast kan geen gegevens transporteren. De gast heeft duidelijk connectiviteit, dus de fout zit in wat het buitenste protocol van de VPN nodig heeft en wat de virtuele NAT doorlaat. Drie voorwaarden bepalen de uitkomst: welk proces de VPN bezit, hoe de buitenste uitwisseling op de lijn eruitziet en of de adaptermodus degene is die je denkt. De voorwaarde benoemen die je kunt wijzigen is de hele beslissing.

Lokaliseer het VPN-proces voordat je het netwerk de schuld geeft

Bepaal eerst of de VPN in de gast of op de host draait, want de twee opstellingen falen verschillend. Een client in de gast bouwt zijn eigen buitenste verbinding via de gastadapter en welke vertaling daarachter ook zit. Een host-VPN onderschept het verkeer van de gast volgens het beleid van de host en de hypervisor, wat een apart onderscheppingspunt met eigen regels is. Ze kunnen tegelijk draaien en het bewijs vertroebelen, dus bepaal welke dit verkeer hoort te dragen voordat je een van beide aanraakt.

Noteer nu de adaptermodus van de gast, voordat je iets wijzigt. Die ene waarde verklaart het meeste van wat volgt, en het is het eerste wat iemand je later zal vragen.

De buitenste uitwisseling bepaalt de compatibiliteit

De netwerkgids van VirtualBox noemt NAT-beperkingen die hier van belang zijn: hij laat geen andere protocollen dan TCP en UDP door, GRE wordt als niet-ondersteund genoemd en PPTP wordt als getroffen voorbeeld gegeven. PPTP gebruikt een TCP-controle-uitwisseling en GRE voor de gegevens, dus de controleverbinding kan slagen terwijl het gegevenspad dezelfde grens niet kan oversteken. Dat zijn twee verschillende bewijzen, en slechts één ervan gaat over het dragen van verkeer. TCP-poort 47 toestaan in een firewallregel is niet hetzelfde als IP-protocol 47 toestaan, en de twee worden voortdurend verward.

Houd de beperking gekoppeld aan deze NAT-opstelling en niet aan elk apparaat dat het woord NAT gebruikt. Een fysieke router kan GRE zonder klagen doorlaten terwijl de virtuele NAT het laat vallen, en een andere hypervisor maakt zijn eigen keuze over wat hij doorstuurt. Waar de organisatie een goedgekeurd transport binnen TCP of UDP biedt, gebruik dan de ondersteunde client en het profiel daarvoor. Compatibiliteit is één vereiste van meerdere, en zij legt noch serververtrouwen, noch accounttoestemming, noch werkende privéroutes vast.

Wat bridging werkelijk verandert

Een bridge geeft het MAC-adres van de gast aan het fysieke segment in plaats van het achter vertaling te verbergen. De gast neemt dan een adres van welke DHCP-server dat segment ook bedient, antwoordt ARP voor dat adres en verschijnt voor de upstream-switch als nog een poort. Dat verwijdert het virtuele vertalingspad, wat precies de reden is dat een oud recept het aanraadt, en het verandert tegelijk drie andere dingen. Adressering komt nu van het lokale segment in plaats van de hypervisor, blootstelling betekent dat de gast zichtbaar is voor dat segment, en toelating hangt af van de switchpoort en zijn beleid. Elk daarvan kan een reden zijn om de wijziging te weigeren, en geen ervan gaat over het VPN-protocol.

Bridging installeert geen ontbrekende plug-in, levert geen niet-beschikbare geheime agent en repareert geen authenticatie-weigering. Het maakt ook geen verouderd protocol tot een goede keuze, en waar de beheerder een onderhouden vervanging heeft, is dat de beslissing en niet het wijzigen van de hypervisor. Port forwarding is een volledig derde rol: het publiceert een inkomende dienst en doet niets voor het buitenste protocol van een uitgaande client.

Twee tunnels, twee bewijssporen

Een gast-VPN heeft een bruikbaar pad van de gastinterface naar zijn peer nodig voordat een intern adres of privéroute ertoe doet. Waar een host-VPN aanwezig is, kan die de buitenste uitwisseling volgens zijn eigen beleid doorgeven of blokkeren, en de interne tunnel van de gast begint pas nadat de buitenste slaagt. De dekking van geen enkele laag is af te lezen aan één verbonden pictogram of aan het openbare adres van de hostbrowser.

Bewaar het eerste foutbericht in plaats van het laatste, omdat de vroegste fout de laag benoemt. Wijzig één ondersteunde netwerkopstelling tegelijk, met hetzelfde gastprofiel en dezelfde inloggegevens, zodat de vergelijking iets betekent. Beslis op basis van de fout welke fase brak: lokale integratie, transport, authenticatie of toegang tot bronnen nadat de tunnel omhoog is. Elk daarvan heeft een andere eigenaar, en slechts één is een hypervisorvraag.

Welke voorwaarde je werkelijk blokkeert

Inmiddels vernauwt de beslissing zich tot drie vragen met verschillende antwoorden. Als het buitenste protocol buiten TCP en UDP valt, is de NAT-modus de beperking, en bridging of een goedgekeurd TCP/UDP-transport is de weg vooruit. Als de buitenste uitwisseling voltooit en het gegevenspad niet, is de beperking dezelfde als bij het tweede bewijs. Als de tunnel omhoog komt en bronnen niet antwoorden, heeft het probleem de hypervisor al voorbijgestoken naar routering of beleid.

Schrijf het antwoord op met de adaptermodus ernaast, anders herhaalt de volgende persoon dezelfde middag. Test na elke correctie de echte toepassing en naamresolutie in de gast, en verbind dan opnieuw en beproef het foutbeleid. Een werkende webpagina door de tunnel bewijst alleen dat het webpad werkt, wat een kleinere bewering is dan het op dat moment voelt.