P_CONTROL_HARD_RESET_CLIENT_V2 a naplóban: hiba ez?

A sor néhány másodpercenként megismétlődik, és minden okának látszik: egy control hard reset nevű csomag, amely olyan klienstől érkezik, amely soha nem jut el sehova. Ez nem hiba. Ez egy új munkamenet első üzenete, az ismétlődés pedig annak a tünete, hogy valami más hibázik később. Az a teljes diagnózis, ha szétválasztjuk, mit mond a címke, és mit tett utána a kapcsolat.

Az opkód helyet jelöl a protokollban

OpenVPN több csomagtípust multiplexál egyetlen socketen, és az opkód megmondja a fogadónak, melyik fajtát tartja. A hard-reset csomagok munkamenetet nyitnak, a vezérlőcsomagok kézfogási anyagot hordoznak, a nyugták visszaigazolják az átvételt, az adatcsomagok pedig az alagút hasznos terhét hordozzák. Az első bájt elolvasása megmutatja, hová tartozik a csomag ebben a cserében, és a forráskód csomagdefiníciói minden családot kifejezetten megneveznek.

Ennyit mond. Az ügyfél kezdeti alaphelyzeteként megjelölt csomag bizonyítja, hogy a csomag elérte a megfigyelési pontját, és hogy a partner munkamenetet akar kezdeni. Nem bizonyítja, hogy a kliens megbízott a tanúsítványában, hogy elfogadták a hitelesítő adatait, vagy hogy az adatcsatorna valaha használhatóvá vált.

A V2 utótag e csomagcsalád protokollgenerációs jelölése, nem termékverzió és nem olyan beállítás, amelyet telepítenie kellene. A névben semmi sem utal alagút visszaállítására, szolgáltatás újraindítására vagy gyorsítótár törlésére.

Mit tesz valójában a kliens abban a pillanatban

A kliens megnyit egy munkamenet-azonosítót, amelyhez mindkét fél hozzácsatolja a következő vezérlőforgalmat. Ha a vezérlőcsatorna védelme be van állítva, az az első csomag már hordozza azt a HMAC-ot, amely lehetővé teszi a fogadó számára annak eldöntését, hogy érdemes-e erőfeszítést fordítani a csere többi részére. Az a fogadó, amely nem tudja ellenőrizni, csendben eldobja a csomagot, ezért látszik a rossz közös kulcs olyannak, mintha a kliens az ürességbe beszélne.

A felhasználó számára látható semmi sem történt még. Egyetlen tanúsítvány sem lett érvényesítve, egyetlen felhasználónév sem lett felajánlva és egyetlen alagútcím sem lett kiosztva. Az alaphelyzet a kézfogás előjátéka, ezért bármilyen ítélet a kapcsolatról ebben a pontban korai.

Egy tétlen újracsatlakozási hurokban az érdekes részlet az intervallum. Az a kliens, amely fix ciklusban próbálkozik újra előrelépés nélkül, általában még azelőtt elutasításra kerül, hogy továbbléphetne, és az ok a partner naplójában van, nem a csomag nevében.

Hol rejtőzik az igazi hiba az alaphelyzet után

Olvassa a két naplót egymás mellett, és keresse az első eseményt, amely nem alaphelyzet. A kliensen a tanúsítvány-ellenőrzési hiba a konkrét okkal jelenik meg: lejárt tanúsítvány, névegyezés hiánya vagy ismeretlen kibocsátó. A kiszolgálón a hitelesítő adatok elutasítása saját okkal jelenik meg hitelesítési hibaként. Mindkettő sokkal konkrétabb, mint a kiszolgáló ismétlődő képe az új próbálkozásokról.

Párosítson egy próbálkozást időbélyeg alapján ahelyett, hogy minden naplót külön olvasna, mert ugyanaz a hiba mindkét helyen más megfogalmazással és más súlyossággal jelenik meg. A feladó partner általában megmondja, miért.

Ha egyik fél sem jelent elutasítást, és a csere mégis elakad, a határ az elérhetőség, nem a bizalom. A visszirányt eldobó tűzfal, a hálózaticím-fordító eszköz, amelynek lejár a leképezése, vagy egy MTU-probléma, amely megöli a nagyobb kézfogási csomagokat, mind elakadt cserét eredményez, minden hitelesítési hiba nélkül.

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

Az a keresés önmagában nem diagnózis, de egy lépésben átviszi a protokoll szókincsétől egy valódi hibacsztályig.

Miért hatástalan reflex az ellenőrzés kikapcsolása

Amikor az alaphelyzet folyamatosan megjelenik, a leggyorsabbnak látszó javítás a tanúsítvány-ellenőrzés kikapcsolása vagy a vezérlőcsatorna védelmének feladása, hogy valami csatlakozzon. Ez diagnosztizálható hibát cserél diagnosztizálhatatlanra, és a telepítést olyan partnerek elfogadásánál hagyja, amelyeket éppen elutasítani építettek.

Változtassa meg inkább azt a határt, amely valóban meghiúsult. A bizalmi probléma a tanúsítványhatóságé és az őt hivatkozó profilé. Az időprobléma az óráé. A hitelesítőadat-probléma azé a hitelesítési háttérrendszeré, amely elutasította, az elérhetetlen partner pedig a két gazdagép közötti útvonalé.

Az opkód egy dologra hasznos egy támogatási beszélgetésben: megmondja, hogy a partner elég messzire jutott ahhoz, hogy megpróbálja. Az, ami utána történt, az, amit tudnia kell, és abban a naplóban van leírva, amely az első konkrét elutasítást rögzíti. Kezdje ott, és az alaphelyzet sora többé nem oknak látszik, hanem időbélyegnek.