VirtualBox NAT aŭ ponto: kie finiĝas la VPN de la VM

Du malsamaj demandoj alvenas kune ĉiufoje, kiam virtuala maŝino rulas VPN-klienton, kaj ili havas malsamajn respondojn. La unua estas, ĉu tunelo ene de la gasto protektas la gastiganton, kaj la dua estas, ĉu tunelo sur la gastiganto kovras la gaston. La adaptila reĝimo decidas ambaŭ, pli ol la VPN-programaro. NAT-adaptilo faras la gastiganton la videbla finpunkto, dum ponta adaptilo metas la gaston en la reton kun propra adreso.

Kiu efektive finas la ĉifritan seancon

Ĉifrita seanco apartenas al la maŝino, kiu finas ĝin, kaj tio estas la gasto, kiam la kliento rulas ene de la VM. Nur trafiko, kiu eniras la virtualan adaptilon de la gasto, trapasas tiun tunelon, kaj la hipervizoro neniam mem direktas alian maŝinon tra la gasto. Tial la gasto povas teni funkciantan tunelon, dum la gastiganto foliumas en la malfermo. La malo ne estas simetria, kaj ĝuste tiu nesimetrio estas la parto, kiun plej multaj gvidiloj maltrafas.

Kies adreson la ekstera reto vidas estas la demando, kiun la adaptila reĝimo respondas. Post kiam tio estas solvita, kovrado ĉesas esti politika demando kaj fariĝas mekanika. Ĉio malsupre sekvas el tiuj du faktoj.

NAT reskribas la gaston ĝis ĝi similas al la gastiganto

Ĉe NAT, la hipervizoro reskribas ĉiun paketon de la gasto al la adreso de la gastiganto antaŭ ol ĝi atingas la unuan ŝaltilon. Tiu trafiko tiam estas transdonita al la propra reta stako de la gastiganto, kie ĝi sekvas lian enkursigan tabelon, inkluzive de defaŭlta vojo posedata de tunelo sur la gastiganto. NAT-gasto do estas kovrita de tunelo sur la gastiganto tute sen ajna agordo, kio estas la malo de tio, kion sugestas la kazo de gasto al gastiganto.

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

Gasto, kiu rulas propran klienton, finas tiun tunelon ene de la gasto, kaj la ĉifrita trafiko poste eliras tra la sama reskribo, do la aplikaĵoj de la gastiganto konservas sian propran vojon kaj sian propran eliran adreson. VirtualBox ankaŭ posedas nomrezoluciadon en ĉi tiu reĝimo, plusendante la demandojn de la gasto tra sia propra motoro krom se --natdnshostresolver1 estas ŝaltita. Ŝalti ĝin transdonas la serĉojn de la gasto al la solvilo de la gastiganto, kio riparas la rezoluciadon kiam la propra vidpunkto de la gastiganto estas ĝusta kaj same transdonas solvilon, kiu eble ekzistas nur ene de tunelo. La VM devas esti malŝaltita antaŭ ol ŝanĝi la agordon, kaj la agordo apartenas al la adaptilo, ne al la programaro de la gasto.

Ponto donas al la gasto propran luon kaj propran elmeton

Ponto plusendas la kadrojn de la gasto al la fizika segmento, do DHCP donas al ĝi luon kaj la reto traktas ĝin kiel apartan gastiganton. Ĉiu pontigita gasto povas teni sendependan tunelon kun propra defaŭlta vojo, kaj la tabelo de la gastiganto neniam ŝanĝiĝas. La prezo estas elmeto: la gasto respondas al dissendoj, aperas en tabeloj de najbaroj kaj submetiĝas al havena sekureco de la ŝaltilo kaj izolado de sendrataj klientoj. Tunelo sur la gastiganto ankaŭ ne kovras ĉi tiun aranĝon, ĉar la kadroj de la gasto neniam trapasas la stakon de la gastiganto.

Tiu diferenco rilate al la NAT-kazo indas esti dirita malkaŝe anstataŭ resti kiel implicaĵo. Pontigita gasto bezonas propran klienton kaj proprajn akreditaĵojn ĉiufoje, kiam ĝia trafiko devas uzi tunelon. Kie la gasto devas resti nevidebla al la loka reto, NAT aŭ reto nur ena kun kontrolita enkursigado estas la pli bona dezajno.

Kial la gasto ne povas esti la kluzo de la gastiganto

Presti la tunelon de gasto al la gastiganto ne havas subtenatan ŝaltilon en nek unu el la du grandaj hipervizoroj. La gastiganto havas neniun vojon en la tunelon de la gasto kaj neniun tradukan regulon montrantan al ĝi, do la trafiko de gasto kaj gastiganto restas apartaj fluoj kun apartaj posedantoj. Tiu direkto malsukcesas sendepende de la adaptila reĝimo.

La uzeblaj anstataŭoj estas plusendoj kaj prokuraj servoj. Loka SSH-plusendo permesas al la gastiganto konekti al sia propra loopback dum la gasto portas la fluon en la tunelon, kio kovras TCP-servojn sen instali duan klienton. Igi la propran IP-trafikon de la gastiganto uzi la tunelon de la gasto anstataŭe postulas enkursigilon ene de la gasto plus eksplicitan vojon sur la gastiganto kaj tradukon sur la gastiganto. Tio estas malgranda reta dezajno, ne markobutono, kaj ĝi postulas planon por la revena vojo. Kiam la gasto ekzistas nur por ruli la klienton, metu la klienton sur la gastiganton kaj forigu la kroman salton.

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

Solviloj kaj vojoj ne transiras la limon

DNS sekvas la adaptilon, kiu ricevis la opcion, do gasto ne heredas la tunelan solvilon de la gastiganto kaj gastiganto neniam ekscias la servilon puŝitan al la gasto. Puŝitaj valoroj dhcp-option DNS validas por la interfaco, kiu akceptis ilin, kaj tial pontigita gasto sen kliento ne povas solvi internajn nomojn. NAT-gasto kutime uzas la DNS-traktadon de la hipervizoro anstataŭe, kaj la diferenco montriĝas en unu komando por ĉiu medio.

# 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

Legu la solvilon kaj la vojon ene de la gasto antaŭ ol supozi, ke iu el ili sekvas la gastiganton. Aldonu la tunelan solvilon al la propra adaptilo de la gasto, kiam internaj nomoj devas esti solvataj tie, poste kontrolu per nomo, kiu ekzistas nur malantaŭ la tunelo. Notu la adaptilan reĝimon, la posedanton de la tunelo kaj la fonton de la solvilo por ĉiu VM, ĉar tiuj tri faktoj respondas preskaŭ ĉiun postan demandon. Aliaj hipervizoroj renomas la reĝimojn kaj lasas la principon netuŝita.