Arquitectura de acceso remoto segura: WireGuard, VPN-HA, diseño de bastión SSH y registro de accesos en la práctica

El acceso remoto en muchos entornos no es un “nice-to-have”, sino una realidad operativa: guardias, proveedores externos, ubicaciones distribuidas, operación mixta Cloud y on‑prem. Al mismo tiempo, el acceso remoto es uno de los vectores de entrada más frecuentes, porque salva límites que internamente funcionan mediante segmentación, zonas de firewall y controles de identidad. Una arquitectura segura de Remote-Access es por tanto menos una herramienta aislada que una interacción robusta entre ruta de red, identidad, control y trazabilidad.

Esta entrada describe una arquitectura de referencia práctica basada en WireGuard (VPN ligero con primitivas criptográficas modernas), VPN-HA (High Availability, es decir, operación redundante con conmutación por error), SSH-Bastion-Design (Jump Host como punto de entrada controlado) y Access-Logging (registro para auditoría y seguridad). El enfoque está en la operación, los puntos críticos, los pasos de verificación, la estrategia de recuperación y en el “por qué” detrás de las medidas —para que la arquitectura no solo funcione en el día a día, sino que además sea auditable y apta para la gestión de incidentes.

arquitectura segura de Remote-Access: panorama de amenazas y suposiciones típicas

El Remote Access rara vez falla por el cifrado, sino por condiciones de contorno: redes demasiado amplias, claves con vida excesivamente larga, demasiados destinos directos y ausencia de protocolos. Causas típicas de incidentes de seguridad y hallazgos en auditorías:

• Redes VPN planas: Una vez que un cliente está “en la LAN”, alcanza demasiado. El movimiento lateral se facilita.
• Accesos administrativos directos a servidores (SSH/RDP) sin un punto de control central: difícil de asegurar, difícil de registrar, difícil de bloquear.
• Identidad poco clara: falta el vínculo entre dispositivo y usuario, las claves se comparten, existen cuentas administrativas locales en paralelo.
• Alta disponibilidad sin enfoque de seguridad: se implementa failover mediante IPs flotantes o Anycast, pero el registro, el estado y la gestión de claves se rompen durante el cambio.
• Registro solo “para después”: sin correlación (tiempo, origen, destino, usuario) los logs son prácticamente inútiles en un incidente.

Un principio importante: “VPN = interno” es un anti‑patrón. Un VPN es solo un canal de transporte seguro. La política de acceso real debe seguir basarse en segmentación, reglas de firewall y controles de identidad.

Imagen objetivo: Componentes de una arquitectura segura de Remote-Access

Un objetivo robusto tiene cuatro niveles claramente separados:

• Transporte: túneles WireGuard entre cliente y gateway (cifrado, autenticación de pares).
• Control de acceso: firewall/política en el gateway y en las redes de destino (Least Privilege, es decir, los derechos mínimos necesarios).
• Punto de entrada administrativo: SSH-Bastion/Jump Host como ruta controlada hacia destinos administrativos.
• Trazabilidad: registro de acceso centralizado, resistente a manipulaciones, correlacionable; grabación de sesiones opcional.

Adicionalmente corresponden MFA (autenticación multifactor) para el acceso inicial, un claro Key-/Device-Lifecycle (Onboarding/Offboarding), así como un probado Failover- und Rückfallplan.

WireGuard en la práctica: segmentar de forma limpia en lugar de “rutarlo todo”

WireGuard es un protocolo VPN y una implementación basada en un conjunto reducido de criptografía moderna que funciona como módulo de kernel o de forma cercana al sistema. Administrativamente importante: WireGuard es de bajo estado (no mantiene „sesiones“ pesadas como los SSL-VPN clásicos) y se configura mediante peers fijos. Eso es estable, pero también incita a enrutar redes de forma demasiado amplia.

Direccionamiento y AllowedIPs: la palanca de riesgo más frecuente

En WireGuard, AllowedIPs es a la vez la definición de enrutamiento y una especie de „ACL ligera“: qué redes de destino se enrutan a través del túnel (lado cliente) y qué rangos de IP de origen puede „poseer“ un peer (lado servidor). Patrones de error:

• 0.0.0.0/0 (Full Tunnel) por comodidad: puede estar bien, pero aumenta la dependencia del VPN y complica la búsqueda de fallos.
• Redes internas demasiado grandes en AllowedIPs: permite el acceso a sistemas que no están pensados para acceso remoto.
• Solapamiento de IP con redes domésticas o redes de socios: conduce a problemas de enrutamiento del tipo „a veces funciona“.

