Neteisingi slaptieji duomenys yra konteinerio problema, o ne slaptažodžio taisyklė
Atmesti prisijungimo duomenys gali būti niekada nepasiekę tinklų sietuvo. Pirmiausia palyginkite įvesties konteinerį, autentifikavimo etapą ir pačią paskyrą.
Pamatę "invalid secrets" dažniausiai darome vieną išvadą: VPN nemėgsta skyrybos ženklų. Ta išvada dažniausiai neteisinga, nes pranešimas dažnai ateina iš vietinio apdorojimo, dar prieš bet kuriam tinklų sietuvui pažvelgus į paskyrą. Du sprendimai perduoda tą patį slaptažodį — grafinis laukas ir prisijungimo duomenų failas — ir jie sugenda skirtingose vietose. Palyginkite konteinerius, prieš supaprastindami slaptažodį, kuris visą laiką buvo geras.
Klaida ateina prieš tinklų sietuvą
Vietinė validacija, užrakinta slaptųjų duomenų saugykla, neegzistuojantis agentas ir netaisyklingai suformuotas prisijungimo duomenų failas — visi sukuria gedimus, kuriuos naudotojas patiria kaip vieną atmetimą. Nė vienas iš jų nesusijęs su autentifikavimo serveriu. Paties tinklų sietuvo atmetimas yra atskiras įvykis ir dažniausiai ateina su kitu pranešimu bei kitu laiku. Jis įvyksta po to, kai tunelis jau egzistuoja, o duomenys perduoti.
Taigi pirmas klausimas ne kokie simboliai leidžiami, o kur bandymas sustojo. Klientas, kuris nė karto neatidarė ryšio, niekieno nebuvo atmestas. Užrašykite etapą, kurį stebėjote, nes kiekvienas tolesnis žingsnis priklauso nuo šios klasifikacijos.
Šis skirtumas keičia ir tai, kas tai taiso. Konteinerio problema priklauso įrenginiui ir jo savininkui, o paskyros atmetimas — tam, kas valdo autentifikavimo posistemį.
Palyginkite konteinerius, o ne simbolius
GUI slaptažodžio laukas, raktų saugyklos įrašas, dviejų eilučių prisijungimo duomenų failas ir automatizavimo paslaptis — visi perduoda tą pačią reikšmę skirtingame voke. Vokas turi savo taisykles, ir dažniausiai lūžta būtent jos. Reikšmė retai būna problema; problemą kelia reikšmės transportavimas. Laikykite dvi idėjas atskirai, ir diagnozė sutrumpės.
| 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 |
Community OpenVPN 2.6 kliento parinktys aprašo tą dviejų eilučių failą, skirtą auth-user-pass, įskaitant elgseną, kai slaptažodžio eilutės nėra: tada klientas paklausia. Ši viena detalė paaiškina pranešimų grupę "kodėl jis klausia slaptažodžio, kurį jau pateikiau". Ji taip pat parodo, kad tuščia antra eilutė yra prasminga būsena, o ne nekenksmingas formatavimo pasirinkimas.
Citavimas yra dar vienas sluoksnis: kabutės paprastame prisijungimo duomenų faile saugomos kaip duomenys, o apvalkalas jas pašalina, prieš programai ką nors pamatant. Tas pats simbolis vienoje vietoje nekenksmingas, kitoje — struktūrinis. Lentelė negali pasakyti, kurį konteinerį naudojo jūsų klientas, todėl prieš rinkdamiesi eilutę perskaitykite paties kliento konfigūraciją.
Eilučių lūžiai taip pat struktūriniai. Failas su eilutėmis atskirtais laukais negali perduoti reikšmės su nauja eilute, ir tai formato apribojimas, o ne sprendimas apie slaptažodžio stiprumą. Naudokite diegimo palaikomą pristatymo mechanizmą, o ne trumpinkite slaptąjį duomenį, kad jis tilptų į improvizuotą failą.
Sukurkite prisijungimo duomenų failą nepažeisdami apvalkalo
Saugiausias vietinis kelias laiko paslaptį už apvalkalo istorijos ir už proceso argumentų sąrašo. Perskaitykite abu laukus interaktyviai, tada įrašykite dvi eilutes, kurių tikisi klientas. Visa kita gali likti konfigūracijos faile, kurį lengva peržiūrėti.
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/credsPirmos dvi komandos nuskaito naudotojo vardą ir slaptažodį jo neperteikdamos, trečioji įrašo abi eilutes, ketvirtoji apriboja failo teises, o paskutinė paleidžia klientą su tuo failu. Atkreipkite dėmesį, kad read -r išsaugo atgalinius brūkšnelius, ir būtent tokia detalė paverčia veikiantį slaptažodį neveikiančiu, kai jos nepaisoma.
Nekurkite failo su necituotu kintamuoju arba here-document, pilnu apvalkalo plėtinių. Abu gali pakeisti simbolius, kol jie pasieks failą, ir atsiradęs gedimas atrodo kaip VPN atmetimas, nes diske esantis slaptažodis tikrai skiriasi nuo to, kurį žinote. Jei įtariate, palyginkite failo baitų ilgį su laukiama reikšme, nespausdindami pačios paslapties. Vieno ar dviejų baitų neatitikimas yra citavimo avarijos parašas.
Nuskaitykite etapą iš pirmosios klaidos
Išsaugokite pirmą konkrečią vieno bandymo žinutę ir klasifikuokite ją. Vietinė validacijos klaida, neegzistuojantis privatus raktas, nepasiekiamas slaptosios agentas ir tinklų sietuvo autentifikavimo gedimas yra keturi skirtingi rezultatai su keturiais skirtingais atsakingais. Tik vienas iš jų yra apie paskyrą.
Jei tinklų sietuvas tikrai atmeta teisingai perduotus duomenis, su administratoriumi patikrinkite paskyrą, autentifikavimo posistemį ir bet kokį privalomą iššūkį. Bendras autentifikavimo gedimas neįvardija uždrausto simbolio.
Atkurkite patvirtintą reikšmę tinkamu mechanizmu, o ne sumažinkite ją iki raidžių ir skaitmenų. Slaptažodžių politika priklauso operatoriui, o apėjimas, kuris ją tyliai apeina, nėra pataisa. Jis taip pat paslepia tikrąjį defektą nuo kito žmogaus, kuris susidurs su ta pačia klaida naudodamas silpnesnį slaptažodį.