Host trafikini VM içindəki VPN vasitəsilə yönləndirmək: altı yoxlama

Sıra ilə yerinə yetirilən altı yoxlama VM-in öz hostu üçün VPN şlüzü rolunu oynaya biləcəyini müəyyən edir. Hipervizor bunların heç birini sizin üçün etmir: tunel qonağa məxsusdur, marşrut hosta məxsusdur, aralarındakı şəbəkə isə adi marşrutlaşdırmadır. Siyahını saxlayıram, çünki bir addımı atlamaq həmişə eyni simptomu verir, sükutu, yəni host qonağı rahat ping edir və daxildə heç nəyə çatmır.

Səbəblə başlayın. Ya korporativ klient yalnız qonağın içində quraşdırılır, ya da siyasət onu orada saxlayır və sizə hələ də hostdan daxili build serveri lazımdır. Əgər hosta öz klienti icazə verilirsə, onu edin: hostda bir tunel hər dəfə iki şəbəkə üstəgəl NAT-dan yaxşıdır.

Yoxlama 1: host ünvanlaya bildiyi bir əlaqəyə ehtiyac duyur

Host qonağın ikinci adapteri ilə eyni prefiksdə yerləşən interfeysə sahib olmalıdır. VirtualBox-da host-only, VMware Workstation-da host-only və ya fərdi VMnet, QEMU/KVM-də daxili körpü və ya tap cihazı, Hyper-V-də Internal keçidi hamısı uyğundur. Qonaq 192.168.56.2, host 192.168.56.1, prefiks 192.168.56.0/24 laboratoriyalarda istifadə etdiyim sxemdir.

QEMU istifadəçi rejimli şəbəkə (-netdev user, standart SLIRP backend) və VirtualBox NAT bu yoxlamadan tamamilə keçmir. Qonaq paketləri hostdakı proxy prosesinə çatır, buna görə host qonağın ünvanlarını daşıyan cihaz görmür və marşrutu yönəltmək üçün heç nəyi olmur. Hyper-V-nin Default Switch-i də eyni hekayədir. Əgər hostdan ping 192.168.56.2 uğursuz olursa, dayanın: sonradan əlavə edilən heç bir marşrut bunu düzəltməyəcək.

Yoxlama 2: qonaq yönləndirir və tərcümə edir

Hostdan gələn paketlər host-only mənbə ünvanı və daxili təyinatla gəlir, buna görə qonaq onları yönləndirməli, sonra öz tunel ünvanının arxasında gizlətməlidir. Linux qonaqda bu, yönləndirmə, FORWARD qəbul cütü və tunelə doğru mənbə NAT deməkdir:

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 qaydası insanların atladığı hissədir. Korporativ marşrutlaşdırıcılar 192.168.56.0/24-in mövcud olduğunu nadir hallarda bilir; qayda ilə daxili serverlər qonağın tunel ünvanını görür və cavab verir, cavab da qonağa geri yol tapır.

Windows qonaq daha əlcəksizdir. SYSTEM\CurrentControlSet\Services\Tcpip\Parameters altında IPEnableRouter=1 tərcümə olmadan yönləndirməni açır, buna görə yalnız korporativ marşrutlaşdırmanın artıq sizin host-only prefiksinizə geri yönəldiyi yerdə işləyir. Internet Connection Sharing tərcümə edir, lakin paylaşılan adapteri 192.168.137.1-a yenidən nömrələyir, buna görə host marşrutlarını yazmadan əvvəl onun həqiqətən aldığı ünvanı oxuyun.

Yoxlama 3: host marşrutları tuneli deyil, qonağı göstərir

Yalnız hostun ehtiyac duyduğu prefiksləri qonaqdan keçirin. Linuxda hər prefiks üçün bir marşrut kifayətdir və təmiz şəkildə geri qaytarılır:

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

Windowsda ekvivalenti route add 10.20.0.0 mask 255.255.0.0 192.168.56.2-dir. Hələ sınaqdan keçirərkən -p-i buraxın ki, pis marşrut yenidən başlatmada ölsün, yol işləyəndə isə onu əlavə edin. Hər host tətbiqi tuneldən istifadə etməlidirsə, hostun defolt marşrutunu silməyin; əgər həqiqətən tam tunel tələb olunursa, iki /1 marşrutunu əlavə edin və hipervizor şəbəkəsinə birbaşa marşrutu saxlayın:

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 hostda interfeys metrikanı da yoxlayın. Host-only adapter söndürülmüşkən əlavə edilən marşrut cədvəldə qalır, lakin heç vaxt trafik daşımır və daha aşağı metriklə ikinci adapter eyni prefiks üçün axtarışı udu bilər.

