VPN ulangan paytda mahalliy tarmoqqa kirib bo’lmayaptimi? To’rt tekshiruv

Tunnel ko’tariladi, intranet ko’rinadi, printer esa javob berishni to’xtatadi. LANda hech narsa buzilmagan; mijoz endi mahalliy deb hisoblamaydigan manzillar uchun qaysi yo’lni ishlatishini o’zgartirgan. Quyidagi to’rt tekshiruvni tartib bilan bajaring va bittasi aniq nomuvofiqlik ko’rsatganda to’xtang, chunki bir xil alomatning to’rtta keng tarqalgan sababi bor va ulardan faqat bittasi VPNni tahrirlash bilan tuzatiladi.

Avval mijoz o’rnatgan marshrut jadvalini ko’ring

VPN ulangan paytda mijozning marshrut jadvalini oching. Linuxda ip route, Windowsda route print yoki Get-NetRoute, macOSda netstat -rn ishlating. Siz tunnel orqali o’tadigan standart marshrutni va jismoniy standart marshrutga nima bo’lganini qidiryapsiz.

To’liq tunnel mijozi 0.0.0.0/0 ni almashtirish o’rniga ko’pincha ikkita yarim standart marshrut qo’shadi: 0.0.0.0/1 va 128.0.0.0/1. Asl standart marshrut ko’rinib turadi, lekin har bir qidiruvda yutqazadi, shuning uchun jadval butun ko’rinishi mumkin, ammo subnetdan tashqaridagi barcha trafik siljiydi. Agar VPN mijozi bo’lingan tunnel variantini taklif qilsa va siyosat ruxsat bersa, bu eng toza tuzatish.

Agar tunnel standart bo’lib qolishi kerak bo’lsa, uning o’rniga mahalliy subnetni mahkamlang. Linuxda marshrut jismoniy interfeys va shlyuzni nomlaydi; Windowsda -p qo’shib uni doimiy qiling va interfeys raqamini taxmin qilmasdan route print dan o’qing:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Mahkamlangan marshrut u nomlagan manzil o’zgarmaguncha turadi. Har ulanishda Wi-Fi adapteriga yangi raqam oladigan noutbuk qoidani yana buzadi, shuning uchun tuzatish muvaffaqiyatsiz bo’ldi deb xulosa qilishdan oldin interfeys manzilini tekshiring.

Ikkinchidan, manzil boshidan mahalliy bo’lganini tasdiqlang

Agar manzil ulangan subnet ichida bo’lsa, tunnelning standart marshruti hech qachon qo’llanilmaydi va VPN sabab emas. 192.168.1.0/24 bo’lgan mijozdagi 192.168.1.40 printeri ulangan marshrutdan foydalanadi; agar bu manzil ishlamasa, VPN emas, qurilma, switch yoki mijozning firevallini ko’ring.

Odamlarni chalg’itadigan holat mahalliy server uchun umumiy manzildir. LAN ichidan routerni WAN manziliga yetib borib qaytish hairpin NAT talab qiladi va ko’p routerlar buni port yo’naltirish uchun umuman amalga oshirmaydi. Xususiy manzilni umumiy manzil yonida sinab ko’ring. Agar xususiy manzil ishlab, umumiy ishlamasa, VPN faqat avvaldan mavjud bo’lgan NAT cheklovini ochib bergan.

Xost nomi buni yanada yomonlashtiradi. Agar mahalliy nom endi umumiy manzilga yechilsa, mijoz qaytib kela olmaydigan yo’lni sinashda davom etadi. Sinov uchun xususiy manzildan foydalaning, so’ngra yana bir port yo’naltirish qo’shish o’rniga nomni tuzating.

Uchinchidan, endi nomlarga kim javob berayotganini ko’ring

