Transmission unter Linux: ausgehenden Verkehr nach Prozesseigentümer erzwingen

Den eingehenden Port von Transmission zu blockieren ist keine VPN-Richtlinie. Ein Torrent-Client öffnet ausgehende Verbindungen zu Peers und Trackern, löst Namen auf und kann einen Remote-Control-Listener bereitstellen, und jeder dieser Vorgänge kann über eine Schnittstelle abfließen, die Sie nicht vorgesehen haben. Arbeiten Sie die fünf Prüfungen der Reihe nach durch und betrachten Sie die Firewall-Regel – nicht die Einstellungen des Clients – als die Grenze. Die letzten beiden Prüfungen sind die, die man gern überspringt, und sie entscheiden darüber, ob die Garantie hält, wenn der Tunnel wegbricht.

Den Prozess benennen, dem die Übertragung gehört

Die Desktop-Anwendung und der System-Daemon laufen unter verschiedenen Konten, und eine Regel nach Eigentümer folgt dem Konto statt dem Programmnamen. Finden Sie heraus, welche der beiden läuft, bevor Sie eine Regel schreiben. Ein eigenes Dienstkonto gibt der Richtlinie ein präzises Subjekt, während ein Desktop-Benutzer seine Identität mit Browsern, Editoren und allem anderen in der Sitzung teilt. Bestätigen Sie die UID, statt anzunehmen, dass der paketierte Kontoname auch der verwendete ist.

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

Existiert das Konto noch nicht, legen Sie es für diesen Zweck an und lassen Sie darüber nichts anderes laufen. Schreiben Sie Konto und UID in den Kommentar der Regel, denn eine Regel ohne Subjekt ist eine Regel, die niemand gefahrlos bearbeiten kann.

Die Listener-Felder von der Route trennen

Transmission 4.x dokumentiert Peer-Listen-Adressen getrennt von rpc-bind-address, und der Unterschied ist wichtig. Die RPC-Einstellung steuert nur den Remote-Control-Listener, ihre Änderung wählt also keine Route für den Peer-Verkehr. Diese beiden Einstellungen als eine zu lesen ist der häufigste Grund, warum eine sorgfältig wirkende Konfiguration trotzdem leckt. Dieselbe Dokumentation beschreibt einen Fallback für den Fall, dass eine Peer-Listen-Adresse ungültig ist; eine nicht verfügbare Adresse ist also ein dokumentierter Fallback-Fall und keine garantierte Ablehnung.

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

Nutzen Sie die Steuerelemente des Clients für das, was sie sind, und legen Sie die Garantie in die Firewall. Eine Listener-Einstellung kann trotzdem sinnvoll sein, aber sie belegt nicht, dass Tracker-Kontakt, lokale Erkennung oder eine delegierte Auflösung allesamt durch den Tunnel verlassen. Wenn die beiden auseinandergehen, entscheidet die Firewall.

Den Eigentümer-Match in der richtigen Kette schreiben

Das Netfilter-Handbuch zum Owner-Match erklärt, wie lokal erzeugte Pakete dem besitzenden Benutzer oder der Gruppe der Socket-Datei zugeordnet werden. Diese Zuordnung erstreckt sich nicht auf weitergeleiteten Verkehr, und das Abgleichen von Zusatzgruppen braucht eine ausdrückliche Option. Lesen Sie das Handbuch für die Erweiterung, die Sie tatsächlich verwenden, statt das erste Beispiel, das Sie finden.

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

Die Reihenfolge zählt genauso viel wie der Match. Eine breite Annahme weiter oben in der Kette hebelt eine präzise Ablehnung weiter unten aus, prüfen Sie also die ganze Kette, statt eine Regel anzuhängen und zu hoffen. Beziehen Sie beide Adressfamilien ein, wenn der Host IPv6 spricht, denn eine reine v4-Richtlinie lässt einen Pfad offen, den niemand beobachtet. Halten Sie die Regeln über Neustarts von Client und Tunnel hinweg installiert.

Entscheiden, was geschieht, wenn tun0 verschwindet

Die Fehlerrichtlinie ist der Kern der Übung. Wenn der Tunnel verschwindet und derselbe Hook die Regeln entfernt, darf der Client die physische Schnittstelle benutzen, bis etwas anderes ihn stoppt. Das sichere Design behält die Regeln und lässt sie ablehnen; genau das macht die Grenze unabhängig von der Gesundheit des Tunnels. Ein Teardown-Hook, der die Regeln zusätzlich löscht, ist das Gegenteil einer Fehlerrichtlinie.

ip link show tun0
iptables -S OUTPUT

Testen Sie es gezielt: Stoppen Sie den Tunnel, starten Sie eine Übertragung, die Sie gefahrlos abbrechen dürfen, und beobachten Sie, ob etwas hinausgeht. Bringen Sie dann den Tunnel zurück und bestätigen Sie, dass der vorgesehene Pfad wieder funktioniert.

Die Pfade abdecken, die die Regel nicht sieht

Die Namensauflösung kann von einem separaten Resolver-Prozess erledigt werden, und ein Namespace oder ein dediziertes Gateway kann eine weitere Grenze bieten, wenn seine Sharing- und Bootstrap-Pfade entsprechend entworfen sind. Entscheiden Sie, welche Komponente für DNS zuständig ist und ob sie derselben Egress-Regel folgt. Dann sehen Sie sich RPC an: Wenn rpc-whitelist im Einsatz ist, gehört das freigegebene Managementnetz zum Vertrag, ein breiter RFC1918-Bereich dagegen nicht.

ss -tunp | grep -i transmission

Schnittstellenzähler können eine Beobachtung stützen, aber sie können nicht beweisen, welcher Prozess die Bytes erzeugt hat. Führen Sie eine Übertragung durch, die Sie abbrechen dürfen: zuerst auf dem funktionierenden Pfad, dann ohne Tunnel beim Start, dann über eine Unterbrechung, eine Wiederverbindung und eine frisch erstellte Schnittstelle hinweg. Testen Sie sowohl einen neuen Versuch als auch eine bereits offene Verbindung, denn die Regel hat auf den älteren Socket vielleicht nicht gegriffen. Halten Sie Datum, Konto und Ergebnis beim Test fest.

Ein Beispiel einzufügen, das die ganze Kette flusht, tauscht ein Loch gegen mehrere, fügen Sie also Regeln hinzu, statt sie zu löschen. Wenn alle fünf Prüfungen bestehen, ist die Garantie ausdrücklich: Der Verkehr des Clients verlässt den Rechner durch den Tunnel oder gar nicht, und die Regel, die das erzwingt, übersteht den Ausfall des Tunnels selbst.