VPN bekapcsolva, a VM elérhetetlen? Az útvonal valószínűleg soha nem volt a probléma

Kapcsold be a VPN-t, és a fejlesztői VM, amely egy perccel ezelőtt még válaszolt, elhallgat. A kézenfekvő történet magától megíródik: a tunnel elvette az útvonalat, a gazdagép most a vendég forgalmát a vállalati hálózatba küldi, a megoldás pedig egy statikus útvonal hozzáadása vagy az adapter hídmódba állítása. Ez a történet néha igaz. De nem ez a szokásos ok, és az elsőként rá épülő beavatkozás általában valami mást tör el.

A host-only hálózat olyan szoftverhálózat, amely a gazdagép tulajdona és a vendégeivel megosztott, minden fizikai csatlakozástól független. Semmi a VPN-kliens saját felületén nem változtat ezen a hálózaton, ezért mielőtt hozzányúlsz, derítsd ki, melyik a négy réteg közül hibázott valójában.

Az útvonal általában továbbra is helyi

A kernelt kérdezd, ne az útválasztási tábla címlapját. Linuxon az ip route get 192.168.56.10 a pontosan használható útvonalat, interfészt és forráscímet jelenti, ami más válasz, mint az alapértelmezett útvonalat olvasni és találgatni. Ha a kimenet a host-only interfészt nevezi meg, a tunnel egyáltalán nem vesz részt ezen az útvonalon.

Két dolog valóban elronthatja, és mindkettő címprobléma, nem VPN-probléma. A host-only előtagot átfedő távoli alhálózat nyerővé teszi a pontosabb útvonalat, és a széles útvonalat alacsonyabb metrikával telepítő VPN-kliens elhúzhatja az előtagot. Mindkettő ugyanabban a parancsban látható: a kimenetben megnevezett interfész lesz a tunnel, és a javítás annak a dolga, akié a címterv.

Az útvonalválasztás és a csomagengedélyezés két külön döntés

Ez az a rész, amelyet a mentális modell általában kihagy. Tökéletes helyi útvonal mellett is visszautasíthatja a csomagot a VPN-kliens. Sok kliens helyi hálózati hozzáférési szabályzatot érvényesít, amely eldönti, mely célok engedélyezettek a tunnelen kívül, és egy csatlakoztatott alhálózat nem frissíti automatikusan ezt a listát.

Ezért a hiba az alkalmazás felől nézve pontosan útválasztási problémának látszik, a kliens felől viszont egészen másnak. Ha az ip route get a helyes interfészt nevezi meg, és a kapcsolat mégis lejár, hagyd abba az útvonalak szerkesztését, és olvasd el inkább a kliens dokumentált helyi hozzáférési viselkedését. Egyes kliensek engedélylistát kínálnak a helyi alhálózatokhoz, mások mindent blokkolnak, ami nem a tunnel, és megint mások csak akkor, ha be van kapcsolva egy kill switch.

Ez a megkülönböztetés számít, mert a javítások nem cserélhetők fel. Egy útvonal hozzáadása nem elégít ki egy szűrőt, és egy szűrő kikapcsolása egyetlen vendég eléréséhez sokkal nagyobb döntés, mint amit a tünet sugall.

A vendégnek három módja van nemet mondani

Egy vendég, amely tud internetezni, semmit nem bizonyít a kívánt szolgáltatásról. A figyelő lehet a vendégen belül a 127.0.0.1-hez kötve, és akkor a gazdagéptől semmilyen kérés nem érkezhet meg, bármilyen jó az útvonal. Ellenőrizd a vendégen a ss -ltn paranccsal, és nézd meg a helyi cím oszlopát, ne csak a portot.

Következik a vendég saját tűzfala. Egy szigorú alapértelmezésű fejlesztői lemezkép elfogadhatja a gazdagép csomagjait, és a szolgáltatás határán eldobhatja őket, ami olyan időtúllépést okoz, amely pontosan útválasztási fekete lyuknak tűnik. Végül ott van maga a szolgáltatás konfigurációja: egy adott gazdagépnévhez kötött webalkalmazás vagy az engedélyezett klienscímek listája elutasítja a host-only alhálózatból érkező kérést akkor is, ha minden csomag megérkezik.

Ezt a hármat járd végig, mielőtt felmerül a VM hálózati módjának megváltoztatása. Mindegyik kisebb változtatás, mint a vendég csatlakozásának újragondolása, és mindegyiknek világos tesztje van.

Mi is valójában a híd, és mibe kerül

Az adapter hídmódba állítása nem a host-only útvonal javítása. Ez annak a döntése, hogy a vendéget más hálózatra, általában a fizikai LAN-ra tesszük, ahol láthatóvá válik minden más számára, ami ott él. Lehet, hogy pontosan ezt akarod. De nem ezt tette az eredeti konfiguráció.

Akkor használd, ha a vendégnek valóban egyenrangú félnek kell lennie azon a LAN-on, és a kitettség jóváhagyott. Ne azért használd, mert egyetlen szolgáltatás abbahagyta a válaszadást, mivel a változtatás kihozhatja a vendéget abból az elszigeteltségből, amely biztonságossá tette a fejlesztést ellene.

Minden jóváhagyott javítás után rögzített sorrendben tesztelj: új kérés a gazdagéptől a vendéghez, szükséges vállalati erőforrás a tunnelen keresztül, és a szándékolt elutasított viselkedés lekapcsolt tunnellel. Ha az utóbbi már nem áll, a javítás túlment a problémán.

A VirtualBox host-only hálózatról szóló szakasza a gazdagép oldali szoftverfelületet és a híd-csatlakozástól való eltérését írja le, ez az a hivatkozás, amelyet érdemes elolvasni, mielőtt feltételeznéd, hogy a két mód felcserélhető.