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 серверлерин окуй баштаңыз. Бул кийинки көйгөй жана анын жаңы эле оңдогон сырсөзгө эч кандай тиешеси жок.