NAT və körpü rejimli VM şəbəkəsi: VPN trafikini hansı daşıyır?

NAT qonaqları host tunelini yalnız müştəri marşrutla tunelləyəndə borc alır; körpü qonaqları özləri marşrutlaşdırır. Qonağı sınaqdan keçirin, sonra uyğun rejimi seçin.

Körpü rejimi və NAT eyni qonağı VPN-ə qoşmağın iki yolu deyil; onlar hər hansı tunel işə düşməzdən əvvəl qonağın paketlərinin kimə aid olduğunu müəyyən edir . NAT rejimində hipervisor qonağın trafikini yenidən yazır və host tərəfindəki koddan çıxarır, beləliklə qonaq hostun həmin koda verdiyi marşrutla gedir. Körpü rejimində qonaq fiziki seqmentdə öz kanal qatı kimliyini alır və öz standart şlüzünü seçir, bu da host tunelini onun üçün əhəmiyyətsiz edir, məgər tuneli LAN marşrutlaşdırıcısı qurursa. Mən VM-i VPN-in içində saymağı dayandırdım və məsələyə qonağın standart marşrutunun hara baxdığı sualı kimi baxmağa başladım. Aşağıdakı sınaq hər rejim üçün bir neçə dəqiqə çəkir və təxminə yer qoymadan həll edir.

NAT qonağı hipervisor kodunun arxasında saxlayır, host marşrutları orada keçərlidir

VirtualBox-da NAT qonağı 10.0.2.0/24 üzərində oturur, virtual şlüzü 10.0.2.2, DNS proxy-si 10.0.2.3-dür və fiziki şəbəkəyə öz marşrutu yoxdur. Çıxan paketləri NAT mühərriki götürür, mənbə host olacaq şəkildə yenidən yazır və host IP yığınına ötürür. Oradan qonağın trafiki host axınıdır və marşrut axtarışı təyinat üzrə olur: hostda 0.0.0.0/1 və 128.0.0.0/1 quraşdıran tam tunel müştərisi VM-in varlığından xəbərsiz onu tutur. Oracle-ın VirtualBox şəbəkə fəsli qurğunuzda ünvanları təsdiqləmək istəsəniz, bu standartları sadalayır.

libvirt-in standart şəbəkəsi eyni yerə 192.168.122.0/24-dən çatır; orada dnsmasq icarə müqavilələri verir və host alt şəbəkəni maskalayır, beləliklə qonağın paketləri yenidən hostun marşrut qərarına gəlir. İstisna trafiki marşruta görə deyil, prosesə görə seçən müştəridir. Əgər split-tunel siyahısında yalnız brauzeriniz varsa, NAT mühərriki o siyahıda deyil və qonaq maşından tunelsiz çıxır, host brauzeri isə hələ örtülü görünür. Eyni alt şəbəkə, əks nəticə.

Körpü rejimi qonağa fiziki LAN-da öz yerini verir

Körpü qonağına real adapterə qoşulmuş virtual NIC verilir, öz MAC ünvanını alır və fiziki şəbəkədən DHCP icarəsi götürür. Onun standart şlüzü hipervisor deyil, LAN marşrutlaşdırıcısıdır və freymları həmin adapterdən kabelə çıxır. Hostun tunel marşrutları hostun cədvəlində yaşayır və heç vaxt nəzərə alınmır, çünki qonağın freymları heç vaxt host IP yığınına daxil olmur.

Bu, hər iki istiqamətdə kəsir. mDNS və SMB gəzintisi işləməyə başlayır, çünki qonaq LAN yayım trafikini görür və qonaq eyni seqmentdəki digər maşınlardan, aralarında host firewallu olmadan əlçatan olur. Körpü həm də qonağı mövcud tuneldən keçirməyin yolu deyil: VM-i hostun WireGuard və ya OpenVPN interfeysinə qoşmaq VirtualBox və ya libvirt-in sizin üçün etdiyi iş deyil. Əgər körpü qonağı tunellənməlidirsə, tunel həmin LAN-da bir yerdə bitməlidir.

Mübahisəni bitirən sınaq

Hər iki rejimdə eyni yoxlamaları aparın və cavabları yazın:

  • Hostda curl -s https://ifconfig.me ictimai v4 ünvanını verir.
  • Qonaqda eyni əmr, üstəgəl ip route Linux-da və ya Get-NetRoute -DestinationPrefix 0.0.0.0/0 Windows-da standart şlüz üçün.
  • Həlledici kimliyi: resolvectl status və ya cat /etc/resolv.conf qonaqda, onun 10.0.2.3-ə yoxsa LAN serverinə baxdığını görmək üçün.
  • Ünvan ailəsi: ip -6 addr show scope global və bir v6 sorğusu, çünki v4 tuneli qonağın malik ola biləcəyi qlobal v6 ünvanı haqqında heç nə demir.

