Hvorfor en gyldig engangskode stadig fejler ved VPN-login

Du åbner VPN-klienten, skriver adgangskoden, og de seks cifre fra autentificeringsappen kommer tilbage som ugyldige — to gange, derefter en tredje. Der er intet ændret på kontoen siden i går, så instinktet er at slette posten i autentificeringsappen og scanne den igen — som regel den forkerte reparation. En engangskode er ikke en ekstra adgangskode: gatewayen skal bede om den i et bestemt trin, fra en bestemt tilmeldt post, inden for et bestemt tidsvindue, og de fleste afvisninger sker, før cifrene bliver sammenlignet. Find ud af, hvilket trin du er i, før du rører tilmeldingen.

Rækkefølgen af anmodninger viser, hvilket flow du er i

Tre former dækker næsten hvert VPN-login med en kode. I to-trins-formen sender klienten adgangskoden, serveren udsteder en udfordring, og klienten spørger igen. I den kombinerede form vil gatewayen have adgangskode og kode i én indsendelse — nogle gange sammenkædet, nogle gange efter en separator, som kun operatøren dokumenterer. I browserformen har klienten slet intet felt: koden går ind på en webside, eller en push-godkendelse erstatter den, og desktopklienten venter på resultatet.

At ramme den forkerte form ligner en dårlig kode. Indsæt en frisk kode i et felt, der kun er til adgangskoden, og serveren læser den som en del af adgangskoden. På klientsiden gør OpenVPN 2.4 og nyere forskellen synlig: en server, der svarer med AUTH_FAILED,CRV1:, forventer et udfordringssvar, så profilen skal have static-challenge eller en adgangskodefil i SCRV1:-form. En ældre profil, der kun har auth-user-pass, godkender adgangskoden og går så i stå, hvilket i loggen ligner en OTP-fejl, selv om der ikke blev sendt nogen kode.

WireGuard fortjener at blive nævnt som undtagelsen: den autentificerer nøglepar i stedet for personer, så der er intet felt til en kode. Hvis en udbyder annoncerer en, er der noget uden for tunnelen, som accepterer den.

Hvad serveren gør med de seks cifre

Tidsbaserede koder følger RFC 6238, som indpakker den ældre tællerbaserede konstruktion fra RFC 4226: en HMAC over en flyttende faktor, som standard afkortet til seks cifre. For TOTP er den flyttende faktor den aktuelle Unix-tid divideret med et trin, 30 sekunder medmindre operatøren har ændret det. Verifikatoren sammenligner aldrig dine cifre med en gemt værdi; den genberegner den forventede kode ud fra det delte seed og accepterer normalt også nabotrinene, så en langsom rundtur ikke får login til at fejle.

To konsekvenser bliver overset. Telefonens tidszone er irrelevant, fordi seedet aldrig ser et lokalt ur — kun afvigelsen fra den rigtige UTC betyder noget, og en håndsæt, der løber to minutter for hurtigt, fejler på hver kode, mens den viser en ren nedtælling. Og en kode er enkelbrug efter design: verifikatoren husker den sidste tællerværdi, den accepterede for det seed, så de samme cifre, der sendes igen, afvises selv inden for samme vindue. En klient, der prøver igen efter en timeout, kan brænde den kode, den netop har sendt.

Tællerbaserede tokens flytter deres tæller ved hvert tryk, så de falder ud af synkronisering, efter at koder er genereret men aldrig sendt; den sædvanlige reparation er et resynkroniseringsvindue, der accepterer nogle få værdier frem. Hvis operatøren tilmeldte HOTP, og din app viser TOTP, er hver værdi forkert på en måde, der ligner et urproblem. URI'en til klargøring bag QR-koden angiver typen, cifrene, perioden og hashen.

Fejl, der ligner en forkert kode

Den tilmeldte post er den mest almindelige årsag. Autentificeringsapps mærker poster med udsteder og konto, så enhver med to identiteter på samme VPN kan ende med to poster, hvis mærkater afviger med ét tegn. En kode er gyldig for det seed, der genererede den, og intet andet. Sammenlign mærkaten på telefonen med det brugernavn, serveren registrerer, ikke med det, du husker, at du skrev.

Det andet er et parametersæt, der ikke passer. Et seed tilmeldt med otte cifre, en periode på 60 sekunder eller SHA-256 giver koder, som en verifikator, der forventer seks cifre, 30 sekunder og SHA-1, afviser, og på klientsiden kan det ikke skelnes fra en forkert kode. Det dukker op efter migreringer, hvor posten blev tilføjet igen fra et foto af QR-koden, eller hvor tokenposten blev genopbygget med standardværdier.

Det tredje handler ikke om koden. Gateways returnerer normalt én generisk autentificeringsfejl for en forkert adgangskode, en udløbet kode og en deaktiveret konto, med vilje, så ingen kan undersøge, hvilken faktor der fejlede. Læs gateway- eller RADIUS-loggen i stedet for klientens banner: en udfordring, der aldrig blev udstedt, en adgangsafvisning uden OTP-attribut og en politikafvisning ser ens ud på skærmen og fører til forskellige næste skridt.

En kort sekvens, der indsnævrer det

Start med den billigste kontrol, og stop ved det første trin, der ikke holder.

1. Vent på en frisk kode, send den én gang, og notér, om udfordringen vises før eller efter adgangskoden accepteres.
2. Sammenlign mærkaten i autentificeringsappen med det brugernavn, serveren gemmer.
3. Bekræft, at profilen overhovedet kan svare på en udfordring, som i CRV1-tilfældet ovenfor.
4. Sammenlign enhedens ur med en kendt tidskilde; en afvigelse på mere end nogle få snese sekunder ødelægger TOTP i sig selv.
5. Spørg operatøren, om tokenet er TOTP eller HOTP, og hvilke cifre, periode og hash der blev tilmeldt.

To regler forhindrer, at det gør tingene værre. Prøv ikke igen mange gange: mange gateways tæller fejl pr. konto og låser den enten eller begynder at forsinke svar, så en byge forvandler en lille fejlkonfiguration til en supportbillet. Og tilmeld ikke tokenet igen som diagnosticering, for det ugyldiggør det gamle seed; hvis den egentlige fejl var en udfordring, som klienten aldrig sendte, har du nu to ændringer at forklare i stedet for én.

Hold seedet og gendannelseskoderne ude af spillet

De seks cifre og hemmeligheden bag dem kan ikke udskiftes. En QR-kode til klargøring eller et Base32-seed genererer hver fremtidig kode til kontoen, så det hører i samme kategori som adgangskoden: ikke i et skærmbillede, ikke i en sagsommentar, ikke i en chat med nogen, der henvendte sig først. Gendannelseskoder er en separat mekanisme — enkelbrug, springer ofte kodeanmodningen helt over, og bruger du én på at teste kontoen, fjerner du en fallback, du måske får brug for senere.

En kode gør heller ikke en loginside troværdig: en OTP-anmodning på et lignende domæne opsamler en gyldig kode og genafspiller den inden for vinduet, og certifikatet er stadig det, der fortæller dig, hvor du skriver.

Hvis sekvensen ender på en profil, der ikke kan svare på en udfordring, så ret profilen og test igen med én frisk kode. Hvis den ender på parameterindstillinger, der ikke passer, så lad operatøren læse tokenposten, før nogen scanner noget. Hvis den ender på en låsning, så vent den ud i stedet for at skifte klient — det er kontoens tilstand, der blokerer, ikke appen.