openvpn3 session-start ігнаруе ваш файл уліковых даных

Падключыцеся кліентам 2.x — профіль працуе; аддайце той самы файл кліенту 3.x — і ён спыніцца на запыце пароля. Перадайце --auth-user-pass creds.txt камандзе openvpn3 session-start — вынік той самы, бо ў новым кліенце няма этапу, які чытае файл. Адмова наўмысная: уліковыя даныя належаць сесіі, а сесію стварае служба, а не працэс у вашым тэрмінале. Выбірайце паміж інтэрактыўным запытам і памочнікам аўтазагрузкі і ведайце, што кожны з іх захоўвае.

Чаму захаванаму файлу няма куды падзецца

У новым дызайне кіраванне канфігурацыяй і кіраванне сесіямі — гэта асобныя службы, якія размаўляюць праз сістэмную шыну. Менавіта гэтае раздзяленне дазваляе звычайнаму карыстальніку пачаць сесію без таго, каб прывілеяваны дэман чытаў за яго абаронены файл пароляў. Уліковыя даныя на аснове файлаў не маюць месца ў такой мадэлі, бо няма запуску на баку дэмана, які б іх чытаў. Адмова — гэта следства архітэктуры, а не адсутная функцыя.

Старую схему варта назваць, каб лягчэй было ад яе адвыкнуць: профіль спасылаецца на файл уліковых даных, і дэман чытае яго пры запуску тунеля. У новай мадэлі ўліковыя даныя належаць сесіі і падаюцца тады, калі гэтая сесія пачынаецца. openvpn3 session-start --config work.ovpn запытвае іх, а --auth-user-pass creds.txt адхіляецца, бо нішто на гэтым шляху не адкрыла б файл. Кожны рэцэпт для 2.x, які вы знойдзеце, мяркуе этап, якога ўжо няма.

Канфігурацыя і лакальныя налады сайта таксама раздзеленыя, і гэта тлумачыць другі сюрпрыз. Профіль можа выглядаць поўным, хаця злучэнне, якое ён дае, пазбаўлена канфігурацыі маршрутызацыі і рэзалвера. Гэтыя часткі ўжываюцца як лакальныя налады сайта, асобна ад імпартаванага файла.

Шлях запыту і сесія, якую ён пакідае

Падаць пароль пры пачатку сесіі — гэта і ёсць прадугледжаны працоўны працэс. Кліент запытвае адзін раз, перадае ўліковыя даныя ўнутранай частцы сесіі і працягвае:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

Гэтым шляхам на дыск нічога не запісваецца. Сесія таксама працягвае працаваць пасля закрыцця тэрмінала, што здзіўляе людзей, якія чакаюць, што працэс загіне разам з іх абалонкай. Менавіта ў гэтым сэнс пераносу кіравання сесіямі ў службу. Сесія жыве даўжэй за тэрмінал, які яе запытаў, і яе трэба спыняць яўна.

Для працоўнай станцыі з чалавекам перад ёй гэта таксама самы бяспечны варыянт, бо няма захаванага сакрэту, які трэба абараняць або забываць. Ён непрыдатны толькі там, дзе няма каму ўводзіць.

Аўтаматызацыя без чалавека за клавіятурай

Там, дзе машына мусіць падключацца без чалавека, праект пастаўляе openvpn3-autoload. Ён чытае каталог профіляў і адпаведны дэскрыптар для кожнага профілю, а дэскрыптар падае ўліковыя даныя адкрытым тэкстам. Памочнік — асобны бінарнік, звычайна ў /usr/sbin/openvpn3-autoload, а не сцяг каманды session-start. Наладзіць яго — значыць стварыць каталог, скапіяваць профіль пад імем, якога чакае дэскрыптар, і напісаць дэскрыптар.

Налада для асобнага карыстальніка выглядае так і выконваецца ад імя ўліковага запісу, які будзе валодаць сесіяй. Рэжым каталога не пускае іншых лакальных карыстальнікаў:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

Дэскрыптар называе ўліковыя даныя і запытвае аўтаматычны запуск. Трымайце значэнне пароля па-за кантролем версій:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

Затым выклічце памочнік адзін раз і пераканайцеся, што сесія з’явілася. Другая каманда — гэта праверка, а не яшчэ адзін крок налады:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

Пры загрузцы ўпакаваны юніт з імем openvpn3-autoload.service выкарыстоўвае сістэмны каталог /etc/openvpn3/autoload, а не каталог асобнага карыстальніка. Гэтае месца патрабуе ўласнасці root і больш строгага рэжыму, а дэскрыптар па-ранейшаму трымае пароль адкрытым тэкстам. Кампраміс відавочны: пароль цяпер ляжыць на дыску, таму стаўцеся да гэтага каталога як да сакрэту, выключайце яго з рэзервовых копій па-за хостам і выбірайце інтэрактыўны шлях, калі побач ёсць чалавек.

Збоі шыны, якія выглядаюць як збоі пароля

Некаторыя збоі, якія прыпісваюць уліковым даным, зусім не такія. Памылка правоў з указаннем шляху актывацыі службы азначае адно з двух: унутраная частка не запушчана або ў выклікальніка няма правоў яе актываваць. Ніякае рэдагаванне профілю гэтага не зменіць. Праверце стан службы і пастаўленую палітыку шыны, перш чым чапаць канфігурацыю.

Каманды ніжэй раздзяляюць гэтыя два выпадкі. Першая паведамляе, ці працуе ўнутраная частка; другая паказвае нядаўнія памылкі шыны:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

Іншае частае хібнае чытанне — сесія, якая з’яўляецца і адразу знікае. Такая карціна звычайна азначае, што лакальныя налады сайта ніколі не ўжываліся, таму тунель узняўся без маршрутаў і змен рэзалвера, якія робяць яго карысным. Чытайце паслядоўнасць, а не апошні радок: ці сесія была створана, ці дасягнула яна злучанага стану і ці выжыла яна — гэта тры асобныя факты.

Калі стары кліент яшчэ выкарыстоўваецца

Кліент 2.x па-ранейшаму прымае файл уліковых даных, і звязка ключоў можа адказаць на яго запыт так, што сакрэт ніколі не трапіць на дыск. Абгортка развязае запіс, таму файл называе пошук, а не пароль. Такая схема залежыць ад разблакаванай звязкі ключоў, чаго не можа даць кантэйнер без сеансу ўваходу або юніт, які запускаецца раней, чым хто-небудзь увойдзе. Тады інструмент пошуку паведамляе пра калекцыю, у якую не можа запісваць, і памылка выглядае як збой уліковых даных, хаця гэта збой звязкі ключоў.

Перш чым будаваць штосьці з гэтага, праверце, ці налада keepalive у профілі не здымае патрэбу ў перазапуску зусім. Сесія, якая трымаецца, ніколі не даходзіць да запыту, які вы спрабуеце аўтаматызаваць.