VPN uyda ulanadi, lekin mehmonxona Wi-Fi-da vaqt tugaydi

Noutbuk uy Wi-Fi-iga ulanadi, mijoz uch sekundda ulanadi va xuddi shu profil bir soatdan keyin mehmonxonada muvaffaqiyatsiz bo'ladi. Orada hech narsa yangilanmagan. Buni oldingizda o'tirgan mijoz bilan ko'rib chiqish, asosan, qaysi xato qaysi bosqichga tegishli ekanini bilish bilan bog'liq, chunki foydali ma'lumot mijoz chop etadigan kodda, u muvaffaqiyatsiz bo'lganligida emas. Quyidagi to'rt qadamni tartib bilan bajaring va nom, paket, port yoki siyosat sizni rad etganini bilib olasiz.

Xato kodini hukm emas, bosqich sifatida o'qing

Tunnel paydo bo'lishidan oldin mijoz uchta alohida bosqichga etadi. U server nomini hal qiladi, tarmoqdagi biror narsadan javob oladi va xavfsizlik assotsiatsiyasi bo'yicha kelishadi. Har bir bosqichning o'z muvaffaqiyatsizlik xabari bor va ayniqsa Windows qaysi bosqichga tegishli ekanini bilganingizda turli kodlarni saxiylik bilan beradi.

Bu kodlardan ikkitasi tarmoq begunoh ekanini bildiradi. 789 paketlar oqayotganini va ikki tomon kripto bo'yicha kelisha olmaganini bildiradi, bu uyda tuzatish mumkin bo'lgan konfiguratsiya muammosi. 868 esa hech bir paket tashqariga chiqishi shart emasligini bildiradi, shuning uchun nom hal bo'lmaguncha tunnel dizayni ahamiyatsiz. Kodni to'g'ri bosqichga ajratish har qanday ushlashdan ko'ra ko'proq vaqt tejaydi, chunki keyingi uch qadamdan qaysi birini o'tkazib yuborishni aytadi.

Agar mijoz Windows bo'lmasa, munosib ehtiyot bo'ling. Uchinchi tomon mijozlari buning ko'p qismini "ulanish muvaffaqiyatsiz" ga jamlaydi, shuning uchun keyingi ikki qadam xabarga umuman tayanmaydi.

Tunnelni ayblashdan oldin nomni tekshiring

Mehmonxona va aeroport tarmoqlari DNS-ni doimiy ushlab qoladi va portal manzili bilan javob beruvchi hal qiluvchi o'lik serverga xuddi o'xshash nosozlik yaratadi. Mahalliy hal qiluvchi nima deyishini ommaviy hal qiluvchi nima deyishi bilan solishtiring:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Ikki javob farq qilsa, sizni yo'naltirishmoqda va bu hal bo'lmaguncha qolgan diagnostika behuda. Ayniqsa portal manzili TCP ulanishini mamnuniyat bilan qabul qiladi va keyin to'xtab qoladi, shuning uchun brauzer bilan sinaganda bu xavfsizlik devori blokiga o'xshab ko'rinishi mumkin.

Endi yetib bormoqchi bo'lgan manzil ishlatilayotganini tasdiqlang. Ba'zi mijozlar oldingi yechimni profilning butun umri davomida keshlaydi, shuning uchun DNS o'zgargandan keyin qayta ulanish hali ham eski manzilga boradi. Qayta sinashdan oldin mijozni butunlay yoping, xuddi shu oynada uzish va ulash tugmalarini bosish o'rniga.

Qaysi tashqi paket yo'qolishini aniqlang

Tunnelning siz va server o'rtasidagi yo'lga to'liq tegishli tashqi oqimi bor va aynan shu oqimni oraliq qutilar tasniflab tashlaydi. Uni mijozda ushlang, keyin ishlaydigan tarmoqni ishlamayotgan bilan solishtiring. Windows-da birinchi qarash uchun ichki ushlash yetarli:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

Siz paketlaringiz umuman chiqayotganini va biror narsa qaytayotganini ko'rishni xohlaysiz. Tashqariga chiqqan paketlarga hech narsa qaytmasa, yo'l yoki uzoq uch ularni tashlayapti; umuman hech narsa chiqmasa, mijoz yuborishga yetib bormagan, bu nom hal qilishga yoki mahalliy xavfsizlik devori siyosatiga ishora qiladi.

Xuddi shu sinovni telefon hotspotida takrorlang. Bu sizda mavjud eng ma'lumotli taqqoslash, chunki u noutbuk, mijoz va hisob ma'lumotlarini bir xil qoldirib, yo'ldan mehmonxonadagi har bir qutini olib tashlaydi. Hotspotda tunnel ko'tarilsa, serverga qarashni to'xtating. U yerda ham muvaffaqiyatsiz bo'lsa, tarmoq hech qachon keltirib chiqarmagan mijoz yoki hisob muammosi bor.

Bitta transportni o'zgartirib, qayta sinang

Tashqi oqim tashlanayotganini bilganingizdan so'ng, amaliy savol tarmoq qaysi oqimga ruxsat berishidir. Aksariyat cheklangan tarmoqlar chiquvchi TCP 443 ga ruxsat beradi, chunki aks holda ular ishlay olmaydi, shuning uchun tinglovchini u yerga ko'chirish odatiy javob. OpenVPN da bu server o'zgartirilmaguncha mijoz tomonidagi kalit:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

IPsec mijozlarining o'z sozlamalar panelida ekvivalent kalit bor, odatda TCP ustidan IPsec yoki NAT o'tishi deb ta'riflanadi. Uni o'zgartirish ham diagnostika: agar tunnel TCP ustidan ko'tarilib, UDP ustidan o'lsa, siz tarmoq UDP ni filtrashini isbotladingiz va o'sha joyga har tashrifda kerak bo'ladigan sozlamani ham topdingiz.

Birinchi urinishda router funksiyalarini o'chirish vasvasasiga qarshi turing. Mehmonxona tarmog'ida holat tekshiruvini yoki toshqin himoyasini o'chirish sizga baribir mavjud emas, o'z uskunangizda esa bu haqiqiy himoyani bitta noutbukka almashtiradi. Qaysi sozlama natijani o'zgartirganini yozib qo'ying, keyin uni qaytaring va tarmoq allaqachon ruxsat beradigan transportni qidiring.

Xuddi shu profilni ikkinchi tarmoqda tekshiring

Chiptani yopishdan oldin o'zgartirish binodan chiqqandan keyin ham saqlanib qolganini isbotlang. Asl tarmoqda asl sozlamalar bilan qayta ulaning, birinchi o'ttiz soniyani ushlang va mijoz hotspotda erishgan holatga erishganini tasdiqlang:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

Oxirgi buyruq ochib beradigan farqni saqlab qolishga arziydi: profil ulangan tunnel haqida xabar berishi mumkin, lekin uning ichidagi marshrutlash noto'g'ri bo'ladi va bu "VPN yoqilgan, lekin hech narsa ishlamaydi" ni keltirib chiqaradi, bu boshqa maqola. Tahriringizdan keyin tunnel turi o'zgargan bo'lsa, profil siz sinagan profil emas.

Keyin topilmani keyingi odam qaraydigan joyga yozing. "Korporativ profil bu joyda TCP 443 talab qiladi; UDP 500 ni mehmonxona filtrlaydi" bu hamkasb harakat qilishi mumkin bo'lgan gap. "Mehmonxonalarda VPN beqaror" bunday emas va keyingi oyda xuddi shu soat yana sarflanishini kafolatlaydi.