NAT vai sillattu VM-verkko: kumpi kuljettaa VPN-liikenteen?

NAT-vieraat lainaavat isäntäkoneen tunnelia vain, jos asiakas tunneloi reitin mukaan; sillatut vieraat reitittävät itse. Testaa vieras ja valitse sitten sopiva tila.

Sillattu ja NAT eivät ole kaksi tapaa liittää sama vieras VPN:hen; ne päättävät, kenelle vieraan paketit kuuluvat ennen kuin tunnelia on edes mukana. NAT-tilassa hypervisor kirjoittaa vieraan liikenteen uudelleen ja lähettää sen isäntäpuolen koodista, joten vieras kulkee millä tahansa reitillä, jonka isäntä sille koodille antaa. Sillatussa tilassa vieras saa oman linkkikerroksen identiteetin fyysisessä segmentissä ja valitsee oman oletusyhdyskäytävänsä, mikä tekee isännän tunnelista sille merkityksettömän, ellei LAN-reititin ole se, joka tunneloi. Lakkasin käsittelemästä VM:ää VPN:ssä olevana ja aloin käsitellä sitä kysymyksenä siitä, mihin kyseisen vieraan oletusreitti osoittaa. Alla oleva testi vie muutaman minuutin tilaa kohti ja ratkaisee asian arvailematta.

NAT pitää vieraan hypervisorin koodin takana, missä isännän reitit pätevät

VirtualBoxissa NAT-vieras istuu osoitteessa 10.0.2.0/24, virtuaalinen yhdyskäytävä on 10.0.2.2, DNS-välityspalvelin 10.0.2.3, eikä sillä ole omaa reittiä fyysiseen verkkoon. Lähtevät paketit ottaa NAT-moottori, ne kirjoitetaan uudelleen niin, että lähde on isäntä, ja ne annetaan isännän IP-pinolle. Siitä eteenpäin vieraan liikenne on isännän virta, ja reittihaku tapahtuu kohteen mukaan: täystunnelin asiakas, joka asentaa 0.0.0.0/1 ja 128.0.0.0/1 isännälle, nappaa sen koskaan tietämättä, että VM on olemassa. Oraclen VirtualBoxin verkkoluku luettelee nämä oletusarvot, jos haluat vahvistaa osoitteet omassa asennuksessasi.

libvirtin oletusverkko saavuttaa saman paikan osoitteesta 192.168.122.0/24, jossa dnsmasq jakaa vuokrauksia ja isäntä maskaa aliverkon, joten vieraan paketit saapuvat jälleen isännän reitityspäätökseen. Poikkeus on asiakas, joka valitsee liikenteen prosessin eikä reitin mukaan. Jos jaetun tunnelin lista sisältää vain selaimen eikä mitään muuta, NAT-moottori ei ole sillä listalla, ja vieras lähtee koneesta tunnelitta, samalla kun isännän selain näyttää yhä katetulta. Sama aliverkko, vastakkainen tulos.

Sillattu antaa vieraalle oman paikkansa fyysisessä LANissa

Sillatulle vieraalle annetaan virtuaalinen verkkokortti, joka on kytketty oikeaan sovittimeen, se saa oman MAC-osoitteensa ja ottaa DHCP-vuokrauksen fyysisestä verkosta. Sen oletusyhdyskäytävä on LAN-reititin, ei hypervisor, ja sen kehykset menevät kaapeliin tuon sovittimen kautta. Isännän tunnelireitit ovat isännän taulukossa eikä niiltä koskaan kysytä, koska vieraan kehykset eivät koskaan päädy isännän IP-pinoon.

Se leikkaa molempiin suuntiin. mDNS ja SMB-selaus alkavat toimia, koska vieras näkee LANin lähetysliikennettä, ja vieraaseen pääsee muista saman segmentin koneista ilman isännän palomuuria välissä. Sillaus ei ole myöskään tapa työntää vieras olemassa olevan tunnelin läpi: VM:n kytkeminen isännän WireGuard- tai OpenVPN-rajapintaan ei ole jotain, minkä VirtualBox tai libvirt tekisi puolestasi. Jos sillatun vieraan on kuljettava tunnelin läpi, tunnelin on päätyttävä jonnekin siihen LANiin.

Testi, joka lopettaa väittelyn

Aja samat tarkistukset molemmissa tiloissa ja kirjoita vastaukset ylös:

  • Isännällä curl -s https://ifconfig.me antaa julkisen v4-osoitteen.
  • Vieraassa sama komento sekä ip route Linuxissa tai Get-NetRoute -DestinationPrefix 0.0.0.0/0 Windowsissa oletusyhdyskäytävää varten.
  • Nimipalvelimen identiteetti: resolvectl status tai cat /etc/resolv.conf vieraassa, jotta näet osoittaako se 10.0.2.3:een vai LAN-palvelimeen.
  • Osoiteperhe: ip -6 addr show scope global ja yksi v6-pyyntö, koska v4-tunneli ei kerro mitään globaalista v6-osoitteesta, joka vieraalla voi olla.

