NAT VPN serveridami yoki routerdami? Ikkalasi ham ishlashi mumkin

Noutbukda ulanishni standart marshrut sifatida belgilash hamma eslaydigan qadamdir va shlyuzda hech narsani o'zgartirmaydigan ham shudir. Mijoz endi internet so'rovlarini tunnelga yuboradi; ular binodan chiqadimi, bu uzatish, tarjima nuqtasi va mijozning xususiy manziliga yetib boradigan qaytish yo'liga bog'liq. Ikki tartib uchalasini ham bera oladi, ular ishni turli joylarga qo'yadi va javob yo'nalishiga hech kim javobgar bo'lmasa, ikkalasi ham xuddi shu jim usulda muvaffaqiyatsiz bo'ladi. Ular orasidan tanlash mijoz hovuzini kim ko'rishi kerakligi haqidagi savol.

Afsona: mijoz marshruti chiqishni quradi

Majburiy tunnellashtirish mijoz tomonidagi siyosatdir: u trafik fizik adapterga emas, VPN adapteriga borishini hal qiladi. Microsoftning VPN marshrutlash hujjatlari bu bo'linish va majburlash xatti-harakatini tavsiflaydi va bu mijozning marshrutlar jadvali haqidagi bayonot, serverning uzatish qoidalari haqida emas. Mijoz nuqtai nazaridan tunnel internet yashaydigan joy; shlyuz nuqtai nazaridan paket yuqorida hech kim eshitmagan manzildan keldi. Hech bir tomon o'z-o'zidan noto'g'ri sozlanmagan va shuning uchun nosozlik noutbuk yonidagi odamga buzilgan serverdek ko'rinadi.

Aynan shu nomuvofiqlik maqolaning qolgan qismi hal qiladigan butun muammodir. Nimadir mijozning xususiy manzilini qaytariladigan qilishi kerak va tanlov qayerda ekanligida.

Avval javob yo'lini chizing

Har qanday sozlamaga tegishdan oldin yo'lni haqiqiy manzillar bilan yozib chiqing va ustiga ikkita mumkin bo'lgan tarjima nuqtasini belgilang. Bu laboratoriya 10.70.0.0/24 VPN hovuzidan foydalanadi, unda bitta mijoz 10.70.0.37 da, serverning LAN manzili 172.16.40.10, router 172.16.40.1 da va ommaviy chiqish 203.0.113.40 da.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

Internetni allaqachon ko'rib chiqayotgan server faqat o'z yo'lini isbotlaydi. Mijoz nomidan uzatilgan paket boshqa qaror bo'lib, uni o'sha mashinadagi uzatish siyosati qabul qiladi va odatda aynan shu yetishmaydi. Diagrammadagi uchta qaror nuqtasini belgilash suhbatni bir vaqtning o'zida ulardan bittasida ushlab turadi.

A varianti: VPN serverida tarjima

Bu yerda server paketni routerga berishdan oldin mijozning manbasini o'zining LAN manziliga tarjima qiladi, router esa chiqishda odatdagi tarjimasini qo'llaydi. Javobda routerning xaritalashi server manzilini, serverning xaritalashi mijoz manzilini tiklaydi. Ketma-ket ikkita holatli tarjima normal va amalga oshiriladigan, ikkalasi ham qayd etilsa; router hech qachon hovuzga marshrutga muhtoj emas va bu ushbu tartibning jozibasi.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

NAT bor deb taxmin qilish o'rniga serverda nima borligini ko'rish uchun bu o'qishlardan foydalaning. Blogdan ko'chirilgan Linux masquerade qoidasi Windows konfiguratsiyasi emas va VPN tinglovchisi uchun xostning tarmoq devoridagi ruxsat mijoz so'rovini oldinga uzatish ruxsati bilan bir xil siyosat emas. Serverning uzatish rolini o'zining boshqaruv interfeysidan tasdiqlang, so'ngra tarjimani alohida ko'rib chiqing, chunki ikkalasini ko'pincha joylashtirishning turli qismlari yoqadi.

B varianti: hovuzni routerga ko'chirish

Ikkinchi tartibda server mijozning haqiqiy manba manzilini uzatadi va router uni tarjima qiladi. Bu mijoz hovuzini chekkada ko'rinadigan qilib turadi, bu routerda trafik siyosati, jurnal yoki tekshiruv joylashgan bo'lsa yordam beradi. Bu shuningdek routerga 10.70.0.0/24 uchun 172.16.40.10 ga ishora qiluvchi qaytish marshruti hamda shu prefiksni haqiqatan o'z ichiga olgan internet siyosati kerakligini bildiradi; LAN quyi tarmog'i uchun yozilgan qoida hovuzga jim tarqalmaydi.

Buni chekka qurilma siyosatning mo'ljallangan egasi bo'lsa va marshrutlash hamda tarjima jadvallarida yana bitta prefiksni qabul qila olsa tanlang. Hovuz yuqorida ko'rinmas qolishi kerak bo'lsa va routerni o'sha jamoa boshqarmasa, server tomonidagi tarjimani tanlang. Hech bir variant mijozdagi hech qanday belgilash katagidan kelib chiqmaydi va hech biri umuman xavfsizroq emas; ular ko'rinuvchanlik va texnik xizmatni turli joylarga qo'yadi.

DNS, IPv6 va qabulni aniq qiling

Manzillar tarjimasi nomlarni hal qilishni tuzatmaydi. Mijoz VPN profili bilan berilgan hal qilgichdan, muayyan nom maydonlari uchun xususiy hal qilgichdan yoki tasdiqlangan ommaviy hal qilgichdan foydalanishi mumkin va bu siyosat ostida yetib bo'lmaydigan hal qilgich marshrutlash ishlagandan keyin ham muvaffaqiyatsizlikka uchraydi. Nom va manzilni alohida sinab ko'ring, ikki nosozlik hech qachon bitta hisobotda birlashmasin.

IPv6 dizaynda o'z abzasiga muhtoj. Ishlaydigan IPv4 tarjimasi IPv6 mijozlarining marshruti, haqiqiy ommaviy manbasi yoki tunnel yiqilganda ularni to'sadigan siyosati bor-yo'qligi haqida hech narsa demaydi. Buni aytilmay qoldirish mijozlarning yarmi shlyuzni jim chetlab o'tib, qolgan yarmi ishlashini bildiradi.

Qabul uchun ruxsat etilgan bitta mijoz so'rovini va uning javobini ikki chegara bo'ylab kuzatib boring va o'sha paytda har bir chegara qaysi manzilni ko'rishi kerakligini yozing. Aynan shu yozuv keyingi hovuz o'zgarishini yo'qolgan qaytish marshruti kimga tegishli degan bahs o'rniga besh daqiqalik tahrirga aylantiradi. Yozuvni chiptada emas, mijoz profili bilan birga saqlang, chunki keyingi muhandis birinchi navbatda profilni topadi.