Tu VPN corporativa está mal configurada de fábrica (y funciona igual)

El escenario: había que sacar a una empresa manufacturera de un servicio de red privada que se les había vuelto inaccesible, y llevarla a otro. Del lado del servidor todo quedó bien a la primera. El túnel levantó, el panel decía Healthy, la ruta hacia la red interna estaba publicada y visible.

Y el escritorio remoto no conectaba.

Unable to connect
We couldn't connect to the remote PC because the PC can't be found.
Please ensure that Local Network access is enabled in the
system Privacy and Security settings.

Error code: 0x104

Ese mensaje es una trampa. Dice «revisa los permisos de tu equipo», y uno se va media hora a pelear con la configuración de privacidad del sistema operativo. El problema estaba en otro lado, y el mensaje era, en realidad, la pista.

Medir en vez de adivinar#

En lugar de seguir la sugerencia del error, preguntamos al sistema por dónde piensa salir el tráfico hacia esa dirección:

$ route -n get 192.168.1.NNN
  interface: en0

en0 es la tarjeta de red local. El equipo estaba buscando el servidor en la red de la casa, no en el túnel. El túnel existía, estaba sano, y nadie lo usaba.

Después preguntamos al cliente de VPN qué reglas tenía cargadas:

Exclude mode, with hosts/ips:
  10.0.0.0/8
  172.16.0.0/12
  192.168.0.0/16      ← aquí está
  169.254.0.0/16
  ...

Ahí estaba, completa. El cliente viene de fábrica excluyendo todas las redes privadas del mundo. Los tres rangos que define el estándar para redes internas están en una lista de "esto no pasa por el túnel".

Y tiene todo el sentido: sin esa lista, la VPN secuestraría la impresora de tu casa, el módem, el disco de red, el timbre inteligente. La configuración de fábrica es correcta para el caso general. Es exactamente lo contrario de lo que necesitas cuando el objetivo del túnel es, precisamente, alcanzar una red interna.

Nadie te lo advierte. El panel dice Healthy porque el túnel sí está sano. Lo que no está es la voluntad del cliente de usarlo.

La decisión que no era obvia#

Con el diagnóstico claro había dos caminos, y el fácil era el peor.

Camino cómodo: quitar la exclusión y dejar el modo por omisión. Funciona en cinco minutos. Y a cambio, toda la navegación de las ocho personas remotas empieza a viajar por el túnel de la empresa. Su banca, su correo personal, sus videollamadas, todo. Más lento, más frágil —cualquier problema del túnel es ahora un problema de "no tengo internet"— y, lo más serio: convierte a la empresa en responsable del tráfico personal de su gente. Nadie firmó eso.

Camino correcto: invertir la lógica. Cambiar de "excluye estas redes" a "incluye solamente esto", y dejar una sola línea:

Selector      Value
IP Address    192.168.1.NNN/32     ← el servidor, y nada más

Con esto la herramienta deja de ser una VPN en el sentido tradicional. Es un cable a una sola dirección. Todo lo demás —internet, correo, la impresora de su casa— sigue por donde siempre. Solo el servidor viaja protegido.

Es menos VPN. Y es mejor.

Dos trampas que costaron tiempo#

Escribir el rango no lo guarda. El campo acepta el valor, se ve escrito en pantalla, y la lista de abajo sigue vacía. Falta dar Add. Y en modo incluir, una lista vacía significa que nada viaja por el túnel — el síntoma es idéntico al problema original, así que uno cree que el cambio no sirvió.

El cliente muestra información vieja. Después de guardar, la aplicación seguía diciendo Not Connected mientras la conexión ya funcionaba. La interfaz no es la fuente de verdad. La línea de comandos sí.

El riesgo que todos mencionan y casi nadie mide#

Aquí viene la parte que hace interesante el caso.

El equipo desde el que probamos estaba en 192.168.1.80. El servidor, en 192.168.1.NNN. Misma red, mismo rango.

Esa es la objeción clásica: «si tu casa usa el mismo rango que la oficina, olvídate, hay que renumerar la red». Y renumerar la red de una planta en producción no es una tarea, es una cirugía.

No hizo falta. Una ruta de un solo host —máscara /32— es más específica que la ruta de la red local, y el sistema operativo prefiere siempre la más específica. Ganó el túnel:

$ route -n get 192.168.1.NNN
  interface: utun10          ← el túnel, ya no en0

$ nc -z 192.168.1.NNN 8088
  succeeded!

Y esto importa más allá del caso: 192.168.1.x es el rango que trae por omisión casi todo módem doméstico en México. Si el traslape impidiera la conexión, la mitad de los trabajadores remotos del país quedarían fuera. No es así, y conviene saberlo antes de proponer renumerar nada.

Lo que hicimos#

1. Medimos antes de tocar. route get para saber por dónde sale, y la configuración real del cliente en lugar de la del panel. El error del sistema apuntaba al lugar equivocado; la tabla de rutas no opina.

2. Elegimos el modo restrictivo aunque costara más explicarlo. Una dirección incluida, en vez de tres rangos excluidos.

3. Verificamos por capas, no de un jalón. Primero la ruta sale por el túnel. Luego el puerto responde. Y solo entonces se prueba el escritorio remoto. Cuando falla un intento de conexión completo no sabes cuál de las tres cosas falló.

4. Dejamos la vía anterior viva durante la prueba. El acceso viejo no se tocó hasta que el nuevo estuvo probado con una persona real entrando a trabajar.

Lo que queda como regla#

Que el panel diga "sano" no significa que alguien lo esté usando. El túnel estaba perfecto y el tráfico salía por otro lado. Verificar el servicio y verificar la ruta son dos cosas distintas.

La configuración por omisión está pensada para el caso general, que casi nunca es el tuyo. Vale la pena leer qué trae de fábrica antes de suponer que el producto está roto.

Y cuando puedas elegir entre encaminar todo o encaminar una sola cosa, elige una sola cosa. Menos superficie, menos dependencia, y ninguna conversación incómoda sobre el tráfico personal de tu equipo.

Caso real de una empresa manufacturera. Las direcciones internas se omitieron parcialmente; los rangos mostrados son los que define el estándar y no identifican a nadie.