Kvifor feilar gjeste-VPN-en din bak VirtualBox NAT?

Ein nettlesar inne i den virtuelle maskina verkar, og VPN-klienten på same gjest kan ikkje føre data. Gjesten har tydeleg tilkopling, så feilen ligg i kva VPN-ens ytre protokoll krev og kva den virtuelle NAT-en slepp gjennom. Tre vilkår avgjer resultatet: kva prosess som eig VPN-en, korleis den ytre utvekslinga ser ut på leidninga, og om adaptermodusen er den du trur. Å namngje vilkåret du kan endre er heile avgjerda.

Finn VPN-prosessen før du klandrar nettverket

Avgjer først om VPN-en køyrer inne i gjesten eller på verten, fordi dei to ordningane feilar ulikt. Ein klient inne i gjesten byggjer si eiga ytre tilkopling gjennom gjesteadapteren og eventuell omsetjing bak den. Ein verts-VPN fangar trafikken til gjesten etter policyen til verten og hypervisoren, som er eit eige fangstpunkt med eigne reglar. Dei kan køyre samtidig og tilsløre prova, så identifiser den som skal bere denne trafikken før du rører nokon av dei.

Skriv ned adaptermodusen til gjesten no, før du endrar noko. Den eine verdien forklarar det meste av det som følgjer, og det er det første nokon spør deg om seinare.

Den ytre utvekslinga avgjer kompatibiliteten

Nettverksrettleiinga til VirtualBox listar NAT-avgrensingar som tyder noko her: ho slepp ikkje gjennom andre protokollar enn TCP og UDP, GRE er nemnd som ikkje støtta, og PPTP er gjeven som eit råka døme. PPTP brukar ein TCP-kontrollutveksling og GRE for dataa, så kontrolltilkoplinga kan lukkast medan datastien ikkje kan krysse same grensa. Det er to ulike prov, og berre eitt av dei handlar om å føre trafikk. Å tillate TCP-port 47 i ein brannmurregel er ikkje det same som å tillate IP-protokoll 47, og dei to blir stadig forveksla.

Hald avgrensinga knytt til denne NAT-ordninga og ikkje til kvar eining som brukar ordet NAT. Ein fysisk ruter kan sleppe GRE gjennom utan klage medan den virtuelle NAT-en droppar det, og ein annan hypervisor gjer sitt eige val om kva han videresender. Der organisasjonen tilbyr ein godkjend transport innanfor TCP eller UDP, bruk den støtta klienten og profilen hans for den vegen. Kompatibilitet er eitt krav blant fleire, og det etablerer korkje servertillit, kontoløyve eller fungerande private ruter.

Kva bru faktisk endrar

Ei bru gjev MAC-adressa til gjesten til det fysiske segmentet i staden for å skjule ho bak omsetjing. Gjesten tek då ei adresse frå den DHCP-tenaren som betener segmentet, svarar ARP for den adressa, og framstår for svitsjen oppstraums som endå ein port. Det fjernar den virtuelle omsetjingsstien, som er nettopp grunnen til at ei gammal oppskrift tilrår det, og det endrar tre andre ting samstundes. Adresseringa kjem no frå det lokale segmentet i staden for hypervisoren, eksponering tyder at gjesten er synleg for det segmentet, og opptak heng av svitsjporten og policyen hans. Kvar av dei kan vere ein grunn til å avvise endringa, og ingen av dei handlar om VPN-protokollen.

Brubygging installerer ikkje ein manglande plugin, leverer ikkje ein utilgjengeleg hemmeleg agent og reparerer ikkje ei avvising av autentisering. Det gjer heller ikkje ein utdatert protokoll til eit godt val, og der operatøren har ein vedlikehalden erstatning, er avgjerda den og ikkje å endre hypervisoren. Portvideresending er ei heilt tredje rolle: ho publiserer ein innkomande teneste og gjer ingenting for den ytre protokollen til ein utgåande klient.

To tunnelar, to bevisspor

Ein gjeste-VPN treng ein brukande sti frå grensesnittet til gjesten til partnaren før noka indre adresse eller privat rute tyder noko. Der ein verts-VPN er til stades, kan han videresende eller blokkere den ytre utvekslinga etter sin eigen policy, og den indre tunnelen til gjesten byrjar først etter at den ytre lukkast. Ingen av laga kan lesast av eit einskilt tilkopla ikon eller av den offentlege adressa til nettlesaren på verten.

Hald på den første feilmeldinga i staden for den siste, fordi den tidlegaste feilen namngjev laget. Endre éi støtta nettverksordning om gongen, med same gjesteprofil og same påloggingsinformasjon, slik at samanlikninga tyder noko. Avgjer ut frå feilen kva trinn som braut: lokal integrering, transport, autentisering eller ressurstilgang etter at tunnelen er oppe. Kvart av dei har ein annan eigar, og berre eitt er eit hypervisorspørsmål.

Kva vilkår som faktisk blokkerer deg

No snevrar avgjerda seg inn til tre spørsmål med ulike svar. Viss den ytre protokollen ligg utanfor TCP og UDP, er NAT-modusen avgrensinga, og vegen vidare er bru eller ein godkjend TCP/UDP-transport. Viss den ytre utvekslinga fullførast og datastien ikkje, er avgrensinga den same som i det andre provet. Viss tunnelen kjem opp og ressursar ikkje svarar, har problemet alt flytta seg forbi hypervisoren til ruting eller policy.

Skriv ned svaret med adaptermodusen ved sida av, elles gjer neste person den same ettermiddagen om att. Test den faktiske applikasjonen og namneoppslag inne i gjesten etter kvar retting, og kople deretter til på nytt og prøv feilpolicyen. Ei fungerande nettside gjennom tunnelen beviser berre at webstien verkar, noko som er ein mindre påstand enn det kjennest i augneblinken.