Dirección peer PPP frente a extremo VPN: cuál va en via

Una sola línea en una interfaz PPP zanja la mayor parte del debate de enrutamiento en una caja VPN: la dirección interna y el peer impreso a su lado. Lee ese par como una subred diminuta y buscarás una puerta de enlace que no existe. Léelo como los dos extremos de un único enlace y el siguiente salto se vuelve obvio. La comparación aquí es entre esas dos lecturas, porque cada tabla que construyas después hereda la que hayas elegido. Nada del extremo VPN exterior lo decide ninguna de las dos.

Dos lecturas de una misma línea de interfaz

Toma una sesión en la que la interfaz informa inet 10.64.3.9 peer 10.64.3.1/32. La lectura de subred trata 10.64.3.9 como un host solitario en una isla /32 y luego busca un router para alcanzar cualquier cosa más allá. Como la única otra dirección del enlace es el peer, esa lectura termina proponiendo 10.64.3.9 como puerta de enlace, lo cual es circular.

La lectura de extremo es la documentada. En una interfaz punto a punto, peer nombra el extremo remoto de ese único enlace, así que 10.64.3.1 es el siguiente salto utilizable y 10.64.3.9 solo es una dirección de origen.

Esa diferencia gobierna lo que puede aparecer en via. Escribir allí la dirección local produce una ruta que el núcleo no puede resolver contra un vecino, así que la entrada falla la validación o engulle tráfico mientras se ve perfectamente sana en un listado. El peer funciona porque es un destino real en el enlace. Ambas lecturas coinciden sobre el extremo VPN exterior, que es una identidad completamente aparte: se alcanza por el underlay, no por el túnel que termina.

Lo que la sesión ya instaló

Antes de escribir cualquier tabla propia, imprime lo que vino con el enlace. Una integración PPP compatible suele instalar una ruta de dispositivo y una ruta de peer durante el montaje de la sesión, y esas dos entradas ya codifican la lectura correcta.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

Una ruta de dispositivo como 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 no lleva puerta de enlace porque la interfaz misma es el camino. Una ruta que nombra al peer con via es otro objeto con otra vida útil, y desaparece cuando cae la sesión. Copiar cualquiera de las dos formas en una tabla persistente sin comprobar cómo se reinstala es la razón habitual por la que un túnel que funcionaba pierde su ruta tras una reconexión.

Compara los dos listados en lugar de fiarte de la memoria. Si la ruta del peer existe en main pero tu tabla adicional está vacía, has aprendido algo que la línea de dirección nunca te dijo.

Una regla y una tabla son decisiones separadas

Seleccionar una tabla y llenarla son pasos independientes, y la comparación importa aquí porque ambos se confunden a menudo al depurar. Una regla que envía tráfico marcado a la tabla 100 no hace nada si la tabla 100 no tiene una ruta coincidente, y una tabla bien poblada es inalcanzable si ninguna regla apunta a ella.

Media ruta por defecto no es una ruta por defecto. Una sola 0.0.0.0/1 cubre la mitad inferior del espacio IPv4, así que una política que pretende capturarlo todo necesita también la 128.0.0.0/1 correspondiente, o una default auténtica. Leer una configuración que funciona y copiar una de las dos mitades es como la gente acaba con un bucle de enrutamiento que solo se rompe en ciertos destinos.

Deja excepciones deliberadas para las direcciones que deben quedarse en la LAN, y decide qué ocurre cuando la búsqueda no encuentra nada en la tabla seleccionada. Una ruta de reserva explícita es más fácil de razonar que una tabla vacía, que devuelve un resultado inalcanzable y hace que la aplicación parezca rota en lugar de mal enrutada.

Hazle a la búsqueda la pregunta que hace tu aplicación

ip route get resuelve una ruta; ip route show lista las entradas almacenadas, y ambas pueden discrepar sin que ninguna esté mal. Incluye el contexto de origen, porque las reglas basadas en origen solo coinciden cuando la búsqueda lleva un origen.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

El primer comando plantea la pregunta desde el host. El segundo añade una interfaz de entrada, que se acerca más a lo que experimenta el tráfico reenviado, y la respuesta suele apuntar a otra tabla. Ninguno de los destinos es un servicio de prueba en vivo; 198.51.100.23 es una dirección de documentación, así que sustitúyela por un host que tengas permitido sondear.

Incluso una búsqueda correcta solo demuestra que se eligió una ruta. No dice nada sobre si el otro extremo acepta el tráfico ni sobre si la respuesta puede volver mediante el mismo razonamiento.

Dónde se invierte la comparación

El tráfico del host y el tráfico reenviado no solo toman búsquedas distintas; se encuentran con filtros distintos a la vuelta. Linux aplica la validación de ruta inversa usando el más estricto de los ajustes de todas las interfaces y de la interfaz receptora, así que cambiar el valor de una interfaz puede no tener efecto visible. El enrutamiento basado en marcas añade la relación src_valid_mark, en la que la marca debe coincidir para que un origen se considere válido.

Si las respuestas desaparecen mientras el enrutamiento saliente parece correcto, lee los valores efectivos antes de tocarlos, y cámbialos solo con una razón de política declarada.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

Elige entre los dos diseños con evidencia: si la aplicación se vincula a la dirección PPP, basta una regla de origen más una tabla que contenga la ruta del peer. Si la caja reenvía para una LAN detrás, también necesitas que el contexto de entrada y el camino de vuelta coincidan. Cuando no coinciden, corrige la propiedad de la ruta en lugar de aflojar la validación para toda la máquina.