TLS-timeout på tres sekunder: hvilken ende stoppede faktisk?
Sammenhold ét klientforsøg med serverens egne hændelser, før du rører ved TLS-indstillingerne. Tavshed, tidlig kassering og en navngiven afvisning kræver forskellige rettelser.
Klienten giver op efter tres sekunder med en besked om nøgleforhandling, og laptop'en udtrykker ingen mening om hvorfor. Den sætning beskriver klientens tålmodighed, ikke serverens adfærd. Tre helt forskellige situationer frembringer den: pakken nåede aldrig den rigtige tjeneste, tjenesten kasserede den før den loggede noget, eller tjenesten afviste den og sagde det et sted, som klienten ikke kan se. Det er korrelationen af ét forsøg i begge ender, der adskiller dem.
Giv ét forsøg en identitet, du kan søge efter
Skriv starttidspunktet med tidszone ned, profilnavnet, den destination klienten faktisk slog op, porten, og om forbindelsen er UDP eller TCP. Hvis profilen indeholder flere fjernposter, noter hvilken det forsøg valgte, for et nyt forsøg kan være flyttet til næste post uden at ændre den fil, du læser.
Tag endepunktet fra den aktive log i stedet for fra den download, du husker. En profil, der peger på en privat adresse, er helt gyldig og helt ubrugelig fra et netværk, der ikke kan route til den, og det tilfælde ser identisk ud med en server, der er nede.
Bed derefter operatøren om samme vindue på den tilsigtede instans. Urforskydning er almindelig nok til, at en afvigelse på få minutter kan få en matchende hændelse til at se fraværende ud, så noter afvigelsen i stedet for at konkludere, at der ikke var nogen hændelse.
Fire observationer, fire forskellige næste skridt
Det, serveren registrerer, afgør grenen. Fravær af ethvert forsøg peger på adressering, transport eller vejen til tjenesten. Indkommende pakker, der forsvinder før en almindelig udveksling, peger på kontrolkanalens krav i den faktiske tjeneste. En navngiven afvisning peger på det objekt, den navngiver. Svar, der forlader serveren, men aldrig når klienten, peger på returvejen.
En tom applikationslog er svagere bevis, end den ser ud. Logning begynder på et bestemt punkt i udvekslingen, og pakker, der kasseres før det punkt, efterlader ingen spor i den fil, du læser. Hvor det er tilladt, kan operatøren bruge tjeneste- og netværksobservationer til at se, om noget overhovedet ankom.
Hold de fire udfald adskilt i dine noter. Fristelsen er at smelte dem sammen til »serveren svarer ikke«, og det er den sætning, der sender folk til at skifte ciphere, når det egentlige problem er en firewall-regel. En note, der kun registrerer ordet timeout, har smidt den skelnen væk, du netop har betalt for.
Ret den fase, beviserne navngiver
En TCP-forbindelse, der fuldføres, beviser kun, at noget accepterede en socket. Den beviser ikke, at lytteren er den OpenVPN-tjeneste, du konfigurerede, og en webserver på samme værtsnavn svarer en browser perfekt, mens den er irrelevant for tunnelen.
Hvis serveren rapporterer en udløbet tilbagekaldelsesliste, er det et langt mere specifikt faktum end klientens endelige timeout, og rettelsen hører hos certifikatmyndigheden, ikke netværket. Hvis de to ender er uenige om kontrolkanalbeskyttelse eller delt materiale, ændrer en nulstilling af adgangskoden intet, fordi kasseringen sker, før nogen legitimationsoplysning undersøges.
Ændr én ting, som beviserne faktisk understøtter, og gentag derefter samme profil mod samme endepunkt. Bevar den første nye hændelse, hvis forbindelsen kommer længere, for den hændelse er næste fase af undersøgelsen, ikke et nyt problem.
grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3
Hvad forlængelsen af vinduet faktisk ændrer
Tres sekunder er klientens håndtryksvindue, og fællesskabets klientreference dokumenterer den indstilling, der justerer det. At hæve det får klienten til at vente længere, før den giver op. Det får ikke en fraværende tjeneste til at dukke op, og det gør ikke en afvist pakke acceptabel.
Der er en legitim brug af et længere vindue på et langsomt link eller en hårdt belastet server, og det er værd at prøve, når du har bevis for, at udvekslingen skrider langsomt frem i stedet for slet ikke at ske. At prøve det først udsætter blot den samme diagnose med endnu et minut og gør tidslinjen sværere at læse. Hvis tidslinjen viser en udveksling, der skrider frem og så går i stå, er vinduet et symptom på belastning, ikke på tilgængelighed.