Reconnectar un client OpenVPN: tres controls, tres àmbits

Algú demana que es reconecti el client VPN, i la petició pot voler dir tres coses diferents. Pot voler dir descartar una sessió autenticada, avisar tots els clients que un servidor UDP desapareix o reiniciar el dimoni mateix. Cadascuna té un radi d’impacte diferent, i triar la incorrecta converteix una reparació per a un usuari en una caiguda. L’abast és la decisió, i l’ordre se’n deriva.

Pregunteu qui ha de quedar afectat abans de preguntar quin control fer servir.

Una instància: la interfície de gestió

Una interfície de gestió configurada pot llistar les instàncies connectades i descartar-ne exactament una. Cada sessió porta un identificador de client, i client-kill CID apunta a aquest identificador i no a un nom comú. Llegiu l’identificador viu de la sortida d’estat actual, perquè un valor copiat d’un registre antic fa referència a una sessió que ja no existeix. Descartar la instància acaba amb aquesta connexió i amb res més.

No garanteix una connexió nova. Que el client torni depèn de la seva configuració de reintents, de les entrades remotes que li queden, dels seus requisits d’autenticació i de si l’aplicació supervisora encara s’executa. Un client que torna obté un identificador nou, i per això comparar identificadors és l’única manera fiable de distingir el vell del nou.

Un avís de sortida UDP no és una ordre per client

explicit-exit-notify és una directiva de configuració sobre esdeveniments de sortida i reinici. En un client UDP diu a l’igual que la sessió s’acaba, i l’argument numèric controla quantes vegades es reintenta l’avís. Quan el servidor funciona sobre UDP envia un missatge de control de reinici als seus clients connectats, i els valors documentats distingeixen reconnectar al mateix servidor de passar a una altra entrada remota. És un senyal de cicle de vida amb una audiència àmplia.

Res no hi selecciona un client arbitrari en un moment arbitrari. Tractar-ho com un botó de reconnexió arriba a totes les sessions connectades alhora.

Els senyals actuen sobre el procés, no sobre una sessió

SIGUSR1 demana a un procés en execució que reiniciï la seva connexió sense rellegir la configuració, i les opcions de persistència decideixen què sobreviu a aquest reinici. SIGHUP va més enllà: rellegeix el fitxer de configuració i reobre els seus recursos. SIGTERM i SIGINT demanen una aturada ordenada. Són operacions a nivell de procés: en un servidor amb diversos clients afecten cada sessió que porta el procés, no la que apareix al tiquet.

Quan el procés s’executa sota un gestor de serveis, feu servir el control propi del gestor en lloc d’enviar un senyal a un PID que hàgiu trobat en un llistat de processos. Llegiu la unitat per veure quin senyal envia el gestor, perquè un reinici i una recàrrega fan coses diferents al mateix dimoni.

Decidiu l’abast abans de triar el control

Tres preguntes ho resolen. Qui ha de quedar afectat: un usuari, cada client d’un servidor o el dimoni i tot el que porta. Què ha de sobreviure: la configuració, l’estat del túnel o ni una cosa ni l’altra. Qui hi està autoritzat: la integració de gestió, el propietari del servei o l’operador de xarxa que controla l’avís de sortida. Responeu-ho i només encaixa un control.

Afegir un escoltador de control no autenticat per obtenir un botó de reconnexió lliura a qui pugui arribar al port molt més que aquest botó.

Verifiqueu la sessió nova, no la desconnexió

Un esdeveniment de desconnexió demostra que la sessió vella s’ha acabat. No diu res sobre una de nova que s’autentiqui, rebi una adreça, instal·li rutes o arribi al recurs que l’usuari necessitava. Comproveu l’identificador nou, després l’estat del túnel, després un recurs real. Aquests tres passos són la diferència entre una reconnexió i una connexió que funciona.

Escriviu l’abast al registre de canvis. «He reconnectat el client» no és una descripció quan el client era un de quaranta en un servidor compartit.