Control de acceso oficina a oficina: aplicar la regla «solo servidores, no toda la LAN»

diciembre 20, 2025 • febrero 3, 2026 • Lectura: 27 min • Views: 5

¿Te fue útil?

Quieres conectar dos oficinas, pero no quieres que cada impresora, portátil BYOD y cámara IoT “temporal” de la Oficina A tenga acceso directo a los equipos de la Oficina B. Quieres la regla sensata y aburrida: el tráfico entre oficinas es para servidores y un conjunto reducido de servicios gestionados, no para toda la LAN.

La mayoría de los equipos dicen que quieren eso. Luego aparece una VPN “rápida”, se filtran rutas y de repente tienes una red plana distribuida con dos cocinas. El trabajo aquí es mantener la conexión reduciendo el radio de impacto.

El modelo: las oficinas no son de confianza, los servicios sí

“Solo servidores, no toda la LAN” suena a regla de firewall. En realidad es una postura de red:

Los segmentos de usuarios de la oficina son ruidosos, impredecibles y están llenos de dispositivos que no parcheas con suficiente rapidez.
Los segmentos de servidores (o “redes de servicios”) se gestionan, monitorizan y son donde puedes aplicar identidad y mínimo privilegio.
La conectividad entre oficinas debe tratarse como un límite hostil, incluso si la otra oficina es “nuestra”.

Prácticamente, “solo servidores” significa:

Entre la Oficina A y la Oficina B, solo un conjunto pequeño de subredes de destino son accesibles (por ejemplo, 10.20.10.0/24 para servidores, no 10.20.0.0/16 para todo).
Incluso dentro de las subredes permitidas, solo se permiten los puertos necesarios (por ejemplo, 443 a reverse proxies, 22 solo desde bastiones, 445 solo desde una pasarela de servicios de archivos—si es imprescindible).
Enrutamiento y políticas alineadas: no publicas una ruta que piensas bloquear, y no bloqueas algo que estás anunciando accidentalmente con un prefijo más específico.
El registro es obligatorio en el límite. Si no puedes responder “quién inició qué hacia dónde”, no estás controlando acceso—estás adivinando.

Toma de posición opinada: si tu “VPN oficina-a-oficina” es solo un túnel con 0.0.0.0/0 en ambos lados y esperas que los firewalls de los hosts te salven, estás construyendo una tubería de incidentes.

Define “servidor” con precisión

Los equipos se atascan porque “servidor” se vuelve una sensación. Hazlo concreto:

Subredes de servidores son rangos IP dedicados a cargas gestionadas (clusters de VM, nodos de contenedores, NAS, AD/LDAP, reverse proxies).
Subredes de clientes son endpoints de usuario (por cable, Wi‑Fi, invitados, laboratorios, salas de reuniones).
Subredes de infraestructura son dispositivos de red, monitorización, planos de gestión, jump hosts y concentradores VPN.

Luego codifica: la conectividad interoficina solo está permitida a subredes de servidores + infraestructura, con una lista de puertos permitidos y, preferiblemente, con identidad encima (mTLS, proxies con SSO o comprobación de postura del dispositivo).

Hechos e historia que explican por qué esto sigue fallando

Algo de contexto ayuda. No porque sea bonito, sino porque estos modos de fallo se repiten por las mismas razones.

Las primeras redes empresariales crecieron “planas” porque era más barato. VLANs y el enrutamiento inter‑VLAN fueron frecuentemente añadidos después, no el plan original.
Los VPNs sitio a sitio se multiplicaron a comienzos de los 2000 cuando los enlaces a Internet fueron lo suficientemente estables para reemplazar líneas dedicadas; muchos diseños copiaron supuestos de “WAN de confianza” de la era MPLS.
La cultura MPLS entrenó a la gente a confiar en la nube del proveedor. Cuando los equipos pasaron a VPNs sobre Internet, a menudo mantuvieron enrutamiento “cualquiera a cualquiera”, solo que cifrado.
CIDR (1993) habilitó agregación pero también facilitó la sobre‑resumificación: anunciar un /16 porque queda ordenado, no porque sea seguro.
NAT se volvió un muleta de seguridad en muchas oficinas. Oculta direccionamiento, pero no aplica mínimo privilegio; solo complica la depuración.
SMB y el descubrimiento en Windows asumían tradicionalmente adyacencia LAN. Cuando las oficinas se unen, el tráfico de descubrimiento histórico se filtra y se convierte en tickets de “¿por qué mi inicio de sesión va lento?”.
Las impresoras históricamente se tratan como inofensivas. Luego descubres que muchas usan stacks antiguos y pueden ser puntos de pivote. Impresoras: el regalo que sigue imprimiendo—y a veces exfiltrando.
Los firewalls fueron más rápidos, así que la gente se volvió más permisiva. Cuando una caja puede empujar decenas de Gbps, “simplemente permitir” se siente inofensivo. No lo es; la escala hace que los errores sean más ruidosos.

