VM-forgalom átirányítása a host-only hálózatban TUN OpenVPN-kiszolgálón keresztül

A host-only adapterek helyi virtuális hálózatot hoznak létre, a route-olt TUN-alagutak pedig IP-csomagokat visznek a címek között. Egyik sem híd a másik felé, ezért egy működő konfigurációnak meg kell mondania, ki továbbít és kié a visszaútvonal. Ha ezt a két hozzárendelést eltéveszti, a vendég olyan forrással válaszol az alagútnak, amelyet az alagút kliens soha nem kért. Az alábbi terv külön tartja a két előtagot, és egyértelművé teszi a visszaútvonalat.

Két hálózat, két előtag

Adjon különböző előtagot az alagút pooljának és a host-only hálózatnak, és soha ne használja az egyiket a másik helyett. Ebben a példában a VPN pool 10.44.0.0/24, a host-only hálózat 192.168.99.0/24, a gazdagép 192.168.99.1, egy vendég pedig 192.168.99.20 címen. Ugyanazt az előtagot a TUN-eszköznek és a host-only adapternek is kiosztani nem köti össze őket. Két igényt teremt egy címtartományra, és az útvonaltábla aztán azt az igényt válaszolja meg, amelyik véletlenül megmaradt.

A host-only adapter a gazdagépen és a vendégen belül is létezik, és önmagában nincs útja ki a gépről. A hidalt és NAT-os csatlakozások kitettsége eltér, és a hidalt módra váltás nem feltétele egyetlen vendégszolgáltatás elérésének.

A gazdagép már tartja az utat

Nézze meg, mi létezik, mielőtt bármit hozzáadna. A gazdagépnek van egy interfésze a host-only hálózaton és egy útvonala ehhez az előtaghoz, mindkettő az adapter felállásakor jött létre.

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

A harmadik sor az a mechanizmus, amely ugrásponttá teszi a gazdagépet. Nélküle az alagútból érkező csomag olyan hálózatra címződik, amelyet a gazdagép elér, de nem fog továbbítani. A továbbítás szükséges és nem elégséges. A szűrőszabályzat továbbra is eldönti, hogy az alagút interfésze és a host-only interfész közötti adott folyam engedélyezett-e, és erről a döntésről írásban kell rendelkezni, nem egy olyan alapértelmezett szabályzatban, amelyet senki nem olvasott el.

Tolja ki az útvonalat, majd szűrje, mit ér el

A kiszolgáló átadhatja a host-only előtagot azoknak a klienseknek, amelyek elfogadják a kitolt útvonalakat, ami ugyanaz a mechanizmus, mint bármely más, az alagút mögötti alhálózat esetében.

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Ez a két szabály egy szolgáltatást engedélyez egy irányban és annak válaszait. A teljes előtagot elérő útvonal és az egy portot engedélyező szűrő szándékos kombináció; az útvonal plusz feltétel nélküli elfogadás az az út, amelyen egy laboratóriumi szolgáltatásból kitett szolgáltatás lesz. A kitolt útvonal sem felhatalmazás. A kliens elfogadja, a gazdagép továbbítja, és a vendég tűzfala meg maga a szolgáltatás továbbra is szót kér.

A vendégnek visszaút kell

A 10.44.0.x címről elért vendégnek a válaszait a gazdagép host-only címére kell küldenie, vagy a gazdagépnek fordítania kell a forrást. Az, hogy a vendég címet kap a VirtualBox DHCP-től, semmit nem mond egyik megoldásról sem.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

Ennek az útvonalnak a vendégen belüli hozzáadása megőrzi az eredeti forrást, ami értelmessé teszi az ügyfelenkénti szabályzatot és naplókat. A gazdagépen végzett korlátozott forrásfordítás az alternatíva, és működik, annak árán, hogy elrejti, melyik kliens kapcsolódott. Az átfedés a másik hibaüzemmód. Egy távoli kliens, amelynek otthoni LAN-ja már a 192.168.99.0/24 címet használja, a kitolt útvonalat a saját hálózataként fogja olvasni, és semmilyen kiszolgálóoldali változtatás nem oldja meg ezt a kétértelműséget. Számozza újra az egyik oldalt, vagy válasszon olyan előtagot, amely valószínűleg nem ütközik.

A TUN-eszköz IP-csomagokat szállít, ezért az alapértelmezett átjáró hozzáadása a vendégen belül nem teszi az alagutat Ethernet-szegmenssé a host-only adapterrel. A TAP-híd más terv, saját kliens-támogatással és címbirtoklással, és a két leírás keverése olyan konfigurációkhoz vezet, amelyek soha nem konvergálnak.

Ellenőrizze, majd tegye újraindítást túlélővé

Teszteljen egy ártalmatlan szolgáltatást egy hétköznapi távoli kliensről, ellenőrizze a vendég visszaútvonalát, és erősítse meg, hogy egy nem engedélyezett szolgáltatás elutasításra kerül, nem pedig lassú.

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

Ezután indítsa újra a VPN-szolgáltatást és a virtuális gép hálózatát, és ismételje meg ugyanazt a három ellenőrzést. A kézzel hozzáadott útvonal a következő újraindításig él, és az a konfiguráció, amely csak meleg munkamenetben működik, nem terv. Jegyezze fel együtt a két előtagot, a továbbítási szabályzatot és a vendég útvonalát. Aki a következő virtuális gépet hozzáadja, mindháromra szüksége lesz, különben minden sikertelen kapcsolatnál újra felfedezi őket.