VirtualBox NAT apo bridge: ku përfundon VPN-i i makinës virtuale

Dy pyetje të ndryshme vijnë bashkë sa herë që një makinë virtuale ekzekuton një klient VPN, dhe përgjigjet e tyre janë të ndryshme. E para është nëse një tunel brenda mysafirit mbron hostin, dhe e dyta është nëse një tunel në host e mbulon mysafirin. Mënyra e adaptorit i vendos të dyja, më shumë sesa vetë softueri VPN. Një adaptor NAT e bën hostin pikën fundore të dukshme, ndërsa një adaptor bridge e vendos mysafirin në rrjet me adresën e vet.

Kush e përfundon në të vërtetë sesionin e kriptuar

Një sesion i kriptuar i takon makinës që e përfundon atë, dhe kjo është mysafiri kur klienti ekzekutohet brenda VM-së. Nëpër atë tunel kalon vetëm trafiku që hyn në adaptorin virtual të mysafirit, dhe hipervizori nuk e drejton kurrë vetë një makinë tjetër përmes mysafirit. Prandaj mysafiri mund të mbajë një tunel funksional ndërsa hosti shfleton në rrjet të hapur. E kundërta nuk është simetrike, dhe pikërisht kjo asimetri është pjesa që shumica e udhëzuesve e gabojnë.

Cilën adresë sheh rrjeti i jashtëm është pyetja së cilës i përgjigjet mënyra e adaptorit. Pasi kjo zgjidhet, mbulimi pushon së qenë çështje politike dhe bëhet mekanik. Gjithçka më poshtë rrjedh nga këto dy fakte.

NAT e rishkruan mysafirin derisa të duket si hosti

Me NAT, hipervizori e rishkruan çdo paketë të mysafirit në adresën e hostit përpara se të arrijë ndërprerësin e parë. Ky trafik pastaj i dorëzohet stakut të rrjetit të vetë hostit, ku ndjek tabelën e tij të rrugëzimit, përfshirë një rrugë të parazgjedhur që zotërohet nga një tunel në host. Një mysafir NAT mbulohet pra nga një tunel në host pa asnjë konfigurim, çka është e kundërta e asaj që sugjeron rasti nga mysafiri në host.

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

Një mysafir që ekzekuton klientin e vet e përfundon atë tunel brenda mysafirit, dhe trafiku i kriptuar del pastaj përmes të njëjtit rishkrim, kështu që aplikacionet e hostit mbajnë rrugën e tyre dhe adresën e tyre të daljes. VirtualBox në këtë mënyrë zotëron edhe zgjidhjen e emrave, duke i kaluar pyetjet e mysafirit përmes motorit të vet, përveçse kur --natdnshostresolver1 është aktivizuar. Aktivizimi ia dorëzon kërkimet e mysafirit zgjidhësit të hostit, çka rregullon zgjidhjen kur pamja e vetë hostit është e saktë dhe njësoj dorëzon një zgjidhës që mund të ekzistojë vetëm brenda një tuneli. VM-ja duhet të fiket përpara se të ndryshohet rregullimi, dhe rregullimi i takon adaptorit e jo softuerit të mysafirit.

Bridge i jep mysafirit qiranë e vet dhe ekspozimin e vet

Bridge i kalon kornizat e mysafirit në segmentin fizik, prandaj DHCP i jep një qira dhe rrjeti e trajton si host të veçantë. Çdo mysafir i urëzuar mund të mbajë një tunel të pavarur me rrugën e vet të parazgjedhur, dhe tabela e hostit nuk ndryshon kurrë. Çmimi është ekspozimi: mysafiri u përgjigjet transmetimeve, shfaqet në tabelat e fqinjëve dhe bie nën sigurinë e porteve të ndërprerësit dhe izolimin e klientëve pa tel. As një tunel në host nuk e mbulon këtë rregullim, sepse kornizat e mysafirit nuk kalojnë kurrë nëpër stakun e hostit.

Kjo diferencë nga rasti NAT meriton të thuhet hapur në vend që të lihet si nënkuptim. Një mysafir i urëzuar ka nevojë për klientin e vet dhe kredencialet e veta sa herë që trafiku i tij duhet të përdorë një tunel. Aty ku mysafiri duhet të mbetet i padukshëm për rrjetin lokal, NAT ose një rrjet vetëm i brendshëm me rrugëzim të kontrolluar është projektimi më i mirë.

Pse mysafiri nuk mund të jetë porta e hostit

Huadhënia e tunelit të një mysafiri hostit nuk ka asnjë ndërprerës të mbështetur në asnjë nga dy hipervizorët e mëdhenj. Hosti nuk ka rrugë në tunelin e mysafirit as rregull përkthimi që të tregojë atje, prandaj trafiku i mysafirit dhe i hostit mbeten rrjedha të ndara me pronarë të ndarë. Ky drejtim dështon pavarësisht nga mënyra e adaptorit.

Zëvendësuesit e zbatueshëm janë ridrejtimet dhe përfaqësuesit. Një ridrejtim lokal SSH i lejon hostit të lidhet me loopback-un e vet ndërsa mysafiri e çon rrjedhën në tunel, çka mbulon shërbimet TCP pa instaluar një klient të dytë. Të bësh trafikun IP të vetë hostit të përdorë tunelin e mysafirit në vend të kësaj kërkon një rrugëzues brenda mysafirit plus një rrugë të shprehur në host dhe përkthim në host. Ky është një projektim i vogël rrjeti dhe jo një kuti shënimi, dhe kërkon një plan për rrugën e kthimit. Kur mysafiri ekziston vetëm për të ekzekutuar klientin, vendos klientin në host dhe hiq kërcimin e tepërt.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Zgjidhësit dhe rrugët nuk e kalojnë kufirin

DNS ndjek adaptorin që e pranoi opsionin, prandaj mysafiri nuk e trashëgon zgjidhësin e tunelit të hostit dhe hosti nuk e mëson kurrë serverin që iu shty mysafirit. Vlerat dhcp-option DNS të shtyra vlejnë për ndërfaqen që i pranoi ato, dhe prandaj një mysafir i urëzuar pa klient nuk mund të zgjidhë emra të brendshëm. Mysafiri NAT zakonisht përdor trajtimin DNS të hipervizorit, dhe diferenca duket në një komandë për çdo mjedis.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

Lexo zgjidhësin dhe rrugën brenda mysafirit përpara se të supozosh që ndonjëri prej tyre ndjek hostin. Shto zgjidhësin e tunelit në adaptorin e vetë mysafirit kur emrat e brendshëm duhet të zgjidhen atje, pastaj verifiko me një emër që ekziston vetëm pas tunelit. Shkruaj mënyrën e adaptorit, pronarin e tunelit dhe burimin e zgjidhësit për çdo VM, sepse këto tre fakte u përgjigjen pothuajse çdo pyetjeje të mëvonshme. Hipervizorët e tjerë i riemërtojnë mënyrat dhe e lënë parimin të paprekur.