VirtualBox NAT sau bridge: unde se termină VPN-ul mașinii virtuale

Două întrebări diferite apar împreună de fiecare dată când o mașină virtuală rulează un client VPN, iar răspunsurile lor diferă. Prima este dacă un tunel din interiorul oaspetelui protejează gazda, iar a doua este dacă un tunel pe gazdă acoperă oaspetele. Modul adaptorului le decide pe amândouă, mai mult decât software-ul VPN în sine. Un adaptor NAT face gazda punctul final vizibil, în timp ce un adaptor bridge pune oaspetele în rețea cu propria adresă.

Cine încheie de fapt sesiunea criptată

O sesiune criptată aparține mașinii care o încheie, iar aceea este oaspetele când clientul rulează în VM. Prin acel tunel trece doar traficul care intră în adaptorul virtual al oaspetelui, iar hipervizorul nu direcționează niciodată singur o altă mașină prin oaspete. De aceea oaspetele poate ține un tunel funcțional în timp ce gazda navighează în clar. Inversul nu este simetric, iar această asimetrie este partea pe care majoritatea ghidurilor o greșesc.

Ce adresă vede rețeaua exterioară este întrebarea la care răspunde modul adaptorului. Odată lămurit acest lucru, acoperirea încetează să fie o chestiune de politică și devine mecanică. Tot ce urmează decurge din aceste două fapte.

NAT rescrie oaspetele până când arată ca gazda

Cu NAT, hipervizorul rescrie fiecare pachet al oaspetelui către adresa gazdei înainte ca acesta să ajungă la primul comutator. Acel trafic este apoi predat stivei de rețea a gazdei, unde urmează tabela ei de rutare, inclusiv o rută implicită deținută de un tunel pe gazdă. Un oaspete NAT este deci acoperit de un tunel pe gazdă fără nicio configurare, ceea ce este opusul a ceea ce sugerează cazul de la oaspete la gazdă.

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

Un oaspete care rulează propriul client încheie acel tunel în interiorul oaspetelui, iar traficul criptat iese apoi prin aceeași rescriere, astfel încât aplicațiile gazdei își păstrează propria cale și propria adresă de ieșire. VirtualBox deține în acest mod și rezolvarea numelor, trimițând interogările oaspetelui prin propriul motor dacă --natdnshostresolver1 nu este activat. Activarea îi predă căutările oaspetelui resolverului gazdei, ceea ce corectează rezolvarea când imaginea gazdei este corectă și, tot la fel, predă un resolver care poate exista doar în interiorul unui tunel. VM-ul trebuie oprit înainte de schimbarea setării, iar setarea aparține adaptorului, nu software-ului oaspetelui.

Bridge îi dă oaspetelui propria concesiune și propria expunere

Bridge trece cadrele oaspetelui în segmentul fizic, așa că DHCP îi dă o concesiune și rețeaua îl tratează ca pe o gazdă separată. Fiecare oaspete conectat în bridge poate ține un tunel independent cu propria rută implicită, iar tabela gazdei nu se schimbă niciodată. Prețul este expunerea: oaspetele răspunde la difuzări, apare în tabelele vecinilor și intră sub securitatea porturilor comutatorului și izolarea clienților wireless. Nici un tunel pe gazdă nu acoperă această configurație, pentru că datele oaspetelui nu trec niciodată prin stiva gazdei.

Această diferență față de cazul NAT merită spusă deschis, nu lăsată ca implicație. Un oaspete conectat în bridge are nevoie de propriul client și de propriile acreditări ori de câte ori traficul său trebuie să folosească un tunel. Acolo unde oaspetele trebuie să rămână invizibil pentru rețeaua locală, NAT sau o rețea doar internă cu rutare controlată este proiectul mai bun.

De ce oaspetele nu poate fi gateway-ul gazdei

Împrumutarea tunelului unui oaspete către gazdă nu are niciun comutator acceptat în niciunul dintre cele două hipervizoare mari. Gazda nu are rută în tunelul oaspetelui și nicio regulă de traducere care să indice spre el, așa că traficul oaspetelui și al gazdei rămân fluxuri separate cu proprietari separați. Acea direcție eșuează indiferent de modul adaptorului.

Înlocuitorii funcționali sunt redirecționările și proxy-urile. O redirecționare locală SSH permite gazdei să se conecteze la propriul loopback în timp ce oaspetele duce fluxul în tunel, ceea ce acoperă servicii TCP fără a instala un al doilea client. A face traficul IP propriu al gazdei să folosească tunelul oaspetelui în schimb necesită un router în interiorul oaspetelui, plus o rută explicită pe gazdă și traducere pe gazdă. Acesta este un proiect de rețea mic și nu o bifă, și are nevoie de un plan pentru calea de întoarcere. Când oaspetele există doar ca să ruleze clientul, pune clientul pe gazdă și elimină saltul suplimentar.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Resolverii și rutele nu trec granița

DNS-ul urmează adaptorul care a primit opțiunea, așa că un oaspete nu moștenește resolverul tunelului gazdei, iar gazda nu află niciodată serverul împins oaspetelui. Valorile dhcp-option DNS împinse se aplică interfeței care le-a acceptat, și de aceea un oaspete conectat în bridge fără client nu poate rezolva nume interne. Un oaspete NAT folosește de obicei gestionarea DNS a hipervizorului, iar diferența se vede într-o singură comandă pe mediu.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

Citește resolverul și ruta din interiorul oaspetelui înainte de a presupune că vreunul urmează gazda. Adaugă resolverul tunelului la adaptorul propriu al oaspetelui când numele interne trebuie rezolvate acolo, apoi verifică cu un nume care există doar în spatele tunelului. Notează modul adaptorului, proprietarul tunelului și sursa resolverului pentru fiecare VM, pentru că aceste trei fapte răspund la aproape orice întrebare ulterioară. Alte hipervizoare redenumesc modurile și lasă principiul intact.