OpenVPN hitelesítő fájl vagy vezérlő socket: melyiket szkripteljük

Egy szkript, amely elindítja az OpenVPN-t és soha nem csatlakozik, általában nem hálózati probléma: a kliens egy kérésnél ül, terminál nélkül, amelyre kirajzolhatná. OpenVPN pontosan két támogatott módot kínál arra, hogy ember nélkül válaszoljon erre a kérésre, a hitelesítő fájlt az auth-user-pass mögött és a vezérlő socketet, és ezek nem felcserélhetők. A fájl egy direktívába kerül és egy kérésre válaszol; a socket minden kérésre válaszol, és bárminek, ami képes loopback portot nyitni, hitelesítés nélküli vezérlőcsatornát ad. Hogy melyik illik a telepítéséhez, attól függ, melyik kérés blokkol valójában, és melyik titkot engedheti meg magának nyugalomban hagyni.

Nevezze meg a kérést, mielőtt mechanizmust választ

Négy kérés ugyanúgy néz ki egy terminálon. A fiók páros a szerver PAM vagy auth-user-pass-verify beállításából jön, és az auth-user-pass válaszol rá. A privát kulcs jelmondata a kulcsfájlhoz tartozik, és --askpass-szal olvasható vagy kézzel gépelhető. A PKCS#12 csomag a saját jelszavát kéri. A proxy hitelesítés a --http-proxy által vett auth fájlt használja, nem a fiók hitelesítő adatait.

Amikor az OpenVPN a systemd, a PHP vagy a Node gyermekeként fut, nincs terminál, így ezek bármelyike csendben blokkol. A folyamat ott ül, a napló megáll a titkosítás sora után, és az egység végül időtúllépésbe fut; ez a csend az oka annak, hogy az emberek újrapróbálkozó ciklust vagy sleepet adnak hozzá ahelyett, hogy megnéznék, melyik kérés vár. Csak a vezérlő socket tud mind a négyre válaszolni. A hitelesítő fájl az elsőre válaszol, és semmi másra.

auth-user-pass: egy fájl, egy kérés

A fájl az első sorban a felhasználónevet, a másodikban a jelszót tartalmazza, és semmi mást: nincs idézőjel, nincs kulcsnév, nincs megjegyzés. Állítsa 600-as módra, és tegye tulajdonossá azt a fiókot, amely az openvpn-t futtatja, ami szolgáltatásnál gyakran dedikált felhasználó, nem az Ön bejelentkezése. A /root alatt root tulajdonában lévő fájl a különbség a shelljében működő parancs és az indításkor meghiúsuló egység között.

Két részlet tesz egy helyes fájlt kéréssé. A CRLF-et mentő szerkesztő a jelszóhoz ragadt kocsivisszatérést hagy, ezért a szerver elutasít egy jelszót, amely a fájlban helyesnek tűnik; ellenőrizze cat -A vagy od -c segítségével, ne szemmel. A profilban lévő argumentum nélküli auth-user-pass pedig tervezés szerint «kérdezd meg a felhasználót» jelent, amit a parancssori második direktíva esetleg nem ír felül, mert a profil ott elemződik, ahol van.

Az opciók sorrendje a harmadik csapda, és verziófüggő. Egyes OpenVPN 2.4 buildek figyelmen kívül hagyják a --auth-user-pass-t, ha a --config előtt áll, így ugyanaz a két opció más sorrendben csatlakozik. Tegye a direktívát a profilba, vagy a parancssorban a --config után, és mielőtt bármi mást változtatna, keressen rá a profilban minden előfordulásra.

Az auth-nocache ehhez a mechanizmushoz tartozik, de nem ad semmit. Korlátozza, meddig tartja a kliens a hitelesítő adatot a memóriában, ami összeomlás után segít, és egyáltalán nem, ha a fájl hiányzik. A szerveroldali munkamenet időtúllépése utáni újracsatlakozás újraolvassa a fájlt, így az indításkor működő hitelesítő adat még a nap közepén lejárhat.

A vezérlő socket: minden kérés, nagyobb felület

Indítsa a klienst figyelővel, és mondja ki egyértelműen, hogy a kérések azon lesznek jelentve, az OpenVPN 2.6 kézikönyvében dokumentált direktívákkal:

management 127.0.0.1 3030
management-query-passwords

Bashból tartsa a kapcsolatot egy tartalék fájlleíró leírón, és a kérés neve szerint válaszoljon, ne a pozíció szerint, mert az újracsatlakozás más sorrendben kérdezhet:

