Acceso por grupos sobre una sola VPN: Contabilidad, Almacén, TI y permisos distintos

El modelo: una VPN, muchos derechos

“Una VPN” no quiere decir “un único nivel de confianza”. Significa un punto de entrada y una superficie operativa: una experiencia de perfil cliente,
un flujo de soporte, un lugar para rotar claves y certificados. Los derechos se calculan después de la autenticación y se aplican en el camino
al destino. Piénsalo como un aeropuerto: todos entran al edificio, pero no todos llegan a la cabina.

Para contabilidad, “derechos” normalmente significa acceso al ERP, recursos financieros y quizá un salto a un servidor de terminales.
Para almacén, suele ser WMS, aplicaciones de escáneres de código de barras, impresoras y quizá una carpeta de depósito limitada. Para TI, son redes de administración,
interfaces de gestión, backups, hipervisores y la autoridad para “romper el vidrio” cuando todo está en llamas.

Obtienes acceso fiable por grupos combinando cuatro primitivas:

• Identidad fuerte: ¿quién es este usuario/dispositivo y cuán seguros estamos?
• Pertenencia a grupos: ¿qué rol(es) tiene ahora mismo?
• Política: a qué puede acceder ese rol (redes, puertos, aplicaciones, shares).
• Aplicación: dónde se aplica realmente esa política (firewall, enrutamiento, ACLs de almacenamiento, autenticación de aplicaciones).

Si solo aplicas una capa, te decepcionarás. Si aplicas dos, dormirás mejor. Si aplicas tres o cuatro,
dejarás de tener debates filosóficos sobre “seguridad vs productividad” porque el sistema será ambas cosas.

Idea parafraseada (atribución): Los sistemas que deben ser fiables deberían asumir que las cosas fallan y diseñar para esa realidad — John Allspaw.
La VPN y sus políticas no son la excepción.

Chiste #1: Una VPN sin controles de acceso es como una discoteca con un solo portero y sin lista: todos entran, y el DJ termina haciendo respuesta a incidentes.

Datos interesantes y contexto histórico

• Las VPN empezaron como “tuberías seguras”, no como “sistemas de identidad”. El pensamiento inicial de IPsec priorizaba el túnel; la autorización fue a menudo un afterthought.
• El split tunneling ha sido controvertido desde que se hizo común. Es un tradeoff de seguridad: menos backhaul, más riesgo si los endpoints están desordenados.
• RADIUS precede a la mayoría de flujos modernos de UI para VPN. La autorización por grupos vía atributos RADIUS existe desde hace décadas.
• La proliferación de grupos en Active Directory es un modo de fallo predecible. Los grupos de “acceso temporal” tienden a convertirse en compañeros permanentes.
• La segmentación de red solía ser mayormente física. VLANs y VRFs la hicieron lógica; la política VPN moderna la hace impulsada por identidad.
• Los permisos SMB y POSIX evolucionaron por separado. Cuando mezclas Samba + ACLs de Linux + grupos de Windows, los malentendidos están garantizados.
• “Zero Trust” es una etiqueta nueva para principios antiguos. Menor privilegio, autenticación fuerte y registros no se inventaron en 2019; solo tienen mejor marketing ahora.
• WireGuard es joven pero con opinión propia. Intencionalmente evita la autenticación de usuarios integrada; se espera que integres identidad en otro lugar.
• Los requisitos de auditoría moldean silenciosamente la arquitectura. Si no puedes responder “quién accedió a qué”, tu diseño será reescrito por cumplimiento más adelante.

Arquitectura de referencia que realmente funciona

Elige un plano de control, y luego cúmplelo

La forma más rápida de construir una VPN frágil es permitir que cada capa invente su propia noción de “grupo”.
Tu servidor VPN tiene “configs de cliente”, tu firewall tiene “objetos de dirección”, tu NAS tiene “usuarios locales”,
y tus auditores tienen “preguntas”. No hagas eso.

Elige una fuente de identidad única:

• Active Directory (AD) si ya eres una organización Windows.
• LDAP/FreeIPA si quieres identidad nativa fuerte en Linux.
• Un proveedor de identidad + SSO si modernizas, pero sé realista sobre la complejidad operativa.

Puntos de aplicación: donde la política se vuelve real

El diseño limpio usa múltiples puntos de aplicación, cada uno haciendo lo que mejor sabe:

• Gateway VPN: autenticación, asignación IP, push de rutas/DNS, política por grupo a nivel grueso.
• Firewall/pasarela de segmentos: acceso de menor privilegio a la red (puertos, destinos) con logs auditables.
• Controles de aplicación: ERP/WMS/SSH tienen su propia autenticación; úsala.
• Controles de almacenamiento: Samba/NTFS ACLs, NFSv4 ACLs, S3/IAM, delegación de dataset ZFS — lo que encaje, pero hazlo cumplir.

