Hook de client o hook de servidor? On s’executa un script d’OpenVPN

La tasca és clara: quan un portàtil es connecta, alguna cosa del portàtil ha de canviar. La configuració que s’edita pertany al servidor, i aquí és on es trenca la suposició. Un camí en un fitxer del servidor anomena un fitxer d’aquell servidor, i cap quantitat de push no canvia quin procés l’executa. Triar entre els dos hooks és sobretot decidir quina màquina és propietària de la feina i acceptar els límits que se’n deriven.

Dues màquines, dues preguntes per respondre primer

Pregunteu on ha de passar el canvi d’estat i després pregunteu quin esdeveniment hi correspon. Si el canvi és una autorització per usuari o una decisió de configuració per client, pertany on es coneix el directori d’usuaris: el servidor. Si el canvi és una ruta, un paràmetre del resolutor o un ajudant local en un extrem, pertany a l’extrem, i només l’extrem pot fer-ho.

Respondre aquestes dues preguntes en l’ordre invers és com la gent acaba intentant empènyer un fitxer batch a un portàtil Windows. El servidor sap qui s’ha connectat; el portàtil sap com és la seva pròpia pila de xarxa. Cap dels dos no té la informació de l’altre, i l’intent sol fallar en silenci en lloc de donar un error clar.

Val la pena fer una tercera pregunta abans de les dues: la plataforma ofereix fins i tot el hook que voleu? Un aparell que genera la seva pròpia configuració pot no oferir els mateixos noms d’esdeveniment, i un client d’escriptori que importa un fitxer .ovpn no és necessàriament el mateix client per al qual es va escriure el fitxer. Confirmar la plataforma primer us estalvia dissenyar al voltant d’un hook que allà no existeix. També us diu quina documentació s’aplica realment a la màquina que teniu davant.

L’opció del costat del servidor: un esdeveniment per connexió

Un script client-connect s’executa en el context del procés del servidor quan es connecta un client autenticat, i rep detalls de connexió documentats com el common name i l’adreça assignada. És el lloc correcte per escriure un fragment de configuració per client, fer complir una decisió de política o registrar estat que el servidor posseeix.

La distinció que la gent passa per alt és la diferència entre aquest hook i un hook up del servidor. El hook up s’activa quan el servidor obre el seu dispositiu de túnel, cosa que en un servidor amb diversos clients passa una vegada en arrencar el dimoni. No és un esdeveniment per inici de sessió, i el codi que hi poseu s’executa quan arrenca el servei, no quan es connecten els usuaris.

En un aparell amb interfície web, feu servir el mecanisme d’extensió suportat en lloc d’editar fitxers del dimoni generats. Els fitxers generats es reescriuen en el proper desament, i la reescriptura elimina el vostre canvi en silenci en el pitjor moment possible. Guardeu una còpia del text de l’extensió fora de l’aparell perquè una actualització de firmware no perdi també la intenció.

L’opció del costat del client: feina que ha de córrer localment

Un client de la comunitat pot executar un script local quan apareix el dispositiu de túnel i de nou quan s’instal·len les rutes. Són dos moments diferents, i triar el moment equivocat produeix la clàssica cursa en què un ajudant arrenca abans que existeixi la ruta de la qual depèn.

L’ajudant ha d’existir en aquell client, ha de ser llegible i executable pel compte que executa el client, i ha d’estar permès per un paràmetre script-security explícit. Un script que funciona quan executeu el client com a administrador no us diu res sobre un servei d’abans de l’inici de sessió o sobre la sessió d’un altre usuari.

Els noms també importen. El hook up correspon a la creació del dispositiu i route-up a la instal·lació de rutes, però una tasca que necessita que una xarxa privada sigui abastable ha de verificar l’abastabilitat en lloc de suposar que la creació del dispositiu implica que cada ruta, entrada de resolutor i aplicació estan a punt.

Per què posar codi executable no és entre les opcions

Les opcions empeses amb push estan restringides a propòsit, i les opcions que executen scripts són una de les categories que el servidor no pot passar avall. Aquesta restricció existeix perquè l’alternativa permetria que un servidor compromès o mal configurat executés ordres arbitràries a cada client que es connecti mai.

Habilitar l’execució d’scripts localment no canvia això. El vostre paràmetre script-security permet scripts locals que hàgiu triat vosaltres; no autoritza el servidor a subministrar-ne de nous.

Si l’objectiu és simplement instal·lar rutes VPN, feu servir la configuració de rutes suportada en lloc d’inventar un esquema d’execució remota. Si l’objectiu requereix de veritat codi local, distribuïu-lo amb les eines de gestió d’extrems de l’organització i reviseu-lo com qualsevol altre programari que s’executi amb els privilegis de l’usuari.

Què cal verificar abans de confiar en qualsevol dels dos hooks

Anoteu quatre coses per a cada hook: la màquina, el nom de l’esdeveniment, el compte amb què s’executa i el canvi d’estat que ha de produir. Després proveu la connexió, una reconnexió i el camí de neteja, perquè un hook que perd estat en reconnectar és pitjor que un que no s’hagi executat mai.

Proveu-ho amb el compte que realment l’executarà, en el moment en què realment s’executarà. El manual openvpn(8) documenta les dues famílies de hooks i les restriccions del push; la plataforma on desplegueu documenta si les exposa o no. Un script que té èxit en un terminal d’administrador interactiu és una hipòtesi, no una verificació.