VirtualBox NAT o bridge: saan nagtatapos ang VPN ng VM

Dalawang magkaibang tanong ang dumarating nang sabay sa tuwing nagpapatakbo ang isang virtual machine ng kliyente ng VPN, at magkaiba ang kanilang sagot. Ang una ay kung pinoprotektahan ng tunnel sa loob ng bisita ang host, at ang pangalawa ay kung tinatakpan ng tunnel sa host ang bisita. Ang mode ng adapter ang nagpapasya sa dalawa, higit pa sa software ng VPN mismo. Ginagawang nakikitang dulo ng adapter na NAT ang host, habang inilalagay ng adapter na bridge ang bisita sa network kasama ang sariling address nito.

Sino talaga ang nagtatapos ng naka-encrypt na sesyon

Ang naka-encrypt na sesyon ay pag-aari ng makina na nagtatapos nito, at iyon ang bisita kapag tumatakbo ang kliyente sa loob ng VM. Tanging ang trapikong pumapasok sa virtual adapter ng bisita ang dumadaan sa tunnel na iyon, at hindi kailanman nagruruta ang hypervisor ng ibang makina sa pamamagitan ng bisita nang kusa. Kaya nakapagpapanatili ang bisita ng gumaganang tunnel habang nagba-browse ang host sa bukas. Hindi simetriko ang kabaligtaran, at ang asimetriyang iyon ang bahaging madalas mali sa mga gabay.

Kaninong address ang nakikita ng panlabas na network ang tanong na sinasagot ng mode ng adapter. Kapag naayos na iyon, hindi na isyu ng patakaran ang saklaw at nagiging mekanikal na. Lahat ng nasa ibaba ay nagmumula sa dalawang katotohanang iyon.

Isinusulat muli ng NAT ang bisita hanggang magmukhang host

Sa NAT, isinusulat muli ng hypervisor ang bawat packet ng bisita sa address ng host bago ito umabot sa unang switch. Ang trapikong iyon ay ibinibigay pagkatapos sa sariling stack ng network ng host, kung saan sinusunod nito ang talahanayan ng ruta ng host, kasama ang default na ruta na pag-aari ng isang tunnel sa host. Kaya ang bisitang NAT ay natatakpan ng tunnel sa host nang walang anumang konfigurasyon, na kabaligtaran ng ipinahihiwatig ng kaso mula bisita patungong host.

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

Ang bisitang nagpapatakbo ng sariling kliyente ay nagtatapos ng tunnel na iyon sa loob ng bisita, at ang naka-encrypt na trapiko ay lumalabas sa pamamagitan ng parehong muling pagsulat, kaya pinapanatili ng mga aplikasyon ng host ang sariling landas at sariling address ng labasan. Pag-aari din ng VirtualBox ang resolusyon ng pangalan sa mode na ito, at ipinapasa ang mga query ng bisita sa sariling engine maliban kung naka-enable ang --natdnshostresolver1. Kapag inenable ito, ibinibigay ang mga paghahanap ng bisita sa resolver ng host, na nag-aayos ng resolusyon kapag tama ang sariling pananaw ng host at gayundin nagbibigay ng resolver na maaaring umiiral lamang sa loob ng tunnel. Kailangang patayin ang VM bago baguhin ang setting, at ang setting ay pag-aari ng adapter hindi ng software ng bisita.

Binibigyan ng bridge ang bisita ng sariling lease at sariling pagkakalantad

Ipinapasa ng bridge ang mga frame ng bisita sa pisikal na segment, kaya binibigyan ito ng DHCP ng lease at tinatrato ito ng network bilang hiwalay na host. Ang bawat bridged na bisita ay maaaring humawak ng malayang tunnel na may sariling default na ruta, at hindi kailanman nagbabago ang talahanayan ng host. Ang halaga ay pagkakalantad: sumasagot ang bisita sa mga broadcast, lumilitaw sa mga talahanayan ng kapitbahay, at napapailalim sa seguridad ng port ng switch at paghihiwalay ng wireless na kliyente. Hindi rin tinatakpan ng tunnel sa host ang kaayusang ito, dahil hindi kailanman dumadaan ang mga frame ng bisita sa stack ng host.

Ang pagkakaibang iyon sa kaso ng NAT ay dapat sabihin nang tuwiran sa halip na iwanan bilang implikasyon. Ang bridged na bisita ay nangangailangan ng sariling kliyente at sariling kredensyal sa tuwing kailangang gumamit ng tunnel ang trapiko nito. Kung saan dapat manatiling di-nakikita ang bisita sa lokal na network, ang NAT o network na panloob lamang na may kontroladong rutahan ang mas mabuting disenyo.

Bakit hindi maaaring maging gateway ng host ang bisita

Ang pagpapahiram ng tunnel ng bisita sa host ay walang sinusuportahang switch sa alinman sa dalawang malalaking hypervisor. Walang ruta ang host papasok sa tunnel ng bisita at walang tuntunin ng pagsasalin na tumuturo doon, kaya nananatiling magkahiwalay na daloy ang trapiko ng bisita at ng host na may magkahiwalay na may-ari. Nabigo ang direksyong iyon anuman ang mode ng adapter.

Ang magagamit na kahalili ay mga forward at proxy. Ang lokal na forward ng SSH ay nagbibigay-daan sa host na kumonekta sa sariling loopback habang dinadala ng bisita ang daloy papasok sa tunnel, na sumasaklaw sa mga serbisyong TCP nang hindi nag-i-install ng pangalawang kliyente. Ang gawing gamitin ng sariling trapikong IP ng host ang tunnel ng bisita sa halip ay nangangailangan ng router sa loob ng bisita at ng malinaw na ruta sa host at pagsasalin sa host. Iyon ay maliit na disenyo ng network at hindi isang kahon ng tseke, at nangangailangan ito ng plano para sa pabalik na daan. Kapag ang bisita ay umiiral lamang upang patakbuhin ang kliyente, ilagay ang kliyente sa host at alisin ang dagdag na pagtalon.

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

Hindi tumatawid ng hangganan ang mga resolver at ruta

Sinusundan ng DNS ang adapter na tumanggap ng opsyon, kaya hindi namamana ng bisita ang resolver ng tunnel ng host at hindi kailanman nalalaman ng host ang server na itinulak sa bisita. Ang mga itinulak na halaga ng dhcp-option DNS ay nalalapat sa interface na tumanggap sa mga ito, at iyon ang dahilan kung bakit ang bridged na bisita na walang kliyente ay hindi makapag-resolve ng mga panloob na pangalan. Ang bisitang NAT ay karaniwang gumagamit ng paghawak ng DNS ng hypervisor, at makikita ang pagkakaiba sa isang utos bawat kapaligiran.

# 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

Basahin ang resolver at ruta sa loob ng bisita bago ipagpalagay na sinusundan ng alinman sa mga ito ang host. Idagdag ang resolver ng tunnel sa sariling adapter ng bisita kapag kailangang i-resolve doon ang mga panloob na pangalan, pagkatapos ay tiyakin gamit ang pangalang umiiral lamang sa likod ng tunnel. Itala ang mode ng adapter, may-ari ng tunnel at pinagmulan ng resolver para sa bawat VM, dahil sinasagot ng tatlong katotohanang iyon ang halos lahat ng susunod na tanong. Binabago ng ibang hypervisor ang mga pangalan ng mode at iniiwang buo ang prinsipyo.