Gestión de usuarios VPN de oficina: rotación de claves, revocación y flujos de acceso limpios

Principios: qué significa realmente “acceso limpio”

“Acceso limpio” no es una postura moral. Es higiene operacional. Significa que puedes responder tres preguntas rápidamente, con evidencia:
¿Quién puede conectarse? ¿Quién se conectó? ¿Podemos detenerlos inmediatamente sin romper al resto?

La VPN es un punto de estrangulamiento. Trátala como un servicio de producción, no como un cable mágico. Tu trabajo es reducir la cantidad de secretos de larga duración,
hacer los cambios de acceso predecibles y asegurar que la revocación realmente revoque.

Reglas no negociables (de las que haces cumplir, no solo admiras)

• La identidad está río arriba. La autorización VPN debe seguir la identidad corporativa (SSO/IdP) siempre que sea posible. Las cuentas locales son el último recurso.
• Credenciales de corta vida vencen a la revocación heroica. Si tus secretos expiran rápido, no tienes que ser perfecto al revocarlos.
• Un usuario, un conjunto de credenciales. Las cuentas compartidas son como construir una responsabilidad sin darte cuenta.
• La revocación debe ser observable. Si no puedes demostrar que funcionó, no revocaste—solo cerraste un ticket.
• Automatiza lo aburrido. Documenta las aristas afiladas. Las personas son excelentes en manejar excepciones. Son terribles en la repetición.

Una cita, porque sigue vigente:
idea parafraseada — Gene Kim: mejorar el sistema gana a culpar a individuos; construye bucles de retroalimentación y facilita los cambios seguros.
(Si quieres que esto funcione, haz que lo correcto sea lo fácil.)

Hechos y contexto histórico (para que dejes de repetir la historia)

1. PPTP (años 90) se popularizó porque era “fácil”, y luego se hizo infame porque era fácil de romper. La conveniencia siempre pasa factura después.
2. IPsec fue diseñado para la seguridad en la capa de red y túneles empresariales, pero su complejidad de configuración generó una industria de malas configuraciones.
3. SSL VPNs crecieron a principios de los 2000 porque los usuarios querían acceso “tipo navegador”; los admins querían menos negociaciones de firewall.
4. La revocación de certificados ha sido un dolor persistente desde los primeros días de la PKI; existen CRL y OCSP porque la gente pierde claves constantemente.
5. OpenVPN ganó tracción por ser flexible y ejecutarse en sistemas commodity; esa misma flexibilidad deja margen para esquemas de autenticación inconsistentes.
6. WireGuard (década de 2010) eligió deliberadamente una base de código pequeña y primitivas criptográficas modernas, pero su modelo de claves estáticas te obliga a pensar en flujos de rotación.
7. “VPN siempre activa” se convirtió en tendencia corporativa con el teletrabajo; reduce la fricción del usuario y aumenta tu radio de impacto cuando el acceso está mal delimitado.
8. El marketing de zero trust no mató a las VPN; cambió expectativas. Más acceso condicional, menos “una vez conectado, estás adentro”.
9. Controles de postura (dispositivo gestionado, SO conforme) se volvieron diferenciadores reales tras oleadas de robo de credenciales y endpoints no gestionados.

Decisiones de diseño que cambian tu día a día

Elige tu modelo de VPN: “extensión de red” vs “acceso por aplicación”

Si tu VPN da a un portátil remoto el mismo movimiento lateral que tendría en la LAN de la oficina, has rehecho la red de la oficina en el peor lugar posible: Internet.
En su lugar, decide qué necesitas realmente:

• VPN de extensión de red (clásica): buena para protocolos legacy y “tiene que ver la subred”. Alto riesgo si la segmentación es débil.
• Acceso por aplicación (preferido): acceso por app/servicio (SSH, Git, web interna). Mucho más fácil de auditar y limitar el radio de impacto.

Autenticación: no te pongas creativo con secretos compartidos

La jerarquía sensata:

1. SSO + MFA (OIDC/SAML vía un IdP) ligado a la postura del dispositivo si puedes.
2. Certificados (certificados de cliente) con vidas cortas y un canal real de revocación.
3. Claves estáticas / PSK solo cuando el cliente es sin interfaz y gestionado, y puedes rotarlas rápido.

Acceso VPN solo por contraseña en 2025 es como dejar la sala de servidores sin llave porque la puerta pesa. Es técnicamente una barrera; no es un control.

Autorización: grupos, no ACLs hechas a mano por usuario

La gente cambia de rol. Los proyectos terminan. Los equipos se reorganizan. Si tu política VPN es un montón de excepciones por usuario, “arreglarás” el acceso a las 2 a.m. copiando una excepción.
Así es como construyes un museo de malas decisiones.

Usa políticas impulsadas por grupos:

• Acceso base: rutas/DNS mínimas, obligatorias para todos.
• Acceso por rol: ingeniería, finanzas, TI, etc.
• Acceso temporal: contratistas, respondedores de incidentes.
• Break-glass: camino separado y fuertemente auditado.

Manejo de sesiones: la revocación debe terminar sesiones activas

Es común revocar una credencial pero olvidar que la sesión ya establecida sigue activa por horas. Tu “revocación” entonces se vuelve una sugerencia educada.
Construye la capacidad de:

• forzar la desconexión de un usuario específico
• eliminar todas las sesiones vinculadas a una credencial/clave
• rotar claves/certs de servidor sin corte (o con uno controlado)

Ciclo de vida del usuario: incorporación hasta salida

