Mehmonxona Wi-Fi tarmog'ida OpenVPN ulanmayaptimi? TCP 443 ni sinab ko'ring

Mijozni oching, Ulanish tugmasini bosing va undan keyin chiqadigan muloqot oynasi o'rniga holat qatorini o'qing. Mehmonxona, kampus yoki mobil tarmoqdan so'ng Ulanmoqda yoki Server kutilmoqda holatida tiqilib qoladigan profil odatda yo'lda qayerdadir transportini yo'qotgan bo'ladi, hisob ma'lumotlarini emas. Keyingi foydali qadam serverga tegishdan oldin bu tarmoq nima tashiishini aniqlashdir. Xuddi shu profil boshqa joyda ishlamaguncha hech narsani o'zgartirmang.

Avval telefon hotspotidan sinab ko'ring. Agar tunnel u yerda ko'tarilsa, server, sertifikat va hisob joyida, qolgan yagona o'zgaruvchi esa oldingizdagi tarmoqdir.

Mijozdan boshlang: holat qatorini o'qing

Holat qatori qaysi bosqich muvaffaqiyatsiz bo'lganini aytadi. Ulanmoqda holatida qolgan mijoz hali xost nomini hal qilmoqda yoki tashqi soketni ochmoqda; Server kutilmoqda ga yetganining yo'li bor, ammo javobi yo'q; autentifikatsiyadan keyin yiqiladiganining muammosi butunlay boshqa. Mijoz jurnali va profilning o'z remote hamda proto maydonlari mijoz nima qilishga urinayotganini ko'rsatadi, buyruq qatori mijozida --verb 4 xuddi shu tafsilotni chop etadi. Buni oldingizdagi tarmoq bilan solishtirish 'VPN bloklangan' degan gapni aniq da'voga aylantiradi.

So'ngra mavjud vositalar bilan tarmoqni tekshiring. nc -vzu 203.0.113.10 1194 UDP datagramma yuboradi, curl -v telnet://203.0.113.10:443 TCP qo'l siqish tugallanishini xabar qiladi, HTTPS sahifani yuklaydigan brauzer esa faqat chiqish 443 o'sha bitta xostga yetishini isbotlaydi. Kichik tekshiruvlar VPN mijozi javob bera olmaydigan savolga javob beradi: qaysi port va qaysi protokol bu tarmoqdan umuman chiqadi.

Tarmoqning uch xil xatti-harakati mijozdan bir xil ko'rinadi va turli javob talab qiladi. Chiqish 443 ochiq bo'lishi mumkin, faqat proksiga ruxsat berilgan bo'lishi mumkin yoki 443 nima tashiishini o'qiy olmaydigan tekshiruv qutisiga shaffof yo'naltirilgan bo'lishi mumkin. Birinchisi quyidagi profil o'zgarishi bilan, ikkinchisi proksi sozlamalari bilan tuzatiladi, uchinchisi esa qo'l siqishni tugatib, keyin tekshiruvchiga oqim yoqmasa tiqilib qolishi mumkin. Uchtasidan qaysi biriga duch kelayotganingizni bilish o'n daqiqalik o'zgarish va yarim kun mijozlarni qayta o'rnatish orasidagi farqdir.

Tinglovchi va profilni birga ko'chiring

Server tomonida tinglovchini tarmoq ruxsat bergan narsaga qo'ying: server konfiguratsiyasida port 443 va proto tcp, so'ngra xizmatni qayta ishga tushiring va soketni ss -lntp bilan tasdiqlang. Mijoz tomonida profil rozi bo'lishi kerak, chunki transport va port tunneldan tashqarida: .ovpn ichida proto tcp va port 443, yoki ilova sozlamalari ekranidagi tegishli maydonlar. Hali ham UDP 1194 ga qaratilgan profil xuddi avvalgidek muvaffaqiyatsiz bo'ladi va allaqachon tuzatilgan tarmoq devorini ayblash istagi paydo bo'ladi. Agar o'sha xost 443 da HTTPS ga ham javob bersa, ikki tinglovchi bu manzil va protokolni baham ko'ra olmaydi; VPN ga ikkinchi manzil bering yoki oldiga demultiplekser qo'ying.

Birinchi ulanishni ikkala uchida tcpdump -ni any port 443 bilan kuzating. Mijozdan chiqib hech qachon yetib bormaydigan paketlar tarmoq baribir filtrlayotganini yoki profildagi manzil siz o'ylagan manzil emasligini bildiradi. Javobsiz yetib kelgan paketlar sizni server jurnaliga qaytaradi, u yerda protokol nomuvofiqligi darhol tashlangan paket sifatida ko'rinadi.

Tarmoqdan faqat proksi chiqsa

Ba'zi mehmon tarmoqlari HTTP proksidan boshqa hech narsaga ruxsat bermaydi, bu yopiq portdan boshqa cheklov va OpenVPN dan ham ko'proq narsani istisno qiladi. Faqat PPTP, L2TP/IPsec yoki yalang'och IPsec gapiradigan mijozlar undan o'tish yo'liga ega emas, chunki bu loyihalar tashqi protokollari serverga to'g'ridan-to'g'ri yetishini kutadi. OpenVPN buni qila oladi, mijoz profilida http-proxy proxy.example.net 8080 bilan, proksi portingizga CONNECT usuliga ruxsat bersa. SOCKS proksi yanada oson, chunki oqimni ichida nima borligiga qaramay uzatadi.

Mijozda proksi qo'llab-quvvatlanmagan joyda odatda 443 ustidagi SSH tunnel qoladi. U ikkinchi qatlam qo'shadi va tarmoq operatorining bu haqda fikri bo'lishi mumkin, shuning uchun unga arxitektura emas, bitta sayohat uchun ko'prik deb qarang.

Zaxira yo'lni saqlab qolishdan oldin narxini hisoblang

TCP ichidagi TCP ning ma'lum narxi bor. Tashqi ulanish TCP va foydali yuk ham TCP bo'lsa, yo'qolgan segment ikkala qatlamda qayta uzatishni keltirib chiqaradi va ichki ulanish o'zi ko'ra olmaydigan yo'qotishdan chekinadi. Ko'rish buni ko'taradi; interaktiv sessiyalar va qo'ng'iroqlar buni sezadi. TCP 443 tinglovchisini talab qiladigan tarmoqlar uchun zaxira yo'l sifatida saqlang, UDP ni esa hali ham o'tkazib yuboradigan hamma narsa uchun standart qilib qo'ying.

Tanlovni profil nomiga va qo'llab-quvvatlash eslatmalariga yozing: qaysi port, qaysi protokol va qaysi tarmoq sabab bo'lgan. So'ngra tarmoq administratoridan keyingi uskuna almashtirilgandan keyin ham bu port ochiq qoladimi, deb so'rang, chunki jimgina yo'qolib ketadigan zaxira yo'l umuman zaxira yo'l bo'lmaganidan yomonroq.