Copiar el /32 del túnel no encamina la subred de la oficina
La dirección que la VPN entrega a su adaptador describe el enlace, no el destino. Añada el prefijo del recurso al perfil y deje la ruta predeterminada en paz.
La VPN se conecta, la interfaz muestra una dirección con una máscara de treinta y dos bits y el servidor de la oficina sigue inalcanzable. El siguiente movimiento suele ser reutilizar esa máscara en una ruta, con la teoría de que la interfaz describe lo que el túnel puede alcanzar. No lo hace. Esa dirección describe el extremo local de un enlace punto a punto, y el destino que le importa vive en un prefijo distinto al otro lado.
Se están confundiendo dos cosas distintas: la dirección que le dio el túnel y la red a la que quiere llegar a través de él.
Dos direcciones, dos trabajos
En un túnel punto a punto, la dirección del cliente suele ser una única dirección de host porque hay exactamente un par en el otro extremo del enlace. No hay segmento compartido ni ARP, así que una máscara que parecería absurda en Ethernet aquí es completamente normal.
El prefijo de destino es un hecho sobre la red de la oficina, no sobre el túnel. Si necesita un servidor, la ruta es una ruta de host para ese servidor. Si necesita toda la subred de la oficina, la ruta es la subred. Ninguna de las dos respuestas se puede leer de la interfaz, y elegir una porque apareció junto a la dirección del túnel es cómo se rompe una configuración que funcionaba.
| What you need to reach | What to install |
|---|---|
| One server, nothing else | A host route for that address |
| The office subnet | A route for the subnet prefix |
| Everything in the private space | Only if the requirement says so, and only with the owner's approval |
Esa tercera fila es donde el optimismo se convierte en una caída. Encaminar todo un rango privado hacia un túnel que solo sirve a un sitio empuja tráfico no relacionado hacia un camino que no puede entregarlo, y los fallos resultantes parecen una VPN rota más que una ruta demasiado amplia.
Elija el prefijo a partir del requisito
Escriba el requisito como una frase antes de tocar un perfil: qué hosts deben ser alcanzables y cuál es el prefijo más estrecho que los cubre. Un solo servidor es una ruta de host. Una subred es una ruta de subred. Un rango de subredes es un resumen, y un resumen es una promesa de que toda dirección dentro de él es alcanzable, lo que rara vez es cierto.
Luego compruebe el número contra lo que la oficina usa en realidad. Copiar un prefijo de un mensaje de chat sin confirmarlo con el plan de direccionamiento del sitio es cómo una ruta termina apuntando a una subred que nadie posee.
Recuerde también que una ruta es un camino, no un permiso. La puerta de enlace sigue decidiendo si su cliente puede usar el destino, y un servicio todavía puede rechazarle. Instalar la ruta correctamente hace llegar el paquete y no responde nada sobre la autorización.
Añada al perfil, nunca lo reemplace
Las rutas en un perfil de NetworkManager son una propiedad de varios valores, y la diferencia entre establecer y añadir es un carácter. Use la forma con más para añadir una entrada y conservar todo lo que ya está guardado.
nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
+ipv4.routes "10.40.20.9/32"Sin el más, la asignación reemplaza toda la lista. En un perfil que ya lleva varios prefijos, eso borra en silencio los que funcionaban, y el síntoma llega más tarde como un servicio que antes era alcanzable desde este portátil.
Use el UUID en lugar del nombre. Los nombres se duplican tras las restauraciones, y la conexión que edita puede no ser la que lleva su tráfico. Compruebe primero si ya existe una entrada idéntica, porque añadir un duplicado es desordenado incluso cuando es inofensivo.
La referencia de propiedades de ruta documenta el destino, el siguiente salto opcional, la métrica y la sintaxis de atributos para la versión instalada. Léala antes de añadir un siguiente salto, porque si hace falta depende de la integración y de la topología, y adivinarlo a partir de la primera dirección de un listado de interfaces no es un método.
La ruta predeterminada y el DNS son decisiones separadas
Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.
Las rutas automáticas son la otra cosa que no conviene perturbar a la ligera. Suprimirlas para resolver una entrada que falta puede eliminar varias que funcionan, y quien lo sugirió normalmente miraba otro perfil con otros push.
El DNS tiene su propio camino y sus propios fallos. Un nombre que se resuelve a la dirección correcta a través del resolutor equivocado, o un resolutor que no puede responder por la zona privada, parecerá un problema de encaminamiento mientras la ruta es perfecta. Pruebe la dirección y el nombre por separado y luego decida qué capa falló en realidad.
Verifique qué se aplicó
Una modificación guardada no es una modificación aplicada. Vuelva a conectarse mediante el ciclo de vida admitido del gestor y después mire la ruta real para el destino previsto y las reglas de política que deciden qué tabla se consulta.
Si el prefijo está ahí y la conexión sigue fallando, se ha movido a otro problema: selección de dirección de origen, una ruta de retorno en el extremo lejano o un servicio que rechaza a su cliente. Cada uno de esos es un lugar mejor donde mirar que el perfil que ya corrigió.