Ugyldige løyndomar er eit containerproblem, ikkje ei passordregel
Ein avvist legitimasjon har kanskje aldri nådd gatewayen. Samanlikn inndatacontaineren, autentiseringstrinnet og sjølve kontoen først.
Å sjå "invalid secrets" gir vanlegvis éin konklusjon: VPN-en likar ikkje teiknsetjing. Den konklusjonen er vanlegvis feil, fordi meldinga ofte kjem frå lokal handsaming før nokon gateway har sett på kontoen. To design leverer det same passordet, eit grafisk felt og ei legitimasjonsfil, og dei feilar på ulike stader. Samanlikn containarane før du forenklar eit passord som var greitt heile tida.
Feilen kjem før gatewayen
Lokal validering, eit låst løyndomslager, ein manglande agent og ei feilformatert legitimasjonsfil gjev alle feil som brukaren opplever som éi avvising. Ingen av dei involverer autentiseringsserveren. Avvisinga frå gatewayen sjølv er ei eiga hending, og ho kjem vanlegvis med ei anna melding og eit anna tidspunkt. Ho skjer etter at ein tunnel finst og legitimasjonen er send.
Så det første spørsmålet er ikkje kva teikn som er lovlege, men kvar forsøket stoppa. Ein klient som aldri opna ei tilkopling, er ikkje avvist av nokon. Skriv ned trinnet du observerte, fordi kvart seinare steg avheng av den klassifiseringa.
Skiljet endrar òg kven som rettar det. Eit containerproblem høyrer til eininga og eigaren, medan ei kontoavvising høyrer til den som driv autentiseringsbackenden.
Samanlikn containarane, ikkje teikna
Eit GUI-passordfelt, ein keychain-oppføring, ei legitimasjonsfil med to linjer og ein automasjonsløyndom ber alle same verdien i ein annan konvolutt. Konvolutten har sine eigne reglar, og det er dei reglane som vanlegvis bryt saman. Verdien er sjeldan problemet; transporten av verdien er det. Hald dei to ideane frå kvarandre, så blir diagnosen kortare.
| 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 |
Fellesskapet sine OpenVPN 2.6 klientval skildrar den tolinjefila for auth-user-pass, inkludert åtferda når passordlinja manglar: klienten spør i staden. Den eine detaljen forklarer ein klasse rapportar om at han spør etter eit passord brukaren alt har oppgitt. Han fortel deg òg at ei tom andre linje er ein meiningsfull tilstand, ikkje eit ufarleg formateringsval.
Sitering er nok eit eige lag: hermeteikn inne i ei vanleg legitimasjonsfil blir lagra som data, medan eit skal fjernar dei før programmet ser noko. Det same teiknet er ufarleg på ein stad og strukturelt på ein annan. Ei tabell kan ikkje fortelje deg kva container klienten brukte, så les klienten si eiga konfigurering før du vel ei rad.
Linjeskift er òg strukturelle. Ei fil med linjedelte felt kan ikkje bera ein verdi som inneheld eit linjeskift, og det er ei avgrensing i formatet, ikkje ein dom over passordstyrke. Bruk den støtta leveringsmekanismen til distribusjonen i staden for å trimme løyndommen så han passar i ei improvisert fil.
Bygg legitimasjonsfila utan skade frå skalet
Den tryggaste lokale vegen held løyndommen utanfor skalhistorikken og utanfor prosessargumentlista. Les begge felta interaktivt, og skriv deretter dei to linjene klienten ventar. Alt anna kan bli liggjande i ei 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/credsDei to første kommandoane les brukarnamnet og deretter passordet utan å vise det, den tredje skriv begge linjene, den fjerde avgrensar fila, og den siste startar klienten med den fila. Legg merke til at read -r bevarer backslashar, som er nettopp den typen detalj som gjer eit fungerande passord til eit feilande når han blir utelaten.
Unngå å byggje fila med ein uquota variabel eller eit here-dokument fullt av skalutvidingar. Begge kan endre teikn før dei når fila, og feilen som følgjer ser ut som ei VPN-avvising fordi passordet på disken faktisk er ulikt passordet du kjenner. Samanlikn bytelengda til fila med den venta verdien om du mistenkjer dette, utan å skrive ut løyndommen sjølv. Ein skilnad på éin eller to byte er signaturen til ei siteringsulukke.
Les trinnet frå den første feilen
Hald på den første konkrete meldinga frå eitt forsøk, og klassifiser ho deretter. Ein lokal valideringsfeil, ein manglande privatnøkkel, ein utilgjengeleg løyndomsagent og ein autentiseringsfeil i gatewayen er fire ulike resultat med fire ulike eigarar. Berre eitt av dei handlar om kontoen.
Viss gatewayen verkeleg avviser ein korrekt levert legitimasjon, sjekk kontoen, autentiseringsbackenden og eventuell påkravd utfordring saman med administratoren. Ein generisk autentiseringsfeil namngir ikkje eit forbode teikn.
Gjenopprett den godkjende verdien gjennom rett mekanisme i staden for å redusere han til bokstavar og siffer. Passordpolicyen høyrer til operatøren, og ein omveg som stille omgår han er ikkje ei retting. Han skjuler òg den verkelege feilen for neste person, som vil møte den same feilen med eit svakare passord og inga betre idé.