Nem csatlakozik az OpenVPN a hotel Wi-Fi-jén? Próbálja a TCP 443-at

Nyissa meg a klienst, nyomja meg a Csatlakozás gombot, és a megjelenő párbeszédablak helyett az állapotsort olvassa. Az a profil, amely hotel-, campus- vagy mobilhálózat után a Csatlakozás vagy a Kiszolgálóra várakozás állapotban elakad, általában valahol az úton elvesztette a szállítási rétegét, nem a hitelesítő adatait. A következő hasznos lépés megtudni, mit szállít ez a hálózat, mielőtt a kiszolgálóhoz nyúlna. Ne változtasson semmit, amíg ugyanaz a profil máshol nem működik.

Először telefonos hotspotról teszteljen. Ha ott felépül az alagút, a kiszolgáló, a tanúsítvány és a fiók rendben van, és az egyetlen maradék változó az Ön előtti hálózat.

Kezdje a kliensnél: olvassa az állapotsort

Az állapotsor megmondja, melyik szakasz hibázott. A Csatlakozásnál ragadt kliens még a gazdagépet oldja fel vagy a külső socketet nyitja; a Kiszolgálóra várakozásig jutó kliensnek van útvonala, de nincs válasza; a hitelesítés után leeső kliensnek egészen más a problémája. A kliens naplója és a profil saját remote és proto mezői megmutatják, mit próbál tenni a kliens, és --verb 4 a parancssori kliensen ugyanezt a részletességet nyomtatja. Ennek összevetése az előtte álló hálózattal az, ami a 'blokkolva van a VPN' kijelentést konkrét állítássá teszi.

Ezután vizsgálja meg a hálózatot a meglévő eszközeivel. nc -vzu 203.0.113.10 1194 UDP-datagramot küld, curl -v telnet://203.0.113.10:443 jelenti, hogy létrejön-e a TCP kézfogás, és egy HTTPS-oldalt betöltő böngésző csak azt bizonyítja, hogy a kimenő 443 eljut ehhez az egy gazdagéphez. A kis vizsgálatok arra válaszolnak, amire a VPN-kliens nem tud: melyik port és melyik protokoll hagyja el egyáltalán ezt a hálózatot.

Három hálózati viselkedés hasonlónak látszik a kliensről, és különböző válaszokat igényel. A kimenő 443 lehet nyitva, csak proxy lehet engedélyezve, vagy a 443-at átlátszóan továbbíthatják egy olyan vizsgáló dobozhoz, amely nem tudja elolvasni, mit szállít. Az elsőt az alábbi profilváltoztatás orvosolja, a másodikat a proxybeállítások, a harmadik pedig létrehozhatja a kézfogást, majd elakadhat, amikor a vizsgáló úgy dönt, hogy nem kedveli a folyamot. Annak ismerete, melyikkel áll szemben, a különbség egy tízperces változtatás és egy délutáni újratelepítés között.

A figyelőt és a profilt együtt mozgassa

A kiszolgáló oldalán állítsa a figyelőt arra, amit a hálózat enged: port 443 és proto tcp a kiszolgáló konfigurációjában, majd indítsa újra a szolgáltatást, és ss -lntp segítségével ellenőrizze a socketet. A kliens oldalán a profilnak egyeznie kell, mert a szállítási réteg és a port az alagúton kívül van: proto tcp és port 443 az .ovpn fájlban, vagy a megfelelő mezők az alkalmazás beállítási képernyőjén. Az UDP 1194-re még mindig célzó profil pontosan úgy elbukik, mint korábban, és a kísértés az, hogy egy már megjavított tűzfalat okoljunk. Ha ugyanaz a gazdagép HTTPS-t is válaszol a 443-on, a két figyelő nem oszthatja meg ezt a címet és protokollt; adjon a VPN-nek egy második címet, vagy tegyen elé egy demultiplexert.

Kövesse végig az első kapcsolatot tcpdump -ni any port 443 segítségével mindkét végén. A kliensről elinduló és soha meg nem érkező csomagok azt jelentik, hogy a hálózat mégis szűr, vagy a profilban lévő cím nem az, amit feltételez. A válasz nélkül megérkező csomagok visszaküldik a kiszolgáló naplójához, ahol a protokoll-eltérés azonnal eldobott csomagként jelenik meg.

Amikor csak egy proxy hagyja el a hálózatot

Egyes vendéghálózatok semmit nem engednek meg az HTTP-proxy kivételével, ami más korlát, mint egy zárt port, és többet zár ki, mint az OpenVPN. Azok a kliensek, amelyek csak PPTP-t, L2TP/IPsec-et vagy csupasz IPsec-et beszélnek, nem jutnak át rajta, mert ezek a tervek azt várják, hogy külső protokolljuk közvetlenül elérje a kiszolgálót. Az OpenVPN képes rá, http-proxy proxy.example.net 8080 beállítással a kliensprofilban, feltéve hogy a proxy engedélyezi a CONNECT metódust az Ön portjára. A SOCKS-proxy még egyszerűbb, mert továbbítja a folyamot anélkül, hogy érdekelné, mi van benne.

Ahol a kliensnek nincs proxy-támogatása, ott általában a 443 feletti SSH-alagút marad. Hozzáad egy második réteget, és a hálózat üzemeltetőjének lehet erről véleménye, ezért egyetlen utazás hídjaként kezelje, ne architektúraként.

Árazza be a tartalékot, mielőtt megtartaná

A TCP a TCP-ben ismert költséggel jár. Amikor a külső kapcsolat TCP, és a hasznos teher is TCP, egy elveszett szegmens mindkét rétegen újraküldést vált ki, és a belső kapcsolat visszalép egy olyan veszteségtől, amelyet nem lát. A böngészés ezt kibírja; az interaktív munkamenetek és a hívások megérzik. Tartsa meg a TCP 443 figyelőt tartalékként azoknak a hálózatoknak, amelyek megkövetelik, és hagyja az UDP-t alapértelmezésként mindannak, ami még átengedi.

Rögzítse a választást a profil nevében és a támogatási feljegyzésekben: melyik port, melyik protokoll és melyik hálózat váltotta ki. Ezután kérdezze meg a hálózat rendszergazdáját, hogy az a port nyitva marad-e a következő eszközcsere után, mert a csendben eltűnő tartalék rosszabb, mint a semmilyen tartalék.