Hvorfor fejler din gæste-VPN bag VirtualBox NAT?

En browser inde i den virtuelle maskine virker, og VPN-klienten på samme gæst kan ikke føre data. Gæsten har tydeligvis forbindelse, så fejlen ligger i, hvad VPN'ens ydre protokol kræver, og hvad den virtuelle NAT vil lukke igennem. Tre betingelser afgør udfaldet: hvilken proces der ejer VPN'en, hvordan den ydre udveksling ser ud på ledningen, og om adaptertilstanden er den, du tror. At navngive den betingelse, du kan ændre, er hele beslutningen.

Find VPN-processen, før du bebrejder netværket

Afgør først, om VPN'en kører inde i gæsten eller på værten, fordi de to ordninger fejler forskelligt. En klient inde i gæsten bygger sin egen ydre forbindelse gennem gæsteadapteren og den oversættelse, der ligger bag den. En vært-VPN fanger gæstens trafik efter værtens og hypervisor'ens politik, hvilket er et separat fangstpunkt med sine egne regler. De kan køre samtidig og sløre beviserne, så identificer den, der skal bære denne trafik, før du rører nogen af dem.

Skriv gæstens adaptertilstand ned nu, før du ændrer noget. Den ene værdi forklarer det meste af det følgende, og det er det første, nogen senere vil spørge dig om.

Den ydre udveksling afgør kompatibiliteten

VirtualBox' netværksvejledning opremser NAT-begrænsninger, der er relevante her: den lukker ikke andre protokoller end TCP og UDP igennem, GRE nævnes som ikke-understøttet, og PPTP gives som et berørt eksempel. PPTP bruger en TCP-kontroludveksling og GRE til dataene, så kontrolforbindelsen kan lykkes, mens datastien ikke kan krydse samme grænse. Det er to forskellige beviser, og kun det ene handler om at føre trafik. At tillade TCP-port 47 i en firewallregel er ikke det samme som at tillade IP-protokol 47, og de to forveksles konstant.

Hold begrænsningen knyttet til denne NAT-ordning frem for til enhver enhed, der bruger ordet NAT. En fysisk router kan føre GRE igennem uden klage, mens den virtuelle NAT dropper det, og en anden hypervisor træffer sit eget valg om, hvad den videresender. Hvor organisationen tilbyder en godkendt transport inden for TCP eller UDP, brug dens understøttede klient og profil til den vej. Kompatibilitet er ét krav blandt flere, og det etablerer hverken servertillid, kontotilladelse eller fungerende private ruter.

Hvad broing faktisk ændrer

En bro giver gæstens MAC-adresse til det fysiske segment i stedet for at skjule den bag oversættelse. Gæsten tager derefter en adresse fra den DHCP-server, der betjener segmentet, svarer ARP for den adresse og fremstår over for den opstrøms switch som endnu en port. Det fjerner den virtuelle oversættelsessti, hvilket er præcis grunden til, at en gammel opskrift anbefaler det, og det ændrer tre andre ting på samme tid. Adressering kommer nu fra det lokale segment i stedet for hypervisor'en, eksponering betyder, at gæsten er synlig for det segment, og adgang afhænger af switchporten og dens politik. Hver af dem kan være en grund til at afvise ændringen, og ingen af dem handler om VPN-protokollen.

Broing installerer ikke et manglende plugin, leverer ikke en utilgængelig hemmelig agent og reparerer ikke en afvisning af godkendelse. Det gør heller ikke en forældet protokol til et godt valg, og hvor operatøren har en vedligeholdt erstatning, er beslutningen den og ikke at ændre hypervisor'en. Portvideresendelse er en helt tredje rolle: den offentliggør en indgående tjeneste og gør intet for en udgående klients ydre protokol.

To tunneller, to bevisspor

En gæste-VPN har brug for en brugbar sti fra gæstens interface til dens peer, før nogen indre adresse eller privat rute betyder noget. Hvor en vært-VPN er til stede, kan den videresende eller blokere den ydre udveksling efter sin egen politik, og gæstens indre tunnel begynder først, når den ydre lykkes. Ingen af lagene kan aflæses af et enkelt tilsluttet ikon eller af værtens browseres offentlige adresse.

Behold den første fejlmeddelelse frem for den sidste, fordi den tidligste fejl navngiver laget. Skift én understøttet netværksordning ad gangen, med samme gæsteprofil og samme legitimationsoplysninger, så sammenligningen betyder noget. Afgør ud fra fejlen, hvilket trin der brød: lokal integration, transport, godkendelse eller ressourceadgang efter tunnelen er oppe. Hver af dem har en anden ejer, og kun én er et hypervisorspørgsmål.

Hvilken betingelse blokerer dig egentlig

Nu indsnævres beslutningen til tre spørgsmål med forskellige svar. Hvis den ydre protokol ligger uden for TCP og UDP, er NAT-tilstanden begrænsningen, og bro eller en godkendt TCP/UDP-transport er vejen frem. Hvis den ydre udveksling fuldføres, og datastien ikke gør, er begrænsningen den samme som i det andet bevis. Hvis tunnelen kommer op, og ressourcer ikke svarer, har problemet allerede bevæget sig forbi hypervisor'en til routing eller politik.

Skriv svaret ned med adaptertilstanden ved siden af, ellers gentager den næste person den samme eftermiddag. Test den faktiske applikation og navneopløsning inde i gæsten efter enhver rettelse, og genopret derefter forbindelsen og afprøv fejlpolitikken. En fungerende webside gennem tunnelen beviser kun, at webstien virker, hvilket er en mindre påstand, end det føles i øjeblikket.