Incorporación: un solo camino, sin cuentas VPN artesanales

El flujo limpio es aburrido:

• RR. HH./TI crea la identidad en el IdP.
• Al usuario se le asignan grupos (departamento + rol + cualquier grupo de proyecto con tiempo limitado).
• El acceso VPN se implica por la pertenencia a grupos.
• MFA y cumplimiento del dispositivo se aplican antes de emitir la VPN.

Evita “simplemente lo añadiremos localmente en la caja VPN”. Eso es el equivalente operacional de escribir secretos de producción en una nota adhesiva porque tu gestor de contraseñas está “caído”.

Cambios de rol: trátalos como revocar + conceder, no como editar

La forma más sencilla de eliminar privilegios es quitar todo el conjunto antiguo y aplicar el nuevo. Los deltas son cómo los permisos perduran.
Mantén un registro: quién aprobó el nuevo alcance de acceso y cuándo expira (si aplica).

Salida: hazlo como si esperases una demanda

El offboarding tiene tres capas, y necesitas las tres:

1. Deshabilitar identidad (IdP): evita nuevas autenticaciones.
2. Revocar credenciales (certs/keys): evita re-autenticación fuera de rutas IdP y mata credenciales de larga duración.
3. Terminación de sesiones: cae túneles activos.

Si tu flujo solo hace el paso 1, aprenderás sobre los pasos 2 y 3 cuando un dispositivo siga conectado durante una entrevista de salida.

Rotación de claves que no rompe a la gente (y que sigue importando)

Qué rotas (y por qué)

“Claves” de VPN puede significar varias cosas. Trátalas de forma distinta:

• Certificados/keys de servidor: la compromisión aquí es catastrófica; rota según calendario y ante cualquier sospecha.
• Certificados/keys de cliente: rota regularmente; vidas más cortas reducen la dependencia de una revocación perfecta.
• Claves públicas de pares de WireGuard: son tokens de identidad; la rotación requiere coordinación.
• PSK: rota con frecuencia si se usa; asume que se filtrará eventualmente.
• CA: rota raramente y con ceremonia. Si rotas la CA a la ligera, eliges el tiempo de inactividad como estilo de vida.

Estrategias de rotación que funcionan en oficinas

Hay dos estilos:

• Rotación escalonada: solapa credenciales antiguas/nuevas por una ventana. Menos dolor, más complejidad.
• Corte seco: rota e invalida lo viejo inmediatamente. Más dolor, menos ambigüedad.

Para VPNs de oficina orientadas a usuarios, la rotación escalonada suele ser la mejor—la gente viaja, los portátiles duermen días, y alguien estará en un avión durante tu ventana de mantenimiento.
Pero debes limitar la solapa y monitorizar el uso de credenciales antiguas durante el período de gracia.

Broma #1: La rotación de claves es como usar hilo dental: todo el mundo acepta que es bueno, y luego misteriosamente nadie tiene tiempo hasta que algo empieza a sangrar.

Certificados de corta duración: el arma secreta

Si puedes emitir certificados de cliente que expiran en días (o horas) y se renuevan automáticamente vía SSO, cambias el problema de “la revocación debe ser perfecta”
a “la expiración es inevitable”. Esa es una compensación que quieres.

Los CRL siguen importando, pero ya no apuestas la empresa a que la distribución de CRL sea perfecta para siempre.

Realidades de WireGuard: claves estáticas, humanos dinámicos

La simplicidad de WireGuard es una característica. También es una limitación: el servidor decide qué claves públicas de pares están permitidas, y los pares a menudo se configuran con claves estáticas.
La rotación se convierte en “añadir nueva clave, permitir ambas brevemente, eliminar la vieja”. Operacionalmente está bien, culturalmente es difícil—porque exige disciplina.

Revocación bien hecha: certificados, claves, sesiones y caches

La revocación es un sistema, no un comando

La revocación falla de maneras previsibles:

• La CRL se actualiza pero no se despliega en todos los servidores VPN.
• El servidor VPN consulta la CRL solo al arranque; no se reinició el servicio.
• El cliente ya está conectado; el servidor no re-verifica a mitad de sesión.
• Se quitó el par de WireGuard de la configuración, pero no se volvió a cargar la config.
• Las rutas DNS aún permiten acceso por otro camino (split tunnel + proxies internos).

La revocación limpia incluye un paso de verificación. Si no lo pruebas, estás haciendo teatro.

Revocación de certificados: CRL vs OCSP en el mundo VPN de oficina

Las configuraciones VPN de oficina comúnmente usan CRL porque son operativamente sencillas: generar CRL, distribuirla y configurar la VPN para consultarla.
OCSP añade una dependencia en línea. Eso puede estar bien, pero introduces un nuevo “servicio de autenticación” que debe ser fiable bajo carga de incidente.

Mi opinión: si ejecutas tu propia PKI basada en OpenVPN, CRL + certificados de corta duración es una línea base sensata. OCSP es un buen siguiente paso cuando puedes operarlo como servicio real,
con monitorización, redundancia y un modo de fallo con el que puedas vivir.

Terminación de sesiones: la parte que todos olvidan

La revocación que no corta túneles en vivo es incompleta. Tu VPN debería soportar:

• matar sesiones específicas por common name (cert CN), nombre de usuario o clave de peer
• limitar la vida de sesión (renegociación, re-autenticación)
• empujar actualizaciones de configuración sin outages totales

Broma #2: “Revocamos su acceso VPN” es la versión de TI de “apagué la estufa”—dicho con confianza mientras la alarma de humo audiciona para una banda de metal.

