Waarom een VPN-herverbinding opnieuw om inloggegevens vraagt

Een tunnel die urenlang werkte, vraagt om een wachtwoord op het moment dat de laptop wakker wordt, en er is niets aan de configuratie veranderd. Wat wel is veranderd, is de staat van de inloggegevens die de herverbinding probeerde te hergebruiken. Drie soorten materiaal bepalen dat, en slechts één ervan overleeft een willekeurige onderbreking.

Lees welke de client vroeg, want de drie verlopen volgens verschillende klokken en falen met verschillende berichten.

Drie soorten herbruikbaar materiaal

Een gecacht wachtwoord is een geheim dat de client bewaart, en het blijft geldig totdat het account het wijzigt. Een sessietoken wordt door de server uitgegeven na een geslaagde aanmelding, draagt zijn eigen levensduur en kan op elk moment worden ingetrokken. Een TLS-sessieticket of een IKE-beveiligingsassociatie is protocolstatus, goedkoop te hervatten en volledig onafhankelijk van je wachtwoord. Elk wordt door een andere component uitgegeven, en elk verloopt op zijn eigen voorwaarden.

Het eerste overleeft een herstart, het tweede overleeft meestal een slaapstand, en het derde overleeft een netwerkwissel misschien helemaal niet. Ze verwarren levert de verkeerde oplossing op, zoals een wachtwoord resetten dat nooit is geweigerd.

De prompt zelf is de diagnose. Een browservenster of een tweedefactorcode betekent dat de server interactieve authenticatie eiste, terwijl een stille fout zonder prompt betekent dat de client nooit ver genoeg kwam om gevraagd te worden.

Sleutelvernieuwing is geen herauthenticatie

Een sleutelvernieuwing vervangt sleutels terwijl de geauthenticeerde identiteit behouden blijft, daarom gebeurt het op een gezonde tunnel af en toe stil. Herauthenticatie herhaalt de identiteitscontrole zelf, en dat is de gebeurtenis die jou nodig heeft. IKEv2 scheidt de twee expliciet, en een peer kan met een ingesteld interval een volledige herauthenticatie eisen, ongeacht hoeveel sleutelvernieuwingen er tussenin plaatsvonden. De twee gebeurtenissen lijken van buitenaf identiek tot je leest welke het logboek noemt.

OpenVPN gedraagt zich hetzelfde in zijn eigen vocabulaire: een heronderhandelingsinterval ververst het datakanaal, en een authenticatietoken kan aan de client worden teruggegeven om een volledige aanmelding bij de volgende verbinding te vermijden. Dat token heeft een levensduur, en de server beslist of het opnieuw wordt geaccepteerd.

Zo kan een herverbinding na acht uur mislukken waar een herverbinding na acht minuten slaagde, zonder enige configuratiewijziging aan beide kanten. Dat is de hele verklaring voor een prompt die pas na de lunch verschijnt.

Wanneer de client de nieuwe uitdaging niet kan voltooien

Een beleid dat een browserstap vereist, zal mislukken op een client die geen manier heeft om er een te tonen. Servers zonder scherm, opstartscripts en oude profielen die voor authenticatie met alleen een wachtwoord zijn gebouwd, lopen allemaal tegen die muur, en de fout verschijnt vaak als een algemene time-out in plaats van een authenticatiefout.

Apparaat- en netwerkwisselingen kunnen ook binnen een evaluatievenster van het beleid vallen, waardoor een roaming van Wi-Fi naar een hotspot samenvalt met een controle die toch al zou plaatsvinden. De samenloop laat het netwerk schuldig lijken terwijl de timer de oorzaak is.

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

De eerste regel toont heronderhandelings- en authenticatiegebeurtenissen in het eigen logboek van de client, en de tweede toont de beveiligingsassociaties die een strongSwan-peer op dit moment heeft. Vergelijk de tijdstempels met het moment waarop de prompt verscheen; een overeenkomst bevestigt de timer en niet het netwerk.

Wat te melden, en wat niet uit te schakelen

Als een handmatige aanmelding slaagt en automatisch hergebruik consistent mislukt, zeg dat dan precies tegen de beheerder. Het benoemt de component: het hergebruikpad, niet de inloggegevens. Vermeld het tijdstip van de fout, het gebruikte account en het type prompt dat je zag.

Schakel de tweede factor niet uit, sla certificaatvalidatie niet over en plak geen inloggegevens in een script om de herverbinding stil te maken. Elk daarvan verwijdert de controle die het beleid hoort af te dwingen, en elk maakt van een aanmeldprompt een incident.

Vraag in plaats daarvan de ondersteunde stroom: een client die de uitdaging kan voltooien, een tokenlevensduur die bij de werkdag past, of een goedgekeurd niet-interactief profiel voor de machine die niet kan vragen. Dat zijn allemaal configuratiebeslissingen die iemand kan goedkeuren, wat een omweg niet is.