NAT vs bridged na networking ng VM: alin ang nagdadala ng trapikong VPN?

Ang bridged at NAT ay hindi dalawang paraan ng pagkakabit ng parehong guest sa VPN mo; sila ang nagpapasya kung kanino ang mga packet ng guest bago pa man may tunnel na nasasangkot. Sa NAT mode, muling isinusulat ng hypervisor ang trapiko ng guest at inilalabas ito mula sa code sa panig ng host, kaya sumasakay ang guest sa rutang ibinibigay ng host sa code na iyon. Sa bridged mode, nakakakuha ang guest ng sariling identidad sa link layer sa pisikal na segment at pumipili ng sariling default gateway, kaya hindi na mahalaga sa kanya ang tunnel ng host, maliban kung ang router ng LAN mismo ang nagtu-tunnel. Tumigil ako sa pagtrato sa VM bilang nasa VPN at sinimulan kong tratuhin ito bilang tanong kung saan nakaturo ang default route ng guest na iyon. Ang pagsubok sa ibaba ay tumatagal ng ilang minuto bawat mode at nilulutas ito nang walang hula.

Hinihila ng NAT ang guest sa likod ng code ng hypervisor, kung saan umiiral ang mga ruta ng host

Sa VirtualBox, ang NAT guest ay nakaupo sa 10.0.2.0/24 na may virtual gateway sa 10.0.2.2, DNS proxy sa 10.0.2.3, at walang sariling ruta papunta sa pisikal na network. Ang mga papalabas na packet ay kinukuha ng NAT engine, muling isinusulat para ang pinagmulan ay ang host, at ipinapasa sa IP stack ng host. Mula doon, ang trapiko ng guest ay isang flow ng host, at ang paghahanap ng ruta ay ayon sa destinasyon: isang kliyenteng may buong tunnel na naglalagay ng 0.0.0.0/1 at 128.0.0.0/1 sa host ay nahuhuli ito nang hindi alam na may VM. Ang kabanata ng Oracle tungkol sa networking ng VirtualBox ay naglilista ng mga default na ito kung gusto mong kumpirmahin ang mga address sa build mo.

Ang default na network ng libvirt ay umabot sa parehong lugar mula sa 192.168.122.0/24, kung saan namimigay ng lease ang dnsmasq at hinihimas ng host ang subnet, kaya bumabalik ang mga packet ng guest sa desisyon sa ruta ng host. Ang eksepsiyon ay kliyenteng pumipili ng trapiko ayon sa proseso sa halip na ayon sa ruta. Kung ang listahan ng split tunnel ay may browser mo lamang, wala ang NAT engine sa listahang iyon, at lumalabas ang guest nang walang tunnel habang mukhang sakop pa rin ang browser sa host. Parehong subnet, kabaligtarang resulta.

Binibigyan ng bridged ang guest ng sariling lugar sa pisikal na LAN

Ang bridged guest ay binibigyan ng virtual NIC na nakakabit sa totoong adapter, nakakakuha ng sariling MAC address, at kumukuha ng DHCP lease mula sa pisikal na network. Ang default gateway niya ay ang router ng LAN, hindi ang hypervisor, at ang mga frame niya ay pumapasok sa wire sa pamamagitan ng adapter na iyon. Ang mga ruta ng tunnel ng host ay nasa talahanayan ng host at hindi kailanman kinukunsulta, dahil hindi kailanman pumapasok ang mga frame ng guest sa IP stack ng host.

Pumapatid ito sa dalawang direksyon. Nagsisimulang gumana ang mDNS at SMB browsing dahil nakikita ng guest ang broadcast trapiko ng LAN, at nagiging maabot ang guest mula sa ibang machine sa parehong segment nang walang firewall ng host sa gitna. Hindi rin paraan ang bridging para itulak ang guest sa umiiral nang tunnel: ang pagkakabit ng VM sa WireGuard o OpenVPN interface ng host ay hindi ginagawa ng VirtualBox o libvirt para sa iyo. Kung ang bridged guest ay kailangang i-tunnel, dapat magtapos ang tunnel sa isang lugar sa LAN na iyon.

Ang pagsubok na nagtatapos sa usapan

Patakbuhin ang parehong mga pagsusuri sa dalawang mode at isulat ang mga sagot:

• Sa host, curl -s https://ifconfig.me ibinibigay ang pampublikong address na v4.
• Sa guest, ang parehong command, dagdag ang ip route sa Linux o Get-NetRoute -DestinationPrefix 0.0.0.0/0 sa Windows para sa default gateway.
• Pagkakakilanlan ng resolver: resolvectl status o cat /etc/resolv.conf sa guest, para makita kung nakaturo ito sa 10.0.2.3 o sa isang server ng LAN.
• Pamilya ng address: ip -6 addr show scope global at isang kahilingang v6, dahil walang sinasabi ang v4 tunnel tungkol sa isang global na v6 address na maaaring taglayin ng guest.