Una cita útil para llevar a cada revisión de diseño (idea parafraseada): “La esperanza no es una estrategia.” — atribuida en círculos de operaciones a Ed Catmull; la redacción varía, así que tómala como idea, no como escritura sagrada.

Arquitectura de referencia: rutas, políticas y puntos de estrangulamiento

El patrón más simple y efectivo también es el más defendible: un punto de estrangulamiento por sitio, enrutamiento explícito y políticas con denegación por defecto. El objetivo es evitar la “aplicación distribuida” donde se espera que cada firewall de host sea perfecto para siempre.

Elige tus puntos de estrangulamiento

En cada oficina quieres un dispositivo (o par HA) que sea:

el punto de terminación del túnel sitio‑a‑sitio (o del overlay SD‑WAN),
la puerta L3 para las VLANs de servidores y clientes (o al menos el enrutador inter‑VLAN),
el punto de aplicación de las políticas inter‑oficina,
el punto de registro.

Opciones comunes: appliance de firewall, enrutador con ACLs, gateway basado en Linux con nftables, o un edge SD‑WAN. La marca importa menos que la disciplina: denegar por defecto, permisos estrechos y anuncios de rutas medidos.

Estrategia de enrutamiento: anuncia solo lo que pretendes permitir

Esta es la parte que la gente omite porque suena “muy de redes”. También es donde la política se vuelve real.

Opciones:

Rutas estáticas: buenas para entornos pequeños, modos de fallo obvios, fáciles de auditar. Malas cuando escalas a muchas subredes y sitios.
Enrutamiento dinámico (BGP/OSPF sobre el túnel): escalable y con conmutación por fallo rápida, pero propagará tus errores a la velocidad del protocolo.
Enrutamiento por política SD‑WAN: conveniente con intención gestionada centralmente, pero debes entender el underlay real y qué ocurre cuando las políticas confligen.

Regla: no anuncies subredes de clientes a través del límite inter‑oficina. Si los clientes de la Oficina A necesitan un servicio en la Oficina B, deben alcanzar un endpoint de servicio en la Oficina B (reverse proxy, gateway, jump host, app publicada), no la VLAN de clientes.

Estrategia de políticas: denegar por defecto con permisos explícitos

En el límite inter‑oficina, implementa una matriz de políticas que incluya:

Zonas de origen (Office A cliente, Office A servidor, Office A infra)
Zonas de destino (Office B servidor, Office B infra)
Grupos de servicios (HTTPS, SSH desde bastión, monitorización, servicios de directorio, replicación de backups)
Registro para denegaciones y para un subconjunto de permisos (o al menos muestreo), para que puedas demostrar que la realidad coincide con la intención.

La inspección stateful es tu amiga. El enrutamiento asimétrico no lo es. Lo diagnosticaremos más adelante, porque te pasará.

Identidad encima: “subred de servidores” no basta

Las listas de subredes reducen la superficie de ataque. No impiden que un servidor comprometido se convierta en cabeza de playa.

Para rutas de alto valor, añade:

mTLS entre servicios
SSH a través de bastiones (sin SSH directo desde clientes de oficina hacia redes remotas de servidores)
Proxies de aplicación (reverse proxies HTTP, gateways RDP, gateways de acceso a archivos)
Postura del dispositivo (comprobaciones de dispositivo gestionado) cuando sea posible

Sí, es trabajo extra. No, no te arrepentirás a las 02:00.

Opciones de control y cuándo cada una es la herramienta adecuada

1) Filtrado de rutas (mejor primera línea)

Si la oficina remota nunca aprende una ruta a tu VLAN de clientes, la mayoría de los problemas desaparecen. El filtrado de rutas es limpio, escalable y no depende del rendimiento de inspección de paquetes.

Úsalo cuando controles el enrutamiento (estático o BGP/OSPF) y quieras un límite de alta confianza.

2) Política de firewall stateful (el libro de reglas real)

Aun con filtrado de rutas, la política de firewall sigue siendo necesaria porque:

algunas rutas deben existir (a subredes de servidores), y
aún necesitas control a nivel de puerto y registro.

3) Microsegmentación / firewalls de host (bueno, pero no suficiente por sí solo)

Los firewalls de host (Windows Firewall, ufw, firewalld) y agentes de microsegmentación pueden reducir drásticamente el movimiento lateral. Pero como único control? Eso es apostar por la higiene de los endpoints. Esa apuesta suele perder eventualmente.

4) Publicación a nivel de aplicación (mejor experiencia de usuario en muchos casos)

