NAT mi bridged VM ağı mı: VPN trafiğini hangisi taşır?
NAT konukları ana makinenin tüneline yalnızca istemci rotaya göre tünel açıyorsa ödünç alır; bridged konuklar rotasını kendisi kurar. Konuğu test edin, sonra uygun modu seçin.
Bridged ve NAT aynı konuğu VPN'inize bağlamanın iki yolu değildir; hangi tarafın herhangi bir tünel devreye girmeden önce konuğun paketlerine sahip olduğunu belirler. NAT modunda hipervizör konuğun trafiğini yeniden yazar ve ana makine tarafındaki koddan çıkarır, böylece konuk ana makinenin o koda verdiği rotadan gider. Bridged modunda konuk fiziksel segmentte kendi bağlantı katmanı kimliğini alır ve kendi varsayılan ağ geçidini seçer; bu da ana makinenin tünelini, tüneli LAN yönlendiricisi yapmadıkça onun için anlamsız kılar. VM'i VPN'in üzerinde duran bir şey olarak görmeyi bıraktım ve bunu o konuğun varsayılan rotasının nereye baktığı sorusu olarak görmeye başladım. Aşağıdaki test mod başına birkaç dakika sürer ve tahmine gerek kalmadan konuyu kapatır.
NAT, konuğu ana makine rotalarının geçerli olduğu hipervizör kodunun arkasında tutar
VirtualBox'ta NAT konuğu 10.0.2.0/24 içinde, 10.0.2.2'de sanal ağ geçidi, 10.0.2.3'te DNS vekili ile oturur ve fiziksel ağa kendi rotası yoktur. Giden paketleri NAT motoru alır, kaynak ana makine olacak şekilde yeniden yazar ve ana makinenin IP yığınına verir. Oradan konuğun trafiği bir ana makine akışıdır ve rota araması hedefe göre yapılır: ana makinede 0.0.0.0/1 ve 128.0.0.0/1 kuran tam tünel istemcisi, bir VM olduğunu hiç bilmeden onu yakalar. Oracle'ın VirtualBox ağ bölümü kendi derlemenizde adresleri doğrulamak isterseniz bu varsayılanları listeler.
libvirt'in varsayılan ağı aynı yere 192.168.122.0/24 üzerinden ulaşır; orada dnsmasq kiraları dağıtır ve ana makine alt ağı maskeler, böylece konuğun paketleri yine ana makinenin yönlendirme kararına gelir. İstisna, trafiği rotaya göre değil sürece göre seçen bir istemcidir. Bölünmüş tünel listesinde yalnızca tarayıcınız varsa NAT motoru o listede değildir ve ana makinedeki tarayıcı hâlâ kapsanmış görünürken konuk makineden tünelsiz çıkar. Aynı alt ağ, ters sonuç.
Bridged, konuğa fiziksel LAN'da kendi yerini verir
Bridged konuğa gerçek bir adaptöre bağlı sanal NIC verilir, kendi MAC adresini alır ve fiziksel ağdan DHCP kirası çeker. Varsayılan ağ geçidi hipervizör değil LAN yönlendiricisidir ve çerçeveleri o adaptörden kabloya çıkar. Ana makinenin tünel rotaları ana makinenin tablosunda durur ve hiç danışılmaz, çünkü konuğun çerçeveleri ana makinenin IP yığınına hiç girmez.
Bu iki yöne de keser. mDNS ve SMB taraması çalışmaya başlar çünkü konuk LAN yayın trafiğini görür ve konuk, arada ana makine güvenlik duvarı olmadan aynı segmentteki diğer makinelerden erişilebilir hale gelir. Bridging, bir konuğu var olan tünelden geçirmenin yolu da değildir: bir VM'i ana makinenin WireGuard veya OpenVPN arayüzüne bağlamak VirtualBox'ın ya da libvirt'in sizin için yaptığı bir şey değildir. Bridged bir konuğun tünellenmesi gerekiyorsa tünel o LAN'ın bir yerinde bitmelidir.
Tartışmayı bitiren test
Aynı kontrolleri iki modda da çalıştırın ve yanıtları yazın:
- Ana makinede,
curl -s https://ifconfig.megenel v4 adresini verir. - Konukta aynı komut, artı
ip routeLinux'ta veyaGet-NetRoute -DestinationPrefix 0.0.0.0/0Windows'ta varsayılan ağ geçidi için. - Çözümleyici kimliği:
resolvectl statusveyacat /etc/resolv.confkonukta, 10.0.2.3'e mi yoksa bir LAN sunucusuna mı işaret ettiğini görmek için. - Adres ailesi:
ip -6 addr show scope globalve bir v6 isteği, çünkü v4 tüneli konuğun sahip olabileceği genel bir v6 adresi hakkında hiçbir şey söylemez.
Eşleşen genel adresler konuğun ana makinenin yolunda olduğu anlamına gelir. LAN'ın olağan çıkışıyla eşleşen bir konuk adresi ise olmadığı anlamına gelir. İnsanların atladığı adım kontrol: ana makine tünelini indirin ve konuk isteğini yineleyin. Konuk taramaya devam ediyorsa, modun adı ne derse desin, ana makine tüneline hiç bağlı olmamıştır. NAT modunda ana makine tüneli inerken konuğun interneti kaybetmesi gerekir; istemci tünel dışı trafiğe izin verecek şekilde yapılandırılmadıysa, ki bunu ayrıca bilmekte yarar var.
İki sinyal yalan söyler. Başarılı bir ping erişilebilirliği kanıtlar, çıkış yolunu değil. Ve DNS, TCP başka bir rota izlerken ana makinenin çözümleyicisi üzerinden 10.0.2.3 vekili tarafından yanıtlanabilir; yüklenen bir sayfa ile hiç tamamlanmayan bir oturum açma böyle ortaya çıkar.
Hangi mod işe uyar
Mod bir yönlendirme kararıdır, bu yüzden onu alışkanlığa göre değil gereksinime göre seçin:
| 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 |
İlk satır insanların yakalandığı yer: NAT artı ana makinede tam tünel istemcisi bir konuğu gerçekten kapsar, ama yalnızca istemci rotaya göre tünel açtığı ve ana makinenin üst bağlantısı o tünel olduğu sürece. İstemciyi yalnızca tarayıcıya izin veren bir listeye taşıyın, kapsama hiçbir yerde hata vermeden kaybolur. Dördüncü satır ters hatadır: kolaylık olsun diye bridged yapılmış ve ofis LAN'ında sessizce SMB ya da SSH yanıtlamaya başlayan bir konuk.
VPN'e yıkılan arızalar
Windows'ta NAT çevirisi VirtualBox VM sürecinin içinde çalışır, bu yüzden uygulama başına çalışan bir istemcinin listesinde sanal makineler için genel bir kural değil, tam olarak o imge bulunmalıdır. Bir istemci güncellemesi izin verilen süreç listesini yeniden kurduğunda NAT konukları kapsamayı ilk kaybeder ve rapor, ana makine iyiyken LAN'a ulaşan ama internete ulaşmayan bir VM gibi okunur.
Wi-Fi'ye bridging diğer klasiktir. Erişim noktaları yabancı kaynak MAC taşıyan çerçeveleri nadiren iletir, bu yüzden wlan0 üzerindeki bir köprü ya hemen başarısız olur ya da AP'deki istemci yalıtımı onu düşürmeye başlayana kadar çalışır. VirtualBox kablosuz adaptörü yine de listesinde sunar. Ana makine Wi-Fi'deyse ve konuk bridged olmak zorundaysa, varsaymak yerine test planlayın.
MTU üçüncüsüdür. Bridged konuk LAN'ın 1500 baytlık MTU'sunu korur ve kendi WireGuard istemcisini 1420'de çalıştırıyorsa büyük TLS el sıkışmaları takılırken küçük istekler geçer. NAT altında ana makine tünelinin MTU'su ana makinenin sorunudur, ama konuk hâlâ 1500'e inanır ve don't-fragment biti ayarlı UDP de aynı şekilde kara deliğe düşer.
Modu yazın ve her adaptör değişikliğinden sonra yeniden kontrol edin
Modu, köprünün kullandığı ana makine arayüzünü, konuğun varsayılan ağ geçidini, çözümleyicisini ve v4 ile v6 çıkış adreslerini kaydedin. O kayıt, bir sonraki arızayı ucuzlatan şeydir: dizüstü bilgisayar dock'tan Wi-Fi'ye geçtiğinde bridged konuk köprüyü başka bir fiziksel adaptöre izler ve başka bir alt ağda yeniden kira alabilir; NAT konuk ise 10.0.2.x adresini korur ve sessizce başka bir üst bağlantıyı devralır.
Kaydı kapatmadan önce şunların her birini doğrulayın:
- Konuğun çıkış adresi ana makinenin çıkış adresinden farklıdır, yani ana makine tünelinde değildir.
- Çözümleyici 10.0.2.3 vekili ya da bir LAN sunucusudur ve hangisinin yanıtladığını biliyorsunuz.
- Tünel tasarımı yalnızca v4 ise konukta genel bir v6 adresi yoktur.
- Ana makine tüneli inerken konuk taramayı bırakır, ya da artık ona hiç bağlı olmadığını biliyorsunuz.
- Konuk, görmemesi gereken LAN yayın trafiğini görmez.