Rrjeti i VM-ve me NAT ose bridged: cila prej tyre mbart trafikun VPN?

Bridged dhe NAT nuk janë dy mënyra për të lidhur të njëjtin të ftuar me VPN-në tuaj; ato vendosin kush i zotëron paketat e të ftuarit përpara se të hyjë në lojë ndonjë tunel. Në mënyrën NAT, hipervizori rishkruan trafikun e të ftuarit dhe e lëshon nga kod në anën e hostit, kështu që i ftuari shkon me çdo rrugë që hosti i jep atij kodi. Në mënyrën bridged, i ftuari merr identitetin e vet të shtresës së lidhjes në segmentin fizik dhe zgjedh portën e tij të paracaktuar, gjë që e bën tunelin e hostit të parëndësishëm për të, përveç nëse ruteri i LAN-it është ai që bën tunelizimin. Ndalova së trajtuari VM-në si diçka që është në VPN dhe fillova ta trajtoj si një pyetje se ku tregon rruga e paracaktuar e atij të ftuari. Testi më poshtë zgjat disa minuta për mënyrë dhe e zgjidh pa hamendësime.

NAT e mban të ftuarin pas kodit të hipervizorit, ku zbatohen rrugët e hostit

Në VirtualBox, i ftuari NAT qëndron në 10.0.2.0/24 me një portë virtuale në 10.0.2.2, një proxy DNS në 10.0.2.3 dhe pa rrugë të vetën drejt rrjetit fizik. Paketat dalëse i merr mekanizmi NAT, i rishkruan që burimi të jetë hosti dhe i kalon stakut IP të hostit. Nga aty trafiku i të ftuarit është një rrjedhë e hostit, dhe kërkimi i rrugës bëhet sipas destinacionit: një klient me tunel të plotë që instalon 0.0.0.0/1 dhe 128.0.0.0/1 në host e kap pa e ditur kurrë se ekziston një VM. Kapitulli i Oracle mbi rrjetin në VirtualBox i liston këto vlera të paracaktuara nëse doni të konfirmoni adresat në build-in tuaj.

Rrjeti i paracaktuar i libvirt arrin në të njëjtin vend nga 192.168.122.0/24, ku dnsmasq shpërndan qira dhe hosti maskon nënrrjetin, kështu që paketat e të ftuarit vijnë përsëri te vendimi i rrugëtimit të hostit. Përjashtim është një klient që zgjedh trafikun sipas procesit dhe jo sipas rrugës. Nëse lista e tunelizimit të ndarë përmban vetëm shfletuesin tuaj, mekanizmi NAT nuk është në atë listë, dhe i ftuari largohet nga makina pa tunel, ndërsa shfletuesi i hostit vazhdon të duket i mbuluar. I njëjti nënrrjet, rezultat i kundërt.

Bridged i jep të ftuarit vendin e vet në LAN-in fizik

Një i ftuar bridged merr një NIC virtuale të lidhur me një përshtatës real, merr adresën e vet MAC dhe merr një qira DHCP nga rrjeti fizik. Porta e tij e paracaktuar është ruteri i LAN-it, jo hipervizori, dhe kornizat e tij shkojnë në tel përmes atij përshtatësi. Rrugët e tunelit të hostit janë në tabelën e hostit dhe nuk konsultohen kurrë, sepse kornizat e të ftuarit nuk hyjnë kurrë në stakun IP të hostit.

Kjo pret në të dyja anët. Shfletimi me mDNS dhe SMB fillon të funksionojë sepse i ftuari sheh trafikun transmetues të LAN-it, dhe i ftuari bëhet i arritshëm nga makina të tjera në të njëjtin segment pa firewall të hostit në mes. Bridging nuk është as një mënyrë për ta shtyrë një të ftuar nëpër një tunel ekzistues: lidhja e një VM me ndërfaqen WireGuard ose OpenVPN të hostit nuk është diçka që VirtualBox ose libvirt e bëjnë për ju. Nëse një i ftuar bridged duhet tunelizuar, tuneli duhet të përfundojë diku në atë LAN.

Testi që e mbyll debatin

Kryeni të njëjtat kontrolle në të dyja mënyrat dhe shkruani përgjigjet:

• Në host, curl -s https://ifconfig.me jep adresën publike v4.
• Në të ftuar, i njëjti komandë, plus ip route në Linux ose Get-NetRoute -DestinationPrefix 0.0.0.0/0 në Windows për portën e paracaktuar.
• Identiteti i zgjidhësit: resolvectl status ose cat /etc/resolv.conf në të ftuar, për të parë nëse tregon 10.0.2.3 ose një server të LAN-it.
• Familja e adresave: ip -6 addr show scope global dhe një kërkesë v6, sepse një tunel v4 nuk thotë asgjë për një adresë globale v6 që i ftuari mund ta ketë.