En lugar de permitir que la Oficina A alcance ampliamente los servidores de la Oficina B, publica aplicaciones específicas:

Apps HTTPS detrás de un reverse proxy con SSO
RDP mediante un gateway con MFA
SMB mediante una pasarela de archivos o sincronización

Cuando la gente dice “necesitamos acceso a la red”, pregunta qué necesitan realmente. Normalmente es “necesitamos una app web y un recurso de archivos”, no “necesitamos descubrir todos los dispositivos en un /16”.

Broma 1: Una red plana es como una oficina de espacio abierto: genial para colaborar, terrible para evitar que alguien oiga tus secretos.

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

Estos son controles prácticos que puedes ejecutar desde gateways Linux, jump hosts de servidor o estaciones de administración. Cada tarea incluye: comando, salida de ejemplo, qué significa y la decisión que tomas.

Task 1: Probar qué rutas tienes realmente (y si se filtraron subredes de clientes)

cr0x@server:~$ ip route show
default via 10.10.0.1 dev eth0 proto dhcp src 10.10.0.20 metric 100
10.10.0.0/24 dev eth0 proto kernel scope link src 10.10.0.20
10.20.10.0/24 via 10.10.0.1 dev eth0
10.20.30.0/24 via 10.10.0.1 dev eth0

Significado: Este host puede enrutar a dos subredes remotas: 10.20.10.0/24 y 10.20.30.0/24. Si 10.20.30.0/24 es una VLAN de clientes, ya violaste “solo servidores”.

Decisión: Arregla la publicidad de rutas o las rutas estáticas primero. No “tapes” rutas filtradas con reglas de host.

Task 2: Ver qué cree hacer tu interfaz VPN

cr0x@server:~$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             10.10.0.20/24 fe80::a00:27ff:fe4e:66a1/64
tun0             UP             172.31.255.2/30

Significado: La interfaz de túnel está arriba con un /30. Está bien. No te dice qué se enruta sobre ella, solo que la interfaz existe.

Decisión: Correlaciona con la tabla de rutas y la política de firewall; no asumas que “tun0 arriba” significa “política correcta”.

Task 3: Validar la ruta a una subred de servidor remota (y detectar desvíos inesperados)

cr0x@server:~$ tracepath -n 10.20.10.50
 1?: [LOCALHOST]                                         pmtu 1500
 1:  10.10.0.1                                            0.410ms
 2:  172.31.255.1                                         1.283ms
 3:  10.20.10.50                                          2.104ms reached
     Resume: pmtu 1500 hops 3 back 3

Significado: El tráfico va al gateway local, luego al peer del túnel y luego al destino. Ruta limpia, MTU 1500.

Decisión: Si los saltos incluyen routers inesperados (como el borde de Internet), probablemente tengas enrutamiento basado en políticas o fugas de rutas.

Task 4: Comprobar problemas de PMTU (clásico “hace ping pero la app se cuelga”)

cr0x@server:~$ ping -M do -s 1472 -c 3 10.20.10.50
PING 10.20.10.50 (10.20.10.50) 1472(1500) bytes of data.
From 10.10.0.1 icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 10.10.0.1 icmp_seq=2 Frag needed and DF set (mtu = 1400)
From 10.10.0.1 icmp_seq=3 Frag needed and DF set (mtu = 1400)

--- 10.20.10.50 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Significado: La MTU efectiva es 1400 en el camino. Paquetes grandes con DF establecido no pueden pasar. Algunas aplicaciones se colgarán o retransmitirán indefinidamente.

Decisión: Limita MSS en el VPN/firewall, o ajusta la MTU del túnel apropiadamente. Luego vuelve a probar con tamaños hasta estabilizar.

Task 5: Confirmar qué está descartando el firewall (ejemplo nftables)

cr0x@gateway:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iifname "lan_clients" oifname "vpn0" ip daddr 10.20.10.0/24 tcp dport { 443 } accept
    iifname "lan_clients" oifname "vpn0" counter log prefix "DROP interoffice " drop
  }
}

Significado: Política por defecto drop en la cadena forward. Solo permitir la VLAN de clientes a la subred remota de servidores en 443. Todo lo demás registra y descarta.

Decisión: Esta es la forma correcta. A continuación, asegúrate de que tus reglas sean simétricas (camino de retorno) y que tus zonas coincidan con las interfaces reales.

Task 6: Ver en vivo los descartes para ver qué intentan los usuarios (y qué olvidaste)

cr0x@gateway:~$ sudo journalctl -k -f | grep "DROP interoffice"
Aug 21 10:13:02 gw kernel: DROP interoffice IN=lan_clients OUT=vpn0 SRC=10.10.50.23 DST=10.20.30.44 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=5421 DF PROTO=TCP SPT=51844 DPT=445 WINDOW=64240 SYN
Aug 21 10:13:04 gw kernel: DROP interoffice IN=lan_clients OUT=vpn0 SRC=10.10.50.23 DST=10.20.10.60 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=5512 DF PROTO=TCP SPT=51845 DPT=3389 WINDOW=64240 SYN

