Wanneer jy “ongeldige geheime” sien, lei dit gewoonlik tot een gevolgtrekking: die VPN hou nie van leestekens nie. Daardie gevolgtrekking is gewoonlik verkeerd, want die boodskap kom dikwels van plaaslike hantering voordat enige poort na die rekening gekyk het. Twee ontwerpe lewer dieselfde wagwoord, ’n grafiese veld en ’n aanmeldingslêer, en hulle misluk op verskillende plekke. Vergelyk die houers voordat jy ’n wagwoord vereenvoudig wat nog altyd reg was.

Die fout kom voor die poort

Plaaslike validering, ’n geslote geheimeberging, ’n ontbrekende agent en ’n wanvormige aanmeldingslêer lewer almal mislukkings wat ’n gebruiker as een verwerping ervaar. Nie een van hulle betrek die verifikasiebediener nie. Die poort se eie verwerping is ’n aparte gebeurtenis, en dit kom gewoonlik met ’n ander boodskap en ’n ander tydsberekening. Dit gebeur nadat ’n tonnel bestaan en aanmeldings oorgedra is.

Die eerste vraag is dus nie watter karakters wettig is nie, maar waar die poging gestop het. ’n Kliënt wat nooit ’n verbinding oopgemaak het nie, is deur niemand verwerp nie. Skryf die stadium neer wat jy waargeneem het, want elke latere stap hang van daardie klassifikasie af.

Die onderskeid verander ook wie dit regmaak. ’n Houerprobleem behoort aan die toestel en sy eienaar, terwyl ’n rekeningverwerping behoort aan wie ook al die verifikasie-agterkant bedryf.

Vergelyk die houers, nie die karakters nie

’n GUI-wagwoordveld, ’n sleutelring-inskrywing, ’n tweereël-aanmeldingslêer en ’n outomatiseringsgeheim dra elk dieselfde waarde in ’n ander omhulsel. Die omhulsel het sy eie reëls, en dit is daardie reëls wat gewoonlik breek. Die waarde is selde die probleem; die vervoer van die waarde is. Hou die twee idees apart en die diagnose word 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

Die Gemeenskap-OpenVPN 2.6-kliëntopsies beskryf daardie tweereël-lêer vir auth-user-pass, insluitend die gedrag wanneer die wagwoordlyn ontbreek: die kliënt vra dan eerder. Daardie enkele besonderheid verklaar ’n klas verslae van die tipe “dit vra vir ’n wagwoord wat ek reeds verskaf het”. Dit sê ook vir jou dat ’n leë tweede lyn ’n betekenisvolle toestand is eerder as ’n onskadelike keuse oor formatering.

Aanhaling is weer ’n aparte laag: aanhalingstekens binne ’n gewone aanmeldingslêer word as data gestoor, terwyl ’n shell dit verwyder voordat die program enigiets sien. Dieselfde karakter is onskadelik op een plek en struktureel op die ander. ’n Tabel kan nie vir jou sê watter houer jou kliënt gebruik het nie, so lees die kliënt se eie konfigurasie voordat jy ’n ry kies.

Reëlskeidings is ook struktureel. ’n Lêer met reëlgeskeide velde kan nie ’n waarde dra wat ’n nuwe reël bevat nie, en dit is ’n beperking van die formaat eerder as ’n oordeel oor wagwoordsterkte. Gebruik die ontplooiing se ondersteunde afleweringsmeganisme eerder as om die geheim in te kort om in ’n geïmproviseerde lêer te pas.

Bou die aanmeldingslêer sonder dat die shell dit beskadig

Die veiligste plaaslike roete hou die geheim uit die shell-geskiedenis en uit die proses se argumentlys. Lees albei velde interaktief, skryf dan die twee reëls wat die kliënt verwag. Al die res kan in ’n konfigurasielêer bly wat maklik nagesien kan word.

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

Die eerste twee opdragte lees die gebruikersnaam en dan die wagwoord sonder om dit te eggo, die derde skryf albei reëls, die vierde beperk die lêer, en die laaste begin die kliënt met daardie lêer. Let daarop dat read -r terugskuinsstrepe bewaar, wat presies die soort besonderheid is wat ’n werkende wagwoord in ’n falende een verander wanneer dit weggelaat word.

Vermy om die lêer met ’n onaanhaling (unquoted) veranderlike of ’n here-dokument vol shell-uitbreidings te bou. Albei kan karakters verander voordat hulle die lêer bereik, en die gevolglike mislukking lyk soos ’n VPN-verwerping omdat die wagwoord op skyf werklik anders is as die wagwoord wat jy ken. Vergelyk die lêer se grepbylengte met die verwagte waarde as jy dit vermoed, sonder om die geheim self te druk. ’n Verskil van een of twee grepe is die kenmerk van ’n aanhaling-ongeluk.

Lees die stadium uit die eerste fout

Hou die eerste spesifieke boodskap van een poging, en klassifiseer dit dan. ’n Plaaslike valideringsfout, ’n ontbrekende private sleutel, ’n onbeskikbare geheime-agent en ’n poort-verifikasiefout is vier verskillende resultate met vier verskillende eienaars. Net een van hulle gaan oor die rekening.

As die poort werklik ’n korrek afgelewerde geloofsbrief verwerp, laat die rekening, die verifikasie-agterkant en enige vereiste uitdaging dan saam met die administrateur nagaan. ’n Algemene verifikasiefout noem nie ’n verbode karakter nie.

Herstel die goedgekeurde waarde deur die korrekte meganisme eerder as om dit tot letters en syfers te reduseer. Die wagwoordbeleid behoort aan die operateur, en ’n oplossing wat dit stilweg verydel, is nie ’n regstelling nie. Dit verberg ook die werklike defek vir die volgende persoon, wat dieselfde fout met ’n swakker wagwoord en geen beter idee sal teëkom.

Verwante artikels