RRAS VPN mijozlariga o‘z IPv4 hovuzi va qaytish yo‘li kerak

VPN mijozi ulanadi va manzil oladi, lekin unga kerak bo‘lgan LAN xosti hali ham javob bera olmaydi. Windows Routing and Remote Access ichida VPN mijozlarining ichki manzili serverning LAN adapteridan alohida sozlangan hovuzdan keladi, LAN tomoniga esa o‘sha hovuzga qaytish marshruti kerak. Ikki o‘zgarish, bitta emas, va ular turli yo‘llar bilan muvaffaqiyatsiz bo‘ladi. Eski diapazonlar bekor qilinishidan oldin manzil rejasi va qaytish yo‘li isbotlanishi uchun ularni tartib bilan bajaring.

Konsolni ochishdan oldin diapazonni zaxiralang

LAN, boshqa VPN diapazonlari yoki saytga marshrutlanadigan biror narsa bilan qoplanmaydigan prefiks tanlang. /24 sinov uchun qulay o‘lcham, va birinchi ishlatsa bo‘ladigan qismini mijozlarga berish mumkin, qolgani o‘sish uchun bo‘sh qoladi. Konsolga kiritishdan oldin uni maqsadi va egasi bilan yozib qo‘ying. Keyingi bo‘linish qayta raqamlashga majbur qilmasligi uchun blokning ikki chetida joy qoldiring.

Faqat konsolda yashaydigan manzil rejasi to‘qnashuvdan bitta qayta qurish narida turadi. U o‘sishga ham moyil: kimdir keyinroq ikkinchi diapazon qo‘shadi va hech kim birinchisini tekshirmaydi. Rejani chat mavzusida emas, server hujjatlari yonida saqlang.

Serverning LAN adapteri bu hovuzni belgilamaydi. Ommaviy tinglovchini o‘zgartirish yoki LANga adapter qo‘shish butunlay boshqa ish qiladi. Shuning uchun mijozlar ulanib, baribir noto‘g‘ri joydan manzil olishlari mumkin. Hovuz serverning IPv4 xossalarida yashaydi, adapterlar ro‘yxatida emas.

Usulni o‘zgartirish diapazon qo‘shish emas

RRASda tayinlash usuli va diapazonlar to‘plami bor. DHCPdan statik hovuzga o‘tish usul o‘zgarishi. Statik hovuz allaqachon faol bo‘lganda yana bir blok qo‘shish diapazon o‘zgarishi.

Har qaysisini ishga tushirishdan oldin ikkala amalni ko‘zdan kechiring va qaysi biri serverning hozirgi holatiga mos kelishini o‘qing:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

Agar server hali DHCP tayinlashida bo‘lsa, ikkinchi cmdlet muvaffaqiyatsiz bo‘ladi yoki yaroqsiz hovuz yaratadi. Birinchisi mavjud hovuzni kengaytirish o‘rniga usulni almashtiradi. Hech bir ko‘rish hech narsani qo‘llamaydi, shuning uchun mos keladiganini ishga tushiring, so‘ngra hosil bo‘lgan hovuzni konsolda tasdiqlang. Server qaysi holatda ekaniga ishonchingiz komil bo‘lmasa, IPv4 xossalari sahifasida tayinlash usulini o‘qing va sozlangan diapazonlarni sanab chiqing:

Get-VpnIPAddressRange

Bo‘sh diapazonlar ro‘yxati bilan DHCP usuli birinchi ko‘rish qo‘llanilishini bildiradi. Mavjud diapazon bilan statik manzillar hovuzi ikkinchisi qo‘llanilishini bildiradi.

Sozlama talab qilishi mumkin bo‘lgan xizmatni qayta ishga tushirishni hisobga oling va ulangan mijozlar darhol qayta raqamlanadi deb o‘ylamang. Eski manzilini qayta ulanmaguncha saqlaydigan mijoz odatdagidek harakat qiladi. O‘zgarishni qayta ulanish maqbul bo‘lgan oyna uchun rejalashtiring.

