Miks teie külalis-VPN ei tööta VirtualBoxi NAT-i taga?

Brauser virtuaalmasinas töötab, ja sama külalise VPN-klient ei suuda andmeid kanda. Külalisel on ilmselt ühenduvus, seega viga on selles, mida VPN-i väline protokoll vajab ja mida virtuaalne NAT läbi laseb. Tulemuse otsustavad kolm tingimust: milline protsess VPN-i omab, kuidas väline vahetus juhtmel välja näeb ja kas adapteri režiim on see, mida arvate. Tingimuse nimetamine, mida saate muuta, on kogu otsus.

Leidke VPN-i protsess enne, kui süüdistate võrku

Otsustage esmalt, kas VPN töötab külalise sees või hostis, sest need kaks korraldust ebaõnnestuvad erinevalt. Külalise sees olev klient ehitab oma välise ühenduse külalise adapteri ja selle taga oleva tõlke kaudu. Host-VPN püüab külalise liiklust hosti ja hüpervisori poliitika järgi, mis on omaette püüdmispunkt oma reeglitega. Need võivad töötada korraga ja tõendeid segada, seega tehke kindlaks, milline peaks seda liiklust kandma, enne kui kumbagi puudutate.

Kirjutage külalise adapteri režiim kohe üles, enne kui midagi muudate. See üks väärtus selgitab suuremat osa järgnevast ja on esimene asi, mida keegi teilt hiljem küsib.

Väline vahetus otsustab ühilduvuse

VirtualBoxi võrgujuhend loetleb siin olulisi NAT-i piiranguid: see ei lase läbi muid protokolle peale TCP ja UDP, GRE on nimetatud toetamata ja PPTP on toodud mõjutatud näitena. PPTP kasutab TCP juhtimisvahetust ja GRE-d andmete jaoks, nii et juhtimisühendus võib õnnestuda, samas kui andmetee ei saa sama piiri ületada. Need on kaks erinevat tõendit ja ainult üks neist puudutab liikluse kandmist. TCP porti 47 lubamine tulemüürireeglis ei ole sama, mis IP-protokolli 47 lubamine, ja neid aetakse pidevalt segamini.

Hoidke piirang seotud selle NAT-korraldusega, mitte iga seadmega, mis kasutab sõna NAT. Füüsiline ruuter võib GRE-d kaebusteta läbi lasta, samal ajal kui virtuaalne NAT selle maha viskab, ja teine hüpervisor teeb oma valiku, mida edasi saata. Kui organisatsioon pakub heakskiidetud transporti TCP või UDP sees, kasutage selle toetatud klienti ja profiili selle tee jaoks. Ühilduvus on üks mitmest nõudest ja see ei taga ei serveri usaldust ega konto luba ega toimivaid privaatseid marsruute.

Mida sillastamine tegelikult muudab

Sild annab külalise MAC-aadressi füüsilisele segmendile, selle asemel et seda tõlke taha peita. Seejärel võtab külaline aadressi ükskõik milliselt DHCP-serverilt, mis seda segmenti teenindab, vastab selle aadressi ARP-le ja ilmub ülesvoolu kommutaatorile veel ühe pordina. See eemaldab virtuaalse tõlketee, mis on täpselt põhjus, miks vana retsept seda soovitab, ja muudab samal hetkel veel kolme asja. Adresseerimine tuleb nüüd kohalikust segmendist, mitte hüpervisorist, paljastatus tähendab, et külaline on sellele segmendile nähtav, ja lubamine sõltub kommutaatori pordist ja selle poliitikast. Igaüks neist võib olla põhjus muudatuse tagasilükkamiseks ja ükski neist ei puuduta VPN-protokolli.

Sillastamine ei paigalda puuduvat pistikprogrammi, ei tarni kättesaamatut salajast agenti ega paranda autentimise tagasilükkamist. See ei tee ka vananenud protokolli heaks valikuks, ja kus operaatoril on hooldatav asendus, on otsus just see, mitte hüpervisori muutmine. Pordi edasisaatmine on täiesti kolmas roll: see avaldab sissetuleva teenuse ega tee väljuva kliendi välise protokolli jaoks midagi.

Kaks tunnelit, kaks tõendijälge

Külalis-VPN vajab kasutatavat teed külalise liidesest oma partnerini, enne kui mis tahes sisemine aadress või privaatne marsruut loeb. Kui host-VPN on olemas, võib see seda välist vahetust oma poliitika järgi edasi saata või blokeerida, ja külalise sisemine tunnel algab alles pärast välise õnnestumist. Ühegi kihi katvust ei saa lugeda ühest ühendatud ikoonist ega hosti brauseri avalikust aadressist.

Hoidke esimene veateade, mitte viimane, sest varaseim ebaõnnestumine nimetab kihi. Muutke korraga üht toetatud võrgukorraldust, sama külalisprofiili ja samade mandaatidega, et võrdlus midagi tähendaks. Otsustage vea põhjal, milline etapp murdus: kohalik integreerimine, transport, autentimine või ressursile juurdepääs pärast tunneli püstitamist. Igaühel neist on erinev omanik ja ainult üks on hüpervisori küsimus.

Milline tingimus teid tegelikult blokeerib

Nüüd kitseneb otsus kolmele erineva vastusega küsimusele. Kui väline protokoll jääb TCP ja UDP välja, on piiranguks NAT-i režiim ning edasiviiv tee on sildamine või heakskiidetud TCP/UDP transport. Kui väline vahetus lõpeb ja andmetee mitte, on piirang sama, mida nähti teises tõendis. Kui tunnel tõuseb ja ressursid ei vasta, on probleem juba hüpervisorist mööda läinud marsruutimisse või poliitikasse.

Kirjutage vastus üles koos adapteri režiimiga, muidu kordab järgmine inimene sama pärastlõunat. Pärast iga parandust testige külalise sees tegelikku rakendust ja nimede lahendamist, seejärel ühenduge uuesti ja proovige tõrke poliitikat. Tunneli kaudu töötav veebileht tõestab ainult seda, et veebitee töötab, mis on väiksem väide, kui see sel hetkel tundub.