VPN + RDP/SSH: Acceso remoto sin abrir puertos a Internet

Por qué no deberías abrir RDP/SSH a Internet

Abrir RDP (3389) o SSH (22) a Internet es como dejar el lector de tarjetas de tu oficina fuera del edificio, pegado a un poste con una nota que dice “por favor, compórtense”. La gente no se va a comportar.

Sí, puedes endurecerlo. Sí, puedes bloquear por geolocalización. Sí, puedes añadir MFA. Pero sigues anunciando una superficie de ataque que está siempre activa, accesible globalmente y constantemente escaneada. Incluso si la autenticación es fuerte, el servicio se convierte en objetivo: fallos de protocolo, problemas pre-auth, degradación extraña, relleno de credenciales, spraying de contraseñas y todo el caos de “es solo un PoC” que termina en incidentes en producción.

Colocar RDP/SSH detrás de una VPN cambia las reglas en tres aspectos:

• Alcanzabilidad: los servicios dejan de ser accesibles públicamente, por lo que la mayoría de los ataques oportunistas ni comienzan.
• Límite de identidad: la primera puerta es la autenticación de la VPN y la postura del dispositivo, no el servicio objetivo.
• Observabilidad: puedes registrar y limitar tasas en un único punto de estrangulamiento. Un lugar para mirar, un lugar para bloquear.

Eso no significa “VPN = seguro”. Significa que puedes construir algo sensato: enrutamiento privado, mínimo privilegio y pistas de auditoría que no parecen una novela policíaca escrita por un balanceador de carga.

Datos interesantes y breve historia

El contexto importa. Gran parte del dolor actual del acceso remoto son decisiones de “lánzalo” de ayer.

1. RDP no fue diseñado para redes hostiles. Creció en LANs y WANs empresariales, no en el moderno modelo de amenazas de Internet.
2. SSH reemplazó a telnet/rsh porque la transmisión en texto plano murió. La adopción temprana de SSH a fines de los 90 fue una respuesta práctica a “la gente puede capturar tus contraseñas”.
3. IPsec precede a la mayoría de las costumbres cloud. IPsec existe desde los 90; muchos debates “nuevos” sobre VPN son argumentos viejos con ropa nueva.
4. Las VPNs SSL despegaron por la existencia de NAT. Cuando todo está detrás de NAT y firewalls, tunelar sobre TCP/443 se volvió una táctica de supervivencia.
5. El brute-force contra RDP se convirtió en una economía. Los botnets escanean 3389 porque es rentable: credenciales, preparación de ransomware, movimiento lateral.
6. WireGuard es joven pero con opinión. Es deliberadamente pequeño, con criptografía moderna y menos perillas. Eso es una ventaja para operaciones: menos para malconfigurar.
7. Split tunneling es una pelea antigua. Seguridad lo quiere desactivado. Redes lo quiere activado. La respuesta suele ser “depende”, pero no tan seguido como la gente piensa.
8. Los hosts bastión son básicamente un jump box de marcación moderno. La idea es antigua: una puerta controlada hacia una red privada.
9. NLA (Network Level Authentication) salvó la reputación de RDP. Hizo la autenticación más temprana en la conexión, reduciendo la exposición a algunas clases de ataques.

Arquitectura de referencia que funciona en entornos reales

Aquí está la arquitectura que recomiendo cuando quieres administración remota (RDP/SSH) sin abrir esos puertos al mundo. Escala desde una empresa de 10 personas hasta la corporación de “tenemos tres productos VPN por fusiones”.

Objetivo: hacer de la red privada la única red que importe

La idea central es simple: tus endpoints administrativos (portátiles) se unen a una VPN. Tus sistemas gestionados (servidores/escritorios) son accesibles solo desde el espacio de direcciones de la VPN o subredes internas. RDP/SSH están vinculados a interfaces internas. Los firewalls lo hacen cumplir.

Partes mínimas en movimiento (pero sin heroísmos)

• Gateway VPN: WireGuard u OpenVPN (o IPsec), idealmente redundante.
• Proveedor de identidad: como mínimo cuentas locales + MFA; mejor es integración SSO en la capa VPN.
• Enrutamiento: ya sea VPN enrutada (L3) o combinación de rutas políticas y NAT. Preferir enrutamiento.
• Control de acceso: rangos IP permitidos por usuario o por grupo; idealmente aplicado en firewall y/o en la configuración de la VPN.
• Registro: conexiones/desconexiones de VPN, eventos de autenticación y metadatos de sesión. Para SSH, registrar comandos cuando sea factible.

Dónde encaja el jump host (y dónde no)

Algunos equipos tratan “VPN” y “bastion host” como mutuamente excluyentes. No lo son. Un patrón limpio es:

