OpenVPN nepievienojas viesnīcas Wi-Fi? Izmēģiniet TCP 443

Atveriet klientu, nospiediet Savienot un lasiet statusa rindu, nevis pēc tās parādīto dialogu. Profils, kas pēc viesnīcas, kamparas vai mobilā tīkla apstājas pie Savienojas vai Gaida serveri, parasti kaut kur ceļā ir zaudējis savu transportu, nevis pieteikšanās datus. Nākamais lietderīgais solis ir noskaidrot, ko šis tīkls pārvadā, pirms aiztikt serveri. Neko nemainiet, līdz tas pats profils ir nostrādājis citur.

Vispirms pārbaudiet no tālruņa piekļuves punkta. Ja tunelis tur paceļas, serveris, sertifikāts un konts ir kārtībā, un vienīgais atlikušais mainīgais ir tīkls jums priekšā.

Sāciet ar klientu: izlasiet statusa rindu

Statusa rinda pasaka, kurš posms neizdevās. Klients, kas iestidzis pie Savienojas, vēl atrisina resursdatora vārdu vai atver ārējo ligzdu; tas, kas sasniedz Gaida serveri, ir ceļš, bet nav atbildes; tas, kas autentificējas un pēc tam nokrīt, ir ar pavisam citu problēmu. Klienta žurnāls un paša profila remote un proto lauki parāda, ko klients mēģina darīt, un komandrindas klientā --verb 4 izdrukā tos pašus datus. Tieši šī salīdzināšana ar tīklu jums priekšā pārvērš 'VPN ir bloķēts' konkrētā apgalvojumā.

Pēc tam pārbaudiet tīklu ar rīkiem, kas jums jau ir. nc -vzu 203.0.113.10 1194 nosūta UDP datagrammu, curl -v telnet://203.0.113.10:443 ziņo, vai TCP rokasspiediens tiek pabeigts, un pārlūks, kas ielādē HTTPS lapu, pierāda tikai to, ka izejošais 443 sasniedz šo vienu resursdatoru. Mazas pārbaudes atbild uz to, ko VPN klients nevar: kurš ports un kurš protokols vispār iziet no šī tīkla.

Trīs tīkla uzvedības no klienta izskatās vienādi un prasa dažādas atbildes. Izejošais 443 var būt atvērts, var būt atļauts tikai starpniekserveris, vai 443 var tikt caurspīdīgi pārsūtīts uz pārbaudes kasti, kas nespēj nolasīt, ko tas pārvadā. Pirmo atrisina zemāk dotā profila izmaiņa, otro starpniekservera iestatījumi, un trešais var pabeigt rokasspiedienu un pēc tam apstāties, kad inspektoram nepatīk plūsma. Zināšana, ar kuru no trim jūs saskaraties, ir atšķirība starp desmit minūšu izmaiņu un pēcpusdienu, kas pavadīta, pārinstalējot klientus.

Pārvietojiet klausītāju un profilu kopā

Servera pusē iestatiet klausītāju uz to, ko tīkls atļauj: port 443 un proto tcp servera konfigurācijā, tad restartējiet pakalpojumu un apstipriniet ligzdu ar ss -lntp. Klienta pusē profilam jāsakrīt, jo transports un ports atrodas ārpus tuneļa: proto tcp un port 443 .ovpn failā vai atbilstošie lauki lietotnes iestatījumu ekrānā. Profils, kas joprojām vērsts uz UDP 1194, neizdodas tieši tāpat kā iepriekš, un rodas kārdinājums vainot jau izlabotu ugunsmūri. Ja tas pats resursdators atbild arī ar HTTPS uz 443, divi klausītāji nevar dalīt šo adresi un protokolu; dodiet VPN otru adresi vai lieciet priekšā demultipleksoru.

Vērojiet pirmo savienojumu ar tcpdump -ni any port 443 abos galos. Paketes, kas iziet no klienta un nekad neierodas, nozīmē, ka tīkls tomēr filtrē, vai arī profila adrese nav tā, ko jūs pieņemat. Paketes, kas ierodas bez atbildes, sūta jūs atpakaļ uz servera žurnālu, kur protokolu neatbilstība uzreiz parādās kā izmesta pakete.

Kad no tīkla iziet tikai starpniekserveris

Daži viesu tīkli nepieļauj neko citu kā HTTP starpniekserveri, kas ir citāds ierobežojums nekā slēgts ports un izslēdz vairāk nekā OpenVPN. Klienti, kas runā tikai PPTP, L2TP/IPsec vai kailu IPsec, tam nevar iziet cauri, jo šie projekti paredz, ka to ārējais protokols sasniegs serveri tieši. OpenVPN var, ar http-proxy proxy.example.net 8080 klienta profilā, ja starpniekserveris atļauj CONNECT metodi uz jūsu portu. SOCKS starpniekserveris ir vēl vienkāršāks, jo pārsūta plūsmu, neinteresējoties, kas ir iekšā.

Tur, kur klientam nav starpniekservera atbalsta, parasti paliek SSH tunelis pa 443. Tas pievieno otru slāni, un tīkla operators var par to izteikt viedokli, tāpēc uztveriet to kā tiltu vienam braucienam, nevis kā arhitektūru.

Novērtējiet rezerves ceļa cenu pirms tā paturēšanas

TCP TCP iekšienē ir zināma cena. Kad ārējais savienojums ir TCP un lietderīgā slodze arī ir TCP, zaudēts segments izraisa atkārtotu pārsūtīšanu abos slāņos, un iekšējais savienojums atkāpjas no zaudējuma, ko tas nespēj saskatīt. Pārlūkošana to iztur; interaktīvas sesijas un zvani to izjūt. Paturiet TCP 443 klausītāju kā rezerves ceļu tīkliem, kas to pieprasa, un atstājiet UDP kā noklusējumu visam, kas to vēl laiž cauri.

Ierakstiet izvēli profila nosaukumā un atbalsta piezīmēs: kurš ports, kurš protokols un kurš tīkls to izraisīja. Pēc tam pajautājiet tīkla administratoram, vai šis ports paliks atvērts pēc nākamās aprīkojuma atjaunošanas, jo rezerves ceļš, kas klusi pazūd, ir sliktāks par pilnīgi nekādu rezerves ceļu.