Датотека со акредитиви или контролна штекер на OpenVPN: што да се скриптира

Скрипта што го стартува 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, не со акредитиви.

Потоа тестирајте го повторното поврзување, не само првото стартување. Прекинете ја сесијата од страна на серверот или почекајте нејзиниот рок; клиентот повторно прашува, и токму таму датотеката што изгледала точна при подигнување покажува дали сѐ уште е читлива за сметката што се поврзува повторно.