Adresa publike të njëjta nënkuptojnë se i ftuari është në rrugën e hostit. Një adresë e të ftuarit që përputhet me daljen e zakonshme të LAN-it nënkupton se nuk është. Hapi që njerëzit e kapërcejnë është kontrolli: ulni tunelin e hostit dhe përsëritni kërkesën nga i ftuari. Nëse i ftuari vazhdon të shfletuar, ai nuk ka qenë kurrë i varur nga tuneli i hostit, sido që të quhet mënyra. Në mënyrën NAT, i ftuari duhet të humbasë internetin me tunelin e hostit të ulur, përveç nëse klienti është konfiguruar të lejojë trafik pa tunel, gjë që ia vlen të dihet më vete.

Dy sinjale gënjejnë. Një ping i suksesshëm provon arritshmërinë, jo rrugën e daljes. Dhe DNS-i mund të përgjigjet nga proxy 10.0.2.3 përmes zgjidhësit të hostit, ndërsa TCP ndjek një rrugë tjetër, dhe kështu ju merrni një faqe që hapet dhe një hyrje që nuk përfundon kurrë.

Cila mënyrë i përshtatet punës

Mënyra është një vendim rrugëtimi, ndaj zgjidheni sipas kërkesës, jo sipas zakonit:

Rreshti i parë është vendi ku njerëzit kapen: NAT plus një klient me tunel të plotë në host e mbulon vërtet një të ftuar, por vetëm sa kohë që klienti tunelon sipas rrugës dhe lidhja lart e hostit është ai tunel. Zhvendosni klientin në një listë lejimesh vetëm për shfletuesin dhe mbulimi zhduket pa asnjë gabim kudo. Rreshti i katërt është gabimi i kundërt, një i ftuar bridged për lehtësi që në heshtje fillon të përgjigjet për SMB ose SSH në LAN-in e zyrës.

Dështimet që ia hedhin VPN-së

Në Windows, përkthimi NAT ekzekutohet brenda procesit të VM-së në VirtualBox, ndaj një klient sipas aplikacioneve ka nevojë për pikërisht atë imazh në listë, jo për një rregull të përgjithshëm për makina virtuale. Kur një përditësim i klientit rindërton listën e proceseve të lejuara, të ftuarit NAT humbin mbulimin të parët, dhe raporti lexohet si një VM që arrin LAN-in por jo internetin, ndërsa hosti është në rregull.

Bridging në Wi-Fi është klasiku tjetër. Pikat e aksesit rrallë përcjellin korniza me një MAC burimi të huaj, ndaj një bridge mbi wlan0 ose dështon menjëherë ose funksionon derisa izolimi i klientëve në AP fillon ta hedhë poshtë. VirtualBox do t'ju ofrojë përsëri përshtatësin wireless në listë. Nëse hosti është në Wi-Fi dhe i ftuari duhet bridged, planifikoni një test në vend që të supozoni.

MTU është i treti. Një i ftuar bridged mban MTU-në e LAN-it prej 1500 bajtësh, dhe nëse drejton klientin e vet WireGuard në 1420, shtrëngimet e mëdha TLS ngecin ndërsa kërkesat e vogla kalojnë. Nën NAT, MTU-ja e tunelit të hostit është problem i hostit, por i ftuari vazhdon të besojë në 1500, dhe UDP me bitin don't-fragment të vendosur përfundon në vrimë të zezë njësoj.

Shkruani mënyrën dhe rikontrolloni pas çdo ndryshimi të përshtatësit

Regjistroni mënyrën, ndërfaqen e hostit që përdor bridge-i, portën e paracaktuar të të ftuarit, zgjidhësin e tij dhe adresat e daljes v4 dhe v6. Ky regjistrim është ai që e bën të lirë dështimin e radhës: kur një laptop kalon nga dock-u në Wi-Fi, një i ftuar bridged ndjek bridge-in drejt një përshtatësi tjetër fizik dhe mund të marrë përsëri qira në një nënrrjet tjetër, ndërsa një i ftuar NAT mban adresën 10.0.2.x dhe trashëgon në heshtje një lidhje lart të ndryshme.

Përpara se të mbyllni tiketën, konfirmoni secilën nga këto:

• Adresa e daljes së të ftuarit ndryshon nga adresa e daljes së hostit, ndaj nuk është në tunelin e hostit.
• Zgjidhësi është proxy 10.0.2.3 ose një server i LAN-it, dhe e dini cili prej tyre u përgjigj.
• Nuk ekziston adresë globale v6 në të ftuar nëse dizajni i tunelit është vetëm v4.
• Me tunelin e hostit të ulur, i ftuari ndalon së shfletuari, ose tani e dini se nuk ka qenë kurrë i varur prej tij.
• I ftuari nuk sheh trafik transmetues të LAN-it që nuk ka pse ta shohë.