OpenVPN etimad faylı, yoxsa idarəetmə soketi: hansını skriptləşdirməli

OpenVPN-i işə salan və heç vaxt qoşulmayan skript adətən şəbəkə problemi deyil: müştəri terminalı olmayan bir sorğu qarşısında oturub. OpenVPN bu sorğunu insansız cavablandırmaq üçün tam iki dəstəklənən üsul təqdim edir: auth-user-pass arxasındakı etimad faylı və idarəetmə soketi, və onlar bir-birini əvəz etmir. Fayl bir direktivə başa gəlir və bir sorğuya cavab verir; soket hər sorğuya cavab verir və loopback portu aça bilən hər şeyə autentifikasiyasız nəzarət kanalı verir. Hansının yerləşdirmənizə aid olduğu faktiki olaraq hansı sorğunun blokladığından və hansı sirri istirahətdə saxlamağa imkanınız olduğundan asılıdır.

Mexanizm seçməzdən əvvəl sorğunu adlandırın

Dörd sorğu terminalda eyni görünür. Hesab cütü serverin PAM və ya auth-user-pass-verify quruluşundan gəlir və auth-user-pass ilə cavablandırılır. Şəxsi açar ifadəsi açar faylına aiddir və --askpass ilə oxunur və ya əl ilə yazılır. PKCS#12 paketi öz parolu istəyir. Proksi autentifikasiyası hesab etimadları deyil, --http-proxy-nin aldığı auth faylını istifadə edir.

OpenVPN systemd, PHP və ya Node uşağı kimi işləyəndə terminal yoxdur, ona görə bunlardan hər biri səssizcə bloklayır. Proses orada oturur, jurnal şifr sətrindən sonra dayanır və vahid nəhayət vaxt aşımına uğrayır; bu səssizlik insanların hansı sorğunun gözlədiyinə baxmaq əvəzinə yenidən cəhd dövrəsi və ya sleep əlavə etməsinin səbəbidir. Yalnız idarəetmə soketi dördünə cavab verə bilər. Etimad faylı birincisinə cavab verir, başqa heç nəyə.

auth-user-pass: bir fayl, bir sorğu

Fayl istifadəçi adını birinci sətirdə, parolu ikinci sətirdə saxlayır, başqa heç nə: dırnaq yox, açar adı yox, şərh yox. Rejimi 600 qoyun və sahibini openvpn-i işlədən hesab edin, bu xidmət üçün çox vaxt girişiniz deyil, ayrılmış istifadəçidir. /root altında root-a məxsus fayl qabığınızda işləyən əmr ilə yükləmədə uğursuz olan vahid arasındakı fərqdir.

İki detal düzgün faylı sorğuya çevirir. CRLF saxlayan redaktor parola yapışmış daşıma qaytarılması buraxır, beləliklə server faylda düzgün görünən parolu rədd edir; gözlə deyil, cat -A və ya od -c ilə yoxlayın. Profil daxilində arqumentsiz auth-user-pass isə dizayn üzrə «istifadəçidən soruş» deməkdir və əmr sətrindəki ikinci direktiv bunu üstələyə bilməz, çünki profil durduğu yerdə təhlil olunur.

Seçim sırası üçüncü tələdir və versiyadan asılıdır. Bəzi OpenVPN 2.4 buraxılışları --auth-user-pass-ı --config-dən əvvəl gələndə nəzərə almır, ona görə eyni iki seçim başqa sırada qoşulur. Direktivi profil daxilinə və ya əmr sətrində --config-dən sonra qoyun və başqa heç nəyi dəyişməzdən əvvəl profildə hər hadisəni grep edin.

auth-nocache bu mexanizmə aiddir, lakin heç nə təmin etmir. Müştərinin etimadı yaddaşda nə qədər saxladığını məhdudlaşdırır; bu qəzadan sonra kömək edir və fayl itdikdə heç kömək etmir. Server tərəfində sessiya vaxt aşımından sonra yenidən qoşulma faylı yenidən oxuyur, ona görə yükləmədə işləyən etimad günün ortasında da bitə bilər.

İdarəetmə soketi: hər sorğu, daha çox səth

Müştərini dinləyici ilə başladın və sorğuların onun üzərində bildiriləcəyini açıq şəkildə göstərin, OpenVPN 2.6 təlimatında sənədləşdirilmiş direktivlərdən istifadə edərək:

management 127.0.0.1 3030
management-query-passwords

