Omrežje VM v načinu NAT ali bridged: katero prenaša promet VPN?
Gostje NAT si tunel gostitelja izposodijo le, če odjemalec tunelira po poti; gostje bridged usmerjajo sami. Preizkusite gosta in nato izberite ustrezen način.
Bridged in NAT nista dva načina priklopa istega gosta na vaš VPN; odločata o tem, kdo je lastnik paketov gosta, preden v igro sploh stopi tunel. V načinu NAT hipervizor prepiše promet gosta in ga odda iz kode na strani gostitelja, zato gre gost po poti, ki jo gostitelj da tej kodi. V načinu bridged gost dobi lastno identiteto povezovalnega sloja na fizičnem segmentu in izbere lastna privzeta prehodna vrata, zaradi česar je tunel gostitelja zanj nepomemben, razen če tunelira sam usmerjevalnik LAN. Nehal sem obravnavati VM kot nekaj, kar je v VPN, in to začel obravnavati kot vprašanje, kam kaže privzeta pot tega gosta. Preizkus spodaj traja nekaj minut na način in stvar razreši brez ugibanja.
NAT drži gosta za kodo hipervizorja, kjer veljajo poti gostitelja
V VirtualBoxu gost NAT sedi v 10.0.2.0/24 z navideznimi prehodnimi vrati 10.0.2.2, proxyjem DNS 10.0.2.3 in brez lastne poti v fizično omrežje. Odhodne pakete prevzame mehanizem NAT, jih prepiše tako, da je vir gostitelj, in jih preda skladu IP gostitelja. Odtlej je promet gosta tok gostitelja, iskanje poti pa poteka po cilju: odjemalec s polnim tunelom, ki na gostitelju nastavi 0.0.0.0/1 in 128.0.0.0/1, ga ujame, ne da bi sploh vedel, da VM obstaja. Oracleovo poglavje o omrežjih v VirtualBoxu navaja te privzete vrednosti, če želite preveriti naslove v svoji različici.
Privzeto omrežje libvirta pride na isto mesto iz 192.168.122.0/24, kjer dnsmasq deli najeme in gostitelj maskira podomrežje, zato paketi gosta spet prispejo do odločitve o usmerjanju na gostitelju. Izjema je odjemalec, ki promet izbira po procesu in ne po poti. Če seznam razdeljenega tuneliranja vsebuje samo vaš brskalnik, mehanizma NAT na tem seznamu ni in gost zapusti stroj brez tunela, medtem ko je brskalnik na gostitelju še vedno videti pokrit. Isto podomrežje, nasproten izid.
Bridged da gostu lastno mesto v fizičnem LAN
Gost bridged dobi navidezno omrežno kartico, pripeto na resnični vmesnik, dobi lasten naslov MAC in najem DHCP iz fizičnega omrežja. Njegova privzeta prehodna vrata so usmerjevalnik LAN, ne hipervizor, njegovi okviri pa gredo na žico skozi ta vmesnik. Poti tunela gostitelja so v tabeli gostitelja in se nikoli ne upoštevajo, ker okviri gosta nikoli ne vstopijo v sklad IP gostitelja.
To reže na obe strani. Brskanje po mDNS in SMB se začne, ker gost vidi oddajni promet LAN, in gost postane dosegljiv z drugih strojev v istem segmentu brez požarnega zidu gostitelja vmes. Bridging tudi ni način, kako gosta potisniti skozi obstoječi tunel: pripeti VM na vmesnik WireGuard ali OpenVPN gostitelja ni nekaj, kar bi VirtualBox ali libvirt naredil za vas. Če mora biti gost bridged tuneliran, se mora tunel končati nekje v tem LAN.
Preizkus, ki konča prepir
Poženite iste preverbe v obeh načinih in odgovore zapišite:
- Na gostitelju
curl -s https://ifconfig.mevrne javni naslov v4. - V gostu ista ukaz, plus
ip routev Linuxu aliGet-NetRoute -DestinationPrefix 0.0.0.0/0v Windows za privzeta prehodna vrata. - Identiteta preiskovalca:
resolvectl statusalicat /etc/resolv.confv gostu, da vidite, ali kaže na 10.0.2.3 ali na strežnik v LAN. - Družina naslovov:
ip -6 addr show scope globalin eno zahtevo v6, ker tunel v4 ne pove nič o globalnem naslovu v6, ki ga gost morda ima.
Enaki javni naslovi pomenijo, da je gost na poti gostitelja. Naslov gosta, ki se ujema z običajnim izhodom LAN, pomeni, da ni. Korak, ki ga ljudje izpustijo, je kontrola: spustite tunel gostitelja in zahtevo iz gosta ponovite. Če gost še naprej brska, nikoli ni bil odvisen od tunela gostitelja, kakor koli se način imenuje. V načinu NAT naj bi gost izgubil internet ob spuščenem tunelu gostitelja, razen če je odjemalec nastavljen tako, da dovoli promet zunaj tunela, kar je samo po sebi vredno vedeti.
Dva signala lažeta. Uspešen ping dokaže dosegljivost, ne izhodne poti. In DNS lahko odgovori proxy 10.0.2.3 prek preiskovalca gostitelja, medtem ko gre TCP po drugi poti, in tako dobite stran, ki se naloži, ter prijavo, ki se nikoli ne dokonča.
Kateri način ustreza nalogi
Način je odločitev o usmerjanju, zato ga izberite po zahtevi, ne po navadi:
| 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 |
Prva vrstica je mesto, kjer se ljudje ujamejo: NAT in odjemalec s polnim tunelom na gostitelju gosta res pokrije, a le dokler odjemalec tunelira po poti in je vzvodna povezava gostitelja ta tunel. Premaknite odjemalec na seznam dovoljenih samo za brskalnik in pokritost izgine brez kakršne koli napake kjerkoli. Četrta vrstica je obratna napaka, gost v načinu bridged iz udobja, ki tiho začne odgovarjati na SMB ali SSH v pisarniškem LAN.
Okvare, ki jih pripišejo VPN
V Windows se prevajanje NAT izvaja znotraj procesa VM v VirtualBoxu, zato odjemalec po aplikacijah potrebuje točno to podobo na seznamu, ne splošnega pravila za navidezne stroje. Ko posodobitev odjemalca znova sestavi seznam dovoljenih procesov, gostje NAT prvi izgubijo pokritost in poročilo se bere kot VM, ki doseže LAN, ne pa interneta, medtem ko je gostitelj v redu.
Bridging na Wi-Fi je druga klasika. Dostopne točke redko posredujejo okvire s tujim izvornim naslovom MAC, zato most na wlan0 bodisi takoj odpove bodisi deluje, dokler ga izolacija odjemalcev na AP ne začne zavračati. VirtualBox bo brezžični vmesnik na seznamu še vedno ponudil. Če je gostitelj na Wi-Fi in mora biti gost bridged, načrtujte preizkus, ne pa domneve.
MTU je tretji. Gost bridged ohrani MTU LAN 1500 bajtov, in če poganja lastnega odjemalca WireGuard na 1420, se veliki rokovanji TLS ustavita, medtem ko majhne zahteve uspejo. Pod NAT je MTU tunela gostitelja težava gostitelja, a gost še vedno verjame v 1500 in UDP z nastavljenim bitom don't-fragment konča v črni luknji prav tako.
Zapišite način in preverite znova po vsaki menjavi vmesnika
Zabeležite način, vmesnik gostitelja, ki ga most uporablja, privzeta prehodna vrata gosta, njegov preiskovalec ter izhodna naslova v4 in v6. Prav ta zapis naredi naslednjo okvaro poceni: ko se prenosnik preseli s postaje na Wi-Fi, gost bridged sledi mostu na drug fizični vmesnik in se lahko znova najame v drugo podomrežje, medtem ko gost NAT obdrži naslov 10.0.2.x in tiho podeduje drugo vzvodno povezavo.
Preden zaprete zahtevek, potrdite vsako od teh točk:
- Izhodni naslov gosta se razlikuje od izhodnega naslova gostitelja, torej ni v tunelu gostitelja.
- Preiskovalec je proxy 10.0.2.3 ali strežnik v LAN in veste, kateri od njiju je odgovoril.
- V gostu ni globalnega naslova v6, če je zasnova tunela samo v4.
- Ob spuščenem tunelu gostitelja gost preneha brskati, ali pa zdaj veste, da od njega nikoli ni bil odvisen.
- Gost ne vidi oddajnega prometa LAN, ki ga ne bi smel videti.