• Los usuarios se conectan por VPN.
• Los usuarios solo pueden alcanzar un jump host endurecido (SSH) y quizá una pasarela de escritorio remoto.
• Desde el jump host, alcanzan redes más profundas según el mínimo privilegio.

Esto reduce el radio de impacto si un portátil está comprometido y te da un lugar para aplicar grabación de sesiones. Pero no pongas un jump host solo para evitar arreglar el enrutamiento. Eso no es arquitectura; eso es penitencia.

Una cita que debería vivir en tu cabeza: “La esperanza no es una estrategia.” (idea parafraseada frecuentemente atribuida a líderes operativos)

Opciones de VPN que no te complican la vida

WireGuard: mi opción por defecto para acceso administrativo moderno

WireGuard es pequeño, rápido y agresivamente minimalista. Para operaciones, eso significa menos estados de configuración que funcionan “a veces”. Las claves son estáticas; la identidad es más bien “esta clave de dispositivo está permitida”. Puedes añadir SSO y postura del dispositivo fuera de WireGuard si usas un controlador, pero incluso WireGuard simple es una base sólida.

Compensaciones:

• Pros: rendimiento, estabilidad, configuraciones simples, criptografía limpia, fácil enrutamiento.
• Contras: la gestión de claves depende de ti a menos que uses una capa de gestión; la revocación es “eliminar peer” (bien, pero necesitas proceso).

OpenVPN: probado en batalla, flexible, a veces ruidoso

OpenVPN sigue siendo común porque funciona casi en todas partes y soporta muchos mecanismos de autenticación. Es más pesado que WireGuard y puede ser más difícil de ajustar, pero se integra bien en entornos empresariales tradicionales.

Compensaciones:

• Pros: ecosistema maduro, muchas integraciones de autenticación, opción TCP/443 para redes hostiles.
• Contras: más perillas, más complejidad, sobrecarga de rendimiento.

IPsec (IKEv2): excelente cuando tienes buena higiene de red

IPsec es ideal cuando puedes estandarizar y te importa la interoperabilidad. También es bueno cuando necesitas túneles sitio-a-sitio entre redes en lugar de administradores individuales.

El problema es menos el protocolo y más la realidad: los proveedores interpretan las cosas de forma distinta, el NAT traversal a veces parece folklore, y la depuración puede convertirse en un duelo de capturas de paquetes.

No confundas “pasarela de escritorio remoto” con “reemplazo de VPN”

Los gateways RDP pueden ser útiles. También pueden convertirse en un objetivo brillante si los publicas a Internet. Si expones una gateway públicamente, trátala como una API de producción: SO endurecido, MFA, limitación de tasa, TLS estricto, parcheo de vulnerabilidades y registro constante. De lo contrario: mantén la gateway detrás de la VPN también.

Broma #1: Una regla de firewall que dice “temporal” es lo único en TI que sobrevive al hardware.

Identidad, control de acceso y “quién hizo qué”

Autenticación: haz que la VPN sea lo difícil

Si pones RDP/SSH detrás de la VPN, el inicio de sesión de la VPN se convierte en tu puerta principal. Hazla fuerte:

• MFA para usuarios de VPN. No es opcional. Si no puedes hacer MFA, no estás haciendo acceso remoto; estás apostando.
• Confianza de dispositivo si puedes: solo dispositivos gestionados, certificados o chequeo de postura.
• Acceso de corta duración para proveedores y emergencias: cuentas limitadas en el tiempo o membresía temporal en grupos.

Autorización: el enrutamiento es un sistema de permisos

La forma más fácil de filtrar acceso es entregar un perfil VPN que enruta todo. Enhorabuena, construiste una red plana con cifrado más bonito.

En su lugar:

• Define pools de direcciones VPN por rol (admins, soporte, proveedores).
• Restringe qué subredes internas puede alcanzar cada pool usando reglas de firewall en el gateway VPN y/o firewalls internos.
• Para entornos muy sensibles, añade una segunda puerta: solo el jump host es alcanzable, y ese host aplica acceso por destino.

Auditoría: la querrás más tarde, así que constrúyela ahora

“¿Quién se conectó, desde dónde y qué tocó?” nunca se pregunta en semanas tranquilas. Lo escucharás cuando algo falle o cuando Legal se ponga intensamente cortés.

Como mínimo, recoge:

• Registros de conexión de VPN (identidad de usuario/dispositivo, IP de origen, IP asignada por la VPN, tiempo de inicio/fin).
• Registros RDP en Windows (eventos de inicio de sesión, inicio/parada de sesión).
• Registros de autenticación SSH y, idealmente, auditoría de comandos para accesos privilegiados.

