Timeout TLS de șaizeci de secunde: care capăt s-a oprit de fapt?

Clientul renunță după șaizeci de secunde cu un mesaj despre negocierea cheilor, iar laptopul nu își exprimă nicio părere despre motiv. Acea frază descrie răbdarea clientului, nu comportamentul serverului. Trei situații complet diferite o produc: pachetul nu a ajuns niciodată la serviciul potrivit, serviciul l-a aruncat înainte de a înregistra ceva, sau serviciul l-a respins și a spus asta undeva unde clientul nu poate vedea. Corelarea unei singure încercări la ambele capete este ceea ce le separă.

Dați unei încercări o identitate pe care o puteți căuta

Notați ora de început împreună cu fusul orar, numele profilului, destinația pe care clientul a rezolvat-o efectiv, portul și dacă conexiunea este UDP sau TCP. Dacă profilul conține mai multe intrări la distanță, notați pe care a ales-o acea încercare, deoarece o reîncercare poate fi trecut la următoarea intrare fără a modifica fișierul pe care îl citiți.

Luați punctul final din jurnalul activ, nu din descărcarea pe care v-o amintiți. Un profil care indică o adresă privată este perfect valid și complet inutilizabil dintr-o rețea care nu poate ruta spre ea, iar acel caz arată identic cu un server oprit.

Apoi cereți operatorului aceeași fereastră pe instanța dorită. Decalajul de ceas este destul de frecvent încât câteva minute de diferență pot face un eveniment potrivit să pară absent, așa că notați decalajul în loc să concluzionați că nu a existat niciun eveniment.

Patru observații, patru pași următori diferiți

Ce înregistrează serverul decide ramura. Absența oricărei încercări indică adresarea, transportul sau calea către serviciu. Pachetele primite care dispar înainte de un schimb obișnuit indică cerințele canalului de control al serviciului real. Un refuz numit indică obiectul pe care îl numește. Răspunsurile care părăsesc serverul dar nu ajung niciodată la client indică calea de întoarcere.

Un jurnal de aplicație gol este o dovadă mai slabă decât pare. Înregistrarea începe într-un anumit punct al schimbului, iar pachetele aruncate înainte de acel punct nu lasă nicio urmă în fișierul pe care îl citiți. Acolo unde este permis, operatorul poate folosi observații ale serviciului și rețelei pentru a vedea dacă a ajuns ceva.

Țineți cele patru rezultate separate în notele dumneavoastră. Tentația este să le contopiți în „serverul nu răspunde”, iar aceasta este fraza care trimite oamenii să schimbe cifrurile când problema reală este o regulă de firewall. O notă care înregistrează doar cuvântul timeout a aruncat distincția pentru care tocmai ați plătit.

Corectați etapa pe care o numește dovada

O conexiune TCP finalizată dovedește doar că ceva a acceptat un socket. Nu dovedește că ascultătorul este serviciul OpenVPN pe care l-ați configurat, iar un server web pe același nume de gazdă răspunde perfect unui browser în timp ce este irelevant pentru tunel.

Dacă serverul raportează o listă de revocare expirată, acesta este un fapt mult mai specific decât timeout-ul final al clientului, iar corecția aparține autorității de certificare și nu rețelei. Dacă cele două capete nu sunt de acord asupra protecției canalului de control sau asupra materialului partajat, resetarea unei parole nu schimbă nimic, deoarece aruncarea are loc înainte de a fi examinată orice acreditare.

Schimbați un singur lucru pe care dovada îl susține cu adevărat, apoi repetați același profil împotriva aceluiași punct final. Păstrați primul eveniment nou dacă conexiunea merge mai departe, deoarece acel eveniment este următoarea etapă a investigației, nu o problemă nouă.

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

Ce schimbă de fapt prelungirea ferestrei

Șaizeci de secunde este fereastra de strângere de mână a clientului, iar referința clientului comunității documentează opțiunea care o ajustează. Creșterea ei face clientul să aștepte mai mult înainte de a renunța. Nu face un serviciu absent să apară și nu face un pachet respins acceptabil.

Există o utilizare legitimă a unei ferestre mai lungi pe o legătură lentă sau pe un server foarte încărcat, și merită încercată atunci când aveți dovezi că schimbul avansează lent și nu că nu are loc. Încercarea ei mai întâi doar amână același diagnostic cu încă un minut și face cronologia mai greu de citit. Dacă cronologia arată un schimb care avansează și apoi se blochează, fereastra este un simptom al încărcării și nu al accesibilității.