VPN yalnız veb şəbəkəsində bloklanıb? Qatları sıra ilə işləyin

Brauzerin işlədiyi, hər tunelin öldüyü kampus və ya otel şəbəkəsi bir problem deyil, dörd üst-üstə yığılmış problemdir. Yol yalnız TCP 443-ə icazə verə bilər, autentifikasiyalı proksi tələb edə bilər, əl sıxmanı yoxlaya bilər və sadəcə siyasətlə uzaq girişi qadağan edə bilər. Onları sıra ilə işləmək sizi şəbəkə qaydasını düzəltmək üçün yeni müştəri almaqdan saxlayır. Aşağıdakı təlimat təxminən on dəqiqə çəkir və hansı qatın sizi rədd etdiyi barədə yazılı cavabla bitir.

Hansı qatın bağlantını rədd etdiyini sübut edin

VPN müştərisi ilə başlamayın. Eyni hosta adi HTTPS sorğusu ilə başlayın və vaxt mərhələlərini oxuyun, çünki uğursuz olan mərhələ hansı cihazın cavabdeh olduğunu deyir:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Cavab yoxdur və connect vaxtı yoxdur, bu TCP heç tamamlanmadı deməkdir, yəni firewall, proksi tələbi və ya səhv təyinat işdədir. connect vaxtı var, amma tls vaxtı yoxdur, bu ortada bir şeyin bağlantını qəbul edib əl sıxmanı dayandırdığı deməkdir, yoxlayıcı proksinin müştəri tərəfindən görünüşü belədir.

İndi həqiqətən aldığınız sertifikata baxın. Bu, serverlə danışdığınızı, yoxsa sessiyanı yenidən imzalamış ara qutunun olduğunu tapmağın ən sürətli yoludur:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Verən sətrini oxuyun. Öz CA-nız xidmətə çatdığınızı bildirir; korporativ və ya cihaz verəni isə filtrin bağlantını dayandırıb sonra nə olacağına qərar verdiyini göstərir. Hər iki çıxışı vaxt damğası ilə qeyd edin, çünki eyni test bir saat sonra qonaq şəbəkəsində fərqli cavab verə bilər.

Proksidən xəbərdar müştəri ilk paketi dəyişir, siyasəti yox

Şəbəkə autentifikasiyalı proksidən CONNECT tələb edirsə, VPN müştərinizə bu barədə deyilməlidir, əks halda marşrutlaşdıra bilmədiyi ünvana soket açmağa çalışacaq. Proksini müştəridən ayrı test edin ki, uğursuzluğun bir izahı olsun:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

Birinci əmr proksinin təyinatı daşıyacağını sübut edir. İkinci müştəriyə 443 üzərində TCP işlətməyi tapşırır, bu, əksər yalnız-veb yollarının ümumiyyətlə ötürəcəyi yeganə nəqliyyatdır. Birinci əmr uğurla, ikinci hələ də uğursuz olarsa, maneə proksi deyil.

Bəzi müştərilər əvəzləmə yerinə əməliyyat sisteminin proksisini oxuyur, bəziləri isə heç birini oxumur. Sistem miqyaslı ayarın tətbiq olunduğunu düşünməzdən əvvəl tətbiqin öz sənədlərinə baxın. Son nöqtəni proksinin xidmət etmədiyi həlledici ilə həll edən müştəri burada da uğursuz olacaq, buna görə DNS dəyişikliyi yalnız bir yan yol olsa da düzəliş kimi görünə bilər.

Yolda yönləndirmə nümunəsinə də fikir verin. Filtrli şəbəkə bir satıcının aşkarlama host adına öz cavabını verə bilər, bu da müştərinin hansı proksi profilini seçdiyini dəyişir. Prosesi həmin qəribəliyin üstündə qurmayın. Saytla dəyişir, xəbərdarlıq olmadan dəyişir və başqası üçün dəstəkləyə biləcəyiniz bir şey deyil.

443 portu əlçatandır, icazəli deyil