Yhtenevät julkiset osoitteet tarkoittavat, että vieras on isännän polulla. Vieraan osoite, joka vastaa LANin tavallista ulostuloa, tarkoittaa, ettei ole. Vaihe, jonka ihmiset ohittavat, on kontrolli: ota isännän tunneli alas ja toista vieraan pyyntö. Jos vieras jatkaa selaamista, se ei koskaan riippunut isännän tunnelista, mitä tilan nimi sitten vihjaileekaan. NAT-tilassa vieraan pitäisi menettää internet, kun isännän tunneli on alhaalla, ellei asiakas ole määritetty sallimaan tunnelitonta liikennettä, mikä kannattaa tietää ihan sellaisenaan.

Kaksi signaalia valehtelee. Onnistunut ping todistaa tavoitettavuuden, ei ulostulopolkua. Ja DNS voi vastata 10.0.2.3-välityspalvelin isännän nimipalvelimen kautta, samalla kun TCP ottaa toisen reitin, ja niin saat sivun, joka latautuu, ja kirjautumisen, joka ei koskaan valmistu.

Mikä tila sopii tehtävään

Tila on reitityspäätös, joten valitse se vaatimuksesta etkä tavasta:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

Ensimmäinen rivi on paikka, jossa ihmiset jäävät kiinni: NAT plus täystunnelin isäntäasiakas kattaa vieraan, mutta vain niin kauan kuin asiakas tunneloi reitin mukaan ja isännän yhteys on tuo tunneli. Siirrä asiakas vain selaimen sallivalle listalle ja kate katoaa ilman virhettä missään. Neljäs rivi on päinvastainen virhe: mukavuuden vuoksi sillattu vieras, joka alkaa hiljaa vastata SMB:hen tai SSH:hen toimiston LANissa.

Viat, jotka kaadetaan VPN:n niskaan

Windowsissa NAT-käännös ajetaan VirtualBoxin VM-prosessin sisällä, joten sovelluskohtainen asiakas tarvitsee juuri sen imagen listalleen eikä yleissääntöä virtuaalikoneille. Kun asiakaspäivitys rakentaa prosessilistansa uudelleen, NAT-vieraat menettävät katteen ensimmäisinä, ja raportti kuulostaa VM:ltä, joka tavoittaa LANin mutta ei internetiä, samalla kun isäntä on kunnossa.

Sillaus Wi-Fiin on toinen klassikko. Tukiasemat välittävät harvoin kehyksiä, joissa on vieras lähde-MAC, joten silta wlan0:aan joko epäonnistuu kokonaan tai toimii, kunnes AP:n asiakaseristys alkaa pudottaa sitä. VirtualBox tarjoaa langattoman sovittimen silti listallaan. Jos isäntä on Wi-Fi:ssä ja vieras on sillattava, suunnittele testaavasi se sen sijaan että olettaisit.

MTU on kolmas. Sillattu vieras pitää LANin 1500 tavun MTUn, ja jos se ajaa omaa WireGuard-asiakastaan 1420:ssa, suuret TLS-kättelyt pysähtyvät pienten pyyntöjen onnistuessa. NATin alla isännän tunnelin MTU on isännän ongelma, mutta vieras uskoo yhä 1500:aan, ja UDP don't-fragment-bitti asetettuna katoaa samalla tavalla.

Kirjaa tila ja tarkista uudelleen jokaisen sovitinmuutoksen jälkeen

Kirjaa tila, isäntärajapinta jota silta käyttää, vieraan oletusyhdyskäytävä, sen nimipalvelin sekä sen v4- ja v6-ulostulo-osoitteet. Juuri tuo kirjaus tekee seuraavasta viasta halvan: kun kannettava siirtyy telakasta Wi-Fiin, sillattu vieras seuraa siltaa toiseen fyysiseen sovittimeen ja voi saada vuokrauksen toiseen aliverkkoon, kun taas NAT-vieras pitää 10.0.2.x-osoitteensa ja perii hiljaa toisen yhteyden.

Ennen kuin suljet tiketin, vahvista jokainen näistä:

  • Vieraan ulostulo-osoite eroaa isännän ulostulo-osoitteesta, joten se ei ole isännän tunnelissa.
  • Nimipalvelin on 10.0.2.3-välityspalvelin tai LAN-palvelin, ja tiedät kumpi vastasi.
  • Vieraassa ei ole globaalia v6-osoitetta, jos tunnelin suunnittelu on vain v4.
  • Kun isännän tunneli on alhaalla, vieras lopettaa selaamisen, tai tiedät nyt, ettei se koskaan riippunut siitä.
  • Vieras ei näe LANin lähetysliikennettä, joka ei sille kuulu.

Aiheeseen liittyvät artikkelit