VirtualBox NAT või sild: kus VM-i VPN lõpeb

Kaks erinevat küsimust tulevad korraga alati, kui virtuaalmasin käivitab VPN-kliendi, ja neil on erinevad vastused. Esimene on, kas külalise sees olev tunnel kaitseb hosti, ja teine on, kas hostil olev tunnel katab külalise. Adapteri režiim otsustab mõlemad, rohkem kui VPN-tarkvara ise. NAT-adapter teeb hostist nähtava lõpp-punkti, samas kui sillatud adapter paneb külalise võrku oma aadressiga.

Kes krüpteeritud seansi tegelikult lõpetab

Krüpteeritud seanss kuulub masinale, mis selle lõpetab, ja see on külaline, kui klient töötab VM-i sees. Sellest tunnelist läbib ainult liiklus, mis siseneb külalise virtuaalsesse adapterisse, ja hüpervisor ei suuna kunagi ise teist masinat külalise kaudu. Seetõttu saab külaline hoida töötavat tunnelit, samal ajal kui host sirvib avatud võrgus. Vastupidine ei ole sümmeetriline, ja just see asümmeetria on osa, mille enamik juhendeid valesti esitab.

Millist aadressi välisvõrk näeb, on küsimus, millele adapteri režiim vastab. Kui see on selge, lakkab katvus olemast poliitikaküsimus ja muutub mehaaniliseks. Kõik alljärgnev tuleneb neist kahest faktist.

NAT kirjutab külalise ümber, kuni see näeb välja nagu host

NAT-i korral kirjutab hüpervisor iga külalise paketi ümber hosti aadressile enne, kui see jõuab esimese kommutaatorini. See liiklus antakse seejärel hosti enda võrgupinule, kus see järgib hosti marsruutimistabelit, sealhulgas vaikimisi marsruuti, mis kuulub hostil olevale tunnelile. Seega on NAT-külaline kaetud hostil oleva tunneliga täiesti ilma konfiguratsioonita, mis on vastupidine sellele, mida vihjab juhtum külalisest hosti suunas.

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

Külaline, mis käivitab oma kliendi, lõpetab selle tunneli külalise sees, ja krüpteeritud liiklus väljub seejärel sama ümberkirjutuse kaudu, nii et hosti rakendused hoiavad oma teed ja oma väljumisaadressi. VirtualBox omab selles režiimis ka nimelahendust, suunates külalise päringud oma mootori kaudu, välja arvatud juhul, kui --natdnshostresolver1 on lubatud. Selle lubamine annab külalise otsingud hosti resolverile, mis parandab lahenduse siis, kui hosti enda vaade on õige, ja annab samavõrd üle resolveri, mis võib eksisteerida ainult tunneli sees. VM tuleb enne seade muutmist välja lülitada, ja seade kuulub adapterile, mitte külalise tarkvarale.

Sild annab külalisele oma rendi ja oma nähtavuse

Sild viib külalise kaadrid füüsilisele segmendile, nii et DHCP annab talle rendi ja võrk kohtleb teda eraldi hostina. Iga sillatud külaline võib hoida iseseisvat tunnelit oma vaikimisi marsruudiga, ja hosti tabel ei muutu kunagi. Hind on nähtavus: külaline vastab ringhäälingule, ilmub naabritabelitesse ja satub kommutaatori pordi turvalisuse ning traadita klientide isolatsiooni alla. Hostil olev tunnel ei kata ka seda lahendust, sest külalise kaadrid ei läbi kunagi hosti pinu.

See erinevus NAT-i juhtumist tasub otse välja öelda, mitte jätta vihjeks. Sillatud külaline vajab oma klienti ja oma volitusi alati, kui tema liiklus peab tunnelit kasutama. Kui külaline peab jääma kohalikule võrgule nähtamatuks, on NAT või ainult sisemine kontrollitud marsruutimisega võrk parem lahendus.

Miks ei saa külaline olla hosti lüüs

Külalise tunneli laenamisel hostile puudub toetatud lüliti mõlemas suures hüpervisoris. Hostil ei ole marsruuti külalise tunnelisse ega tõlkereeglit, mis sinna osutaks, nii et külalise ja hosti liiklus jäävad eraldi voogudeks eraldi omanikega. See suund ebaõnnestub sõltumata adapteri režiimist.

Toimivad asendused on edasisaatmised ja puhverserverid. SSH kohalik edasisaatmine laseb hostil ühenduda oma loopbackiga, samal ajal kui külaline kannab voo tunnelisse, mis katab TCP-teenuseid ilma teise kliendi paigaldamiseta. Host enda IP-liikluse panemine hoopis külalise tunnelit kasutama nõuab marsruuterit külalise sees pluss selgesõnalist marsruuti hostil ja tõlget hostil. See on väike võrgukujundus, mitte märkeruut, ja see nõuab plaani tagasitee jaoks. Kui külaline on olemas ainult kliendi käitamiseks, pane klient hostile ja kustuta lisahüpe.

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

Resolverid ja marsruudid ei ületa piiri

DNS järgib adapterit, mis valiku vastu võttis, nii et külaline ei päri hosti tunneli resolverit ja host ei saa kunagi teada külalisele lükatud serverit. Lükatud dhcp-option DNS väärtused kehtivad liidesele, mis need vastu võttis, ja seetõttu ei saa sillatud klientideta külaline sisemisi nimesid lahendada. NAT-külaline kasutab tavaliselt hoopis hüpervisori DNS-käsitlust, ja erinevus ilmneb ühe käsuga keskkonna kohta.

# 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

Loe resolver ja marsruut külalise sees enne, kui eeldad, et kumbki järgib hosti. Lisa tunneli resolver külalise enda adapterile, kui sisemised nimed tuleb seal lahendada, ja kontrolli seejärel nimega, mis eksisteerib ainult tunneli taga. Kirjuta iga VM-i kohta üles adapteri režiim, tunneli omanik ja resolveri allikas, sest need kolm fakti vastavad peaaegu igale hilisemale küsimusele. Teised hüpervisorid nimetavad režiimid ümber ja jätavad põhimõtte puutumata.