P_CONTROL_HARD_RESET_CLIENT_V2 în log: este o eroare?

Linia se repetă la fiecare câteva secunde și pare cauza tuturor: un pachet numit control hard reset, care vine de la un client ce nu ajunge nicăieri. Nu este o eroare. Este primul mesaj al unei sesiuni noi, iar repetarea este simptomul altceva care eșuează mai departe. Separarea a ceea ce spune eticheta de ceea ce a făcut conexiunea după aceea este întregul diagnostic.

Opcode-ul numește o poziție în protocol

OpenVPN multiplexează mai multe tipuri de pachete pe un singur socket, iar opcode-ul îi spune receptorului ce tip ține. Pachetele hard-reset deschid o sesiune, pachetele de control transportă material de handshake, confirmările confirmă recepția, iar pachetele de date transportă încărcătura tunelului. Citirea primului octet arată unde se încadrează pachetul în acel schimb, iar definițiile de pachet din codul sursă numesc fiecare familie în mod explicit.

Asta este tot ce spune. Un pachet marcat ca reset inițial al clientului dovedește că pachetul a ajuns la punctul dumneavoastră de observare și că partenerul vrea să înceapă o sesiune. Nu dovedește că clientul a avut încredere în certificatul dumneavoastră, că acreditările sale au fost acceptate sau că un canal de date a devenit vreodată utilizabil.

Sufixul V2 este un marcaj de generație de protocol pentru acea familie de pachete, nu o versiune de produs și nu o setare pe care o instalați. Nimic din nume nu se referă la resetarea unui tunel, repornirea unui serviciu sau golirea unui cache.

Ce face clientul de fapt în acel moment

Clientul deschide un identificator de sesiune la care ambele capete vor atașa traficul de control următor. Când protecția canalului de control este configurată, acel prim pachet poartă deja HMAC-ul care îi permite receptorului să decidă dacă merită să depună efort pentru restul schimbului. Un receptor care nu îl poate verifica aruncă pachetul în tăcere, motiv pentru care o cheie partajată greșită arată ca un client care vorbește în vid.

Nimic vizibil pentru utilizator nu s-a întâmplat încă. Niciun certificat nu a fost validat, niciun nume de utilizator nu a fost oferit și nicio adresă de tunel nu a fost atribuită. Resetul este preambulul handshake-ului, așa că orice judecată despre conexiune în acest punct este prematură.

Într-o buclă inactivă de reconectare, detaliul interesant este intervalul. Un client care reîncearcă într-un ciclu fix fără progres este de obicei respins înainte de a putea înainta, iar motivul este în logul partenerului, nu în numele pachetului.

Unde se ascunde defecțiunea reală după reset

Citiți cele două loguri alăturate și găsiți primul eveniment care nu este un reset. La client, o eroare de validare a certificatului este raportată cu motivul concret: un certificat expirat, o nepotrivire de nume sau un emitent necunoscut. La server, o respingere a acreditărilor este raportată ca eroare de autentificare cu propriul motiv. Ambele sunt mult mai concrete decât viziunea repetată a serverului asupra încercărilor noi.

Potriviți o încercare după marcajul de timp în loc să citiți fiecare log izolat, deoarece aceeași eroare apare în ambele locuri cu formulări și gravități diferite. Partenerul care renunță spune de obicei de ce.

Dacă niciuna dintre părți nu raportează o respingere și schimbul tot se blochează, limita este accesibilitatea, nu încrederea. Un firewall care aruncă direcția de retur, un dispozitiv de traducere a adreselor de rețea a cărui mapare expiră sau o problemă de MTU care ucide pachetele de handshake mai mari produc toate un schimb blocat fără nicio eroare de autentificare.

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

Acea căutare nu este un diagnostic în sine, dar vă mută de la vocabularul protocolului la o clasă reală de defecțiune într-un singur pas.

De ce dezactivarea verificării este reflexul greșit

Când resetul continuă să apară, remedierea care pare cea mai rapidă este să dezactivați validarea certificatelor sau să renunțați la protecția canalului de control ca să se conecteze ceva. Asta schimbă o defecțiune diagnosticabilă cu una nediagnosticabilă și lasă implementarea să accepte parteneri pe care a fost construită să îi respingă.

Schimbați în schimb limita care a eșuat cu adevărat. O problemă de încredere aparține autorității de certificare și profilului care o referențiază. O problemă de timp aparține ceasului. O problemă de acreditări aparține backend-ului de autentificare care le-a respins, iar un partener inaccesibil aparține căii dintre cele două gazde.

Opcode-ul este util într-o conversație de suport pentru un singur lucru: vă spune că partenerul a ajuns suficient de departe încât să încerce. Ce s-a întâmplat după aceea este ce trebuie să știți, și este scris în logul care înregistrează prima respingere concretă. Începeți de acolo, iar linia de reset încetează să mai pară o cauză și începe să pară un marcaj de timp.