Es recomendable una subred VPN dedicada por grupo de usuarios o propósito (p. ej. administradores, cuentas de servicio, proveedores externos). Con ello puede separar claramente políticas y registro.

Patrón de configuración: servidor WireGuard con alcance de peer RESTrictivo

Como ejemplo, una interfaz de servidor WireGuard (Linux). El punto no es tanto la sintaxis como el patrón: red VPN propia, ganchos de registro/firewall, sin „catch-all“.

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.60.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>

# Optional: beim Up/Down Firewall-Regeln setzen
PostUp = nft add rule inet filter forward iifname "wg0" oifname "lan0" ip daddr { 10.10.20.0/24 } tcp dport { 22, 3389 } accept
PostUp = nft add rule inet filter forward iifname "wg0" drop
PostDown = nft flush chain inet filter forward

[Peer]
# Admin-Laptop 01
PublicKey = <CLIENT_PUBLIC_KEY>
AllowedIPs = 10.60.0.10/32
PersistentKeepalive = 25

Importante: AllowedIPs en el lado servidor por peer sólo /32 (una IP de túnel). Qué redes de destino son accesibles conviene decidirlo mediante firewall/política en el gateway y en los segmentos de destino —no mediante rutas „amistosas“.

MTU, NAT y roaming: escollos típicos en la operación

• Problemas de MTU: cuando se trabaja sobre DSL/PPPoE, LTE o a través de otros túneles, la fragmentación puede hacer que paquetes se pierdan „silenciosamente“. Síntoma: SSH conecta, pero SFTP se queda colgado; RDP va lento. Enfoque: reducir la MTU en la interfaz de WireGuard (habitualmente 1380 o 1420, según el trayecto) y probar con ping/DF.
• NAT y redes cambiantes: los clientes móviles se benefician de PersistentKeepalive; si no, los mapeos NAT „se duermen“.

VPN-HA: Aumentar la disponibilidad sin perder el control

VPN High Availability significa: la caída de un gateway no debe detener la operación remota. En la práctica existen tres vías habituales, que afectan de forma distinta al registro, al material de claves y al troubleshooting.

Opción A: IP flotante / VRRP (clásico, fácil de seguir)

Con VRRP (Virtual Router Redundancy Protocol, frecuentemente mediante keepalived) una IP flotante pasa al nodo activo en el failover. Ventaja: los clientes mantienen un endpoint estable (DNS/IP). Inconvenientes: necesita sincronización limpia de estado/configuración y hay que tener en cuenta que WireGuard es de bajo estado, pero los peers y las claves deben estar configurados de forma idéntica.

Ejemplo mínimo keepalived (Atención: ajustar según la distribución/configuración de red):

# /etc/keepalived/keepalived.conf
vrrp_instance VPN {
  state BACKUP
  interface eth0
  virtual_router_id 60
  priority 100
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass <STRONG_RANDOM>
  }
  virtual_ipaddress {
    203.0.113.10/32
  }
}

Puntos críticos en configuraciones con IP flotante:

• Caches ARP/NDP: Con IPv4/IPv6 puede tardar minutos hasta que todas las redes vean el nuevo maestro. Planifique GARP/Gratuitous Neighbor Advertisements.
• Estado en firewalls: Las firewalls con estado/NAT pueden perder flujos existentes. En accesos de administración suele ser aceptable, pero debe constar en los runbooks.
• Identidad en los logs: Si ambos nodos son visibles bajo la misma IP virtual (VIP), debe registrar de forma clara las IDs de nodo en los logs (hostnames, etiquetas de agente).

Opción B: Failover por DNS (sencillo, pero dependiente del tiempo)

El failover por DNS con TTL corto puede funcionar, pero en incidentes y con caches de proveedores es poco fiable. Para acceso de administración el failover por DNS suele ser la segunda opción, salvo que disponga de un cliente controlado (p. ej. portátiles corporativos con resolver definido).

Opción C: Anycast / Balanceador de carga (potente, pero conceptualmente más exigente)

Anycast o un balanceador de carga frontal puede resolver HA de forma elegante, pero introduce nuevas preguntas: el balanceo UDP (WireGuard usa UDP) debe funcionar correctamente, la observabilidad se complica, y con distribución L4 debe planificarse correctamente el manejo de la IP de origen para registros y políticas.

Lista de verificación HA: lo que debe probar antes de la puesta en producción

