OpenVPN auth-user-pass: fayl, stdin yoki so’rov? Qanday tanlash kerak

Qaysi hisob ma’lumot manbasidan foydalanishni uch narsa hal qiladi: konsolda odam o’tirganmi, sir diskda yashay oladimi va boshqa jarayon so’rovga javob berishi kerakmi. Noto’g’ri tanlasangiz, parol to’liq to’g’ri bo’lsa ham klient stdin muammosi haqida xabar beradi va bu ko’pchilikni sababsiz serverga yuboradi. Avval yo’lni tanlang; xato xabarlari faqat qaysi yo’l ularni keltirib chiqarganini bilganingizda ma’noga ega bo’ladi.

Buni hal qiladigan uch shart

Konsol so’rovi odamni talab qiladigan yagona yo’l, shuning uchun systemd birligi yoki konteynerda jimgina muvaffaqiyatsiz bo’ladigan yagona yo’l ham shu. Agar biror kishi klientni ishga tushirib parolni yozsa, hech qanday fayl ishtirok etmaydi va hech qanday nozik narsa diskka tushmaydi. Agar klient yuklanish vaqtida ishga tushsa, o’sha so’rov osilib qolishga aylanadi va vaqt tugashi odatda hisob ma’lumotlari xatosi emas, umumiy ulanish xatosi sifatida ko’rinadi.

Hisob ma’lumotlari fayli jarayon nazoratsiz ishga tushganda va sir nazorat qilinadigan ruxsatlar to’plami ostida diskda saqlanib qolishi mumkin bo’lganda to’g’ri javobdir. Sir umuman yozilmasligi kerak bo’lganda - faqat seyf siyosati, qisqa muddatli token - klient ocha oladigan oqim kerak, bu amalda jarayonni almashtirish yoki fayl deskriptoriga yozadigan yordamchi degani. Boshqaruv interfeysi to’rtinchi holatni qamrab oladi: tunnelning hayot aylanishini allaqachon boshqaradigan va savollarga soket orqali javob bera oladigan kontroller.

• Konsolda odam, avtomatlashtirish yo’q: interaktiv so’rov.
• Nazoratsiz ishga tushirish, sirni saqlash mumkin: 0600 rejimli hisob ma’lumotlari fayli.
• Nazoratsiz ishga tushirish, sirni saqlash mumkin emas: jarayonni almashtirish yoki sir agenti yozadigan fd.
• Klient boshqa jarayonga tegishli: boshqaruv interfeysi.

Ikki javob mos kelganda, sirni argv va shell tarixidan tashqarida saqlaydiganini tanlang. Dastur argumenti sifatida berilgan parolni har qanday mahalliy foydalanuvchi jarayonlar ro’yxati orqali o’qiy oladi va bu oshkorlikni qaytarish qiyin.

Har bir kirish yo’li aslida nima qiladi

--auth-user-pass yakka o’zi konsolda foydalanuvchi nomi va parolni so’raydi. Fayl nomi berilsa, klient birinchi qatorni foydalanuvchi nomi, ikkinchi qatorni parol sifatida oladi; hech narsa qo’shtirnoq, izoh yoki kalit-qiymat sintaksisini qo’llab-quvvatlamaydi. Butun format shu, shuning uchun INI faylini kutib tahrirlagan har kim uni buzadi. Ichki <auth-user-pass> bloki o’sha ikki qatorni profil ichida saqlaydi, bu profilning o’zini sirga aylantiradi va uni shaxsiy kalit bilan bir xil ishlov sinfiga qo’yadi.

Qolgan ikki yo’l - oqim va soket. OpenVPN ga faqat o’qiladigan fayl deskriptori kerak, shuning uchun u jarayonni almashtirishni, quvur bilan qo’llab-quvvatlanadigan /dev/fd yozuvini yoki aslida FIFO bo’lgan fayl nomini qabul qiladi. Boshqaruv interfeysi tabiatan boshqacha: klient qiymatlarni o’zi o’qish o’rniga nazoratchi jarayondan so’raydi. Bu farq qayta ulanishda muhim: hisob ma’lumotlari fayli, sir yordamchisi qayta yozishi mumkin bo’lgan FIFO va boshqaruv interfeysi odamsiz qayta taqdim eta oladi; jarayonni almashtirish esa yo’q, chunki deskriptor birinchi o’qishda sarflanadi.

