Encamine solo el puerto 25 al túnel, no el host

Cuatro cosas deben alinearse antes de que un host Linux envíe solo su propio SMTP por un túnel: una ruta en una tabla dedicada, una regla de política que seleccione el tráfico, una dirección de origen que el peer acepte y una ruta de retorno que sobreviva a la asimetría. Cada una es una configuración distinta con su propio modo de fallo. El orden de abajo es el que hace que un fallo señale la pieza que realmente está mal. Es un trabajo de enrutamiento específico de puerto, no una solicitud de una ruta predeterminada de VPN.

Una regla de puerto no es una ruta predeterminada

Una regla que hace coincidir TCP generado localmente con el puerto de destino 25 envía ese tráfico a una tabla que usted nombra. La regla no crea nada por sí sola: selecciona, y la tabla debe contener una ruta capaz de transportar el paquete. Combinar ambas cubre solo la dirección saliente de un protocolo, así que el reenvío para otros hosts, las conexiones de correo entrantes e IPv6 quedan fuera del arreglo. Llamarlo política específica de puerto en lugar de VPN predeterminada mantiene honesta esa frontera.

Dos ajustes de wg-quick son requisitos previos, no parte de la política. AllowedIPs = 0.0.0.0/0 permite que el peer transporte destinos IPv4 arbitrarios, y Table = off impide que wg-quick instale su propia ruta predeterminada para ese prefijo. No mezcle estas instrucciones con un gestor que aplique su propia política de rutas, porque ambos discreparán sobre quién posee la tabla principal.

Escriba la ruta, el selector y la guarda

Elija un número de tabla y un par de prioridades que nada más use, y luego aplique la ruta, el selector y la guarda en ese orden. Los números de abajo son ejemplos, no valores reservados:

ip -4 route add default dev wg0 src 10.77.0.2 table 51825
ip -4 rule add priority 10000 iif lo ipproto tcp dport 25 lookup 51825
ip -4 rule add priority 10001 iif lo ipproto tcp dport 25 unreachable

iif lo restringe la regla al tráfico originado localmente, y ipproto tcp dport 25 identifica la dirección de la conexión; la referencia de ip-rule documenta ambos selectores. Existen en los núcleos y versiones de iproute2 actuales, y en un sistema más antiguo la regla se rechaza de plano, lo que es un fallo más claro que una regla que se carga y no coincide con nada.

La regla unreachable en la prioridad siguiente es la guarda. Sin ella, una ruta ausente en la tabla 51825 cae en la ruta predeterminada ordinaria, y el correo sale por el enlace físico durante una caída del túnel, que es exactamente el caso que la política quería evitar.

La dirección de origen debe coincidir

La preferencia src de la ruta solo rellena un origen para las conexiones que no han vinculado uno propio. No es traducción y no anula una vinculación explícita, así que un demonio vinculado a la dirección física sigue enviando desde esa dirección. Si eso es lo que encuentra, cambie el ajuste del propio demonio o diseñe una política de traducción deliberada, porque un masquerade global tardío es otra solución con otras consecuencias.

En la pasarela, el peer del cliente debe autorizar el origen que realmente recibe, que es 10.77.0.2/32 en lugar de un prefijo de destino amplio. Copiar el 0.0.0.0/0 del cliente en cada peer de la pasarela confunde qué peer posee qué tráfico. La pasarela también necesita reenvío, una política de cortafuegos que permita el flujo y una ruta de retorno, incluida la traducción de salida cuando el extremo superior no puede enrutar una dirección privada del túnel.

Compruebe la ruta de retorno y luego la persistencia

Lea las consultas antes de confiar en nada, porque muestran qué tabla y qué origen recibe cada dirección. Un destino en el puerto 25 y el mismo destino en el puerto 443 bastan:

ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443

La primera consulta debería nombrar wg0 y el origen previsto, y la segunda debería conservar el enlace ascendente ordinario. Cuando la aplicación vincule su propia dirección, añada from con esa dirección a la consulta. Una dirección de respuesta que llega a wg0 y luego se descarta localmente apunta al filtrado de ruta inversa IPv4, porque una regla solo de salida por puerto no hace que la consulta inversa elija el túnel.

Donde se autoriza el enrutamiento asimétrico, el modo laxo limitado a la interfaz mediante net.ipv4.conf.wg0.rp_filter=2 puede ser adecuado, y conviene comprobar primero el máximo efectivo de los valores all y de la interfaz. No desactive la validación globalmente como atajo. Después entregue la tabla, las prioridades y la guarda a quien posea la configuración, y abra conexiones nuevas tras una reconexión para confirmar que la selección sigue vigente. Tenga en cuenta que las respuestas de un escucha SMTP local llevan el puerto de origen 25 en lugar del puerto de destino 25, lo que es una cuestión de política aparte.