Encamiñade só o porto 25 ao túnel, non o host

Catro cousas deben aliñarse antes de que un host Linux envíe só o seu propio SMTP por un túnel: unha ruta nunha táboa dedicada, unha regra de política que seleccione o tráfico, un enderezo de orixe que o peer acepte e un camiño de retorno que sobreviva á asimetría. Cada unha é unha configuración distinta co seu propio modo de fallo. A orde de abaixo é a que fai que un fallo sinale a peza que realmente está mal. É un traballo de encamiñamento específico de porto, non unha petición dunha ruta predeterminada de VPN.

Unha regra de porto non é unha ruta predeterminada

Unha regra que fai coincidir TCP xerado localmente co porto de destino 25 envía ese tráfico a unha táboa que vostede nomea. A regra non crea nada por si soa: selecciona, e a táboa debe conter unha ruta capaz de transportar o paquete. Combinar ambas cobre só a dirección de saída dun protocolo, así que o reenvío para outros hosts, as conexións de correo entrantes e IPv6 quedan fóra do arranxo. Chamalo política específica de porto en lugar de VPN predeterminada mantén esa fronteira honesta.

Dous axustes de wg-quick son requisitos previos, non parte da política. AllowedIPs = 0.0.0.0/0 permite que o peer transporte destinos IPv4 arbitrarios, e Table = off impide que wg-quick instale a súa propia ruta predeterminada para ese prefixo. Non mesture estas instrucións cun xestor que aplique a súa propia política de rutas, porque os dous discreparán sobre quen posúe a táboa principal.

Escribide a ruta, o selector e a garda

Escollede un número de táboa e un par de prioridades que nada máis use, e logo aplicade a ruta, o selector e a garda nesa orde. Os números de abaixo son exemplos, non 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 limita a regra ao tráfico orixinado localmente, e ipproto tcp dport 25 identifica a dirección da conexión; a referencia de ip-rule documenta ambos os selectores. Existen nos núcleos e versións de iproute2 actuais, e nun sistema máis antigo a regra rexéitase de plano, o que é un fallo máis claro que unha regra que se carga e non coincide con nada.

A regra unreachable na prioridade seguinte é a garda. Sen ela, unha ruta ausente na táboa 51825 cae na ruta predeterminada ordinaria, e o correo sae pola ligazón física durante unha caída do túnel, que é exactamente o caso que a política quería evitar.

O enderezo de orixe debe coincidir

A preferencia src da ruta só enche unha orixe para as conexións que non teñen vinculado unha propia. Non é tradución e non anula unha vinculación explícita, así que un demo vinculado ao enderezo físico segue enviando desde ese enderezo. Se iso é o que atopa, cambie o axuste do propio demo ou deseñe unha política de tradución deliberada, porque un masquerade global tardío é outra solución con outras consecuencias.

Na pasarela, o peer do cliente debe autorizar a orixe que realmente recibe, que é 10.77.0.2/32 en lugar dun prefixo de destino amplo. Copiar o 0.0.0.0/0 do cliente en cada peer da pasarela confunde que peer posúe que tráfico. A pasarela tamén necesita reenvío, unha política de cortafogos que permita o fluxo e un camiño de retorno, incluída a tradución de saída cando o extremo superior non pode encamiñar un enderezo privado do túnel.

Comprobade o camiño de retorno e despois a persistencia

Lede as consultas antes de confiar en nada, porque mostran que táboa e que orixe recibe cada dirección. Un destino no porto 25 e o mesmo destino no porto 443 abondan:

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

A primeira consulta debería nomear wg0 e a orixe prevista, e a segunda debería conservar a ligazón ascendente ordinaria. Cando a aplicación vincule o seu propio enderezo, engadide from con ese enderezo á consulta. Unha dirección de resposta que chega a wg0 e logo se descarta localmente apunta á filtrado de ruta inversa IPv4, porque unha regra só de saída por porto non fai que a consulta inversa escolla o túnel.

Onde se autoriza o encamiñamento asimétrico, o modo laxo limitado á interface mediante net.ipv4.conf.wg0.rp_filter=2 pode ser axeitado, e paga a pena comprobar primeiro o máximo efectivo dos valores all e da interface. Non desactive a validación globalmente como atallo. Despois entregade a táboa, as prioridades e a garda a quen posúa a configuración, e abride conexións novas tras unha reconexión para confirmar que a selección aínda se mantén. Teñade presente que as respostas dun escoitador SMTP local levan o porto de orixe 25 en lugar do porto de destino 25, que é unha cuestión de política á parte.