Uyğun ictimai ünvanlar qonağın hostun yolunda olduğunu bildirir. LAN-ın adi çıxışına uyğun qonaq ünvanı isə olmadığını. İnsanların atladığı addım nəzarətdir: host tunelini söndürün və qonağın sorğusunu təkrarlayın. Əgər qonaq gəzməyə davam edirsə, rejimin adı nə deyirsə desin, o heç vaxt host tunelindən asılı olmayıb. NAT rejimində host tuneli söndükdə qonaq interneti itirməlidir, müştəri tunelsiz trafikə icazə vermək üçün konfiqurasiya edilməyibsə; bunu bilmək özlüyündə dəyərlidir.

İki siqnal yalan deyir. Uğurlu ping əlçatanlığı sübut edir, çıxış yolunu yox. DNS isə host həlledicisi vasitəsilə 10.0.2.3 proxy-si tərəfindən cavablandırıla bilər, TCP isə başqa marşrut tutur; yüklənən səhifə və heç tamamlanmayan giriş belə yaranır.

Hansı rejim işə uyğundur

Rejim marşrut qərarıdır, ona görə də onu vərdişdən deyil, tələbdən seçin:

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

Birinci sətir insanların ilişdiyi yerdir: NAT üstəgəl hostda tam tunel müştərisi qonağı həqiqətən örtür, amma yalnız müştəri marşrutla tunelləyəndə və hostun yuxarı kanalı həmin tunel olanda. Müştərini yalnız brauzer üçün icazə siyahısına keçirin və heç bir yerdə xəta olmadan örtük yox olur. Dördüncü sətir əks səhvdir: rahatlıq üçün körpülənmiş qonaq sakitcə ofis LAN-ında SMB və ya SSH cavablandırmağa başlayır.

VPN-in üstünə yazılan nasazlıqlar

Windows-da NAT tərcüməsi VirtualBox VM prosesinin içində işləyir, ona görə hər tətbiq üçün müştəriyə virtual maşınlar üçün ümumi qayda deyil, məhz həmin image lazımdır. Müştəri yeniləməsi proses icazə siyahısını yenidən quranda NAT qonaqları örtüyü birinci itirir və hesabat host yaxşı olduğu halda LAN-a çatıb internetə çatmayan VM kimi oxunur.

Wi-Fi-yə körpü digər klassikdir. Giriş nöqtələri yad mənbə MAC daşıyan freymları nadir hallarda yönləndirir, ona görə wlan0-a körpü ya tamamilə uğursuz olur, ya da AP-də müştəri izolyasiyası onu atmağa başlayana kimi işləyir. VirtualBox yenə də simsiz adapteri siyahısında təklif edəcək. Host Wi-Fi-dadırsa və qonaq körpülənməlidirsə, bunu güman etmək yerinə sınamağı planlayın.

MTU üçüncüdür. Körpü qonağı LAN-ın 1500 baytlıq MTU-sunu saxlayır və öz WireGuard müştərisini 1420-də işlədirsə, böyük TLS əl sıxmaları dayanır, kiçik sorğular isə keçir. NAT altında host tunelinin MTU-su hostun problemidir, amma qonaq hələ də 1500-ə inanır və parçalanmasın biti qoyulmuş UDP eyni qara dəliyə düşür.

Rejimi yazın, sonra hər adapter dəyişikliyindən sonra yenidən yoxlayın

Rejimi, körpünün istifadə etdiyi host interfeysini, qonağın standart şlüzünü, həlledicisini və v4 və v6 çıxış ünvanlarını qeyd edin. Bu qeyd növbəti nasazlığı ucuz edir: noutbuk dokdan Wi-Fi-yə keçəndə körpü qonağı körpünü başqa fiziki adapterə izləyir və başqa alt şəbəkəyə yenidən icarə götürə bilər, NAT qonağı isə 10.0.2.x ünvanını saxlayır və səssizcə başqa yuxarı kanalı miras alır.

Bileti bağlamazdan əvvəl bunların hər birini təsdiqləyin:

  • Qonağın çıxış ünvanı hostun çıxış ünvanından fərqlənir, deməli host tunelində deyil.
  • Həlledici 10.0.2.3 proxy-si və ya LAN serveridir və hansının cavab verdiyini bilirsiniz.
  • Tunel dizaynı yalnız v4-dürsə, qonaqda qlobal v6 ünvanı yoxdur.
  • Host tuneli söndükdə qonaq gəzməyi dayandırır, ya da indi bilirsiniz ki, o heç vaxt ondan asılı olmayıb.
  • Qonaq görməli olmadığı LAN yayım trafikini görmür.

Əlaqəli məqalələr