OpenVPN auth-user-pass: файл, stdin әлде сұрау ма? Қалай таңдау керек

Қай тіркелгі деректері көзін пайдалану керектігін үш нәрсе шешеді: консольде адам отыр ма, құпия дискіде өмір сүре ала ма және басқа процесс сұрауға жауап беруі керек пе. Қате таңдасаңыз, клиент stdin мәселесін хабарлайды, ал құпиясөз толығымен жарамды болады, бұл көпшілікті себепсіз серверге жібереді. Алдымен жолды таңдаңыз; қате хабарлары қай жол оларды тудырғанын білгенде ғана мағыналы болады.

Мұны шешетін үш шарт

Консоль сұрауы адамды қажет ететін жалғыз жол, сондықтан ол systemd бірлігінде немесе контейнерде үнсіз сәтсіздікке ұшырайтын жалғыз жол. Егер адам клиентті іске қосып, құпиясөзді терсе, ешбір файл қатыспайды және ешбір құпия дискіге түспейді. Егер клиент жүктелу кезінде іске қосылса, сол сұрау тоқтап қалуға айналады, ал уақыт шегі әдетте тіркелгі деректерінің қатесі емес, жалпы қосылым ақауы ретінде көрінеді.

Тіркелгі деректерінің файлы процесс қадағалаусыз іске қосылғанда және құпия бақыланатын рұқсаттар жиынтығы астында дискіде қала алғанда дұрыс жауап болып табылады. Құпияны мүлдем жазуға болмайтын кезде - тек қойма саясаты, қысқа мерзімді токен - клиент аша алатын ағын керек, бұл іс жүзінде процесті ауыстыру немесе файл дескрипторына жазатын көмекші дегенді білдіреді. Басқару интерфейсі төртінші жағдайды қамтиды: туннельдің өмірлік циклін әлдеқашан басқаратын және сұрақтарға сокет арқылы жауап бере алатын контроллер.

• Консольде адам, автоматтандыру жоқ: интерактивті сұрау.
• Қадағалаусыз іске қосу, құпияны сақтауға болады: режимі 0600 тіркелгі деректерінің файлы.
• Қадағалаусыз іске қосу, құпияны сақтауға болмайды: процесті ауыстыру немесе құпия агенті жазатын fd.
• Клиентті басқа процесс иеленеді: басқару интерфейсі.

Екі жауап сәйкес келсе, құпияны argv-ден және shell тарихынан тыс ұстайтынды таңдаңыз. Бағдарлама аргументі ретінде берілген құпиясөзді кез келген жергілікті пайдаланушы процестер тізімі арқылы оқи алады, және бұл әшкерелеуді кері қайтару қиын.

Әр кіру жолы шын мәнінде не істейді

--auth-user-pass өздігінен консольде пайдаланушы аты мен құпиясөзді сұрайды. Файл аты берілсе, клиент бірінші жолды пайдаланушы аты, екінші жолды құпиясөз ретінде алады; ешнәрсе тырнақшаларды, түсініктемелерді немесе кілт-мән синтаксисін қолдамайды. Бұл бүкіл формат, сондықтан INI файлын күтіп оны өңдейтін адам оны бұзады. Кіріктірілген <auth-user-pass> блогы профиль ішінде сол екі жолды ұстайды, бұл профильдің өзін құпия етеді және оны жеке кілтпен бірдей өңдеу класына қояды.

Қалған екі жол - ағын мен сокет. OpenVPN тек оқылатын файл дескрипторын қажет етеді, сондықтан ол процесті ауыстыруды, құбырмен қамтамасыз етілген /dev/fd жазбасын немесе шын мәнінде FIFO болатын файл атын қабылдайды. Басқару интерфейсі табиғаты бойынша өзгеше: клиент мәндерді өзі оқудың орнына қадағалаушы процестен сұрайды. Бұл айырмашылық қайта қосылу кезінде маңызды: тіркелгі деректерінің файлы, құпия көмекшісі қайта жаза алатын FIFO және басқару интерфейсі адамсыз қайта жеткізе алады; процесті ауыстыру мұны істей алмайды, өйткені дескриптор бірінші оқуда таусылады.

Файл дәл екі жолдан тұруы керек

Бүлінген тіркелгі деректері файлдарының көбін екі ақау режимі қамтиды. Windows редакторы CRLF аяқтарын қалдырады, вагонның қайтарылуы құпиясөздің бөлігіне айналады, ал сервер экранда дұрыс көрінетін мәнді қабылдамайды. Бос екінші жол - құпиясөз тұруы керек жердегі бос жол - клиентті бос құпиясөзбен қалдырады, сервер экрандағы мән дұрыс көрінсе де оны қабылдамайды. Құпиясөзден кейінгі қосымша жаңа жол зиянсыз. Файлды редактордан емес, shell-ден жазыңыз және байттарды тексеріңіз:

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

Жол мазмұн сияқты маңызды. Салыстырмалы жол процесс жұмыс каталогына қатысты шешіледі, ал қызмет үшін бұл сирек сынақ жүргізген каталог болады. Абсолютті жолды пайдаланыңыз, файлды клиентті іске қосатын тіркелгінің меншігіне айналдырыңыз және топ пен басқалар оны оқи алмауы үшін 0600 режимін сақтаңыз. OpenVPN 2.6 нұсқаулығы директиваның қабылданатын нысандарын тізімдейді; үшіншісін ойлап таппас бұрын оны тексеріңіз.

Серверді кінәламас бұрын файлды сынап көріңіз. openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 іске қосу файлдың ашылып-ашылмағанын және кейінірек тіркелгі деректерінің қабылданғанын басып шығарады, бұл келесі қай қабатты өзгерту керектігін айтады.

Ағындар, stdin және олар тудыратын қателер

