NAT või sillatud VM-võrk: kumb kannab VPN-liiklust?
NAT-külalised laenavad hosti tunnelit ainult siis, kui klient tunneleb marsruudi järgi; sillatud külalised marsruudivad ise. Testi külalist ja vali siis sobiv režiim.
Sildamine ja NAT ei ole kaks viisi, kuidas sama külaline sinu VPN-iga ühendada; need otsustavad, kellele kuuluvad külalise paketid enne, kui tunnel mängu tuleb. NAT-režiimis kirjutab hüpervisor külalise liikluse ümber ja saadab selle hostipoolsest koodist, nii et külaline sõidab marsruudil, mille host sellele koodile annab. Sillatud režiimis saab külaline füüsilisel segmendil oma link-kihi identiteedi ja valib ise oma vaikimisi lüüsi, mis teeb hosti tunneli tema jaoks ebaoluliseks, välja arvatud juhul, kui LAN-i ruuter on see, mis tunneleb. Ma lõpetasin VM-i käsitlemise VPN-is olevana ja hakkasin seda käsitlema küsimusena, kuhu selle külalise vaikimisi marsruut osutab. Allpool olev test võtab režiimi kohta paar minutit ja lahendab asja ilma oletusteta.
NAT hoiab külalist hüpervisori koodi taga, kus kehtivad hosti marsruudid
VirtualBoxis istub NAT-külaline aadressil 10.0.2.0/24, virtuaalse lüüsiga 10.0.2.2, DNS-puhverserveriga 10.0.2.3 ja ilma oma marsruudita füüsilisse võrku. Väljuvad paketid võtab NAT-mootor, kirjutab need ümber nii, et allikaks on host, ja annab need hosti IP-kihile. Sealt edasi on külalise liiklus hosti voog ja marsruudi otsing toimub sihtkoha järgi: täistunneli klient, mis paigaldab hosti 0.0.0.0/1 ja 128.0.0.0/1, püüab selle kinni, teadmata kunagi, et VM on olemas. Oracle'i VirtualBoxi võrgustiku peatükk loetleb need vaikeväärtused, kui tahad oma koostes aadresse kinnitada.
libvirti vaikevõrk jõuab samasse kohta aadressilt 192.168.122.0/24, kus dnsmasq jagab liise ja host maskeerib alamvõrgu, nii et külalise paketid jõuavad jälle hosti marsruutimisotsuseni. Erandiks on klient, mis valib liiklust protsessi, mitte marsruudi järgi. Kui split-tunneli nimekiri sisaldab ainult sinu brauserit ja mitte midagi muud, ei ole NAT-mootor selles nimekirjas ja külaline lahkub masinast tunnelita, samal ajal kui hosti brauser näib endiselt kaetud. Sama alamvõrk, vastupidine tulemus.
Sildamine annab külalisele oma koha füüsilises LAN-is
Sillatud külaline saab virtuaalse võrguadapteri, mis on kinnitatud pärisadapteri külge, omandab oma MAC-aadressi ja võtab füüsilisest võrgust DHCP-liisi. Tema vaikimisi lüüs on LAN-i ruuter, mitte hüpervisor, ja tema kaadrid lähevad selle adapteri kaudu juhtmele. Hosti tunnelimarsruudid elavad hosti tabelis ja neid ei küsita kunagi, sest külalise kaadrid ei jõua kunagi hosti IP-kihile.
See lõikab mõlemas suunas. mDNS ja SMB-brausimine hakkavad tööle, sest külaline näeb LAN-i ringhäälingu liiklust, ja külaline muutub teistest samas segmendis olevatest masinatest kättesaadavaks ilma hosti tulemüüri vahel. Sildamine ei ole ka viis, kuidas külalist olemasolevast tunnelist läbi suruda: VM-i kinnitamine hosti WireGuard- või OpenVPN-liidese külge ei ole midagi, mida VirtualBox või libvirt sinu eest teeb. Kui sillatud külaline peab tunnelist läbi minema, peab tunnel kuskil selles LAN-is lõppema.
Test, mis vaidluse lõpetab
Käivita samad kontrollid mõlemas režiimis ja kirjuta vastused üles:
- Hostis annab
curl -s https://ifconfig.meavaliku v4-aadressi. - Külalises sama käsk, pluss
ip routeLinuxis võiGet-NetRoute -DestinationPrefix 0.0.0.0/0Windowsis vaikimisi lüüsi jaoks. - Resolveerija identiteet:
resolvectl statusvõicat /etc/resolv.confkülalises, et näha, kas see osutab 10.0.2.3-le või LAN-i serverile. - Aadressiperekond:
ip -6 addr show scope globalja üks v6-päring, sest v4-tunnel ei ütle midagi globaalse v6-aadressi kohta, mis külalisel võib olla.
Kattuvad avalikud aadressid tähendavad, et külaline on hosti teel. Külalise aadress, mis kattub LAN-i tavalise väljundiga, tähendab, et ei ole. Samm, mille inimesed vahele jätavad, on kontroll: võta hosti tunnel maha ja korda külalise päringut. Kui külaline jätkab brausimist, ei sõltunud ta kunagi hosti tunnelist, mida iganes režiimi nimi vihjab. NAT-režiimis peaks külaline hosti tunneli maas olles interneti kaotama, kui klient pole just seadistatud lubama tunnelita liiklust, mida tasub iseenesest teada.
Kaks signaali valetavad. Õnnestunud ping tõestab kättesaadavust, mitte väljundteed. Ja DNS-i võib vastata 10.0.2.3 puhverserver hosti resolveerija kaudu, samal ajal kui TCP võtab teise marsruudi, nii saadki lehe, mis laeb, ja sisselogimise, mis ei lõpe kunagi.
Milline režiim tööga sobib
Režiim on marsruutimisotsus, seega vali see nõudest, mitte harjumusest:
| 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 |
Esimene rida on koht, kus inimesed vahele jäävad: NAT pluss täistunneli hostiklient katab külalise tõesti, aga ainult seni, kuni klient tunneleb marsruudi järgi ja hosti ühendus on see tunnel. Viige klient ainult brauseri lubatud nimekirja ja kate kaob ilma ühegi veata kusagil. Neljas rida on vastupidine viga: mugavusest sillatud külaline, mis hakkab vaikselt kontori LAN-is SMB-le või SSH-le vastama.
Tõrked, mida süüdistatakse VPN-is
Windowsis jookseb NAT-tõlge VirtualBoxi VM-protsessi sees, seega vajab rakendusepõhine klient oma nimekirjas täpselt seda pilti, mitte üldreeglit virtuaalmasinate kohta. Kui kliendi uuendus ehitab oma protsessinimekirja uuesti, kaotavad NAT-külalised katte esimesena ja aruanne kõlab nagu VM, mis jõuab LAN-i, aga mitte internetti, samal ajal kui host on korras.
Sildamine Wi-Fi peale on teine klassika. Pääsupunktid edastavad harva kaadreid võõra lähtemaciga, seega wlan0 peale tehtud sild kas ebaõnnestub täielikult või töötab seni, kuni AP kliendiisolatsioon selle maha viskab. VirtualBox pakub juhtmevaba adapterit ikka oma nimekirjas. Kui host on Wi-Fi peal ja külaline tuleb sillata, planeeri seda testida, mitte eeldada.
MTU on kolmas. Sillatud külaline hoiab LAN-i 1500-baidist MTU-d ja kui ta jooksutab oma WireGuardi klienti 1420 peal, jäävad suured TLS-käepigistused seisma, samal ajal kui väikesed päringud õnnestuvad. NAT-i all on hosti tunneli MTU hosti mure, aga külaline usub endiselt 1500-sse ja UDP seadistatud don't-fragment bitiga kaob samamoodi.
Kirjuta režiim üles ja kontrolli uuesti pärast iga adapterivahetust
Kirjuta üles režiim, hosti liides, mida sild kasutab, külalise vaikimisi lüüs, selle resolveerija ning selle v4- ja v6-väljundaadressid. Just see kirje teeb järgmise tõrke odavaks: kui sülearvuti liigub dokist Wi-Fi peale, järgneb sillatud külaline sillale teise füüsilise adapteri juurde ja võib saada liisi teises alamvõrgus, samal ajal kui NAT-külaline hoiab oma 10.0.2.x aadressi ja pärib vaikselt teise ühenduse.
Enne piletisulgemist kinnita iga järgnev punkt:
- Külalise väljundaadress erineb hosti väljundaadressist, seega ei ole ta hosti tunnelis.
- Resolveerija on 10.0.2.3 puhverserver või LAN-i server ja sa tead, milline vastas.
- Külalises ei ole ühtki globaalset v6-aadressi, kui tunneli kavand on ainult v4.
- Hosti tunneli maas olles lõpetab külaline brausimise, või tead nüüd, et ta ei sõltunud sellest kunagi.
- Külaline ei näe LAN-i ringhäälingu liiklust, mis teda ei puuduta.