La pasarela VPN no es un aparato mágico de políticas. Es un cuello de botella. Úsala para asegurar que las identidades mapeen a IPs y rutas esperadas.
Luego haz que el firewall sea la fuente de la verdad sobre “quién puede hablar con qué”.

Un diseño concreto y amigable para producción

Aquí tienes un esquema que escala y no se convierte en una casa encantada:

• Una entrada VPN: vpn-gw01 (y vpn-gw02 para HA si valoras los fines de semana).
• Segmentos internos separados detrás de una frontera firewall/VRF:
  • FIN-NET (aplicaciones contables, comparticiones financieras)
  • WMS-NET (servidores de aplicación del almacén, impresoras)
  • MGMT-NET (hipervisores, iDRAC/iLO, servidores de backup)
  • USER-NET (servicios corporativos generales)
• Pools de direcciones VPN por grupo (o por rol), por ejemplo:
  • 10.66.10.0/24 para contabilidad
  • 10.66.20.0/24 para almacén
  • 10.66.30.0/24 para TI
• Reglas de firewall basadas en el pool fuente VPN junto con logs de identidad desde la autenticación VPN.
• DNS por grupo: los usuarios financieros no deberían resolver nombres de mgmt, no porque DNS sea “seguridad”, sino por higiene y para reducir errores.

Verás el patrón: aislar por defecto, permitir de forma estrecha y facilitar la demostración.

Identidad y mapeo de grupos: donde empieza el control de acceso

Usuarios vs dispositivos: decide qué estás autorizando

Los entornos de almacén a menudo tienen dispositivos compartidos, inicios de sesión en kiosco o escáneres embebidos.
Contabilidad tiende a tener usuarios nominales con mayor sensibilidad. TI suele tener usuarios nominales y dispositivos privilegiados.

Decide, de forma explícita:

• VPN basada en usuario: el usuario se autentica con MFA; la pertenencia a grupos se deriva de grupos del directorio.
• VPN basada en dispositivo: certificado de dispositivo o clave precompartida; el grupo se deriva de la identidad del dispositivo.
• Híbrido: el dispositivo debe estar inscrito y además el usuario debe autenticarse (lo mejor para acceso de administradores TI).

Si no puedes articular si tus escáneres de almacén son “usuarios” o “dispositivos”, estás a punto de construir la política equivocada.

Mapeo de grupos: mantenlo aburrido

Usa un número reducido de “grupos de acceso” que correspondan a conjuntos de políticas de red, no a organigramas.
Los grupos organizacionales cambian con reorganizaciones y política interna. Los grupos de acceso deberían cambiar con las necesidades de las aplicaciones.

Patrón práctico:

• VPN-Accounting → apps FIN + comparticiones financieras
• VPN-Warehouse → app WMS + impresoras
• VPN-IT → redes mgmt + jump hosts + SSH/RDP a servidores
• VPN-AllUsers → línea base mínima (DNS, NTP, gestión de endpoints)

MFA: hazlo, pero sin ser performativo

MFA no es una política. Es una medida que ayuda cuando las credenciales se filtran.
Sigues necesitando controles de autorización porque un atacante con un token de sesión comprometido no se impresionará con tus carteles motivacionales.

Capas de aplicación: enrutamiento, firewall y almacenamiento

Enrutamiento: controla el radio de impacto con pools y push de rutas

Asigna pools VPN separados por grupo. Esta es la palanca más simple y fácil de auditar que tienes.
Facilita el firewall y hace que las investigaciones de “quién hizo esto” sean menos como leer hojas de té.

El push de rutas debe ser mínimo:

• Los clientes de contabilidad reciben rutas solo a FIN-NET y a servicios corporativos compartidos que realmente necesitan.
• Los clientes de almacén reciben rutas solo a WMS-NET y subredes de impresoras.
• Los clientes de TI pueden obtener rutas más amplias, pero aún se prefieren jump hosts para superficies administrativas.

Si te tienta “simplemente empujar 0.0.0.0/0 a todos” para hacerlo fácil: eso no es simplicidad, es deuda.

Firewall: el adulto en la sala

La política de firewall debe ser explícita, registrada y con control de cambios.
Prefiere listas de permitidos por grupo. Negar por defecto. Registra los denegados para depuración (pero limita la tasa para no DDoS tu propio SIEM).

Una estructura de reglas sólida:

• Fuente: pool VPN (10.66.10.0/24)
• Destino: subnet de aplicación o grupo de hosts
• Servicio: TCP/443, TCP/445, UDP/161, etc.
• Acción: allow + log (al menos para redes de administración)

Permisos de almacenamiento: donde “acceso de red” no es suficiente

Los datos financieros no se protegen por estar en FIN-NET. Se protegen porque el servidor de archivos aplica los permisos.
Si un usuario de almacén puede montar un share SMB y navegar carpetas de contabilidad, tu segmentación de red es decorativa.

Haz esto correctamente:

• Samba/SMB: usa ACLs respaldadas por AD; mapea grupos de forma clara; evita usuarios locales en el NAS para shares corporativos.
• NFSv4: prefiere ACLs NFSv4 con identidad respaldada por directorio; no confíes en adivinanzas de UID.
• Datasets ZFS: datasets separados por clase de sensibilidad; snapshots; delegación para operaciones TI sin acceso a los datos cuando sea posible.

Chiste #2: Si tu “política de acceso” es una hoja de cálculo y esperanza, felicidades: has inventado Compliance Theater: El Musical.

Tareas prácticas con comandos, salidas y decisiones

Estas son las tareas que realmente ejecutas cuando construyes o depuras acceso por grupos sobre una sola VPN.
Cada tarea incluye: un comando, qué significa la salida típica y la decisión que tomas.
Los nombres de host y rutas son realistas; ajústalos a tu entorno.

1) Confirma que la interfaz VPN está arriba y tiene el pool de direcciones correcto

cr0x@server:~$ ip -brief addr show dev wg0
wg0             UNKNOWN        10.66.0.1/16

Significado: La interfaz gateway existe y tiene el supernet esperado. Si pretendías pools /24 separados,
el gateway aún puede usar un prefijo más amplio; eso está bien siempre que las reglas del firewall se basen en la IP fuente del cliente.

Decisión: Si la interfaz falta o la IP es incorrecta, para y arregla el bring-up/config de la VPN antes de perseguir “permisos”.

2) Verifica peers VPN activos y sus direcciones asignadas

cr0x@server:~$ sudo wg show wg0
interface: wg0
  public key: 3m4x...redacted
  listening port: 51820

peer: Zq1a...redacted
  endpoint: 198.51.100.24:53321
  allowed ips: 10.66.10.23/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 102.45 MiB received, 88.22 MiB sent

Significado: Este peer está usando 10.66.10.23, que debería corresponder a un grupo (aquí: pool de contabilidad).
Un handshake reciente confirma que el túnel está vivo.

Decisión: Si un usuario de almacén aparece en el rango de contabilidad, tu lógica de asignación identidad→IP está rota.
Arregla eso antes de ajustar reglas de firewall; de lo contrario “arreglarás” abriendo agujeros.

3) Verifica el enrutamiento hacia una subred protegida desde el gateway VPN

cr0x@server:~$ ip route get 10.20.10.50
10.20.10.50 via 10.0.0.1 dev eth0 src 10.0.0.10 uid 1000

Significado: El gateway sabe cómo alcanzar FIN-NET (host ejemplo 10.20.10.50). Si esto está mal, los clientes pueden autenticarse pero no alcanzarán nada.

Decisión: Si la ruta apunta a un lugar inesperado (o falta), arregla el enrutamiento interno/VRF antes de culpar a los usuarios VPN.

4) Confirma el forwarding IP en el gateway (clásico “conecta pero nada funciona”)

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Significado: El gateway puede enrutar tráfico entre interfaces.

Decisión: Si está a 0, habilítalo (y persístelo) antes de depurar reglas de firewall.

5) Inspecciona reglas nftables que limitan los pools VPN

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ip saddr 10.66.10.0/24 ip daddr 10.20.10.0/24 tcp dport { 443, 445 } accept
    ip saddr 10.66.20.0/24 ip daddr 10.30.20.0/24 tcp dport 443 accept
    ip saddr 10.66.30.0/24 ip daddr 10.40.0.0/16 accept
    counter drop
  }
}

Significado: Drop por defecto. Luego allows explícitos por pool VPN. Esto es lo que “derechos distintos” parece en la vida real.

Decisión: Si contabilidad puede alcanzar redes de almacén o mgmt, probablemente encontrarás una regla allow demasiado amplia o un rango fuente inesperado.

6) Valida que el firewall esté registrando el deny que te importa

cr0x@server:~$ sudo journalctl -k -n 20 | grep -E "DROP|DENY" | tail
Dec 28 11:04:02 vpn-gw01 kernel: IN=wg0 OUT=eth0 SRC=10.66.20.44 DST=10.20.10.50 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=39321 DF PROTO=TCP SPT=51522 DPT=445 WINDOW=64240 SYN

Significado: Un cliente de almacén intentó acceder a SMB en un servidor financiero y fue bloqueado. Bien. Eso es la política aplicándose.

Decisión: Si no ves logs, o los paquetes no llegan al gateway (enrutamiento) o el logging no está habilitado (depuración más difícil).

7) Confirma qué IP tiene realmente un usuario (desde el cliente)

cr0x@server:~$ ip -brief addr show dev wg0
wg0             UNKNOWN        10.66.20.44/32

Significado: El cliente está en el pool de almacén. Este es tu primer chequeo de cordura cuando alguien dice “estoy en contabilidad pero no puedo alcanzar finanzas”.

