Instrada solo la porta 25 nel tunnel, non l’host

Quattro cose devono allinearsi prima che un host Linux invii solo il proprio SMTP attraverso un tunnel: una rotta in una tabella dedicata, una regola di policy che seleziona il traffico, un indirizzo sorgente che il peer accetterà e un percorso di ritorno che sopravvive all’asimmetria. Ognuna è una configurazione separata con il proprio modo di fallire. L’ordine sotto è quello che fa puntare un guasto alla parte davvero sbagliata. È un lavoro di routing specifico per porta, non una richiesta di una rotta predefinita VPN.

Una regola di porta non è una rotta predefinita

Una regola che abbina il TCP generato localmente alla porta di destinazione 25 invia quel traffico a una tabella che tu nomini. La regola non crea nulla da sola: seleziona, e la tabella deve contenere una rotta capace di trasportare il pacchetto. Combinare le due copre solo la direzione uscente di un protocollo, quindi l’inoltro per altri host, le connessioni di posta in entrata e IPv6 restano fuori dall’accordo. Chiamarla policy specifica per porta invece di VPN predefinita mantiene onesto quel confine.

Due impostazioni di wg-quick sono prerequisiti, non parte della policy. AllowedIPs = 0.0.0.0/0 consente al peer di trasportare destinazioni IPv4 arbitrarie, e Table = off impedisce a wg-quick di installare la propria rotta predefinita per quel prefisso. Non mescolare queste istruzioni con un gestore che applica la propria policy di routing, perché i due non saranno d’accordo su chi possiede la tabella principale.

Scrivete la rotta, il selettore e la guardia

Scegli un numero di tabella e una coppia di priorità che nulla altro usa, poi applica la rotta, il selettore e la guardia in quell’ordine. I numeri sotto sono esempi, non valori riservati:

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 la regola al traffico di origine locale, e ipproto tcp dport 25 identifica la direzione della connessione; il riferimento di ip-rule documenta entrambi i selettori. Esistono nei kernel e nelle versioni di iproute2 attuali, e su un sistema più vecchio la regola viene respinta di netto, il che è un guasto più chiaro di una regola che si carica e non corrisponde a nulla.

La regola unreachable alla priorità successiva è la guardia. Senza di essa, una rotta assente nella tabella 51825 ricade sulla rotta predefinita ordinaria, e la posta esce dal collegamento fisico durante un’interruzione del tunnel, che è esattamente il caso che la policy voleva impedire.

L’indirizzo sorgente deve concordare

La preferenza src della rotta riempie una sorgente solo per le connessioni che non ne hanno vincolata una propria. Non è traduzione e non annulla un bind esplicito, quindi un demone vincolato all’indirizzo fisico continua a inviare da quell’indirizzo. Se è questo che trovi, cambia l’impostazione del demone stesso o progetta una policy di traduzione deliberata, perché un masquerade globale tardivo è un’altra soluzione con altre conseguenze.

Al gateway, il peer del client deve autorizzare la sorgente che riceve davvero, cioè 10.77.0.2/32 invece di un prefisso di destinazione ampio. Copiare il 0.0.0.0/0 del client in ogni peer del gateway confonde quale peer possiede quale traffico. Il gateway ha anche bisogno dell’inoltro, di una policy del firewall che consenta il flusso e di un percorso di ritorno, inclusa la traduzione in uscita quando l’upstream non può instradare un indirizzo privato del tunnel.

Verificate il percorso di ritorno, poi la persistenza

Leggi le ricerche prima di fidarti di qualcosa, perché mostrano quale tabella e quale sorgente ottiene ogni direzione. Una destinazione sulla porta 25 e la stessa destinazione sulla porta 443 bastano:

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 prima ricerca dovrebbe nominare wg0 e la sorgente prevista, e la seconda dovrebbe mantenere il normale collegamento ascendente. Quando l’applicazione vincola il proprio indirizzo, aggiungi from con quell’indirizzo alla ricerca. Una direzione di risposta che raggiunge wg0 e poi viene scartata localmente indica il filtraggio del percorso inverso IPv4, perché una regola solo per la porta in uscita non fa scegliere il tunnel alla ricerca inversa.

Dove il routing asimmetrico è autorizzato, la modalità lasca limitata all’interfaccia tramite net.ipv4.conf.wg0.rp_filter=2 può essere adatta, e vale la pena controllare prima il massimo effettivo dei valori all e dell’interfaccia. Non disattivare la convalida a livello globale come scorciatoia. Poi consegna la tabella, le priorità e la guardia a chi possiede la configurazione, e apri nuove connessioni dopo una riconnessione per confermare che la selezione regge ancora. Tieni presente che le risposte di un listener SMTP locale portano la porta sorgente 25 e non la porta di destinazione 25, che è una questione di policy separata.