Registro, responsabilidad y señales de auditoría confiables

Qué registrar (y qué no pretender que sabes)

Registra eventos sobre los que puedas actuar:

• éxitos/errores de autenticación con identidad de usuario (sujeto IdP, cert CN, nombre de peer WireGuard)
• marcas de tiempo de inicio/fin de sesión
• IP VPN asignada, IP pública del cliente e identificador del dispositivo (donde esté disponible)
• versión de configuración o hash de política aplicada a la sesión
• acciones de administrador: quién revocó, quién rotó, quién cambió la política

Ten cuidado con registrar afirmaciones que no puedes garantizar, como “propietario del dispositivo”. Los portátiles se prestan. Los teléfonos se comparten. Las credenciales VPN se copian.
Registra lo que puedas verificar y diseña controles para reducir la ambigüedad.

Retención y controles de acceso

Los registros VPN son sensibles: muestran desde dónde se conectó la gente y qué tocaron (a veces indirectamente).
Retén el tiempo suficiente para respuesta a incidentes y cumplimiento, pero no trates los logs como chatarra que puedes volcar en cualquier cubeta.
Protégelos y registra el acceso a los propios logs.

Auditoría: concilia tres vistas

Tu auditoría tiene que conciliar:

1. Estado deseado: quién debería tener acceso (grupos, roles, excepciones con expiraciones).
2. Estado configurado: qué aceptan realmente los servidores VPN (DB de certificados, peers de WireGuard, conectores de auth).
3. Estado observado: quién se conectó y desde dónde (logs).

Si esos tres no coinciden, tu problema no es “seguridad”. Es gestión de configuración y disciplina del ciclo de vida.

Tareas prácticas con comandos, salidas y decisiones (12+)

Los comandos abajo asumen servidores Linux. Los nombres de host y rutas son típicos, no mágicos. Ejecútalos, lee la salida y luego toma una decisión explícita.
Esa es la diferencia entre operaciones y sensaciones.

Tarea 1: Identificar quién está conectado actualmente (OpenVPN vía systemd journal)

cr0x@server:~$ sudo journalctl -u openvpn-server@office -S -2h | egrep "Peer Connection Initiated|SIGTERM\[soft,remote-exit\]|Inactivity timeout"
Aug 28 09:11:02 vpn-1 openvpn[1423]: 203.0.113.44:53412 Peer Connection Initiated with [AF_INET]203.0.113.44:53412
Aug 28 09:11:02 vpn-1 openvpn[1423]: user=jdoe cn=jdoe-laptop-2025 assigned_ip=10.8.0.42
Aug 28 10:07:18 vpn-1 openvpn[1423]: user=asmith cn=asmith-macbook assigned_ip=10.8.0.57 Inactivity timeout (--ping-restart), restarting
Aug 28 10:41:30 vpn-1 openvpn[1423]: 198.51.100.19:60122 Peer Connection Initiated with [AF_INET]198.51.100.19:60122
Aug 28 10:41:30 vpn-1 openvpn[1423]: user=vendor1 cn=vendor1-temp assigned_ip=10.8.0.88

Qué significa: Puedes mapear sesiones a identidades y IPs VPN asignadas. También ves clientes inestables (reinicios por inactividad).

Decisión: Si hay un offboarding en curso, confirma que el usuario no esté conectado; si lo está, planifica una desconexión forzada tras la revocación.

Tarea 2: Verificar que el servidor aplica una CRL (comprobación de config OpenVPN)