Decisión: Si la IP no coincide con el pool esperado, arregla el mapeo de grupos o la asignación de perfiles, no el firewall.

8) Prueba la accesibilidad a un servicio permitido (TCP/443) e interpreta modos de fallo

cr0x@server:~$ nc -vz -w 2 10.30.20.10 443
Connection to 10.30.20.10 443 port [tcp/https] succeeded!

Significado: La ruta de red y el allow en el firewall están bien para ese servicio.

Decisión: Si expira el tiempo de espera, suele ser enrutamiento/firewall. Si aparece “refused”, el host es alcanzable pero el servicio no está escuchando o está bloqueado localmente.

9) Traza la ruta cuando el enrutamiento es extraño (especialmente con múltiples saltos internos)

cr0x@server:~$ traceroute -n 10.20.10.50
traceroute to 10.20.10.50 (10.20.10.50), 30 hops max, 60 byte packets
 1  10.66.0.1  9.214 ms  9.012 ms  9.118 ms
 2  10.0.0.1   10.202 ms  10.144 ms  10.165 ms
 3  10.20.10.50  11.011 ms  10.989 ms  10.972 ms

Significado: Ves el gateway VPN, luego el router/firewall interno, luego el destino. Ese es el camino feliz.

Decisión: Si muere en el hop 1, es local cliente/VPN. Si muere en el hop 2, es enrutamiento/firewall interno.

10) Verifica comportamiento DNS por grupo (porque “no alcanza ERP” suele ser “resolución de nombres incorrecta”)

cr0x@server:~$ resolvectl status wg0
Link 12 (wg0)
      Current Scopes: DNS
DefaultRoute setting: no
       LLMNR setting: no
MulticastDNS setting: no
  DNS Servers: 10.20.10.53
   DNS Domain: corp.example

Significado: El DNS para la interfaz VPN apunta al servidor DNS de finanzas (ejemplo). Si los usuarios de almacén no deben usar este DNS,
no deberían recibirlo por push.

Decisión: Si se aplica el DNS incorrecto, arregla el DNS push de la VPN o la configuración del cliente; no “arregles” abriendo el firewall a resolvers aleatorios.

11) Confirma la pertenencia a grupos en AD para un usuario (entrada de autorización)

cr0x@server:~$ id jsmith
uid=11820(jsmith) gid=10513(domain users) groups=10513(domain users),12900(VPN-Warehouse),12910(WMS-Users)

Significado: Este usuario está en VPN-Warehouse y debería recibir la política de acceso de almacén.

Decisión: Si falta el grupo VPN esperado, arregla la pertenencia en el directorio y vuelve a autenticar; no añadas excepciones en el firewall.

12) Inspecciona ACLs de share Samba (aplicación en almacenamiento)

cr0x@server:~$ getfacl /srv/samba/finance
# file: srv/samba/finance
# owner: root
# group: "CORP\\Finance Admins"
user::rwx
group::rwx
group:"CORP\\Accounting":rwx
group:"CORP\\Warehouse":---
mask::rwx
other::---

Significado: Almacén no tiene permisos. Contabilidad sí. Esto es lo que “derechos distintos” parece donde residen los datos.

Decisión: Si almacén puede leer finanzas de todos modos, probablemente tengas otro path de share, ACLs heredadas o una mala configuración de mapeo de SMB guest.

13) Confirma que SMB ve el mapeo de identidad correcto (clásico “permisos parecen correctos pero acceso falla”)

cr0x@server:~$ wbinfo -i jsmith
jsmith:*:11820:10513:John Smith:/home/CORP/jsmith:/bin/bash

Significado: Winbind puede mapear el usuario AD a una identidad Unix. Si esto falla, las ACLs que referencian grupos AD no se comportarán bien.

Decisión: Arregla la integración de directorio (Kerberos, winbind, SSSD) antes de tocar las ACLs.

14) Prueba cuál lado está descartando paquetes con tcpdump (úsalo con moderación, pero úsalo)

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.66.10.23 and host 10.20.10.50 and tcp port 445 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
11:06:41.112233 IP 10.66.10.23.51422 > 10.20.10.50.445: Flags [S], seq 11223344, win 64240, options [mss 1380,sackOK,TS val 12345 ecr 0,nop,wscale 7], length 0
11:06:42.114512 IP 10.66.10.23.51422 > 10.20.10.50.445: Flags [S], seq 11223344, win 64240, options [mss 1380,sackOK,TS val 13345 ecr 0,nop,wscale 7], length 0

Significado: Los SYNs llegan a la interfaz VPN; si no hay SYN-ACK de vuelta, el drop está aguas abajo (firewall, enrutamiento, firewall del host, servicio).

Decisión: Si ves tráfico en wg0 pero no en eth0, el firewall del gateway está descartando. Si lo ves también en eth0, está aguas abajo.

15) Revisa conntrack para estado (especialmente con enrutamiento asimétrico)

