OpenVPN verbind nie op hotel-Wi-Fi nie? Probeer TCP 443

Maak die kliënt oop, druk Connect en lees die statuslyn eerder as die dialoogvenster wat daarop volg. 'n Profiel wat by Connecting of Waiting for server vasval ná 'n hotel-, kampus- of mobiele netwerk het gewoonlik sy vervoer iewers op die pad verloor, nie sy geloofsbriewe nie. Die nuttige volgende stap is om te leer wat daardie netwerk dra voordat jy aan die bediener raak. Moet niks verander voordat dieselfde profiel elders gewerk het nie.

Toets eers vanaf 'n selfoon se hotspot. As die tonnel daar opkom, is die bediener, die sertifikaat en die rekening heeltemal in orde, en die enigste veranderlike wat oorbly, is die netwerk voor jou.

Begin by die kliënt: lees die statuslyn

Die statuslyn sê watter fase misluk het. 'n Kliënt wat by Connecting vashaak, is steeds besig om die gasheer op te los of die buitenste sok te open; een wat Waiting for server bereik, het 'n pad maar geen antwoord nie; een wat verifieer en dan verbinding verloor, het heeltemal 'n ander probleem. Die kliëntlog en die profiel se eie remote en proto-velde wys wat die kliënt probeer doen, en --verb 4 op 'n opdragreëlkliënt druk dieselfde besonderhede. Om dit met die netwerk voor jou te vergelyk, is wat die bewering dat die VPN geblokkeer is, in 'n spesifieke stelling verander.

Ondersoek dan die netwerk met gereedskap wat jy reeds het. nc -vzu 203.0.113.10 1194 stuur 'n UDP-datagram, curl -v telnet://203.0.113.10:443 rapporteer of 'n TCP-handdruk voltooi, en 'n blaaier wat 'n HTTPS-bladsy laai, bewys net dat uitgaande 443 daardie een gasheer bereik. Klein ondersoeke antwoord wat die VPN-kliënt nie kan nie: watter poort en protokol hierdie netwerk hoegenaamd verlaat.

Drie netwerkgedragings lyk van die kliënt af dieselfde en vereis verskillende antwoorde. Uitgaande 443 kan oop wees, net 'n instaanbediener kan toegelaat word, of 443 kan deursigtig na 'n inspeksieboks deurgestuur word wat nie kan lees wat dit dra nie. Die eerste word deur die profielverandering hieronder reggemaak, die tweede deur instaanbediener-instellings, en die derde kan 'n handdruk voltooi en dan vashaak wanneer die inspekteur besluit hy hou nie van die stroom nie. Om te weet watter een jy in die gesig staar, is die verskil tussen 'n verandering van tien minute en 'n middag se herinstalleer van kliënte.

Skuif die luisteraar en die profiel saam

Aan die bedienerkant, stel die luisteraar op wat die netwerk toelaat: port 443 en proto tcp in die bedienerkonfigurasie, herbegin dan die diens en bevestig die sok met ss -lntp. Aan die kliëntkant moet die profiel saamstem, want vervoer en poort sit buite die tonnel: proto tcp en port 443 in die .ovpn, of die ooreenstemmende velde in die app se instellingsskerm. 'n Profiel wat steeds op UDP 1194 gemik is, misluk presies soos voorheen, en die versoeking is om 'n brandmuur te blameer wat reeds reggemaak is. As dieselfde gasheer ook HTTPS op 443 antwoord, kan die twee luisteraars nie daardie adres en protokol deel nie; gee die VPN 'n tweede adres of plaas 'n demultiplekser voor.

Volg die eerste verbinding deur met tcpdump -ni any port 443 aan beide kante. Pakkette wat die kliënt verlaat en nooit aankom nie, beteken die netwerk filter tog, of die adres in die profiel is nie die een wat jy aanneem nie. Pakkette wat aankom sonder enige antwoord stuur jou terug na die bedienerlog, waar 'n protokolwanpassing onmiddellik as 'n laat val pakket verskyn.

Wanneer net 'n instaanbediener die netwerk verlaat

Sommige gasnetwerke laat niks anders as 'n HTTP-instaanbediener toe nie, wat 'n ander beperking as 'n geslote poort is en meer as OpenVPN uitsluit. Kliënte wat net PPTP, L2TP/IPsec of blote IPsec praat, het geen manier deur een nie, want daardie ontwerpe verwag dat hul buitenste protokol die bediener direk bereik. OpenVPN kan, met http-proxy proxy.example.net 8080 in die kliëntprofiel, mits die instaanbediener die CONNECT-metode na jou poort toelaat. 'n SOCKS-instaanbediener is nog makliker, want dit stuur die stroom deur sonder om te gee wat binne-in is.

Waar die kliënt geen instaanbediener-ondersteuning het nie, is 'n SSH-tonnel oor 443 gewoonlik wat oorbly. Dit voeg 'n tweede laag by, en die operateur van die netwerk het miskien 'n mening daaroor, so behandel dit as 'n brug vir een reis eerder as 'n argitektuur.

Weeg die terugvalopsie voordat jy dit hou

TCP binne TCP het 'n bekende koste. Wanneer die buitenste verbinding TCP is en die vrag ook TCP is, veroorsaak 'n verlore segment herversending op albei lae, en die binneste verbinding trek terug van 'n verlies wat dit nie kan sien nie. Blaai oorleef dit; interaktiewe sessies en oproepe voel dit. Hou die TCP 443-luisteraar as 'n terugval vir netwerke wat dit vereis, en laat UDP die verstek vir alles wat dit nog deurlaat.

Teken die keuse in die profielnaam en in die ondersteuningsnotas aan: watter poort, watter protokol en watter netwerk dit genoodsaak het. Vra dan die netwerk se administrateur of daardie poort na die volgende toerustingvernuwing oop bly, want 'n terugval wat stilweg verdwyn, is erger as geen terugval nie.