NAT ar tiltinis VM tinklas: kuris perneša VPN srautą?
NAT svečiai skolinasi hosto tunelį tik tada, kai klientas tuneliuoja pagal maršrutą; tiltiniai svečiai maršrutizuoja patys. Išbandykite svečią ir tada pasirinkite tinkamą režimą.
Tiltas ir NAT nėra du būdai prijungti tą patį svečią prie jūsų VPN; jie nusprendžia kam priklauso svečio paketai, kol tunelis dar net nepasirodė. NAT režimu hipervizorius perrašo svečio srautą ir išsiunčia jį iš hosto pusės kodo, todėl svečias važiuoja tuo maršrutu, kurį hostas duoda tam kodui. Tiltiniame režime svečias gauna savo tapatybę susiejimo lygmenyje fiziniame segmente ir pasirenka savo numatytąją šliuzą, o tai daro hosto tunelį jam nesvarbų, nebent LAN maršrutizatorius yra tas, kuris tuneliuoja. Nustojau laikyti VM esančia VPN ir pradėjau tai traktuoti kaip klausimą, kur rodo to svečio numatytasis maršrutas. Žemiau esantis testas užima kelias minutes vienam režimui ir išsprendžia be spėlionių.
NAT laiko svečią už hipervizoriaus kodo, kur galioja hosto maršrutai
VirtualBox NAT svečias sėdi 10.0.2.0/24 tinkle su virtualia šliuza 10.0.2.2, DNS įgaliuoju serveriu 10.0.2.3 ir neturi savo maršruto į fizinį tinklą. Išeinančius paketus paima NAT variklis, perrašo juos taip, kad šaltinis būtų hostas, ir perduoda hosto IP dėklui. Nuo ten svečio srautas yra hosto srautas, o maršruto paieška atliekama pagal paskirties vietą: viso tunelio klientas, kuris hoste įdiegia 0.0.0.0/1 ir 128.0.0.0/1, jį užčiuopia niekada nežinodamas, kad yra VM. Oracle VirtualBox tinklų skyrius išvardija šias numatytąsias reikšmes, jei norite patvirtinti adresus savo dieginyje.
libvirt numatytasis tinklas pasiekia tą pačią vietą iš 192.168.122.0/24, kur dnsmasq dalija nuomas, o hostas maskuoja potinklį, todėl svečio paketai vėl atvyksta į hosto maršrutizavimo sprendimą. Išimtis yra klientas, kuris renkasi srautą pagal procesą, o ne pagal maršrutą. Jei padalinto tunelio sąraše yra tik jūsų naršyklė ir nieko daugiau, NAT variklio tame sąraše nėra, ir svečias palieka mašiną be tunelio, kol hosto naršyklė vis dar atrodo uždengta. Tas pats potinklis, priešingas rezultatas.
Tiltas suteikia svečiui savo vietą fiziniame LAN
Tiltiniam svečiui suteikiama virtuali tinklo plokštė, prijungta prie tikro adapterio, jis gauna savo MAC adresą ir paima DHCP nuomą iš fizinio tinklo. Jo numatytoji šliuza yra LAN maršrutizatorius, ne hipervizorius, o jo kadrai išeina į laidą per tą adapterį. Hosto tunelio maršrutai gyvena hosto lentelėje ir niekada nėra klausiami, nes svečio kadrai niekada nepatenka į hosto IP dėklą.
Tai kerta į abi puses. mDNS ir SMB naršymas pradeda veikti, nes svečias mato LAN transliacijos srautą, o svečias tampa pasiekiamas iš kitų to paties segmento mašinų be hosto ugniasienės tarp jų. Tiltas taip pat nėra būdas stumti svečią per esamą tunelį: prijungti VM prie hosto WireGuard ar OpenVPN sąsajos nėra tai, ką VirtualBox ar libvirt padarytų už jus. Jei tiltinis svečias turi eiti per tunelį, tunelis turi baigtis kažkur tame LAN.
Testas, kuris baigia ginčą
Paleiskite tuos pačius patikrinimus abiem režimais ir užsirašykite atsakymus:
- Hoste
curl -s https://ifconfig.mepateikia viešą v4 adresą. - Svečio viduje ta pati komanda ir
ip routeLinux arbaGet-NetRoute -DestinationPrefix 0.0.0.0/0Windows, skirti numatytajai šliuzai. - Sprendėjo tapatybė:
resolvectl statusarbacat /etc/resolv.confsvečio viduje, kad pamatytumėte, ar jis rodo į 10.0.2.3, ar į LAN serverį. - Adresų šeima:
ip -6 addr show scope globalir viena v6 užklausa, nes v4 tunelis nieko nesako apie visuotinį v6 adresą, kurį svečias gali turėti.
Sutampantys vieši adresai reiškia, kad svečias yra hosto kelyje. Svečio adresas, atitinkantis įprastą LAN išėjimą, reiškia, kad ne. Žingsnis, kurį žmonės praleidžia, yra kontrolė: išjunkite hosto tunelį ir pakartokite svečio užklausą. Jei svečias toliau naršo, jis niekada nepriklausė nuo hosto tunelio, kad ir ką siūlytų režimo pavadinimas. NAT režimu svečias turėtų prarasti internetą, kai hosto tunelis išjungtas, nebent klientas sukonfigūruotas leisti srautą be tunelio, ką verta žinoti savaime.
Du signalai meluoja. Sėkmingas ping įrodo pasiekiamumą, ne išėjimo kelią. Ir DNS gali atsakyti 10.0.2.3 įgaliuoju serveriu per hosto sprendėją, kol TCP eina kitu maršrutu, ir taip gaunamas puslapis, kuris įkeliamas, ir prisijungimas, kuris niekada nebaigiamas.
Kuris režimas tinka darbui
Režimas yra maršrutizavimo sprendimas, todėl rinkitės jį pagal reikalavimą, o ne pagal įprotį:
| 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 |
Pirmoji eilutė yra ten, kur žmonės įkliūva: NAT ir viso tunelio hosto klientas tikrai uždengia svečią, bet tik tol, kol klientas tuneliuoja pagal maršrutą ir hosto aukštutinė jungtis yra tas tunelis. Perkelkite klientą į leidžiamųjų sąrašą, skirtą tik naršyklei, ir uždengimas išnyksta be jokios klaidos bet kur. Ketvirtoji eilutė yra atvirkštinė klaida: patogumui tiltu tapęs svečias, kuris tyliai pradeda atsakinėti į SMB ar SSH biuro LAN tinkle.
Gedimai, kurie priskiriami VPN
Windows NAT vertimas vyksta VirtualBox VM proceso viduje, todėl kiekvienai programai skirtas klientas turi turėti būtent tą atvaizdį savo sąraše, o ne bendrą taisyklę virtualioms mašinoms. Kai kliento atnaujinimas iš naujo sudaro proceso sąrašą, NAT svečiai pirmieji praranda uždengimą, ir ataskaita skamba kaip VM, kuri pasiekia LAN, bet ne internetą, kol hostas yra tvarkingas.
Tiltas į Wi-Fi yra kitas klasikinis atvejis. Prieigos taškai retai persiunčia kadrus su svetimu šaltinio MAC, todėl tiltas į wlan0 arba visiškai nepavyksta, arba veikia tol, kol AP klientų izoliacija pradeda jį mesti. VirtualBox vis tiek pasiūlys belaidį adapterį savo sąraše. Jei hostas yra Wi-Fi tinkle ir svečią reikia tiltu, planuokite tai išbandyti, o ne manyti.
MTU yra trečias. Tiltinis svečias išlaiko LAN 1500 baitų MTU, o jei jis paleidžia savo WireGuard klientą 1420, dideli TLS rankos paspaudimai sustoja, o maži prašymai pavyksta. Pagal NAT hosto tunelio MTU yra hosto problema, bet svečias vis dar tiki 1500, o UDP su nustatytu don't-fragment bitu išnyksta taip pat.
Užrašykite režimą ir po kiekvieno adapterio pakeitimo patikrinkite iš naujo
Užrašykite režimą, hosto sąsają, kurią naudoja tiltas, svečio numatytąją šliuzą, jo sprendėją ir jo v4 bei v6 išėjimo adresus. Būtent šis įrašas daro kitą gedimą pigų: kai nešiojamasis kompiuteris persikelia iš doko į Wi-Fi, tiltinis svečias seka tiltą į kitą fizinį adapterį ir gali iš naujo nuomotis kitame potinklyje, o NAT svečias išlaiko savo 10.0.2.x adresą ir tyliai paveldi kitą aukštutinę jungtį.
Prieš uždarydami bilietą, patvirtinkite kiekvieną iš šių:
- Svečio išėjimo adresas skiriasi nuo hosto išėjimo adreso, taigi jis nėra hosto tunele.
- Sprendėjas yra 10.0.2.3 įgaliojasis serveris arba LAN serveris, ir žinote, kuris atsakė.
- Svečio viduje nėra visuotinio v6 adreso, jei tunelio projektas yra tik v4.
- Išjungus hosto tunelį, svečias nustoja naršyti, arba dabar žinote, kad jis niekada nuo jo nepriklausė.
- Svečias nemato LAN transliacijos srauto, kuris jo neliečia.