NAT yoki bridged VM tarmog'i: VPN trafigini qaysi biri olib o'tadi?

NAT mehmonlari xost tunnelini faqat klient yo'l bo'yicha tunnel qilsa qarzga oladi; bridged mehmonlar o'zi yo'l tanlaydi. Mehmonni sinab ko'ring, so'ng mos rejimni tanlang.

Bridged va NAT bir xil mehmonni VPN'ingizga ulashning ikki usuli emas; ular har qanday tunnel ishga tushishidan oldin mehmon paketlari kimga tegishli ekanini hal qiladi. NAT rejimida gipervizor mehmon trafigini qayta yozadi va uni xost tomonidagi koddan chiqaradi, shuning uchun mehmon xost o'sha kodga bergan yo'ldan boradi. Bridged rejimida mehmon jismoniy segmentda o'zining kanal qatlami identifikatorini oladi va o'z standart shlyuzini tanlaydi, bu esa xost tunnelini, tunnelni LAN routeri qilmasa, u uchun ahamiyatsiz qiladi. Men VM'ni VPN'da turgan narsa deb qarashni to'xtatib, buni o'sha mehmonning standart yo'li qayerga qaratilgani haqidagi savol deb qaray boshladim. Quyidagi sinov har bir rejim uchun bir necha daqiqa vaqt oladi va taxminlarsiz masalani hal qiladi.

NAT mehmonni xost yo'llari amal qiladigan gipervizor kodi orqasida ushlab turadi

VirtualBox'da NAT mehmoni 10.0.2.0/24 ichida, 10.0.2.2 da virtual shlyuz, 10.0.2.3 da DNS proksi bilan o'tiradi va jismoniy tarmoqqa o'z yo'li yo'q. Chiquvchi paketlarni NAT mexanizmi oladi, manba xost bo'lishi uchun qayta yozadi va xostning IP stekiga uzatadi. U yerdan mehmon trafigi xost oqimi bo'ladi, yo'l qidiruvi esa manzil bo'yicha bo'ladi: xostda 0.0.0.0/1 va 128.0.0.0/1 o'rnatadigan to'liq tunnel klienti VM borligini bilmasdan uni ushlab oladi. Oracle'ning VirtualBox tarmoq bo'limi o'z qurilmangizda manzillarni tekshirishni istasangiz, bu standart qiymatlarni sanab o'tadi.

libvirt'ning standart tarmog'i xuddi shu joyga 192.168.122.0/24 dan yetib boradi, u yerda dnsmasq ijara tarqatadi va xost quyi tarmoqni maskalaydi, shuning uchun mehmon paketlari yana xostning yo'l qaroriga keladi. Istisno — trafikni yo'l bo'yicha emas, jarayon bo'yicha tanlaydigan klient. Agar bo'lingan tunnel ro'yxatida faqat brauzeringiz bo'lsa, NAT mexanizmi bu ro'yxatda yo'q va xost brauzeri hali ham qoplangandek ko'rinib turganda mehmon mashinadan tunnelsiz chiqib ketadi. Bir xil quyi tarmoq, qarama-qarshi natija.

Bridged mehmonga jismoniy LAN'da o'z joyini beradi

Bridged mehmon haqiqiy adapterga ulangan virtual NIC oladi, o'z MAC manzilini oladi va jismoniy tarmoqdan DHCP ijarasini oladi. Uning standart shlyuzi LAN routeri, gipervizor emas, kadrlari esa o'sha adapter orqali simga chiqadi. Xostning tunnel yo'llari xost jadvalida turadi va hech qachon so'ralmaydi, chunki mehmon kadrlari hech qachon xostning IP stekiga kirmaydi.

Bu ikki tomonga ham kesadi. mDNS va SMB ko'rish ishlay boshlaydi, chunki mehmon LAN eshittirish trafigini ko'radi va mehmon o'rtada xost xavfsizlik devori bo'lmagan holda bir segmentdagi boshqa mashinalardan yetib boriladigan bo'ladi. Bridging bor tunnel orqali mehmonni siqib o'tkazish usuli ham emas: VM'ni xostning WireGuard yoki OpenVPN interfeysiga ulash VirtualBox yoki libvirt siz uchun qiladigan ish emas. Agar bridged mehmon tunnel qilinishi shart bo'lsa, tunnel o'sha LAN'ning bir joyida tugashi kerak.

Bahsni tugatadigan sinov

Ikkala rejimda ham bir xil tekshiruvlarni o'tkazing va javoblarni yozib qo'ying:

  • Xostda, curl -s https://ifconfig.me ommaviy v4 manzilini beradi.
  • Mehmonda, xuddi shu buyruq, qo'shimcha ip route Linux'da yoki Get-NetRoute -DestinationPrefix 0.0.0.0/0 Windows'da standart shlyuz uchun.
  • Rasolvchining kimligi: resolvectl status yoki cat /etc/resolv.conf mehmonda, u 10.0.2.3 ga yoki LAN serveriga qaratilganini ko'rish uchun.
  • Manzil oilasi: ip -6 addr show scope global va bitta v6 so'rovi, chunki v4 tunnel mehmon ega bo'lishi mumkin bo'lgan global v6 manzili haqida hech narsa demaydi.

