Fitxer de credencials o sòcol de gestió d'OpenVPN: què cal scriptar

Un script que inicia OpenVPN i no es connecta mai no sol ser un problema de xarxa: el client s'està en un missatge sense cap terminal on dibuixar-lo. OpenVPN té exactament dues maneres admeses de respondre aquest missatge sense una persona, un fitxer de credencials darrere d'auth-user-pass i el sòcol de gestió, i no són intercanviables. El fitxer costa una directiva i respon un missatge; el sòcol respon tots els missatges i dona a qualsevol cosa que pugui obrir un port de loopback un canal de control no autenticat. Quin dels dos pertoca al vostre desplegament depèn de quin missatge bloqueja realment i de quin secret us podeu permetre deixar en repòs.

Anomeneu el missatge abans de triar un mecanisme

Quatre missatges semblen idèntics en un terminal. La parella de compte ve de la configuració PAM o auth-user-pass-verify del servidor i la respon auth-user-pass. La contrasenya d'una clau privada pertany al fitxer de clau i es llegeix amb --askpass o s'escriu a mà. Un paquet PKCS#12 demana una contrasenya pròpia. L'autenticació de proxy fa servir el fitxer auth que pren --http-proxy, no les credencials del compte.

Quan OpenVPN s'executa com a fill de systemd, PHP o Node no hi ha terminal, així que qualsevol d'aquests bloqueja en silenci. El procés s'hi queda, el registre s'atura després de la línia de xifratge i la unitat acaba esgotant el temps; aquest silenci és la raó per la qual la gent afegeix un bucle de reintent o un sleep en lloc de mirar quin missatge està pendent. Només el sòcol de gestió pot respondre els quatre. El fitxer de credencials respon el primer i res més.

auth-user-pass: un fitxer, un missatge

El fitxer porta el nom d'usuari a la primera línia i la contrasenya a la segona, i res més: sense cometes, sense noms de clau, sense comentari. Poseu el mode 600 i feu que el propietari sigui el compte que executa openvpn, que per a un servei sovint és un usuari dedicat i no el vostre inici de sessió. Un fitxer propietat de root sota /root és la diferència entre una ordre que funciona a la vostra shell i una unitat que falla a l'arrencada.

Dos detalls converteixen un fitxer correcte en un missatge. Un editor que desa CRLF deixa un retorn de carro enganxat a la contrasenya, així que el servidor rebutja una contrasenya que al fitxer sembla correcta; comproveu-ho amb cat -A o od -c en lloc de a ull. I un auth-user-pass sense argument dins del perfil vol dir «pregunta l'usuari» per disseny, cosa que una segona directiva a la línia d'ordres potser no pot anul·lar, perquè el perfil s'analitza on és.

L'ordre de les opcions és el tercer parany, i depèn de la versió. Algunes compilacions d'OpenVPN 2.4 ignoren --auth-user-pass quan apareix abans de --config, així que les mateixes dues opcions en l'altre ordre es connecten. Poseu la directiva dins del perfil, o després de --config a la línia d'ordres, i cerqueu al perfil cada aparició abans de canviar res més.

auth-nocache pertany a aquest mecanisme però no aporta res. Limita quant de temps el client guarda la credencial en memòria, cosa que ajuda després d'un error i no ajuda gens quan falta el fitxer. Una reconnexió després d'un temps d'espera de sessió al servidor torna a llegir el fitxer, així que una credencial que funcionava a l'arrencada encara pot caducar a mitja tarda.

El sòcol de gestió: cada missatge, més superfície

Inicieu el client amb un oient i declareu explícitament que els missatges s'informaran per ell, amb les directives documentades al manual d'OpenVPN 2.6:

management 127.0.0.1 3030
management-query-passwords

Des de bash, manteniu la connexió en un descriptor de fitxer lliure i responeu pel nom del missatge en lloc de per la posició, perquè una reconnexió pot preguntar en un altre ordre:

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

La frontera és el transport. El protocol de gestió és text pla sobre TCP al loopback, així que l'oient no s'ha de publicar en una adreça de LAN o de túnel perquè un controlador remot hi arribi; un controlador remot vol dir un reenviament SSH, no una vinculació més ampla. El dimoni de la comunitat també accepta un sol client de gestió alhora, així que una GUI o un monitor no poden compartir el sòcol amb el vostre script. La segona connexió es rebutja, no es posa en cua, i la fallada sembla un script que s'ha tornat sord.

Aquest sòcol també és un canal de control. Sense contrasenya de gestió, qualsevol cosa que es pugui connectar a 127.0.0.1:3030 pot llegir l'estat, matar el túnel o respondre un missatge ell mateix. La contrasenya de gestió i el fitxer de credencials són secrets de la mateixa classe, i tots dos mereixen la mateixa cura.

Quin encaixa amb el desplegament

Trieu el fitxer de credencials quan l'únic missatge és la parella de compte, el client funciona com a servei amb un propietari estable i podeu mantenir un fitxer 600 fora de còpies de seguretat que no controleu. Trieu el sòcol de gestió quan hi hagi una contrasenya de clau o una contrasenya PKCS#12, quan l'embolcall ja supervisa el procés o quan necessiteu vigilar l'estat i els missatges mentre depureu una reconnexió.

Dues condicions mouen la decisió. Si l'embolcall és /bin/sh, una unitat de systemd que crida el binari directament o un contenidor mínim, l'engrut de sòcol només per a bash no hi és i el fitxer és la resposta més barata. Si el secret rota sovint, cap fitxer no és un bon lloc per a ell: consulteu un anell de claus des d'un embolcall petit i deixeu que la unitat cridi l'embolcall, cosa que manté la rotació en un sol lloc i la contrasenya fora de l'historial de la shell.

La substitució de processos se situa entre els dos i no pertany a cap. L'ordre d'una línia de sota funciona perquè bash l'expandeix abans que openvpn arrenqui, no perquè el client entengui la sintaxi:

openvpn --config client.ovpn --auth-user-pass <(printf "%s
%s
" "$USER" "$PASS")

Es trenca sota /bin/sh, en una unitat que evita la shell i en imatges sense bash o /dev/fd. Guardeu-lo per a proves interactives, mai com el contracte del qual depèn un servei.

Protegiu el secret, i després verifiqueu des del registre

Tots dos mecanismes deixen un secret llegible pel procés OpenVPN. No poseu mai la contrasenya a la línia d'ordres ni al fitxer de la unitat, on ps i systemctl la mostren a cada usuari local; passeu el camí del fitxer, no el valor que hi ha a dins. On els certificats poden substituir la parella de compte, això elimina la categoria de missatge en lloc d'amagar-la.

Una execució correcta mostra la seqüència de missatges completant-se i la sessió arribant a «Initialization Sequence Completed». Si el client s'atura al mateix missatge, la concordança ha fallat: imprimiu les línies exactes que el sòcol ha enviat, comproveu les cometes i el nom del missatge, i arregleu el patró en lloc d'afegir un sleep. Un túnel que informa d'èxit i no transporta res és un problema d'encaminament o de push, no de credencials.

Després proveu la reconnexió, no només la primera arrencada. Deixeu caure la sessió del servidor o espereu el seu temps d'espera; el client torna a preguntar, i és aquí on un fitxer que semblava correcte a l'arrencada mostra si encara és llegible pel compte que es reconnecta.