Proč váš hostující VPN nefunguje za NAT VirtualBoxu?

Prohlížeč uvnitř virtuálního stroje funguje, ale klient VPN na stejném hostu nemůže přenášet data. Host má zjevně konektivitu, takže porucha je v tom, co vnější protokol VPN potřebuje a co virtuální NAT propustí. Výsledek určují tři podmínky: který proces VPN vlastní, jak výměna vypadá na drátě a zda režim adaptéru je ten, který si myslíte. Pojmenovat podmínku, kterou můžete změnit, je celé rozhodnutí.

Najděte proces VPN, než obviníte síť

Nejprve rozhodněte, zda VPN běží uvnitř hosta, nebo na hostiteli, protože obě uspořádání selhávají různě. Klient uvnitř hosta staví vlastní vnější spojení přes adaptér hosta a jakýkoli překlad za ním. VPN na hostiteli zachycuje provoz hosta podle zásad hostitele a hypervizoru, což je samostatný bod zachycení s vlastními pravidly. Mohou běžet současně a mást důkazy, proto určete tu, která má tento provoz přenášet, než se dotknete kterékoli.

Zapište si nyní režim adaptéru hosta, než cokoli změníte. Tato jediná hodnota vysvětluje většinu toho, co následuje, a je to první věc, na kterou se vás později každý zeptá.

Vnější výměna rozhoduje o kompatibilitě

Průvodce sítěmi VirtualBox uvádí omezení NAT, která zde mají význam: nepustí protokoly jiné než TCP a UDP, GRE je uveden jako nepodporovaný a PPTP je dán jako postižený příklad. PPTP používá řídicí výměnu TCP a GRE pro data, takže řídicí spojení může uspět, zatímco datová cesta nemůže překročit stejnou hranici. To jsou dva různé důkazy a jen jeden z nich se týká přenosu provozu. Povolit TCP port 47 v pravidle firewallu není totéž jako povolit IP protokol 47 a obojí se neustále plete.

Držte omezení u tohoto uspořádání NAT, ne u každého zařízení, které používá slovo NAT. Fyzický router může propustit GRE bez stížnosti, zatímco virtuální NAT ho zahodí, a jiný hypervizor se sám rozhodne, co předá dál. Kde organizace nabízí schválený transport v TCP nebo UDP, použijte jeho podporovaného klienta a profil pro tuto cestu. Kompatibilita je jeden z několika požadavků a nezakládá ani důvěru serveru, ani oprávnění účtu, ani funkční soukromé trasy.

Co přemostění skutečně mění

Most předává MAC adresu hosta fyzickému segmentu místo toho, aby ji skrýval za překladem. Host pak převezme adresu od kteréhokoli serveru DHCP, který tento segment obsluhuje, odpovídá ARP na tuto adresu a vůči nadřazenému přepínači se jeví jako další port. Tím zmizí cesta virtuálního překladu, což je právě důvod, proč ji starý recept doporučuje, a zároveň se změní tři další věci. Adresování nyní přichází z místního segmentu, ne z hypervizoru, vystavení znamená, že host je pro tento segment viditelný, a přijetí závisí na portu přepínače a jeho zásadách. Každé z toho může být důvodem změnu odmítnout a žádné není o protokolu VPN.

Premostění nenainstaluje chybějící plugin, neposkytne nedostupného tajného agenta ani neopraví odmítnutí autentizace. Také nedělá ze zastaralého protokolu dobrou volbu, a kde má operátor udržovanou náhradu, je rozhodnutím právě ona, ne změna hypervizoru. Přesměrování portu je zcela třetí role: zveřejňuje příchozí službu a pro vnější protokol odchozího klienta nedělá nic.

Dva tunely, dvě stopy důkazů

Hostující VPN potřebuje použitelnou cestu z rozhraní hosta k jeho protějšku, než začne záležet na jakékoli vnitřní adrese nebo soukromé trase. Kde je přítomna VPN na hostiteli, může tuto vnější výměnu předávat nebo blokovat podle vlastních zásad, a vnitřní tunel hosta začíná až po úspěchu vnějšího. Pokrytí žádné vrstvy nelze odečíst z jedné připojené ikony ani z veřejné adresy prohlížeče na hostiteli.

Zachovejte první chybovou zprávu, ne poslední, protože nejčasnější selhání pojmenovává vrstvu. Měňte jedno podporované síťové uspořádání najednou, se stejným profilem hosta a stejnými přihlašovacími údaji, aby srovnání něco znamenalo. Podle selhání rozhodněte, která fáze se zlomila: místní integrace, transport, autentizace nebo přístup k prostředkům po vztyčení tunelu. Každá má jiného vlastníka a jen jedna je otázkou hypervizoru.

Která podmínka vás ve skutečnosti blokuje

Rozhodnutí se nyní zužuje na tři otázky s různými odpověďmi. Pokud vnější protokol leží mimo TCP a UDP, omezením je režim NAT a cestou vpřed je most nebo schválený transport TCP/UDP. Pokud se vnější výměna dokončí a datová cesta ne, je omezením totéž, co je vidět ve druhém důkazu. Pokud se tunel zvedne a prostředky neodpovídají, problém už překročil hypervizor do směrování nebo zásad.

Zapište odpověď s režimem adaptéru vedle, jinak další člověk zopakuje stejné odpoledne. Po každé opravě otestujte skutečnou aplikaci a překlad jmen uvnitř hosta, potom se znovu připojte a vyzkoušejte zásady selhání. Fungující webová stránka tunelem dokazuje jen to, že webová cesta funguje, což je menší tvrzení, než se v tu chvíli zdá.