Ana makine trafiğini VM içinde VPN üzerinden yönlendirme: altı kontrol

Sırayla yapılan altı kontrol, bir VM'in kendi ana makinesi için VPN geçidi olup olamayacağına karar verir. Hipervizör bunların hiçbirini sizin için yapmaz: tünel konuğa aittir, yol ana makineye aittir ve aralarındaki ağ sıradan yönlendirmedir. Bu listeyi tutuyorum çünkü bir adımı atlamak her zaman aynı belirtiyi verir, sessizliği, ana makinenin konuğa neşeyle ping attığı ama içeride hiçbir yere ulaşamadığı durumu.

Nedenle başlayın. Ya kurumsal istemci yalnızca konuğun içine kurulur ya da ilke onu orada tutar ve yine de ana makineden iç build sunucusuna ihtiyacınız vardır. Ana makinenin kendi istemcisine izin veriliyorsa bunu yapın: ana makinedeki tek bir tünel her seferinde iki ağ artı bir NAT'ı yener.

Kontrol 1: ana makinenin adres verebileceği bir bağlantıya ihtiyacı var

Ana makinenin, konuğun ikinci bağdaştırıcısıyla aynı önekte bir arayüzü olmalıdır. VirtualBox'ta host-only, VMware Workstation'da host-only veya özel VMnet, QEMU/KVM'de iç köprü veya tap aygıtı ve Hyper-V'de Internal anahtarının hepsi uygundur. Konuk 192.168.56.2, ana makine 192.168.56.1, önek 192.168.56.0/24 laboratuvarlarda kullandığım düzen.

QEMU'nun kullanıcı modu ağı (-netdev user, varsayılan SLIRP arka ucu) ve VirtualBox NAT bu kontrolde tamamen başarısız olur. Konuk paketleri ana makinedeki bir vekil sürece ulaşır, bu yüzden ana makine konuğun adreslerini taşıyan bir aygıtı hiç görmez ve yolu yöneltecek bir şeyi olmaz. Hyper-V'nin Default Switch'i de aynı hikâye. Ana makineden ping 192.168.56.2 başarısız olursa durun: sonradan eklenen hiçbir yol bunu düzeltmez.

Kontrol 2: konuk iletir ve çevirir

Ana makineden gelen paketler host-only kaynak adresi ve iç hedefle gelir, bu yüzden konuk onları iletmeli ve sonra kendi tünel adresinin arkasına saklamalıdır. Linux konukta bu, iletme, bir FORWARD accept çifti ve tünele doğru source NAT anlamına gelir:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

MASQUERADE kuralı insanların atladığı kısımdır. Kurumsal yönlendiriciler 192.168.56.0/24 olduğunu nadiren bilir; kuralla iç sunucular konuğun tünel adresini görür ve ona yanıt verir, yanıt da konuğa geri dönüş yolunu bulur.

Windows konuk daha hantaldır. SYSTEM\CurrentControlSet\Services\Tcpip\Parameters altında IPEnableRouter=1, çeviri olmadan iletmeyi açar, bu yüzden yalnızca kurumsal yönlendirmenin zaten sizin host-only önekinize geri baktığı yerde çalışır. Internet Connection Sharing çevirir ama paylaşılan bağdaştırıcıyı 192.168.137.1 olarak yeniden numaralandırır, bu yüzden ana makine yollarını yazmadan önce gerçekte aldığı adresi okuyun.

Kontrol 3: ana makine yolları tüneli değil konuğu adlandırır

Konuktan yalnızca ana makinenin ihtiyaç duyduğu önekleri geçirin. Linux'ta önek başına bir yol yeterlidir ve temiz biçimde geri döner:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

Windows'ta karşılığı route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Test ederken -p dışarıda bırakın, böylece kötü bir yol yeniden başlatmada ölür; yol çalışınca ekleyin. Ana makinenin varsayılan yolunu, ana makinedeki her uygulama tüneli kullanmak zorunda değilse kaldırmayın; tam tünel gerçekten gerekiyorsa iki /1 yolunu ekleyin ve hipervizör ağına doğrudan yolu koruyun:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