Significado: Alguien intenta SMB (445) a una subred de clientes remota (10.20.30.44), y RDP (3389) a un servidor (10.20.10.60). Tu política solo permitió 443.

Decisión: No permitas 445/3389 por instinto. Pregunta: ¿debe SMB atravesar oficinas? ¿RDP debe ir a través de un gateway? Usualmente la respuesta es “publicar correctamente”.

Task 7: Verificar que los anuncios BGP no estén filtrando subredes de clientes

cr0x@router:~$ vtysh -c "show ip bgp neighbors 172.31.255.1 advertised-routes" | sed -n '1,40p'
BGP table version is 44, local router ID is 10.10.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.20.10.0/24    0.0.0.0                  0         32768 i
*> 10.20.99.0/24    0.0.0.0                  0         32768 i

Significado: Anuncias dos prefijos. Si 10.20.99.0/24 es una VLAN de clientes/Wi‑Fi, lo estás exportando sobre el enlace inter‑oficina.

Decisión: Añade prefix-lists/route-maps para exportar solo prefijos de servidor e infraestructura. Luego confirma en el lado remoto las rutas recibidas.

Task 8: Comprobar rutas recibidas en el otro lado (confirma que la corrección funcionó)

cr0x@router-b:~$ vtysh -c "show ip bgp neighbors 172.31.255.2 received-routes" | sed -n '1,40p'
BGP table version is 107, local router ID is 10.20.0.1

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.20.10.0/24    172.31.255.2            0             0 i

Significado: Solo se recibe la subred de servidores. Bien. Menos alcance significa menos formas de sorprenderte.

Decisión: Mantenlo así. Si alguien pide más tarde “acceso temporal” a una subred de clientes, trátalo como una solicitud de cambio con expiración.

Task 9: Confirmar forwarding y rp_filter (trampa de enrutamiento asimétrico)

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

Significado: El reenvío IP está habilitado. El filtrado de ruta inversa es estricto (1). El rp_filter estricto puede descartar tráfico legítimo cuando las rutas de regreso difieren (común con enlaces duales, SD‑WAN o enrutamiento por políticas).

Decisión: Si observas tráfico unidireccional con estado válido, considera establecer rp_filter a 2 (loose) en las interfaces VPN, pero solo después de entender la simetría de rutas.

Task 10: Capturar tráfico en el límite para distinguir “sin ruta” vs “descartado por firewall”

cr0x@gateway:~$ sudo tcpdump -ni vpn0 host 10.10.50.23 and host 10.20.10.50 and tcp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vpn0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:15:22.011221 IP 10.10.50.23.51910 > 10.20.10.50.443: Flags [S], seq 405483990, win 64240, options [mss 1360,sackOK,TS val 120119 ecr 0,nop,wscale 7], length 0
10:15:22.032909 IP 10.20.10.50.443 > 10.10.50.23.51910: Flags [S.], seq 29199210, ack 405483991, win 65160, options [mss 1360,sackOK,TS val 99122 ecr 120119,nop,wscale 7], length 0

Significado: SYN y SYN‑ACK son visibles en vpn0. El handshake ocurre. Si el cliente sigue fallando, el problema probablemente esté más allá del límite inter‑oficina (firewall del host, TLS, proxy, app).

Decisión: Deja de tocar políticas VPN/firewall y sube en la pila.

Task 11: Probar la alcanzabilidad de puertos sin engañarte

cr0x@client-jumphost:~$ nc -vz -w 3 10.20.10.50 443
Connection to 10.20.10.50 443 port [tcp/https] succeeded!

Significado: La conexión TCP funciona. Eso es L3/L4 suficiente. No confirma que la aplicación esté correcta.

Decisión: Si la conexión falla, revisa descartes de firewall y rutas. Si funciona pero la app falla, revisa certificados TLS, SNI, proxies y ACLs del servidor.

Task 12: Confirmar que una subred de clientes remota sea realmente inaccesible (el objetivo)

cr0x@client-jumphost:~$ ping -c 2 10.20.30.44
PING 10.20.30.44 (10.20.30.44) 56(84) bytes of data.

--- 10.20.30.44 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1021ms

Significado: Sin respuesta ICMP. Esto por sí solo no prueba bloqueo (ICMP puede estar filtrado), pero es una señal razonable cuando se combina con rutas y registros de firewall.

Decisión: Valida con ip route get 10.20.30.44 y contadores/registro del firewall. Tu objetivo: no hay ruta, o hay una denegación explícita con registros.

