OpenVPN auth-user-pass: fayl, stdin yoxsa interaktiv sorğu? Necə seçməli

Hansı etimad mənbəyini istifadə edəcəyinizi üç şey həll edir: konsolda adam oturubmu, sirr diskdə yaşaya bilərmi və sorğuya başqa proses cavab verməlidirmi. Seçimi səhv etsəniz, parol tamamilə düzgün olduğu halda klient stdin problemi bildirir və bu, çoxlarını heç bir səbəb olmadan serverə yönəldir. Əvvəlcə yolu seçin; xəta mesajları yalnız hansı yolun onları doğurduğunu bildikdən sonra məna kəsb edir.

Qərarı verən üç şərt

Konsol sorğusu insan tələb edən yeganə yoldur, ona görə də systemd unitində və ya konteynerdə səssizcə uğursuz olan yeganə yoldur. Əgər adam klienti başladıb parolu yazırsa, heç bir fayl iştirak etmir və diskə həssas heç nə düşmür. Əgər klient yüklənmə zamanı başlayırsa, həmin sorğu donmaya çevrilir və taym-aut adətən etimad xətası kimi deyil, ümumi bağlantı xətası kimi görünür.

Etimad faylı proses nəzarətsiz başladıqda və sirrin nəzarətli icazə dəsti altında diskdə qalması mümkün olduqda düzgün cavabdır. Sirri ümumiyyətlə yazmaq mümkün olmadıqda - yalnız seyf siyasəti, qısamüddətli token - klientin aça biləcəyi axın lazımdır, bu da praktikada proses əvəzləməsi və ya fayl deskriptoruna yazan köməkçi deməkdir. İdarəetmə interfeysi dördüncü halı əhatə edir: tunelin həyat dövrünü artıq idarə edən və suallara soket üzərindən cavab verə bilən nəzarətçi.

• Konsolda insan, avtomatlaşdırma yoxdur: interaktiv sorğu.
• Nəzarətsiz başlanğıc, sirr saxlana bilər: 0600 rejimli etimad faylı.
• Nəzarətsiz başlanğıc, sirr saxlanıla bilməz: proses əvəzləməsi və ya sirr agentinin yazdığı fd.
• Klienti başqa prosesə məxsusdur: idarəetmə interfeysi.

İki cavab uyğun gəldikdə, sirri argv-dən və shell tarixçəsindən kənarda saxlayanı seçin. Proqram arqumenti kimi ötürülən parolu istənilən yerli istifadəçi proses siyahısı vasitəsilə oxuya bilər və bu məruz qalmanı geri qaytarmaq çətindir.

Hər giriş yolu əslində nə edir

--auth-user-pass təkbaşına konsolda istifadəçi adı və parol istəyir. Fayl adı verildikdə klient birinci sətri istifadəçi adı, ikinci sətri parol kimi götürür; sitat, şərh və ya açar-dəyər sintaksisi dəstəklənmir. Format tamamilə budur, ona görə də INI faylı gözləyərək onu redaktə edən hər kəs onu pozur. Daxili <auth-user-pass> bloku profilin içində eyni iki sətri saxlayır, bu da profilin özünü sirrə çevirir və onu şəxsi açarla eyni idarəetmə sinfinə qoyur.

Digər iki yol axın və soketdir. OpenVPN yalnız oxuna bilən fayl deskriptoruna ehtiyac duyur, ona görə də proses əvəzləməsini, boru ilə dəstəklənən /dev/fd girişini və ya əslində FIFO olan fayl adını qəbul edəcək. İdarəetmə interfeysi mahiyyətcə fərqlidir: klient dəyərləri özü oxumaq əvəzinə nəzarət edən prosesdən soruşur. Bu fərq yenidən qoşulmada vacibdir: etimad faylı, sirr köməkçisinin yenidən yaza bildiyi FIFO və idarəetmə interfeysi insan olmadan yenidən təmin edə bilər; proses əvəzləməsi isə bilməz, çünki deskriptor ilk oxunuşda tükənir.

Fayl mütləq iki sətirdən ibarət olmalıdır

İki uğursuzluq rejimi pozulmuş etimad fayllarının çoxunu əhatə edir. Windows redaktoru CRLF sonluqları qoyur, daşıma qaytarılması parolun bir hissəsinə çevrilir və server ekranda düzgün görünən dəyəri rədd edir. Boş ikinci sətir - parolun olmalı olduğu yerdə boş sətir - klienti boş parolla qoyur və server ekrandakı dəyər doğru görünsə də onu rədd edir. Paroldan sonra əlavə sətir zərərsizdir. Faylı redaktordan deyil, shell-dən yazın və baytları yoxlayın:

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

Yol məzmun qədər vacibdir. Nisbi yol prosesin iş qovluğuna görə həll olunur, bu da xidmət üçün nadir hallarda sınaq keçirdiyiniz qovluq olur. Mütləq yoldan istifadə edin, faylı klienti işlədən hesaba məxsus edin və 0600 rejimini saxlayın ki, qrup və digərləri onu oxuya bilməsin. OpenVPN 2.6 təlimatı direktivin qəbul edilən formalarını sadalayır; üçüncü forma icad etməzdən əvvəl ona baxın.

Serveri günahlandırmazdan əvvəl faylı sınayın. openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 işlətmək faylın açılıb-açılmadığını və sonra etimad məlumatlarının qəbul edilib-edilmədiyini çap edir, bu da növbəti hansı qatı dəyişməli olduğunuzu bildirir.

Axınlar, stdin və onların doğurduğu xətalar