Құпиясөзді құбырға жіберу - көпшілік ең алдымен байқап көретін нәрсе және ең көп тосынсыйы бар жол. Процесті ауыстыру жұмыс істейді, өйткені клиентке тек оқылатын дескриптор керек: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin жіберу клиент сұраған сәтте stdin әлі ашық және оқылатын болғанда ғана жұмыс істейді, ал оны әлдеқашан тұтынып қойған құбырда бұл дұрыс емес.

ERROR: could not read Auth username from stdin екі түрлі себепке ие. Кейбір 2.3.x клиенттерінде хабар stdin өңдеу ақауынан шыққан, оны кейінгі 2.3 шығарылымдары түзеткен, сондықтан соншалықты ескі клиент тек жаңарту арқылы жақсарады. Қазіргі клиентте сол тұжырым клиент консоль енгізуін сұрағанын және stdin терминал болмағанын білдіреді - дәл systemd бірлігіндегі, cron тапсырмасындағы немесе -t-сіз іске қосылған контейнердегі жағдай.

auth-nocache бүлінген құпиясөзге ұқсайтын үшінші циклді қосады. Ол пайдаланғаннан кейін тіркелгі деректерін жадтан лақтырады, сондықтан желі өзгерісі тудырған қайта қосылымда қайталайтын ештеңе болмайды және сұрау қайта оралады. Бұл жобаланғандай жұмыс істейтін директива. auth-nocache клиенттің жадта ұстайтынын өзгертеді, сервердің немесе сәйкестендіру провайдерінің тіркелгі туралы ойын емес, сондықтан бүкіл түзету - сол файлды қайта жеткізу, ол қайта іске қосу кезінде қайта оқылады - ал басқарылатын қосылым үшін бұл жеткізу бекітілген құпия қоймасынан келуі керек, скрипттегі құпиясөзден емес.

Сұрауды басқа процесс иеленген кездегі басқару интерфейсі

Туннельді әлдеқашан қадағалайтын контроллер оның сұрақтарына да жауап бере алады. Клиентті --management 127.0.0.1 7505 арқылы іске қосыңыз, күй жолдарын оқыңыз және >PASSWORD:Need 'Auth' username/password белгісін бақылаңыз. Контроллер жеке командалық жолдарда username "Auth" alice және одан кейін password "Auth" ... арқылы жауап береді. 'Auth' токені сұраудағы идентификаторды қайталайды және сәйкес келуі керек, әйтпесе жауап еленбейді және клиент күтеді.

Бағасы - енді сізге тиесілі күй машинасы: қосылым реті, клиентті қайта іске қосулар және хосттағы басқа пайдаланушылар жетпеуі тиіс жергілікті сокет. Сіз сатып алатын нәрсе - орындалу уақытында жеткізілген тіркелгі деректері, дискіде файлсыз және ілініп қалуы мүмкін сұраусыз. Егер стектегі басқа ештеңе бұл протоколды білмесе, бұл жол күтіп ұстауға қажет құрамдас қосады.

Тіркелгі деректерінің мәселесіне ұқсайтын ақаулар

Ешқашан аяқталмайтын TLS қол алысуы немесе VERIFY ERROR: depth=0, error=certificate signature failure сенім мәселесі болып табылады және кез келген пайдаланушы аты оқылмай тұрып орын алады. UDP тыңдаушысына бағытталған proto tcp клиенті де сол жерде сәтсіздікке ұшырайды: пакеттер аутентификация кезеңіне ешқашан жетпейді, сондықтан әрбір құпиясөз байланыс арқылы қате болып көрінеді. Тіркелгі деректері жіберілмес бұрын сертификатты тексеруді қосулы ұстаңыз; таныс сұрау құпиясөзді кім алатыны туралы ештеңе айтпайды. Тіркелгі деректеріне тимес бұрын сертификат тізбегін, жалпы атауды және тасымалды тексеріңіз.

Профильді құрастыратын скрипттегі shell қателері - екінші жалған із. [ ! -f "$file" ] ішіндегі жетіспейтін бос орын command not found тудырады, скрипт ерте тоқтайды, профиль ешқашан қайта құрылмайды және клиент алдыңғысымен іске қосылады. Бұл қате аутентификацияға емес, shell-ге тиесілі, және құпиясөзді қанша рет қайта терсеңіз де ол кетпейді.

Бұл ағындағы әрбір сұрау бұл тіркелгі деректері емес. Жеке кілттің құпиясөзі, HTTP проксиге кіру және қызметтің құпиясөзі - әртүрлі кезеңдерде сұралатын үш түрлі құпия, ал кілт құпиясөзін әдетте auth-user-pass емес, клиент немесе агент өңдейді. Егер сұрау TLS сессиясы орнамай тұрып пайда болса, сіз қате сұраққа жауап беріп жатырсыз және тіркелгіні қалпына келтіру көмектеспейді. Қате сұрау алынып тасталғаннан кейін қалған тексерулер ең ерте қабаттан басталады:

• Соңғы тіркелгі деректері жолын емес, бірінші протокол қатесін оқыңыз: TLS, содан кейін аутентификация, содан кейін push.
• Файлдың екі жол екенін, вагон қайтарылымдары жоқ екенін және абсолютті жолмен сілтелетінін растаңыз.
• Профиль мен командалық жолдың директива туралы келіспейтінін растаңыз.
• "Тіркелгі деректері қабылданды" мен "трафик ағады"ны ажыратыңыз - маршруттау мен DNS кейінгі қабат.

Клиент push кезеңіне жеткенде, тіркелгі деректеріне қарауды доғарып, сервер жіберген маршруттар мен DNS серверлерін оқи бастаңыз. Бұл келесі мәселе және оның жаңа ғана түзеткен құпиясөзге қатысы жоқ.