NAT vagy áthidalt VM-hálózat: melyik viszi a VPN-forgalmat?

A NAT-vendégek csak akkor használják a gazdagép alagútját, ha a kliens útvonal szerint alagutazik; az áthidalt vendégek maguk útvonalaznak. Teszteld a vendéget, majd válaszd a megfelelő módot.

Az áthidalás és a NAT nem ugyanannak a vendégnek a VPN-hez csatolására szolgáló két mód; arról döntenek, kié a vendég csomagja, mielőtt egyáltalán alagút kerülne a képbe. NAT módban a hypervisor átírja a vendég forgalmát, és gazdagép oldali kódból küldi ki, így a vendég azt az útvonalat használja, amelyet a gazdagép annak a kódnak ad. Áthidalt módban a vendég saját linkréteg-identitást kap a fizikai szegmensen, és saját alapértelmezett átjárót választ, ami a gazdagép alagútját irrelevánssá teszi számára, kivéve, ha a LAN-router az, amelyik alagutazik. Abbahagytam, hogy a VM-et a VPN-en lévőnek tekintsem, és elkezdtem úgy kezelni, mint kérdést arról, hova mutat a vendég alapértelmezett útvonala. Az alábbi teszt módonként néhány percet vesz igénybe, és találgatás nélkül eldönti.

A NAT a hypervisor kódja mögött tartja a vendéget, ahol a gazdagép útvonalai érvényesek

A VirtualBoxban a NAT-vendég a 10.0.2.0/24-en ül, virtuális átjáróval a 10.0.2.2-n, DNS-proxyval a 10.0.2.3-on, és nincs saját útvonala a fizikai hálózat felé. A kimenő csomagokat a NAT-motor veszi át, átírja, hogy a forrás a gazdagép legyen, és átadja a gazdagép IP-veremének. Onnantól a vendég forgalma gazdagép-folyam, és az útvonalkeresés cél szerint történik: a teljes alagutas kliens, amely 0.0.0.0/1 és 128.0.0.0/1 útvonalat telepít a gazdagépre, elkapja anélkül, hogy valaha tudná, hogy létezik VM. Az Oracle VirtualBox-hálózatról szóló fejezete felsorolja ezeket az alapértékeket, ha ellenőrizni szeretnéd a címeket a saját buildeden.

A libvirt alapértelmezett hálózata ugyanoda jut el a 192.168.122.0/24-ből, ahol a dnsmasq bérleteket oszt és a gazdagép maszkolja az alhálózatot, így a vendég csomagjai újra a gazdagép útválasztási döntéséhez érkeznek. A kivétel az a kliens, amely folyamat szerint választ forgalmat, nem útvonal szerint. Ha az osztott alagút listája csak a böngésződet tartalmazza és semmi mást, a NAT-motor nincs ezen a listán, és a vendég alagút nélkül hagyja el a gépet, miközben a gazdagép böngészője továbbra is lefedettnek látszik. Ugyanaz az alhálózat, ellenkező eredmény.

Az áthidalás saját helyet ad a vendégnek a fizikai LAN-on

Az áthidalt vendég virtuális hálózati kártyát kap, amely valódi adapterhez csatlakozik, saját MAC-címet szerez és DHCP-bérletet vesz fel a fizikai hálózatról. Az alapértelmezett átjárója a LAN-router, nem a hypervisor, és a keretei ezen az adapteren mennek ki a vezetékre. A gazdagép alagút-útvonalai a gazdagép táblájában élnek, és soha nem kérdezik őket, mert a vendég keretei soha nem lépnek be a gazdagép IP-veremébe.

Ez mindkét irányba vág. Az mDNS és az SMB-böngészés működni kezd, mert a vendég látja a LAN broadcast-forgalmát, és a vendég elérhetővé válik a szegmens más gépeiről anélkül, hogy a gazdagép tűzfala közte lenne. Az áthidalás nem módja annak sem, hogy egy vendéget meglévő alagúton átpréselj: a VM-et a gazdagép WireGuard- vagy OpenVPN-interfészére kötni nem olyasmi, amit a VirtualBox vagy a libvirt megtenne helyetted. Ha egy áthidalt vendégnek alagúton kell átmennie, az alagútnak valahol azon a LAN-on kell végződnie.

A teszt, amely lezárja a vitát

Futtasd ugyanazokat az ellenőrzéseket mindkét módban, és írd fel a válaszokat:

  • A gazdagépen a curl -s https://ifconfig.me a nyilvános v4-címet adja.
  • A vendégben ugyanez a parancs, plusz ip route Linuxon vagy Get-NetRoute -DestinationPrefix 0.0.0.0/0 Windowson az alapértelmezett átjáróhoz.
  • A feloldó identitása: resolvectl status vagy cat /etc/resolv.conf a vendégben, hogy lássad, a 10.0.2.3-ra vagy egy LAN-kiszolgálóra mutat-e.
  • Címcsalád: ip -6 addr show scope global és egy v6-kérés, mert a v4-alagút semmit nem mond arról a globális v6-címről, amely a vendégnél lehet.