Endurecimiento de RDP y SSH una vez detrás de la VPN

Vincula los servicios a interfaces internas

Tu estado ideal es: incluso si alguien abre accidentalmente un firewall, el servicio sigue sin escuchar en la interfaz pública. Defensa en profundidad, no defensa basada en desear que así sea.

Endurecimiento SSH que realmente importa

• Claves en lugar de contraseñas para cuentas administrativas.
• Sin login root por SSH. Usa sudo con registro.
• Limitar usuarios con AllowUsers o AllowGroups.
• Usar criptografía moderna (la mayoría de los valores por defecto están bien en distros actuales; no te pongas creativo).

Endurecimiento RDP que realmente importa

• Habilitar NLA y exigir autenticación fuerte.
• Usar el grupo Remote Desktop Users intencionalmente; no metas “Domain Users” ahí por pereza.
• Limitar el portapapeles/redirección de unidades si manejas datos sensibles. La conveniencia es por donde escapa la información.
• Parchear agresivamente. Los fallos relacionados con RDP no son coleccionables teóricos.

Segmenta las redes de gestión

Si puedes, mantén una subred de gestión dedicada. Tus subredes de aplicaciones en producción no deberían ser el lugar donde los administradores navegan servidores por RDP descuidadamente. Así es como el malware aprende el mapa interno.

Tareas prácticas con comandos: verificar, diagnosticar, decidir

No resuelves problemas de acceso remoto con sensaciones. Los resuelves con rutas de paquetes, tablas de enrutamiento y registros. Abajo hay tareas reales que puedes ejecutar hoy. Cada una incluye qué significa la salida y la decisión que tomas a continuación.

Task 1: Confirmar tu interfaz VPN y la dirección asignada (Linux)

cr0x@server:~$ ip -brief addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             203.0.113.10/24 fe80::1c2:abff:fe3d:111/64
wg0              UP             10.42.0.2/32

Qué significa: wg0 existe y tiene 10.42.0.2. Si falta o está DOWN, no estás “en la VPN”.

Decisión: Si falta wg0, inicia el servicio y revisa la configuración; si está UP pero no fluye tráfico, pasa a tareas de enrutamiento/firewall.

Task 2: Comprobar el handshake de WireGuard y la última actividad

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

peer: N7u2dX3XyqS3pWm0pYbV5z6mXh3q3wVxQe7zq7LwG3M=
  endpoint: 198.51.100.24:53321
  allowed ips: 10.42.0.1/32
  latest handshake: 34 seconds ago
  transfer: 42.11 MiB received, 18.07 MiB sent

Qué significa: Un handshake reciente prueba la criptografía y la conectividad básica. Los contadores de transferencia cambiantes indican que pasa tráfico real.

Decisión: Si los handshakes están obsoletos, revisa NAT/firewall/alcance de puertos. Si los handshakes están recientes pero RDP/SSH falla, es enrutamiento o binding del servicio.

Task 3: Validar la ruta a una subred interna vía VPN

cr0x@server:~$ ip route get 10.10.20.15
10.10.20.15 dev wg0 src 10.42.0.2 uid 1000
    cache

Qué significa: El kernel planea enviar a 10.10.20.15 vía wg0.

Decisión: Si dice dev eth0 o “unreachable”, arregla AllowedIPs/rutas de la VPN antes de tocar configs de RDP/SSH.

Task 4: Probar la alcanzabilidad básica (ICMP) e interpretar con cuidado

cr0x@server:~$ ping -c 3 10.10.20.15
PING 10.10.20.15 (10.10.20.15) 56(84) bytes of data.
64 bytes from 10.10.20.15: icmp_seq=1 ttl=63 time=23.4 ms
64 bytes from 10.10.20.15: icmp_seq=2 ttl=63 time=22.9 ms
64 bytes from 10.10.20.15: icmp_seq=3 ttl=63 time=23.1 ms

--- 10.10.20.15 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 22.9/23.1/23.4/0.2 ms

Qué significa: El camino funciona y la latencia es razonable. Si el ping falla, aún podría estar bien: ICMP a menudo está bloqueado.

Decisión: Si el ping tiene éxito pero TCP no, concéntrate en los puertos del servicio y firewalls. Si el ping falla, pasa a traceroute y reglas de firewall.

Task 5: Probar la alcanzabilidad TCP para SSH

cr0x@server:~$ nc -vz 10.10.20.15 22
Connection to 10.10.20.15 22 port [tcp/ssh] succeeded!

Qué significa: Algo está escuchando y es alcanzable en el puerto 22.

Decisión: Si falla, revisa el estado de escucha del servicio local y las políticas de firewall. No “lo abras” globalmente; ábrelo solo desde los CIDR de la VPN.

