NAT versus mostové síťování VM: které přenáší VPN provoz?
NAT hosté si půjčují tunel hostitele jen tehdy, když klient tuneluje podle trasy; mostoví hosté si směrují sami. Otestujte hosta a pak zvolte odpovídající režim.
Mostový režim a NAT nejsou dva způsoby připojení stejného hosta k vaší VPN; rozhodují o tom, komu patří pakety hosta dřív, než se do toho zapojí jakýkoli tunel . V režimu NAT hypervizor přepisuje provoz hosta a vysílá ho z kódu na straně hostitele, takže host jede po trase, kterou hostitel tomuto kódu dá. V mostovém režimu dostane host vlastní identitu linkové vrstvy na fyzickém segmentu a volí si vlastní výchozí bránu, což činí tunel hostitele irelevantním, pokud tunel nestaví router na LAN. Přestal jsem brát VM jako součást VPN a začal to vnímat jako otázku, kam ukazuje výchozí trasa toho hosta. Test níže trvá pár minut na režim a rozhodne to bez hádání.
NAT drží hosta za kódem hypervizoru, kde platí trasy hostitele
Ve VirtualBoxu sedí NAT host na 10.0.2.0/24 s virtuální bránou 10.0.2.2, DNS proxy 10.0.2.3 a bez vlastní trasy do fyzické sítě. Odchozí pakety převezme NAT engine, přepíše je tak, aby zdrojem byl hostitel, a předá je IP zásobníku hostitele. Odtud je provoz hosta tokem hostitele a hledání trasy probíhá podle cíle: klient s plným tunelem, který na hostiteli nainstaluje 0.0.0.0/1 a 128.0.0.0/1, ho zachytí, aniž by věděl, že VM existuje. Kapitola o síťování VirtualBoxu od Oracle uvádí tyto výchozí hodnoty, pokud si chcete adresy na své sestavě ověřit.
Výchozí síť libvirtu se dostane na stejné místo z 192.168.122.0/24, kde dnsmasq rozdává lease a hostitel maskaruje podsíť, takže pakety hosta znovu dorazí k rozhodnutí o směrování na hostiteli. Výjimkou je klient, který vybírá provoz podle procesu, ne podle trasy. Pokud seznam pro rozdělený tunel obsahuje jen váš prohlížeč, NAT engine na tom seznamu není a host opouští stroj bez tunelu, zatímco prohlížeč hostitele stále vypadá pokrytý. Stejná podsíť, opačný výsledek.
Mostový režim dá hostovi vlastní místo na fyzické LAN
Mostový host dostane virtuální NIC připojenou ke skutečnému adaptéru, vlastní MAC adresu a DHCP lease z fyzické sítě. Jeho výchozí brána je router na LAN, ne hypervizor, a jeho rámce jdou na drát přes tento adaptér. Tunelové trasy hostitele žijí v tabulce hostitele a nikdy se nekonzultují, protože rámce hosta nikdy nevstoupí do IP zásobníku hostitele.
To řeže na obě strany. Prohlížení mDNS a SMB začne fungovat, protože host vidí broadcast provoz LAN, a host se stane dostupným z jiných strojů ve stejném segmentu bez firewallu hostitele mezi nimi. Most také není způsob, jak protlačit hosta přes existující tunel: připojit VM k rozhraní WireGuard nebo OpenVPN hostitele není něco, co by VirtualBox nebo libvirt udělaly za vás. Pokud mostový host musí být v tunelu, tunel musí končit někde na této LAN.
Test, který ukončí hádku
Proveďte stejné kontroly v obou režimech a zapište odpovědi:
- Na hostiteli
curl -s https://ifconfig.medává veřejnou v4 adresu. - V hostu stejný příkaz, plus
ip routena Linuxu neboGet-NetRoute -DestinationPrefix 0.0.0.0/0na Windows pro výchozí bránu. - Identita resolveru:
resolvectl statusnebocat /etc/resolv.confv hostu, abyste viděli, zda ukazuje na 10.0.2.3, nebo na server v LAN. - Rodina adres:
ip -6 addr show scope globala jeden v6 požadavek, protože v4 tunel neříká nic o globální v6 adrese, kterou host může mít.
Shodné veřejné adresy znamenají, že host jde cestou hostitele. Adresa hosta, která odpovídá běžnému výstupu LAN, znamená, že ne. Krok, který lidé vynechávají, je kontrola: sundejte tunel hostitele a zopakujte požadavek hosta. Pokud host dál prohlíží, nikdy na tunelu hostitele nezávisel, ať název režimu naznačuje cokoli. V režimu NAT by měl host ztratit internet při vypnutém tunelu hostitele, ledaže je klient nastaven tak, aby povoloval provoz mimo tunel, což je samo o sobě užitečné vědět.
Dva signály lžou. Úspěšný ping dokazuje dosažitelnost, ne výstupní cestu. A DNS může odpovědět proxy 10.0.2.3 přes resolver hostitele, zatímco TCP jde jinou trasou, a tak vznikne stránka, která se načte, a přihlášení, které nikdy neskončí.
Který režim se hodí k úloze
Režim je rozhodnutí o směrování, takže ho vybírejte podle požadavku, ne podle zvyku:
| Requirement | Mode that fits |
|---|---|
| Every guest flow must exit through the host tunnel | NAT, with a host client that tunnels by route, verified from inside the guest |
| The guest needs its own VPN account or profile | Bridged, or NAT with a client running inside the guest, not both |
| The guest must serve SSH, SMB, or a dev server to the LAN | Bridged; NAT needs a port forward, which does not change the outbound path |
| The guest must stay invisible to the LAN | NAT; a bridged guest is another host on the segment |
| The guest needs a real public IPv6 address | Bridged; VirtualBox NAT mode has no IPv6 forwarding |
| Isolation from the LAN with access to the host | Host-only adapter, not NAT |
První řádek je místo, kde se lidé chytí: NAT plus klient s plným tunelem na hostiteli hosta skutečně pokrývá, ale jen dokud klient tuneluje podle trasy a dokud je spojení hostitele tímto tunelem. Přesuňte klienta do seznamu jen pro prohlížeč a pokrytí zmizí bez jakékoli chyby. Čtvrtý řádek je opačná chyba: host zmostovaný pro pohodlí začne tiše odpovídat na SMB nebo SSH v kancelářské LAN.
Selhání, která se svádějí na VPN
Ve Windows běží překlad NAT uvnitř procesu VirtualBox VM, takže klientský program pro jednotlivé aplikace potřebuje přesně tento image na svém seznamu, ne obecné pravidlo pro virtuální stroje. Když aktualizace klienta znovu postaví seznam povolených procesů, NAT hosté ztratí pokrytí jako první a zpráva vypadá jako VM, která dosáhne na LAN, ale ne na internet, zatímco hostitel je v pořádku.
Most do Wi-Fi je další klasika. Přístupové body zřídka předávají rámce s cizí zdrojovou MAC, takže most na wlan0 buď úplně selže, nebo funguje, dokud ho izolace klientů na AP nezačne zahazovat. VirtualBox přesto bezdrátový adaptér v seznamu nabídne. Pokud je hostitel na Wi-Fi a host musí být mostový, naplánujte test, místo abyste to předpokládali.
MTU je třetí. Mostový host si zachová MTU LAN 1500 bajtů, a pokud spustí vlastního klienta WireGuard na 1420, velké TLS handshaky se zaseknou, zatímco malé požadavky projdou. Pod NAT je MTU tunelu hostitele problém hostitele, ale host stále věří v 1500, a UDP s nastaveným bitem nefragmentovat spadne do stejné černé díry.
Zapište režim a po každé změně adaptéru zkontrolujte znovu
Zaznamenejte režim, rozhraní hostitele, které most používá, výchozí bránu hosta, jeho resolver a jeho výstupní adresy v4 a v6. Právě tento záznam dělá příští selhání levným: když notebook přejde z doku na Wi-Fi, mostový host následuje most na jiný fyzický adaptér a může si znovu pronajmout adresu v jiné podsíti, zatímco NAT host si drží adresu 10.0.2.x a tiše zdědí jiné spojení.
Než tiket zavřete, potvrďte každé z těchto:
- Výstupní adresa hosta se liší od výstupní adresy hostitele, takže není v tunelu hostitele.
- Resolver je proxy 10.0.2.3 nebo server v LAN a víte, který z nich odpověděl.
- V hostu není globální v6 adresa, pokud je návrh tunelu jen v4.
- Když je tunel hostitele dole, host přestane prohlížet, nebo už víte, že na něm nikdy nezávisel.
- Host nevidí broadcast provoz LAN, který by vidět neměl.