cr0x@server:~$ sudo conntrack -L | grep 10.66.10.23 | head
tcp      6 117 SYN_SENT src=10.66.10.23 dst=10.20.10.50 sport=51422 dport=445 src=10.20.10.50 dst=10.66.10.23 sport=445 dport=51422 [UNREPLIED] mark=0 use=1

Significado: El gateway ve el intento saliente, pero no está recibiendo respuestas. Eso estrecha mucho la búsqueda.

Decisión: Mira las políticas del firewall interno, las rutas de retorno y el firewall del host en 10.20.10.50.

16) Valida rutas de retorno en un servidor interno (el clásico “funciona desde LAN, no desde VPN”)

cr0x@server:~$ ip route
default via 10.20.10.1 dev eth0
10.20.10.0/24 dev eth0 proto kernel scope link src 10.20.10.50

Significado: La puerta de enlace por defecto del servidor es 10.20.10.1. Si los clientes VPN vienen de 10.66.0.0/16 y 10.20.10.1 no sabe cómo devolver,
las respuestas pueden ser black-holed.

Decisión: Asegura que el gateway interno conozca rutas de retorno a los pools VPN (o SNAT en el gateway VPN —último recurso, pero a veces operativo sensato).

Guía de diagnóstico rápido

Cuando un usuario dice “la VPN está rota”, quiere decir cinco cosas distintas. Tu trabajo es encontrar el cuello de botella en minutos, no horas.
Aquí está el orden que funciona en producción.

Primero: identifica el alcance y clasifica la falla

• Un usuario vs un grupo vs todos.
• Fallo de autenticación vs conectado pero no alcanza vs alcanza pero sin permisos.
• Una app vs todos los destinos internos.

Si es todos: para. Estás mirando salud del gateway, certificados/keys, enrutamiento o una caída aguas arriba.
Si es un grupo: sospecha mapeo de grupo, asignación de pool, orden de reglas del firewall o pushes de ruta.
Si es un usuario: sospecha identidad (pertenencia a grupos), config del cliente o controles de postura del dispositivo.

Segundo: verifica el túnel y la IP asignada

• En el gateway: wg show / archivo de estado OpenVPN / estado SA de IPsec.
• En el cliente: IP de interfaz y ajustes DNS.

Un rango de IP incorrecto significa derechos incorrectos. Eso no es un “bug de red”, es un bug de mapeo de autorización.

Tercero: prueba un flujo permitido de extremo a extremo

• Elige un destino conocido bueno para ese grupo (p. ej., almacén → WMS HTTPS).
• Prueba con nc o curl en lugar de “abrir un navegador y sentir”.
• Observa logs de denegados del firewall mientras pruebas.

Cuarto: localiza la caída

• ¿El gateway ve el paquete en la interfaz VPN?
• ¿El gateway lo reenvía por la interfaz LAN?
• ¿El firewall interno lo ve y permite?
• ¿El host destino responde?

Quinto: solo entonces toca permisos de almacenamiento

Si la red no llega al servidor de archivos, los permisos no importan.
Si la red llega al servidor pero el acceso es denegado, ahora estás en territorio de ACLs (logs Samba, permisos efectivos, mapeo de grupos).

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

1) “Almacén puede ver comparticiones financieras”

Síntomas: Un usuario de almacén puede navegar o leer shares SMB de finanzas tras conectar la VPN.

Causa raíz: Existe segmentación de red, pero la ruta del share financiero es accesible desde una VLAN de servidor de archivos general; herencia de ACL o permisos “Everyone”/“Domain Users” filtrados.

Solución: Coloca las comparticiones financieras en un dataset/share dedicado con denegación explícita/ausencia para grupos de almacén; verifica con getfacl y comprobaciones de acceso efectivo SMB; restringe rutas de red para que solo el pool de contabilidad pueda alcanzar TCP/445 en los servidores de archivos financieros.

2) “Contabilidad no alcanza ERP, pero el ping funciona”

Síntomas: ICMP tiene éxito; la conexión a la aplicación falla o expira.

Causa raíz: El firewall permite ICMP (o no está filtrado) pero bloquea TCP/443 o el puerto de la app; a veces problemas de MTU causan bloqueo TLS.

Solución: Prueba con nc -vz al puerto exacto; revisa reglas de firewall para el pool de contabilidad; si TLS se queda, prueba MTU (ping -M do -s) y ajusta MSS en el gateway.

3) “TI alcanza servidores, pero SSH se congela aleatoriamente”

Síntomas: TCP conecta, luego sesiones se congelan intermitentemente, especialmente sobre redes móviles.

Causa raíz: PMTUD bloqueado, causando fragmentación problemática; o presión en la tabla conntrack bajo carga.

Solución: Habilita clamping de MSS en el gateway; revisa uso de conntrack y aumenta límites si procede; asegúrate de que ICMP “fragmentation needed” no esté bloqueado internamente.

