Kodėl OpenVPN profilis namuose veikia, o viešbutyje nepavyksta

Biuro Wi-Fi ir viešbučio kambarys tam pačiam nešiojamajam kompiuteriui gali duoti du visiškai skirtingus tinklus, o tarp jų esantis profilis apie tai nieko nežino. Namuose veikiantis nustatymas daro prielaidą, kad yra leidžianti viršutinė jungtis, veikiantis vardų sprendimas ir vietinis potinklis, kuris nesusiduria su niekuo, ką tunelis perduoda. Kiekviena iš šių prielaidų gali nepavyksti atskirai.

Naudingas būdas tai derinti yra traktuoti tinklą kaip keturis atskirus faktus ir tada juos tikrinti iš eilės. Pirmiausia spėlioti apie profilį paprastai duoda pakeitimą, kuris nieko nepataiso ir užmaskuoja įrodymus.

Keturi tinklo faktai skiriasi priklausomai nuo vietos

Pirmas faktas yra tai, ar vietinis tinklas apskritai išleidžia jus lauk. Prisijungimo portalas įleidžia įrenginį į prisijungimo puslapį ir blokuoja visa kita, kol tas puslapis nebaigtas, o tai reiškia, kad tunelis negali prasidėti, kad ir koks teisingas būtų profilis.

Antrasis yra vardų sprendimas. Portalas, perimantis DNS, į kiekvieną užklausą atsako savo adresu, todėl VPN mazgo vardas išsprendžiamas į portalą ir klientas bando statyti tunelį į tinklalapį.

Trečiasis yra transporto filtravimas. Tinklai, norintys leisti tik naršymą, praleidžia TCP 443 į bet kokias paskirties vietas ir numeta beveik visa kita, įskaitant UDP.

Ketvirtasis yra adresavimas. Vietinis potinklis gali persidengti su tinklu už tunelio, arba viršutinė jungtis gali visai nepateikti jokio tinkamo IPv4 maršruto.

Vardų sprendimas ir prisijungimo portalas

Pakeiskite profilyje esantį mazgo vardą skaitiniu serverio adresu ir bandykite dar kartą. Jei IP prisijungia, o vardas ne, kalta vardų sprendimas, o pats profilis yra tvarkingas.

Prieš liedami VPN atidarykite naršyklę ir pabandykite įprastą HTTP puslapį. Nukreipimas į prisijungimo puslapį reiškia, kad portalas dar nebaigtas; užbaikite jį ir tada junkitės iš naujo. Daugelis viešbučių taip pat nutraukia sesiją po kelių valandų, o tai atrodo kaip dienos vidurio atsijungimas, o ne prisijungimo problema.

Jei skaitinis adresas taip pat nepavyksta, vardų sprendimas nėra paaiškinimas, todėl pereikite prie transporto. Išsaugokite adresą, kurį tikrinote, nes jis pasakys kitam patikrinimui, ar paketai apskritai paliko mašiną.

Transporto filtravimas: pirmiausia UDP, TCP 443 kaip atsarginis

OpenVPN srautas per UDP 1194 neatrodo kaip niekas, ką viešbučio ugniasienė atpažintų, todėl jis numetamas be klaidos. Klientas kartoja, kol baigiasi jo laiko limitas, o vartotojas mato ryšį, kuris niekada neužsimezga, o ne atmetimą. Taip besielgiančios ugniasienės retai kur nors matomai registruoja numetimą. Atmetimo nebuvimas pats savaime yra užuomina.

TCP 443 yra patikimas atsarginis variantas, nes tinklas negali jo atskirti nuo įprasto HTTPS. Naudokite operatoriaus TCP profilį, kai jis yra, nes serveris taip pat turi klausytis tuo transportu ir prievadu; keičiant tik klientą gaunama kitokia gedimo rūšis. Jei TCP profilio nėra, paklauskite operatoriaus, o ne išgalvokite jį redaguodami prievadą. Serverio pusė taip pat turi sutikti, o neatitikimas vėl atrodo kaip ugniasienės problema.

Tikėkitės našumo kainos. TCP TCP viduje sustiprina pakartotinius perdavimus nuostolingoje jungtyje, todėl veikiantis TCP tunelis gali vis tiek atrodyti lėtas perkrautame viešbučio tinkle. Tai mainai už pasiekiamumą, o ne trūkumas, kurį reikia persekioti.

Adresų susidūrimai ir viršutinės jungtys be IPv4

Tunelis gali susidaryti ir vis tiek nieko neperduoti. Kai vietinis LAN ir nuotolinis tinklas dalijasi priešdėliu, pavyzdžiui, 192.168.1.0/24, klientas nuotolinį mazgą laiko tiesiogiai prijungtu ir siunčia paketą į vietinę jungtį, o ne į tunelį. Simptomas yra sėkmingas ryšys su vienu nepasiekiamu potinkliu, kurį lengva neteisingai perskaityti kaip serverio pusės maršruto problemą.

Nuolatinis sprendimas yra perkelti nuotolinį LAN į neįprastą privatų diapazoną. Pasirinkus diapazoną, kurio namuose niekas nenaudoja, pavyzdžiui, 10.42.0.0/24, problema išvengiama kiekvienai būsimai vietai, o ne vienai. Vietinė apeiga yra vengti to viešbučio, viešosios prieigos taško ar maršrutizatoriaus, o tai visai ne sprendimas.

Mobiliojo ryšio jungtys prideda du variantus. Operatoriaus lygmens NAT reiškia, kad įeinančios jungtys neateina, o tai svarbu, jei talpinate serverį, bet ne išeinančiam klientui. APN, sukonfigūruotas tik su IPv6 ir NAT64 vertimu, gali sužlugdyti klientą, kuris reikalauja tikro IPv4 maršruto, o įprasta priemonė yra pakeisti APN protokolą į IPv4 arba dvigubą krūvą.

Simptomai po to, kai tunelis pakyla

Tunelis, kuris prisijungia ir tada nutyla, paprastai yra keepalive arba MTU problema, o ne užblokuotas prievadas. Ryšys, kuris nutrūksta po fiksuoto minučių skaičiaus, rodo į keepalive arba pakartotinio derėjimosi laikmatį. Nustatykite klientą tikrinti savo partnerį ir paleisti iš naujo, kai atsakymai nutrūksta, ir išbandykite mažesnį tunelio MTU, jei ping praeina, o dideli perdavimai stringa.

Prieš prašydami pagalbos užsirašykite tris dalykus: adresą, kurį bandėte, ir ar jis atsakė, transportą ir prievadą, kuriuos naudojote, ir nepavykusio tinklo vietinį potinklį. Kartu jie atskiria vardų sprendimą nuo transporto filtravimo ir nuo adresų susidūrimo, tai priežastys, kurios atlaiko susidūrimą su įrodymais.