Une app via WireGuard : lier n'est pas router

Le réglage ressemble à un interrupteur par application, alors on lie le client à l'interface WireGuard en s'attendant à ce que seul ce client utilise le tunnel. Ce que fait réellement la liaison, c'est choisir une adresse source. Le noyau cherche ensuite une route vers la destination, trouve la route par défaut ordinaire et envoie le paquet par le lien physique avec l'adresse du tunnel accrochée. Seule une route sélectionnée pour cette adresse source accomplit l'intention.

Le mécanisme a deux moitiés : une table de routage que seul le trafic du tunnel devrait utiliser, et une règle qui y envoie la source correspondante.

Lier fixe une adresse source, rien de plus

Linux choisit une interface de sortie en cherchant la destination dans une table de routage, après que les règles de politique ont eu la possibilité de rediriger cette recherche. Les règles peuvent sélectionner sur l'adresse source, une marque de pare-feu, l'interface entrante, un UID ou même un port ; chacune est une autre façon de dire ce trafic plutôt que tout. La configuration du client VPN choisit la table qui contient les routes du tunnel ; la règle choisit quel trafic est autorisé à la consulter. La liaison seule ne fournit ni l'une ni l'autre.

C'est pourquoi l'échec paraît si étrange. L'application utilise bien l'adresse du tunnel, le tunnel est bien monté, et le trafic sort bien par la mauvaise interface. Chaque affirmation est vraie, et ensemble elles décrivent un système où rien ne reliait l'adresse à la route.

Donnez au tunnel sa propre table

wg-quick installe les routes là où le profil le lui dit. Ajouter Table = 40 sous [Interface] les déplace dans la table 40 au lieu de la table principale. Montez l'interface et vérifiez qu'elles sont arrivées : ip -4 route ls table 40 devrait afficher les routes du tunnel, et ip -4 route get 10.66.127.142 montre comment le noyau résout actuellement l'une d'elles. Avec les routes dans leur propre table, la table principale continue de fonctionner pour tout le reste.

Faites de même pour IPv6 au lieu de faire correspondre un préfixe large. ip -6 rule add from fd00::2/128 lookup 40 fige une adresse ; fc00::/8 peut entrer en collision avec d'autres interfaces de l'hôte et produire une règle qui correspond à plus que prévu.

Ajoutez la règle de source et surveillez les compteurs

Reliez ensuite les deux moitiés : ip -4 rule add from 10.66.127.142/32 lookup 40, avec cette même adresse attachée à l'interface WireGuard. Placez les deux règles dans PostUp pour qu'une reconnexion les rétablisse. Vérifiez avec une vraie requête plutôt qu'un réglage : ip route get 1.1.1.1 from 10.66.127.142 devrait nommer l'interface du tunnel, et curl --interface wg0 ifconfig.me devrait annoncer l'adresse du tunnel plutôt que celle de la maison.

Quand cela échoue encore, lisez ip -s rule. Une règle qui existe mais n'a jamais correspondu affiche des compteurs à zéro, ce qui distingue une règle erronée d'une absence de règle. Cette seule commande épargne beaucoup de suppositions sur le point de savoir si l'application a ignoré son réglage d'interface.

Le cas inverse : garder SSH hors du tunnel

Le problème opposé est tout aussi courant : wg-quick possède la route par défaut et la session SSH vers le serveur meurt en cours de session. Ses règles se trouvent à un numéro de priorité bas, donc une exception doit être évaluée avant elles. ip rule add dport 22 ipproto tcp table main priority 123 le fait sur un iproute2 récent ; là où le sélecteur n'est pas disponible, marquez le flux dans nftables et faites correspondre la marque à la place.

Vérifiez aussi le chemin de retour. Une session SSH qui s'établit puis se tait a généralement un routage asymétrique, une direction sortant par le tunnel et l'autre par l'interface physique. ip route get pour l'adresse du serveur vous dit par où la réponse partirait.

Notez le numéro de table, la règle de source et l'exception dans le profil lui-même. Les trois relèvent d'une seule conception et seront modifiés ensemble.