OpenVPN ne konektiĝas en hotelaj Wi-Fi? Provu TCP 443

Malfermu la klienton, premu Connect kaj legu la statlinion anstataŭ la dialogon, kiu sekvas ĝin. Profilo, kiu haltas ĉe Connecting aŭ Waiting for server post hotela, kampa aŭ poŝa reto, kutime perdis sian transporton ie survoje, ne siajn akreditaĵojn. La utila sekva paŝo estas ekscii, kion tiu reto portas, antaŭ ol tuŝi la servilon. Ne ŝanĝu ion, ĝis la sama profilo funkciis aliloke.

Unue testu el poŝtelefona hotspot. Se la tunelo leviĝas tie, la servilo, la atestilo kaj la konto estas en ordo, kaj la sola restanta variablo estas la reto antaŭ vi.

Komencu ĉe la kliento: legu la statlinion

La statlinio diras, kiu stadio malsukcesis. Kliento blokita ĉe Connecting ankoraŭ solvas la gastigan nomon aŭ malfermas la eksteran socketon; tiu, kiu atingas Waiting for server, havas vojon sed neniun respondon; tiu, kiu aŭtentikigas kaj poste falas, havas tute alian problemon. La klienta protokolo kaj la propraj kampoj remote kaj proto de la profilo montras, kion la kliento provas fari, kaj --verb 4 ĉe komandlinia kliento presas la saman detalon. Ĝuste la komparo kun la reto antaŭ vi transformas «la VPN estas blokita» en konkretan aserton.

Poste esploru la reton per iloj, kiujn vi jam havas. nc -vzu 203.0.113.10 1194 sendas UDP-datagramon, curl -v telnet://203.0.113.10:443 raportas, ĉu TCP-manpremo kompletiĝas, kaj retumilo, kiu ŝargas HTTPS-paĝon, pruvas nur, ke la elira 443 atingas tiun unu gastiganton. Malgrandaj provoj respondas al tio, kion la VPN-kliento ne povas: kiu pordo kaj protokolo entute forlasas ĉi tiun reton.

Tri retaj kondutoj aspektas same de la kliento kaj postulas malsamajn respondojn. La elira 443 povas esti malfermita, nur prokurilo povas esti permesata, aŭ 443 povas esti travideble plusendata al inspekta skatolo, kiu ne povas legi, kion ĝi portas. La unuan solvas la profila ŝanĝo sube, la duan la prokuraj agordoj, kaj la tria povas kompleti manpremon kaj poste halti, kiam la inspektisto decidas, ke ĝi ne ŝatas la fluon. Scii, kun kiu vi frontas, estas la diferenco inter ŝanĝo de dek minutoj kaj posttagmezo da reinstalado de klientoj.

Movi la aŭskultanton kaj la profilon kune

Ĉe la servila flanko, agordu la aŭskultanton al tio, kion la reto permesas: port 443 kaj proto tcp en la servila agordo, poste restartigu la servon kaj konfirmu la socketon per ss -lntp. Ĉe la klienta flanko, la profilo devas konsenti, ĉar transporto kaj pordo staras ekster la tunelo: proto tcp kaj port 443 en la .ovpn, aŭ la respondaj kampoj en la agorda ekrano de la aplikaĵo. Profilo ankoraŭ celanta UDP 1194 malsukcesas ĝuste kiel antaŭe, kaj la tento estas kulpigi fajroŝirmilon, kiu jam estas riparita. Se la sama gastiganto ankaŭ respondas HTTPS ĉe 443, la du aŭskultantoj ne povas kunhavi tiun adreson kaj protokolon; donu al la VPN duan adreson aŭ metu demultipleksilon antaŭe.

Observu la unuan konekton per tcpdump -ni any port 443 ĉe ambaŭ finoj. Paketoj, kiuj forlasas la klienton kaj neniam alvenas, signifas, ke la reto tamen filtradas, aŭ ke la adreso en la profilo ne estas tiu, kiun vi supozas. Paketoj, kiuj alvenas sen respondo, resendas vin al la servila protokolo, kie protokola miskongruo tuj montriĝas kiel faligita paketo.

Kiam nur prokurilo eliras el la reto

Iuj gastaj retoj permesas nenion krom HTTP-prokurilo, kio estas alia limigo ol fermita pordo kaj ekskludas pli ol OpenVPN. Klientoj, kiuj parolas nur PPTP, L2TP/IPsec aŭ nudan IPsec, havas neniun vojon tra ĝi, ĉar tiuj dezajnoj atendas, ke ilia ekstera protokolo atingos la servilon rekte. OpenVPN povas, kun http-proxy proxy.example.net 8080 en la klienta profilo, kondiĉe ke la prokurilo permesas la metodon CONNECT al via pordo. SOCKS-prokurilo estas eĉ pli facila, ĉar ĝi plusendas la fluon sen zorgi, kio estas interne.

Kie la kliento ne subtenas prokurilon, SSH-tunelo super 443 estas kutime tio, kio restas. Ĝi aldonas duan tavolon, kaj la operatoro de la reto eble havas opinion pri ĝi, do traktu ĝin kiel ponton por unu vojaĝo, ne kiel arkitekturon.

Kalkulu la koston de la rezervo antaŭ ol teni ĝin

TCP ene de TCP havas konatan koston. Kiam la ekstera konekto estas TCP kaj la utila ŝarĝo ankaŭ estas TCP, perdita segmento ekigas reelsendon ĉe ambaŭ tavoloj, kaj la interna konekto retiriĝas de perdo, kiun ĝi ne povas vidi. Retumado postvivas tion; interagaj sesioj kaj vokoj sentas ĝin. Tenu la TCP 443 aŭskultanton kiel rezervon por retoj, kiuj postulas ĝin, kaj lasu UDP kiel implicitan por ĉio, kio ankoraŭ trapasas ĝin.

Registru la elekton en la profila nomo kaj en la subtenaj notoj: kiu pordo, kiu protokolo kaj kiu reto kaŭzis ĝin. Poste demandu la administranton de la reto, ĉu tiu pordo restas malfermita post la sekva ekipaĵa renovigo, ĉar rezervo, kiu silente malaperas, estas pli malbona ol neniu rezervo.