Sieť VM v režime NAT alebo bridged: ktorá z nich prenáša prevádzku VPN?
Hostia v NAT si tunel hostiteľa požičiavajú len vtedy, keď klient tuneluje podľa trasy; hostia v bridged si smerujú sami. Otestujte hosťa a potom vyberte vhodný režim.
Bridged a NAT nie sú dva spôsoby pripojenia toho istého hosťa k vášmu VPN; rozhodujú o tom, kto vlastní pakety hosťa skôr, než sa do hry dostane akýkoľvek tunel. V režime NAT hypervízor prepisuje prevádzku hosťa a vysiela ju z kódu na strane hostiteľa, takže hosť ide po trase, ktorú hostiteľ tomu kódu dá. V režime bridged hosť získa vlastnú identitu linkovej vrstvy na fyzickom segmente a vyberá si vlastnú predvolenú bránu, čo robí tunel hostiteľa preňho nepodstatným, pokiaľ tunelovanie nerobí samotný router LAN. Prestal som brať VM ako niečo, čo je vo VPN, a začal som to brať ako otázku, kam ukazuje predvolená trasa toho hosťa. Test nižšie trvá pri každom režime pár minút a vyrieši to bez hádania.
NAT drží hosťa za kódom hypervízora, kde platia trasy hostiteľa
Vo VirtualBoxe sedí hosť NAT v 10.0.2.0/24 s virtuálnou bránou 10.0.2.2, proxy DNS 10.0.2.3 a bez vlastnej trasy do fyzickej siete. Odchádzajúce pakety prevezme mechanizmus NAT, prepíše ich tak, aby zdrojom bol hostiteľ, a odovzdá ich zásobníku IP hostiteľa. Odvtedy je prevádzka hosťa tokom hostiteľa a vyhľadanie trasy ide podľa cieľa: klient s plným tunelom, ktorý na hostiteľovi nastaví 0.0.0.0/1 a 128.0.0.0/1, ho zachytí a ani nevie, že nejaká VM existuje. Kapitola o sieťach vo VirtualBoxe od Oracle uvádza tieto predvolené hodnoty, ak si chcete overiť adresy na svojom builde.
Predvolená sieť libvirtu sa dostane na to isté miesto z 192.168.122.0/24, kde dnsmasq rozdáva prenájmy a hostiteľ maskuje podsústavu, takže pakety hosťa znova dospejú k rozhodnutiu o smerovaní na hostiteľovi. Výnimkou je klient, ktorý vyberá prevádzku podľa procesu, nie podľa trasy. Ak zoznam rozdeleného tunelovania obsahuje len váš prehliadač, mechanizmus NAT v tom zozname nie je a hosť opúšťa stroj bez tunela, kým prehliadač na hostiteľovi stále vyzerá pokrytý. Tá istá podsústava, opačný výsledok.
Bridged dáva hosťovi vlastné miesto vo fyzickej LAN
Bridged hosť dostane virtuálnu sieťovú kartu pripojenú k fyzickému adaptéru, získa vlastnú MAC adresu a prenájom DHCP z fyzickej siete. Jeho predvolená brána je router LAN, nie hypervízor, a jeho rámce idú na drôt cez ten adaptér. Trasy tunela hostiteľa sú v tabuľke hostiteľa a nikdy sa nekonzultujú, pretože rámce hosťa sa nikdy nedostanú do zásobníka IP hostiteľa.
To reže na obe strany. Prehliadanie mDNS a SMB začne fungovať, pretože hosť vidí broadcast prevádzku LAN, a hosť sa stane dostupným z iných strojov v tom istom segmente bez firewallu hostiteľa medzi nimi. Bridging tiež nie je spôsob, ako pretlačiť hosťa existujúcim tunelom: pripojiť VM k rozhraniu WireGuard alebo OpenVPN hostiteľa nie je niečo, čo za vás urobí VirtualBox alebo libvirt. Ak bridged hosť musí byť tunelovaný, tunel musí skončiť niekde v tej LAN.
Test, ktorý ukončí spor
Spustite tie isté kontroly v oboch režimoch a odpovede si zapíšte:
- Na hostiteľovi,
curl -s https://ifconfig.mevráti verejnú adresu v4. - V hosťovi ten istý príkaz plus
ip routev Linuxe aleboGet-NetRoute -DestinationPrefix 0.0.0.0/0vo Windows pre predvolenú bránu. - Identita prekladača:
resolvectl statusalebocat /etc/resolv.confv hosťovi, aby ste videli, či ukazuje na 10.0.2.3 alebo na server v LAN. - Rodina adries:
ip -6 addr show scope globala jedna požiadavka v6, pretože tunel v4 nehovorí nič o globálnej adrese v6, ktorú hosť môže mať.
Zhodné verejné adresy znamenajú, že hosť ide po ceste hostiteľa. Adresa hosťa, ktorá sa zhoduje s bežným výstupom LAN, znamená, že nejde. Krok, ktorý ľudia preskakujú, je kontrola: zložte tunel hostiteľa a požiadavku z hosťa zopakujte. Ak hosť ďalej prehliada, nikdy nezávisel od tunela hostiteľa, nech už názov režimu naznačuje čokoľvek. V režime NAT by hosť mal stratiť internet pri zloženom tuneli hostiteľa, pokiaľ klient nie je nastavený povoliť prevádzku mimo tunela, čo je samo o sebe užitočné vedieť.
Dva signály klamú. Úspešný ping dokazuje dostupnosť, nie výstupnú cestu. A DNS môže odpovedať cez proxy 10.0.2.3 prostredníctvom prekladača hostiteľa, kým TCP ide inou trasou, a tak vznikne stránka, ktorá sa načíta, a prihlásenie, ktoré sa nikdy nedokončí.
Ktorý režim sa hodí na danú úlohu
Režim je rozhodnutie o smerovaní, takže ho vyberajte podľa požiadavky, nie podľa 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 |
Prvý riadok je miesto, kde sa ľudia chytia: NAT plus klient s plným tunelom na hostiteľovi hosťa naozaj pokryje, ale len kým klient tuneluje podľa trasy a odchádzajúce pripojenie hostiteľa je ten tunel. Presuňte klienta na zoznam povolených len pre prehliadač a pokrytie zmizne bez akéhokoľvek hlásenia kdekoľvek. Štvrtý riadok je opačná chyba, hosť v bridged režime pre pohodlie, ktorý potichu začne odpovedať na SMB alebo SSH v kancelárskej LAN.
Poruchy, ktoré sa zvaľujú na VPN
Vo Windows beží preklad NAT vnútri procesu VM vo VirtualBoxe, takže klient podľa aplikácií potrebuje na zozname presne tento image, nie všeobecné pravidlo pre virtuálne stroje. Keď aktualizácia klienta prestaví zoznam povolených procesov, hostia NAT stratia pokrytie ako prví a hlásenie znie ako VM, ktorá dosiahne LAN, ale nie internet, kým hostiteľ je v poriadku.
Bridging na Wi-Fi je druhá klasika. Prístupové body málokedy preposielajú rámce s cudzou zdrojovou MAC adresou, takže most na wlan0 buď hneď zlyhá, alebo funguje, kým ho izolácia klientov na AP nezačne zahadzovať. VirtualBox vám bezdrôtový adaptér na zozname aj tak ponúkne. Ak je hostiteľ na Wi-Fi a hosť musí byť bridged, naplánujte test namiesto predpokladu.
MTU je tretí. Bridged hosť si drží MTU LAN 1500 bajtov, a ak prevádzkuje vlastného klienta WireGuard na 1420, veľké TLS podania ruky zaseknú, kým malé požiadavky prejdú. Pod NAT je MTU tunela hostiteľa problém hostiteľa, ale hosť stále verí na 1500 a UDP s nastaveným bitom don't-fragment skončí v čiernej diere rovnako.
Zapíšte režim a po každej zmene adaptéra ho znova overte
Zaznamenajte režim, rozhranie hostiteľa, ktoré most používa, predvolenú bránu hosťa, jeho prekladač a výstupné adresy v4 a v6. Práve tento záznam robí ďalšiu poruchu lacnou: keď sa laptop presunie z doku na Wi-Fi, bridged hosť nasleduje most na iný fyzický adaptér a môže sa znova prenajať do inej podsústavy, kým hosť NAT si ponechá adresu 10.0.2.x a potichu zdedí iné odchádzajúce pripojenie.
Pred zatvorením tiketu potvrďte každý z týchto bodov:
- Výstupná adresa hosťa sa líši od výstupnej adresy hostiteľa, takže nie je v tuneli hostiteľa.
- Prekladač je proxy 10.0.2.3 alebo server v LAN a viete, ktorý z nich odpovedal.
- V hosťovi neexistuje globálna adresa v6, ak je návrh tunela iba v4.
- Pri zloženom tuneli hostiteľa hosť prestane prehliadať, alebo už viete, že od neho nikdy nezávisel.
- Hosť nevidí broadcast prevádzku LAN, ktorú by vidieť nemal.