Xost trafigini VM ichidagi VPN orqali yo'naltirish: olti tekshiruv

Ketma-ket bajariladigan olti tekshiruv VM o'z xosti uchun VPN shlyuzi bo'la olishini aniqlaydi. Gipervayzor buning hech birini siz uchun qilmaydi: tunnel mehmonga tegishli, marshrut xostga tegishli, ular orasidagi tarmoq esa oddiy marshrutlashdir. Bu ro'yxatni saqlayman, chunki bitta qadamni o'tkazib yuborish har doim bir xil alomat beradi, sukunat, xost mehmonni xursandchilik bilan ping qiladi, lekin ichkaridagi hech narsaga yetib bormaydi.

Sababdan boshlang. Yoki korporativ mijoz faqat mehmon ichiga o'rnatiladi, yoki siyosat uni o'sha yerda ushlab turadi, va sizga hali ham xostdan ichki build server kerak. Agar xostga o'z mijozi ruxsat etilsa, shuni qiling: xostdagi bitta tunnel har doim ikkita tarmoq va NATdan afzal.

Tekshiruv 1: xostga manzil bera oladigan ulanish kerak

Xostda mehmonning ikkinchi adapteri bilan bir xil prefiksda interfeys bo'lishi kerak. VirtualBoxda host-only, VMware Workstationda host-only yoki maxsus VMnet, QEMU/KVMda ichki ko'prik yoki tap qurilmasi va Hyper-Vda Internal kaliti — barchasi mos. Mehmon 192.168.56.2, xost 192.168.56.1, prefiks 192.168.56.0/24 laboratoriyalarda ishlatadigan joylashuvim.

QEMUning foydalanuvchi rejimidagi tarmog'i (-netdev user, standart SLIRP backend) va VirtualBox NAT bu tekshiruvdan butunlay o'tmaydi. Mehmon paketlari xostdagi proksi jarayoniga yetib boradi, shuning uchun xost mehmon manzillarini tashuvchi qurilmani hech qachon ko'rmaydi va marshrutni yo'naltiradigan hech narsasi yo'q. Hyper-Vning Default Switch ham xuddi shu voqea. Agar xostdan ping 192.168.56.2 muvaffaqiyatsiz bo'lsa, to'xtang: keyin qo'shilgan hech qanday marshrut buni tuzatmaydi.

Tekshiruv 2: mehmon uzatadi va tarjima qiladi

Xostdan keladigan paketlar host-only manba manzili va ichki manzil bilan keladi, shuning uchun mehmon ularni uzatishi, so'ng o'z tunnel manzili orqasiga yashirishi kerak. Linux mehmonda bu uzatish, FORWARD accept juftligi va tunnelga qarab source NAT degani:

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 qoidasi odamlar tashlab ketadigan qismdir. Korporativ marshrutizatorlar 192.168.56.0/24 borligini kamdan-kam biladi; qoida bilan ichki serverlar mehmonning tunnel manzilini ko'rib unga javob beradi, javob esa mehmonga qaytish yo'lini topadi.

Windows mehmon noqulayroq. SYSTEM\CurrentControlSet\Services\Tcpip\Parameters ostidagi IPEnableRouter=1 uzatishni tarjimasiz yoqadi, shuning uchun u faqat korporativ marshrutlash allaqachon sizning host-only prefiksingizga qaytib ko'rsatadigan joyda ishlaydi. Internet Connection Sharing tarjima qiladi, lekin umumiy adapterni 192.168.137.1 ga qayta raqamlaydi, shuning uchun xost marshrutlarini yozishdan oldin u haqiqatda olgan manzilni o'qing.

Tekshiruv 3: xost marshrutlari mehmonni nomlaydi, tunnelni emas

Mehmondan faqat xostga kerakli prefikslarni o'tkazing. Linuxda har bir prefiksga bitta marshrut yetarli va u toza qaytadi:

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

Windowsda muqobili route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Sinov paytida -p ni tashqarida qoldiring, yomon marshrut qayta yuklashda o'lsin, va yo'l ishlagach uni qo'shing. Xostning standart marshrutini olib tashlamang, agar xostdagi har bir dastur tunneldan foydalanishi shart bo'lmasa; agar haqiqatan to'liq tunnel talab qilinsa, ikkita /1 marshrutini qo'shing va gipervayzor tarmog'iga to'g'ridan-to'g'ri marshrutni saqlang:

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 xostda interfeys metrikasini ham tekshiring. host-only adapter o'chirilgan paytda qo'shilgan marshrut jadvalda qoladi, lekin hech qachon trafik tashimaydi, va pastroq metrikali ikkinchi adapter xuddi shu prefiks uchun qidiruvni yutishi mumkin.