Ang magkatugmang pampublikong address ay nangangahulugang nasa landas ng host ang guest. Ang address ng guest na tumutugma sa karaniwang labasan ng LAN ay nangangahulugang wala siya roon. Ang hakbang na nilalaktawan ng mga tao ay ang kontrol: ibaba ang tunnel ng host at ulitin ang kahilingan mula sa guest. Kung patuloy na nagba-browse ang guest, hindi siya kailanman umasa sa tunnel ng host, anuman ang sabihin ng pangalan ng mode. Sa NAT mode, dapat mawalan ng internet ang guest kapag nakababa ang tunnel ng host, maliban kung ang kliyente ay naka-configure na payagan ang trapikong labas ng tunnel, na mahalagang malaman sa sarili nito.

Dalawang senyales ang nagsisinungaling. Ang matagumpay na ping ay nagpapatunay ng maabot, hindi ng landas palabas. At ang DNS ay maaaring sagutin ng 10.0.2.3 proxy sa pamamagitan ng resolver ng host habang ang TCP ay kumukuha ng ibang ruta, at ganoon nakakakuha ka ng pahinang naglo-load at login na hindi kailanman natatapos.

Aling mode ang bagay sa gawain

Ang mode ay desisyon sa ruta, kaya piliin ito ayon sa pangangailangan at hindi ayon sa kinaugalian:

Ang unang hilera ang lugar kung saan nadadali ang mga tao: ang NAT kasama ang buong tunnel na kliyente sa host ay talagang sumasakop sa guest, pero hangga't nagtu-tunnel ang kliyente ayon sa ruta at ang uplink ng host ay ang tunnel na iyon. Ilipat ang kliyente sa listahang pinapayagan lamang ang browser at mawawala ang saklaw nang walang anumang error kahit saan. Ang ikaapat na hilera ang kabaligtarang pagkakamali, isang guest na binridged para sa kaginhawahan na tahimik nang sumasagot sa SMB o SSH sa LAN ng opisina.

Mga pagkabigo na isinasisi sa VPN

Sa Windows, ang NAT translation ay tumatakbo sa loob ng proseso ng VM ng VirtualBox, kaya kailangan ng per-app na kliyente ang eksaktong imaheng iyon sa listahan, hindi isang pangkalahatang tuntunin para sa mga virtual machine. Kapag ang update ng kliyente ay muling bumuo ng listahan ng pinapayagang proseso, nauuna ang mga NAT guest na mawalan ng saklaw, at ang ulat ay parang VM na nakakaabot sa LAN pero hindi sa internet habang maayos ang host.

Ang bridging papuntang Wi-Fi ang isa pang klasiko. Bihirang ipasa ng mga access point ang mga frame na may banyagang source MAC, kaya ang bridge papuntang wlan0 ay agad na nabibigo o gumagana hanggang sa simulan ng client isolation sa AP na itapon ito. Ia-alok pa rin ng VirtualBox ang wireless adapter sa listahan nito. Kung ang host ay nasa Wi-Fi at kailangang bridged ang guest, magplano ng pagsubok sa halip na mag-assume.

Ang MTU ang pangatlo. Pinapanatili ng bridged guest ang MTU ng LAN na 1500 byte, at kung pinapatakbo nito ang sariling WireGuard client sa 1420, ang malalaking TLS handshake ay natigil habang ang maliliit na kahilingan ay pumapasa. Sa ilalim ng NAT, problema ng host ang MTU ng tunnel ng host, pero naniniwala pa rin ang guest sa 1500, at ang UDP na may nakatakdang don't-fragment bit ay bumabagsak sa black hole sa parehong paraan.

Isulat ang mode at suriin muli pagkatapos ng anumang pagpapalit ng adapter

Itala ang mode, ang host interface na ginagamit ng bridge, ang default gateway ng guest, ang resolver nito, at ang mga exit address nitong v4 at v6. Ang talaang iyon ang nagpapamura sa susunod na pagkabigo: kapag lumipat ang laptop mula sa dock papuntang Wi-Fi, sinusundan ng bridged guest ang bridge papunta sa ibang pisikal na adapter at maaaring muling mag-lease sa ibang subnet, habang ang NAT guest ay pinapanatili ang address nitong 10.0.2.x at tahimik na nagmamana ng ibang uplink.

Bago isara ang ticket, kumpirmahin ang bawat isa sa mga ito:

• Iba ang exit address ng guest sa exit address ng host, kaya wala siya sa tunnel ng host.
• Ang resolver ay ang 10.0.2.3 proxy o isang server ng LAN, at alam mo kung alin ang sumagot.
• Walang global na v6 address sa guest kung ang disenyo ng tunnel ay v4 lamang.
• Kapag nakababa ang tunnel ng host, tumitigil ang guest sa pagba-browse, o alam mo na ngayong hindi siya kailanman umasa rito.
• Hindi nakikita ng guest ang broadcast trapiko ng LAN na wala siyang karapatang makita.