¿La impresora se desconecta al conectar la VPN? Revise la tabla de rutas

Su portátil se une a la VPN corporativa y la impresora que está a dos metros deja de responder. En la impresora no ha cambiado nada y la red local no se ha caído. Lo que ha cambiado es la tabla de rutas: el adaptador del túnel ahora tiene una ruta que cubre la dirección de la impresora, así que esos paquetes salen por la VPN y llegan a una puerta de enlace que no tiene ni idea de dónde está su red plana. Recorra las cuatro comprobaciones siguientes en orden y deténgase en la primera que falle.

Paso uno: demuestre que la impresora sigue siendo accesible en la LAN

Antes de tocar el enrutamiento, confirme que el dispositivo está vivo para algo que no use la VPN. Pida a un teléfono en la misma Wi-Fi que abra la página web de la impresora, o haga ping a la dirección desde otra máquina de la red plana. Si la impresora tampoco responde allí, la VPN es una coincidencia y el fallo está en la impresora, en su asociación Wi-Fi o en el aislamiento de clientes del punto de acceso.

Si responde en todas partes menos en este portátil, tiene un problema de enrutamiento o de resolución de nombres que vive en el portátil, y el paso siguiente le dice cuál de los dos es.

Paso dos: encuentre la ruta que Windows elige realmente

No lea la tabla de arriba abajo ni adivine. Pregunte a Windows qué entrada elige para la dirección exacta que le importa, y obtenga el índice de interfaz al mismo tiempo.

Find-NetRoute -RemoteIPAddress 192.168.1.50
route print -4
tracert -d 192.168.1.50

Find-NetRoute imprime la ruta ganadora y su interfaz, y esos son los dos hechos de los que depende el resto. route print -4 muestra las entradas vecinas, incluidas las dos medias rutas por defecto que instalan los clientes de túnel completo: 0.0.0.0/1 y 128.0.0.0/1, que juntas cubren todo el espacio IPv4 sin reemplazar nunca 0.0.0.0/0. Una /1 es más larga que una /0, pero su 192.168.1.0/24 lo es aún más, y por eso una ruta LAN ausente importa más que la propia pretensión del túnel.

Dos reglas deciden la respuesta. El prefijo coincidente más largo gana primero, y entre entradas con el mismo prefijo gana la métrica total más baja, donde el total combina la métrica de la ruta y la métrica de la interfaz. Si la interfaz seleccionada es el túnel, siga adelante. Si es el adaptador físico y el tráfico sigue fallando, deténgase aquí: su problema es la resolución de nombres o la lista de acceso de la propia impresora, no la ruta de la VPN.

Paso tres: añada la ruta más estrecha que nombre puerta de enlace e interfaz

La reparación es una entrada que apunta la dirección de la impresora al router local en el adaptador local. Ejecútela en un símbolo del sistema elevado y sustituya los valores que acaba de leer.

route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 if 12 -p

El valor de if es el índice de interfaz del adaptador físico. Omitirlo es el motivo más habitual de que el comando parezca tener éxito y no cambie nada, porque con dos adaptadores capaces de alcanzar el mismo siguiente salto Windows es libre de elegir el que usted no quería. El indicador -p hace que la entrada sea persistente, de modo que sobrevive a un reinicio en lugar de morir con la sesión.

Prefiera una ruta de host para el dispositivo individual antes que una ruta para toda la 192.168.1.0/24. Una ruta de subred es más amplia de lo que la tarea necesita y choca en el momento en que el lado corporativo también usa ese prefijo: un prefijo pasa a tener dos dueños, y qué entrada gane decide a qué red puede llegar realmente.

En el otro sentido, si ha borrado la opción de puerta de enlace predeterminada en la conexión VPN para proteger la LAN, los prefijos privados remotos también dejan de resolverse. Añada rutas para ellos a través de la interfaz VPN de la misma manera, o el túnel se convierte en un enlace que no transporta nada.

Paso cuatro: haga que la excepción sobreviva a la próxima conexión

Muchos clientes corporativos reinstalan todo su conjunto de rutas en cada conexión y recalculan las métricas de interfaz mientras lo hacen, así que una ruta que ayer funcionaba hoy puede quedar superada. Tras reconectar, repita Find-NetRoute para la impresora y compruebe que la interfaz sigue coincidiendo con el adaptador físico. Si la entrada ha desaparecido, algo la está borrando; una ruta persistente no le protege de un agente que barre la tabla. Las tareas programadas que vuelven a añadir la ruta después de que la VPN se conecte son la solución habitual, y también son la solución que se rompe cuando el índice del adaptador cambia tras una base de acoplamiento o una actualización de controlador.

Vigile IPv6 por separado. Un cliente que solo reclama el valor predeterminado IPv4 puede dejar la ruta predeterminada IPv6 en el adaptador físico, de modo que una impresora accesible por IPv6 sigue funcionando mientras IPv4 falla, o al revés. Pruebe con ping -4 y ping -6 antes de decidir que la tabla de rutas es inocente.

Qué le cuesta el atajo local

Cualquier ruta que evite el túnel es un agujero en la promesa del túnel. El tráfico hacia esa dirección ya no pasa por la puerta de enlace corporativa, lo que significa sin inspección, sin registro y sin aplicación de políticas. En un dispositivo gestionado eso puede ser un problema de cumplimiento y no una preferencia, así que pregunte si existe una excepción oficial de túnel dividido antes de añadir una a mano. Mantenga la suya tan estrecha como la tarea y tan breve como la situación permita.

Si la impresora responde tras el cambio, repita las cuatro comprobaciones después de su próxima reconexión en lugar de suponer que la corrección aguantó. Si no responde, capture la salida de Find-NetRoute antes y después de la conexión; la diferencia le dice si el cliente borró la entrada o solo la reordenó.