Fayl aynan ikki qatordan iborat bo’lishi kerak

Buzilgan hisob ma’lumotlari fayllarining ko’p qismini ikki nosozlik rejimi qamrab oladi. Windows muharriri CRLF oxirlarini qoldiradi, vagon qaytishi parolning qismiga aylanadi va server ekranda to’g’ri ko’rinadigan qiymatni rad etadi. Bo’sh ikkinchi qator - parol bo’lishi kerak joyda bo’sh qator - klientni bo’sh parol bilan qoldiradi, ekrandagi qiymat to’g’ri ko’rinsa ham server uni rad etadi. Paroldan keyingi ortiqcha yangi qator zararsiz. Faylni muharrirdan emas, shell’dan yozing va baytlarni tekshiring:

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

Yo’l mazmun kabi muhim. Nisbiy yo’l jarayonning ish katalogiga nisbatan hal qilinadi, u xizmat uchun kamdan-kam siz sinab ko’rgan katalog bo’ladi. Mutlaq yo’ldan foydalaning, faylni klientni ishga tushiruvchi hisob egaligiga aylantiring va guruh hamda boshqalar o’qiy olmasligi uchun 0600 rejimini saqlang. OpenVPN 2.6 qo’llanmasi direktivaning qabul qilingan shakllarini sanab o’tadi; uchinchisini o’ylab topishdan oldin uni ko’zdan kechiring.

Serverni ayblashdan oldin faylni sinab ko’ring. openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 ni ishga tushirish fayl ochilganmi va keyin hisob ma’lumotlari qabul qilinganmi - shuni chop etadi, bu keyingi qaysi qatlamni o’zgartirishni aytadi.

Oqimlar, stdin va ular keltirib chiqaradigan xatolar

Parolni quvurga berish ko’pchilik birinchi sinab ko’radigan narsa va eng ko’p syurprizli yo’l. Jarayonni almashtirish ishlaydi, chunki klientga faqat o’qiladigan deskriptor kerak: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin ni uzatish faqat klient so’ragan paytda stdin hali ochiq va o’qiladigan bo’lsa ishlaydi, uni allaqachon sarflagan quvurda bu to’g’ri emas.

ERROR: could not read Auth username from stdin ning ikki xil sababi bor. Ba’zi 2.3.x klientlarda xabar keyingi 2.3 chiqimlari tuzatgan stdin bilan ishlash nuqsonidan kelgan, shuning uchun shuncha eski klient faqat yangilash bilan yaxshilanadi. Hozirgi klientda o’sha ibora klient konsol kiritishini so’ragani va stdin terminal bo’lmaganini bildiradi - aynan systemd birligi, cron vazifasi yoki -t siz ishga tushirilgan konteynerdagi holat.

auth-nocache buzilgan parolga o’xshab ko’rinadigan uchinchi sikl qo’shadi. U ishlatilgandan keyin hisob ma’lumotlarini xotiradan tashlaydi, shuning uchun tarmoq o’zgarishi sabab bo’lgan qayta ulanishda qayta ijro etadigan narsa qolmaydi va so’rov qaytadi. Bu loyihalashtirilganidek ishlaydigan direktiva. auth-nocache klient xotirada nima saqlashini o’zgartiradi, server yoki identifikatsiya provayderi hisob haqida nimani o’ylashini emas, shuning uchun butun tuzatish o’sha faylni qayta taqdim etishdir, u qayta ishga tushirishda qayta o’qiladi - boshqariladigan ulanish uchun esa bu taqdimot tasdiqlangan sir omboridan kelishi kerak, skriptdagi paroldan emas.

So’rov boshqa jarayonga tegishli bo’lganda boshqaruv interfeysi

