VPN-kapcsolat időtúllépése: DNS, átvitel, egyeztetés vagy bejelentkezés

„A kapcsolat túllépte az időt” a legkevésbé konkrét hiba, amit egy VPN-kliens kiírhat. Azt jelenti, hogy egy művelet elmulasztotta a határidejét, és minden szakasznak a névfeloldástól a bejelentkezési válaszig van határideje. Azok a kliensek, amelyek csak a végső üzenetet mutatják, azonossá teszik a szakaszokat, ezért az emberek növelik az időkorlátot, portot váltanak és újratelepítik a profilt, ebben a sorrendben, anélkül hogy bármit tanulnának. A szakaszok összehasonlítása gyorsabb: mindegyik más helyen bukik el, és minden hiba másfajta bizonyítékot hagy maga után.

Négy szakasz, négy különböző hiba

A sorrend akkor is rögzített, ha a kliens elrejti: a nevet fel kell oldani, a kapott címhez átvitelt kell létesíteni, a protokollnak egyeztetnie kell a paramétereit és a kulcsait, és a fiókot hitelesíteni kell. Az OpenVPN kapcsolódási hibaelhárítási útmutatója ugyanezt a sorrendet követi a saját kliensénél, a többiek pedig szorosan követik. A második szakaszban bekövetkező időtúllépésnek és a negyedikben bekövetkezőnek semmi közös nincs, csak a képernyőn álló szó.

A naplóban az utolsó előrehaladást jelző sort keresse, ne a hiba előtti utolsó sort. A legtöbb kliens kiír valami olyat, mint feloldott cím, létrejött socket, elkezdett kézfogás vagy hitelesítési kérés, és az ezt követő szakasz az, amelyik túllépte az időt.

A névfeloldás még minden kapcsolat előtt elbukik

Ha a végpont soha nem oldódik fel, a kliensnek nincs mihez kapcsolódnia, és semmilyen átviteli munka nem történt. Ez a hiba általában azonnali, nem teljes időtúllépés, és ez a legolcsóbb módja annak megkülönböztetésére a többitől. Tesztelje a nevet a rendszer feloldójával és egy második feloldóval, és hasonlítsa össze a két választ, mielőtt arra jut, hogy a kiszolgáló áll.

A fórumbejegyzésből másolt régi cím gyakori oka a kiszolgálóproblémának látszó időtúllépésnek, mert a cím most valami máshoz vagy semmihez tartozik. Használja az üzemeltető jelenlegi profilját, ahelyett hogy egy korábban működő címet helyettesítene. A hiányzó ping-válasz semmilyen irányban nem bizonyíték: sok végpont eldobja az ICMP-t, miközben teljesen jól szolgál.

Az átvitel beállítása olyan csomagra vár, amely nem érkezik meg

Ha a DNS rendben van, és a kliens mégis elégeti a teljes időkorlátot, az átviteli réteg a gyanúsított. TCP-n közvetlenül tesztelheti a portot; Test-NetConnection Windowson vagy nc -vz Linuxon megmondja, fogad-e valami kapcsolatot, és ez hasznosabb a pingnél. UDP-n nem tesztelhet ugyanígy, mert azon a rétegen nincs befejezendő kézfogás, és ez az aszimmetria sok téves következtetést okoz.

Amit egy TCP-teszt bizonyít, az korlátozott: a 443-as portot fogadó szolgáltatás nem feltétlenül a VPN figyelője, és a csak UDP-s végpontnak nincs TCP-portja, amely bármit fogadhatna. Egy profil UDP-ről TCP-re írása nem hoz létre figyelőt a másik oldalon; csak azt változtatja meg, mire vár a kliens. Ha a hálózat szűri a protokollt, a változtatás más időtúllépést eredményez ugyanabban a szakaszban.

A captive portálok saját ellenőrzést érdemelnek ebben a szakaszban. Amíg a portál nem engedélyezi az eszközt, a kimenő forgalom a portálhoz megy, és az alagút-kísérlet egyszerűen lóg. Először fejezze be a portált egy böngészőben, aztán próbálja újra, és ne változtassa a profilt, amíg a portál függőben van.

Az egyeztetés és a bejelentkezés azt jelenti, hogy a kiszolgáló válaszolt

Amint az alagút eléri a kiszolgálót, a kliens kézfogást indít, és a hiba jellege megváltozik. Az itteni megakadás a kompatibilitásról szól, nem az elérhetőségről: nem passzoló protokollverziók, a másik fél által nem elfogadott titkosítási vagy adatcsatorna-beállítás, vagy olyan profil, amely a kiszolgáló által nem kínált funkciót vár. OpenVPN annyiszor mozdította el az egyeztetési alapértékeit a fő verziók között, hogy egy generációra írt profil elérheti a kiszolgálót, és mégis elakadhat az indulásnál.

A hitelesítés az utolsó szakasz, és a legkönnyebb félreolvasni. Az egyértelmű elutasítás válasz, ami azt jelenti, hogy az útvonal működik, és a probléma az identitás, a tanúsítvány vagy a fiók állapota. A böngészőalapú egyszeri bejelentkezési folyamat a harmadik eset: a kliens olyan műveletre vár, amelyet nem tett meg, vagy olyan böngészőre, amelyet nem tud elindítani, és semmi nem érkezik meg, amíg be nem fejezi azt a lépést.

Hasonlítsa össze a bizonyítékokat, mielőtt módosítja az újrapróbálkozást

Tartsa rögzítve az eszközt és a profilt, és egyszerre egy dolgot változtasson, a hálózattal kezdve. Ha ugyanaz a profil telefonos hotspoton csatlakozik, és a hotel Wi-Fi-jén időtúllépést ad, a változó az útvonal, nem a kiszolgáló. Ha mindenhol elbukik, a változó a profil vagy a végpont. Ha csak a nap egy adott szakában bukik el, rögzítse az időbélyeget, és hasonlítsa össze a kiszolgálóoldali eseményekkel, mielőtt bármit feltételezne a terhelésről.

Egy Ön által üzemeltetett szolgáltatásnál a döntő összehasonlítás az, hogy a kísérlet egyáltalán megérkezik-e. Az a kapcsolat, amely eléri a figyelőt, majd megakad, az egyeztetési szakaszhoz tartozik; amelyik soha nem jelenik meg a figyelő látókörében, az átviteli vagy feloldási probléma, és semmilyen újrapróbálkozás-hangolás nem mozdítja el. A kiszolgálónaplók elválasztják az elutasított bejelentkezést a csendes eldobástól, ami az identitásjavítás és a tűzfaljavítás közötti különbség.

Jegyezze fel a kliens verzióját, a profil nevét, a kísérlet idejét az időzónájával és az első hasznos hibát a végső bontott sor helyett. Távolítsa el a kulcsokat és a hitelesítő adatokat hordozó anyagot, mielőtt megosztja a részletet. Ezután végezzen egy értelmes javítást, és próbálja újra, mert a hosszabb határidő csak a dokumentált lassú műveletnek segít, és semmit nem tesz a rossz címért vagy a blokkolt portért.