Brúun og NAT eru ekki tvær leiðir til að tengja sama gestinn við VPN-ið þitt; þær ákvarða hver á pakka gestsins áður en nokkur göng koma við sögu. Í NAT-ham skrifar hypervisorinn umferð gestsins og sendir hana út frá kóða á hýsilhlið, þannig að gesturinn fer eftir þeirri leið sem hýsillinn gefur þeim kóða. Í brúuðum ham fær gesturinn eigin auðkenni á tengilagi í eðlisfræðilega hlutanum og velur sína eigin sjálfgefnu gátt, sem gerir göng hýsilsins óviðkomandi fyrir hann, nema LAN-leiðarinn sé sá sem göngugreiðir. Ég hætti að líta á VM-ið sem eitthvað sem er á VPN-inu og byrjaði að líta á það sem spurningu um hvert sjálfgefna leið gestsins vísar. Prófið hér að neðan tekur nokkrar mínútur á hvern ham og leysir það án ágiskana.

NAT heldur gestinum bak við kóða hypervisorsins, þar sem leiðir hýsilsins gilda

Í VirtualBox situr NAT-gestur á 10.0.2.0/24 með sýndargátt á 10.0.2.2, DNS-milliþjón á 10.0.2.3 og enga eigin leið út í eðlisfræðilega netið. Útfarandi pakka tekur NAT-vélin, skrifar þá um þannig að uppruninn sé hýsillinn og afhendir þá IP-stæðu hýsilsins. Þaðan er umferð gestsins flæði hýsilsins, og leiðarleitin er eftir áfangastað: biðlari með full göng sem setur upp 0.0.0.0/1 og 128.0.0.0/1 á hýsilinn grípur hana án þess að vita nokkurn tíma að VM sé til. Kafli Oracle um netkerfi VirtualBox telur upp þessi sjálfgefnu gildi ef þú vilt staðfesta vistföngin í þinni uppsetningu.

Sjálfgefna net libvirt nær sama stað frá 192.168.122.0/24, þar sem dnsmasq úthlutar leigum og hýsillinn hylur undirnetið, svo pakkar gestsins koma aftur að leiðarákvörðun hýsilsins. Undantekningin er biðlari sem velur umferð eftir ferli í stað leiðar. Ef listi sundurgreindra ganga inniheldur aðeins vafrann þinn og ekkert annað, er NAT-vélin ekki á þeim lista, og gesturinn yfirgefur vélina án ganga meðan vafri hýsilsins virðist enn vera undir. Sama undirnet, gagnstæð niðurstaða.

Brúun gefur gestinum eigin stað á eðlisfræðilega LAN-inu

Brúaður gestur fær sýndar-netkort tengt við raunverulegan millistykki, fær eigið MAC-vistfang og tekur DHCP-leigu úr eðlisfræðilega netinu. Sjálfgefna gáttin hans er LAN-leiðarinn, ekki hypervisorinn, og rammar hans fara á vírinn í gegnum þann millistykki. Göng leiða hýsilsins liggja í töflu hýsilsins og er aldrei spurt um þær, því rammar gestsins fara aldrei inn í IP-stæðu hýsilsins.

Það sker í báðar áttir. mDNS og SMB-vafrun byrja að virka því gesturinn sér dreifiumferð LAN-sins, og gesturinn verður aðgengilegur frá öðrum vélum í sama hluta án eldveggjar hýsilsins á milli. Brúun er líka ekki leið til að ýta gesti í gegnum fyrirliggjandi göng: að tengja VM við WireGuard- eða OpenVPN-viðmót hýsilsins er ekki eitthvað sem VirtualBox eða libvirt gerir fyrir þig. Ef brúaður gestur verður að fara í gegnum göng, verða göngin að enda einhvers staðar á því LAN-i.

Prófið sem endar rökþrætuna

Keyrðu sömu prófanir í báðum hám og skrifaðu niður svörin:

  • Á hýsilnum gefur curl -s https://ifconfig.me hið opinbera v4-vistfang.
  • Í gestinum sama skipun, auk ip route á Linux eða Get-NetRoute -DestinationPrefix 0.0.0.0/0 á Windows fyrir sjálfgefnu gáttina.
  • Auðkenni leysandans: resolvectl status eða cat /etc/resolv.conf í gestinum, til að sjá hvort það vísar á 10.0.2.3 eða LAN-þjón.
  • Vistfangafjölskylda: ip -6 addr show scope global og ein v6-beiðni, því v4-göng segja ekkert um alþjóðlegt v6-vistfang sem gesturinn kann að hafa.

