OpenVPN tarnyba sustoja prašant privataus rakto slaptažodžio: kaip tai ištaisyti
Tarnyba neturi terminalo, todėl užšifruotam raktui reikia askpass ir skaitomo failo. Atskirkite rakto slaptafrazę nuo prisijungimo prie serverio ir patikrinkite unit.
OpenVPN vietiniame kompiuteryje prašo privataus rakto slaptafrazės, todėl veikiantis prisijungimo failas į ją niekada neatsako. Tarnyboje nėra terminalo rašyti, o paleidimas arba pakimba, arba nepavyksta su žurnalo įrašu, kuris įvardija įvestį, o ne priežastį. Čia susijusios dvi paslaptys, ir kiekvienai prieš unit perkrovimą reikia savo skaitomo šaltinio. Toliau pateikta eiga jas atskiria, o po to patikrina tapatybę, kuri iš tikrųjų atidaro kiekvieną failą.
Atskirkite abu prašymus
Rakto slaptafrazė iššifruoja vietinį privatų raktą; paskyros duomenys autentifikuoja sesiją serveryje. Jie ateina iš skirtingų vietų, nepavyksta skirtingais momentais ir pateikia skirtingus pranešimus. Sumaišius juos, žmonės ieško slaptažodžio atkūrimo, nors paskyra visai nedalyvavo. Prieš keisdami bet kurią parinktį perskaitykite prašymo tekstą, nes formuluotė yra vienintelė patikima užuomina, kurios paslapties trūksta.
„Community OpenVPN 2.x“ askpass nurodo failą, kurio pirmoje eilutėje yra rakto slaptafrazė, o auth-user-pass nurodo failą, kuriame vienoje eilutėje yra vartotojo vardas, o kitoje – slaptažodis. Nė vienas failas netenkina kitos parinkties. Darbalaukio programėlė ar „NetworkManager“ profilis gali laikyti abu savo paslapčių saugykloje, kurios komandinės eilutės klientas niekada neskaito, todėl prieš rašydami bet kurį kelią atkreipkite dėmesį, kurį klientą konfigūruojate.
Nukreipkite abi parinktis į skaitomus failus
Profilis, kuriam reikia abiejų įvesčių, galiausiai turi tris failų nuorodas: užšifruotą raktą, jį atidarančią slaptafrazę ir prisijungimo porą. Pridėkite jas neliesdami CA ir tapatybės patikrų, nes šios nusprendžia, kas yra serveris, ir nepriklauso šiai problemai. Jei diegimas visai nenaudoja paskyros duomenų, pridėjus auth-user-pass sukuriama įvestis, kurios niekas negali pateikti.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authParinktys be argumento elgiasi kitaip nei parinktys su keliu, ir tarnyboje šis skirtumas svarbus. askpass be argumento vis dar skaito konsolę, o auth-user-pass failas su vien tik vartotojo vardu vis dar palieka laukiantį slaptažodžio prašymą. Kai klientas tampa demonu, jis visai negali prašyti terminalo įvesties, todėl taip sukonfigūruota tarnyba nepasileidžia.
Absoliutūs keliai pašalina darbo katalogo klausimą, bet nesuteikia prieigos. Toliau seka savininkas, režimas ir praėjimas, ir visi trys tikrinami pagal paskyrą, kuria veikia procesas.
Pirmiau perskaitykite unit konfigūraciją, o paskui profilį
Kurią konfigūraciją įkelia egzempliorius, sprendžia unit, o ne failas, kurį redagavote. Perskaitykite jo komandų eilutę ir visus drop-in, tada sekite darbo katalogu iki faktiškai naudojamo profilio. Slaptafrazės nuoroda, pridėta prie kito .ovpn failo, šiam egzemplioriui nieko nekeičia.
Trys tik skaitymo komandos atsako į didžiąją dalį. Pirmoji išspausdina unit ir visus drop-in, antroji – tapatybę ir proceso ribojančius sandbox nustatymus, trečioji – dėl ko paskutinis paleidimas iš tikrųjų skundėsi. Naudokite egzemplioriaus vardą, kuris egzistuoja pagrindiniame kompiuteryje:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bAtkreipkite dėmesį į ProtectHome ir į paties profilio parinktis user, group ir chroot. Failas namų kataloge gali būti skaitomas jūsų apvalkale ir nematomas tarnybos viduje, kai namų katalogai paslepiami. Paskyra, kuria paleidžiama systemd, ne visada yra ta paskyra, kuri galiausiai atidaro raktą.
Įrodykite, kad vykdymo tapatybė gali atidaryti abu failus
Režimo perskaityti nepakanka, nes kiekvienas kelio katalogas turi būti pereinamas ta pačia tapatybe. Pereikite kelią komponentas po komponento, tada išbandykite atidarymą kaip paskyra, kurią naudoja procesas. Failas su režimu 600, priklausantis root, veikia tik tol, kol procesas dar yra root, o po daugelio profilių atliekamo privilegijų sumažinimo tai nebegalioja. Dvi komandos apima praėjimą ir atidarymą:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readablePirmoji komanda išspausdina kiekvieno komponento režimą ir nepavyksta ten, kur paskyra negali praeiti; antroji atsako į vienintelį svarbų klausimą – ar vykdymo tapatybė gali atidaryti failą skaitymui. Nė viena nespausdina failo turinio, ir būtent tai yra esmė, kai faile yra slaptafrazė. Pakartokite bandymą prisijungimo failui, nes abu dažnai saugomi su skirtingu savininku.
Jei procesas naudoja chroot arba ribotą namespace, paleiskite tą patį bandymą iš to vaizdo vidaus, kitaip atsakymas aprašo neteisingą failų sistemą. Paslaptis, saugoma po paslėptu namų katalogu, yra įprastas bandymo, kuris pavyksta už unit ribų ir nepavyksta jo viduje, pavyzdys.
Patikrinkite pirmą paleidimą, o paskui prisijungimą iš naujo
Paleiskite egzempliorių vieną kartą ir skaitykite pirmą, o ne paskutinę klaidą. Trūkstamas įvesties failas, nepavykęs rakto iššifravimas ir serverio pusėje gautas AUTH_FAILED yra trys skirtingi įvykiai su trimis skirtingais taisymais. Teisių įspėjimo ištaisymas nieko neįrodo apie tai, ar raktas buvo atidarytas.
Žurnalo eilutė pasako, kuris iš trijų. Taisymas išplaukia iš to, kuri įvestis nepavyko:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
Tada išbandykite gyvavimo ciklą, kurio jums iš tikrųjų reikia: paleidimą įkrovimo metu ir bet kokį palaikomą prisijungimą iš naujo, o ne tik rankinį paleidimą iš savo apvalkalo. Su auth-nocache įvestys atmetamos po pirmo naudojimo, todėl vėlesniam prisijungimui iš naujo vis tiek reikia skaitomo šaltinio. Raktų saugykla, atidaroma prisijungiant prie darbalaukio, neprieinama tarnybai, kuri startavo prieš kam nors prisijungiant, ir tai įprasta priežastis, kodėl rankinis bandymas pavyksta, o perkrovimas nepavyksta. Jei pirmas paleidimas pavyksta, o vėlesnis prisijungimas iš naujo nepavyksta, perskaitykite žurnalą apie prisijungimo iš naujo įvykį prieš vėl keisdami teises.
Slaptafrazės laikymas prie rakto sumažina tai, ką duoda šifravimas, todėl apribokite tą failą ir jo atsargines kopijas. Rakto slaptafrazės pašalinimą traktuokite kaip atskirą prisijungimo duomenų sprendimą, o ne kaip trūkstamos įvesties taisymą. Diegimui, kuris priklauso nuo žmogaus patvirtinimo ar interaktyvios MFA, reikia palaikomo agento ar valdymo integracijos; visam laikui išsaugotas vienkartinis kodas nėra lygiavertis pakaitalas.