Task 13: Mostrar qué regla está coincidiendo (ejemplo contadores iptables)

cr0x@gateway:~$ sudo iptables -L FORWARD -v -n --line-numbers | sed -n '1,25p'
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in          out         source          destination
1     918K  712M ACCEPT     all  --  *           *           0.0.0.0/0       0.0.0.0/0       ctstate RELATED,ESTABLISHED
2     231K   18M ACCEPT     tcp  --  lan_clients vpn0        10.10.50.0/24    10.20.10.0/24    tcp dpt:443
3     1245  104K DROP       all  --  lan_clients vpn0        0.0.0.0/0       0.0.0.0/0

Significado: La regla 2 se usa activamente; la regla 3 descarta el resto. Los contadores hacen real la política. Si la regla 3 sube inesperadamente, usuarios/apps intentan rutas prohibidas.

Decisión: Investiga qué se está descartando antes de añadir nuevos permisos. A veces la solución correcta es “dejar de hacer eso”, no “abrir el firewall”.

Task 14: Probar que el DNS no causa ilusiones de “está caído” entre oficinas

cr0x@client-jumphost:~$ dig +short app.officeb.internal
10.20.10.50

Significado: El nombre resuelve a una IP de subred de servidores. Bien. Si resuelve inesperadamente a una IP de subred de clientes o a una IP pública, tu plan de control de acceso parecerá “aleatorio” para los usuarios.

Decisión: Asegura que el DNS interno responda diferente por sitio solo cuando sea intencional. No dejes que DNS de horizonte dividido se convierta en cerebro dividido.

Guía rápida de diagnóstico

Este es el orden que encuentra el cuello de botella rápidamente, sin hacer cambios frenéticos que empeoren las cosas.

Primero: la verdad del enrutamiento (alcanzabilidad en L3)

En el host origen: ip route get <dest-ip> para ver la interfaz de salida y el siguiente salto.
En el gateway: confirma que la ruta existe y apunta al túnel/overlay SD‑WAN.
En el gateway remoto: confirma que la ruta de retorno existe hacia la subred origen (o que la política NAT es deliberada y consistente).

Si no hay ruta, detente. Arregla la publicidad de rutas o las rutas estáticas antes de tocar reglas de firewall.

Segundo: política de firewall y contadores (¿se descarta o se permite?)

Comprueba la política por defecto: ¿drop o accept?
Comprueba el permiso explícito para la tupla exacta: src subnet, dst subnet, protocolo, puerto.
Comprueba contadores/registros mientras reproduces el problema.

Si los contadores muestran descartes, decide: ¿es una petición legítima (publicar/gateway), o es un movimiento lateral esperando ocurrir (seguir descartando)?

Tercero: statefulness y asimetría (la trampa de “debería funcionar”)

Busca rutas de retorno asimétricas (WAN dual, enrutamiento por políticas, ECMP, eventos de failover SD‑WAN).
Revisa rp_filter y el comportamiento de la tabla de estados.
Usa tcpdump en ambas interfaces (LAN y VPN) para confirmar que los paquetes atraviesan como se espera.

Cuarto: MTU y fragmentación (el asesino silencioso)

Usa ping -M do con tamaños para encontrar la MTU funcional.
Busca “Frag needed and DF set”.
Limita MSS en el túnel.

Quinto: capa de aplicación e identidad

Prueba la conexión TCP (nc), luego TLS (openssl s_client si es necesario), luego la aplicación real.
Revisa firewalls y ACLs del lado servidor.
Valida respuestas DNS desde el sitio afectado.

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

Estos son los que siguen apareciendo porque son seductores.

1) “Solo permitimos subredes de servidores, pero los usuarios aún alcanzan escritorios remotos”

Síntoma: Usuarios de la Oficina A hacen RDP hacia máquinas aleatorias en la Oficina B.

Causa raíz: La “subred de servidores” incluye pools VDI, jump boxes con alcance amplio o escritorios mal clasificados. O permitiste 3389 ampliamente a la VLAN de servidores.

Solución: Separa admin/jump/VDI en subredes distintas y aplica reglas más estrictas. Usa un gateway RDP con MFA; bloquea 3389 directo inter‑oficina.

2) “Hace ping, HTTPS se agota”

Síntoma: ICMP funciona, el handshake TCP quizá funciona, pero las respuestas grandes se atascan.

Causa raíz: Desajuste MTU/MSS en el túnel u overlay; PMTUD bloqueado.

Solución: Limitar MSS en el borde VPN, permitir mensajes ICMP de fragmentación necesarios, ajustar MTU del túnel y verificar con pings DF.

3) “Bloqueamos todo, ahora nada funciona—incluido lo permitido”

Síntoma: Incluso reglas explícitas parecen ignoradas.