bash-dən bağlantını ehtiyat fayl deskriptorunda saxlayın və mövqeyə görə deyil, sorğu adına görə cavab verin, çünki yenidən qoşulma fərqli sırada soruşa bilər:

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

Sərhəd nəqliyyatdır. İdarəetmə protokolu loopback üzərində TCP ilə açıq mətndir, ona görə dinləyici uzaq nəzarətçinin ona çatması üçün LAN və ya tunel ünvanında yayımlanmamalıdır; uzaq nəzarətçi daha geniş bağlama deyil, SSH yönləndirməsi deməkdir. İcma demonu da bir anda yalnız bir idarəetmə müştərisi qəbul edir, ona görə GUI və ya monitor soketi skriptinizlə paylaşa bilməz. İkinci bağlantı növbəyə qoyulmur, rədd edilir və nasazlıq kar olmuş skript kimi görünür.

Bu soket həm də nəzarət kanalıdır. İdarəetmə parolu olmadan 127.0.0.1:3030-a qoşula bilən hər şey statusu oxuya, tuneli öldürə və ya sorğuya özü cavab verə bilər. İdarəetmə parolu ilə etimad faylı eyni sinif sirdir və hər ikisi eyni qayğıya layiqdir.

Hansı yerləşdirməyə uyğundur

Etimad faylını yeganə sorğu hesab cütü olduqda, müştəri sabit sahiblə xidmət kimi işləyəndə və 600 faylını nəzarət etmədiyiniz ehtiyat nüsxələrdən kənarda saxlaya biləndə seçin. İdarəetmə soketini açar ifadəsi və ya PKCS#12 parolu iştirak edəndə, sarğı artıq prosesə nəzarət edəndə və ya yenidən qoşulmanı sazlayarkən status və sorğuları izləmək lazım olanda seçin.

İki şərt qərarı dəyişir. Sarğı /bin/sh-dirsə, binary-ni birbaşa çağıran systemd vahididirsə və ya minimal konteynerdirsə, yalnız bash üçün olan soket yapışqanı mövcud deyil və fayl daha ucuz cavabdır. Sirr tez-tez dövriyyə edirsə, heç bir fayl onun üçün yaxşı ev deyil: kiçik sarğıdan açar halqası sorğulayın və vahid sarğını çağırsın, bu dövriyyəni bir yerdə saxlayır və parolu qabıq tarixindən kənarda.

Proses əvəzləməsi ikisinin arasında dayanır və heç birinə aid deyil. Aşağıdakı bir sətir işləyir, çünki bash onu openvpn başlamazdan əvvəl genişləndirir, müştəri sintaksisi anladığı üçün deyil:

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

/bin/sh altında, qabığı yan keçən vahiddə və bash və ya /dev/fd olmayan obrazlarda pozulur. Onu interaktiv sınaq üçün saxlayın, heç vaxt xidmətin asılı olduğu müqavilə kimi deyil.

Sirri qoruyun, sonra jurnaldan yoxlayın

Hər iki mexanizm OpenVPN prosesinin oxuya biləcəyi sirr qoyur. Parolu heç vaxt əmr sətrinə və ya vahid faylına qoymayın, çünki ps və systemctl onu hər yerli istifadəçiyə göstərir; faylın yolunu ötürün, içindəki dəyəri deyil. Sertifikatlar hesab cütünü əvəz edə bildikdə, bu, sorğu kateqoriyasını gizlətmək əvəzinə aradan qaldırır.

Düzgün işləmə sorğu ardıcıllığının tamamlandığını və sessiyanın «Initialization Sequence Completed» səviyyəsinə çatdığını göstərir. Müştəri eyni sorğuda dayanırsa, uyğunluq uğursuz oldu: soketin göndərdiyi dəqiq sətirləri çap edin, dırnaqları və sorğu adını yoxlayın və sleep əlavə etmək əvəzinə nümunəni düzəldin. Uğur bildirən və heç nə daşımayan tunel marşrutlaşdırma və ya push problemidir, etimad problemi deyil.

Sonra yalnız ilk başlanğıcı deyil, yenidən qoşulmanı sınaqdan keçirin. Server tərəfindəki sessiyanı atın və ya vaxt aşımını gözləyin; müştəri yenidən soruşur və yükləmədə düzgün görünən faylın yenidən qoşulan hesab üçün hələ oxunaqlı olub-olmadığı məhz burada görünür.