VPN evdə qoşulur, otel Wi-Fi-da vaxt aşımına düşür

Noutbuk evin Wi-Fi şəbəkəsinə qoşulur, müştəri üç saniyəyə bağlanır, sonra eyni profil bir saat sonra oteldə uğursuz olur. Arada heç nə yenilənməyib. Bunu qarşınızda müştəri ilə nəzərdən keçirmək əsasən hansı xətanın hansı mərhələyə aid olduğunu bilməkdən ibarətdir, çünki faydalı məlumat müştərinin çap etdiyi koddadır, onun uğursuz olmasında deyil. Aşağıdakı dörd addımı ardıcıllıqla işlədin və ad, paket, port yoxsa siyasətin sizi rədd etdiyini biləcəksiniz.

Xəta kodunu hökm deyil, mərhələ kimi oxuyun

Tunel yaranmazdan əvvəl müştəri üç ayrı mərhələyə çatır. Server adını həll edir, şəbəkədəki nəyisə cavab alır və təhlükəsizlik assosiasiyası üzərində razılaşır. Hər mərhələnin öz uğursuzluq mesajı var və xüsusilə Windows, hansı mərhələyə aid olduqlarını bildikdən sonra fərqli kodlarla səxavətli davranır.

Bu kodlardan ikisi şəbəkənin günahsız olduğunu bildirir. 789 paketlərin getdiyini və iki tərəfin kripto barədə razılaşmadığını bildirir ki, bu, evdə düzəldə biləcəyiniz konfiqurasiya problemidir. 868 isə heç bir paketin çıxmasına ehtiyac olmadığını bildirir, yəni ad həll olunana qədər tunelin dizaynı əhəmiyyətsizdir. Kodu düzgün mərhələyə ayırmaq istənilən tutmadan daha çox vaxt qazandırır, çünki növbəti üç addımdan hansını atlayacağınızı deyir.

Müştəri Windows deyilsə, uyğun şəkildə ehtiyatlı olun. Üçüncü tərəf müştəriləri bunların çoxunu "bağlantı alınmadı" kəlməsinə yığır, buna görə də növbəti iki addım mesaja heç güvənmir.

Tuneli günahlandırmadan əvvəl adı yoxlayın

Otel və hava limanı şəbəkələri DNS-i daim tutur və portal ünvanı ilə cavab verən həlledici ölü serverə tam bənzəyən uğursuzluq yaradır. Yerli həlledicinin dediyini ictimai həlledicinin dediyi ilə müqayisə edin:

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

İki cavab fərqlidirsə, siz yönləndirilirsiniz və bu həll olunana qədər diaqnozun qalanı boşa gedir. Xüsusilə portal ünvanı TCP bağlantısını məmnuniyyətlə qəbul edib sonra dayanır, buna görə də brauzerlə sınayanda firewall blokuna bənzəyə bilər.

İndi çatmaq istədiyiniz ünvanın istifadə edilən ünvan olduğunu təsdiqləyin. Bəzi müştərilər əvvəlki həlli profilin ömrü boyu keşləyir, ona görə DNS dəyişikliyindən sonra yenidən qoşulma hələ də köhnə ünvana gedir. Yenidən sınamadan əvvəl müştəri tamamilə bağlayın, eyni pəncərədə əlaqəni kəs və qoş düymələrinə basmaq əvəzinə.

Hansı xarici paketin itdiyini öyrənin

Tunelin sizinlə server arasındakı yola tamamilə aid olan xarici axını var və aralıq qurğular məhz bu axını təsnif edib atır. Onu müştəridə tutun, sonra işlək şəbəkə ilə uğursuz olanı müqayisə edin. Windows-da ilk baxış üçün daxili tutma kifayətdir:

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

Görmək istədiyiniz paketlərinizin ümumiyyətlə çıxıb-çıxmadığı və nəyinsə geri qayıdıb-qayıtmadığıdır. Çıxan paketlərə cavab olmaması yolun və ya uzaq ucun onları atdığını bildirir; ümumiyyətlə heç nə çıxmırsa, müştəri göndərməyə çatmamışdır ki, bu da ad həllinə və ya yerli firewall siyasətinə işarə edir.

Eyni testi telefon hotspotunda təkrarlayın. Bu, sizin üçün mövcud olan ən məlumatlı müqayisədir, çünki noutbukun, müştərinin və etimadnamələrin eyni qalması ilə oteldəki hər qurğunu yoldan çıxarır. Tunel hotspotda qalxırsa, serverə baxmağı dayandırın. Orada da uğursuz olursa, şəbəkənin heç vaxt yaratmadığı müştəri və ya hesab probleminiz var.

Bir nəqliyyatı dəyişib yenidən sınayın

Xarici axının atıldığını bildikdən sonra praktik sual şəbəkənin hansı axına icazə verdiyidir. Məhdud şəbəkələrin çoxu çıxan TCP 443-ə icazə verir, çünki başqa cür işləyə bilməzlər, ona görə də dinləyicini ora köçürmək adi cavabdır. OpenVPN üzərində bu, server dəyişdirilənə qədər müştəri tərəfindəki keçiddir:

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

IPsec müştərilərində öz parametr panellərində ekvivalent açar var, adətən TCP üzərindən IPsec və ya NAT keçidi kimi təsvir olunur. Onu dəyişmək də bir diaqnostikadır: tunel TCP üzərindən qalxıb UDP üzərindən ölürsə, şəbəkənin UDP-ni filtrlədiyini sübut etmisiniz və həm də həmin sayta hər gedişinizdə lazım olacaq parametri tapmısınız.

Router funksiyalarını ilk cəhddə söndürmək istəyinə qarşı durun. Otel şəbəkəsində vəziyyətli yoxlamanı və ya sel qorunmasını söndürmək sizin üçün onsuz da əlçatan deyil, öz avadanlığınızda isə real qorunmanı bir noutbukla dəyişir. Hansı parametrin nəticəni dəyişdiyini qeyd edin, sonra onu geri qaytarın və şəbəkənin artıq icazə verdiyi nəqliyyat axtarın.

Eyni profili ikinci şəbəkədə yoxlayın

Bileti bağlamazdan əvvəl dəyişikliyin binadan çıxdıqdan sonra da işlədiyini sübut edin. Orijinal şəbəkədə orijinal parametrlərlə yenidən qoşulun, ilk otuz saniyəni tutun və müştərinin hotspotda çatdığı vəziyyətə çatdığını təsdiqləyin:

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

Son əmrin açığa çıxardığı fərqi saxlamaya dəyər: profil qoşulmuş tunel bildirə bilər, halbuki onun içindəki marşrutlaşdırma səhvdir və bu, "VPN işləyir, amma heç nə işləmir" nəticəsini verir ki, bu başqa məqalədir. Redaktənizdən sonra tunel növü dəyişdisə, profil sınaqdan keçirdiyiniz profil deyil.

Sonra tapıntını növbəti şəxsin baxacağı yerə yazın. "Korporativ profil bu saytda TCP 443 tələb edir; UDP 500-ü otel filtrləyir" həmkarınızın hərəkət edə biləcəyi bir cümlədir. "Otellərdə VPN qeyri-sabitdir" belə deyil və növbəti ay eyni saatın yenidən xərclənməsinə zəmanət verir.