Task 6: Probar la alcanzabilidad TCP para RDP

cr0x@server:~$ nc -vz 10.10.30.25 3389
Connection to 10.10.30.25 3389 port [tcp/ms-wbt-server] succeeded!

Qué significa: RDP es alcanzable en la dirección interna. Si el cliente RDP aún falla, es autenticación/NLA/política de certificados, no alcanzabilidad de red.

Decisión: Si esto falla pero el ping funciona, estás ante un firewall en el host, ACL de subred o servicio no iniciado.

Task 7: Confirmar que el daemon SSH solo escucha en interfaces internas/VPN (Linux)

cr0x@server:~$ sudo ss -lntp | grep ':22'
LISTEN 0      128        10.10.20.15:22        0.0.0.0:*    users:(("sshd",pid=923,fd=3))
LISTEN 0      128           10.42.0.10:22        0.0.0.0:*    users:(("sshd",pid=923,fd=4))

Qué significa: SSH escucha en direcciones internas y de VPN, no en 0.0.0.0:22 (todas las interfaces).

Decisión: Si ves 0.0.0.0:22 en un host con interfaz pública, vincula a direcciones específicas o usa reglas de firewall para limitar fuentes estrictamente.

Task 8: Validar reglas de firewall en el gateway VPN (nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    iif "wg0" tcp dport { 22, 3389 } accept
    iif "wg0" icmp type echo-request accept
    tcp dport 51820 accept
    reject with icmpx type port-unreachable
  }
}

Qué significa: Política por defecto drop. Solo la interfaz VPN wg0 puede alcanzar SSH/RDP en este gateway. Se permite el puerto de WireGuard.

Decisión: Si ves aceptaciones amplias en iif "eth0" para 22/3389, arréglalo. Si la política es drop y olvidaste ct state established, crearás un comportamiento de “funciona 2 segundos”.

Task 9: Comprobar el reenvío IP y rp_filter (trampa clásica de enrutamiento)

cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
net.ipv4.ip_forward = 1
net.ipv4.conf.all.rp_filter = 2

Qué significa: El reenvío está habilitado. El filtrado de ruta inversa es “loose” (2), normalmente correcto para enrutamiento VPN con caminos asimétricos.

Decisión: Si el reenvío es 0 en un gateway de enrutamiento, habilítalo. Si rp_filter es estricto (1) y ves tráfico unidireccional raro, ponlo en 2 para las interfaces relevantes.

Task 10: Verificar reglas NAT si debes NATear (iptables)

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.42.0.0/24 -o eth1 -j MASQUERADE

Qué significa: Los clientes VPN en 10.42.0.0/24 se enmascaran cuando salen por eth1 hacia redes internas que no conocen la ruta VPN.

Decisión: Prefiere agregar rutas adecuadas en lugar de NAT. Pero si no puedes cambiar el enrutamiento interno rápidamente, NAT puede ser un paliativo. Documentalo como si fuera un arma cargada.

Task 11: Confirmar que el host Windows objetivo realmente está escuchando RDP

cr0x@server:~$ sudo nmap -Pn -p 3389 10.10.30.25
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-27 10:20 UTC
Nmap scan report for 10.10.30.25
Host is up (0.024s latency).

PORT     STATE SERVICE
3389/tcp open  ms-wbt-server

Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds

Qué significa: El puerto está abierto. Si tu cliente RDP falla, es negociación/autenticación/certificado/NLA, no un puerto cerrado.

Decisión: Si está cerrado, revisa reglas del firewall de Windows, políticas de grupo y si Remote Desktop está habilitado.

Task 12: Confirmar fallos de autenticación SSH versus fallos de red

cr0x@server:~$ ssh -vvv admin@10.10.20.15
OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 10.10.20.15 [10.10.20.15] port 22.
debug1: Connection established.
debug1: Authenticating to 10.10.20.15:22 as 'admin'
debug1: Offering public key: /home/cr0x/.ssh/id_ed25519 ED25519 SHA256:4tS...
debug1: Authentications that can continue: publickey
debug1: Authentication succeeded (publickey).
debug1: Entering interactive session.

Qué significa: La red está bien y la autenticación tuvo éxito. Si en su lugar ves timeouts, es red/enrutamiento/firewall. Si ves “Permission denied”, son claves/usuarios/políticas.

Decisión: Dirige problemas de autenticación a IAM/distribución de claves. Dirige timeouts a red/SRE.

Task 13: Encontrar dónde mueren los paquetes (traceroute sobre VPN)