Causa raíz: Asignación incorrecta de zonas/interfaces, política aplicada en la dirección equivocada, o bypass de política por offload/fast-path del hardware.

Solución: Valida nombres de interfaz, membresía de zonas y orden de reglas. Desactiva temporalmente fast-path para depurar. Confirma con contadores y tcpdump.

4) “Tras el failover, algunos flujos mueren y nunca se recuperan”

Síntoma: Ocurre failover SD‑WAN; algunos usuarios se reconectan, otros quedan atascados.

Causa raíz: Dispositivos stateful pierden tablas de sesiones durante el cambio de ruta; la ruta asimétrica retorna por un túnel diferente; rp_filter estricto descarta paquetes de retorno.

Solución: Asegura enrutamiento simétrico o sincronización de sesiones en HA. Usa NAT consistente. Considera rp_filter loose en interfaces de túnel.

5) “No anunciamos subredes de clientes, pero la oficina remota aún las alcanza”

Síntoma: Juras que las rutas están filtradas, pero existe conectividad.

Causa raíz: Alguien añadió una ruta estática supernet, o una ruta por defecto cruza el túnel, o NAT hace hairpin de tráfico sin querer.

Solución: Audita rutas estáticas en gateways, busca 0/0 o grandes sumarios en los selectores de VPN/ACLs criptográficas, y verifica con ip route y tablas BGP.

6) “El acceso a la carpeta compartida es intermitente y lento entre oficinas”

Síntoma: SMB funciona, pero los usuarios se quejan constantemente.

Causa raíz: Comportamiento chatty de SMB sobre enlaces de mayor latencia, problemas con opportunistic locking y tráfico de resolución/descubrimiento bloqueado de forma extraña.

Solución: No extiendas SMB a través de oficinas como primera opción. Usa DFS con diseño cuidadoso, sincronización de archivos o publica mediante una pasarela cercana a los usuarios.

7) “El equipo de seguridad pidió ‘sin este‑oeste’ pero necesitamos monitorización”

Síntoma: Monitorización o backups se rompen tras la segmentación.

Causa raíz: Monitorización/backups dependían implícitamente de amplia alcanzabilidad (ICMP, SNMP, agentes, RPC).

Solución: Haz de la monitorización un servicio de primera clase: subred de monitorización dedicada, puertos explícitos y, idealmente, agentes pull con mTLS.

Broma 2: Una VPN sin filtrado es solo un cable Ethernet largo con sello de pasaporte.

Tres mini‑historias corporativas desde el terreno

Mini‑historia 1: El incidente causado por una suposición errónea

Dos oficinas. Un sitio “corporativo” y un “satélite”. El satélite necesitaba acceso a un puñado de apps internas y a un bastión SSH. El equipo de red desplegó un túnel sitio‑a‑sitio y pidió “las subredes” para enrutar.

El propietario de la app respondió algo como “Usamos 10.40.0.0/16.” Eso fue cierto del mismo modo que “el océano está mojado” es cierto: técnicamente exacto, operacionalmente inútil. Dentro de ese /16 vivían VLANs de servidores, VLANs de usuarios, impresoras y una red de laboratorio donde ingenieros probaban cosas que probablemente no debían.

La suposición errónea fue simple: “Si es interno, es de confianza.” En una semana, un portátil comprometido en el satélite (phishing, nada exótico) escaneó a través del túnel, encontró un antiguo share SMB en una VLAN de escritorios en la sede y lo usó como pivote. El atacante no necesitó un zero‑day. Necesitó alcanzabilidad y tiempo.

La forense fue incómoda. No porque el exploit fuera ingenioso—no lo fue—sino porque los registros eran escasos. El dispositivo VPN tenía “permitir cualquier” con registro mínimo para “evitar ruido”. El equipo de endpoints aseguraba que el portátil estaba parcheado. El equipo de red decía que el túnel era “privado”. Todos tenían razón en la forma que te hace ser comprometido.

La corrección no fue heroica. Dejar de anunciar el /16, dividir la red en prefijos de servidores publicados y obligar acceso administrativo vía bastión con MFA. El informe de respuesta usó la palabra “segmentación” unas cuarenta veces. La lección real fue menos palabras: deja de enrutar lo que no quieres asegurar.

Mini‑historia 2: La optimización que salió mal

Una empresa mediana desplegó SD‑WAN para conectar múltiples oficinas. El rendimiento mejoró de inmediato; el jitter cayó y las videollamadas dejaron de sonar como entrevistas submarinas. El equipo de red entonces “optimizó” la política de seguridad: en vez de docenas de reglas granulares, las resumieron en unas pocas grandes. Menos reglas, menos errores. Razonable, ¿no?