Windows ana makinede arayüz ölçütünü de kontrol edin. host-only bağdaştırıcı devre dışıyken eklenen yol tabloda kalır ama hiç trafik taşımaz ve ölçütü daha düşük ikinci bir bağdaştırıcı aynı önek için aramayı kazanabilir.

Kontrol 4: DNS yolu izler, tünelin varsayılanını değil

Yollar paketleri hareket ettirir; çözümleyici hangi adların paket ürettiğine karar verir. Ana makinenin çözümleyicisini değiştirmek yerine kurumsal çözümleyiciyi kurumsal bölgeyle sınırlayın ve onu yeni yolun zaten ulaştığı bir DNS sunucusuna yönlendirin. Ana makinede systemd-resolved ile:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

Windows'ta ad çözümleme ilkesi tablosundaki bir giriş aynı işi yapar: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Konuk host-only adresinde kendi çözümleyicisini çalıştırıyorsa onun yerine o adresi kullanın, ancak loopback'te değil 192.168.56.2 üzerinde yanıt verdiğini doğruladıktan sonra.

Sonra yavaş sayfalar için DNS'i suçlamadan önce MTU'yu kontrol edin. Tünel arayüzü ana makinenin 1500 baytlık arayüzünden daha küçüktür, bu yüzden DF bitini ayarlayarak tam boyutlu segmentler gönderen ana makine bunların konuğun içinde bir yerde düşürüldüğünü görür. Klasik belirti çalışan bir ping ve TLS el sıkışmasından sonra takılan iç web uygulamasıdır. Konuğun iletme yolunda MSS'yi sıkın:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Kontrol 5: iki uçtan doğrulayın

Ana makineden iç adrese traceroute veya tracert ilk atlama olarak fiziksel geçidi değil 192.168.56.2 göstermelidir. Konukta aynı denemenin çıkışını izleyin: tcpdump -ni any host 10.20.30.40 host-only tarafında iletilen isteği ve tünelde çevrilen isteği gösterir. Çıkıp geri gelen ve yine de ana makineyi sessiz bırakan istek dönüş yolunu işaret eder.

İki arıza bunun çoğunu açıklar. Ya NAT kuralı olmadığı için konuğun tüneli host-only öneki için dönüş yolu taşımaz, ya da ana makine yolu yeniden başlatmadan sonra konuğun artık sahip olmadığı bir adresi gösterir. Önceki oturumun notlarına güvenmek yerine adresleri ip -br addr ve ip route get ile yeniden okuyun.

Kontrol 6: yeniden başlatmaya ve hipervizör yükseltmesine dayanıklı yapın

İki yarıyı da kalıcı kılın: ana makinede netplan veya NetworkManager yol yapılandırması, Windows'ta route add ... -p ve /etc/sysctl.d/ içinde net.ipv4.ip_forward=1 ile konukta yeniden yüklenen güvenlik duvarı kuralları kümesi. Yapılandırma doğrulanır doğrulanmaz, bir sonraki kurumsal istemci güncellemesi gelmeden önce konuğun anlık görüntüsünü alın.

Hipervizör bağdaştırıcılarını yeniden oluşturduğunda host-only ağlar yeniden numaralandırılır ve bu, 192.168.56.0/24 üzerine kurulmuş her yolu ve NAT kuralını sessizce geçersiz kılar. Yükseltmeden sonra ilk üç kontrolü sırayla yeniden çalıştırın; bu bir dakika sürer ve ana makinenin yolu hâlâ varken konuğun yeni alt ağa taşındığı durumu yakalar.

IPv6 kendi turunu ister. ip6tables kuralları, AAAA kayıtları ve ikinci ana makine yolu ailesi IPv4 kurulumunu izlemez ve IPv6 üzerinden erişilebilen kurumsal hizmet, IPv4 çalışırken kalıcı olarak bozuk görünecektir.

Geçse de geçmese de sırayla: ana makine konuğun host-only adresine ping atabilir; konuk tünele doğru iletir ve MASQUERADE yapar; ip route get iç önek için geçit olarak konuğu döndürür; kurumsal adlar sınırlı çözümleyici aracılığıyla çözülür; traceroute önce konuğu gösterir; ve aynı altı yanıt yeniden başlatmayı atlatır.