OpenVPN ei yhdistä hotellin Wi-Fi-verkossa? Kokeile TCP 443

Avaa asiakasohjelma, paina Connect ja lue tilabarivi eikä sen perässä avautuvaa valintaikkunaa. Profiili, joka juuttuu Connecting- tai Waiting for server -tilaan hotelli-, kampus- tai matkapuhelinverkon jälkeen, on yleensä menettänyt kuljetuksensa jossain matkan varrella, ei tunnuksiaan. Hyödyllinen seuraava askel on selvittää, mitä verkko kuljettaa, ennen kuin kosket palvelimeen. Älä muuta mitään, ennen kuin sama profiili on toiminut jossain muualla.

Testaa ensin puhelimen hotspotista. Jos tunneli nousee siellä, palvelin, varmenne ja tili ovat kunnossa, ja ainoa jäljellä oleva muuttuja on edessäsi oleva verkko.

Aloita asiakkaasta: lue tilabarivi

Tilabarivi kertoo, missä vaiheessa epäonnistuttiin. Connecting-tilaan juuttunut asiakas ratkaisee yhä isäntänimeä tai avaa ulomman pistokkeen; se, joka saavuttaa Waiting for server -tilan, omaa polun mutta ei vastausta; se, joka todennetaan ja sitten katkeaa, kärsii aivan eri ongelmasta. Asiakkaan loki ja profiilin omat remote- ja proto-kentät näyttävät, mitä asiakas yrittää tehdä, ja --verb 4 komentoriviasiakkaassa tulostaa samat yksityiskohdat. Juuri vertailu edessäsi olevaan verkkoon muuttaa väitteen »VPN on estetty« konkreettiseksi väitteeksi.

Koettele sitten verkkoa työkaluilla, jotka sinulla jo on. nc -vzu 203.0.113.10 1194 lähettää UDP-datagrammin, curl -v telnet://203.0.113.10:443 kertoo, täyttyykö TCP-kättely, ja HTTPS-sivun lataava selain todistaa vain, että lähtevä 443 tavoittaa juuri sen yhden isännän. Pienet kokeet vastaavat siihen, mihin VPN-asiakas ei pysty: mikä portti ja protokolla ylipäätään poistuu tästä verkosta.

Kolme verkon käyttäytymistä näyttää asiakkaasta samalta ja vaatii erilaisia vastauksia. Lähtevä 443 voi olla auki, vain välityspalvelin voidaan sallia, tai 443 voidaan välittää läpinäkyvästi tarkastuslaatikkoon, joka ei pysty lukemaan, mitä se kuljettaa. Ensimmäisen korjaa alla oleva profiilin muutos, toisen välityspalvelimen asetukset, ja kolmas voi täydentää kättelyn ja sitten juuttua, kun tarkastaja päättää, ettei pidä virrasta. Sen tietäminen, kumpaan törmäät, on ero kymmenen minuutin muutoksen ja asiakkaiden uudelleenasennukseen kuluvan iltapäivän välillä.

Siirrä kuuntelija ja profiili yhdessä

Palvelimen puolella aseta kuuntelija siihen, mitä verkko sallii: port 443 ja proto tcp palvelimen kokoonpanossa, käynnistä sitten palvelu uudelleen ja vahvista pistoke komennolla ss -lntp. Asiakkaan puolella profiilin on oltava samaa mieltä, koska kuljetus ja portti ovat tunnelin ulkopuolella: proto tcp ja port 443 .ovpn-tiedostossa tai sovelluksen asetusnäytön vastaavat kentät. Profiili, joka tähtää yhä UDP 1194:ään, epäonnistuu täsmälleen kuten ennenkin, ja kiusaus on syyttää palomuuria, joka on jo korjattu. Jos sama isäntä vastaa myös HTTPS:ään portissa 443, kaksi kuuntelijaa ei voi jakaa sitä osoitetta ja protokollaa; anna VPN:lle toinen osoite tai aseta demultiplekseri eteen.

Seuraa ensimmäistä yhteyttä komennolla tcpdump -ni any port 443 molemmissa päissä. Paketit, jotka lähtevät asiakkaasta eivätkä koskaan saavu, tarkoittavat, että verkko kuitenkin suodattaa, tai että profiilin osoite ei ole se, jonka oletat. Vastauksetta saapuvat paketit lähettävät sinut takaisin palvelimen lokiin, jossa protokollan epäsopivuus näkyy heti pudotettuna pakettina.

Kun verkosta pääsee ulos vain välityspalvelin

Jotkin vierasverkot eivät salli muuta kuin HTTP-välityspalvelimen, mikä on eri rajoitus kuin suljettu portti ja sulkee pois enemmän kuin OpenVPN:n. Asiakkaat, jotka puhuvat vain PPTP:tä, L2TP/IPsec:iä tai pelkkää IPsec:iä, eivät pääse sen läpi, koska ne rakenteet odottavat ulomman protokollansa saavuttavan palvelimen suoraan. OpenVPN pystyy siihen, kun asiakasprofiilissa on http-proxy proxy.example.net 8080, edellyttäen että välityspalvelin sallii CONNECT-menetelmän portillesi. SOCKS-välityspalvelin on vielä helpompi, koska se välittää virran välittämättä siitä, mitä sisällä on.

Kun asiakkaalla ei ole välityspalvelintukea, SSH-tunneli 443:n yli on yleensä se, mikä jää. Se lisää toisen kerroksen, ja verkon operaattorilla voi olla siitä mielipide, joten kohtele sitä siltana yhtä matkaa varten, älä arkkitehtuurina.

Laske varavaihtoehdon hinta ennen kuin pidät sen

TCP TCP:n sisällä maksaa tunnetusti. Kun ulompi yhteys on TCP ja hyötykuorma myös TCP, kadonnut segmentti laukaisee uudelleenlähetyksen molemmissa kerroksissa, ja sisempi yhteys perääntyy tappiosta, jota se ei näe. Selailu kestää sen; vuorovaikutteiset istunnot ja puhelut tuntevat sen. Pidä TCP 443 -kuuntelija varavaihtoehtona verkoille, jotka vaativat sitä, ja jätä UDP oletukseksi kaikelle, mikä vielä päästää sen läpi.

Kirjaa valinta profiilin nimeen ja tukimuistiinpanoihin: mikä portti, mikä protokolla ja mikä verkko sen aiheutti. Kysy sitten verkon ylläpitäjältä, pysyykö portti auki seuraavan laiteuudistuksen jälkeen, sillä hiljaa katoava varavaihtoehto on pahempi kuin ei varavaihtoehtoa lainkaan.