Parolu boru ilə ötürmək çoxlarının ilk cəhd etdiyi şeydir və ən çox sürpriz olan yoldur. Proses əvəzləməsi işləyir, çünki klientə yalnız oxuna bilən deskriptor lazımdır: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin ötürmək yalnız klient soruşduğu anda stdin hələ açıq və oxuna bilən olduqda işləyir, bu da onu artıq istehlak etmiş boru xəttində doğru deyil.

ERROR: could not read Auth username from stdin iki fərqli səbəbə malikdir. Bəzi 2.3.x klientlərində mesaj stdin emalındakı qüsurdan gəlirdi və sonrakı 2.3 buraxılışları onu düzəltdi, ona görə də bu qədər köhnə klient yalnız yüksəltməklə yaxşılaşır. Müasir klientdə eyni ifadə klientin konsol girişi istədiyini və stdin-in terminal olmadığını bildirir - məhz systemd unitində, cron tapşırığında və ya -t olmadan başladılmış konteynerdəki vəziyyət.

auth-nocache pozulmuş parol kimi görünən üçüncü dövrə əlavə edir. İstifadədən sonra etimad məlumatlarını yaddaşdan atır, ona görə şəbəkə dəyişikliyinin tətiklədiyi yenidən qoşulmanın təkrar oynadacağı heç nə qalmır və sorğu qayıdır. Bu, direktivin dizaynla işləməsidir. auth-nocache klientin yaddaşda saxladığını dəyişir, serverin və ya kimlik provayderinin hesab haqqında düşündüyünü deyil, ona görə də bütün düzəliş eyni faylı yenidən təmin etməkdir, yenidən başlatmada yenidən oxunur - və idarə olunan bağlantı üçün bu təminat təsdiqlənmiş sirr anbarından gəlməlidir, skriptdəki paroldan deyil.

Sorğu başqa prosesə məxsus olduqda idarəetmə interfeysi

Tunelə artıq nəzarət edən nəzarətçi onun suallarına da cavab verə bilər. Klienti --management 127.0.0.1 7505 ilə başladın, vəziyyət sətirlərini oxuyun və >PASSWORD:Need 'Auth' username/password gözləyin. Nəzarətçi ayrı əmr sətirlərində username "Auth" alice və ardınca password "Auth" ... ilə cavab verir. 'Auth' tokeni sorğudakı identifikatoru əks etdirir və uyğun gəlməlidir, əks halda cavab nəzərə alınmır və klient gözləyir.

Xərc artıq sizə məxsus olan vəziyyət maşınıdır: bağlantı sırası, klient yenidən başlatmaları və hostdakı digər istifadəçilərin çatmamalı olduğu yerli soket. Aldığınız isə işləmə vaxtı təmin edilən etimad məlumatıdır, diskdə fayl yoxdur və dona biləcək sorğu yoxdur. Əgər texnologiya stekinizdə başqa heç nə artıq protokolu danışmırsa, bu yol saxlanmalı bir komponent əlavə edir.

Etimad problemi kimi görünən nasazlıqlar

Heç vaxt tamamlanmayan TLS əl sıxışması və ya VERIFY ERROR: depth=0, error=certificate signature failure etimad problemidir və hər hansı istifadəçi adı oxunmazdan əvvəl baş verir. UDP dinləyicisinə yönəldilmiş proto tcp klienti də eyni yerdə uğursuz olur: paketlər autentifikasiya mərhələsinə heç vaxt çatmır, ona görə hər parol assosiasiya yolu ilə səhv görünür. Etimad məlumatı göndərilməzdən əvvəl sertifikat yoxlamasını açıq saxlayın; tanış sorğu parolu kimin aldığı barədə heç nə demir. Etimad məlumatına toxunmazdan əvvəl sertifikat zəncirini, ümumi adı və nəqli yoxlayın.

Profili yığan skriptdəki shell xətaları digər yanlış izdir. [ ! -f "$file" ] daxilində çatışmayan boşluq command not found doğurur, skript erkən dayanır, profil heç vaxt yenidən qurulmur və klient əvvəlki ilə başlayır. Bu xəta autentifikasiyaya deyil, shell-ə aiddir və parolu nə qədər yenidən yazsanız da onu silməz.

Bu axındakı hər sorğu bu etimad məlumatı deyil. Şəxsi açarın parol ifadəsi, HTTP proksi girişi və xidmət parolu müxtəlif mərhələlərdə istənilən üç fərqli sirrdir və açar parol ifadəsini adətən auth-user-pass deyil, klient və ya agent idarə edir. Əgər sorğu TLS sessiyası qurulmazdan əvvəl görünürsə, səhv suala cavab verirsiniz və heç bir hesab sıfırlaması kömək etməyəcək. Səhv sorğu istisna edildikdən sonra qalan yoxlamalar ən erkən qatdan başlayır:

• Son etimad sətrini deyil, ilk protokol xətasını oxuyun: TLS, sonra autentifikasiya, sonra push.
• Faylın iki sətir olduğunu, daşıma qaytarılmalarının olmadığını və mütləq yolla göstərildiyini təsdiqləyin.
• Profil ilə əmr sətrinin direktiv barədə ziddiyyət təşkil etmədiyini təsdiqləyin.
• "Etimad məlumatları qəbul edildi" ilə "trafik axır"ı ayırın - marşrutlaşdırma və DNS sonrakı qatdır.

Klient push mərhələsinə çatdıqda etimad məlumatlarına baxmağı dayandırın və serverin göndərdiyi marşrutları və DNS serverlərini oxumağa başlayın. Bu, növbəti problemdir və təzəcə düzəltdiyiniz parolla heç bir əlaqəsi yoxdur.