Korporativ rezolver intranetni biladi va odatda NAS xost nomi, printerning Bonjour nomi yoki routerning mahalliy taxallusi haqida hech narsa bilmaydi. VPN o’z DNS serverlarini itarib yuborganda, bu nomlar yechilishni to’xtatadi, garchi manzillari hali ham yetib boriladigan bo’lsa. Nomni to’g’ridan-to’g’ri so’rang va javobni qurilma egallashini bilgan manzil bilan solishtiring.

Linuxda resolvectl query nas.local qaysi rezolver javob berganini ko’rsatadi. Windowsda nslookup nas.local serverni nomlaydi, ipconfig /all esa rezolverlar tartibini ko’rsatadi. Agar mahalliy suffiksni endi korporativ rezolver boshqarsa, o’sha suffiksni mahalliy rezolverga qaytaring yoki qurilma uchun IP manzildan foydalaning.

Aniqlash alohida qatlam. mDNS va broadcast marshrutlangan tunneldan o’tmaydi, shuning uchun qurilma manzil bo’yicha yetib boriladigan bo’lib, nomi ko’rinmas qolishi mumkin. Buni reflektor yoki mahalliy DNS yozuvi hal qiladi; marshrut hal qilmaydi.

To’rtinchidan, ikkinchi mashina ham VPNda emasligini tekshiring

Agar siz yetib bormoqchi bo’lgan mashina ham VPN mijozini ishga tushirsa, seansingiz kelib, uning javobi boshqa tunnel orqali chiqib ketishi mumkin. Bundan ulanish o’rnatilib, keyin tiqilib qoladi yoki RDP va SSH urinishi siz tomonda xatosiz vaqt tugashi bilan yakunlanadi. O’z mijozingizni ayblashdan oldin ikkinchi xostning marshrut jadvalini va standart yo’lini tekshiring.

Xizmat qaysi manzilda tinglayotganini ham tekshiring. Faqat tunnel manziliga bog’langan tinglovchi VPNdan kelgan ulanishlarni qabul qiladi va LANdan kelganlarini rad etadi, marshrutlash mukammal bo’lsa ham. Bu xizmat konfiguratsiyasi, tarmoq yo’li emas va VPN manziliga qulflangan boshqaruv interfeyslarida keng tarqalgan.

Tunnelga bog’liq bo’lmagan boshqaruv yo’lini saqlang: manba tarmog’ingizni nomlaydigan statik marshrut, LANga ulangan boshqa interfeys yoki tunnelni butunlay chetlab o’tadigan konsol. Bu yo’lni seans uzilgandan keyin loyihalash keyingi ulanishdan oldin qo’shishdan ancha qiyin.

Muvaffaqiyatsiz tekshiruvga mos keladigan tuzatishni qo’llang

Agar marshrut jadvali yarim standart egallashni ko’rsatgan bo’lsa, siyosat ruxsat berganda bo’lingan tunnelni, bermaganda mahkamlangan mahalliy marshrutni tanlang. Agar manzil umumiy bo’lib chiqsa, sinov va nomni xususiy manzilga o’tkazing. Agar rezolver qo’l almashtirgan bo’lsa, mahalliy suffiks bilan cheklaning yoki manzildan foydalaning. Agar ikkinchi xost tunnelda bo’lsa, uning qaytish yo’lini yoki tinglovchi bog’lanishini tuzating.

Bitta narsani o’zgartiring, so’ngra o’sha tekshiruvni takrorlang. Noto’g’ri subnet uchun qo’shilgan marshrut, xato yozilgan rezolver suffiksi va yangi raqam oladigan interfeysdagi mahkamlangan marshrut — barchasi asl nosozlikka o’xshaydi. Tuzatishni tasodifdan ajratadigan narsa — takrorlash.

VPN ulangan paytda ishlagan marshrut, manzil va rezolverni yozib qo’ying. Keyingi qayta ulanish ularning kamida bittasini o’zgartiradi, va yozuv keyingi uzilishni yangi tekshiruv o’rniga qisqa taqqoslashga aylantiradi.