N’envoyez que le port 25 dans le tunnel, pas l’hôte

Quatre éléments doivent s’aligner avant qu’un hôte Linux n’envoie uniquement son propre SMTP par un tunnel : une route dans une table dédiée, une règle de politique qui sélectionne le trafic, une adresse source que le peer acceptera, et un chemin de retour qui survit à l’asymétrie. Chacun est une configuration distincte avec son propre mode de défaillance. L’ordre ci-dessous est celui qui fait pointer une défaillance vers la pièce réellement fautive. C’est un travail de routage propre à un port, pas une demande de route par défaut VPN.

Une règle de port n’est pas une route par défaut

Une règle qui associe le TCP généré localement au port de destination 25 envoie ce trafic vers une table que vous nommez. La règle ne crée rien à elle seule : elle sélectionne, et la table doit contenir une route capable de porter le paquet. La combinaison des deux ne couvre que la direction sortante d’un protocole, donc le transfert pour d’autres hôtes, les connexions de messagerie entrantes et IPv6 restent hors du dispositif. L’appeler politique propre à un port plutôt que défaut VPN garde cette frontière honnête.

Deux réglages de wg-quick sont des prérequis, pas une partie de la politique. AllowedIPs = 0.0.0.0/0 permet au peer de porter des destinations IPv4 arbitraires, et Table = off empêche wg-quick d’installer sa propre route par défaut pour ce préfixe. Ne mélangez pas ces instructions avec un gestionnaire qui applique sa propre politique de routes, car les deux seront en désaccord sur qui possède la table principale.

Écrivez la route, le sélecteur et la garde

Choisissez un numéro de table et une paire de priorités que rien d’autre n’utilise, puis appliquez la route, le sélecteur et la garde dans cet ordre. Les numéros ci-dessous sont des exemples, pas des valeurs réservées :

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 limite la règle au trafic d’origine locale, et ipproto tcp dport 25 identifie la direction de la connexion ; la référence ip-rule documente les deux sélecteurs. Ils existent sur les noyaux et les versions d’iproute2 actuels, et sur un système plus ancien la règle est rejetée d’emblée, ce qui est un échec plus clair qu’une règle qui se charge et ne correspond à rien.

La règle unreachable à la priorité suivante est la garde. Sans elle, une route absente dans la table 51825 retombe sur la route par défaut ordinaire, et le courrier sort par le lien physique pendant une panne du tunnel, ce qui est exactement le cas que la politique visait à empêcher.

L’adresse source doit s’accorder

La préférence src de la route ne remplit une source que pour les connexions qui n’en ont pas lié une. Ce n’est pas de la traduction, et elle ne contourne pas une liaison explicite, donc un démon lié à l’adresse physique continue d’émettre depuis cette adresse. Si c’est ce que vous constatez, changez le réglage du démon lui-même ou concevez une politique de traduction délibérée, car un masquerade global tardif est une autre solution aux autres conséquences.

À la passerelle, le peer du client doit autoriser la source qu’il reçoit réellement, soit 10.77.0.2/32 plutôt qu’un préfixe de destination large. Copier le 0.0.0.0/0 du client dans chaque peer de la passerelle brouille qui possède quel trafic. La passerelle a aussi besoin du transfert, d’une politique de pare-feu qui autorise le flux et d’un chemin de retour, y compris la traduction de sortie lorsque l’amont ne peut pas router une adresse privée de tunnel.

Vérifiez le chemin de retour, puis la persistance

Lisez les recherches avant de faire confiance à quoi que ce soit, car elles montrent quelle table et quelle source chaque direction reçoit. Une destination sur le port 25 et la même destination sur le port 443 suffisent :

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 première recherche devrait nommer wg0 et la source voulue, et la seconde devrait conserver le lien montant ordinaire. Lorsque l’application lie sa propre adresse, ajoutez from avec cette adresse à la recherche. Une direction de réponse qui atteint wg0 puis est abandonnée localement indique un filtrage du chemin inverse IPv4, car une règle de sortie propre à un port ne fait pas choisir le tunnel par la recherche inverse.

Là où le routage asymétrique est autorisé, un mode lâche limité à l’interface via net.ipv4.conf.wg0.rp_filter=2 peut convenir, et il vaut la peine de vérifier d’abord le maximum effectif des valeurs all et d’interface. Ne désactivez pas la validation globalement comme raccourci. Remettez ensuite la table, les priorités et la garde à ce qui possède la configuration, et ouvrez de nouvelles connexions après une reconnexion pour confirmer que la sélection tient toujours. Gardez à l’esprit que les réponses d’un écouteur SMTP local portent le port source 25 et non le port de destination 25, ce qui est une question de politique distincte.