cr0x@server:~$ traceroute -n 10.10.20.15
traceroute to 10.10.20.15 (10.10.20.15), 30 hops max, 60 byte packets
 1  10.42.0.1  24.102 ms  23.881 ms  23.770 ms
 2  10.10.0.1  24.231 ms  24.021 ms  23.996 ms
 3  10.10.20.15  23.902 ms  23.912 ms  23.901 ms

Qué significa: Puedes ver el gateway VPN y los saltos del router interno. Si se detiene en el salto 1, el gateway no puede enrutar hacia adelante.

Decisión: Donde se detenga es donde mirarás: tabla de enrutamiento, ACL o ruta de retorno faltante.

Task 14: Ver tráfico en vivo en el gateway VPN (tcpdump)

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.42.0.2 and host 10.10.20.15 and tcp port 22
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:23:11.102334 IP 10.42.0.2.52144 > 10.10.20.15.22: Flags [S], seq 341234112, win 64240, options [mss 1420,sackOK,TS val 123 ecr 0], length 0
10:23:11.125883 IP 10.10.20.15.22 > 10.42.0.2.52144: Flags [S.], seq 91234122, ack 341234113, win 65160, options [mss 1360,sackOK,TS val 456 ecr 123], length 0

Qué significa: Ves SYN y SYN-ACK. Eso prueba que existe tráfico de retorno al menos en wg0. Si solo ves SYN, el camino de retorno está roto.

Decisión: Si falta el camino de retorno, revisa rutas internas hacia la subred VPN o comportamiento NAT.

Task 15: Confirmar que las redes internas tienen ruta de regreso a la subred VPN

cr0x@server:~$ ip route | grep 10.42.0.0
10.42.0.0/24 dev wg0 proto kernel scope link src 10.42.0.1

Qué significa: El gateway VPN sabe que la subred VPN está en wg0. Esto es necesario pero no suficiente: los routers internos también deben saber dónde vive 10.42.0.0/24.

Decisión: Si los routers internos no tienen una ruta de retorno, añádela (mejor) o usa NAT (temporal). Una VPN unidireccional es una pérdida de tiempo clásica.

Task 16: Comprobar el estado del servidor OpenVPN si esa es tu pila

cr0x@server:~$ sudo systemctl status openvpn-server@server
● openvpn-server@server.service - OpenVPN service for server
     Loaded: loaded (/lib/systemd/system/openvpn-server@.service; enabled; preset: enabled)
     Active: active (running) since Sat 2025-12-27 09:41:02 UTC; 42min ago
       Docs: man:openvpn(8)
   Main PID: 1234 (openvpn)
      Tasks: 1 (limit: 18954)
     Memory: 9.6M
        CPU: 1.214s

Qué significa: Está en ejecución. Si los usuarios no pueden conectarse, revisa logs y configuración del cliente, no el estado del servicio.

Decisión: Si no está activo, trátalo como una caída: restaura la configuración, valida certificados/keys y confirma reglas de firewall.

Guion de diagnóstico rápido

Este es el guion para “la VPN está arriba pero no puedo RDP/SSH” y necesitas respuestas antes de que se enfríe tu café.

Primero: prueba que la VPN está realmente conectada y intercambiando tráfico

• Revisa que la interfaz exista y tenga IP (ip -brief addr).
• Comprueba el handshake (WireGuard: wg show; OpenVPN: estado del servicio + logs).
• Verifica que los contadores de transferencia aumenten cuando intentas una conexión.

Si el handshake está muerto: mira la alcanzabilidad al endpoint de la VPN (firewall, NAT, UDP bloqueado, puerto equivocado).

Segundo: verifica el enrutamiento en ambos sentidos

• Desde el cliente: ip route get <target> debe decir que usa la interfaz VPN.
• Desde el gateway VPN: confirma que puede enrutar a la subred objetivo.
• Desde el router interno: confirma que tiene una ruta de retorno a la subred VPN (o que estás haciendo NAT intencionalmente).

Si ves SYN pero no SYN-ACK: enrutamiento de retorno o firewall en el lado lejano. Si ves SYN-ACK en wg0 pero el cliente aún hace timeout, puedes tener problemas de MTU o firewall local.

Tercero: comprueba que el servicio sea alcanzable y esté escuchando donde crees

• Alcanzabilidad de puerto: nc -vz host 22 / nc -vz host 3389.
• En el objetivo: confirma dirección de escucha (ss -lntp en Linux; firewall/estado del servicio en Windows).
• Valida que el firewall del host permita tráfico desde el CIDR de la VPN.

Cuarto: aislar cuellos de botella de rendimiento (latencia, MTU, DNS)

