Fel klocka på enheten kan stoppa VPN: kontrollera tiden först

VPN slutar ansluta, loggen nämner ett certifikat, och den första impulsen är att byta profil. En enhetsklocka som är minuter eller timmar fel ger exakt det felet, eftersom certifikatets giltighet bedöms mot det lokala ögonblicket. Tidszonens etikett på skärmen är inte problemet; den underliggande tiden är det. Kontrollera klockan innan du rör något certifikatmaterial.

Felet ser ut som ett certifikatproblem, inte ett klockproblem

En TLS-handskakning misslyckas när motpartens certifikat hamnar utanför sitt giltighetsfönster i förhållande till verifierarens klocka. Den kontrollen körs på klienten, så en felaktig klientklocka avvisar ett helt bra certifikat. Feltexten namnger certifikatet, och därför byter folk ut det och ser samma fel igen. Klockan är den billigare hypotesen och bör testas först.

En klocka som ligger före realtiden avvisar ett aktuellt certifikat som utgånget; en klocka som ligger efter avvisar ett nyare som ännu inte giltigt. Båda meddelandena pekar på datum, och båda uppstår utan någon kontakt med certifikatmyndigheten. Det är tecknet: ett verkligt utgångsdatum drabbar varje klient, medan ett klockproblem bara drabbar den enda maskinen med fel tid.

Läs ögonblicket, sedan certifikatet

Skriv ut klockan i UTC och certifikatets egna datum innan du ändrar något. Att jämföra två absoluta ögonblick tar bort tidszonsfrågan helt från undersökningen. Om certifikatets fönster innehåller det aktuella ögonblicket är certifikatet inte ditt fel.

date -u
timedatectl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Om den lokala klockan är fel, kontrollera om den är synkroniserad och med vad. En maskin med synkronisering avstängd, eller med en tidskälla den inte når, driver tills något går sönder. Statusutdata namnger källan och den senaste lyckade justeringen, vilket är mer användbart än den aktuella avvikelsen ensam. En stor avvikelse utan konfigurerad källa är ett annat problem än en liten avvikelse mot en fungerande källa.

timedatectl timesync-status
chronyc tracking

Stoppa om certifikatet verkligen har gått ut för varje klient. Då är klockan okej och certifikatet behöver förnyelse, inte justering.

Inloggningskoder misslyckas av en besläktad men annan anledning

Tidsbaserade engångslösenord hämtar sitt värde från det aktuella tidssteget, vanligtvis trettio sekunder. En enhet vars klocka är mer än ett eller två steg fel producerar koder som servern inte accepterar, även om användaren skrev rätt siffror. Felet ser ut som ett fel lösenord, vilket skickar folk in i en återställningsslinga som inte kan rätta en klocka.

Ta reda på vilken komponent som avvisade försöket, eftersom VPN-klienten, gatewayen och identitetsleverantören rapporterar olika steg. Om koden avvisas men lösenordet godtas är kontot förmodligen okej och klockan är den misstänkta. Om båda avvisas kan kontot vara låst och klockan är ett villospår. Följ leverantörens återställningsanvisningar i stället för att godkänna förfrågningar du inte startade.

Ställ inte tillbaka klockan för att få en kod att fungera. Det döljer orsaken och bryter nästa tidsbaserade kontroll.

Reparera källan, inte den visade timmen

Synkronisering är en nätverkstjänst, och tunneln kan ändra om tidskällan är nåbar. En företagskälla kan kräva tunneln, medan en offentlig källa kan blockeras av policy. Surfande kan fungera medan tidsjänstens egen väg misslyckas, och därför är detta beroende lätt att missa. NTP är protokollet bakom justeringen, och det behöver sin egen väg som alla andra tjänster.

sudo systemctl status systemd-timesyncd
sudo chronyc sources -v
ping -c1 203.0.113.20

Det finns också ett problem med startordningen: en mycket fel klocka kan hindra en autentiserad tunnel, och den enda användbara tidskällan kan ligga bakom den tunneln. En hanterad flotta behöver en dokumenterad rutin för det tillståndet, och att kringgå certifikatverifiering är inte en sådan. På en personlig enhet, använd operativsystemets egna tidskontroller och ta reda på varför klockan går förlorad efter avstängning eller återställning. En maskin som driver vid varje start har ett maskinvaru- eller konfigurationsproblem, inte ett VPN-problem.

Efter reparationen, försök igen med den ursprungliga anslutningen och läs det nya felet separat. En dålig serveridentitet, ett certifikat som verkligen gick ut och ett avvisat konto är tre olika fel, och att blanda dem är hur en enkel klockkorrigering blir en vecka av profilbyten.