Miért nem működik a vendég VPN a VirtualBox NAT mögött?

A virtuális gépen belüli böngésző működik, és az ugyanazon a vendégen futó VPN-kliens nem tud adatot továbbítani. A vendégnek nyilvánvalóan van kapcsolata, tehát a hiba abban van, amire a VPN külső protokolljának szüksége van, és abban, amit a virtuális NAT átenged. Három feltétel dönti el az eredményt: melyik folyamat birtokolja a VPN-t, hogyan néz ki a külső csere a vezetéken, és hogy az adapter módja-e az, amire gondol. A megváltoztatható feltétel megnevezése maga a döntés.

Azonosítsa a VPN-folyamatot, mielőtt a hálózatot okolná

Először döntse el, hogy a VPN a vendégen belül vagy a gazdagépen fut, mert a két elrendezés másképp hibázik. A vendégen belüli kliens a saját külső kapcsolatát a vendég adapterén és a mögötte lévő bármilyen fordítás keresztül építi fel. A gazdagép VPN-je a vendég forgalmát a gazdagép és a hypervisor szabályzata szerint fogja el, ami külön elfogási pont saját szabályokkal. Egyszerre is futhatnak, és összezavarhatják a bizonyítékokat, ezért azonosítsa azt, amelyiknek ezt a forgalmat vinnie kell, mielőtt bármelyikhez hozzányúl.

Jegyezze fel most a vendég adapterének módját, mielőtt bármit megváltoztat. Ez az egyetlen érték megmagyarázza a következők nagy részét, és ez az első dolog, amit később bárki kérdezni fog.

A külső csere dönt a kompatibilitásról

A VirtualBox hálózati útmutatója felsorolja az itt számító NAT-korlátozásokat: nem enged át TCP-n és UDP-n kívül más protokollt, a GRE nem támogatottként szerepel, és a PPTP érintett példaként jelenik meg. A PPTP TCP-vezérlécserét és GRE-t használ az adatokhoz, így a vezérlőkapcsolat sikerülhet, miközben az adatútvonal nem tudja átlépni ugyanazt a határt. Ez két különböző bizonyíték, és csak az egyik szól a forgalom továbbításáról. A TCP 47-es port engedélyezése egy tűzfal-szabályban nem ugyanaz, mint az IP 47-es protokoll engedélyezése, és a kettőt folyamatosan összekeverik.

Tartsa a korlátozást ehhez a NAT-elrendezéshez kötve, ne minden eszközhöz, amely a NAT szót használja. Egy fizikai router panasz nélkül átengedheti a GRE-t, miközben a virtuális NAT eldobja, és egy másik hypervisor saját döntést hoz arról, mit továbbít. Ahol a szervezet TCP-n vagy UDP-n belül jóváhagyott átvitelt kínál, használja annak támogatott kliensét és profilját ahhoz az útvonalhoz. A kompatibilitás egy követelmény a sok közül, és nem alapoz meg sem szerverbizalmat, sem fiókengedélyt, sem működő privát útvonalakat.

Mit változtat valójában a hidazás

A híd átadja a vendég MAC-címét a fizikai szegmensnek ahelyett, hogy fordítás mögé rejtené. A vendég ezután címet kap attól a DHCP-kiszolgálótól, amely ezt a szegmenst kiszolgálja, ARP-választ ad erre a címre, és a felső kapcsoló számára még egy portként jelenik meg. Ez eltávolítja a virtuális fordítási útvonalat, ami pontosan az oka annak, hogy egy régi recept ezt ajánlja, és ugyanabban a pillanatban három másik dolgot is megváltoztat. A címzés most a helyi szegmensből jön a hypervisor helyett, a kitettség azt jelenti, hogy a vendég látható annak a szegmensnek, a belépés pedig a kapcsoló portjától és annak szabályzatától függ. Ezek mindegyike ok lehet a változtatás elutasítására, és egyik sem szól a VPN-protokollról.

A hidazás nem telepít hiányzó bővítményt, nem biztosít elérhetetlen titkos ügynököt, és nem javítja a hitelesítés elutasítását. Nem tesz elavult protokollt jó választássá sem, és ahol az üzemeltetőnek karbantartott helyettesítője van, a döntés az, nem a hypervisor cseréje. A porttovábbítás teljesen harmadik szerep: közzétesz egy bejövő szolgáltatást, és semmit nem tesz egy kimenő kliens külső protokolljáért.

Két alagút, két bizonyítéknyom

A vendég VPN-nek használható útvonalra van szüksége a vendég interfészétől a partneréig, mielőtt bármely belső cím vagy privát útvonal számítana. Ahol gazdagép VPN van jelen, az saját szabályzata szerint továbbíthatja vagy blokkolhatja ezt a külső cserét, és a vendég belső alagútja csak a külső sikeressége után kezdődik. Egyik réteg lefedettsége sem olvasható le egyetlen csatlakoztatott ikonról vagy a gazdagép böngészőjének nyilvános címéről.

Az első hibaüzenetet tartsa meg, ne az utolsót, mert a legkorábbi hiba nevezi meg a réteget. Egyszerre egy támogatott hálózati elrendezést változtasson, ugyanazzal a vendégprofillal és ugyanazokkal a hitelesítő adatokkal, hogy az összehasonlítás jelentsen valamit. A hiba alapján döntse el, melyik szakasz tört el: helyi integráció, átvitel, hitelesítés vagy erőforrás-hozzáférés az alagút felállása után. Mindegyiknek más a tulajdonosa, és csak az egyik hypervisor-kérdés.

Melyik feltétel blokkolja valójában

Mostanra a döntés három különböző válaszú kérdésre szűkül. Ha a külső protokoll a TCP-n és UDP-n kívül esik, a NAT módja a korlát, és előre a hidazás vagy egy jóváhagyott TCP/UDP-átvitel visz. Ha a külső csere befejeződik, az adatútvonal pedig nem, a korlát ugyanaz, mint a második bizonyítéknál. Ha az alagút feláll, de az erőforrások nem válaszolnak, a probléma már túljutott a hypervisoron az útválasztásba vagy a szabályzatba.

Írja le a választ az adapter módjával együtt, különben a következő ember ugyanazt a délutánt ismétli meg. Minden javítás után tesztelje a tényleges alkalmazást és a névfeloldást a vendégen belül, majd csatlakozzon újra, és próbálja ki a hiba szabályzatát. Az alagúton át működő weboldal csak azt bizonyítja, hogy a webútvonal működik, ami kisebb állítás, mint amilyennek abban a pillanatban tűnik.