Forkert ur på enheden kan stoppe VPN: tjek tiden først

VPN holder op med at forbinde, loggen nævner et certifikat, og den første indskydelse er at udskifte profilen. Et ur på enheden, der er minutter eller timer forkert, giver præcis den fejl, fordi certifikatets gyldighed vurderes mod det lokale øjeblik. Tidszonens etiket på skærmen er ikke problemet; den underliggende tid er. Tjek uret, før du rører ved noget certifikatmateriale.

Fejlen ligner et certifikatproblem, ikke et urproblem

Et TLS-håndtryk mislykkes, når modpartens certifikat falder uden for sit gyldighedsvindue i forhold til verifikatorens ur. Den kontrol kører på klienten, så et forkert klientur afviser et helt fint certifikat. Fejlteksten nævner certifikatet, og derfor udskifter folk det og ser den samme fejl igen. Uret er den billigere hypotese og bør testes først.

Et ur foran den virkelige tid afviser et gyldigt certifikat som udløbet; et ur bagud afviser et nyere som endnu ikke gyldigt. Begge meddelelser peger på datoer, og begge opstår uden nogen kontakt med certifikatmyndigheden. Det er tegnet: en ægte udløb rammer alle klienter, mens et urproblem kun rammer den ene maskine med den forkerte tid.

Læs øjeblikket, og derefter certifikatet

Print uret i UTC og certifikatets egne datoer, før du ændrer noget. At sammenligne to absolutte øjeblikke fjerner tidszone-spørgsmålet helt fra undersøgelsen. Hvis certifikatets vindue indeholder det aktuelle øjeblik, er certifikatet ikke din fejl.

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

Hvis det lokale ur er forkert, så tjek, om det er synkroniseret, og med hvad. En maskine med synkronisering slået fra, eller med en tidskilde den ikke kan nå, driver, indtil noget fejler. Statusoutputtet nævner kilden og den seneste vellykkede justering, hvilket er mere nyttigt end den aktuelle afvigelse alene. En stor afvigelse uden konfigureret kilde er et andet problem end en lille afvigelse mod en fungerende kilde.

timedatectl timesync-status
chronyc tracking

Stop, hvis certifikatet reelt er udløbet for alle klienter. Så er uret fint, og certifikatet skal fornyes, ikke justeres.

Login-koder fejler af en beslægtet men anderledes grund

Tidsbaserede engangskoder udleder deres værdi fra det aktuelle tidstrin, normalt tredive sekunder. En enhed, hvis ur er mere end et trin eller to forkert, producerer koder, som serveren ikke accepterer, selv om brugeren har skrevet de rigtige cifre. Fejlen ligner en forkert adgangskode, hvilket sender folk i en nulstillingsløkke, der ikke kan rette et ur.

Find ud af, hvilken komponent der afviste forsøget, fordi VPN-klienten, gatewayen og identitetsudbyderen rapporterer forskellige trin. Hvis koden afvises, men adgangskoden accepteres, er kontoen sandsynligvis fin, og uret er den mistænkte. Hvis begge afvises, kan kontoen være låst, og uret er et blindspor. Følg udbyderens vejledning til gendannelse i stedet for at godkende anmodninger, du ikke selv startede.

Stil ikke uret tilbage for at få en kode til at virke. Det skjuler årsagen og ødelægger den næste tidsbaserede kontrol.

Ret kilden, ikke den viste time

Synkronisering er en netværkstjeneste, og tunnelen kan ændre, om tidskilden kan nås. En virksomhedskilde kan kræve tunnelen, mens en offentlig kilde kan blokeres af politik. Browsing kan virke, mens tidsjenestens egen rute fejler, og derfor er denne afhængighed let at overse. NTP er protokollen bag justeringen, og den har brug for sin egen rute som enhver anden tjeneste.

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

Der er også et opstartsrækkefølgeproblem: et meget forkert ur kan forhindre en autentificeret tunnel, og den eneste brugbare tidskilde kan ligge bag den tunnel. En administreret flåde har brug for en dokumenteret procedure for den tilstand, og at omgå certifikatverifikation er ikke en. På en personlig enhed skal du bruge operativsystemets egne tidskontroller og finde ud af, hvorfor uret går tabt efter nedlukning eller gendannelse. En maskine, der driver ved hver opstart, har et hardware- eller konfigurationsproblem, ikke et VPN-problem.

Efter reparationen skal du prøve den oprindelige forbindelse igen og læse den nye fejl separat. En dårlig serveridentitet, et certifikat der virkelig er udløbet og en afvist konto er tre forskellige fejl, og at blande dem er, hvordan en simpel urrettelse bliver til en uge med profiludskiftninger.