Samhljóða opinber vistföng þýða að gesturinn er á braut hýsilsins. Vistfang gestsins sem passar við venjulega útleið LAN-sins þýðir að svo er ekki. Skrefið sem fólk sleppir er viðmiðunin: taktu göng hýsilsins niður og endurtaktu beiðni gestsins. Ef gesturinn heldur áfram að vafra var hann aldrei háður göngum hýsilsins, hvað sem nafn hamsins gefur í skyn. Í NAT-ham ætti gesturinn að missa internetið þegar göng hýsilsins eru niðri, nema biðlarinn sé stilltur til að leyfa umferð án ganga, sem er sjálft þess virði að vita.

Tvö merki ljúga. Árangursríkt ping sannar aðgengi, ekki útleið. Og DNS getur verið svarað af 10.0.2.3-milliþjóninum í gegnum leysanda hýsilsins á meðan TCP tekur aðra leið, og þannig færðu síðu sem hleðst og innskráningu sem klárast aldrei.

Hvaða hamur hentar verkefninu

Hamurinn er leiðarákvörðun, svo veldu hann eftir kröfunni en ekki eftir vananum:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

Fyrsta röðin er þar sem fólk festist: NAT auk biðlara með full göng á hýsilnum hylur vissulega gest, en aðeins á meðan biðlarinn göngugreiðir eftir leið og uppstreymistenging hýsilsins eru þau göng. Færðu biðlarann á lista sem leyfir aðeins vafrann og hulin hverfur án nokkurrar villu hvar sem er. Fjórða röðin er öfug mistök: gestur sem er brúaður til þæginda og byrjar hljóðlega að svara SMB eða SSH á skrifstofu-LAN-inu.

Bilanir sem er kennt um VPN-inu

Á Windows keyrist NAT-þýðingin inni í VM-ferli VirtualBox, svo biðlari fyrir hvert forrit þarf nákvæmlega þessa ímynd á listann sinn í stað almennrar reglu fyrir sýndarvélar. Þegar uppfærsla biðlarans byggir ferlalistann upp á ný tapa NAT-gestir hulin fyrst, og skýrslan les eins og VM sem nær LAN-inu en ekki internetinu á meðan hýsillinn er í lagi.

Brúun á Wi-Fi er hinn klassíski. Aðgangspunktar senda sjaldan ramma með erlendu upprunamarki, svo brú á wlan0 mistekst annaðhvort alveg eða virkar þar til einangrun biðlara á aðgangspunktinum byrjar að fleygja henni. VirtualBox býður samt þráðlausa millistykkisins á lista sínum. Ef hýsillinn er á Wi-Fi og gestinn verður að brúa skaltu skipuleggja að prófa það í stað þess að gera ráð fyrir því.

MTU er þriðja atriðið. Brúaður gestur heldur 1500 bæta MTU LAN-sins, og ef hann keyrir eigin WireGuard-biðlara á 1420 stöðvast stór TLS-handtök á meðan litlar beiðnir ganga. Undir NAT er MTU ganga hýsilsins vandamál hýsilsins, en gesturinn heldur samt að 1500 sé rétt, og UDP með don't-fragment-bitanum stilltum hverfur á sama hátt.

Skrifaðu haminn niður og athugaðu aftur eftir hverja millistykki

Skrifaðu niður haminn, hýsilviðmótið sem brúin notar, sjálfgefna gátt gestsins, leysandann hans og útleiðarvistföng hans v4 og v6. Þessi skráning er það sem gerir næstu bilun ódýra: þegar fartölva fer af tengistöðinni yfir á Wi-Fi fylgir brúaður gestur brúnni á annan eðlisfræðilegan millistykki og getur tekið nýja leigu í öðru undirneti, á meðan NAT-gestur heldur 10.0.2.x vistfanginu sínu og erfir hljóðlega aðra uppstreymistengingu.

Áður en þú lokar miðanum skaltu staðfesta hvert þessara atriða:

  • Útleiðarvistfang gestsins er annað en útleiðarvistfang hýsilsins, svo hann er ekki á göngum hýsilsins.
  • Leysandinn er 10.0.2.3-milliþjónninn eða LAN-þjónn og þú veist hvor svaraði.
  • Ekkert alþjóðlegt v6-vistfang er í gestinum ef hönnun ganganna er aðeins v4.
  • Með göng hýsilsins niðri hættir gesturinn að vafra, eða þú veist nú að hann var aldrei háður þeim.
  • Gesturinn sér ekki LAN-dreifiumferð sem honum kemur ekki við.

Tengdir greinar