• Failover bajo carga: sesiones SSH activas, conexiones simultáneas, resolución DNS.
• Reincorporación/Failback: el retorno al nodo primario no debe producir „flapping“ (conmutaciones frecuentes).
• Deriva de configuración: los peers, las policies y las reglas de firewall deben estar versionados de forma idéntica (p. ej. vía Git y CI para despliegues de configuración).
• Continuidad de logs: ambos Nodes envían logs a un punto central; la hora/NTP está sincronizada.

Diseño de bastión SSH: punto de entrada controlado en lugar de „SSH en todas partes“

Un SSH-Bastion Host (también Jump Host) es un servidor endurecido que actúa como único punto de entrada SSH a un segmento de administración. El valor es operativo: se refuerza un nodo de forma exhaustiva, se exige la identidad, se agrupan las políticas y se obtienen logs consistentes. Al mismo tiempo se reduce la superficie de ataque expuesta: los sistemas objetivo no tienen por qué ser accesibles directamente desde la VPN.

Modelo de red y de zonas: así el bastión resulta eficaz

El bastión suele ubicarse en una zona propia (p. ej. „Admin-Access“ o „Management“). Reglas que han demostrado su eficacia:

• Los clientes VPN deben solo conectarse al bastión (TCP/22) y, en su caso, a un proxy de Identity/MFA.
• Desde el bastión los destinos son accesibles solo por puertos de gestión (SSH, WinRM, RDP vía gateway, Out-of-Band solo en casos de emergencia).
• Se evita el acceso VPN directo a los workloads de producción; las excepciones se documentan y se regulan estrictamente.

Endurecimiento del bastión: los elementos clave

En el bastión, a menudo pocas medidas determinan si es „auditable“ o „esperamos que lo sea“. Elementos centrales:

