Xost VPN ulanayotganda Hyper-V mehmoni DNSni yo'qotadi

Mehmon bugun ertalab yaxshi edi. Keyin xost Cisco AnyConnectni ishga tushirdi va VM DNSni, domen ishonchini va umumiy jildni yo'qotdi, ichida hech narsa o'zgarmagan holda. Xost tunneli va mehmon tarmog'i alohida yo'llar va birini ulash ikkinchisini jilmaydi. Mehmonning ichidan tashqariga qarab ishlang va biror narsani o'zgartirishdan oldin ko'rganlaringizni yozib oling.

Mehmon hali ham nimalarni ko'ra oladi

VMda manzilni, standart shlyuzni va hal qiluvchini bir marta xost ulanishidan oldin va bir marta keyin qayd eting. Manzilini saqlab, faqat nomlar yechimini yo'qotgan mehmon hal qiluvchi muammosiga ega. Hech qachon marshruti bo'lmagan mehmon yo'l muammosiga ega va ikkalasi ham boshqa ish talab qiladi. Xostdan ularni ajrata olmaysiz, shuning uchun o'qish ichkaridan kelishi kerak.

O'sha uchta o'qish, ikki marta olingan, sizning asosiy chizig'ingiz. Keyingi hamma narsa ularga qarab o'lchanadi.

Mehmon qaysi chiqishdan foydalanmoqda

Hyper-V bunga ikki buyruq bilan javob beradi: Get-VMSwitch switchlarni sanab chiqadi va Get-VMNetworkAdapter -VMName TestVM mehmon ulangan switchini ko'rsatadi. Default Switch Windows boshqaradigan NAT tarmog'i; tashqi switch trafikni jismoniy adapterga topshiradi; ichki switch kimdir NAT yoki router qo'shmaguncha hech narsa tashimaydi. VirtualBox xuddi shu uchta g'oyani NAT, NAT Network va bridged sifatida taqdim etadi.

Rejim xost tunnelining umuman ahamiyati bo'lishi mumkinmi-yo'qmi shuni hal qiladi. NAT mehmoni WinNAT tomonidan tarjima qilinadi va keyin xost steki tomonidan uzatiladi, shuning uchun u xostning marshrut jadvaliga amal qiladi; to'liq tunnel mijozi bilan uning trafigi VPN adapteriga kiradigan trafik bo'ladi va mijoz mahalliy quyi tarmoqni bloklaganda u tashlab yuboriladi. Tashqi switchga ko'prik qilingan mehmon xost marshrutlashiga hech qachon yetib bormaydi: uning freymlari jismoniy NICdan to'g'ridan-to'g'ri chiqadi, shuning uchun u ham tunnelni, ham mijozning mahalliy tarmoq siyosatini chetlab o'tadi.

Xost tunnelini Hyper-V bilan ulashish

Agar mehmonga tunnel kerak bo'lsa va o'z mijozini ishga tushira olmasa, Windows VPN ulanishini ulashishi mumkin. VPN adapterining xossalarini oching, Ulashishga o'ting va boshqa tarmoq foydalanuvchilariga u orqali ulanishga ruxsat bering. Uy tarmog'i ulanishini Hyper-V adapteriga yo'naltiring, vEthernet (Default Switch), keyin mehmonning ichidan yangi so'rovni sinab ko'ring.

Bu tartibni laboratoriya yechimi deb biling, chunki u shunday yo'l tutadi. U uzilishdan, qayta ulanishdan yoki xostni qayta yuklashdan keyin qayta qo'llanilishi kerak. Ba'zi Windows 11 buildlarida adapter ochiladigan ro'yxatda umuman yo'q va o'shanda bu yo'l yopiq.

Hyper-V xususiyatini qayta o'rnatish bir nechta qaysar mehmonni saqlab qoldi. Buni oxiriga qoldiring va avval mehmonning holatini qayd eting.

Quyi tarmoq filtrlanganda portlarni yo'naltirish

Mehmonning NAT quyi tarmog'ini filtrlaydigan xost VPN nomlar yechimini emas, to'g'ridan-to'g'ri kirishni buzadi. VM ishlayapti, lekin ssh [email protected] osilib qoladi, gipervayzor tarjimasi hali ham ishlayotganda. Ish uchun kerakli portlarni yo'naltiring va buning o'rniga xost manziliga ulaning. Quyidagi Vagrantfile satrlari SSH va bitta HTTPS xizmatini qamrab oladi; ikkalasi ham qayta yuklashdan oldin kiritiladi.

config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443

Nomlar yechimi alohida qaror va o'z tuzatishiga loyiq. O'sha NAT adapteri uchun xostning hal qiluvchi xususiyatini yoqing, yoki mehmonning ichidagi ichki DNS serverni qo'lda sozlang. Mehmonni umumiy hal qiluvchiga yo'naltirish ko'rishni ishga tushiradi va har bir ichki nomni buzadi, bu uzilishdan ham yomonroq, chunki muvaffaqiyat kabi ko'rinadi. Faqat ichki hal qiluvchi biladigan nomni sinab ko'ring.

Ishlaganini aytadigan tekshiruv

Ushbu o'zgarishlardan birortasidan keyin, xost VPN ulangan holatda mehmonning ichidan yangi so'rovni ishga tushiring, undan oldin emas. Qayta ulangandan keyin va qayta yuklangandan keyin ulashishni qayta tekshiring, chunki ulardan faqat bittasiga chidaydigan tuzatish tuzatish emas. Mehmonning hal qiluvchilar ro'yxati uning trafigi haqiqatda ishlatadigan tarmoqqa mos kelishini tasdiqlang. Keyin portlarni yo'naltirishni xost manzilidan sinab ko'ring, chunki mehmondan sinash hech narsani isbotlamaydi. Mehmonning ichidan ikkita PowerShell tekshiruvi hal qiluvchini va yo'naltirilgan portni qamrab oladi:

Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22

Har bir switch yoki drayver o'zgarishini uni qaytarish qadami bilan yozib oling. Microsoftning Hyper-V NAT qo'llanmasi Default Switch aslida nima ekanini tushuntiradi va u bilan ziddiyatga tushadigan ikkinchi NAT tarmog'ini yaratishdan oldin o'qishga arziydi.