• Latencia: ping o tiempo de conexión TCP, luego traceroute.
• MTU/MSS: síntomas son “se conecta pero se congela” o “pantalla negra de RDP”.
• DNS: si el hostname falla pero la IP funciona, arregla split-DNS o empuja resolutores internos.

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

1) “La VPN se conecta, pero no puedo alcanzar nada interno.”

Síntoma: La VPN muestra conectada; puedes hacer ping al gateway VPN pero no a hosts internos.

Causa raíz: Rutas faltantes (AllowedIPs demasiado estrechos, o routers internos no conocen la subred VPN).

Solución: Añade rutas para subredes internas en la configuración del cliente VPN y agrega una ruta de retorno en los routers internos (preferido) o NAT en el gateway (temporal).

2) “SSH funciona a algunos hosts pero no a otros, de forma aleatoria.”

Síntoma: Algunas subredes funcionan, otras timeout; se siente inconsistente.

Causa raíz: Rangos IP solapados (pool VPN choca con rangos internos) o enrutamiento asimétrico a través de múltiples salidas.

Solución: Reasigna el pool VPN a un espacio no solapado; asegura simetría de enrutamiento interno o usa enrutamiento por políticas en el gateway.

3) “RDP se conecta y luego pantalla negra / se cuelga.”

Síntoma: TCP 3389 es alcanzable, pero la sesión se queda estancada.

Causa raíz: Problemas de MTU/MSS sobre el túnel, o inspección de seguridad agresiva que altera el tráfico.

Solución: Ajusta el MTU del túnel de forma conservadora; ajusta MSS en el gateway; evita tunelizar TCP sobre TCP a menos que sea imprescindible.

4) “Exponemos solo el puerto VPN; aún así nos comprometieron.”

Síntoma: El único puerto público es la VPN, y aun así un atacante entró.

Causa raíz: Autenticación VPN débil (sin MFA), claves filtradas, cuentas compartidas o un endpoint comprometido con credenciales válidas.

Solución: Exige MFA, rota claves/certificados, revoca peers rápidamente, exige dispositivos gestionados y restringe lo que los clientes VPN pueden alcanzar.

5) “DNS funciona para Internet, pero nombres internos fallan en la VPN.”

Síntoma: Puedes SSH por IP, pero no por nombre; nombres internos no se resuelven.

Causa raíz: Split-DNS no configurado; la VPN no empuja resolutores internos ni dominios de búsqueda.

Solución: Empuja servidores DNS internos y dominios de búsqueda vía configuración de la VPN o política de cliente. No dependas de hosts files manuales.

6) “El rendimiento es terrible solo en la VPN.”

Síntoma: Alta latencia, RDP entrecortado, SCP lento.

Causa raíz: Enrutamiento hairpin (todo vuelve por la sede), CPU del gateway saturada, expectativas erróneas de offload criptográfico o pérdida de paquetes en la ruta UDP.

Solución: Usa split tunneling con cautela para tráfico no corporativo, añade gateways regionales, monitoriza CPU del gateway y valida pérdida de paquetes con contadores de tcpdump.

7) “Después de endurecer SSH, la automatización falló.”

Síntoma: Jobs CI/CD fallan al hacer SSH tras un cambio de seguridad.

Causa raíz: Se deshabilitó la autenticación por contraseña sin provisionar claves, o se restringieron usuarios/grupos demasiado amplio.

Solución: Mueve la automatización a cuentas de servicio dedicadas con claves con alcance; prueba cambios en un entorno staging que refleje la autenticación de producción.

8) “El acceso de proveedores se vuelve permanente.”

Síntoma: Cuentas VPN antiguas de proveedores siguen funcionando meses después.

Causa raíz: No hay flujo de offboarding; el acceso se concede por excepción y nunca se revisa.

Solución: Limita en el tiempo las cuentas de proveedores, exige revisiones periódicas de acceso y requiere referencia de ticket en metadatos de la cuenta.

Tres microhistorias corporativas desde el terreno

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa mediana trasladó una app contable legacy a un entorno hospedado. El equipo de ops estaba orgulloso: sin RDP público, sin SSH público, solo una VPN. Hicieron lo correcto—casi. Llegó la semana de nómina y las sesiones RDP empezaron a caerse cada pocos minutos.

La suposición era simple y equivocada: “Si la VPN está conectada, el camino de red está bien.” El equipo persiguió actualizaciones de Windows, configuraciones de RDP y los portátiles de los usuarios. Alguien incluso sugirió aumentar los timeouts de RDP, que es una forma elegante de perder tiempo con confianza.

El verdadero problema fue el enrutamiento de retorno. El gateway VPN podía alcanzar los servidores. Los servidores podían responder, pero su gateway por defecto enviaba tráfico a otro router que no tenía idea de dónde vivía la subred VPN. La mitad del tráfico tomaba una ruta escénica hacia un agujero negro. Parecía “desconexiones aleatorias” porque lo eran.

