Transmission Linuxissa: pakota lähtevä liikenne prosessin omistajan mukaan

Transmissionin saapuvan portin estäminen ei ole VPN-käytäntö. Torrent-asiakas avaa lähteviä yhteyksiä vertaisiin ja tracker-palvelimiin, ratkaisee nimiä ja voi pitää etähallinnan kuuntelijaa, ja jokainen näistä voi lähteä rajapinnasta, jota et tarkoittanut. Käy viisi tarkistusta läpi järjestyksessä ja pidä rajana palomuurisääntöä, älä asiakkaan asetuksia. Kaksi viimeistä tarkistusta jätetään usein väliin, ja juuri ne ratkaisevat, pitääkö takuu tunnelin pudotessa.

Nimeä prosessi, joka omistaa siirron

Työpöytäsovellus ja järjestelmän taustapalvelu toimivat eri tileillä, ja omistajaan perustuva sääntö seuraa tiliä eikä ohjelman nimeä. Selvitä, kumpi on käynnissä, ennen kuin kirjoitat säännön. Erillinen palvelutili antaa käytännölle täsmällisen subjektin, kun taas työpöytäkäyttäjä jakaa identiteettinsä selainten, editorien ja kaiken muun istunnon kanssa. Vahvista UID sen sijaan, että olettaisit paketin tilitunnuksen olevan käytössä oleva.

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

Jos tiliä ei vielä ole, luo se tätä tarkoitusta varten äläkä anna sille mitään muuta ajettavaa. Kirjoita tili ja UID säännön kommenttiin, koska sääntö ilman subjektia on sääntö, jota kukaan ei voi muokata turvallisesti.

Erota kuuntelukentät reitistä

Transmission 4.x dokumentoi vertaisten kuunteluosoitteet erikseen rpc-bind-address-asetuksesta, ja ero on tärkeä. RPC-asetus ohjaa vain etähallinnan kuuntelijaa, joten sen muuttaminen ei valitse reittiä vertaisliikenteelle. Näiden kahden asetuksen lukeminen yhtenä on yleisin syy siihen, että huolelliselta näyttävä kokoonpano vuotaa silti. Sama dokumentaatio kuvaa varatien, kun vertaisen kuunteluosoite on virheellinen, eli käyttökelvoton osoite on dokumentoitu varatapaus, ei taattu hylkäys.

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

Käytä asiakkaan säätimiä siihen, mitä ne ovat, ja laita takuu palomuuriin. Kuunteluasetus voi silti olla hyödyllinen, mutta se ei osoita, että yhteys trackereihin, paikallinen löytäminen tai delegoitu haku lähtevät kaikki tunnelin kautta. Kun nämä kaksi ovat eri mieltä, palomuuri ratkaisee.

Kirjoita omistajavastaavuus oikeaan ketjuun

Netfilterin omistajavastaavuuden käsikirja selittää, miten paikallisesti luodut paketit liitetään socket-tiedoston omistavaan käyttäjään tai ryhmään. Tämä liittäminen ei ulotu välitettyyn liikenteeseen, ja lisäryhmien vastaavuus vaatii nimenomaisen valinnan. Lue sen laajennuksen käsikirja, jota todella käytät, älä ensimmäistä löytämääsi esimerkkiä.

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

Järjestys on yhtä tärkeä kuin vastaavuus. Laaja hyväksyntä ketjun alussa kumoaa tarkan hylkäyksen myöhemmin, joten tarkista koko ketju sen sijaan, että lisäisit säännön ja toivoisit. Sisällytä molemmat osoiteperheet, jos isäntä ajaa IPv6:ta, koska vain v4:n käytäntö jättää avoimeksi polun, jota kukaan ei valvo. Pidä säännöt asennettuina sekä asiakkaan että tunnelin uudelleenkäynnistysten yli.

Päätä, mitä tapahtuu, kun tun0 katoaa

Vikatilakäytäntö on harjoituksen ydin. Jos tunneli katoaa ja sama koukku poistaa säännöt, asiakas saa käyttää fyysistä rajapintaa, kunnes jokin muu pysäyttää sen. Turvallinen suunnittelu pitää säännöt ja antaa niiden hylätä, ja juuri se tekee rajasta riippumattoman tunnelin terveydestä. Purkukoukku, joka poistaa myös säännöt, on vikatilakäytännön täsmällinen vastakohta.

ip link show tun0
iptables -S OUTPUT

Testaa sitä tarkoituksella: pysäytä tunneli, käynnistä siirto, jonka voi turvallisesti hylätä, ja katso, lähteekö mitään. Tuo sitten tunneli takaisin ja vahvista, että aiottu polku toimii taas.

Kata polut, joita sääntö ei näe

Nimien ratkaisun voi hoitaa erillinen ratkaisuprosessi, ja nimiavaruus tai erillinen yhdyskäytävä voi tarjota toisen rajan, jos niiden jakamis- ja käynnistyspolut on suunniteltu siihen. Päätä, mikä komponentti omistaa DNS:n ja seuraako se samaa lähtösääntöä. Katso sitten RPC:tä: jos rpc-whitelist on käytössä, hyväksytty hallintaverkko on osa sopimusta, mutta laaja RFC1918-alue ei.

ss -tunp | grep -i transmission

Rajapintalaskurit voivat tukea havaintoa, mutta eivät voi todistaa, mikä prosessi tuotti tavut. Tee siirto, jonka saat hylätä: ensin toimivalla polulla, sitten ilman tunnelia käynnistyksessä, sitten keskeytyksen, uudelleenyhdistämisen ja juuri luodun rajapinnan kautta. Testaa sekä uusi yritys että jo avoinna ollut yhteys, koska sääntöä ei ehkä sovellettu vanhempaan socketiin. Kirjaa päivämäärä, tili ja tulos testin kanssa.

Koko ketjun tyhjentävän esimerkin liittäminen vaihtaa yhden reiän useaan, joten lisää sääntöjä sen sijaan, että poistat niitä. Kun kaikki viisi tarkistusta menevät läpi, takuu on selvä: asiakkaan liikenne lähtee tunnelin kautta tai ei lainkaan, ja sääntö, joka sen pakottaa, kestää itse tunnelin vian.