OpenVPN neprisijungia prie viešbučio Wi-Fi? Išbandykite TCP 443
Profilis, kuris veikia namuose, o viešbučio ar miestelio Wi-Fi tinkle sustoja, prarado transportą. Įrodykite blokavimą, perkelkite klausiklį į TCP 443 ir žinokite kainą.
Atidarykite klientą, spauskite Jungtis ir skaitykite būsenos eilutę, o ne po jos pasirodantį dialogą. Profilis, kuris po viešbučio, miestelio ar mobiliojo tinklo sustoja ties Jungiamasi arba Laukiama serverio, dažniausiai kažkur kelyje prarado savo transportą, o ne prisijungimo duomenis. Kitas naudingas žingsnis – išsiaiškinti, ką tas tinklas perduoda, prieš liesdami serverį. Nekeiskite nieko, kol tas pats profilis nesuveiks kitur.
Pirmiausia išbandykite iš telefono prieigos taško. Jei ten tunelis pakyla, serveris, sertifikatas ir paskyra yra tvarkingi, o vienintelis likęs kintamasis – priešais esantis tinklas.
Pradėkite nuo kliento: perskaitykite būsenos eilutę
Būsenos eilutė pasako, kuris etapas nepavyko. Klientas, įstrigęs ties Jungiamasi, dar sprendžia prieglobos vardą arba atidaro išorinį lizdą; pasiekęs Laukiama serverio turi kelią, bet neturi atsakymo; o tas, kuris autentifikuojasi ir tada nukrenta, turi visai kitą problemą. Kliento žurnalas ir paties profilio remote bei proto laukai rodo, ką klientas bando daryti, o komandinės eilutės kliente --verb 4 išspausdina tą pačią informaciją. Būtent to palyginimas su priešais esančiu tinklu paverčia 'VPN užblokuotas' konkrečiu teiginiu.
Tada patikrinkite tinklą įrankiais, kuriuos jau turite. nc -vzu 203.0.113.10 1194 siunčia UDP datagramą, curl -v telnet://203.0.113.10:443 praneša, ar baigiamas TCP rankos paspaudimas, o naršyklė, įkelianti HTTPS puslapį, įrodo tik tai, kad išeinantis 443 pasiekia tą vieną prieglobą. Mažos patikros atsako į tai, ko VPN klientas negali: kuris prievadas ir kuris protokolas apskritai išeina iš šio tinklo.
Trys tinklo elgsenos iš kliento atrodo vienodai ir reikalauja skirtingų atsakymų. Išeinantis 443 gali būti atidarytas, gali būti leidžiamas tik tarpinis serveris, arba 443 gali būti skaidriai perduodamas į patikros dėžę, kuri negali perskaityti, ką jis perduoda. Pirmoji sprendžiama žemiau pateiktu profilio pakeitimu, antroji – tarpinio serverio nuostatomis, o trečioji gali baigti rankos paspaudimą ir tada sustoti, kai inspektorius nusprendžia, kad srautas jam nepatinka. Žinojimas, su kuria iš trijų susiduriate, yra skirtumas tarp dešimties minučių pakeitimo ir pusdienio, praleisto perinstaliuojant klientus.
Perkelkite klausiklį ir profilį kartu
Serverio pusėje nustatykite klausiklį į tai, ką leidžia tinklas: port 443 ir proto tcp serverio konfigūracijoje, tada iš naujo paleiskite tarnybą ir patvirtinkite lizdą su ss -lntp. Kliento pusėje profilis turi sutikti, nes transportas ir prievadas yra už tunelio: proto tcp ir port 443 .ovpn faile arba atitinkami laukai programėlės nustatymų ekrane. Profilis, vis dar nukreiptas į UDP 1194, nepavyksta lygiai taip pat kaip anksčiau, ir kyla pagunda kaltinti jau sutaisytą ugniasienę. Jei tas pats priegloba taip pat atsako HTTPS per 443, du klausikliai negali dalytis tuo adresu ir protokolu; duokite VPN antrą adresą arba statykite demultiplekserį priešais.
Stebėkite pirmąjį ryšį su tcpdump -ni any port 443 abiejuose galuose. Paketai, kurie išeina iš kliento ir niekada neatvyksta, reiškia, kad tinklas vis dėlto filtruoja, arba kad profilio adresas yra ne tas, kurį manote. Paketai, kurie atvyksta be atsakymo, nukreipia jus atgal į serverio žurnalą, kur protokolų neatitikimas iškart pasirodo kaip atmestas paketas.
Kai iš tinklo išeina tik tarpinis serveris
Kai kurie svečių tinklai neleidžia nieko, išskyrus HTTP tarpinį serverį, o tai yra kitoks apribojimas nei uždarytas prievadas ir pašalina daugiau nei OpenVPN. Klientai, kalbantys tik PPTP, L2TP/IPsec arba grynu IPsec, neturi kelio pro jį, nes tos konstrukcijos tikisi, kad jų išorinis protokolas pasieks serverį tiesiogiai. OpenVPN gali, su http-proxy proxy.example.net 8080 kliento profilyje, jei tarpinis serveris leidžia CONNECT metodą į jūsų prievadą. SOCKS tarpinis serveris dar paprastesnis, nes perduoda srautą nekreipdamas dėmesio, kas yra viduje.
Ten, kur klientas neturi tarpinio serverio palaikymo, paprastai lieka SSH tunelis per 443. Jis prideda antrą sluoksnį, o tinklo operatorius gali turėti nuomonę apie tai, todėl traktuokite jį kaip tiltą vienai kelionei, o ne kaip architektūrą.
Įvertinkite atsarginio kelio kainą prieš jį palikdami
TCP TCP viduje turi žinomą kainą. Kai išorinis ryšys yra TCP ir naudingoji apkrova taip pat TCP, prarastas segmentas sukelia pakartotinį perdavimą abiejuose sluoksniuose, o vidinis ryšys traukiasi nuo nuostolio, kurio negali matyti. Naršymas tai išlaiko; interaktyvios sesijos ir skambučiai tai jaučia. Palikite TCP 443 klausiklį kaip atsarginį kelią tinklams, kurie to reikalauja, o UDP palikite numatytuoju viskam, kas jį dar praleidžia.
Užrašykite pasirinkimą profilio pavadinime ir palaikymo pastabose: kuris prievadas, kuris protokolas ir kuris tinklas paskatino. Tada paklauskite tinklo administratoriaus, ar tas prievadas liks atidarytas po kito įrangos atnaujinimo, nes tyliai išnykstantis atsarginis kelias yra blogiau nei jokio atsarginio kelio.