VM‘ingiz host VPN‘idan foydalanadimi? Mehmon ichidan sinab ko‘ring

Hostning umumiy IP manzilini tekshirasiz, unda VPN ko‘rinadi va VM himoyalangan deb xulosa qilasiz. Bu xulosa ushbu sinov bilan tasdiqlanmaydi. Mehmonning o‘z marshrutlash jadvali, o‘z resolversi va o‘z interfeyslari bor, va hostning chiqish manzili ular haqida hech narsa demaydi.

Sinov mehmon ichida bajarilishi kerak va nima o‘lchanganini aytishi kerak.

Host brauzeridan emas, mehmon ichidan boshlang

Avval gipervisorning tarmoq rejimini yozib oling: NAT, bridged, host-only yoki macvtap. NAT rejimida host mehmon trafigini marshrutlaydi, shuning uchun host tunnelining qo‘llanishi yoki qo‘llanmasligi klient marshrutlarni qanday o‘rnatishiga bog‘liq. Bridged rejimida mehmon fizik LANdagi teng huquqli ishtirokchi, host tunnelining esa ahamiyati yo‘q. Bu ikki rejim bir xil host konfiguratsiyasidan qarama-qarshi javob beradi.

Biror narsani o‘zgartirishdan oldin rejimni yozib qo‘ying, chunki natijaning ma’nosi shunga bog‘liq.

Manzili sizga ma’lum bo‘lgan bitta so‘rov yuboring

O‘zi ko‘rgan manba manzilini bildiradigan xizmatga zararsiz so‘rov yuboring. So‘ngra o‘sha manzil uchun mehmonning o‘z marshrutlash qarorini tekshiring: ip route get 203.0.113.5 mehmon foydalanadigan interfeys va shlyuzni chop etadi.

Agar interfeys mehmonning oddiy NIC‘i bo‘lsa, trafik mehmon ichidagi tunneldan o‘tmaydi.

Ikkinchi adapter, proksi sozlamasi yoki mehmon tomonidagi VPN klienti bitta dastur uchun javobni o‘zgartirib, boshqasi uchun o‘zgartirmasligi mumkin. Shell‘dan kelgan umumiy so‘rovni emas, sizga haqiqatan muhim bo‘lgan dasturni sinab ko‘ring.

Resolverni alohida tekshiring

O‘zgargan chiqish manzili o‘sha host nomini qaysi resolver ishlaganini aytmaydi. Nomni platformaga mos vosita bilan aniq so‘rang va qaysi server javob berganini yozib qo‘ying. Split DNS resolver savoli va marshrutlash savoli turli javoblarga ega ekanini bildiradi.

Bu ikkisi har qanday yo‘nalishda farq qilishi mumkin va aynan shu farq ko‘pincha haqiqiy xatodir.

systemd hostda resolvectl query javob ortidagi interfeys va DNS serverni nomlaydi. Eski konfiguratsiyalar serverni dig chiqishida ko‘rsatadi. Qanday bo‘lsa ham, gap javob keldi-kelmadida emas, qaysi server javob berganini ko‘rishda.

Faqat muvaffaqiyatni emas, muvaffaqiyatsizlik siyosatini ham sinang

Agar talab tunnel tashqarisiga hech qanday trafik chiqmasligi bo‘lsa, muvaffaqiyatli so‘rov hech narsani isbotlamaydi. Klient qo‘llab-quvvatlaydigan boshqariladigan muvaffaqiyatsizlik sinovidan foydalaning: tunnelni qo‘llab-quvvatlanadigan usulda to‘xtating va mehmonning yangi so‘rovi bloklanishini ko‘ring. Host klientining kill switch har qanday virtual yo‘naltirish sxemasini qamrab oladi deb o‘ylamang. Uning hujjatlashtirilgan qamrovi ishonishingiz mumkin bo‘lgan yagona narsa.

Tunnel uzilganda fizik NIC‘ga qaytadigan mehmon NAT rejimi ruxsat bergan narsani aynan qilmoqda.

Rejim va qamrovni yozib oling

Gipervisor rejimini, mehmon interfeysi va yo‘lini, resolverni va siz sinagan dasturni yozing. Sanani ham qo‘shing, chunki snapshotni tiklash yoki gipervisorni yangilash to‘rttasini ham o‘zgartirishi mumkin.

Agar IPv4 tunneldan o‘tgan bo‘lsa, shuni ayting. Bu da’voni IPv6, boshqa nomlar maydoni yoki boshqa tarmoqdagi boshqa VM‘ga kengaytirmang.