Tuneli 443 üzərində TLS-ə bükmək əlçatanlığı həll edir, başqa heç nəyi. Portu yoxlayan filtr onu keçirəcək; əl sıxmanın barmaq izini götürən filtr keçirməyəcək, şifrələnmiş müştəri salamlaması isə server adını yalnız hər iki tərəf dəstəklədikdə gizlədir. Testi işlədin və ümid etmək yerinə hansı filtrin arxasında olduğunuzu öyrənin.

İnsanların sonradan kəşf etdiyi performans xərci də var. Etibarlı nəqliyyatın içində etibarlı nəqliyyat itkini gücləndirir, çünki daxili yığın xarici yığının artıq yenidən göndərdiyi seqmentləri yenidən göndərir. Təmiz keçiddə heç kim fərq etmir. Sıx kampus simsiz şəbəkəsində tunel məhz ona ehtiyac duyduğunuz anda istifadəsiz olur və qrafik heç nə qəsdən atılmadığı halda paket itkisi kimi görünür.

UDP adətən ilk itki olur və bunu ehtimal etmək yerinə təsdiqləməyə dəyər. WireGuard və ya standart OpenVPN əl sıxmanı heç tamamlamırsa, TCP 443 işləyirsə, şəbəkə UDP-ni atır və heç bir açar bərpası bunu dəyişməyəcək:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Dünən işləyən peer-in yanında boş əl sıxma vaxt damğası UDP cavabıdır. İki DNS sorğusu başqa suala cavab verir: yerli həlledici ilə açıq həlledici son nöqtə ünvanı barədə razılaşmırsa, siz yönləndirilirsiniz və nəqliyyat arqumenti səhv olandır.

Maşından həqiqətən nə çıxdığını yoxlayın

Müştəri qeydləri müştərinin inandığını təsvir edir. Tutma şəbəkənin gördüyünü təsvir edir və bu halların çoxu ikisi arasındakı fərqdə həll olunur:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

SYN paketləri görürsünüz və SYN-ACK yoxdursa, blok yuxarı axındadır və müştəri günahsızdır. Serverin ünvanı olmayan ünvana tamamlanmış əl sıxma görürsünüzsə, proksi və ya tutucu ilə danışırsınız. Heç nə görmürsünüzsə, nəticə çıxarmazdan əvvəl düzgün interfeysdə tutduğunuzu yoxlayın.

Soket siyahısı daha incə bir halı tutur: standart marşrutu artıq tutan ikinci tunel. Marşrut cədvəli üstündə dava edən iki müştəri tam olaraq bloklanmış şəbəkəyə bənzəyən fasiləli uğursuzluqlar yaradır və tutma gözləmədiyiniz interfeysdən çıxan trafiki göstərəcək.

Geri qaytarma və saxlamağa dəyər qeyd

Dəyişiklikləri etdiyiniz tərs sıra ilə geri alın. Proksi dəyişənlərini ləğv edin, əl ilə başlatdığınız müştərini dayandırın və əlavə etdiyiniz hər hansı marşrut və ya həlledici əvəzləməsini silin:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

Əl ilə başladılmış müştərini işlək qoymaq noutbukun növbəti ofis ziyarətində pozulmuş şəbəkə ilə qalmasının yoludur. Qabıq profilində qalan proksi dəyişənləri həftələr sonra əlaqəsiz alətləri pozur və onları sazlayan şəxs iki hadisəni əlaqələndirməyəcək.

Sonra dörd sətir yazın: şəbəkə, vaxt damğası, uğursuz olan mərhələ və gördüyünüz verən. Bir kampusda işləyib növbətisində uğursuz olan yol normaldır və növbəti şəxs fərqin proksi, həlledici yoxsa filtr olduğunu bilməlidir. Cavab şəbəkənin uzaq girişi qadağan etməsi olsa, orada dayanın və oxumadığınız siyasətə yan yol daşımaq əvəzinə administratordan dəstəklənən marşrutu istəyin.