cr0x@server:~$ sudo grep -R --line-number "crl-verify" /etc/openvpn/server/*.conf
/etc/openvpn/server/office.conf:38:crl-verify /etc/openvpn/pki/crl.pem

Qué significa: La configuración del servidor apunta a un archivo CRL. Esto es necesario pero no suficiente (debe estar actual y ser legible).

Decisión: Si falta, en la práctica no estás revocando certificados; añade la enforzación de CRL y programa una ventana de cambio.

Tarea 3: Comprobar frescura de la CRL y siguiente actualización (inspección OpenSSL x509)

cr0x@server:~$ openssl crl -in /etc/openvpn/pki/crl.pem -noout -lastupdate -nextupdate
lastUpdate=Aug 28 08:55:01 2025 GMT
nextUpdate=Sep 04 08:55:01 2025 GMT

Qué significa: Las CRL tienen una ventana de validez. Si tu CRL está caducada, tu servidor puede rechazar a todos o aceptar demasiado, según la configuración.

Decisión: Si nextUpdate está en el pasado o demasiado en el futuro, arregla tu calendario de generación y distribución de CRL ahora.

Tarea 4: Asegurar que el proceso VPN puede leer el archivo CRL (permisos y sanity SELinux/AppArmor)

cr0x@server:~$ sudo ls -l /etc/openvpn/pki/crl.pem
-rw-r----- 1 root openvpn 1245 Aug 28 08:55 /etc/openvpn/pki/crl.pem

Qué significa: Si el demonio OpenVPN corre como grupo openvpn, esto es legible. Si no, las revocaciones pueden fallar silenciosamente.

Decisión: Si los permisos no permiten lectura, arréglalos; luego reinicia/recarga el servicio si tu versión de OpenVPN no vuelve a leer CRLs dinámicamente.

Tarea 5: Revocar un certificado cliente (ejemplo Easy-RSA) y regenerar CRL

cr0x@server:~$ cd /etc/openvpn/easy-rsa
cr0x@server:/etc/openvpn/easy-rsa$ sudo ./easyrsa revoke jdoe-laptop-2025
Using Easy-RSA configuration from: /etc/openvpn/easy-rsa/vars
Revoking Certificate: /etc/openvpn/pki/issued/jdoe-laptop-2025.crt
Certificate Revoked. Database updated.

cr0x@server:/etc/openvpn/easy-rsa$ sudo ./easyrsa gen-crl
Using Easy-RSA configuration from: /etc/openvpn/easy-rsa/vars
CRL file: /etc/openvpn/pki/crl.pem generated successfully.

Qué significa: La revocación actualiza la base de datos de la CA; generar la CRL la hace aplicable por servidores configurados para consultarla.

Decisión: Distribuye inmediatamente la nueva CRL a todos los servidores VPN (o asegúrate de que esté en almacenamiento compartido) y verifica que nuevas conexiones sean rechazadas.

Tarea 6: Validar que un cert revocado queda bloqueado (prueba cliente simulada)

cr0x@server:~$ sudo openvpn --config /tmp/jdoe-test.ovpn --verb 4
...
VERIFY OK: depth=1, CN=office-vpn-ca
VERIFY OK: depth=0, CN=vpn-server
TLS Error: TLS handshake failed
AUTH: Received control message: AUTH_FAILED,CRV1: certificate revoked
Exiting due to fatal error

Qué significa: El servidor está rechazando activamente el certificado revocado durante el handshake.

Decisión: Si la conexión tiene éxito, para e investiga la enforzación/distribución de CRL antes de afirmar que el usuario está offboarded.

Tarea 7: Matar una sesión cliente OpenVPN activa (ejemplo interfaz de management)

cr0x@server:~$ printf "status 3\nquit\n" | sudo nc -U /run/openvpn/office-mgmt.sock | sed -n '1,25p'
OpenVPN MANAGEMENT: Client connected from /run/openvpn/office-mgmt.sock
TITLE,OpenVPN 2.6.8 x86_64-pc-linux-gnu
TIME,Aug 28 11:12:40 2025,1756379560
HEADER,CLIENT_LIST,Common Name,Real Address,Virtual Address,Bytes Received,Bytes Sent,Connected Since
CLIENT_LIST,jdoe-laptop-2025,203.0.113.44:53412,10.8.0.42,1928831,2100440,Aug 28 09:11:02 2025
END

cr0x@server:~$ printf "kill jdoe-laptop-2025\nquit\n" | sudo nc -U /run/openvpn/office-mgmt.sock
SUCCESS: client-instance-killed

Qué significa: Enumeraste sesiones y terminaste un common name específico.

Decisión: Usa el kill de sesión como parte del offboarding y la respuesta a incidentes; no confíes en “ellos se desconectarán eventualmente”.

Tarea 8: Listar peers de WireGuard y último handshake (chequeo de realidad para acceso “revocado”)

cr0x@server:~$ sudo wg show wg0
interface: wg0
  public key: 6O1N3oOQmWvB7lq7mH2dQeGmU6u4VwV4y0G0rQvJm2k=
  listening port: 51820

peer: r6Q2V2qzQd7J0zC5cV0n9zq7p0cJw+u3p6rH7P3fN1c=
  preshared key: (hidden)
  endpoint: 198.51.100.19:45122
  allowed ips: 10.70.0.23/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 1.34 GiB received, 2.10 GiB sent

peer: oJ4oYg2m6mS7y0T2a6a0ZQ1i2b8tFhH0G5QzQ0hVQ1k=
  endpoint: (none)
  allowed ips: 10.70.0.88/32
  latest handshake: 9 days, 4 hours, 10 minutes ago
  transfer: 0 B received, 0 B sent

Qué significa: “Latest handshake” te dice quién está usando activamente el acceso. Los peers obsoletos son candidatos para limpieza o confirmación con managers.

Decisión: Si un usuario supuestamente offboarded aún tiene handshakes recientes, quita su peer inmediatamente e investiga cómo permaneció autorizado.

Tarea 9: Eliminar un peer de WireGuard y aplicar inmediatamente

cr0x@server:~$ sudo wg set wg0 peer r6Q2V2qzQd7J0zC5cV0n9zq7p0cJw+u3p6rH7P3fN1c= remove
cr0x@server:~$ sudo wg show wg0 | grep -n "peer:" -n
7:peer: oJ4oYg2m6mS7y0T2a6a0ZQ1i2b8tFhH0G5QzQ0hVQ1k=

Qué significa: El peer se quita de la interfaz en vivo. Si usas archivos de config, también actualízalos o el peer reaparecerá al reiniciar.

Decisión: Siempre acompaña la eliminación en tiempo de ejecución con gestión de configuración (Ansible, etc.). De lo contrario, tu revocación está a un reinicio de volver a fallar.

Tarea 10: Encontrar artefactos de usuario VPN obsoletos en disco (perfiles cliente, certs antiguos)

cr0x@server:~$ sudo find /etc/openvpn/clients -type f -name "*.ovpn" -mtime +90 -print
/etc/openvpn/clients/vendor1-temp.ovpn
/etc/openvpn/clients/old-intern.ovpn

Qué significa: Los configs cliente antiguos a menudo contienen certs/keys embebidos. Si perduran, se envían por email, se copian y se resucitan.

Decisión: Borra perfiles obsoletos tras la revocación y deja de distribuir perfiles que embeben claves privadas de larga duración cuando puedas evitarlo.

Tarea 11: Comprobar fallos de autenticación y patrones de fuerza bruta (PAM/puerta SSO o logs OpenVPN)

cr0x@server:~$ sudo journalctl -u openvpn-server@office -S -24h | egrep "AUTH_FAILED|TLS Error|VERIFY ERROR" | tail -n 12
Aug 28 02:11:09 vpn-1 openvpn[1423]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Aug 28 02:11:12 vpn-1 openvpn[1423]: VERIFY ERROR: depth=0, error=certificate revoked: CN=old-intern
Aug 28 03:44:01 vpn-1 openvpn[1423]: AUTH_FAILED,CRV1: bad username/password
Aug 28 03:44:04 vpn-1 openvpn[1423]: AUTH_FAILED,CRV1: bad username/password
Aug 28 03:44:08 vpn-1 openvpn[1423]: AUTH_FAILED,CRV1: bad username/password

Qué significa: Intentos con certs revocados son una buena señal (la revocación funciona). Fallos repetidos de auth pueden indicar credential stuffing o clientes rotos.

Decisión: Si los fallos aumentan, habilita rate limiting, revisa la aplicación de MFA y confirma que el acceso condicional del IdP se aplica a las autenticaciones VPN.

Tarea 12: Confirmar que el enrutamiento y la política de firewall coinciden con el acceso previsto (evitar túnel completo accidental)

cr0x@server:~$ ip route show table main | sed -n '1,12p'
default via 192.0.2.1 dev eth0 proto dhcp src 192.0.2.10 metric 100
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
10.20.0.0/16 via 10.8.0.2 dev tun0
10.30.5.0/24 via 10.8.0.2 dev tun0

cr0x@server:~$ sudo nft list ruleset | sed -n '1,40p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    iif "tun0" oif "eth0" ip daddr 10.20.0.0/16 accept
    iif "tun0" oif "eth0" ip daddr 10.30.5.0/24 accept
    counter drop
  }
}

Qué significa: Las rutas y reglas de firewall definen qué pueden alcanzar los clientes VPN. Tener policy drop está bien; los allow explícitos son mejores.

Decisión: Si ves reenvío permisivo o rutas inesperadas, corrige el alcance antes de rotar credenciales—si no, estarás asegurando lo equivocado.

Tarea 13: Detectar usuarios “huérfanos”: en la configuración pero no en el grupo IdP (ejemplo simple basado en texto)

cr0x@server:~$ sudo awk -F, '/^CLIENT_LIST/ {print $2}' /var/log/openvpn-status.log | sort -u
asmith-macbook
jdoe-laptop-2025
vendor1-temp

cr0x@server:~$ cat /etc/vpn/approved-users.txt
asmith-macbook
jdoe-laptop-2025

Qué significa: vendor1-temp se conectó pero no está en la lista aprobada (ejemplo de reconciliación con pertenencia a grupos IdP).

Decisión: Trata esto como un incidente de deriva de políticas. Investiga cómo existe la credencial y revoca si no está explícitamente aprobada.

Tarea 14: Verificar fechas de expiración de certificados para hacer cumplir la cadencia de rotación

cr0x@server:~$ openssl x509 -in /etc/openvpn/pki/issued/asmith-macbook.crt -noout -subject -enddate
subject=CN=asmith-macbook
notAfter=Nov 15 09:01:12 2025 GMT

Qué significa: Tienes una fecha límite concreta. La expiración es un control de rotación, no un accidente.

Decisión: Si ves expiraciones de varios años en certificados de usuario final, acórtalos e implementa automatización de renovación. Los certs de larga vida son deuda silenciosa.

Tarea 15: Confirmar comportamiento DNS para clientes VPN (fuente común de reclamos “la VPN está caída”)

cr0x@server:~$ resolvectl status tun0 | sed -n '1,25p'
Link 9 (tun0)
      Current Scopes: DNS
DefaultRoute setting: no
       LLMNR setting: no
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 10.20.0.53
         DNS Servers: 10.20.0.53 10.20.0.54
          DNS Domain: corp.example

Qué significa: El DNS está acotado al túnel y apunta a resolvers internos. Si esto es incorrecto, los usuarios pueden “conectarse” pero nada interno resuelve.

Decisión: Arregla el DNS antes de perseguir fantasmas de enrutamiento. La mayoría de los tickets “la VPN no funciona” son realmente “DNS inconsistente”.

Guion de diagnóstico rápido

Cuando la VPN “está caída” o “la revocación no funcionó”, no tienes tiempo para un debate filosófico sobre redes. Revisa lo siguiente en orden.
El objetivo es encontrar el cuello de botella rápido y detener la hemorragia.

Primero: ¿puede alguien autenticarse?

• Revisa la salud del servidor: proceso arriba, CPU/memoria sane, disco no lleno.
• Revisa el backend de auth: IdP accesible, sincronización de tiempo correcta (skew de reloj mata TLS y validación de tokens).
• Revisa logs por fallos generales: errores de TLS handshake, server cert expirado, CRL caducada.

Segundo: ¿las sesiones establecidas son estables?

• Busca reconexiones masivas, timeouts de inactividad, problemas de MTU (muchos retransmisos).
• Revisa pérdida de paquetes y path MTU, especialmente tras cambios de ISP/firewall.
• Confirma que la interfaz del túnel esté arriba y que las rutas estén presentes.

Tercero: ¿la autorización/política es el problema real?

• Verifica que el usuario esté en el grupo correcto y que la política se aplique.
• Confirma que las reglas de firewall permiten los destinos correctos (y nada más).
• Revisa el acotamiento DNS y la alcanzabilidad de los resolvers internos.

Cuarto: ¿la revocación realmente se propagó?

• Confirma timestamp de actualización de la CRL y nextUpdate.
• Confirma que cada servidor VPN tiene la misma CRL (comparar hashes).
• Confirma que las sesiones activas fueron terminadas (si era requerido).

Errores comunes: síntomas → causa raíz → solución

1) “Revocamos el cert, pero el usuario aún puede conectar”

Síntomas: el CN revocado aún se autentica; los logs muestran TLS handshake exitosos.

Causa raíz: CRL no aplicada, CRL no desplegada en todas partes, o el servidor no vuelve a leer la CRL (requiere restart/reload).

Solución: forzar crl-verify, distribuir CRL vía gestión de configuración, monitorizar frescura de CRL y probar revocación con un certificado conocido revocado.

2) “El usuario dado de baja no puede autenticarse, pero su túnel sigue activo”

Síntomas: IdP muestra cuenta deshabilitada; el usuario aún accede a recursos internos desde una IP del pool VPN.

Causa raíz: sesión no terminada; la VPN no re-authentica con frecuencia; vidas de sesión largas.

Solución: implementar kill explícito de sesiones en el offboarding, limitar duración de sesiones y requerir re-auth/renegociación periódica donde sea compatible.

3) “La VPN funciona para algunos usuarios, otros obtienen fallos aleatorios”

Síntomas: errores intermitentes de conexión; algunas redes fallan; hotspots móviles “lo arreglan”.

Causa raíz: problemas de MTU/fragmentación, UDP bloqueado en ciertas redes, o cambios de ruta tras actualizaciones de firewall.

Solución: estandarizar ajustes de MTU, ofrecer fallback TCP si es necesario, monitorizar retransmisos y probar desde redes limitadas (el Wi‑Fi de hotel es un gran laboratorio).

4) “Todos se conectan pero los nombres internos no resuelven”

Síntomas: túnel arriba; conectividad IP a IPs internas conocida funciona; los nombres no resuelven.

Causa raíz: DNS no empujado, split DNS mal configurado, resolver inaccesible a través de la VPN, o el SO cliente ignora el DNS empujado.

Solución: aplicar la configuración DNS vía perfiles cliente/MDM, verificar la alcanzabilidad del resolver y probar con resolvectl / dig.

5) “El día de rotación provocó un outage”

Síntomas: fallos masivos de auth justo después de cambios de cert/key; clientes en bucle de reconexión.

Causa raíz: cert de servidor reemplazado sin distribuir nueva cadena CA, clientes fijando el cert viejo, o ventana de solapa no implementada.

Solución: despliegue escalonado: desplegar cadena CA nueva primero, solapar certs de servidor si es posible, comunicar requisitos de actualización a clientes y monitorizar tasas de éxito de conexión.

6) “Borramos un peer de WireGuard, pero volvió”

Síntomas: peer eliminado en vivo; tras reboot/restart reaparece.

Causa raíz: archivo de config persistente aún contiene el peer; la gestión de configuración lo reaplica.

Solución: trata los cambios en tiempo de ejecución como temporales; actualiza la fuente de la verdad (Git/CM) y redeploya limpiamente.

7) “El acceso de un contratista perdura meses”

Síntomas: existen peers/certs de personas que nadie reconoce; el último handshake es reciente.

Causa raíz: no hay mecanismo de acceso con tiempo limitado; no hay revisiones periódicas de acceso; las excepciones se vuelven permanentes.

Solución: exigir expiraciones en accesos no empleados, ejecutar reconciliaciones mensuales y obligar a los managers a re-aprobar explícitamente.

Listas de verificación / plan paso a paso

Checklist de incorporación limpia (VPN de oficina)

1. Crear usuario en IdP; exigir MFA; exigir cumplimiento del dispositivo si está disponible.
2. Añadir usuario a grupo(s) elegibles para VPN según rol. Evitar grupos “temporales” sin expiración.
3. Emitir credenciales:
   • Preferido: auth basada en SSO con credenciales/tokens de cliente de corta duración.
   • Alternativa: cert de cliente con vida de 30–90 días más flujo de renovación.
4. Asignar rutas y DNS con principio de menor privilegio. Denegar por defecto en firewall; permitir solo subredes/servicios necesarios.
5. Registrar y verificar: una conexión de prueba, confirmar que los logs muestran identidad y IP VPN asignada.
6. Documentar propiedad: qué equipo aprueba futuras expansiones de acceso.

Plan de rotación programada (cadencia trimestral es un buen comienzo)

1. Decidir qué rota en este ciclo: certs cliente, cert servidor, peers WireGuard, PSKs.
2. Montar material nuevo en paralelo:
   • Generar nuevos certs/keys.
   • Distribuir por canal seguro (MDM, gestor de secretos, gestión de dispositivos).
   • Mantener la ventana de solapa corta y monitorizada.
3. Desplegar CRL/listas de peers actualizadas a todos los servidores y verificar checksums coincidentes entre nodos.
4. Monitorizar tasas de éxito/fallo de conexión durante el despliegue; detener si las fallas aumentan.
5. Tras la ventana de solapa, deshabilitar credenciales antiguas y limpiar artefactos.
6. Ejecutar una auditoría de acceso: configurado vs observado vs deseado.

Checklist de offboarding (hazlo rápido y final)

1. Deshabilitar identidad en IdP inmediatamente.
2. Revocar credenciales:
   • Para certs: revocar + generar CRL + distribuir.
   • Para WireGuard: eliminar peer de la interfaz en vivo + quitar de la fuente de verdad de la configuración.
3. Terminar sesiones activas (por CN/usuario/clave de peer) y confirmar la desconexión en logs.
4. Invalidar confianza de dispositivo si aplica (wipe MDM / quitar cumplimiento / revocar cert de dispositivo).
5. Buscar y borrar perfiles cliente obsoletos almacenados centralmente.
6. Registrar evidencia: timestamp, operador, qué se revocó, resultado de la verificación.

Flujo de incidentes: sospecha de compromiso de credenciales

1. Contener: matar sesiones, revocar credenciales específicas y si hace falta restringir temporalmente rutas VPN al mínimo para respuesta a incidentes.
2. Confirmar propagación: consistencia de CRL/lista de peers en servidores VPN.
3. Hunt: revisar logs por IPs de primera aparición, patrones de viaje imposibles, transferencias de datos inusuales.
4. Recuperar: emitir nuevas credenciales, requerir re-enrolamiento de MFA y revisar membresías de grupos.
5. Prevenir: acortar vidas, añadir checks de postura y automatizar triggers de offboarding.

Tres micro-historias de la vida corporativa

1) Incidente causado por una suposición errónea: “Deshabilitar la cuenta es suficiente”

Una empresa mediana operaba una SSL VPN ligada a su IdP para logins de empleados. Estaban orgullosos. “No más usuarios VPN locales”, decían, y no estaban equivocados.
El offboarding era una única casilla en el IdP: deshabilitar al usuario. Ticket cerrado. Manager contento.

Un ingeniero saliente tenía un portátil de la empresa que se mantuvo encendido días después de su último día. No fue malintencionado—solo la realidad moderna del modo suspensión, reconexiones automáticas
y un cliente VPN al que le encantaba “sempre activo”. La deshabilitación en el IdP evitó nuevos logins, pero el túnel existente siguió fluyendo porque la pasarela VPN no re-authentica a mitad de sesión,
y nadie terminaba sesiones en el offboarding.

Salió a la luz cuando una alerta de monitoreo interno mostró acceso al repositorio de código desde una IP que pertenecía al pool VPN. Los logs del repo decían que era el dispositivo del ingeniero
continuando el sync. El equipo de seguridad asumió compromiso; el equipo de TI asumió que el monitoreo estaba equivocado; el ingeniero asumió que nada de esto era su problema ya.
Todos tenían razón y al mismo tiempo estaban perdiendo el punto.

Arreglarlo fue aburrido y efectivo: implementar terminación de sesiones durante el offboarding, limitar la vida de sesión y añadir un job diario que enumerara sesiones vinculadas a usuarios deshabilitados.
También empezaron a registrar “evidencia de verificación” en el ticket de offboarding: “usuario no puede autenticarse” y “sesión activa terminada”.

La lección real no fue “la gente es mala”. La lección fue que identidad no es lo mismo que estado de sesión. Una cuenta deshabilitada no cancela retroactivamente paquetes ya en vuelo.

2) Optimización que salió mal: “Reducamos carga extendiendo vidas de certificados”

Otra organización tenía un OpenVPN con certs cliente que expiraban cada 30 días. La renovación estaba semi-automatizada pero generaba ruido en helpdesk: usuarios de vacaciones,
portátiles que no hacían check-in, contratistas que olvidaban que tenían VPN hasta el día que la necesitaban.

Alguien propuso una “optimización simple”: extender la vida de certs cliente a dos años. Menos renovaciones, menos tickets, menos overhead operacional de la CA. En papel parecía genial.
Se desplegó rápido, lo cual debería haber sido la primera señal de alarma.

Seis meses después, robaron el portátil de un contratista. El cert estaba embebido en un perfil exportado, por conveniencia. Revocaron el cert y generaron una CRL,
pero uno de los nodos secundarios VPN no había recibido la nueva CRL debido a una falla silenciosa en la gestión de configuración. El portátil robado conectó a través del nodo con CRL obsoleta.
La org ahora tenía una credencial de larga duración con un modo de fallo también de larga duración.

El trabajo post-incidente fue predecible: acortar nuevamente la vida de certs, automatizar la renovación correctamente e implementar monitorización que comparara checksums de CRL entre nodos.
También dejaron de embeder claves privadas en perfiles fácilmente exportables a menos que el dispositivo estuviera totalmente gestionado y la clave en un keystore protegido.

Extender vidas de credenciales redujo la carga de helpdesk. También extendió la ventana temporal en la que tus errores siguen siendo explotables. Adivina cuál importó más.

3) Práctica aburrida pero correcta que salvó el día: “Conciliación mensual de accesos y expiraciones”

Una empresa grande con múltiples oficinas tenía una VPN de acceso remoto basada en WireGuard para un subconjunto de sistemas de ingeniería. No tenían branding “zero trust” fancy.
Tenían disciplina: cada entrada de peer no-empleado requería una fecha de expiración, y un trabajo mensual de reconciliación generaba un informe: peers sin handshake en 60 días,
peers pasados de expiración y peers no ligados a un ticket activo.

Era aburrido. También impopular, porque generaba trabajo. Cada mes alguien tenía que preguntar “¿seguimos necesitando esto?” y alguien tenía que responder sin encogerse de hombros.
Pero el proceso creó un hábito: el acceso es temporal a menos que se re-justifique.

Un mes, el informe señaló un peer de contratista que había tenido un handshake en la última hora pero cuyo plazo aprobado había expirado. El manager asumió que era un bug del reporte.
El equipo VPN removió el peer de todas formas y preguntó después, porque la política es la política.

Las credenciales del contratista habían sido copiadas a una máquina personal “por conveniencia” tras terminar su contrato. Cuando dejó de funcionar, el intento se volvió visible.
RR. HH. y seguridad hicieron seguimiento, y la org evitó una situación embarazosa donde el acceso correcto existía para la persona equivocada en el momento equivocado.

Nada de heroísmos. Ninguna herramienta milagrosa. Solo una práctica recurrente, documentada y aplicable que trató el acceso como inventario en vez de folklore.

Preguntas frecuentes

1) ¿Con qué frecuencia debemos rotar credenciales cliente VPN?

Apunta a vidas de 30–90 días para certs cliente si puedes automatizar la renovación. Si no puedes, empieza en 180 días y acorta conforme mejore la automatización.
Para claves estáticas (WireGuard), rota en cambios de rol, offboarding y cualquier sospecha; si no, programa rotación anual con una ventana de solapa ajustada.

2) ¿Revocar en el IdP es suficiente?

Evita nuevos eventos de autenticación vía IdP. No necesariamente termina sesiones activas, y no cubre credenciales no-IdP (certs/keys) a menos que esté integrado.
El offboarding necesita deshabilitar identidad + revocar credencial + terminar sesiones.

3) ¿Deberíamos usar CRL u OCSP para revocación de certificados VPN?

Las CRL son operativamente más simples y funcionan bien con certs de corta duración. OCSP ofrece estado más fresco pero introduce dependencia en un responder en línea.
Elige CRL a menos que estés preparado para operar OCSP como un servicio de producción con monitorización y redundancia.

4) ¿Cuál es la forma más limpia de manejar contratistas?

Acceso con tiempo limitado. Siempre. Usa grupos y políticas separados, exige expiraciones y realiza revisiones mensuales.
Si no puedes adjuntar una solicitud de acceso y una expiración, no tienes un flujo para contratistas—tienes un hallazgo de auditoría futuro.

5) ¿Cómo prevenimos el intercambio de credenciales entre empleados?

Usa credenciales individuales ligadas a identidad, exige MFA y añade checks de postura de dispositivo. También monitoriza viajes imposibles y sesiones concurrentes desde ubicaciones distantes.
Técnicamente, ligar el acceso a dispositivos gestionados ayuda más que escribir políticas que la gente no leerá.

6) ¿Necesitamos rotar también el certificado del servidor VPN?

Sí. Rota certificados de servidor según un calendario y ante cualquier sospecha. Mantén la CA estable y rota certificados de servidor más frecuentemente.
Si haces pin del certificado de servidor en clientes, planifica solapas cuidadosamente o te causarás un outage auto-infligido.

7) ¿Cuál es el mínimo de logging para auditorías y respuesta a incidentes?

Éxitos/errores de auth, inicio/fin de sesión, identidad mapeada, IP VPN asignada, IP pública del cliente y acciones de admin (revocaciones/cambios de política).
Si tus logs no pueden atar una sesión a una identidad humana o al menos a una credencial única, estarás ciego cuando importe.

8) ¿Cómo manejamos dispositivos perdidos?

Trátalo como un compromiso hasta que se demuestre lo contrario: revoca la credencial VPN del dispositivo, termina sesiones e invalida la confianza del dispositivo en MDM.
Luego re-emite credenciales en un nuevo dispositivo después de re-validación MFA.

9) ¿Split tunnel o full tunnel para VPN de oficina?

Split tunnel reduce carga y suele mejorar la experiencia del usuario, pero aumenta el riesgo de rutas de exfiltración y fugas DNS si se hace mal.
Full tunnel es más simple de razonar pero consume ancho de banda y puede romper acceso a SaaS. Decide según el modelo de amenaza y madurez operacional—y luego aplícalo consistentemente.

10) ¿Cuál es la mejor forma de probar que la revocación funcionó?

Intenta una conexión con la credencial revocada y verifica que el servidor la rechace (evidencia en logs). También confirma que la sesión activa del usuario desapareció y no puede restablecerse.
“Corrí el comando de revocar” no es prueba; es una esperanza con timestamps.

Conclusión: siguientes pasos que realmente reducen el riesgo

La gestión de usuarios VPN de oficina no es una configuración única. Es un ciclo de vida: emisión, rotación, revocación, verificación y auditoría. Hazlo bien y la VPN se vuelve aburrida.
Aburrido es bueno. Aburrido significa predecible.

Siguientes pasos que puedes ejecutar esta semana:

1. Implementar un runbook verificado de offboarding: deshabilitar identidad, revocar credencial, matar sesión y luego probar el fallo con evidencia.
2. Acortar vidas de credenciales a un número que puedas soportar operativamente; automatiza la renovación en lugar de extender expiraciones para evitar tickets.
3. Auditar configurado vs observado vs deseado mensualmente. Encuentra los fantasmas antes de que aparezcan en un incidente.
4. Estandarizar enrutamiento “least privilege VPN” con denegación por defecto en forwarding y allows explícitos.
5. Añadir monitorización para propagación de revocación: frescura de CRL, consistencia de checksum de CRL entre nodos y alertas en intentos de conexión con certificados revocados.

Tu VPN no necesita ser perfecta. Necesita ser operable bajo estrés y honesta sobre lo que puede y no puede garantizar. Construye eso y dormirás más.
O al menos te despertarán por menos problemas evitables, que es lo más parecido a la paz en producción.