TLS-timeout på sextio sekunder: vilken sida slutade egentligen?

Klienten ger upp efter sextio sekunder med ett meddelande om nyckelförhandling, och laptopen har ingen åsikt om varför. Den meningen beskriver klientens tålamod, inte serverns beteende. Tre helt olika situationer skapar den: paketet nådde aldrig rätt tjänst, tjänsten kastade det innan den loggade något, eller tjänsten avvisade det och sa det någonstans där klienten inte kan se. Det är korrelationen av ett försök i båda ändar som skiljer dem.

Ge ett försök en identitet som du kan söka efter

Skriv ner starttiden med tidszonen, profilnamnet, destinationen som klienten faktiskt löste, porten och om anslutningen är UDP eller TCP. Om profilen innehåller flera fjärrposter, notera vilken det försöket valde, eftersom ett nytt försök kan ha flyttat till nästa post utan att ändra filen du läser.

Ta slutpunkten från den aktiva loggen, inte från nedladdningen du minns. En profil som pekar på en privat adress är helt giltig och helt oanvändbar från ett nätverk som inte kan routa dit, och det fallet ser identiskt ut med en server som ligger nere.

Be sedan operatören om samma fönster på den avsedda instansen. Klockavvikelse är vanligt nog att en skillnad på några minuter kan få en matchande händelse att verka saknas, så anteckna avvikelsen i stället för att dra slutsatsen att ingen händelse fanns.

Fyra observationer, fyra olika nästa steg

Vad servern registrerar avgör grenen. Frånvaro av varje försök pekar på adressering, transport eller vägen till tjänsten. Inkommande paket som försvinner före ett vanligt utbyte pekar på kraven från den faktiska tjänstens kontrollkanal. En namngiven avvisning pekar på objektet den namnger. Svar som lämnar servern men aldrig når klienten pekar på returvägen.

En tom applikationslogg är svagare bevis än den ser ut. Loggningen börjar vid en viss punkt i utbytet, och paket som kastas före den punkten lämnar inga spår i filen du läser. Där det är tillåtet kan operatören använda tjänste- och nätverksobservationer för att se om något över huvud taget kom fram.

Håll de fyra utfallen åtskilda i dina anteckningar. Frestelsen är att smälta samman dem till ”servern svarar inte”, och det är just den meningen som skickar folk att byta chiffer när det verkliga problemet är en brandväggsregel. En anteckning som bara registrerar ordet timeout har kastat bort den distinktion du just betalade för.

Rätta till fasen som bevisen namnger

En slutförd TCP-anslutning bevisar bara att något accepterade en socket. Den bevisar inte att lyssnaren är den OpenVPN-tjänst du konfigurerade, och en webbserver på samma värdnamn svarar en webbläsare perfekt medan den är irrelevant för tunneln.

Om servern rapporterar en utgången återkallningslista är det ett långt mer specifikt faktum än klientens slutliga timeout, och rättelsen hör till certifikatmyndigheten och inte till nätet. Om de två ändarna inte är överens om skyddet av kontrollkanalen eller delat material ändrar en återställning av lösenordet ingenting, eftersom kastandet sker innan någon autentiseringsuppgift granskas.

Ändra en sak som bevisen faktiskt stöder, upprepa sedan samma profil mot samma slutpunkt. Behåll den första nya händelsen om anslutningen kommer längre, eftersom den händelsen är nästa fas av undersökningen, inte ett nytt problem.

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

Vad förlängningen av fönstret egentligen ändrar

Sextio sekunder är klientens handskakningsfönster, och gemenskapens klientreferens dokumenterar alternativet som justerar det. Att höja det får klienten att vänta längre innan den ger upp. Det får inte en frånvarande tjänst att dyka upp, och det gör inte ett avvisat paket acceptabelt.

Ett längre fönster har legitim användning på en långsam länk eller en hårt belastad server, och det är värt att prova när du har bevis för att utbytet går långsamt framåt i stället för att inte ske alls. Att prova det först skjuter bara upp samma diagnos med ännu en minut och gör tidslinjen svårare att läsa. Om tidslinjen visar ett utbyte som går framåt och sedan stannar är fönstret ett symptom på belastning och inte på nåbarhet.