Mos keladigan ommaviy manzillar mehmon xost yo'lida ekanini bildiradi. LAN'ning oddiy chiqishiga mos keladigan mehmon manzili esa yo'qligini bildiradi. Odamlar o'tkazib yuboradigan qadam — nazorat: xost tunnelini tushiring va mehmon so'rovini takrorlang. Agar mehmon ko'rishda davom etsa, u hech qachon xost tunneliga bog'liq bo'lmagan, rejim nomi nima deyishidan qat'i nazar. NAT rejimida xost tunneli tushirilganda mehmon internetni yo'qotishi kerak, agar klient tunnelsiz trafikka ruxsat berishga sozlanmagan bo'lsa, buni alohida bilish arziydi.

Ikki signal yolg'on gapiradi. Muvaffaqiyatli ping yetib borishni isbotlaydi, chiqish yo'lini emas. Va DNS 10.0.2.3 proksi tomonidan xost rasolvchisi orqali javoblanishi mumkin, TCP esa boshqa yo'ldan ketayotgan bo'lishi mumkin — shunday qilib yuklanadigan sahifa va hech qachon tugamaydigan kirish paydo bo'ladi.

Qaysi rejim ishga mos keladi

Rejim yo'l qaroridir, shuning uchun uni odatga emas, talabga qarab tanlang:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

Birinchi qator odamlar qoqiladigan joy: NAT va xostda to'liq tunnel klienti mehmonni haqiqatan qoplaydi, lekin faqat klient yo'l bo'yicha tunnel qilsa va xostning yuqori kanali o'sha tunnel bo'lsa. Klientni faqat brauzerga ruxsat beruvchi ro'yxatga o'tkazing, qoplov qayerda ham xato ko'rsatmasdan yo'qoladi. To'rtinchi qator teskari xato: qulaylik uchun bridged qilingan va ofis LAN'ida jimgina SMB yoki SSH'ga javob bera boshlagan mehmon.

VPN'ga ag'dariladigan nosozliklar

Windows'da NAT tarjimasi VirtualBox VM jarayoni ichida ishlaydi, shuning uchun ilova bo'yicha klient ro'yxatida virtual mashinalar uchun umumiy qoida emas, aynan o'sha obraz bo'lishi kerak. Klient yangilanishi ruxsat etilgan jarayonlar ro'yxatini qayta qurganda NAT mehmonlari qoplovni birinchi bo'lib yo'qotadi va hisobot xost joyida bo'lganda LAN'ga yetadigan, ammo internetga yetmaydigan VM kabi o'qiladi.

Wi-Fi'ga bridging — yana bir klassika. Kirish nuqtalari begona manba MAC'li kadrlarni kamdan-kam uzatadi, shuning uchun wlan0 ustidagi ko'prik yo darhol ishlamaydi, yo AP'dagi klient izolyatsiyasi uni tashlay boshlaguncha ishlaydi. VirtualBox simsiz adapterni baribir ro'yxatda taklif qiladi. Agar xost Wi-Fi'da bo'lsa va mehmon bridged bo'lishi shart bo'lsa, taxmin qilish o'rniga sinovni rejalashtiring.

MTU — uchinchisi. Bridged mehmon LAN'ning 1500 baytli MTU'sini saqlaydi va agar o'z WireGuard klientini 1420 da ishga tushirsa, katta TLS qo'l siqishlari tiqilib qoladi, kichik so'rovlar esa o'tadi. NAT ostida xost tunnelining MTU'si xostning muammosi, lekin mehmon hali ham 1500 ga ishonadi va don't-fragment biti qo'yilgan UDP xuddi shunday qora tuynukka tushadi.

Rejimni yozib qo'ying va har qanday adapter o'zgarishidan keyin qayta tekshiring

Rejimni, ko'prik ishlatadigan xost interfeysini, mehmonning standart shlyuzini, uning rasolvchisini va v4 hamda v6 chiqish manzillarini yozib qo'ying. Aynan shu yozuv keyingi nosozlikni arzon qiladi: noutbuk dock'dan Wi-Fi'ga o'tganda bridged mehmon ko'prik bilan boshqa jismoniy adapterga o'tadi va boshqa quyi tarmoqda qayta ijara olishi mumkin, NAT mehmon esa 10.0.2.x manzilini saqlab, jimgina boshqa yuqori kanalni meros oladi.

Tiketni yopishdan oldin quyidagilarning har birini tasdiqlang:

  • Mehmonning chiqish manzili xostning chiqish manzilidan farq qiladi, ya'ni u xost tunnelida emas.
  • Rasolvchi 10.0.2.3 proksi yoki LAN serveri va qaysi biri javob berganini bilasiz.
  • Agar tunnel loyihasi faqat v4 bo'lsa, mehmonda global v6 manzil yo'q.
  • Xost tunneli tushirilganda mehmon ko'rishni to'xtatadi, yoki endi u hech qachon unga bog'liq bo'lmaganini bilasiz.
  • Mehmon ko'rishga haqqi yo'q LAN eshittirish trafigini ko'rmaydi.

O'xshash maqolalar