Arreglarlo fue aburrido: añadir una ruta para la subred VPN en el router interno correcto. Las caídas de RDP desaparecieron de inmediato. La nota del postmortem fue corta: nunca asumas que “conectado” significa “enrutado en ambos sentidos”.

Microhistoria 2: La optimización que salió mal

Una organización más grande quiso más rendimiento en la VPN. Su equipo de red movió el servicio VPN para correr sobre TCP/443 porque “atraviesa cualquier firewall”. Fue vendido como mejora de fiabilidad. También fue una trampa.

La primera semana parecía bien. Luego una oficina regional empezó a quejarse de transferencias de archivos y RDP lentos. No solo lentos—pegajosos, con ráfagas e impredecibles. Capturas de paquetes mostraron retransmisiones y bloqueo head-of-line.

Habían construido TCP sobre TCP: un túnel TCP llevando aplicaciones TCP. Cuando hay pérdida, TCP intenta recuperar; tu TCP interno también intenta recuperar. Los mecanismos de recuperación se pelean y los usuarios ven una presentación de diapositivas.

La solución fue volver a UDP para la VPN donde fuera posible y reservar TCP/443 como último recurso. El rendimiento se estabilizó y la “optimización” fue retirada del diagrama de arquitectura en silencio.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una empresa regulada tenía una regla estricta: cada usuario VPN pertenece a un grupo, cada grupo se mapea a acceso a subredes explícitas y cada cambio de acceso requiere un ticket. Todos lo odiaban en tiempos tranquilos porque era fricción. El equipo de seguridad estaba acostumbrado a no ser popular. Les resultaba relajante.

Una tarde, robaron el portátil de un ingeniero del coche. El portátil estaba cifrado, pero el equipo de respuesta asumió el peor escenario: el dispositivo podría comprometerse eventualmente. La pregunta se convirtió en: “¿Qué puede alcanzar este dispositivo ahora mismo?”

Porque el modelo de acceso era aburrido y explícito, la respuesta fue inmediata. El perfil VPN del ingeniero solo enrutaba hacia una subred de jump host, no a bases de datos de producción. Revocar el acceso fue eliminar un peer en una línea, y el jump host requería MFA y credenciales de corta duración de todos modos.

Rotaron las claves relevantes, revisaron logs y siguieron adelante sin una semana de pánico. La regla que todos criticaban resultó ser la razón por la que el incidente fue un ticket, no un titular.

Broma #2: Lo único más persistente que los atacantes es un interno que aprendió redirección de puertos ayer.

Listas de verificación / plan paso a paso

Plan A: El predeterminado sensato (VPN + acceso enrutado + subredes restringidas)

1. Elige un CIDR VPN no solapado (ejemplo: 10.42.0.0/24). Anótalo. Trátalo como un contrato de API.
2. Despliega gateways VPN con firewall en deny por defecto. Expón solo el puerto VPN públicamente.
3. Habilita MFA para acceso VPN. Si tu producto VPN no lo soporta, esa es tu petición de cambio.
4. Define acceso por roles: admins pueden alcanzar subredes de gestión; soporte alcanza endpoints limitados; proveedores obtienen acceso acotado en el tiempo a hosts específicos.
5. Empuja DNS interno a clientes VPN y configura split-DNS si es necesario.
6. Añade rutas de retorno en routers internos para el CIDR VPN vía el gateway VPN. Evita NAT salvo que sea imprescindible.
7. Vincula SSH/RDP a interfaces internas y bloquea firewalls de host para permitir solo el CIDR de la VPN o jump hosts.
8. Centraliza logs: logs de autenticación VPN, logs de seguridad Windows, logs SSH. Configura alertas para patrones sospechosos.
9. Prueba desde un cliente limpio: nuevo perfil VPN, verifica enrutamiento, verifica alcanzabilidad de puertos, verifica que la autenticación funcione.
10. Documenta el procedimiento “romper cristal”: quién puede obtener acceso de emergencia, cómo se aprueba y cómo se revoca.

Plan B: Añade un jump host cuando necesites control más estricto

1. Los usuarios entran por VPN, pero solo pueden alcanzar una subred de jump host.
2. El jump host aplica MFA/SSO de nuevo, con registro estricto y grabación de sesiones donde sea factible.
3. Desde el jump host, permite SSH/RDP a objetivos según membresía de grupo.
4. Prohíbe rutas directas cliente-a-producción. No aceptes excepciones “solo para mí”. Las excepciones se vuelven cultura.

Plan C: Acceso de proveedores sin caos