• No SSH con contraseña: exclusivamente Public-Key, idealmente con claves basadas en hardware (FIDO2/PKCS#11) o certificados de corta duración.
• MFA antes de SSH: p. ej. mediante integración SSO/IdP o módulos PAM; lo importante es que una clave robada del portátil por sí sola no sea suficiente.
• No usar cuentas compartidas: cada administrador usa identidad personal; sudo se audita.
• Reglas egress RESTrictivas: el bastión no debe poder conectarse indiscriminadamente a Internet; si se compromete, se convierte en un trampolín.
• Disciplina de parches y reinicios: el bastión es Tier-0 para el acceso administrativo, por tanto actualizarlo con prioridad y planificar ventanas de reinicio.

Configuración SSH: valores predeterminados claros, pocas sorpresas

Ejemplo de una configuración sshd conservadora (extracto). Objetivo: prohibiciones claras, controlar explícitamente el forwarding y mantener los logs con información útil. Según el entorno puede ser más estricta o más flexible.

# /etc/ssh/sshd_config (Auszug)
Port 22
Protocol 2
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no
GatewayPorts no

ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE

# Optional: nur definierte Gruppen
AllowGroups it-admins it-ops

¿Por qué „LogLevel VERBOSE“? Con ello sshd escribe más contexto (p. ej. huella de la clave), lo que ayuda en el análisis forense si las claves están comprometidas. Al mismo tiempo debe tener en cuenta el volumen de registros y los requisitos de protección de datos (datos personales).

Riesgo: SSH-Agent-Forwarding y Port-Forwarding

Muchos administradores usan Agent-Forwarding como función de comodidad. Riesgo: si la Bastion se compromete, un atacante puede abusar del agente reenviado. Igual de crítico es el TCP-Forwarding (local/remoto/dinámico), porque elude las políticas y crea túneles inesperados. Un diseño seguro por defecto es: Forwarding desactivado por defecto, y las excepciones se permiten de forma selectiva por grupo o host – incluyendo registro y fecha de caducidad.

Access-Logging: de «VPN encendido/apagado» a pistas de auditoría fiables

Para muchos, Access-Logging significa únicamente «quién se ha conectado». Para operación e Incident Response necesita más: quién (identidad), desde dónde (dispositivo/peer, red origen), cuándo (hora, zona horaria, correlación), a dónde (sistema/puerto destino), y, en el mejor de los casos, qué (metadatos de sesión o grabación).

Qué fuentes de registros necesita como mínimo

• WireGuard-Gateway: handshake de peer, paquetes permitidos/denegados (firewall), eventos de interfaz.
• Bastion: SSH-Auth, sudo, inicio/fin de sesión; grabación de sesión opcional (TTY-Recording).
• Sistemas destino: inicios de sesión exitosos y fallidos, acciones privilegiadas, en su caso registros RDP/WinRM.
• Identity Provider: eventos MFA, emisión de tokens, cambios de roles/grupos.

Técnicamente es crucial que todos los sistemas estén síncronizados en el tiempo (NTP/chrony). Sin marcas temporales consistentes, la correlación en SIEM/Log-Search es costosa e poco fiable.

Reenvío central de registros: robusto frente al Backpressure

En operación, el logging suele fallar por «Backpressure» (el receptor de logs es lento o está caído). Entonces se pierden eventos o los sistemas se bloquean. Son recomendables agentes/forwarders con cola (p. ej. rsyslog con Disk-Queue). Ejemplo: rsyslog con encolamiento persistente para el reenvío seguro a un colector central (detalles TLS omitidos, ya que la PKI varía según el entorno).

# /etc/rsyslog.d/60-remote-access.conf
module(load="imjournal")

# Persistente Queue für Ausfälle des Collectors
action(type="omfwd"
       target="log-collector.intern"
       port="6514"
       protocol="tcp"
       StreamDriver="gtls"
       StreamDriverMode="1"
       StreamDriverAuthMode="anon"
       action.resumeRetryCount="-1"
       queue.type="LinkedList"
       queue.filename="q_remote_access"
       queue.maxdiskspace="2g"
       queue.saveonshutdown="on")

Nota: StreamDriverAuthMode=“anon“ se muestra aquí únicamente como marcador de posición. En entornos productivos debería usar comprobación de certificado de servidor y, idealmente, mTLS (autenticación TLS mutua), para que los registros no acaben en manos equivocadas ni en destinos incorrectos.

Qué debería poder correlacionarse como mínimo en SIEM/sistema de búsqueda

• IP del peer VPN ↔ dispositivo/usuario (mapeo de activos e identidades)
• Login en la Bastion ↔ login en el host destino (relación de salto)
• sudo/acciones privilegiadas ↔ tickets de cambio/tickets de incidentes (procesal)
• Fallos y anomalías (p. ej. países nuevos, horarios inusuales, nuevos destinos)

Pasos de implementación: un plan de despliegue pragmático

Un error frecuente es «Big Bang»: cambiar VPN, Bastion y registro al mismo tiempo. Es más estable un despliegue iterativo que permita opciones de retroceso.

Fase 1: Establecer fundamentos de red y políticas

• Definir subredes VPN (por persona/socio/caso de uso).
• Identificar segmentos objetivo (red de gestión vs. red de aplicaciones vs. red de bases de datos).
• Diseñar reglas de firewall: desde la VPN solo hacia la Bastion; desde la Bastion solo a los puertos de gestión.
• Planificar resolución de nombres (DNS interno sobre túnel, documentar claramente Split DNS).

Fase 2: Poner el gateway WireGuard en producción

• Versionar la configuración (Git), hacer reproducible el despliegue.
• Monitorización: estado del interfaz (up/down), accesibilidad del puerto UDP, pérdidas de paquetes, CPU/memoria.
• Probar y fijar la MTU; verificar roaming con redes móviles.

Fase 3: Introducir la Bastion y eliminar el acceso directo

• Desplegar la Bastion hardened, acceso solo desde las subredes VPN.
• Reconfigurar los sistemas objetivo para que SSH solo esté permitido desde la Bastion/red de gestión.
• Probar los flujos de trabajo de administración (scp/rsync/ansible), sin permitir atajos de reenvío (forwarding).

Fase 4: Centralizar el registro de accesos y responder a preguntas de auditoría

• Activar Log-Forwarder con cola.
• Dashboards/consultas: «¿Quién accedió a qué host y cuándo?»
• Aclarar retención y control de acceso sobre los logs (los logs son sensibles).

Pasos de comprobación y resolución de problemas: cuando no funciona como en el diagrama

Para el acceso remoto debería disponer de un runbook breve que funcione también en un incidente bajo estrés. Secuencias de comprobación prácticas:

1) Disponibilidad y Handshake (Gateway)

# WireGuard-Status
sudo wg show

# Interface-Details
ip -brief address show wg0
ip route show table main | grep -E "10.60.0.0/24|wg0"

Si faltan handshakes: comprobar puerto UDP/firewall, NAT/Keepalive, claves incorrectas, deriva de tiempo (en sistemas que enlazan mecanismos de autenticación adicionales).

2) Ruta y políticas (Firewall/Segmentación)

# Paketfilter prüfen (nftables Beispiel)
sudo nft list ruleset

# Drops im Kernel (je nach Setup)
sudo journalctl -k --since "15 min ago" | tail -n 200

