Zakaj profil OpenVPN doma deluje, v hotelu pa ne

Pisarniški Wi-Fi in hotelska soba lahko istemu prenosniku ponudita dve zelo različni omrežji, profil vmes pa o tem ne ve nič. Kar deluje doma, predpostavlja popustljivo odhodno povezavo, delujoče razreševanje imen in lokalno podomrežje, ki ne trči z ničimer, kar tunel prenaša. Vsaka od teh predpostavk lahko odpove posebej.

Koristen način za odpravljanje težave je obravnavati omrežje kot štiri ločena dejstva in jih nato preizkusiti po vrsti. Ugibanje o profilu najprej običajno prinese spremembo, ki ničesar ne popravi in zakrije dokaze.

Štiri omrežna dejstva se med lokacijami spreminjajo

Prvo dejstvo je, ali vas lokalno omrežje sploh spusti ven. Prijavni portal spusti napravo na prijavno stran in blokira vse drugo, dokler stran ni dokončana, kar pomeni, da tunel ne more začeti, ne glede na to, kako pravilen je profil.

Drugo je razreševanje imen. Portal, ki prestreza DNS, odgovori na vsako poizvedbo z lastnim naslovom, zato se ime gostitelja VPN razreši na portal in odjemalec poskuša zgraditi tunel do spletne strani.

Tretje je filtriranje prevoza. Omrežja, ki želijo dovoliti samo brskanje, spustijo TCP 443 do poljubnih ciljev in zavržejo skoraj vse drugo, vključno z UDP.

Četrto je naslavljanje. Lokalno podomrežje se lahko prekriva z omrežjem za tunelom ali pa odhodna povezava ne ponuja nobene uporabne poti IPv4.

Razreševanje imen in prijavni portal

Zamenjajte ime gostitelja v profilu s številčnim naslovom strežnika in poskusite znova. Če se IP poveže, ime pa ne, je krivo razreševanje imen, sam profil pa je v redu.

Odprite brskalnik in poskusite običajno stran HTTP, preden se dotaknete VPN. Preusmeritev na prijavno stran pomeni, da portal še čaka; dokončajte ga in se nato znova povežite. Mnogi hoteli po nekaj urah tudi prekinejo sejo, kar je videti kot prekinitev sredi dneva in ne kot težava s prijavo.

Če tudi številčni naslov odpove, razreševanje imen ni razlaga, zato pojdite na prevoz. Obdržite naslov, ki ste ga preizkusili, saj naslednji preveritvi pove, ali so paketi sploh zapustili stroj.

Filtriranje prevoza: najprej UDP, TCP 443 kot rezerva

Tok OpenVPN prek UDP 1194 ni videti kot nič, kar hotelski požarni zid prepozna, zato se zavrže brez napake. Odjemalec poskuša znova, dokler ne poteče njegov časovni limit, uporabnik pa vidi povezavo, ki se nikoli ne vzpostavi, namesto zavrnitve. Požarni zidovi, ki se tako obnašajo, zavrženja redko zabeležijo kjer koli, kjer bi to videli. Odsotnost zavrnitve je sama po sebi namig.

TCP 443 je zanesljiva rezerva, ker ga omrežje ne more ločiti od običajnega HTTPS. Uporabite operaterjev profil TCP, kadar obstaja, saj mora tudi strežnik poslušati na tem prevozu in vratih; spreminjanje samo odjemalca povzroči drugačno vrsto napake. Če profila TCP ni, vprašajte operaterja, namesto da bi si ga izmislili z urejanjem vrat. Stran strežnika se mora strinjati, in neskladje je spet videti kot težava s požarnim zidom.

Pričakujte ceno v zmogljivosti. TCP znotraj TCP ojači ponovne prenose na povezavi z izgubami, zato je delujoč tunel TCP na preobremenjenem hotelskem omrežju lahko še vedno videti počasen. To je menjava za dosegljivost, ne napaka, ki bi jo bilo treba loviti.

Trki naslovov in odhodne povezave brez IPv4

Tunel se lahko vzpostavi in vseeno nič ne prenaša. Ko si lokalni LAN in oddaljeno omrežje delita predpono, kot je 192.168.1.0/24, odjemalec oddaljenega gostitelja šteje za neposredno povezanega in paket pošlje na lokalno povezavo namesto v tunel. Simptom je uspešna povezava z enim nedosegljivim podomrežjem, kar je lahko napačno brati kot težavo s potjo na strani strežnika.

Trajna rešitev je premakniti oddaljeni LAN v nenavadno zasebno območje. Izbira območja, ki ga doma nihče ne uporablja, recimo 10.42.0.0/24, prepreči težavo za vsako prihodnjo lokacijo namesto samo eno. Lokalna rešitev je izogibanje tistemu hotelu, dostopni točki ali usmerjevalniku, kar sploh ni rešitev.

Mobilne odhodne povezave dodajo dve različici. NAT na ravni operaterja pomeni, da vhodne povezave ne prispejo, kar je pomembno, če gostite strežnik, ne pa za odhodnega odjemalca. APN, nastavljen samo z IPv6 in pretvorbo NAT64, lahko izneveri odjemalca, ki vztraja pri pravi poti IPv4, običajno zdravilo pa je spremeniti protokol APN na IPv4 ali dvojni sklad.

Simptomi po dvigu tunela

Tunel, ki se poveže in nato utihne, je običajno težava s keepalive ali MTU, ne blokirana vrata. Povezava, ki pade po določenem številu minut, kaže na časovnik keepalive ali ponovnega pogajanja. Nastavite odjemalca, da preverja partnerja in se znova zažene, ko se odgovori ustavijo, in preizkusite manjši MTU tunela, če pingi uspejo, veliki prenosi pa se ustavijo.

Preden prosite za pomoč, zapišite tri stvari: naslov, ki ste ga poskusili, in ali je odgovoril, prevoz in vrata, ki ste jih uporabili, ter lokalno podomrežje omrežja, ki je odpovedalo. Skupaj ločujejo razreševanje imen od filtriranja prevoza in od trka naslovov, in to so vzroki, ki prestanejo stik z dokazi.