Tunnelni allaqachon nazorat qilayotgan kontroller uning savollariga ham javob bera oladi. Klientni --management 127.0.0.1 7505 bilan ishga tushiring, holat qatorlarini o’qing va >PASSWORD:Need 'Auth' username/password ni kuzating. Kontroller alohida buyruq qatorlarida username "Auth" alice va keyin password "Auth" ... bilan javob beradi. 'Auth' tokeni so’rovdagi identifikatorni takrorlaydi va mos kelishi shart, aks holda javob e’tiborsiz qoldiriladi va klient kutadi.

Narx - endi sizga tegishli holat mashinasi: ulanishlar tartibi, klientni qayta ishga tushirishlar va xostdagi boshqa foydalanuvchilar yetib bormasligi kerak bo’lgan mahalliy soket. Siz sotib oladigan narsa - ish vaqtida taqdim etiladigan hisob ma’lumotlari, diskda faylsiz va osilib qolishi mumkin bo’lgan so’rovsiz. Agar stekingizda boshqa hech narsa bu protokolni allaqachon gapirmasa, bu yo’l parvarish talab qiladigan komponent qo’shadi.

Hisob ma’lumotlari muammosiga o’xshab ko’rinadigan nosozliklar

Hech qachon tugamaydigan TLS qo’l berishishi yoki VERIFY ERROR: depth=0, error=certificate signature failure ishonch muammosi bo’lib, har qanday foydalanuvchi nomi o’qilishidan oldin sodir bo’ladi. UDP tinglovchisiga qaratilgan proto tcp klienti ham o’sha joyda muvaffaqiyatsiz bo’ladi: paketlar hech qachon autentifikatsiya bosqichiga yetib bormaydi, shuning uchun har bir parol bog’lanish tufayli noto’g’ri ko’rinadi. Hisob ma’lumotlarini yuborishdan oldin sertifikat tekshiruvini yoqib turing; tanish so’rov parolni kim olishi haqida hech narsa aytmaydi. Hisob ma’lumotlariga tegishdan oldin sertifikat zanjiri, umumiy nom va transportni tekshiring.

Profilni yig’adigan skriptdagi shell xatolari ikkinchi yolg’on iz. [ ! -f "$file" ] ichidagi yo’qolgan bo’sh joy command not found ni hosil qiladi, skript erta to’xtaydi, profil hech qachon qayta qurilmaydi va klient oldingisi bilan ishga tushadi. Bu xato shell’ga tegishli, autentifikatsiyaga emas va parolni necha marta qayta yozsangiz ham u o’chmaydi.

Bu oqimdagi har bir so’rov bu hisob ma’lumotlari emas. Shaxsiy kalit parol iborasi, HTTP proksi orqali kirish va xizmat paroli turli bosqichlarda so’raladigan uch xil sirdir va kalit parol iborasini odatda auth-user-pass emas, klient yoki agent boshqaradi. Agar so’rov TLS seansi o’rnatilishidan oldin paydo bo’lsa, siz noto’g’ri savolga javob bermoqdassiz va hech qanday hisobni tiklash yordam bermaydi. Noto’g’ri so’rov chiqarib tashlangach, qolgan tekshiruvlar eng erta qatlamdan boshlanadi:

• Oxirgi hisob ma’lumotlari qatorini emas, birinchi protokol xatosini o’qing: TLS, keyin autentifikatsiya, keyin push.
• Fayl ikki qatordan iboratligini, vagon qaytishlari yo’qligini va mutlaq yo’l bilan ko’rsatilganini tasdiqlang.
• Profil va buyruq qatori direktiva haqida kelishmasligini tasdiqlang.
• "Hisob ma’lumotlari qabul qilindi" ni "trafik oqmoqda" dan ajrating - marshrutlash va DNS keyingi qatlam.

Klient push bosqichiga yetganda hisob ma’lumotlariga qarashni to’xtating va server yuborgan marshrutlar hamda DNS serverlarini o’qishni boshlang. Bu keyingi muammo va hozir tuzatgan parolingizga hech qanday aloqasi yo’q.