4) “Usuario fue movido a contabilidad, sigue teniendo acceso de almacén”

Síntomas: Cambio de grupo en directorio hecho, pero derechos VPN no cambian por horas.

Causa raíz: Pertenencia a grupos cacheada por la capa de autenticación VPN (RADIUS/LDAP) o sesiones VPN de larga duración no forzadas a re-autenticar.

Solución: Reduce TTL del cache de autenticación, fuerza re-autenticación en cambios de grupo, define duraciones de sesión; operativamente: ten un runbook “derechos cambiados → desconectar sesión”.

5) “Todos reciben rutas completas a pesar de la configuración por grupo”

Síntomas: Clientes de almacén ven rutas internas que no deberían; traceroute va a lugares indebidos.

Causa raíz: Config cliente por defecto empuja rutas amplias; overrides por grupo no aplicados o el orden es incorrecto.

Solución: Haz el push de rutas por grupo de forma explícita y prueba con un perfil de cliente limpio; trata las configs cliente como código, con revisión y despliegue por etapas.

6) “VPN conectada, pero DNS resuelve nombres internos a IPs públicas”

Síntomas: Usuarios alcanzan endpoints equivocados; SSO entra en bucle; errores de app que parecen fallos de autenticación.

Causa raíz: Split DNS no configurado; el cliente sigue usando resolvers domésticos/públicos; dominios de búsqueda no establecidos.

Solución: Push de servidores DNS y dominios correctos por grupo; verifica con resolvectl; evita confiar en ajustes DNS manuales en endpoints.

7) “El acceso funciona un tiempo y luego falla tras cambios de red”

Síntomas: Tras agregar una nueva subred o mover una app, un grupo pierde acceso mientras otros están bien.

Causa raíz: Objetos/grupos de firewall no actualizados; ruta no anunciada; deriva de políticas entre entornos.

Solución: Mantén una fuente única de verdad para subredes y políticas; añade hooks de cambio: cuando se introduce una subred, actualiza push de rutas y reglas de firewall juntos y valida con pruebas de conectividad.

8) “Usuario financiero no puede abrir hojas en SMB, pero puede listar directorios”

Síntomas: Listado de directorios funciona; abrir archivos falla con errores de permisos o bloqueo.

Causa raíz: Permisos a nivel de archivo OK, pero ACLs NTFS/Samba incorrectas en archivos; o mismatch en requerimientos de firmado/encriptación SMB; a veces opportunistic locking afecta clientes antiguos.

Solución: Revisa ACLs de archivos y herencia, no solo la carpeta superior; verifica configuración Samba; prueba con un cliente Windows conocido bueno; mantén coherencia en la seguridad SMB.

Tres micro-historias de la vida corporativa

Micro-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana consolidó acceso remoto en una sola VPN “para simplificar soporte”. Objetivo sensato.
El equipo de red separó pools VPN para contabilidad y almacén y lo dio por terminado. También sensato —en papel.
Luego un supervisor de almacén abrió un ticket: “Puedo ver carpetas de finanzas. ¿Es normal?”

La suposición fue que si almacén no podía enrutar a FIN-NET, no podría acceder a datos financieros.
Desgraciadamente, las comparticiones financieras no estaban en FIN-NET. Vivían en un servidor de archivos de uso general accesible desde USER-NET,
porque “son solo archivos” y el servidor de archivos existía desde antes del proyecto de segmentación.
La segmentación de red y la ubicación de datos se distanciaron con los años como dos colegas que dejaron de hablar tras una reorganización.

La solución inmediata fue fea pero efectiva: regla de firewall bloqueando TCP/445 desde el pool de almacén al servidor de archivos.
Eso detuvo el problema pero también rompió cargas legítimas del almacén, porque estaban en el mismo servidor.
La solución real tardó una semana: crear comparticiones Samba separadas respaldadas por datasets ZFS separados, mover datos financieros a un dataset exclusivo de finanzas,
y aplicar ACLs respaldadas por AD. La compartición del almacén permaneció accesible; finanzas no.

La lección no fue “la segmentación es mala”. La lección fue que la segmentación sin aplicación en almacenamiento es una sugerencia,
y a los atacantes les encantan las sugerencias.

Micro-historia 2: La optimización que salió mal

En otro sitio, otra “idea inteligente”: reducir CPU del servidor VPN y simplificar enrutamiento haciendo SNAT de todo el tráfico cliente VPN a una IP gateway única.
El argumento fue rendimiento y simplicidad: menos rutas internas necesarias, menos estado distribuido por el estate de firewall.
Incluso “funcionó”, como una pared recién pintada “funciona” para esconder una grieta.

Llegó la temporada de auditoría. El equipo de seguridad preguntó: “¿Qué usuarios accedieron a la subred de la app financiera el martes pasado?”
Con SNAT, los logs internos solo mostraban la IP del gateway. Los logs VPN tenían identidades, claro, pero correlacionar por-flujo requería coser
tiempos de sesión y adivinar qué tráfico pertenecía a cada usuario. Era posible, pero indefendible.