El problema fue el resumen. Reemplazaron múltiples prefijos destino de servidores por un agregado más amplio. Hizo el enrutamiento más limpio y la política de firewall más corta. También incluyó discretamente una VLAN “temporal” usada por contratistas, con dispositivos que eran gestionados… en el sentido de que alguien los había gestionado alguna vez.

Al principio no pasó nada. Por eso este tipo de fallo es peligroso: espera. Luego una máquina de contratista comenzó a generar tráfico sospechoso hacia un servicio Git interno en otra oficina. El acceso no fue bloqueado porque encajaba en la nueva regla agregada. El alertado no saltó porque el tráfico parecía HTTPS normal.

El postmortem no fue amable con la optimización. No perdieron datos, pero sí tiempo. Mucho. Tuvieron que deshacer el agregado, identificar lo que la VLAN de contratistas debía acceder (casi nada) e introducir route‑maps para evitar inclusión accidental en futuros resúmenes.

Conclusión: la agregación es una optimización de rendimiento; la segmentación es una decisión de riesgo. No dejes que una conveniencia de enrutamiento reescriba tu modelo de seguridad.

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

Una organización financiera con dos oficinas principales tenía una política inter‑oficina estricta: solo subredes de servidores, solo puertos específicos y todas las reglas controladas por cambio con un propietario y fecha de expiración. No era emocionante. La gente se quejaba del proceso. Naturalmente.

Una tarde llegó un ticket: “Usuario en Oficina A no puede acceder a algo en Oficina B.” La petición sonaba legítima y urgente. Empezó la presión habitual: “Ábrelo temporalmente.”

El SRE de guardia hizo lo aburrido. Revisó los registros del firewall y vio intentos repetidos de alcanzar TCP/445 y TCP/135 entre oficinas desde una VLAN de usuarios—patrones clásicos de movimiento lateral, no “acceder a la app”. También revisó DNS y encontró que el usuario intentaba alcanzar un hostname que resolvía a una subred de escritorios en la Oficina B, no al endpoint de servicio publicado.

En vez de abrir el firewall, arreglaron el problema: corrigieron el DNS para que el hostname apuntara a un reverse proxy en la VLAN de servidores, y añadieron un permiso estrecho a TCP/443 solo para ese proxy. Mientras tanto, el equipo de seguridad investigó el endpoint del usuario. Resultó estar infectado con algo que estaba intentando su suerte.

No pasó nada dramático porque la política ya estaba diseñada para hacer lo dramático aburrido. Ese es el objetivo: hacer que la ruta segura sea la fácil y la ruta insegura ruidosa y bloqueada.

Listas de verificación / plan paso a paso

Paso a paso: implementar “solo servidores” sin romper el negocio

Inventaria las subredes por función: cliente, servidor, infra, invitados, lab. Si no puedes etiquetar una subred, no está lista para enrutarse a ningún lado.
Define los prefijos de destino permitidos por oficina: normalmente solo servidor + infra. Mantenlo corto.
Define puertos de servicio por caso de uso:
- Apps web: 443 a reverse proxies
- Admin: 22 solo desde bastiones; evita SSH directo oficina→servidor
- Directorios: solo lo necesario, desde orígenes específicos
- Monitorización: desde la subred de monitorización solo
Arregla el enrutamiento primero: filtrado de prefijos o rutas estáticas solo para los prefijos permitidos. No exportes VLANs de clientes.
Aplica políticas de firewall: denegar por defecto, permisos explícitos, con registro. Asegura ambas direcciones (las políticas stateful ayudan, pero no esperes magia).
Decide la política NAT: idealmente ninguna para interno→interno, pero si debes NATear, hazlo consistentemente y documenta por qué. NAT puede ocultar pecados de enrutamiento; no los absuelve.
Publica apps en vez de redes cuando sea posible: reverse proxies, gateways, SSO, MFA. Los usuarios quieren apps, no subredes.
Implementa un flujo de cambios: cada nuevo permiso inter‑oficina necesita un propietario y una expiración. Las reglas permanentes están bien; las temporales eternas son una mentira.
Prueba desde ambos lados: comprobaciones de rutas, puertos y aplicaciones. Valida MTU temprano.
Baseline de registros y contadores: debes poder responder “qué se descartó” y “qué se permitió” durante un incidente.
Ejecuta un simulacro de mesa: simula una fuga de rutas o un prefijo mal resumido y verifica la detección (alertas sobre nuevos prefijos, picos en descartes, flujos inesperados).

Lista operacional: qué monitorizar continuamente

Nuevas rutas aprendidas sobre la adyacencia inter‑oficina (especialmente agregados amplios y VLANs de clientes).
Contadores de reglas de firewall para “deny interoffice” (picos suelen indicar escaneo o mala configuración).
Indicadores de MTU/fragmentación del túnel y retransmisiones TCP.
Cambios de camino SD‑WAN y eventos de failover correlacionados con quejas de aplicaciones.
Anomalías DNS: nombres internos resolviendo a subredes inesperadas por sitio.
Señales de identidad: fallos MFA, uso inusual de bastiones, comportamiento anómalo de cuentas de servicio.

