NAT aŭ pontita VM-retaro: kiu portas la VPN-trafikon?
NAT-gastoj pruntas la gastigan tunelon nur se la kliento tunelas laŭ itinero; pontitaj gastoj mem itinumas. Testu la gaston, poste elektu la konforman reĝimon.
Pontita kaj NAT ne estas du manieroj ligi la saman gaston al via VPN; ili decidas kiu posedas la pakaĵojn de la gasto antaŭ ol tunelo entras la bildon. En la NAT-reĝimo la hipervidilo reverkas la trafikon de la gasto kaj elsendas ĝin el hosta kodo, do la gasto uzas ajnan itineron, kiun la hosto donas al tiu kodo. En pontita reĝimo la gasto ricevas propran identecon ĉe la ligtavolo en la fizika segmento kaj elektas sian propran implicitan enpasejon, kio igas la tunelon de la hosto sensignifa por ĝi, krom se la LAN-enkursigilo estas tiu, kiu tunelas. Mi ĉesis trakti la VM-on kiel parton de la VPN kaj komencis trakti ĝin kiel demandon pri tio, kien montras la implicita itinero de tiu gasto. La suba testo daŭras kelkajn minutojn por reĝimo kaj solvas ĝin sen divenado.
NAT tenas la gaston malantaŭ hipervidila kodo, kie validas la itineroj de la hosto
En VirtualBox NAT-gasto sidas sur 10.0.2.0/24 kun virtuala enpasejo ĉe 10.0.2.2, DNS-prokurilo ĉe 10.0.2.3, kaj neniu propra itinero al la fizika reto. Elirantajn pakaĵojn prenas la NAT-motoro, reverkas ilin tiel, ke la fonto estas la hosto, kaj transdonas ilin al la IP-stako de la hosto. De tie la trafiko de la gasto estas hosta fluo, kaj itinera serĉo okazas laŭ celo: plentunela kliento, kiu instalas 0.0.0.0/1 kaj 128.0.0.0/1 sur la hosto, kaptas ĝin sen iam scii, ke ekzistas VM. La ĉapitro de Oracle pri VirtualBox-retaro listigas tiujn implicitajn valorojn, se vi volas konfirmi la adresojn en via konstruo.
La implicita reto de libvirt atingas la saman lokon el 192.168.122.0/24, kie dnsmasq disdonas luojn kaj la hosto maskas la subreton, do la pakaĵoj de la gasto denove alvenas al la enkursiga decido de la hosto. La escepto estas kliento, kiu elektas trafikon laŭ procezo anstataŭ laŭ itinero. Se la listo de disigita tunelado enhavas vian retumilon kaj nenion alian, la NAT-motoro ne estas sur tiu listo, kaj la gasto forlasas la maŝinon sen tunelo, dum la retumilo de la hosto ankoraŭ ŝajnas kovrita. Sama subreto, kontraŭa rezulto.
Pontigo donas al la gasto propran lokon en la fizika LAN
Pontita gasto ricevas virtualan retkarton ligitan al reala adaptilo, akiras propran MAC-adreson kaj prenas DHCP-luon el la fizika reto. Ĝia implicita enpasejo estas la LAN-enkursigilo, ne la hipervidilo, kaj ĝiaj kadroj iras sur la draton tra tiu adaptilo. La tunelaj itineroj de la hosto restas en la tabelo de la hosto kaj neniam estas konsultataj, ĉar la kadroj de la gasto neniam eniras la IP-stakon de la hosto.
Tio tranĉas ambaŭdirekte. mDNS kaj SMB-retumado eklaboras, ĉar la gasto vidas LAN-dissendan trafikon, kaj la gasto fariĝas atingebla de aliaj maŝinoj en la sama segmento sen hosta fajroŝirmilo intere. Pontigo ankaŭ ne estas maniero puŝi gaston tra ekzistanta tunelo: ligi VM-on al la WireGuard- aŭ OpenVPN-interfaco de la hosto ne estas io, kion VirtualBox aŭ libvirt faras por vi. Se pontita gasto devas esti tunelita, la tunelo devas finiĝi ie en tiu LAN.
La testo, kiu finas la disputon
Rulu la samajn kontrolojn en ambaŭ reĝimoj kaj skribu la respondojn:
- Sur la hosto,
curl -s https://ifconfig.medonas la publikan v4-adreson. - En la gasto, la sama komando, plus
ip routesur Linux aŭGet-NetRoute -DestinationPrefix 0.0.0.0/0sur Windows por la implicita enpasejo. - Identeco de la solvilo:
resolvectl statusaŭcat /etc/resolv.confen la gasto, por vidi ĉu ĝi montras al 10.0.2.3 aŭ al LAN-servilo. - Adresfamilio:
ip -6 addr show scope globalkaj unu v6-peto, ĉar v4-tunelo diras nenion pri tutmonda v6-adreso, kiun la gasto eble havas.
Kongruaj publikaj adresoj signifas, ke la gasto estas sur la vojo de la hosto. Gasta adreso kongrua kun la ordinara eliro de la LAN signifas, ke ĝi ne estas. La paŝo, kiun homoj preterlasas, estas la kontrolo: malŝaltu la tunelon de la hosto kaj ripetu la peton de la gasto. Se la gasto daŭre retumas, ĝi neniam dependis de la tunelo de la hosto, kion ajn la nomo de la reĝimo sugestas. En NAT-reĝimo la gasto devus perdi interreton kun la hosta tunelo malŝaltita, krom se la kliento estas agordita por permesi netunelitan trafikon, kio mem indas scii.
Du signaloj mensogas. Sukcesa ping pruvas atingeblon, ne eliran vojon. Kaj DNS povas esti respondita de la prokurilo 10.0.2.3 tra la solvilo de la hosto, dum TCP prenas alian itineron, tiel vi ricevas paĝon, kiu ŝargiĝas, kaj saluton, kiu neniam finiĝas.
Kiu reĝimo taŭgas por la tasko
La reĝimo estas enkursiga decido, do elektu ĝin laŭ la postulo anstataŭ laŭ kutimo:
| 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 |
La unua vico estas kie homoj kaptiĝas: NAT plus plentunela hosta kliento ja kovras gaston, sed nur dum la kliento tunelas laŭ itinero kaj la hosta suprenligo estas tiu tunelo. Movu la klienton al permeslisto nur por retumilo kaj la kovrado malaperas sen iu ajn eraro ie ajn. La kvara vico estas la inversa eraro: gasto pontita pro oportuneco, kiu kviete ekkomencas respondi SMB aŭ SSH en la oficeja LAN.
Malsukcesoj, kiuj estas kulpigataj al la VPN
Sur Windows la NAT-traduko rulas ene de la VirtualBox-VM-procezo, do po-aplika kliento bezonas ĝuste tiun bildon sur sia listo anstataŭ ĝeneralan regulon por virtualaj maŝinoj. Kiam klienta ĝisdatigo rekonstruas sian procezliston, NAT-gastoj unue perdas kovradon, kaj la raporto legiĝas kiel VM, kiu atingas la LAN sed ne la interreton, dum la hosto estas en ordo.
Pontigo al Wi-Fi estas la alia klasikaĵo. Alirpunktoj malofte plusendas kadrojn kun fremda fonta MAC, do ponto al wlan0 aŭ tute malsukcesas aŭ funkcias ĝis klienta izolado sur la alirpunkto ekmalasas ĝin. VirtualBox ankoraŭ proponos la sendratan adaptilon en sia listo. Se la hosto estas sur Wi-Fi kaj la gasto devas esti pontita, planu testi ĝin anstataŭ supozi ĝin.
MTU estas la tria. Pontita gasto konservas la 1500-bajtan MTU de la LAN, kaj se ĝi rulas propran WireGuard-klienton je 1420, grandaj TLS-manpremoj haltas dum malgrandaj petoj sukcesas. Sub NAT la MTU de la hosta tunelo estas la problemo de la hosto, sed la gasto ankoraŭ kredas je 1500, kaj UDP kun la ne-fragmentigu bito ŝaltita same malaperas.
Notu la reĝimon kaj rekontrolu post ĉiu adaptila ŝanĝo
Notu la reĝimon, la hostan interfacon, kiun uzas la ponto, la implicitan enpasejon de la gasto, ĝian solvilon kaj ĝiajn v4- kaj v6-elirajn adresojn. Tiu noto igas la sekvan malsukceson malmultekosta: kiam tekkomputilo moviĝas de doko al Wi-Fi, pontita gasto sekvas la ponton al alia fizika adaptilo kaj eble reluas en alian subreton, dum NAT-gasto konservas sian 10.0.2.x-adreson kaj silente heredas alian suprenligon.
Antaŭ ol fermi la bileton, konfirmu ĉiun el ĉi tiuj:
- La elira adreso de la gasto diferencas de la elira adreso de la hosto, do ĝi ne estas sur la hosta tunelo.
- La solvilo estas la prokurilo 10.0.2.3 aŭ LAN-servilo, kaj vi scias, kiu respondis.
- Neniu tutmonda v6-adreso ekzistas en la gasto, se la tunela dezajno estas nur v4.
- Kun la hosta tunelo malŝaltita, la gasto ĉesas retumi, aŭ vi nun scias, ke ĝi neniam dependis de ĝi.
- La gasto ne vidas LAN-dissendan trafikon, kiu tute ne koncernas ĝin.