Operativamente, SNAT también empeoró la depuración. Cuando la app WMS se ralentizó, los equipos de aplicación culparon a la VPN.
El equipo de VPN culpó a la app. El equipo de firewall tenía una sola IP origen para todos, así que no podía aislar clientes ruidosos ni ver comportamientos por grupo.
El sistema perdió observabilidad, y cada incidente tomó más tiempo porque la verdad había que reconstruirla.

Finalmente revirtieron SNAT y añadieron rutas de retorno adecuadas desde las redes internas a los pools VPN.
La CPU subió un poco; la claridad subió mucho. Esa suele ser una buena compensación.

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

Una empresa con estricta separación entre contabilidad y almacén tenía una práctica que parecía dolorosamente aburrida: “chequeos de realidad” trimestrales de acceso.
No un ejercicio anual de casilla. Trimestral. Un conjunto pequeño de pruebas scriptadas corría desde tres cuentas de prueba —una por grupo— y verificaba alcance:
¿puede contabilidad alcanzar ERP? ¿puede almacén alcanzar WMS? ¿puede TI alcanzar jump hosts? ¿puede almacén no alcanzar SMB de finanzas?

Un viernes, una actualización interna de red movió los servidores WMS a una nueva subred. La ventana de cambio terminó, todos se fueron a casa,
y el ingeniero on-call esperaba paz. Las pruebas trimestrales, ejecutadas como parte de la validación post-cambio, fallaron inmediatamente:
los clientes VPN de almacén ya no podían alcanzar WMS. Contabilidad y TI estaban bien.

La causa fue simple: las reglas de firewall estaban escritas con subredes de destino explícitas antiguas, y la nueva subred no se añadió.
Como la validación era automatizada y por grupo, la falla se detectó antes de que el turno nocturno empezara a escanear pallets.
La solución fue una pequeña actualización de política y volver a ejecutar las pruebas.

No ocurrió nada heroico. No hubo war room. No hubo ejecutivos. Solo una práctica aburrida haciendo su trabajo aburrido: prevenir drama.

Listas de verificación / plan paso a paso

Plan paso a paso para implementar derechos por grupos sobre una sola VPN

1. Define roles como políticas de acceso, no como unidades organizativas.
   Crea 3–6 grupos de acceso VPN que mapeen a servicios alcanzables.
   Evita que “VPN-Employees” se convierta en “VPN-Todos-Y-Sus-Contratistas”.
2. Crea pools IP VPN distintos por grupo.
   Esto será tu clave de firewall y tu handle de auditoría.
3. Elige el límite de aplicación.
   Lo mejor: aplicar en el firewall entre VPN y segmentos internos. Suficiente: aplicar en el gateway VPN con nftables/iptables. Peor: “lo haremos en las apps.”
4. Push de rutas y DNS mínimos por grupo.
   Si contabilidad nunca necesita WMS, no se lo anuncies. Menos rutas = menos sorpresas.
5. Implementa forwarding con deny por defecto.
   Luego permite flujos explícitos (pool fuente → subnet/hosts destino → puertos).
6. Registra denegados (con límites sensatos) y registra allows administrativos.
   Quieres evidencia suficiente para depurar y auditar, no suficiente para fundir discos.
7. Aplica en almacenamiento, no solo en la red.
   Datasets/shares separados; aplica ACLs de AD; prueba con tokens de usuario reales.
8. Añade un jump host para acceso administrativo TI.
   Mantén las interfaces de gestión fuera del alcance directo desde Wi‑Fi de hoteles aleatorios.
9. Define duración de sesión y comportamiento de re-autenticación.
   Si cambia la pertenencia a grupos, las sesiones deben refrescarse en una ventana de tiempo predecible.
10. Escribe pruebas de validación por grupo y ejecútalas tras cambios.
    Las pruebas de conectividad son baratas. Las caídas no lo son.
11. Documenta el “por qué” junto al “qué”.
    Los comentarios de reglas deben decir qué capacidad de negocio habilitan. Si no, las reglas se multiplicarán como conejos.
12. Realiza una revisión trimestral de accesos que incluya verificación técnica.
    “Revisar la lista de grupos” no es verificación. Verificación son paquetes, logs y comprobaciones de ACL.

Lista operativa para ventanas de cambio

• Antes del cambio: snapshot/exporta configs VPN y firewall; confirma que la ruta de rollback funciona.
• Durante el cambio: actualiza rutas, objetos de firewall y DNS juntos para las apps afectadas.
• Después del cambio: ejecuta pruebas de alcance por grupo; confirma que los denies siguen denegando.
• Después del cambio: revisa logs por drops/permits inesperados desde pools VPN.

Checklist de seguridad que no sabotea operaciones

