Het zien van "invalid secrets" leidt meestal tot één conclusie: de VPN houdt niet van leestekens. Die conclusie is meestal onjuist, omdat de melding vaak uit lokale verwerking komt voordat een gateway naar het account heeft gekeken. Twee ontwerpen leveren hetzelfde wachtwoord, een grafisch veld en een inloggegevensbestand, en ze falen op verschillende plaatsen. Vergelijk de containers voordat je een wachtwoord vereenvoudigt dat al die tijd in orde was.

De fout komt vóór de gateway

Lokale validatie, een vergrendelde geheimenopslag, een ontbrekende agent en een misvormd inloggegevensbestand produceren allemaal fouten die de gebruiker als één afwijzing ervaart. Geen ervan betrekt de authenticatieserver. De afwijzing van de gateway zelf is een aparte gebeurtenis, en die komt meestal met een andere melding en een andere timing. Ze gebeurt nadat er een tunnel bestaat en inloggegevens zijn verzonden.

De eerste vraag is dus niet welke tekens zijn toegestaan, maar waar de poging stopte. Een client die nooit een verbinding opende, is door niemand afgewezen. Schrijf de fase op die je hebt waargenomen, want elke latere stap hangt van die classificatie af.

Het onderscheid verandert ook wie het oplost. Een containerprobleem hoort bij het apparaat en zijn eigenaar, terwijl een accountafwijzing hoort bij wie de authenticatiebackend beheert.

Vergelijk de containers, niet de tekens

Een GUI-wachtwoordveld, een keychain-item, een inloggegevensbestand van twee regels en een automatiseringsgeheim dragen allemaal dezelfde waarde in een andere envelop. De envelop heeft zijn eigen regels, en die regels zijn wat meestal breekt. De waarde is zelden het probleem; het transport van de waarde is dat. Houd de twee ideeën uit elkaar en de diagnose wordt korter.

Where the value stopsWhat you seeWhat you checkWho owns the fix
GUI field or managed profileA validation message before any connection opensThe selected authentication mode and whether the field holds the secret or the usernameThe device owner or the profile author
Keychain or secret agentA prompt that keeps reappearing, or an agent errorWhether the agent is unlocked and holds an entry for this profileThe user who owns the keychain
Two-line credential fileA prompt for a password that was already suppliedLine count, line order and whether a trailing newline is presentWhoever generated the file
Shell argument or environmentWorks interactively but fails in automationWhether the shell expanded, trimmed or logged the valueWhoever wrote the automation

De Community OpenVPN 2.6-clientopties beschrijven dat bestand van twee regels voor auth-user-pass, inclusief het gedrag wanneer de wachtwoordregel ontbreekt: de client vraagt er dan om. Dat ene detail verklaart een klasse meldingen als "hij vraagt om een wachtwoord dat ik al heb opgegeven". Het vertelt je ook dat een lege tweede regel een betekenisvolle toestand is, geen onschuldige opmaakkeuze.

Quoting is weer een aparte laag: aanhalingstekens in een gewoon inloggegevensbestand worden als gegevens opgeslagen, terwijl een shell ze verwijdert voordat het programma iets ziet. Hetzelfde teken is op de ene plaats onschuldig en op de andere structureel. Een tabel kan je niet vertellen welke container je client gebruikte, dus lees de configuratie van de client zelf voordat je een rij kiest.

Regelafbrekingen zijn ook structureel. Een bestand met door regels gescheiden velden kan geen waarde bevatten met een nieuwe regel, en dat is een beperking van het formaat, geen oordeel over wachtwoordsterkte. Gebruik het ondersteunde leveringsmechanisme van de implementatie in plaats van het geheim in te korten om in een geïmproviseerd bestand te passen.

Bouw het inloggegevensbestand zonder schade door de shell

De veiligste lokale route houdt het geheim buiten de shellgeschiedenis en buiten de argumentenlijst van het proces. Lees beide velden interactief en schrijf daarna de twee regels die de client verwacht. Al het andere kan in een configuratiebestand blijven dat gemakkelijk te beoordelen is.

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/creds

De eerste twee opdrachten lezen de gebruikersnaam en daarna het wachtwoord zonder het te tonen, de derde schrijft beide regels, de vierde beperkt het bestand en de laatste start de client met dat bestand. Merk op dat read -r backslashes behoudt, precies het soort detail dat een werkend wachtwoord verandert in een falend wachtwoord wanneer het wordt weggelaten.

Vermijd het bouwen van het bestand met een niet-aangehaalde variabele of een here-document vol shellexpansies. Beide kunnen tekens veranderen voordat ze het bestand bereiken, en de resulterende fout lijkt op een VPN-afwijzing omdat het wachtwoord op schijf werkelijk verschilt van het wachtwoord dat je kent. Vergelijk de bytelengte van het bestand met de verwachte waarde als je dit vermoedt, zonder het geheim zelf af te drukken. Een verschil van één of twee bytes is het kenmerk van een quoting-ongeluk.

Lees de fase uit de eerste fout

Bewaar het eerste specifieke bericht van één poging en classificeer het daarna. Een lokale validatiefout, een ontbrekende privésleutel, een niet-beschikbare geheimenagent en een authenticatiefout bij de gateway zijn vier verschillende resultaten met vier verschillende eigenaren. Slechts één ervan gaat over het account.

Als de gateway echt inloggegevens afwijst die correct zijn aangeleverd, controleer dan het account, de authenticatiebackend en elke vereiste uitdaging met de beheerder. Een generieke authenticatiefout noemt geen verboden teken.

Herstel de goedgekeurde waarde via het juiste mechanisme in plaats van hem te reduceren tot letters en cijfers. Het wachtwoordbeleid is van de operator, en een omweg die dat stilletjes ondermijnt is geen oplossing. Hij verbergt ook het echte defect voor de volgende persoon, die dezelfde fout zal tegenkomen met een zwakker wachtwoord en geen beter idee.

Gerelateerde artikelen