Fóra do servidor VPN: manteña unha segunda vía de entrada

Abre a consola, cambia unha regra de devasas e o túnel polo que estaba conectado desaparece. O cambio era correcto, a recarga non, e agora a única ruta de volta á máquina é a que acaba de romper. Unha segunda vía de entrada é unha decisión de deseño, e ten que existir antes da caída, non durante.

Repase o que aínda ten

Comece pola pantalla de consola que ten diante e enumere as vías que non dependen do túnel. Unha consola web do provedor cunha sesión serie ou VNC é unha. Unha interface de xestión nunha rede separada é outra. O acceso físico é a terceira, e é a que a xente descobre que falta no peor momento.

Lea a terceira columna como unha lista de fallos e non como unha abstracción. Dúas desas vías adoitan fallar polo mesmo motivo. A táboa é como se decata antes de que unha caída llo explique.

A independencia é unha cuestión de dependencias

Unha conta de recuperación non é independente se o seu contrasinal se garda nun servizo ao que chega polo túnel. Unha segunda VPN no mesmo host, o mesmo porto e a mesma política de devasas tampouco é independente, porque o cambio que rompeu a primeira rompe as dúas.

Baixe pola cadea e nomee que necesita cada paso. A accesibilidade de rede, a resolución de nomes, unha fonte de autenticación e o propio servizo de xestión son catro dependencias separadas, e unha vía que comparta calquera delas herda ese fallo.

A vía que nunca se probou merece a súa propia sospeita. Unha consola que non se abriu durante meses pode requirir un restablecemento do contrasinal por correo, e ese buzón pode estar aloxado na máquina á que non chega. Probe a vía mentres todo funciona e atoparao unha tarde tranquila.

Use a segunda vía para un cambio controlado

Desde a consola, tome unha instantánea ou copie a configuración que está a piques de editar. Cambie unha cousa. Recargue o servizo e lea o resultado antes de tocar calquera outra cousa, porque dous cambios á vez converten unha recuperación nun experimento.

Manteña aberta a sesión de recuperación mentres o fai. Todo o valor da segunda vía é que sobrevive ao que está a cambiar, así que pechala primeiro elimina a única propiedade que a facía útil.

Verifique desde a vía de recuperación, non de memoria

A comprobación que importa é se volve a vía normal, e a sesión de recuperación é onde o confirma por orde:

systemctl status openvpn-server@server --no-pager
ss -lntup | grep -E ':(1194|443)\b'
nft list ruleset | sed -n '1,40p'
journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30

Lea primeiro o estado do servizo, despois o oínte, despois as regras, despois o rexistro. Un servizo que funciona sen oínte apunta á configuración do servizo, mentres que un oínte sen regras accesibles apunta á filtraxe. A orde importa porque cada paso estreita o seguinte, e saltar ao rexistro adoita significar ler erros que describen o síntoma e non a causa.

A documentación de systemctl cobre o comportamento de estado e reinicio usado aquí, incluído como unha recarga fallida deixa o proceso anterior en marcha. Restaurar unha revisión coherente é mellor que reconectar unha e outra vez desde un cliente que non pode reparar o servidor. Se se cumpriu a condición de reversión que definiu antes do cambio, restaure e detéñase.

Manteña o inventario ao día

Revise a lista de acceso cando cambian as persoas ou a infraestrutura. Probe a vía de recuperación mentres todo funciona. Retire as contas que ninguén usou desde a última reorganización. Dúas contas obsoletas e un certificado caducado son unha pequena limpeza un martes e unha caída un domingo.

Rexistre quen pode usar cada vía, que permite e como se rotan as credenciais. Unha vía de recuperación sen propietario convértese nunha entrada esquecida, que é un tipo de fallo distinto de quedar fóra.