• MFA para VPN basada en usuario (especialmente contabilidad y TI).
• No cuentas compartidas de administrador TI; cuentas nominales separadas para acceso privilegiado.
• Acceso de emergencia documentado y probado (sí, probado).
• Rota keys/certs; expira perfiles viejos; revoca rápidamente en offboarding.
• Restringe movimiento lateral: los clientes VPN no deberían hablar entre sí salvo necesidad explícita.

Preguntas frecuentes

1) ¿Puedo hacer esto con un solo servidor VPN, o necesito servidores separados por departamento?

Un solo servidor está bien si puede asignar IPs/rutas distintas según identidad y haces cumplir política en un firewall.
Servidores separados a veces se usan por comodidad política; técnicamente, a menudo son complejidad innecesaria.

2) ¿Es mejor aplicar política en el gateway VPN o en un firewall interno?

Prefiere la frontera del firewall interno porque centraliza aplicación y logging para todos los caminos de ingreso, no solo VPN.
Aplicar en el gateway es aceptable para setups pequeños, pero tiende a convertirse en una jungla de reglas.

3) ¿Necesito subredes separadas (pools VPN) por grupo?

No lo necesitas, pero te arrepentirás de no hacerlo.
Pools separados hacen las políticas legibles, la depuración más rápida y las auditorías sobrevivibles.

4) ¿Y los contratistas que necesitan acceso a contabilidad por un mes?

Ponlos en un grupo de acceso con tiempo limitado y un flujo de expiración explícito.
No los añadas al grupo principal de contabilidad “temporalmente”. Temporal es cómo se construye riesgo permanente.

5) ¿Los escáneres de almacén deben usar el mismo método VPN que los portátiles?

No necesariamente. Los escáneres suelen funcionar mejor con identidad basada en dispositivo y rutas bloqueadas.
Si los escáneres son compartidos, las políticas basadas en usuario no mapearán bien sin gestión adicional de dispositivos.

6) ¿El split tunneling es aceptable en este modelo?

A veces. Si los endpoints están gestionados y minimizas backhaul, el split tunnel puede ser sensato.
Para acceso administrativo TI y operaciones financieras, full tunnel suele ser más seguro porque controlas DNS e inspección de salida.

7) ¿Por qué no puedo confiar solo en los inicios de sesión de aplicaciones (ERP/WMS) y saltarme las restricciones de red?

Porque la red es donde viven el escaneo, la explotación y el movimiento lateral.
Las apps protegen la app; la política de red reduce la superficie de ataque alcanzable y limita “ups, me conecté a lo equivocado”.

8) ¿Cómo le demuestro a los auditores que almacén no puede acceder a datos de finanzas?

Proporciona evidencia en capas: política de firewall que muestre denegados (y logs de intentos desde cuentas de prueba),
más evidencia de ACLs de almacenamiento que muestre que las comparticiones financieras niegan a grupos de almacén. Puntos extra por scripts de prueba reproducibles.

9) ¿Cuál es la forma más limpia de manejar las necesidades amplias de TI sin darles “toda la red”?

Usa jump hosts y flujos de acceso privilegiado. TI puede alcanzar el jump host; el jump host alcanza redes de gestión.
Lo registras. Lo controlas. Puedes revocarlo sin reescribir cada regla de firewall.

10) ¿Cómo evitamos la deriva de políticas con el tiempo?

Trata la VPN y la política de firewall como código: revisiones, cambios por etapas y pruebas automatizadas por grupo.
La deriva ocurre cuando tratas la política de red como una pizarra.

Conclusión: siguientes pasos que puedes ejecutar

Los derechos por grupos sobre una sola VPN no son una característica de producto. Son una disciplina de diseño.
El enfoque ganador es aburrido: identidad → mapeo de grupos → pools IP distintos → política explícita de firewall → aplicación de ACLs de almacenamiento → logs utilizables.
Cualquier otra cosa es teatro.

Siguientes pasos que mueven la aguja esta semana:

1. Crea (o limpia) tres grupos de acceso: VPN-Accounting, VPN-Warehouse, VPN-IT. Haz las reglas de pertenencia explícitas.
2. Asigna tres pools de direcciones VPN y asegura que los clientes aterricen en el correcto cada vez.
3. Implementa forwarding con deny por defecto y escribe reglas allow por pool solo a subredes/puertos requeridos.
4. Mueve datos financieros a su propio share/dataset y aplica ACLs con grupos de directorio.
5. Construye una pequeña suite de validación: una cuenta de prueba por grupo, cinco pruebas de conectividad y una prueba negativa (almacén → SMB finanzas debe fallar).
6. Operativiza: registra denegados, revisa cambios y documenta el runbook “derechos cambiados → re-autenticación de sesión”.

Haz eso, y “una VPN” dejará de ser una concesión de seguridad y se convertirá en lo que siempre debió ser: un punto de entrada manejable con acceso controlado.