Transmission a Linux: forçar la sortida per propietari del procés

Bloquejar el port d’entrada del Transmission no és una política de VPN. Un client de torrents obre connexions sortints cap als parells i els rastrejadors, resol noms i pot exposar un escoltador de control remot, i cadascuna d’aquestes sortides pot marxar per una interfície que no havíeu previst. Recorreu les cinc comprovacions en ordre i tracteu la regla del tallafoc, no els ajustos del client, com la frontera. Les dues últimes comprovacions són les que la gent s’estalvia, i són les que decideixen si la garantia aguanta quan el túnel cau.

Nomenar el procés propietari de la transferència

L’aplicació d’escriptori i el dimoni del sistema s’executen amb comptes diferents, i una regla basada en el propietari segueix el compte en lloc del nom del programa. Esbrineu quin dels dos s’executa abans d’escriure cap regla. Un compte de servei dedicat dona a la política un subjecte precís, mentre que un usuari d’escriptori comparteix la seva identitat amb navegadors, editors i tota la resta de la sessió. Confirmeu l’UID en lloc de suposar que el nom de compte empaquetat és el que s’utilitza.

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

Si el compte encara no existeix, creeu-lo per a aquesta finalitat i no li doneu res més a executar. Escriviu el compte i l’UID al comentari de la regla, perquè una regla sense subjecte és una regla que ningú no pot editar amb seguretat.

Separar els camps d’escolta de la ruta

El Transmission 4.x documenta les adreces d’escolta de parells per separat de rpc-bind-address, i la diferència importa. L’ajust RPC només controla l’escoltador de control remot, així que canviar-lo no tria una ruta per al trànsit de parells. Llegir els dos ajustos com un de sol és la raó més habitual que una configuració d’aspecte curós segueixi filtrant. La mateixa documentació descriu un retrocés quan una adreça d’escolta de parells no és vàlida, així que una adreça no disponible és un cas de retrocés documentat, no una negativa garantida.

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

Useu els controls del client per al que són i poseu la garantia al tallafoc. Un ajust d’escolta encara pot valer la pena, però no estableix que el contacte amb rastrejadors, el descobriment local o una resolució delegada surtin tots pel túnel. Quan els dos discrepen, és el tallafoc qui decideix.

Escriure la coincidència de propietari a la cadena correcta

El manual del Netfilter sobre la coincidència de propietari explica com els paquets generats localment s’atribueixen a l’usuari o grup propietari del fitxer de socket. Aquesta atribució no s’estén al trànsit reenviat, i la coincidència de grups suplementaris necessita una opció explícita. Llegiu el manual de l’extensió que realment feu servir en lloc del primer exemple que trobeu.

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 importa tant com la coincidència. Una acceptació àmplia més amunt a la cadena anul·la un rebuig precís més avall, així que reviseu tota la cadena en lloc d’afegir una regla i esperar. Incloeu les dues famílies d’adreces si l’amfitrió executa IPv6, perquè una política només de v4 deixa obert un camí que ningú no vigila. Manteniu les regles instal·lades a través dels reinicis tant del client com del túnel.

Decidir què passa quan el tun0 desapareix

La política de fallada és el centre de l’exercici. Si el túnel desapareix i el mateix hook treu les regles, el client és lliure d’usar la interfície física fins que una altra cosa l’aturi. El disseny segur conserva les regles i les deixa rebutjar, i és això el que fa la frontera independent de la salut del túnel. Un hook de desmuntatge que també esborra les regles és el contrari d’una política de fallada.

ip link show tun0
iptables -S OUTPUT

Proveu-ho a propòsit: atureu el túnel, inicieu una transferència que pugueu abandonar sense risc i observeu si en surt res. Després torneu el túnel i confirmeu que el camí previst torna a funcionar.

Cobrir els camins que la regla no veu

La resolució de noms pot anar a càrrec d’un procés resolutor a part, i un espai de noms o una passarel·la dedicada poden oferir una altra frontera si els seus camins de compartició i d’arrencada estan dissenyats per a això. Decidiu quin component és propietari del DNS i si segueix la mateixa regla de sortida. Després mireu l’RPC: si s’usa rpc-whitelist, la xarxa de gestió aprovada forma part del contracte, i un interval RFC1918 ampli no.

ss -tunp | grep -i transmission

Els comptadors d’interfície poden corroborar una observació, però no poden demostrar quin procés ha produït els bytes. Feu una transferència que tingueu permís per abandonar: primer pel camí que funciona, després sense túnel en arrencar, i tot seguit a través d’una interrupció, una reconnexió i una interfície creada de nou. Proveu tant un intent nou com una connexió que ja era oberta, perquè potser la regla no s’ha aplicat al socket més antic. Anoteu la data, el compte i el resultat amb la prova.

Enganxar un exemple que buida tota la cadena canvia un forat per diversos, així que afegiu regles en lloc d’esborrar-les. Quan passen les cinc comprovacions, la garantia és explícita: el trànsit del client surt pel túnel o no surt, i la regla que ho imposa sobreviu a la fallada del túnel mateix.