NAT eller brua VM-nettverk: kven ber VPN-trafikken?
NAT-gjester låner tunnelen til verten berre når klienten tunnelerer etter rute; brua gjester rutar sjølve. Test gjesten og vel deretter modusen som passar.
Bru og NAT er ikkje to måtar å kople den same gjesten til VPN-et ditt på; dei avgjer kven som eig pakkane til gjesten før ein tunnel i det heile er med i biletet. I NAT-modus skriv hypervisoren om trafikken til gjesten og sender han ut frå kode på vertssida, slik at gjesten følgjer kva rute verten gir den koden. I brua modus får gjesten sin eigen identitet på lenkjelaget i det fysiske segmentet og vel sin eigen standard gateway, noko som gjer tunnelen til verten irrelevant for han, med mindre det er LAN-rutaren som tunnelerer. Eg slutta å sjå på VM-en som noko som er på VPN-et og byrja å sjå på det som eit spørsmål om kvar standardruta til den gjesten peikar. Testen nedanfor tek nokre minutt per modus og avgjer det utan gissing.
NAT held gjesten bak koden til hypervisoren, der rutene til verten gjeld
I VirtualBox sit ein NAT-gjest på 10.0.2.0/24 med ein virtuell gateway på 10.0.2.2, ein DNS-proxy på 10.0.2.3 og inga eiga rute til det fysiske nettet. Utgåande pakkar blir tekne av NAT-motoren, skrivne om slik at kjelda er verten, og sende vidare til IP-stakken til verten. Derfrå er trafikken til gjesten ein vertsstraum, og ruteoppslaget skjer etter destinasjon: ein klient med full tunnel som installer 0.0.0.0/1 og 128.0.0.0/1 på verten, fangar han utan å nokon gong vite at det finst ein VM. Kapittelet til Oracle om VirtualBox-nettverk listar desse standardverdiane om du vil stadfeste adressene i din installasjon.
Standardnettverket til libvirt når same stad frå 192.168.122.0/24, der dnsmasq deler ut leiger og verten maskerer subnettet, slik at pakkane til gjesten igjen kjem til rutervalet til verten. Unntaket er ein klient som vel trafikk etter prosess i staden for etter rute. Viss lista for delt tunnel berre inneheld nettlesaren din og ingenting anna, er ikkje NAT-motoren på den lista, og gjesten forlèt maskina utan tunnel medan nettlesaren på verten framleis ser dekt ut. Same subnett, motsett resultat.
Bru gir gjesten sin eigen plass på det fysiske LAN-et
Ein brua gjest får eit virtuelt nettverkskort festa til ein ekte adapter, får si eiga MAC-adresse og tek ei DHCP-leige frå det fysiske nettet. Standard gateway er LAN-rutaren, ikkje hypervisoren, og rammene går ut på kabelen via den adapteren. Tunnelrutene til verten lever i tabellen til verten og blir aldri spurde, fordi rammene til gjesten aldri kjem inn i IP-stakken til verten.
Det skjer i begge retningar. mDNS og SMB-blaing byrjar å verke fordi gjesten ser kringkastartrafikken i LAN-et, og gjesten blir tilgjengeleg frå andre maskiner i same segment utan ein brannmur på verten imellom. Bru er heller ikkje ein måte å dytte ein gjest gjennom ein eksisterande tunnel: å feste ein VM til WireGuard- eller OpenVPN-grensesnittet til verten er ikkje noko VirtualBox eller libvirt gjer for deg. Viss ein brua gjest må gjennom ein tunnel, må tunnelen enda ein stad på det LAN-et.
Testen som avgjer saka
Køyr dei same kontrollane i begge modus og skriv ned svara:
- På verten gir
curl -s https://ifconfig.meden offentlege v4-adressa. - I gjesten den same kommandoen, pluss
ip routepå Linux ellerGet-NetRoute -DestinationPrefix 0.0.0.0/0på Windows for standard gateway. - Identiteten til oppløysaren:
resolvectl statusellercat /etc/resolv.confi gjesten, for å sjå om han peikar på 10.0.2.3 eller på ein LAN-server. - Adressefamilie:
ip -6 addr show scope globalog éin v6-førespurnad, fordi ein v4-tunnel ikkje seier noko om ei global v6-adresse som gjesten kan ha.
Samanfallande offentlege adresser betyr at gjesten er på vegen til verten. Ei gjesteadresse som svarar til den vanlege utgangen i LAN-et betyr at han ikkje er det. Steget folk hoppar over, er kontrollen: ta ned tunnelen til verten og gjer om førespurnaden frå gjesten. Viss gjesten held fram med å bla, har han aldri vore avhengig av tunnelen til verten, kva modusnamnet enn antydar. I NAT-modus skal gjesten miste internett når tunnelen til verten er nede, med mindre klienten er sett opp til å tillate trafikk utan tunnel, noko som er verdt å vite i seg sjølv.
To signal lyg. Ein vellukka ping beviser nåbarheit, ikkje utgangsvegen. Og DNS kan svarast av 10.0.2.3-proxyen gjennom oppløysaren til verten medan TCP tek ei anna rute, og slik får du ei side som lastar og ei innlogging som aldri blir fullført.
Kva modus som passar til jobben
Modusen er eit ruterval, så vel han ut frå kravet og ikkje ut frå vanen:
| 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 |
Fyrste rad er der folk går på ein smell: NAT pluss ein vertsklient med full tunnel dekkjer faktisk ein gjest, men berre så lenge klienten tunnelerer etter rute og opplenkja til verten er den tunnelen. Flytt klienten til ei tillatingsliste berre for nettlesaren, og dekninga forsvinn utan nokon feil nokon stad. Fjerde rad er den motsette feilen: ein gjest som er brua fordi det er lettvint, og som stille byrjar å svare på SMB eller SSH i kontor-LAN-et.
Feil som blir lagde på VPN-et
På Windows køyrer NAT-omsetjinga inne i VM-prosessen til VirtualBox, så ein klient per applikasjon treng nett det biletet på lista si i staden for ein generell regel for virtuelle maskiner. Når ein klientoppdatering byggjer prosesslista på nytt, mistar NAT-gjester dekninga fyrst, og rapporten blir lesen som ein VM som når LAN-et men ikkje internett medan verten er i orden.
Bru til Wi-Fi er den andre klassikaren. Aksesspunkt videresender sjeldan rammer med framand kjelde-MAC, så ei bru til wlan0 anten feilar heilt eller verkar til klientisolering på aksesspunktet byrjar å sleppe henne. VirtualBox vil framleis tilby den trådlause adapteren på lista si. Viss verten er på Wi-Fi og gjesten må bruast, planlegg å teste det i staden for å gå ut frå det.
MTU er den tredje. Ein brua gjest held på MTU-en på 1500 byte i LAN-et, og om han køyrer sin eigen WireGuard-klient på 1420, stoppar store TLS-handtrykk medan små førespurnader lukkast. Under NAT er MTU-en til tunnelen til verten verten sitt problem, men gjesten trur framleis på 1500, og UDP med don't-fragment-biten sett forsvinn på same måte.
Skriv ned modusen og sjekk på nytt etter kvar adapterendring
Skriv ned modusen, vertsgrensesnittet brua nyttar, standard gateway for gjesten, oppløysaren hans og utgangsadressene hans for v4 og v6. Det er den registreringa som gjer den neste feilen billeg: når ein berbar PC flyttar seg frå dokka til Wi-Fi, følgjer ein brua gjest brua til ein annan fysisk adapter og kan ta ny leige i eit anna subnett, medan ein NAT-gjest held på 10.0.2.x-adressa si og stille arvar ei anna opplenkje.
Før du lukkar saka, stadfest kvart av desse punkta:
- Utgangsadressa til gjesten er ulik utgangsadressa til verten, så han er ikkje på tunnelen til verten.
- Oppløysaren er 10.0.2.3-proxyen eller ein LAN-server, og du veit kven som svara.
- Det finst inga global v6-adresse i gjesten om tunneldesignet berre er v4.
- Med tunnelen til verten nede sluttar gjesten å bla, eller du veit no at han aldri var avhengig av han.
- Gjesten ser ikkje kringkastartrafikk i LAN-et som han ikkje har noko med.