Ugyldige hemmeligheter er et containerproblem, ikke en passordregel
En avvist legitimasjon har kanskje aldri nådd gatewayen. Sammenlign inndatacontaineren, autentiseringstrinnet og selve kontoen først.
Å se "invalid secrets" gir vanligvis én konklusjon: VPN-en liker ikke tegnsetting. Den konklusjonen er vanligvis feil, fordi meldingen ofte kommer fra lokal behandling før noen gateway har sett på kontoen. To design leverer det samme passordet, et grafisk felt og en legitimasjonsfil, og de feiler på forskjellige steder. Sammenlign containerne før du forenkler et passord som var greit hele tiden.
Feilen kommer før gatewayen
Lokal validering, et låst hemmelighetslager, en manglende agent og en feilformatert legitimasjonsfil gir alle feil som brukeren opplever som én avvisning. Ingen av dem involverer autentiseringsserveren. Gatewayens egen avvisning er en egen hendelse, og den kommer vanligvis med en annen melding og et annet tidspunkt. Den skjer etter at en tunnel finnes og legitimasjonen er sendt.
Så det første spørsmålet er ikke hvilke tegn som er lovlige, men hvor forsøket stoppet. En klient som aldri åpnet en tilkobling, er ikke avvist av noen. Skriv ned trinnet du observerte, fordi hvert senere steg avhenger av den klassifiseringen.
Forskjellen endrer også hvem som fikser det. Et containerproblem tilhører enheten og eieren, mens en kontoavvisning tilhører den som driver autentiseringsbackenden.
Sammenlign containerne, ikke tegnene
Et GUI-passordfelt, en keychain-oppføring, en legitimasjonsfil med to linjer og en automasjonshemmelighet bærer alle samme verdi i en forskjellig konvolutt. Konvolutten har sine egne regler, og det er de reglene som vanligvis brytes. Verdien er sjelden problemet; transporten av verdien er det. Hold de to ideene fra hverandre, så blir diagnosen 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 |
Fellesskapets OpenVPN 2.6 klientalternativer beskriver den tolinjefilen for auth-user-pass, inkludert oppførselen når passordlinjen mangler: klienten spør i stedet. Den ene detaljen forklarer en klasse av rapporter om at den spør etter et passord brukeren allerede har oppgitt. Den forteller deg også at en tom andre linje er en meningsfull tilstand, ikke et ufarlig formateringsvalg.
Sitering er nok et eget lag: anførselstegn inne i en vanlig legitimasjonsfil lagres som data, mens et skall fjerner dem før programmet ser noe. Det samme tegnet er ufarlig på ett sted og strukturelt på et annet. En tabell kan ikke fortelle deg hvilken container klienten brukte, så les klientens egen konfigurasjon før du velger en rad.
Linjeskift er også strukturelle. En fil med linjedelte felt kan ikke bære en verdi som inneholder et linjeskift, og det er en begrensning i formatet, ikke en dom over passordstyrke. Bruk distribusjonens støttede leveringsmekanisme i stedet for å trimme hemmeligheten så den passer i en improvisert fil.
Bygg legitimasjonsfilen uten skade fra skallet
Den tryggeste lokale veien holder hemmeligheten utenfor skallhistorikken og utenfor prosessargumentlisten. Les begge feltene interaktivt, og skriv deretter de to linjene klienten forventer. Alt annet kan bli liggende i en konfigurasjonsfil som er lett å gjennomgå.
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 to første kommandoene leser brukernavnet og deretter passordet uten å vise det, den tredje skriver begge linjene, den fjerde begrenser filen, og den siste starter klienten med den filen. Legg merke til at read -r bevarer backslashes, som er nettopp den typen detalj som gjør et fungerende passord til et feilende når den utelates.
Unngå å bygge filen med en uquoted variabel eller et here-dokument fullt av skallutvidelser. Begge kan endre tegn før de når filen, og feilen som følger ser ut som en VPN-avvisning fordi passordet på disken faktisk er forskjellig fra passordet du kjenner. Sammenlign filens bytelengde med den forventede verdien hvis du mistenker dette, uten å skrive ut hemmeligheten selv. En forskjell på én eller to byte er signaturen til en siteringsulykke.
Les trinnet fra den første feilen
Behold den første konkrete meldingen fra ett forsøk, og klassifiser den deretter. En lokal valideringsfeil, en manglende privatnøkkel, en utilgjengelig hemmelighetsagent og en autentiseringsfeil i gatewayen er fire forskjellige resultater med fire forskjellige eiere. Bare én av dem handler om kontoen.
Hvis gatewayen virkelig avviser en korrekt levert legitimasjon, sjekk kontoen, autentiseringsbackenden og eventuell påkrevd utfordring sammen med administratoren. En generisk autentiseringsfeil navngir ikke et forbudt tegn.
Gjenopprett den godkjente verdien gjennom riktig mekanisme i stedet for å redusere den til bokstaver og sifre. Passordpolicyen tilhører operatøren, og en omvei som stille omgår den er ikke en rettelse. Den skjuler også den virkelige feilen for neste person, som vil møte den samme feilen med et svakere passord og ingen bedre idé.