Preguntas frecuentes

1) ¿Es mejor bloquear rutas que bloquear con reglas de firewall?

Sí, cuando puedes. El filtrado de rutas reduce la superficie alcanzable antes de que los paquetes lleguen a la política. Usa ambas: filtrado de rutas para alcanzabilidad, firewall para puertos y registro.

2) Necesitamos que usuarios de la Oficina A accedan a una base de datos en la Oficina B. ¿Permitimos la subred DB?

Prefiere publicar a través de una capa de aplicación o un proxy en la Oficina B. Si debes permitir acceso a la BD, restríngelo a subredes (o hosts) origen específicas y a puertos específicos, y regístralo. Las bases de datos no son servicios casuales entre oficinas.

3) ¿Podemos confiar en Windows Firewall en servidores en lugar de firewalls de red?

Usa Windows Firewall, por supuesto. Pero no confíes en él como único control perimetral. La aplicación en red te da política consistente, registros centralizados y un punto de estrangulamiento más difícil de eludir.

4) ¿Y si “confiamos en nuestras oficinas” porque es la misma empresa?

La confianza no es un principio de diseño de red. Las oficinas contienen dispositivos no gestionados, contratistas, equipos de salas de reuniones y endpoints que navegan Internet todo el día. Trata el enlace inter‑oficina como transporte no confiable que lleva servicios permitidos explícitamente.

5) ¿Deberíamos NAT entre oficinas para “ocultar” redes?

Sólo si tienes una razón clara (espacio IP solapado, integración por adquisición). NAT puede simplificar colisiones de direccionamiento, pero complica la depuración, rompe algunos protocolos y da confianza falsa. Si NATeas, documéntalo y estandarízalo.

6) ¿Cómo manejar rangos RFC1918 solapados tras una adquisición?

Corto plazo: NAT en el límite y mantiene los servicios permitidos muy estrechos. Medio plazo: renumerar un lado o introducir un segmento de traducción con propiedad clara. Largo plazo: deja de tratar el espacio IP como un detalle en integraciones.

7) Nuestro equipo de seguridad dice “zero trust”. ¿Qué significa para oficina‑a‑oficina?

Significa que la ubicación en la red no es suficiente. Mantén listas de subredes permitidas, pero añade identidad: mTLS, proxies SSO, postura de dispositivo y MFA para caminos administrativos. “Solo servidores” pasa a ser “solo servicios específicos en servidores específicos con identidad verificada”.

8) ¿Cómo evitamos que reglas “temporales” se vuelvan permanentes?

Haz obligatorias las fechas de expiración y automatiza recordatorios (o deshabilitado automático) cuando venza. Si una regla aún es necesaria, renuévala con justificación. La fricción aquí es una característica.

9) ¿Qué puertos no deberían permitirse ampliamente entre oficinas?

En general: SMB (445), NetBIOS (137–139), RPC endpoint mapper (135) y RDP directo (3389). Hay excepciones, pero deben sentirse como excepciones y venir con controles compensatorios.

10) ¿Cuál es la prueba más rápida de que logramos “solo servidores”?

Desde una subred de cliente en la Oficina A deberías tener (a) sin ruta a las VLANs de clientes de la Oficina B, y (b) registros de firewall mostrando descartes para cualquier intento. Desde orígenes aprobados, puertos aprobados a subredes de servidores deberían tener contadores limpios y éxito.

Conclusión: próximos pasos que puedes hacer esta semana

“Solo servidores, no toda la LAN” no es un eslogan. Es un diseño que se hace cumplir con disciplina de enrutamiento, política de denegación por defecto y registros que dicen la verdad cuando alguien insiste “antes funcionaba”.

Pasos prácticos:

Lista cada subred en ambas oficinas y etiquétala client/servidor/infra/invitados/lab.
Deja de anunciar VLANs de clientes sobre el enlace inter‑oficina. Usa prefix‑lists o ajusta rutas estáticas.
Implementa una política de firewall inter‑oficina por defecto-deny con permisos explícitos a subredes de servidores y puertos estrechos.
Publica apps vía gateways/proxies en lugar de abrir acceso de red amplio (especialmente RDP y SMB).
Añade registro y contadores, luego establece la línea base de lo “normal” antes de que el próximo incidente te enseñe por las malas.

Si haces una sola cosa: filtra rutas para que las redes equivocadas no sean alcanzables en absoluto. Cada otro control se vuelve más fácil cuando la alcanzabilidad ya está restringida.