openvpn3 session-start ја игнорира датотеката со податоци за најава

3.x клиентот ги зема податоците за најава на почетокот на сесијата и не чита зачувана датотека. Користете го барањето или патеката autoload и знајте што чува секое од нив.

Поврзете се со 2.x клиентот и профилот работи; предадете ја истата датотека на 3.x клиентот и тој запира на барањето за лозинка. Предадете --auth-user-pass creds.txt на openvpn3 session-start и резултатот е ист, бидејќи поновиот клиент нема фаза што ја чита датотеката. Одбивањето е намерно: податоците за најава и припаѓаат на сесијата, а сесијата ја создава услуга, а не процесот во вашиот терминал. Изберете меѓу интерактивното барање и autoload помошникот и знајте што чува секое.

Зошто зачуваната датотека нема каде да оди

Во поновиот дизајн, управувањето со конфигурација и управувањето со сесии се одделни услуги што разговараат преку системската магистрала. Токму ова одвојување му овозможува на обичен корисник да започне сесија без привилегиран демон да чита заштитена датотека со лозинки во негово име. Податоците за најава засновани на датотека немаат место во тој модел, бидејќи нема стартување од страната на демонот што би ги прочитало. Одбивањето е последица на архитектурата, а не функција што недостасува.

Стариот модел вреди да се именува за полесно да се отучи: профилот упатува на датотека со податоци за најава, а демонот ја чита кога тунелот започнува. Во новиот модел, податоците за најава и припаѓаат на сесијата и се доставуваат кога таа сесија започнува. 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 во профилот целосно ја отстранува потребата за рестартирање. Сесија што останува подигната никогаш не стигнува до барањето што се обидувате да го автоматизирате.

Поврзани статии