Ugyldige hemmeligheder er et containerproblem, ikke en adgangskoderegel
Et afvist login er måske aldrig nået frem til gatewayen. Sammenlign først inputcontaineren, godkendelsesstadiet og selve kontoen.
Når du ser »ugyldige hemmeligheder«, fører det normalt til én konklusion: VPN kan ikke lide tegnsætning. Den konklusion er som regel forkert, fordi meddelelsen ofte kommer fra lokal behandling, før nogen gateway har kigget på kontoen. To design leverer den samme adgangskode, et grafisk felt og en legitimationsfil, og de fejler forskellige steder. Sammenlign containerne, før du forenkler en adgangskode, der hele tiden var i orden.
Fejlen kommer før gatewayen
Lokal validering, et låst hemmelighedslager, en manglende agent og en forkert udformet legitimationsfil giver alle fejl, som brugeren oplever som én afvisning. Ingen af dem involverer godkendelsesserveren. Gatewayens egen afvisning er en særskilt hændelse, og den kommer normalt med en anden meddelelse og på et andet tidspunkt. Den sker, efter at der findes en tunnel, og efter at legitimationsoplysningerne er sendt.
Det første spørgsmål er altså ikke, hvilke tegn der er tilladte, men hvor forsøget stoppede. En klient, der aldrig har åbnet en forbindelse, er ikke blevet afvist af nogen. Skriv det stadie ned, du har observeret, fordi hvert senere skridt afhænger af den klassificering.
Sondringen ændrer også, hvem der retter det. Et containerproblem tilhører enheden og dens ejer, mens en kontoafvisning tilhører den, der driver godkendelsesbackenden.
Sammenlign containerne, ikke tegnene
Et grafisk adgangskodefelt, en nøgleringspost, en legitimationsfil med to linjer og en hemmelighed til automatisering bærer hver den samme værdi i en anden indpakning. Indpakningen har sine egne regler, og det er normalt dem, der brækker. Værdien er sjældent problemet; transporten af værdien er. Hold de to idéer adskilt, og diagnosen bliver kortere.
| Where the value stops | What you see | What you check | Who owns the fix |
|---|---|---|---|
| GUI field or managed profile | A validation message before any connection opens | The selected authentication mode and whether the field holds the secret or the username | The device owner or the profile author |
| Keychain or secret agent | A prompt that keeps reappearing, or an agent error | Whether the agent is unlocked and holds an entry for this profile | The user who owns the keychain |
| Two-line credential file | A prompt for a password that was already supplied | Line count, line order and whether a trailing newline is present | Whoever generated the file |
| Shell argument or environment | Works interactively but fails in automation | Whether the shell expanded, trimmed or logged the value | Whoever wrote the automation |
OpenVPN 2.6-fællesskabets klientindstillinger beskriver den tolinjede fil til auth-user-pass, inklusive adfærden, når adgangskodelinjen mangler: så spørger klienten selv. Den ene detalje forklarer en hel klasse af rapporter af typen »den spørger om en adgangskode, jeg allerede har angivet«. Den fortæller dig også, at en tom anden linje er en betydningsfuld tilstand og ikke et harmløst formateringsvalg.
Citering er igen et særskilt lag: anførselstegn inde i en almindelig legitimationsfil gemmes som data, mens en shell fjerner dem, før programmet ser noget. Det samme tegn er harmløst det ene sted og strukturelt det andet. En tabel kan ikke fortælle dig, hvilken container din klient brugte, så læs klientens egen konfiguration, før du vælger en række.
Linjeskift er også strukturelle. En fil med linjeadskilte felter kan ikke bære en værdi, der indeholder et linjeskift, og det er en begrænsning i formatet, ikke en dom over adgangskodens styrke. Brug den leveringsmekanisme, som udrulningen understøtter, i stedet for at klippe hemmeligheden til, så den passer i en improviseret fil.
Byg legitimationsfilen uden skader fra shellen
Den sikreste lokale vej holder hemmeligheden ude af shell-historikken og ude af processens argumentliste. Læs begge felter interaktivt, og skriv derefter de to linjer, klienten forventer. Alt andet kan blive i en konfigurationsfil, der er let at gennemgå.
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/credsDe første to kommandoer læser brugernavnet og derefter adgangskoden uden at ekkoe den, den tredje skriver begge linjer, den fjerde begrænser filen, og den sidste starter klienten med den fil. Bemærk, at read -r bevarer omvendte skråstreger, og det er netop den slags detalje, der gør en fungerende adgangskode til en fejlende, når den udelades.
Undgå at bygge filen med en variabel uden anførselstegn eller med et here-dokument fuld af shell-udvidelser. Begge kan omdanne tegn, før de når filen, og den resulterende fejl ligner en VPN-afvisning, fordi adgangskoden på disken faktisk er forskellig fra den, du kender. Hvis du har mistanke om det, sammenlign filens bytelængde med den forventede værdi uden at udskrive selve hemmeligheden. En forskel på en eller to bytes er signaturen på en citeringsulykke.
Læs stadiet ud fra den første fejl
Behold den første konkrete meddelelse fra ét forsøg, og klassificér den derefter. En lokal valideringsfejl, en manglende privat nøgle, en utilgængelig hemmelighedsagent og en godkendelsesfejl i gatewayen er fire forskellige resultater med fire forskellige ejere. Kun ét af dem handler om kontoen.
Hvis gatewayen virkelig afviser en korrekt leveret legitimationsoplysning, så kontrollér kontoen, godkendelsesbackenden og enhver påkrævet udfordring sammen med administratoren. En generisk godkendelsesfejl nævner ikke noget forbudt tegn.
Gendan den godkendte værdi gennem den korrekte mekanisme i stedet for at reducere den til bogstaver og cifre. Adgangskodepolitikken tilhører operatøren, og en omvej, der stille omgår den, er ikke en rettelse. Den skjuler også den egentlige defekt for den næste person, som vil møde den samme fejl med en svagere adgangskode og ingen bedre idé.