Ogiltiga hemligheter är ett containerproblem, inte en lösenordsregel
En avvisad inloggningsuppgift kanske aldrig nådde gatewayen. Jämför först inmatningsbehållaren, autentiseringssteget och själva kontot.
När »invalid secrets« visas leder det oftast till en slutsats: VPN gillar inte skiljetecken. Den slutsatsen är oftast fel, eftersom meddelandet ofta kommer från lokal hantering innan någon gateway har tittat på kontot. Två konstruktioner levererar samma lösenord, ett grafiskt fält och en fil med inloggningsuppgifter, och de misslyckas på olika ställen. Jämför behållarna innan du förenklar ett lösenord som var bra hela tiden.
Felet kommer före gatewayen
Lokal validering, ett låst hemlighetslager, en saknad agent och en felaktig fil med inloggningsuppgifter ger alla fel som användaren upplever som en enda avvisning. Ingen av dem involverar autentiseringsservern. Gatewayens egen avvisning är en separat händelse och kommer oftast med ett annat meddelande och en annan timing. Den inträffar efter att en tunnel finns och uppgifterna har skickats.
Så den första frågan är inte vilka tecken som är tillåtna utan var försöket stannade. En klient som aldrig öppnade en anslutning har inte avvisats av någon. Skriv ner steget du observerade, eftersom varje senare steg beror på den klassificeringen.
Skillnaden ändrar också vem som åtgärdar det. Ett containerproblem tillhör enheten och dess ägare, medan en kontoavvisning tillhör den som driver autentiseringsserverdelen.
Jämför behållarna, inte tecknen
Ett grafiskt lösenordsfält, en nyckelringspost, en fil med inloggningsuppgifter på två rader och en hemlighet för automatisering bär alla samma värde i ett olika hölje. Höljet har sina egna regler och det är oftast de reglerna som brister. Värdet är sällan problemet; transporten av värdet är det. Håll de två idéerna isär så blir diagnosen kortare.
| Var värdet stannar | Vad du ser | Vad du kontrollerar | Vem som äger åtgärden |
|---|---|---|---|
| Grafiskt fält eller hanterad profil | Ett valideringsmeddelande innan någon anslutning öppnas | Det valda autentiseringsläget och om fältet innehåller hemligheten eller användarnamnet | Enhetens ägare eller profilens författare |
| Nyckelring eller hemlighetsagent | En uppmaning som ständigt återkommer, eller ett agentfel | Om agenten är upplåst och har en post för den här profilen | Användaren som äger nyckelringen |
| Fil med inloggningsuppgifter på två rader | En uppmaning om ett lösenord som redan har angetts | Antal rader, radordning och om en avslutande ny rad finns | Den som skapade filen |
| Skalargument eller miljö | Fungerar interaktivt men misslyckas i automatisering | Om skalet expanderade, trimmade eller loggade värdet | Den som skrev automatiseringen |
De officiella alternativen för klienten Community OpenVPN 2.6 beskriver den filen på två rader för auth-user-pass, inklusive beteendet när lösenordsraden saknas: klienten frågar i stället. Den enda detaljen förklarar en klass av rapporter om att den frågar efter ett lösenord som redan angetts. Den säger också att en tom andra rad är ett meningsfullt tillstånd och inte ett ofarligt formateringsval.
Citattecken är ännu ett separat lager: citattecken i en vanlig fil med inloggningsuppgifter lagras som data, medan ett skal tar bort dem innan programmet ser något. Samma tecken är ofarligt på ett ställe och strukturellt på ett annat. En tabell kan inte säga vilken behållare din klient använde, så läs klientens egen konfiguration innan du väljer en rad.
Radbrytningar är också strukturella. En fil med radavgränsade fält kan inte bära ett värde som innehåller en ny rad, och det är en begränsning i formatet snarare än en bedömning av lösenordsstyrka. Använd den leveransmekanism som driftsättningen stöder i stället för att trimma hemligheten så att den passar i en improviserad fil.
Bygg filen med inloggningsuppgifter utan skalskador
Den säkraste lokala vägen håller hemligheten utanför skalhistoriken och utanför processens argumentlista. Läs båda fälten interaktivt och skriv sedan de två raderna som klienten förväntar sig. Allt annat kan stanna i en konfigurationsfil som är lätt att granska.
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 två första kommandona läser användarnamnet och sedan lösenordet utan att eka det, det tredje skriver båda raderna, det fjärde begränsar filen och det sista startar klienten med den filen. Notera att read -r bevarar omvänt snedstreck, vilket är precis den typen av detalj som förvandlar ett fungerande lösenord till ett misslyckat när den utelämnas.
Undvik att bygga filen med en variabel utan citattecken eller ett here-dokument fullt av skalexpansioner. Båda kan omvandla tecken innan de når filen, och det resulterande felet ser ut som en VPN-avvisning eftersom lösenordet på disken verkligen är ett annat än det du känner till. Om du misstänker detta, jämför filens bytelängd med det förväntade värdet utan att skriva ut hemligheten. En skillnad på en eller två byte är signaturen för en citeringsolycka.
Läs steget från det första felet
Behåll det första specifika meddelandet från ett försök och klassificera det sedan. Ett lokalt valideringsfel, en saknad privat nyckel, en otillgänglig hemlighetsagent och ett autentiseringsfel i gatewayen är fyra olika resultat med fyra olika ägare. Bara ett av dem handlar om kontot.
Om gatewayen verkligen avvisar en korrekt levererad uppgift, kontrollera kontot, autentiseringsserverdelen och eventuell nödvändig utmaning med administratören. Ett allmänt autentiseringsfel namnger inte ett förbjudet tecken.
Återställ det godkända värdet genom rätt mekanism i stället för att reducera det till bokstäver och siffror. Lösenordspolicyn tillhör operatören, och en kringgående lösning som tyst upphäver den är ingen åtgärd. Den döljer också det verkliga felet för nästa person, som möter samma fel med ett svagare lösenord och ingen bättre idé.