OpenVPN ferbynt net op hotel-wifi? Brûk TCP 443

Iepenje de klant, druk op Ferbine en lês de statusrigel ynstee fan de dialooch dy't dêrnei komt. In profyl dat nei in hotel-, kampus- of mobyl netwurk hingjen bliuwt op Ferbinen of Wachtet op server hat meastentiids syn transport earne ûnderweis ferlern, net syn oanmeldgegevens. De nuttige folgjende stap is om te learen wat dat netwurk ferfiert foardat jo de server oanreitsje. Feroarje neat oant itselde profyl earne oars wurke hat.

Test earst fanôf in hotspot fan in tillefoan. As de tunnel dêr opkomt, binne de server, it sertifikaat en it akkount allegear yn oarder, en is de iennige fariabele dy't oerbliuwt it netwurk foar jo.

Begjin by de klant: lês de statusrigel

De statusrigel fertelt jo hokker stadium mislearre. In klant dy't by Ferbinen fêstsit, is noch de host oan it oplossen of de bûtenste socket oan it iepenjen; ien dy't Wachtet op server berikt, hat in paad mar gjin antwurd; ien dy't autentisearret en dan fuortfalt, hat in hiel oar probleem. It klantlog en de eigen remote- en proto-fjilden fan it profyl litte sjen wat de klant probearret te dwaan, en --verb 4 op in kommandorigel-klant printsje deselde details. It fergelykjen fan dat mei it netwurk foar jo is wat 'de VPN is blokkearre' feroaret yn in konkrete bewearing.

Probearje dan it netwurk mei helpmiddels dy't jo al hawwe. nc -vzu 203.0.113.10 1194 stjoert in UDP-datagram, curl -v telnet://203.0.113.10:443 rapportearret oft in TCP-handshake foltôget, en in browser dy't in HTTPS-side laadt, bewiist allinnich dat útgeand 443 dat iene host berikt. Lytse probes beäntwurdzje wat de VPN-klant net kin: hokker poarte en protokol dit netwurk hielendal ferlitte.

Trije netwurkgedragingen lykje fanôf de klant opinoar en freegje ferskillende antwurden. Utgeand 443 kin iepen wêze, allinnich in proxy kin tastien wêze, of 443 kin transparant trochstjoerd wurde nei in ynspeksjeboks dy't net lêze kin wat it ferfiert. It earste wurdt oplost troch de profylferoaring hjirûnder, it twadde troch proxy-ynstellingen, en it tredde kin in handshake foltôgje en dan hingjen bliuwe as de ynspekteur beslút dat er de stream net lije mei. Witten hokker fan de trije jo treffe, is it ferskil tusken in feroaring fan tsien minuten en in middei klanten opnij ynstallearje.

Ferpleats de listener en it profyl tegearre

Serverside sette jo de listener op wat it netwurk tastiet: port 443 en proto tcp yn 'e serverkonfiguraasje, dan de tsjinst opnij starte en de socket befêstigje mei ss -lntp. Klientside moat it profyl dermei ynstimme, want transport en poarte steane bûten de tunnel: proto tcp en port 443 yn 'e .ovpn, of de oerienkommende fjilden yn it ynstellingsskerm fan 'e app. In profyl dat noch op UDP 1194 rjochte is, mislearret krekt as earder, en de ferlieding is om in firewall de skuld te jaan dy't al reparearre is. As deselde host ek HTTPS op 443 beantwurdet, kinne de twa listeners dat adres en protokol net diele; jou de VPN in twadde adres of set in demultiplexer foaroan.

Sjoch de earste ferbining troch mei tcpdump -ni any port 443 oan beide kanten. Pakketten dy't de klant ferlitte en nea oankomme, betsjutte dat it netwurk dochs filteret, of dat it adres yn it profyl net is wat jo oannimme. Pakketten dy't oankomme sûnder antwurd stjoere jo werom nei it serverlog, dêr't in protokolmismatch daliks as in fuortfallen pakket ferskynt.

As allinnich in proxy it netwurk ferlit

Guon gaste-netwurken tastean neat oars as in HTTP-proxy, wat in oare beheining is as in sletten poarte en mear as OpenVPN útslút. Klanten dy't allinnich PPTP, L2TP/IPsec of keale IPsec prate, komme dêr net trochhinne, want dy ûntwerpen ferwachtsje dat har bûtenste protokol de server direkt berikt. OpenVPN kin it, mei http-proxy proxy.example.net 8080 yn it klantprofyl, mits de proxy de CONNECT-metoade nei jo poarte tastiet. In SOCKS-proxy is noch makliker, want dy stjoert de stream troch sûnder him derom te bekroadzjen wat der yn sit.

Wêr't de klant gjin proxy-stipe hat, is in SSH-tunnel oer 443 meastentiids wat oerbliuwt. It foeget in twadde laach ta, en de operator fan it netwurk kin der in miening oer hawwe, dus behannelje it as in brêge foar ien reis ynstee fan as in arsjitektuer.

Priisje de fallback foardat jo him hâlde

TCP yn TCP hat in bekende priis. As de bûtenste ferbining TCP is en de lading ek TCP, dan feroarsaket in ferlern segmint weromstjoering op beide lagen, en de binnenste ferbining docht efterút foar in ferlies dat er net sjen kin. Browsen oerlibbet dat; ynteraktive sesjes en oproppen fiele dat. Hâld de TCP 443-listener as fallback foar netwurken dy't him easkje, en lit UDP de standert bliuwe foar alles dat him noch trochlit.

Skriuw de kar op yn 'e profylnamme en yn 'e stipe-notysjes: hokker poarte, hokker protokol en hokker netwurk hat der oanlieding ta jûn. Freegje dan de behearder fan it netwurk oft dy poarte iepen bliuwt nei de folgjende apparatuerferfanging, want in fallback dy't stil ferdwynt is slimmer as hielendal gjin fallback.