Transmission sous Linux : imposer la sortie par propriétaire de processus

Bloquer le port entrant de Transmission n’est pas une politique VPN. Un client BitTorrent ouvre des connexions sortantes vers des pairs et des traqueurs, résout des noms et peut exposer un écouteur de contrôle à distance ; chacun de ces flux peut sortir par une interface que vous n’aviez pas prévue. Déroulez les cinq vérifications dans l’ordre et considérez la règle de pare-feu, et non les réglages du client, comme la frontière. Les deux dernières vérifications sont celles que l’on saute, et ce sont elles qui décident si la garantie tient lorsque le tunnel tombe.

Nommer le processus propriétaire du transfert

L’application de bureau et le démon système tournent sous des comptes différents, et une règle fondée sur le propriétaire suit le compte plutôt que le nom du programme. Déterminez lequel des deux s’exécute avant d’écrire la moindre règle. Un compte de service dédié donne à la politique un sujet précis, alors qu’un utilisateur de bureau partage son identité avec les navigateurs, les éditeurs et tout le reste de la session. Confirmez l’UID au lieu de supposer que le nom de compte fourni par le paquet est celui qui est utilisé.

systemctl status transmission-daemon
ps -o user=,pid=,cmd= -C transmission-daemon

Si le compte n’existe pas encore, créez-le pour cet usage et ne lui confiez rien d’autre. Inscrivez le compte et l’UID dans le commentaire de la règle, car une règle sans sujet est une règle que personne ne peut modifier sans risque.

Séparer les champs d’écoute de la route

Transmission 4.x documente les adresses d’écoute des pairs séparément de rpc-bind-address, et la différence compte. Le réglage RPC ne contrôle que l’écouteur de contrôle à distance : le modifier ne choisit donc pas de route pour le trafic des pairs. Lire ces deux réglages comme un seul est la raison la plus fréquente pour laquelle une configuration d’apparence soignée fuit encore. La même documentation décrit un repli lorsqu’une adresse d’écoute des pairs est invalide ; une adresse indisponible est donc un cas de repli documenté, pas un refus garanti.

grep -E '"(peer-port|rpc-bind-address|bind-address-ipv4)"' /var/lib/transmission-daemon/.config/transmission-daemon/settings.json

Utilisez les contrôles du client pour ce qu’ils sont, et placez la garantie dans le pare-feu. Un réglage d’écoute peut encore valoir la peine, mais il n’établit pas que le contact avec les traqueurs, la découverte locale ou une résolution déléguée sortent tous par le tunnel. Quand les deux se contredisent, c’est le pare-feu qui tranche.

Écrire la correspondance de propriétaire dans la bonne chaîne

Le manuel Netfilter de la correspondance de propriétaire explique comment les paquets générés localement sont attribués à l’utilisateur ou au groupe propriétaire du fichier de socket. Cette attribution ne s’étend pas au trafic transféré, et la correspondance des groupes supplémentaires exige une option explicite. Lisez le manuel de l’extension que vous utilisez réellement plutôt que le premier exemple que vous trouvez.

iptables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner transmission -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
ip6tables -A OUTPUT -m owner --uid-owner transmission -j REJECT

L’ordre compte autant que la correspondance. Une acceptation large placée plus haut dans la chaîne annule un rejet précis placé plus bas : examinez donc la chaîne entière au lieu d’ajouter une règle en espérant. Incluez les deux familles d’adresses si l’hôte fait tourner IPv6, car une politique limitée à la v4 laisse ouvert un chemin que personne ne surveille. Laissez les règles installées à travers les redémarrages du client comme du tunnel.

Décider de ce qui se passe quand tun0 disparaît

La politique de panne est le cœur de l’exercice. Si le tunnel disparaît et que le même hook retire les règles, le client est libre d’utiliser l’interface physique tant que rien d’autre ne l’arrête. La conception sûre conserve les règles et les laisse rejeter : c’est ce qui rend la frontière indépendante de la santé du tunnel. Un hook de démontage qui supprime aussi les règles est l’exact contraire d’une politique de panne.

ip link show tun0
iptables -S OUTPUT

Testez-le délibérément : arrêtez le tunnel, lancez un transfert que vous pouvez abandonner sans risque et regardez si quelque chose sort. Ramenez ensuite le tunnel et confirmez que le chemin prévu fonctionne de nouveau.

Couvrir les chemins que la règle ne voit pas

La résolution de noms peut être assurée par un processus de résolution distinct, et un espace de noms ou une passerelle dédiée peut fournir une autre frontière si ses chemins de partage et d’amorçage sont conçus pour cela. Décidez quel composant possède le DNS et s’il suit la même règle de sortie. Regardez ensuite le RPC : si rpc-whitelist est utilisé, le réseau d’administration approuvé fait partie du contrat, et une large plage RFC1918 n’en fait pas partie.

ss -tunp | grep -i transmission

Les compteurs d’interface peuvent corroborer une observation, mais ils ne peuvent pas prouver quel processus a produit les octets. Lancez un transfert que vous êtes autorisé à abandonner : d’abord sur le chemin qui fonctionne, ensuite sans tunnel au démarrage, puis à travers une interruption, une reconnexion et une interface nouvellement créée. Testez une nouvelle tentative aussi bien qu’une connexion déjà ouverte, car la règle n’a peut-être pas été appliquée à l’ancien socket. Notez la date, le compte et le résultat avec le test.

Coller un exemple qui vide toute la chaîne échange un trou contre plusieurs : ajoutez donc des règles plutôt que de les effacer. Quand les cinq vérifications passent, la garantie est explicite : le trafic du client sort par le tunnel ou pas du tout, et la règle qui l’impose survit à la défaillance du tunnel lui-même.