exec 3<>/dev/tcp/127.0.0.1/3030
while read -r -u 3 line; do
  case "$line" in
    *"Need 'Auth' username/password"*)
      echo 'username "Auth" alice' >&3
      echo 'password "Auth" secret' >&3 ;;
    *"Need 'Private Key' password"*)
      echo 'password "Private Key" secret' >&3 ;;
  esac
done

A határ a szállítás. A vezérlő protokoll sima szöveg TCP felett loopbacken, ezért a figyelőt nem szabad LAN vagy alagút címén közzétenni, hogy egy távoli vezérlő elérhesse; a távoli vezérlő SSH-továbbítást jelent, nem szélesebb kötést. A közösségi daemon egyszerre csak egy vezérlő klienst fogad, ezért egy GUI vagy monitor nem oszthatja meg a socketet a szkriptjével. A második kapcsolat elutasításra kerül, nem sorba, és a hiba úgy néz ki, mint egy megsüketült szkript.

Ez a socket vezérlőcsatorna is. Vezérlő jelszó nélkül bármi, ami csatlakozni tud a 127.0.0.1:3030-hoz, olvashat állapotot, megölheti az alagutat, vagy maga válaszolhat egy kérésre. A vezérlő jelszó és a hitelesítő fájl ugyanabba a titokosztályba tartozik, és mindkettő ugyanazt a gondosságot érdemli.

Melyik illik a telepítéshez

Akkor válassza a hitelesítő fájlt, ha az egyetlen kérés a fiók páros, a kliens szolgáltatásként fut stabil tulajdonossal, és a 600-as fájlt olyan biztonsági mentéseken kívül tudja tartani, amelyeket nem ellenőriz. Akkor válassza a vezérlő socketet, ha kulcs jelmondata vagy PKCS#12 jelszó van játékban, ha a burkoló már felügyeli a folyamatot, vagy ha az állapotot és a kéréseket figyelnie kell egy újracsatlakozás hibakeresése közben.

Két feltétel mozdítja el a döntést. Ha a burkoló /bin/sh, egy systemd egység, amely közvetlenül hívja a binárist, vagy egy minimális konténer, akkor a csak bashhez való socketragasztó nem elérhető, és a fájl az olcsóbb válasz. Ha a titok gyakran rotálódik, egyik fájl sem jó otthon neki: kérdezzen kulcstartót egy kis burkolótól, és hagyja, hogy az egység a burkolót hívja, ami a rotációt egy helyen tartja, a jelszót pedig a shell előzményein kívül.

A folyamathelyettesítés a kettő között áll, és egyikhez sem tartozik. Az alábbi egysoros azért működik, mert a bash kiterjeszti, mielőtt az openvpn elindul, nem azért, mert a kliens érti a szintaxist:

openvpn --config client.ovpn --auth-user-pass <(printf "%s
%s
" "$USER" "$PASS")

Elromlik /bin/sh alatt, a shellt megkerülő egységben és bash vagy /dev/fd nélküli image-ekben. Tartsa meg interaktív tesztelésre, soha ne azként a szerződésként, amelytől egy szolgáltatás függ.

Védje a titkot, majd ellenőrizze a naplóból

Mindkét mechanizmus olvasható titkot hagy az OpenVPN folyamat számára. Soha ne tegye a jelszót a parancssorba vagy az egységfájlba, ahol a ps és a systemctl minden helyi felhasználónak megmutatja; a fájl elérési útját adja át, nem a benne lévő értéket. Ahol a tanúsítványok helyettesíthetik a fiók párost, az eltávolítja a kérés kategóriáját ahelyett, hogy elrejtené.

A helyes futás a kéréssorozat befejeződését és a munkamenet «Initialization Sequence Completed» elérését mutatja. Ha a kliens ugyanannál a kérésnél megáll, az egyeztetés meghiúsult: nyomtassa ki a socket által küldött pontos sorokat, ellenőrizze az idézőjeleket és a kérés nevét, és javítsa a mintát ahelyett, hogy sleepet adna hozzá. Az alagút, amely sikert jelent és semmit nem szállít, útvonal- vagy push-probléma, nem hitelesítő adat probléma.

Ezután tesztelje az újracsatlakozást, ne csak az első indítást. Dobja el a szerveroldali munkamenetet, vagy várja ki annak időtúllépését; a kliens újra kérdez, és ott mutatja meg az indításkor helyesnek tűnt fájl, hogy az újracsatlakozó fiók számára még olvasható-e.