Miért működik otthon egy OpenVPN-profil, de egy hotelben elakad

Az irodai Wi-Fi és egy hotelszoba két nagyon különböző hálózatot adhat ugyanannak a laptopnak, és a köztük lévő profil erről semmit sem tud. Az otthon működő beállítás megengedő feltöltő kapcsolatot, működő névfeloldást és olyan helyi alhálózatot feltételez, amely nem ütközik semmivel, amit az alagút szállít. Mindegyik feltevés külön-külön megbukhat.

A hibakeresés hasznos módja, hogy a hálózatot négy különálló tényként kezeljük, majd sorban teszteljük őket. Ha először a profilra tippelünk, az általában olyan változtatást eredményez, amely semmit sem javít, és eltakarja a bizonyítékokat.

Négy hálózati tény változik helyszínenként

Az első tény, hogy a helyi hálózat egyáltalán kienged-e. A bejelentkező portál beengedi az eszközt egy bejelentkező oldalra, és minden mást blokkol, amíg az az oldal be nem fejeződik, ami azt jelenti, hogy az alagút nem tud elindulni, bármilyen helyes is a profil.

A második a névfeloldás. A DNS-t elfogó portál minden lekérdezésre a saját címével válaszol, így a VPN gazdagépneve a portálra oldódik fel, és a kliens egy weboldal felé próbál alagutat építeni.

A harmadik a forgalomszűrés. Azok a hálózatok, amelyek csak böngészést akarnak engedni, átengedik a TCP 443-at tetszőleges célokra, és szinte minden mást eldobnak, az UDP-t is beleértve.

A negyedik a címzés. A helyi alhálózat átfedésbe kerülhet az alagút mögötti hálózattal, vagy a feltöltő kapcsolat egyáltalán nem kínál használható IPv4-útvonalat.

Névfeloldás és a bejelentkező portál

Cserélje ki a profilban a gazdagépnevet a kiszolgáló numerikus címére, és próbálja újra. Ha az IP csatlakozik, a név pedig nem, akkor a névfeloldás a hibás, és maga a profil rendben van.

Nyisson egy böngészőt, és próbáljon meg egy közönséges HTTP-oldalt, mielőtt a VPN-hez nyúlna. A bejelentkező oldalra történő átirányítás azt jelenti, hogy a portál még függőben van; fejezze be, majd csatlakozzon újra. Sok hotel néhány óra után lejáratja a munkamenetet is, ami inkább déli megszakításnak látszik, mint bejelentkezési problémának.

Ha a numerikus cím is meghiúsul, a névfeloldás nem magyarázat, ezért lépjen tovább a forgalomra. Tartsa meg a tesztelt címet, mert ez mondja meg a következő ellenőrzésnek, hogy a csomagok egyáltalán elhagyták-e a gépet.

Forgalomszűrés: először UDP, TCP 443 tartalékként

Az UDP 1194 feletti OpenVPN-folyam nem hasonlít semmire, amit egy hotel tűzfala felismer, ezért hiba nélkül eldobja. A kliens újrapróbálkozik, amíg le nem jár az időkorlátja, és a felhasználó egy soha létre nem jövő kapcsolatot lát az elutasítás helyett. Az így viselkedő tűzfalak ritkán naplózzák az eldobást olyan helyen, ahol látná. Az elutasítás hiánya maga a nyom.

A TCP 443 a megbízható tartalék, mert a hálózat nem tudja megkülönböztetni a közönséges HTTPS-től. Használja az üzemeltető TCP-profilját, ha van ilyen, mert a kiszolgálónak is ezen a szállításon és porton kell figyelnie; csak a kliens módosítása másfajta hibát okoz. Ha nincs TCP-profil, kérdezze meg az üzemeltetőt, ahelyett hogy a port szerkesztésével kitalálna egyet. A kiszolgáló oldalnak is egyeznie kell, és az eltérés ismét tűzfalproblémának látszik.

Számítson teljesítményköltségre. A TCP a TCP-ben felerősíti az újraküldéseket egy veszteséges kapcsolaton, ezért egy működő TCP-alagút még mindig lassúnak tűnhet egy zsúfolt hotelhálózaton. Ez a csere az elérhetőségért, nem pedig üldözendő hiba.

Címütközések és IPv4 nélküli feltöltő kapcsolatok

Az alagút létrejöhet, és mégsem szállít semmit. Amikor a helyi LAN és egy távoli hálózat közös előtagot használ, például 192.168.1.0/24-et, a kliens a távoli gazdagépet közvetlenül csatlakozónak tekinti, és a csomagot az alagút helyett a helyi kapcsolatra küldi. A tünet egy sikeres kapcsolat egy elérhetetlen alhálózattal, amit könnyű kiszolgálóoldali útvonalproblémaként félreolvasni.

A tartós megoldás a távoli LAN áthelyezése egy szokatlan privát tartományba. Egy olyan tartomány választása, amelyet otthon senki sem használ, például a 10.42.0.0/24, minden jövőbeli helyszínre megelőzi a problémát, nem csak egyre. A helyi kerülőút annak a hotelnek, hotspotnak vagy routernek az elkerülése, ami egyáltalán nem megoldás.

A mobil feltöltő kapcsolatok két változatot adnak hozzá. A szolgáltatói szintű NAT azt jelenti, hogy a bejövő kapcsolatok nem érkeznek meg, ami számít, ha kiszolgálót üzemeltet, de kimenő kliensnél nem. A NAT64-fordítással csak IPv6-ra beállított APN megbuktathat egy klienst, amely valódi IPv4-útvonalat követel, és a szokásos orvosság az APN protokolljának IPv4-re vagy kettős veremre váltása.

Tünetek az alagút felállása után

Az az alagút, amely csatlakozik, majd elhallgat, általában keepalive- vagy MTU-probléma, nem blokkolt port. Egy fix percszám után leeső kapcsolat keepalive- vagy újratárgyalási időzítőre utal. Állítsa be a klienst, hogy fürkészze a partnerét, és indítsa újra, amikor a válaszok megszűnnek, és próbáljon kisebb alagút-MTU-t, ha a pingek átmennek, de a nagy átvitelek megakadnak.

Mielőtt segítséget kér, írjon le három dolgot: a kipróbált címet és hogy válaszolt-e, a használt szállítást és portot, valamint a meghiúsult hálózat helyi alhálózatát. Együtt elválasztják a névfeloldást a forgalomszűréstől és a címütközéstől, és ezek azok az okok, amelyek kiállják a bizonyítékokkal való találkozást.