Az egyező nyilvános címek azt jelentik, hogy a vendég a gazdagép útján van. A LAN szokásos kimenetével egyező vendégcím azt jelenti, hogy nincs. A lépés, amelyet az emberek kihagynak, a kontroll: húzd le a gazdagép alagútját, és ismételd meg a vendég kérését. Ha a vendég tovább böngészik, soha nem függött a gazdagép alagútjától, bármit sugall is a mód neve. NAT módban a vendégnek el kellene veszítenie az internetet, ha a gazdagép alagútja le van húzva, kivéve, ha a kliens engedélyezi az alagút nélküli forgalmat, amit önmagában is érdemes tudni.

Két jel hazudik. A sikeres ping elérhetőséget bizonyít, nem kimeneti útvonalat. A DNS pedig a 10.0.2.3 proxyval válaszolhat a gazdagép feloldóján keresztül, miközben a TCP más útvonalat vesz, és így kapsz egy oldalt, amely betöltődik, és egy bejelentkezést, amely soha nem fejeződik be.

Melyik mód illik a feladathoz

A mód útválasztási döntés, ezért a követelmény alapján válaszd, ne a szokás alapján:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

Az első sor az, ahol az emberek fennakadnak: a NAT plusz teljes alagutas gazdagép-kliens valóban lefedi a vendéget, de csak addig, amíg a kliens útvonal szerint alagutazik, és a gazdagép uplinkje az az alagút. Vidd át a klienst egy csak böngészőre vonatkozó engedélyezési listára, és a lefedettség minden hibaüzenet nélkül eltűnik. A negyedik sor a fordított hiba: kényelemből áthidalt vendég, amely csendben elkezd SMB-re vagy SSH-ra válaszolni az irodai LAN-on.

Hibák, amelyeket a VPN-re kennek

Windowson a NAT-fordítás a VirtualBox VM-folyamatán belül fut, ezért az alkalmazásonkénti kliensnek pontosan ezt a képet kell a listáján szerepeltetnie, nem pedig egy általános szabályt a virtuális gépekre. Amikor egy kliensfrissítés újraépíti a folyamatlistáját, a NAT-vendégek veszítik el először a lefedettséget, és a jelentés úgy olvasható, mint egy VM, amely eléri a LAN-t, de az internetet nem, miközben a gazdagép rendben van.

A Wi-Fi-re áthidalás a másik klasszikus. A hozzáférési pontok ritkán továbbítanak idegen forrás-MAC-ú kereteket, ezért a wlan0-ra tett híd vagy teljesen meghiúsul, vagy addig működik, amíg az AP kliensizolációja el nem kezdi dobálni. A VirtualBox továbbra is felajánlja a vezeték nélküli adaptert a listáján. Ha a gazdagép Wi-Fi-n van, és a vendéget áthidalni kell, tervezz teszteléssel, ne feltételezéssel.

Az MTU a harmadik. Az áthidalt vendég megtartja a LAN 1500 bájtos MTU-ját, és ha saját WireGuard-klienst futtat 1420-on, a nagy TLS-kézfogások megakadnak, miközben a kis kérések átmennek. NAT alatt a gazdagép alagútjának MTU-ja a gazdagép problémája, de a vendég továbbra is hisz az 1500-ban, és a don't-fragment bittel beállított UDP ugyanígy eltűnik.

Írd fel a módot, majd ellenőrizd újra minden adaptercsere után

Írd fel a módot, a híd által használt gazdagép-interfészt, a vendég alapértelmezett átjáróját, a feloldóját, valamint a v4- és v6-kimeneti címeit. Ez a feljegyzés teszi olcsóvá a következő hibát: amikor egy laptop a dokkolóról Wi-Fi-re vált, az áthidalt vendég követi a hidat egy másik fizikai adapterre, és esetleg más alhálózatban újra bérel, míg a NAT-vendég megtartja 10.0.2.x címét, és csendben más uplinket örököl.

A ticket lezárása előtt igazold mindegyiket:

  • A vendég kimeneti címe eltér a gazdagép kimeneti címétől, tehát nincs a gazdagép alagútján.
  • A feloldó a 10.0.2.3 proxy vagy egy LAN-kiszolgáló, és tudod, melyik válaszolt.
  • Nincs globális v6-cím a vendégben, ha az alagút terve csak v4.
  • A gazdagép alagútjának lehúzásával a vendég abbahagyja a böngészést, vagy most már tudod, hogy soha nem függött tőle.
  • A vendég nem lát olyan LAN-broadcast forgalmat, amelyhez semmi köze.

Kapcsolódó cikkek