Yoxlama 4: DNS tunelin defoltunu deyil, marşrutu izləyir

Marşrutlar paketləri hərəkət etdirir; həlledici hansı adların paket yaradacağına qərar verir. Korporativ həlledicini host həlledicisini əvəz etmək yerinə korporativ zonaya bağlayın və onu yeni marşrutun artıq çatdığı DNS serverinə yönəldin. Hostda systemd-resolved ilə:

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

Windowsda ad həlli siyasəti cədvəlinin qeydi eyni işi görür: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Əgər qonaq öz həlledicisini host-only ünvanında işlədirsə, onun yerinə həmin ünvandan istifadə edin, ancaq onun loopback-də deyil, 192.168.56.2 üzərində cavab verdiyini təsdiqlədikdən sonra.

Sonra yavaş səhifələr üçün DNS-i günahlandırmadan əvvəl MTU-nu yoxlayın. Tunel interfeysi hostun 1500 baytlıq interfeysindən kiçikdir, buna görə DF biti qoyulmuş tam ölçülü seqmentlər göndərən host onları qonağın içində bir yerdə itirir. Klassik simptom işləyən ping və TLS əl sıxışmasından sonra dayanan daxili veb tətbiqidir. Qonağın yönləndirmə yolunda MSS-i sıxın:

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

Yoxlama 5: hər iki tərəfdən yoxlayın

Hostdan daxili ünvana traceroute və ya tracert ilk hopp kimi fiziki şlüzü deyil, 192.168.56.2 göstərməlidir. Qonaqda eyni cəhdin çıxışını izləyin: tcpdump -ni any host 10.20.30.40 yönləndirilmiş sorğunu host-only tərəfdə, tərcümə edilmişini isə tuneldə göstərir. Çıxan, qayıdan və hostu yenə də səssiz qoyan sorğu geri dönüş yolunu göstərir.

Uğursuzluqların çoxunu iki hal izah edir. Ya qonaq tuneli host-only prefiksi üçün geri marşrut daşımır, çünki NAT qaydası yoxdur, ya da host marşrutu qonağın yenidən başlatmadan sonra artıq daşımadığı ünvanı göstərir. Keçən sessiyanın qeydlərinə güvənmək əvəzinə ünvanları ip -br addr və ip route get ilə yenidən oxuyun.

Yoxlama 6: yenidən başlatmaya və hipervizor yeniləməsinə dözməsini təmin edin

Hər iki yarısını saxlayın: hostda netplan və ya NetworkManager marşrut konfiqurasiyası, Windowsda route add ... -p, və /etc/sysctl.d/ içində net.ipv4.ip_forward=1 üstəgəl qonaqda yenidən yüklənən firewall qaydalar dəsti. Konfiqurasiya təsdiqlənən kimi, növbəti korporativ klient yeniləməsi gəlməzdən əvvəl qonağın snapshotunu götürün.

Hipervizor adapterlərini yenidən yaratdıqda host-only şəbəkələr yenidən nömrələnir və bu, 192.168.56.0/24 üzərində qurulmuş hər marşrutu və NAT qaydasını səssizcə etibarsız edir. Yeniləmədən sonra ilk üç yoxlamanı sıra ilə yenidən keçirin; bu bir dəqiqə çəkir və hostun marşrutu qaldığı halda qonağın yeni alt şəbəkəyə keçdiyi halı tutur.

IPv6 ayrıca keçid tələb edir. ip6tables qaydaları, AAAA qeydləri və ikinci host marşrut ailəsi IPv4 quraşdırmasını izləmir və IPv6 üzərindən çatılan korporativ xidmət IPv4 işləyərkən daim pozulmuş görünəcək.

Keçsin ya keçməsin, sıra ilə: host qonağın host-only ünvanını ping edə bilir; qonaq tunelə doğru yönləndirir və MASQUERADE edir; ip route get daxili prefiks üçün şlüz kimi qonağı qaytarır; korporativ adlar məhdudlaşdırılmış həlledici vasitəsilə həll olunur; traceroute qonağı birinci göstərir; və eyni altı cavab yenidən başlatmaya dözür.