1. Crea perfiles VPN específicos para proveedores con límite de tiempo y AllowedIPs estrechos.
2. Forza el acceso a través de un jump host con sesiones grabadas.
3. Deshabilita split tunneling para perfiles de proveedores si puedes; al menos bloquea acceso a recursos internos no necesarios.
4. Revisa el acceso de proveedores regularmente; revoca automáticamente al finalizar el contrato.

Preguntas frecuentes

1) ¿Una VPN es suficiente, o aún debo endurecer SSH/RDP?

Endurece igualmente. La VPN reduce la exposición; no elimina riesgo interno, endpoints comprometidos o movimiento lateral. Trata la VPN como una puerta, no como un campo de fuerza mágico.

2) ¿Debería desactivar el split tunneling?

Por defecto desactívalo para perfiles administrativos. Si debes habilitar split tunneling, restringe qué subredes internas son alcanzables y monitorea DNS cuidadosamente. La mayoría de los incidentes por “split tunnel” son en realidad problemas de split-DNS.

3) ¿Qué es mejor: VPN o un bastion host?

Para equipos pequeños, solo VPN está bien si el acceso a subredes está restringido. Para mayor garantía, usa ambos: VPN para entrar a la red privada, bastion/jump host para controlar y registrar lo que sucede después.

4) ¿Por qué no cambiar SSH a un puerto no estándar y darlo por resuelto?

Porque los escáneres cuentan hasta 65535. Mover puertos reduce el ruido, no el riesgo. Si tu objetivo es “no ser atacado”, esconderse no es un plan; aislarse sí lo es.

5) ¿Puedo mantener RDP/SSH abiertos pero limitar por listas de IP permitidas?

A veces. Sigue siendo frágil porque las IPs domésticas cambian, las redes móviles cambian y terminarás permitiendo rangos más amplios de lo previsto. La VPN te da identidad estable y un único punto de entrada controlado.

6) ¿Cuál es la causa principal de “la VPN está arriba pero nada funciona”?

Rutas de retorno faltantes. El lado VPN sabe a dónde enviar paquetes, pero las redes internas no saben cómo responder a la subred VPN.

7) ¿Cómo manejo acceso de emergencia si la VPN cae?

Diseña para eso explícitamente: consola fuera de banda, plano de gestión separado o un segundo gateway/proveedor VPN. No dejes SSH/RDP públicos “por si acaso”. Así es como “por si acaso” se convierte en “nos comprometieron por si acaso”.

8) ¿WireGuard es seguro para uso empresarial?

Sí, si gestionas claves y accesos correctamente. Su simplicidad es una ventaja operativa. La pregunta empresarial suele ser sobre ciclo de vida: onboarding, offboarding, auditoría y aplicación de políticas.

9) ¿Y las redes de almacenamiento/administración—alguna preocupación especial?

Sí: el acceso de gestión a sistemas de almacenamiento tiene alto impacto. Mantén las interfaces de gestión de almacenamiento en subredes dedicadas accesibles solo vía VPN y preferiblemente vía jump host. Audita agresivamente.

10) ¿Cómo demuestro que ya no exponemos RDP/SSH?

Realiza escaneos externos desde fuera de tu perímetro de red y verifica que los puertos 22 y 3389 estén cerrados. Internamente, confirma que los servicios están vinculados a interfaces privadas y que los firewalls restringen fuentes a los CIDR de la VPN.

Siguientes pasos que puedes hacer esta semana

1. Inventaria la exposición: identifica cualquier SSH/RDP público y ciérralo. Si no puedes cerrarlo de inmediato, restríngelo por IP de origen y añade MFA mientras migras.
2. Levanta un piloto de VPN: elige un CIDR no solapado, despliega un gateway, conecta dos admins, enruta a una subred de gestión.
3. Arregla el enrutamiento correctamente: añade rutas de retorno en routers internos en lugar de confiar en NAT, salvo que tengas una excepción documentada.
4. Endurece los objetivos: vincula SSH/RDP a interfaces internas, exige claves/NLA y restringe reglas de firewall de host a los CIDR de la VPN.
5. Escribe el runbook: copia el Guion de diagnóstico rápido en tus docs on-call y añade los rangos IP y las interfaces específicas de tu entorno.
6. Haz que la revocación sea rápida: practica eliminar un peer/usuario VPN y verifica que quede cortado. Si la revocación tarda una hora, no es revocación; es una reunión.

Si no haces nada más: deja de publicar protocolos administrativos a Internet. Ponlos detrás de una VPN con autenticación fuerte y enrutamiento estricto. Tu yo del futuro enviará agradecimientos a través de la única máquina del tiempo fiable: menos incidentes.