Miks OpenVPN profiil töötab kodus, aga hotellis ebaõnnestub

Kontori Wi-Fi ja hotellituba võivad anda samale sülearvutile kaks väga erinevat võrku ning nende vahel olev profiil ei tea sellest midagi. Kodus töötav eeldab lubavat ühendust, toimivat nimelahendust ja kohalikku alamvõrku, mis ei kattu millegagi, mida tunnel kannab. Kõik need eeldused võivad eraldi ebaõnnestuda.

Kasulik viis seda siluda on käsitleda võrku nelja eraldi faktina ja seejärel neid järjest kontrollida. Profiili esimesena oletamine tekitab tavaliselt muudatuse, mis ei paranda midagi ja varjab tõendeid.

Neli võrgufakti muutuvad asukohiti

Esimene fakt on, kas kohalik võrk üldse välja laseb. Sisselogimisportaal laseb seadme sisselogimislehele ja blokeerib kõik muu, kuni see leht on lõpetatud, mis tähendab, et tunnel ei saa alata, ükskõik kui õige profiil on.

Teine on nimelahendus. Portaal, mis DNS-i püüab, vastab igale päringule oma aadressiga, mistõttu VPN-i hostinimi lahendub portaalile ja klient üritab ehitada tunnelit veebilehele.

Kolmas on transpordi filtreerimine. Võrgud, mis tahavad lubada ainult sirvimist, lasevad TCP 443 läbi suvalistele sihtkohtadele ja viskavad kõrvale peaaegu kõik muu, sealhulgas UDP.

Neljas on adresseerimine. Kohalik alamvõrk võib kattuda tunneli taga oleva võrguga või ei pruugi ühendus pakkuda ühtegi kasutatavat IPv4-teed.

Nimelahendus ja sisselogimisportaal

Asendage profiilis hostinimi serveri numbrilise aadressiga ja proovige uuesti. Kui IP ühendub ja nimi mitte, on süüdi nimelahendus ning profiil ise on korras.

Avage brauser ja proovige tavalist HTTP-lehte enne, kui VPN-i puudutate. Ümbersuunamine sisselogimislehele tähendab, et portaal on veel pooleli; lõpetage see ja seejärel ühenduge uuesti. Paljud hotellid lõpetavad sessiooni ka mõne tunni pärast, mis näeb välja nagu keskpäevane katkestus, mitte sisselogimisprobleem.

Kui ka numbriline aadress ebaõnnestub, ei ole nimelahendus seletus, seega liikuge transpordi juurde. Jätke meelde testitud aadress, sest see ütleb järgmisele kontrollile, kas paketid üldse masinast lahkusid.

Transpordi filtreerimine: esmalt UDP, varuvariant TCP 443

OpenVPN voog üle UDP 1194 ei näe välja nagu miski, mida hotelli tulemüür tunneb, seega visatakse see vigadeta kõrvale. Klient proovib uuesti, kuni selle ajalõpp lõpeb, ja kasutaja näeb ühendust, mis ei teki kunagi, mitte keeldumist. Tulemüürid, mis nii käituvad, logivad kõrvaleviskamist harva kuskil nähtavas kohas. Keeldumise puudumine on ise vihje.

TCP 443 on usaldusväärne varuvariant, sest võrk ei suuda seda tavalisest HTTPS-ist eristada. Kasutage operaatori TCP-profiili, kui see olemas on, kuna ka server peab sellel transpordil ja pordil kuulama; ainult kliendi muutmine tekitab teist tüüpi tõrke. Kui TCP-profiili pole, küsige operaatorilt, selle asemel et porti redigeerides uus välja mõelda. Serveripool peab nõustuma ja lahknevus näeb jälle välja nagu tulemüüriprobleem.

Oodake jõudluse hinda. TCP TCP sees võimendab kordusi kadudega ühendusel, seega võib toimiv TCP-tunnel umbes hotellivõrgus siiski aeglane tunduda. See on vahetus kättesaadavuse eest, mitte viga, mida taga ajada.

Aadresside kokkupõrked ja IPv4-ta ühendused

Tunnel võib püsti minna ja ikkagi mitte midagi kanda. Kui kohalik LAN ja kaugvõrk jagavad prefiksit nagu 192.168.1.0/24, peab klient kaugperemeesarvutit otse ühendatuks ja saadab paketi tunnelile kohaliku lüli kaudu. Sümptom on edukas ühendus ühe kättesaamatu alamvõrguga, mida on lihtne valesti lugeda serveripoolse marsruudiprobleemina.

Püsiv parandus on viia kaug-LAN ebatavalisse privaatsesse vahemikku. Sellise vahemiku valimine, mida keegi kodus ei kasuta, näiteks 10.42.0.0/24, hoiab probleemi ära iga tulevase asukoha jaoks, mitte ainult ühe jaoks. Kohalik möödarääk on seda hotelli, hotspoti või ruuterit vältida, mis pole üldse lahendus.

Mobiilsed ühendused lisavad kaks varianti. Operaatoritasandi NAT tähendab, et sissetulevad ühendused ei jõua kohale, mis loeb siis, kui majutate serverit, aga mitte väljuva kliendi puhul. Ainult IPv6-ga ja NAT64-tõlkega konfigureeritud APN võib ebaõnnestuda kliendil, kes nõuab tõelist IPv4-teed, ja tavaline abinõu on muuta APN-i protokoll IPv4 või kahekordse virna vastu.

Sümptomid pärast tunneli püstitamist

Tunnel, mis ühendub ja siis vaikib, on tavaliselt keepalive'i või MTU probleem, mitte blokeeritud port. Ühendus, mis katkeb kindla arvu minutite järel, viitab keepalive'i või uuesti läbirääkimise taimerile. Seadke klient oma partnerit sondeerima ja vastuste lakkamisel taaskäivituma, ning testige väiksemat tunneli MTU-d, kui pingid lähevad läbi, aga suured ülekanded takerduvad.

Enne abi palumist kirjutage üles kolm asja: aadress, mida proovisite, ja kas see vastas, transport ja port, mida kasutasite, ning ebaõnnestunud võrgu kohalik alamvõrk. Koos eraldavad need nimelahenduse transpordi filtreerimisest ja aadresside kokkupõrkest, mis on põhjused, mis peavad vastu kokkupuutele tõenditega.