El síntoma «VPN conectada, pero el destino no es accesible» suele ser casi siempre un problema de políticas/routing/MTU. Use trazas (tcpdump) en dos puntos: en wg0 y en la interfaz de destino.

3) Bastion-Login und Zielsprung

# SSH-Auth-Events auf der Bastion
sudo journalctl -u ssh --since "30 min ago"

# sudo-Audit (Distribution abhängig)
sudo journalctl --since "30 min ago" | grep -i sudo | tail -n 50

Si el inicio de sesión en la Bastion funciona, pero el salto al destino no: revisar firewall del destino (¿solo IP de la Bastion permitida?), DNS (¿nombre objetivo interno?), Hostkeys/known_hosts (en reconstrucciones), y políticas distintas de usuario/clave.

Estrategia de retroceso: volver de forma segura, sin pérdida de control

Una buena estrategia de retroceso no significa «volver todo a como antes», sino un desmantelamiento controlado en caso de fallos:

• Acceso Break-Glass (acceso de emergencia): credenciales separadas, fuertemente registradas, probadas periódicamente, almacenadas fuera de línea. El objetivo es la disponibilidad en el incidente, no la comodidad.
• Rollback escalonado: primero desactivar HA (pasar a un Single-Node estable), luego relajar políticas (con límite temporal), y solo al final eludir la Bastion.
• Change-Flags: diseñar reglas de firewall para poder activar excepciones temporales de forma específica y trazable (con fecha de expiración y referencia de ticket).

Importante: las rutas de contingencia deben conocerse de antemano en el equipo. Si no, en caso de emergencia surgirán soluciones improvisadas ad hoc que perduran meses.

Decisiones de diseño típicas y sus consecuencias

Split Tunneling frente a Full Tunneling

Split Tunneling significa: solo redes internas a través del VPN, Internet local. Ventaja: menos carga, menor dependencia. Desventaja: DNS y controles de seguridad son más difíciles de aplicar de forma consistente. Full Tunneling simplifica las políticas de seguridad centrales (proxy web, filtros DNS), pero aumenta el impacto de una caída del VPN. Decida esto de manera consciente por grupo de usuarios, no de forma global.

Device Binding y ciclo de vida de claves

WireGuard trabaja con pares de claves. Operativamente debe aclarar: ¿Cómo se emiten, rotan y revocan las claves? Sin un ciclo de vida surgen „peers olvidados“. Requisitos mínimos prácticos:

• Asignación de peer a un activo (ID del portátil/dispositivo) y a una persona.
• Proceso de offboarding: eliminar el peer, marcar los registros, y, si procede, bloquear las claves de bastión.
• Rotación: al menos en caso de pérdida del dispositivo o cambio de rol; idealmente periódica.

Registro de accesos y protección de datos

Los registros de acceso contienen datos personales (usuarios, IP, marcas temporales) y en parte datos de contenido (en grabación de sesiones). Documente: propósito, retención, acceso, análisis. Para los equipos de administración es importante que las reglas no sean „grises“: políticas claras evitan discusiones posteriores durante un incidente.

Relación con Zero Trust y PAM

Muchas organizaciones avanzan hacia Zero Trust Network Access (ZTNA), es decir «nunca confiar implícitamente, siempre verificar explícitamente». WireGuard puede formar parte de ello, pero no sustituye una capa de identidad y políticas. Un bastión es a su vez un componente de Privileged Access Management (PAM), es decir, la gestión de accesos privilegiados con trazabilidad. Si posteriormente introduce suites PAM o gateways ZTNA, se beneficiará del trabajo previo: segmentación, puntos de entrada claros y registros limpios.

Conclusión: el acceso remoto es un sistema, no un único producto

Una arquitectura de acceso remoto segura surge cuando se planifican conjuntamente transporte (WireGuard), disponibilidad (VPN-HA), control (bastión SSH) y trazabilidad (registro de accesos). La ganancia operativa es tangible: menor superficie de ataque expuesta, autorizaciones más claras, rutas de resolución de problemas reproducibles y pistas de auditoría fiables.

Si quiere mantener el inicio pragmático, comience con tres pasos: separar subredes VPN, establecer un bastión como único punto de entrada para administradores y hacer los registros correlacionables de forma centralizada. Después el diseño escala – también hacia ZTNA o programas PAM más amplios.

Para este tema también son importantes WireGuard VPN y el host bastión SSH. El artículo sitúa estos aspectos de forma comprensible y muestra en qué centrarse en la operativa diaria.