Planificar unha ventá de mantemento de OpenVPN sen perder o host

Reiniciar o servizo de VPN remata cada sesión que o usa, así que a ventá ten que construírse arredor das conversas e non do xestor de paquetes. Os usuarios necesitan aviso suficiente para rematar traballo sensible, e ti necesitas un xeito de volver que non dependa do túnel que estás a piques de deter. Todo o demais do manual existe para facer manexables eses dous feitos. Omite calquera dos dous e unha actualización rutineira convértese nunha caída sen saída.

A orde de abaixo é deliberada: cada etapa produce algo que a seguinte necesita, e calquera etapa pode rematar o cambio antes de que comece.

Rexistra o servizo que existe antes de cambialo

Le a unidade instalada en lugar da que recordas ter escrito: systemctl cat [email protected] imprime a unidade e calquera drop-in, e systemctl show [email protected] -p ExecStart -p User -p WorkingDirectory mostra que se executa realmente e con que identidade. Pregunta ao binario que nomea esa unidade, porque openvpn --version desde un shell pode resolverse a outra compilación. Anota a ruta do perfil e cada ficheiro ao que fai referencia.

Fíxate tamén nos sockets de escoita: ss -lunp | grep 1194 diche que enderezo e protocolo posúe hoxe o daemon. Se a resposta non é a que suxire o perfil, algún drop-in ou ficheiro de contorno a está sobrescribindo, e a actualización herdará esa sorpresa.

Reúne un conxunto de recuperación que outra persoa poida usar

O conxunto de recuperación ten que poder usalo un compañeiro ás 03:00 sen o teu contexto. Inclúe a configuración efectiva con cada ficheiro referenciado, o material de confianza e revocación baixo control do propietario da PKI, as asignacións e os hooks por cliente, e as versións exactas de paquetes instaladas hoxe. Unha copia dun só nome de ficheiro non é unha configuración. Gárdao onde o operador de garda poida chegar sen a VPN.

Os controis de acceso tamén se aplican a ese conxunto, porque contén claves privadas ou credenciais de backend. Non reconstruas a CA nin volvas emitir identidades só porque cambiou unha versión de paquete.

Ensaia nun oínte piloto cun cliente real

Executa a versión candidata nun oínte separado co seu propio plan de portos e enderezos, non xunto á instancia de produción no mesmo socket. Conéctate cos motores de cliente que os teus usuarios usan de verdade, incluído o incómodo. Comproba a asignación de enderezos, o DNS empurrado, unha aplicación que importe e unha ruta que deba seguir bloqueada. Os hooks personalizados teñen que executarse no contexto real de privilexios e de sistema de ficheiros do servizo, porque un shell de root non demostra nada sobre eles.

Le as notas da versión por cambios de comportamento, non só por funcións novas. Os valores por defecto de cifrado e TLS móvense entre versións, e un perfil que aínda se analiza pode fallar o handshake. Se a actualización precisa cambios de perfil ou de certificado, expónos como un paso propio en lugar de metelos na actualización do paquete.

Cambia unha soa vez, desde unha ruta fóra do túnel

Comeza a ventá desde unha consola ou unha rede de xestión que non atravese o servizo. Confirma que se avisou os usuarios e que un segundo operador sabe como reverter. Aplica o cambio preparado a través do seu propietario, reinicia con sudo systemctl restart [email protected] e segue o journal con journalctl -u openvpn-server@office -b -f. Unha recarga abonda cando só cambiaron definicións de unidade; un perfil cambiado necesita reiniciar o proceso.

Espera que todos os clientes se reconecten e espera que algunhas sesións de aplicación non se retomen. Coordina unha pausa limpa coas cargas de traballo que non o toleran.

Acepta ou reverte, e despois di aos usuarios que cambiou

A aceptación é un inicio de sesión novo máis unha operación real máis as restricións que seguen vixentes. Unha unidade activa e unha liña de estado verde son feitos do proceso. Se os criterios fallan dentro da ventá, reverte co método preparado, non restaurando un só ficheiro e confiando; un binario ou unha política de servizo cambiados sobreviven a unha restauración da configuración. Conserva calquera cambio de revocación ou autorización feito durante a ventá para que a reversión non desfaga traballo de seguridade.

Anota as versións, os cambios de perfil e os resultados de aceptación para o seguinte operador, retira o oínte piloto e di aos usuarios que perfil usar agora. Unha ventá que remata sen esa nota volve discutirse na próxima actualización.