Hvorfor feiler gjeste-VPN-en din bak VirtualBox NAT?

En nettleser inne i den virtuelle maskinen virker, og VPN-klienten på samme gjest kan ikke føre data. Gjesten har tydeligvis tilkobling, så feilen ligger i hva VPN-ens ytre protokoll krever og hva den virtuelle NAT-en slipper gjennom. Tre betingelser avgjør resultatet: hvilken prosess som eier VPN-en, hvordan den ytre utvekslingen ser ut på ledningen, og om adaptermodusen er den du tror. Å navngi betingelsen du kan endre er hele beslutningen.

Finn VPN-prosessen før du klandrer nettverket

Avgjør først om VPN-en kjører inne i gjesten eller på verten, fordi de to ordningene feiler ulikt. En klient inne i gjesten bygger sin egen ytre forbindelse gjennom gjesteadapteren og eventuell oversettelse bak den. En verts-VPN fanger gjestens trafikk etter vertens og hypervisor-ens policy, som er et eget fangstpunkt med egne regler. De kan kjøre samtidig og tilsløre bevisene, så identifiser den som skal bære denne trafikken før du rører noen av dem.

Skriv ned gjestens adaptermodus nå, før du endrer noe. Den ene verdien forklarer det meste av det som følger, og det er det første noen spør deg om senere.

Den ytre utvekslingen avgjør kompatibiliteten

VirtualBox' nettverksveiledning lister NAT-begrensninger som betyr noe her: den slipper ikke gjennom andre protokoller enn TCP og UDP, GRE er nevnt som ikke støttet, og PPTP er gitt som et berørt eksempel. PPTP bruker en TCP-kontrollutveksling og GRE for dataene, så kontrollforbindelsen kan lykkes mens datastien ikke kan krysse samme grense. Det er to forskjellige bevis, og bare ett av dem handler om å føre trafikk. Å tillate TCP-port 47 i en brannmurregel er ikke det samme som å tillate IP-protokoll 47, og de to forveksles stadig.

Hold begrensningen knyttet til denne NAT-ordningen og ikke til hver enhet som bruker ordet NAT. En fysisk ruter kan slippe GRE gjennom uten klage mens den virtuelle NAT-en dropper det, og en annen hypervisor gjør sitt eget valg om hva den videresender. Der organisasjonen tilbyr en godkjent transport innenfor TCP eller UDP, bruk dens støttede klient og profil for den veien. Kompatibilitet er ett krav blant flere, og det etablerer verken servertillit, kontotillatelse eller fungerende private ruter.

Hva bro faktisk endrer

En bro gir gjestens MAC-adresse til det fysiske segmentet i stedet for å skjule den bak oversettelse. Gjesten tar deretter en adresse fra den DHCP-serveren som betjener segmentet, svarer ARP for den adressen, og fremstår for svitsjen oppstrøms som enda en port. Det fjerner den virtuelle oversettelsesstien, som er nettopp grunnen til at en gammel oppskrift anbefaler det, og det endrer tre andre ting samtidig. Adressering kommer nå fra det lokale segmentet i stedet for hypervisor-en, eksponering betyr at gjesten er synlig for det segmentet, og opptak avhenger av svitsjporten og dens policy. Hver av dem kan være en grunn til å avvise endringen, og ingen av dem handler om VPN-protokollen.

Broing installerer ikke en manglende plugin, leverer ikke en utilgjengelig hemmelig agent og reparerer ikke en avvisning av autentisering. Det gjør heller ikke en utdatert protokoll til et godt valg, og der operatøren har en vedlikeholdt erstatning, er beslutningen den og ikke å endre hypervisor-en. Portvideresending er en helt tredje rolle: den publiserer en innkommende tjeneste og gjør ingenting for en utgående klients ytre protokoll.

To tunneler, to bevisspor

En gjeste-VPN trenger en brukbar sti fra gjestens grensesnitt til partneren før noen indre adresse eller privat rute betyr noe. Der en verts-VPN er til stede, kan den videresende eller blokkere den ytre utvekslingen etter sin egen policy, og gjestens indre tunnel begynner først etter at den ytre lykkes. Ingen av lagene kan leses av et enkelt tilkoblet ikon eller av vertens nettlesers offentlige adresse.

Behold den første feilmeldingen i stedet for den siste, fordi den tidligste feilen navngir laget. Endre én støttet nettverksordning om gangen, med samme gjesteprofil og samme påloggingsinformasjon, slik at sammenligningen betyr noe. Avgjør ut fra feilen hvilket trinn som brast: lokal integrasjon, transport, autentisering eller ressurstilgang etter at tunnelen er oppe. Hver av dem har en annen eier, og bare én er et hypervisorspørsmål.

Hvilken betingelse som faktisk blokkerer deg

Nå snevres beslutningen inn til tre spørsmål med ulike svar. Hvis den ytre protokollen ligger utenfor TCP og UDP, er NAT-modusen begrensningen, og veien videre er bro eller en godkjent TCP/UDP-transport. Hvis den ytre utvekslingen fullføres og datastien ikke, er begrensningen den samme som i det andre beviset. Hvis tunnelen kommer opp og ressurser ikke svarer, har problemet allerede beveget seg forbi hypervisor-en til ruting eller policy.

Skriv ned svaret med adaptermodusen ved siden av, ellers gjentar neste person samme ettermiddag. Test den faktiske applikasjonen og navneoppslag inne i gjesten etter enhver korreksjon, og koble deretter til på nytt og prøv feilpolicyen. En fungerende nettside gjennom tunnelen beviser bare at webstien virker, noe som er en mindre påstand enn det føles i øyeblikket.