Tekshiruv 4: DNS marshrutga ergashadi, tunnelning standartiga emas

Marshrutlar paketlarni harakatlantiradi; qaysi nomlar paket yaratishini hal qiluvchi belgilaydi. Xostning hal qiluvchisini almashtirish o'rniga korporativ hal qiluvchini korporativ zona bilan cheklang va uni yangi marshrut allaqachon yetib boradigan DNS serveriga qarating. Xostda systemd-resolved bilan:

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

Windowsda nom hal qilish siyosati jadvalining yozuvi xuddi shu ishni qiladi: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Agar mehmon host-only manzilda o'z hal qiluvchisini ishlatsa, uning o'rniga o'sha manzilni ishlating, lekin u loopbackda emas, 192.168.56.2 da javob berishini tasdiqlagandan keyingina.

So'ng sekin sahifalar uchun DNSni ayblashdan oldin MTUni tekshiring. Tunnel interfeysi xostning 1500 baytli interfeysidan kichik, shuning uchun DF bitini qo'yib to'liq o'lchamli segmentlar yuboradigan xost ularni mehmon ichida bir joyda yo'qotadi. Klassik alomat — ishlaydigan ping va TLS qo'l berishdan keyin to'xtab qoladigan ichki veb dastur. Mehmonning uzatish yo'lida MSSni qisqartiring:

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

Tekshiruv 5: ikkala tomondan tasdiqlang

Xostdan ichki manzilga traceroute yoki tracert birinchi hop sifatida jismoniy shlyuzni emas, 192.168.56.2 ni ko'rsatishi kerak. Mehmonda xuddi shu urinishning chiqishini kuzating: tcpdump -ni any host 10.20.30.40 host-only tomonda uzatilgan so'rovni va tunnelda tarjima qilinganini ko'rsatadi. Chiqib, qaytib kelib ham xostni jim qoldiradigan so'rov qaytish yo'liga ishora qiladi.

Buning ko'p qismini ikkita nosozlik tushuntiradi. Yoki NAT qoidasi yo'qligi sababli mehmon tunneli host-only prefiksi uchun qaytish marshrutini tashimaydi, yoki xost marshruti qayta yuklashdan keyin mehmonda bo'lmagan manzilga ishora qiladi. O'tgan sessiya yozuvlariga ishonish o'rniga manzillarni ip -br addr va ip route get bilan qayta o'qing.

Tekshiruv 6: uni qayta yuklash va gipervayzor yangilanishiga chidamli qiling

Ikkala yarmini ham doimiy saqlang: xostda netplan yoki NetworkManager marshrut konfiguratsiyasi, Windowsda route add ... -p, va /etc/sysctl.d/ ichida net.ipv4.ip_forward=1 bilan mehmonda qayta yuklanadigan xavfsizlik devori qoidalari to'plami. Konfiguratsiya tasdiqlangan zahoti, keyingi korporativ mijoz yangilanishi kelishidan oldin mehmonning snapshotini oling.

Gipervayzor o'z adapterlarini qayta yaratganda host-only tarmoqlar qayta raqamlanadi, bu esa 192.168.56.0/24 ustiga qurilgan har bir marshrut va NAT qoidasini jimgina bekor qiladi. Yangilanishdan keyin dastlabki uchta tekshiruvni tartib bilan qayta bajaring; bu bir daqiqa oladi va xostda marshruti hali bor, mehmon esa yangi quyi tarmoqqa ko'chgan holatni ushlaydi.

IPv6 o'z aylanmasini talab qiladi. ip6tables qoidalari, AAAA yozuvlari va xost marshrutlarining ikkinchi oilasi IPv4 sozlamasiga ergashmaydi, va IPv6 orqali yetib boriladigan korporativ xizmat IPv4 ishlab turganda doim buzilgan ko'rinadi.

O'tdi yoki yo'q, tartib bilan: xost mehmonning host-only manzilini ping qila oladi; mehmon tunnelga qarab uzatadi va MASQUERADE qiladi; ip route get ichki prefiks uchun shlyuz sifatida mehmonni qaytaradi; korporativ nomlar cheklangan hal qiluvchi orqali hal qilinadi; traceroute mehmonni birinchi ko'rsatadi; va o'sha olti javob qayta yuklashga dosh beradi.