NAT of oerbrêge VM-netwurk: hokker fiert it VPN-ferkear?
NAT-gasten liene de tunnel fan de host allinnich as de klient per rûte tunnelt; oerbrêge gasten rûte sels. Test de gast en kies dan de modus dy't past.
Oerbrêgje en NAT binne net twa manieren om deselde gast oan dyn VPN te keppeljen; se beslute wa't de pakketten fan 'e gast hat foardat der ek mar in tunnel yn it spul is. Yn NAT-modus skriuwt de hypervisor it ferkear fan 'e gast om en stjoert it út fan koade oan 'e hostkant, sadat de gast de rûte folget dy't de host oan dy koade jout. Yn oerbrêge modus krijt de gast syn eigen identiteit op 'e keppellaach yn it fysike segmint en kiest syn eigen standertgateway, wat de tunnel fan 'e host foar him irrelevant makket, útsein as de LAN-router dejinge is dy't tunnellet. Ik bin opholden de VM as op it VPN te beskôgjen en begûn it te behanneljen as in fraach oer wêr't de standertrûte fan dy gast nei wiist. De test hjirûnder kostet in pear minuten per modus en makket it sûnder rieden dúdlik.
NAT hâldt de gast efter hypervisorkoade, dêr't de rûtes fan 'e host jilde
Yn VirtualBox sitet in NAT-gast op 10.0.2.0/24 mei in firtuele gateway op 10.0.2.2, in DNS-proxy op 10.0.2.3 en gjin eigen rûte nei it fysike netwurk. Utgeande pakketten wurde troch de NAT-motor nommen, omskreaun sadat de boarne de host is, en trochjûn oan 'e IP-stapel fan 'e host. Fan dêrôf is it ferkear fan 'e gast in hoststream, en rûtesykjen bart op bestimming: in folsleine-tunnel-klient dy't 0.0.0.0/1 en 128.0.0.0/1 op 'e host ynstallearret, fangt it sûnder ea te witten dat der in VM bestiet. It haadstik fan Oracle oer VirtualBox-netwurk listet dizze standertwearden, as jo de adressen yn jo build befêstigje wolle.
It standertnetwurk fan libvirt berikt itselde plak fan 192.168.122.0/24, dêr't dnsmasq leases útdielt en de host it subnet maskearret, sadat de pakketten fan 'e gast wer by de rûtingsbeslissing fan 'e host útkomme. De útsûndering is in klient dy't ferkear op proses keapet ynstee fan op rûte. As de list fan split-tunnel allinne dyn browser befettet en fierder neat, stiet de NAT-motor net op dy list, en de gast ferlit de masine sûnder tunnel, wylst de browser fan 'e host der noch altyd bedutsen útsjocht. Selde subnet, tsjinsteld resultaat.
Oerbrêgje jout de gast syn eigen plak op it fysike LAN
In oerbrêge gast krijget in firtuele netwurkkaart oan in echte adapter, kriget syn eigen MAC-adres en nimt in DHCP-lease fan it fysike netwurk. Syn standertgateway is de LAN-router, net de hypervisor, en syn frames geane oer dy adapter de tried op. De tunnelrûtes fan 'e host libje yn 'e tabel fan 'e host en wurde nea rieplachte, om't de frames fan 'e gast nea yn 'e IP-stapel fan 'e host komme.
Dat snijt beide kanten út. mDNS en SMB-browsing begjinne te wurkjen om't de gast LAN-broadcastferkear sjocht, en de gast wurdt berikber fan oare masines yn itselde segmint sûnder in host-firewall der tusken. Oerbrêgje is ek gjin manier om in gast troch in besteande tunnel te triuwen: in VM oan 'e WireGuard- of OpenVPN-interface fan 'e host keppelje is net wat VirtualBox of libvirt foar dy docht. As in oerbrêge gast tunnelje moat, moat de tunnel earne op dat LAN einigje.
De test dy't de diskusje einiget
Rin deselde kontrôles yn beide modi en skriuw de antwurden op:
- Op 'e host jout
curl -s https://ifconfig.meit iepenbiere v4-adres. - Yn 'e gast itselde kommando, plus
ip routeop Linux ofGet-NetRoute -DestinationPrefix 0.0.0.0/0op Windows foar de standertgateway. - Identiteit fan 'e resolver:
resolvectl statusofcat /etc/resolv.confyn 'e gast, om te sjen oft it nei 10.0.2.3 of nei in LAN-tsjinner wiist. - Adresfamylje:
ip -6 addr show scope globalen ien v6-fersyk, om't in v4-tunnel neat seit oer in globale v6-adres dy't de gast hawwe kin.
Oerienkommende iepenbiere adressen betsjutte dat de gast op it paad fan 'e host is. In gastadres dat oerienkomt mei de gewoane útgong fan it LAN betsjut dat it net sa is. De stap dy't minsken oerslaan is de kontrôle: helje de tunnel fan 'e host del en werhelje it fersyk fan 'e gast. As de gast trochgiet mei browsen, hie hy nea fan 'e tunnel fan 'e host ôfhinklik, wat de namme fan 'e modus ek suggerearret. Yn NAT-modus moat de gast ynternet ferlieze mei de tunnel fan 'e host del, útsein as de klient ynsteld is om net-tunnele ferkear ta te litten, wat op himsels wittensweardich is.
Twa sinjalen lige. In slagge ping bewissiget berikberens, net it útgongspaad. En DNS kin troch de 10.0.2.3-proxy fia de resolver fan 'e host beantwurde wurde, wylst TCP in oare rûte nimt, en sa krijst in side dy't laden wurdt en in oanmelding dy't nea foltôget.
Hokker modus past by de taak
De modus is in rûtingsbeslissing, dus kies him út 'e eask ynstee fan út wizânsje:
| Requirement | Mode that fits |
|---|---|
| Every guest flow must exit through the host tunnel | NAT, with a host client that tunnels by route, verified from inside the guest |
| The guest needs its own VPN account or profile | Bridged, or NAT with a client running inside the guest, not both |
| The guest must serve SSH, SMB, or a dev server to the LAN | Bridged; NAT needs a port forward, which does not change the outbound path |
| The guest must stay invisible to the LAN | NAT; a bridged guest is another host on the segment |
| The guest needs a real public IPv6 address | Bridged; VirtualBox NAT mode has no IPv6 forwarding |
| Isolation from the LAN with access to the host | Host-only adapter, not NAT |
Rige ien is dêr't minsken fongen wurde: NAT plus in folsleine-tunnel-hostklient dekt in gast wol, mar allinnich salang't de klient per rûte tunnelt en de uplink fan 'e host dy tunnel is. Ferpleats de klient nei in allowlist allinne foar de browser en de dekking ferdwynt sûnder ien flater earne. Rige fjouwer is de omkearde flater: in gast dy't foar gemak oerbrêge is en stil begjint te antwurdzjen op SMB of SSH op it LAN fan kantoar.
Flaters dy't op it VPN skood wurde
Op Windows rint de NAT-oersetting yn it VM-proses fan VirtualBox, dus in per-app-klient hat krekt dy ôfbylding op syn list nedich ynstee fan in algemiene regel foar firtuele masines. As in klientupdate syn proseslist wer opbouwt, ferlieze NAT-gasten earst de dekking, en it rapport lêst as in VM dy't it LAN wol berikt mar it ynternet net, wylst de host goed is.
Oerbrêgje nei Wi-Fi is de oare klassiker. Tagongspunten stjoere selden frames mei in frjemde boarne-MAC troch, dus in brêge nei wlan0 mislearret hielendal of wurket oant kliïntisolaasje op it AP it begjint te dalen. VirtualBox sil de draadloze adapter noch altyd op syn list oanbiede. As de host op Wi-Fi is en de gast moat oerbrêge wurde, plan dan om it te testen ynstee fan it oan te nimmen.
MTU is de tredde. In oerbrêge gast hâldt de MTU fan 1500 byte fan it LAN, en as er syn eigen WireGuard-klient op 1420 rint, stopje grutte TLS-handshakes wylst lytse fersiken slagje. Under NAT is de MTU fan 'e tunnel fan 'e host it probleem fan 'e host, mar de gast leaut noch altyd yn 1500, en UDP mei de don't-fragment-bit set ferdwynt itselde.
Skriuw de modus op en kontrolearje opnij nei elke adapterwiziging
Skriuw de modus op, de host-interface dy't de brêge brûkt, de standertgateway fan 'e gast, syn resolver en syn v4- en v6-útgongsadressen. Dat ferslach is wat de folgjende flater goedkeap makket: as in laptop fan dock nei Wi-Fi ferhûzet, folget in oerbrêge gast de brêge nei in oare fysike adapter en kin er opnij lease yn in oar subnet, wylst in NAT-gast syn 10.0.2.x-adres hâldt en stil in oare uplink erft.
Foardat jo it ticket slute, befêstigje elk fan dizze:
- It útgongsadres fan 'e gast ferskilt fan dat fan 'e host, dus it sit net op 'e tunnel fan 'e host.
- De resolver is de 10.0.2.3-proxy of in LAN-tsjinner, en jo witte hokker antwurde.
- Der bestiet gjin globale v6-adres yn 'e gast as it tunnelûntwerp allinne v4 is.
- Mei de tunnel fan 'e host del hâldt de gast op mei browsen, of jo witte no dat er der nea fan ôfhinklik wie.
- De gast sjocht gjin LAN-broadcastferkear dat him neat oangiet.