LANga qaytish marshruti kerak

Faraz qilaylik, LAN 10.60.0.0/24, RRAS serveri esa unda 10.60.0.10. O‘sha LANdagi 10.250.50.0/24 dagi mijozga javob beradigan xostga RRAS serveri orqali hovuzga yo‘l kerak. Bu yo‘lsiz so‘rov yetib boradi va javob o‘ladi.

Agar xostning standart shlyuzi boshqa marshrutizator bo‘lsa, o‘sha marshrutizatorga VPN prefiksi uchun qaytish marshruti kerak. RRAS serveridagi statik marshrut bu yerda yordam bermaydi; qaytish yo‘li LAN shlyuziga ega qurilmada bo‘lishi kerak, shuning uchun uni marshrutlash jadvaliga yoki dinamik marshrutlash jarayoniga qo‘shing, sayt nima ishlatsa, shunga ko‘ra.

Yangi manba diapazoniga qarshi xostning tarmoq devori va har qanday tarmoqqa kirish qoidalarini ham tekshiring. Eski mijoz diapazoni uchun yozilgan qoidalar tayinlash muvaffaqiyatli bo‘lsa ham yangisini rad etadi. Mijozning LANga yo‘nalgan marshrutlari va DNS hal qilish alohida talablar, va tunnel sog‘lom ko‘ringanda ikkisi ham muvaffaqiyatsiz bo‘lishi mumkin. Har birini alohida sinab ko‘ring.

Eskisini bekor qilishdan oldin yangi hovuzni bitta qurilmada isbotlang

O‘zingiz boshqaradigan bitta avtorizatsiyani oling, qayta ulanib mijoz olgan hovuz manzilini o‘qing. O‘sha bitta raqam tayinlashni marshrutlashdan ajratadi. So‘ngra nomlangan dasturda sinab ko‘ring, qaytish trafigini kuzating va rad etilgan holda qolishi kerak bo‘lgan manzilni sinang. Uch kuzatuv, uch xil muvaffaqiyatsizlik usuli.

Nomlarni hal qilish o‘z sinoviga loyiq: IP orqali kirish ishlashi mumkin, mijozning DNSi esa hali yeta olmaydigan hal qiluvchiga ishora qiladi. LANdagi DNS serverga faqat mijozning u yerga marshruti bo‘lsa va server yangi diapazondan so‘rovlarni qabul qilsa yetish mumkin. Hovuz ko‘chganda ikkisi ham odatiy o‘tkazib yuborishlardir.

Eski diapazonlar va ularning istisnolarini faol seanslar va texnik xizmat jarayonini hisobga olgandan keyingina bekor qiling. Yangi manzil bilan ulangan mijoz tayinlashni isbotlaydi, kirish siyosatini emas. Eski diapazonni undan foydalangan oxirgi seans tugaguncha hujjatlashtirilgan holda saqlang.

Natijani uch kuzatuv bilan tekshiring

Qabul qilish uchun uchta fakt kerak: mijozda yangi hovuzdan manzil bor, LAN xosti unga yetib javob ola oladi, va rad etilgan manzil hali ham rad etilgan. Har birining o‘z tekshiruvi bor, shuning uchun muvaffaqiyatsizlik tayinlash, marshrutlash yoki siyosatga ishora qiladi. Ularni shu tartibda bajaring.

Mijozdan manzilni va bitta LAN xostiga marshrutni tasdiqlang:

ipconfig | findstr /i "IPv4"
route print -4

LAN xostidan qaytish yo‘lini va siyosatni bir o‘tishda tasdiqlang. Agar ping muvaffaqiyatsiz bo‘lsa-yu dastur ishlasa, yetishmayotgan qism marshrut emas, ICMP qoidasi bo‘lishi ehtimoli katta. Agar ikkisi ham muvaffaqiyatsiz bo‘lsa, VPNni tahrirlashdan oldin xostdagi marshrutni o‘qing. Uch natijani o‘zgarish chiptasiga yozing, keyingi odam dalillardan boshlasin.