Az OpenVPN szolgáltatás elakad a titkos kulcs jelszavának kérésénél: így javítható
A szolgáltatásnak nincs terminálja, ezért a titkosított kulcshoz askpass és olvasható fájl kell. Válassza külön a kulcs jelmondatát a kiszolgáló bejelentkezésétől, és ellenőrizze az unitot.
OpenVPN a helyi gépen kéri a titkos kulcs jelmondatát, ezért egy működő bejelentkezési fájl soha nem válaszol rá. A szolgáltatásban nincs terminál a beírásra, és az indítás vagy megakad, vagy naplóbejegyzéssel hiúsul meg, amely a bemenetet nevezi meg az ok helyett. Két titok van jelen, és mindegyiknek meg kell lennie a saját olvasható forrásának az unit újraindítása előtt. Az alábbi menet szétválasztja őket, majd ellenőrzi azt az identitást, amely valóban megnyit minden fájlt.
Különböztesse meg a két kérést
A kulcs jelmondata fejti vissza a helyi titkos kulcsot; a fiók hitelesítő adatai hitelesítik a munkamenetet a kiszolgáló felé. Különböző helyekről jönnek, különböző pillanatokban hiúsulnak meg, és különböző üzeneteket adnak. Összekeverésük jelszó-visszaállítás után küldi az embereket, pedig a fiók nem is vett részt. Olvassa el a kérés szövegét, mielőtt bármely beállítást módosít, mert a megfogalmazás az egyetlen megbízható nyom arra, melyik titok hiányzik.
A Community OpenVPN 2.x-ben a askpass olyan fájlt nevez meg, amelynek első sorában a kulcs jelmondata van, a auth-user-pass pedig olyat, amelyben a felhasználónév az egyik sorban, a jelszó a következőben. Egyik fájl sem elégíti ki a másik beállítást. Egy asztali alkalmazás vagy NetworkManager-profil mindkettőt a saját titoktárában tarthatja, amelyet a parancssori kliens soha nem olvas, ezért jegyezze fel, melyik klienst állítja be, mielőtt bármilyen útvonalat ír.
Irányítsa mindkét beállítást olvasható fájlokra
Egy profil, amelynek mindkét bemenetre szüksége van, végül három fájlhivatkozás mellett marad: a titkosított kulcs, az azt kinyitó jelmondat és a bejelentkezési pár. Adja hozzá őket anélkül, hogy a CA-hoz vagy az identitásellenőrzésekhez nyúlna, mert azok döntik el, ki a kiszolgáló, és nem részei ennek a problémának. Ha a telepítés egyáltalán nem használ fiókadatokat, a auth-user-pass hozzáadása olyan bemenetet hoz létre, amelyet senki nem tud szolgáltatni.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authAz argumentum nélküli beállítások másképp viselkednek, mint az útvonalasak, és szolgáltatásban ez a különbség számít. Az argumentum nélküli askpass továbbra is a konzolt olvassa, és a csak felhasználónevet tartalmazó auth-user-pass fájl továbbra is várakoztat egy jelszókérést. Amint a kliens démonná válik, egyáltalán nem tud bemenetet kérni a termináltól, ezért az így beállított szolgáltatás nem indul el.
Az abszolút útvonalak megszüntetik a munkakönyvtár kérdését, de nem adnak hozzáférést. Ezután jön a tulajdonos, a mód és az átjárhatóság, és mindhármat annak a fióknak a viszonylatában ellenőrzi a rendszer, amely alatt a folyamat fut.
Előbb az unit beállításait olvassa el, aztán a profilt
Hogy melyik beállítást tölti be a példány, azt az unit dönti el, nem az a fájl, amelyet szerkesztett. Olvassa el a parancssorát és minden drop-int, majd kövesse a munkakönyvtárat a ténylegesen használt profilig. Egy másik .ovpn fájlba tett jelmondat-hivatkozás semmit nem változtat ezen a példányon.
Három csak olvasható parancs megválaszolja a legtöbbet. Az első kiírja az unitot és az esetleges drop-inekat, a második az identitást és a folyamatot korlátozó sandbox-beállításokat, a harmadik pedig azt, hogy mire panaszkodott valójában az utolsó indítás. A gazdagépen létező példánynevet használja:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bFigyeljen a ProtectHome beállításra és a profil saját user, group és chroot opcióira. Egy otthoni könyvtár alatti fájl olvasható lehet a héjában, és láthatatlan a szolgáltatásban, ha az otthoni könyvtárakat elrejtik. Az a fiók, amellyel a systemd indul, nem mindig az a fiók, amely végül kinyitja a kulcsot.
Bizonyítsa, hogy a futásidejű identitás mindkét fájlt meg tudja nyitni
A mód elolvasása nem elég, mert az útvonal minden könyvtárának átjárhatónak kell lennie ugyanazon identitás számára. Járja végig az útvonalat összetevőnként, majd próbálja ki a megnyitást a folyamat által használt fiókkal. Egy root tulajdonában lévő, 600 módú fájl csak addig működik, amíg a folyamat még root, ami sok profil jogosultságcsökkentése után már nem igaz. Két parancs fedi le az átjárást és a megnyitást:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableAz első parancs kiírja minden összetevő módját, és ott hiúsul meg, ahol a fiók nem tud átjárni; a második az egyetlen fontos kérdésre válaszol, vagyis hogy a futásidejű identitás meg tudja-e nyitni a fájlt olvasásra. Egyik sem írja ki a fájl tartalmát, és éppen ez a lényeg, amikor a fájl jelmondatot tartalmaz. Ismételje meg a tesztet a bejelentkezési fájlra is, mert a kettőt gyakran eltérő tulajdonossal tárolják.
Ha a folyamat chrootot vagy korlátozott namespace-t használ, ugyanezt a tesztet abból a nézetből futtassa, különben a válasz a rossz fájlrendszert írja le. Egy rejtett otthoni könyvtár alatt tárolt jelmondat a szokásos példa arra a tesztre, amely az uniton kívül átmegy, belül viszont megbukik.
Ellenőrizze az első indítást, majd az újracsatlakozást
Indítsa el a példányt egyszer, és az első, ne az utolsó hibát olvassa el. A hiányzó bemeneti fájl, a sikertelen kulcsvisszafejtés és a kiszolgáló oldali AUTH_FAILED három különböző esemény három különböző javítással. Egy jogosultsági figyelmeztetés javítása semmit nem bizonyít arról, hogy a kulcs kinyílt-e.
A naplósor megmondja, melyik a három közül. A javítás abból következik, melyik bemenet hiúsult meg:
| 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 |
Utána tesztelje azt az életciklust, amelyre valóban szüksége van: indítást bootkor és minden támogatott újracsatlakozást, nem csak egy kézi indítást a héjából. A auth-nocache mellett a bemenetek az első használat után eldobódnak, ezért egy későbbi újracsatlakozásnak még mindig olvasható forrás kell. Egy asztali bejelentkezéskor kinyíló kulcstartó nem érhető el olyan szolgáltatás számára, amely azelőtt indult, hogy bárki bejelentkezett volna, és ez a szokásos oka annak, hogy egy kézi teszt átmegy, az újraindítás pedig megbukik. Ha az első indítás sikerül, és egy későbbi újracsatlakozás megbukik, olvassa el a naplóban az újracsatlakozási eseményt, mielőtt újra módosítja a jogosultságokat.
A jelmondat kulcs melletti tárolása csökkenti, amit a titkosítás nyújt, ezért korlátozza azt a fájlt és a biztonsági mentéseit. A kulcs jelmondatának eltávolítását külön hitelesítőadat-döntésként kezelje, ne a hiányzó bemenet javításaként. Az emberi jóváhagyástól vagy interaktív MFA-tól függő telepítésnek a támogatott ügynökére vagy felügyeleti integrációjára van szüksége; a tartósan mentett egyszeri kód nem egyenértékű helyettesítő.