Transmission w Linuxie: wymuś ruch wychodzący według właściciela procesu

Blokowanie portu wejściowego Transmission nie jest polityką VPN. Klient torrentów otwiera połączenia wychodzące do peerów i trackerów, rozwiązuje nazwy i może wystawić nasłuch zdalnego sterowania, a każdy z tych strumieni może wyjść przez interfejs, którego nie zamierzaliście użyć. Przejdźcie pięć kontroli po kolei i traktujcie jako granicę regułę zapory, a nie ustawienia klienta. Ostatnie dwie kontrole najczęściej się pomija i właśnie one decydują, czy gwarancja się utrzyma, gdy tunel padnie.

Nazwij proces, który jest właścicielem transferu

Aplikacja desktopowa i demon systemowy działają na różnych kontach, a reguła oparta na właścicielu idzie za kontem, a nie za nazwą programu. Ustal, który z nich działa, zanim napiszesz regułę. Dedykowane konto usługi daje polityce dokładny podmiot, podczas gdy użytkownik pulpitu dzieli tożsamość z przeglądarkami, edytorami i wszystkim innym w sesji. Potwierdź UID, zamiast zakładać, że nazwa konta z pakietu jest tą używaną.

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

Jeśli konto jeszcze nie istnieje, utwórz je w tym celu i nie dawaj mu niczego innego do uruchamiania. Zapisz konto i UID w komentarzu reguły, bo reguła bez podmiotu to reguła, której nikt nie może bezpiecznie edytować.

Oddziel pola nasłuchu od trasy

Transmission 4.x dokumentuje adresy nasłuchu peerów osobno od rpc-bind-address, a ta różnica ma znaczenie. Ustawienie RPC steruje tylko nasłuchem zdalnego sterowania, więc jego zmiana nie wybiera trasy dla ruchu peerów. Czytanie obu ustawień jako jednego to najczęstsza przyczyna tego, że staranna z pozoru konfiguracja wciąż przecieka. Ta sama dokumentacja opisuje przypadek awaryjny, gdy adres nasłuchu peerów jest nieprawidłowy, więc niedostępny adres to udokumentowany przypadek awaryjny, a nie gwarantowana odmowa.

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

Używajcie kontrolek klienta zgodnie z ich przeznaczeniem, a gwarancję umieśćcie w zaporze. Ustawienie nasłuchu może nadal być przydatne, ale nie dowodzi, że kontakt z trackerami, lokalne wykrywanie albo delegowane wyszukiwanie wychodzą przez tunel. Gdy te dwie rzeczy się nie zgadzają, decyduje zapora.

Zapisz dopasowanie właściciela w odpowiednim łańcuchu

Podręcznik Netfilter o dopasowaniu właściciela wyjaśnia, jak lokalnie tworzone pakiety przypisuje się użytkownikowi lub grupie będącym właścicielami pliku gniazda. To przypisanie nie obejmuje ruchu przekazywanego, a dopasowanie dodatkowych grup wymaga jawnej opcji. Czytajcie podręcznik tego rozszerzenia, którego naprawdę używacie, a nie pierwszy znaleziony przykład.

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

Kolejność jest równie ważna jak dopasowanie. Szerokie zezwolenie wyżej w łańcuchu znosi precyzyjną odmowę niżej, więc przejrzyjcie cały łańcuch, zamiast dopisywać regułę i mieć nadzieję. Uwzględnijcie obie rodziny adresów, jeśli host działa na IPv6, bo polityka tylko dla v4 zostawia otwartą ścieżkę, której nikt nie pilnuje. Utrzymujcie reguły zainstalowane także po restartach klienta i tunelu.

Zdecydujcie, co się stanie, gdy tun0 zniknie

Polityka awaryjna jest sednem ćwiczenia. Jeśli tunel zniknie, a ten sam hook usunie reguły, klient może swobodnie używać interfejsu fizycznego, dopóki coś innego go nie zatrzyma. Bezpieczny projekt zachowuje reguły i pozwala im odmawiać, i to czyni granicę niezależną od kondycji tunelu. Hook demontażu, który usuwa także reguły, jest dokładnym przeciwieństwem polityki awaryjnej.

ip link show tun0
iptables -S OUTPUT

Sprawdźcie to celowo: zatrzymajcie tunel, rozpocznijcie transfer, który można bezpiecznie porzucić, i obserwujcie, czy coś wychodzi. Potem przywróćcie tunel i potwierdźcie, że zamierzona ścieżka znów działa.

Obejmijcie ścieżki, których reguła nie widzi

Rozwiązywanie nazw może obsługiwać osobny proces resolvera, a przestrzeń nazw lub dedykowana brama mogą dać kolejną granicę, jeśli ich ścieżki udostępniania i rozruchu są tak zaprojektowane. Zdecydujcie, który komponent jest właścicielem DNS i czy stosuje tę samą regułę wyjścia. Potem spójrzcie na RPC: jeśli używane jest rpc-whitelist, zatwierdzona sieć zarządzania jest częścią umowy, a szeroki zakres RFC1918 nie.

ss -tunp | grep -i transmission

Liczniki interfejsu mogą potwierdzić obserwację, ale nie mogą dowieść, który proces wytworzył bajty. Wykonajcie transfer, który wolno wam porzucić: najpierw na działającej ścieżce, potem bez tunelu przy starcie, a następnie przez przerwanie, ponowne połączenie i świeżo utworzony interfejs. Przetestujcie zarówno nową próbę, jak i połączenie już otwarte, bo reguła mogła nie zostać zastosowana do starszego gniazda. Zapiszcie datę, konto i wynik razem z testem.

Wklejenie przykładu, który czyści cały łańcuch, zamienia jedną dziurę na kilka, więc dodawajcie reguły, zamiast je usuwać. Gdy przejdzie wszystkie pięć kontroli, gwarancja jest wyraźna: ruch klienta wychodzi przez tunel albo wcale, a reguła, która to wymusza, przetrwa własną awarię tunelu.