Файл уліковых даных ці кіравальны сокет OpenVPN: што лепш скрыптаваць
auth-user-pass пакрывае запыт акаўнта; кіравальны сокет пакрывае ўсе чатыры. Параўнайце ўздзеянне, кошт скрыптавання і тое, як кожны падае ў службе.
Скрыпт, які запускае OpenVPN і ніколі не падключаецца, звычайна не з'яўляецца праблемай сеткі: кліент стаіць на запыце без тэрмінала, каб яго адлюстраваць. OpenVPN мае роўна два падтрыманыя спосабы адказаць на гэты запыт без чалавека: файл уліковых даных за auth-user-pass і кіравальны сокет, і яны не ўзаемазаменныя. Файл каштуе адну дырэктыву і адказвае на адзін запыт; сокет адказвае на кожны запыт і дае ўсяму, што можа адкрыць порт loopback, неаўтэнтыфікаваны канал кіравання. Які з іх належыць вашаму разгортванню, залежыць ад таго, які запыт фактычна блакуе, і ад таго, якую таямніцу вы можаце дазволіць сабе пакінуць у спакоі.
Назвіце запыт, перш чым выбіраць механізм
Чатыры запыты выглядаюць на тэрмінале аднолькава. Пара ўліковых даных прыходзіць з налады сервера PAM або auth-user-pass-verify і адказваецца праз auth-user-pass. Парольная фраза прыватнага ключа належыць файлу ключа і чытаецца праз --askpass або ўводзіцца ўручную. Пакет PKCS#12 запытвае ўласны пароль. Аўтэнтыфікацыя проксі выкарыстоўвае файл auth, які бярэ --http-proxy, а не ўліковыя даныя акаўнта.
Калі OpenVPN працуе як даччыны працэс systemd, PHP або Node, тэрмінала няма, таму любы з гэтых блакуе моўчкі. Працэс стаіць, журнал спыняецца пасля радка шыфра, і модуль урэшце выходзіць па тайм-аўце; гэтая цішыня — прычына, чаму людзі дадаюць цыкл паўтору або sleep замест таго, каб паглядзець, які запыт чакае. Толькі кіравальны сокет можа адказаць на ўсе чатыры. Файл уліковых даных адказвае на першы і ні на што больш.
auth-user-pass: адзін файл, адзін запыт
Файл змяшчае імя карыстальніка ў першым радку і пароль у другім, і нічога больш: без лапак, без імёнаў ключоў, без каментара. Усталюйце рэжым 600 і зрабіце ўладальнікам акаўнт, які запускае openvpn, а для службы гэта часта асобны карыстальнік, а не ваш лагін. Файл, які належыць root, пад /root — гэта розніца паміж камандай, што працуе ў вашай абалонцы, і модулем, які падае пры загрузцы.
Дзве дэталі ператвараюць правільны файл у запыт. Рэдактар, які захоўвае CRLF, пакідае вяртанне карэткі, прыклеенае да пароля, таму сервер адхіляе пароль, які ў файле выглядае правільным; правярайце праз cat -A або od -c, а не на вока. А auth-user-pass без аргумента ўнутры профілю азначае «спытаць карыстальніка» па задуме, і другая дырэктыва ў камандным радку можа гэтага не пераадолець, бо профіль разбіраецца там, дзе ён знаходзіцца.
Парадак опцый — трэцяя пастка, і ён залежыць ад версіі. Некаторыя зборкі OpenVPN 2.4 ігнаруюць --auth-user-pass, калі ён стаіць перад --config, таму тыя ж дзве опцыі ў іншым парадку падключаюцца. Змясціце дырэктыву ўнутры профілю або пасля --config у камандным радку і перад любымі іншымі зменамі праверце профіль пошукам кожнага ўваходжання.
auth-nocache належыць да гэтага механізму, але нічога не дае. Ён абмяжоўвае, як доўга кліент трымае ўліковыя даныя ў памяці, што дапамагае пасля збою і зусім не дапамагае, калі файла няма. Перападключэнне пасля тайм-аўту сесіі на баку сервера зноў чытае файл, таму ўліковыя даныя, якія працавалі пры загрузцы, могуць скончыцца пасярод дня.
Кіравальны сокет: кожны запыт, больш паверхні
Запусціце кліент са слухачом і яўна пакажыце, што запыты будуць паведамляцца на ім, выкарыстоўваючы дырэктывы, дакументаваныя ў кіраўніцтве OpenVPN 2.6:
management 127.0.0.1 3030
management-query-passwords
З bash трымайце злучэнне на зрэзным дэскрыптары файла і адказвайце па імені запыту, а не па пазіцыі, бо перападключэнне можа пытаць у іншым парадку:
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
Мяжа — гэта транспарт. Пратакол кіравання — адкрыты тэкст праз TCP на loopback, таму слухач не павінен публікавацца на адрасе LAN або тунэля, каб выдалены кантролер мог да яго дабрацца; выдалены кантролер азначае перанакіраванне SSH, а не шырэйшае прывязванне. Супольны дэман таксама прымае аднаго кліента кіравання за раз, таму GUI або манітор не могуць дзяліць сокет з вашым скрыптам. Другое злучэнне адхіляецца, а не ставіцца ў чаргу, і збой выглядае як скрыпт, які аглух.
Гэты сокет таксама канал кіравання. Без пароля кіравання ўсё, што можа падключыцца да 127.0.0.1:3030, можа чытаць статус, забіць тунэль або само адказаць на запыт. Пароль кіравання і файл уліковых даных — таямніцы аднаго класа, і абодва заслугоўваюць аднолькавай увагі.
Што падыходзіць разгортванню
Выбірайце файл уліковых даных, калі адзіны запыт — пара ўліковых даных, кліент працуе як служба са стабільным уладальнікам, і вы можаце трымаць файл 600 па-за рэзервовымі копіямі, якія не кантралюеце. Выбірайце кіравальны сокет, калі ў гульні парольная фраза ключа або пароль PKCS#12, калі абгортка ўжо наглядае за працэсам, або калі трэба назіраць стан і запыты, адладжваючы перападключэнне.
Дзве ўмовы рухаюць рашэнне. Калі абгортка — /bin/sh, модуль systemd, які выклікае бінарнік напрамую, або мінімальны кантэйнер, то клей для сокета толькі для bash недаступны, і файл — больш танны адказ. Калі таямніца часта круціцца, ні адзін файл не з'яўляецца добрым домам для яе: запытайце звязку ключоў з маленькай абгорткі і дайце модулю выклікаць абгортку, што трымае ратацыю ў адным месцы, а пароль — па-за гісторыяй абалонкі.
Падстаноўка працэсу стаіць паміж двума і не належыць ні аднаму. Аднарадковік ніжэй працуе, бо bash разгортвае яго да запуску openvpn, а не таму, што кліент разумее сінтаксіс:
openvpn --config client.ovpn --auth-user-pass <(printf "%s
%s
" "$USER" "$PASS")
Ён ламаецца пад /bin/sh, у модулі, які абынае абалонку, і ў вобразах без bash або /dev/fd. Трымайце яго для інтэрактыўнага тэсціравання, ніколі як кантракт, ад якога залежыць служба.
Абараніце таямніцу, потым праверце па журнале
Абодва механізмы пакідаюць таямніцу чытальнай для працэсу OpenVPN. Ніколі не змяшчайце пароль у камандны радок або ў файл модуля, дзе ps і systemctl паказваюць яго кожнаму лакальнаму карыстальніку; перадавайце шлях да файла, а не значэнне ўнутры яго. Там, дзе сертыфікаты могуць замяніць пару ўліковых даных, гэта выдаляе катэгорыю запыту, а не хавае яе.
Правільны запуск паказвае завяршэнне паслядоўнасці запытаў і дасягненне сесіяй «Initialization Sequence Completed». Калі кліент спыняецца на тым жа запыце, супастаўленне не ўдалося: надрукуйце дакладныя радкі, што даслаў сокет, праверце лапкі і імя запыту і выпраўце ўзор замест дадання sleep. Тунэль, які паведамляе пра поспех і нічога не нясе, — гэта праблема маршрутызацыі або push, а не ўліковых даных.
Затым праверце перападключэнне, а не толькі першы запуск. Скіньце сесію на баку сервера або дачакайцеся яе тайм-аўту; кліент спытае зноў, і менавіта там файл, які выглядаў правільным пры загрузцы, паказвае, ці ўсё яшчэ ён чытальны для акаўнта, які перападключаецца.