Miksi nftables ei näe OpenVPN:n asiakkaiden välistä liikennettä
Vertaisverkon liikenne toimitetaan VPN-prosessin sisällä, joten edelleenlähetyslaskurit eivät koskaan liiku. Sen laskeminen tarkoittaa valintaa ydinpolun ja prosessipolun välillä.
Kaksi asiakasta samalla palvelimella vaihtaa tiedostoja, siirto onnistuu, ja jokainen edelleenlähetyssääntö, jonka osoitat tunnelille, raportoi nolla pakettia. Säännöt eivät ole rikki eikä ketju ole väärässä paikassa. Kun vertaisten välinen edelleenlähetys on käytössä, paketti toimitetaan palvelinprosessin sisällä eikä isäntäpino koskaan muutu reitittimeksi, joten ytimen palomuurilla ei ole mitään laskettavaa. Tämän jaon ymmärtäminen ratkaisee, pidätkö oikotien vai rakennatko polun uudelleen ytimen kautta.
Seuraa yhtä pakettia palvelimen läpi
Reititetyssä tunnelissa taustaprosessi antaa kunkin asiakkaan salauksen purkaman paketin tunnelilaitteelle. Siitä isäntä reitittää sen, edelleenlähetyskoukku ajetaan, ja tunnelilaitteeseen täsmäävä sääntö voi laskea tai pudottaa liikenteen. Tämä on polku, jonka useimmat palomuuriesimerkit olettavat.
| Forwarding path | Who decides | What the host firewall sees |
|---|---|---|
| Kernel routing between clients | Host routing table and forward rules | Every inner packet, with interface names |
| Peer forwarding inside the server process | The VPN daemon's own peer table | Only the outer encrypted transport |
Oikotie poistaa isännän keskeltä. Yhden istunnon salauksen purkama paketti annetaan toiselle istunnolle taustaprosessin sisällä, eikä sisäistä pakettia koskaan lähetetä tunnelilaitteelle eikä isäntä reititä sitä. Kapseloitu liikenne ylittää silti fyysisen rajapinnan, joten ulkoinen kaappaus näyttää kiireiseltä, kun sisäiset säännöt pysyvät hiljaisina. Tunnelilaitteella otettu kaappaus ei näytä yhtään mitään, mikä yllättää jokaisen, joka odottaa näkevänsä siirron siellä. Tämä epäsymmetria on nopein tapa tunnistaa oikotie taustaprosessin ulkopuolelta.
Laskuritesti, joka ratkaisee, mikä polku toteutui
Kiinnitä laskuri sääntöön, jonka pitäisi päteä, aja siirto kahden asiakkaan välillä, jotka säännön pitäisi estää, ja lue laskuri sen jälkeen.
sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward
Jos siirto onnistuu ja laskuri pysyy nollassa, ydin ei koskaan käsitellyt näitä paketteja, eikä mikään sääntöjen muokkaus muuta sitä. Toista sama testi palvelimella itsellään olevaa palvelua vastaan, koska tämä virta todella kulkee isäntäpinon läpi ja sen laskuri liikkuu. Kahden tuloksen vertailu tuottaa vastauksen.
Kaksi yksityiskohtaa estää väärän lukeman. Ketjutunnisteeseen kirjoitettu rajapinnan nimi ei itsessään suodata mitään, koska täsmäytys tapahtuu sääntöjen sisäisissä rajapintakentissä. Ja sillattu 2. kerroksen rakenne käyttäytyy taas eri tavalla: siellä asiakkaat jakavat yhden lähetysalueen, joten vertaisten löytyminen on odotettua eikä reititysvika.
Kytkin ei ole käyttöluettelo
Tämä on se osa, joka maksaa yhden iltapäivän. Vertaisten välinen edelleenlähetys on yksi päällä tai pois -asetus, ja kun se on päällä, taustaprosessi on ainoa edelleenlähetyspiste. Isännän palomuuri ei voi ilmaista, kuka saa päästä kenen luo, eivätkä asiakaskohtaiset tiedostot tee kytkimestä politiikkamatriisia.
Jos tarvitset säännöt vertaittain, valinta on oikotiestä luopumisen ja isännän palomuurista ohjausvälineenä luopumisen välillä. Sen pois kytkeminen palauttaa ytimen edelleenlähetyksen, mikä vaatii IP-edelleenlähetyksen palvelimella ja nimenomaiset säännöt halutuille virroille. Päällä pitäminen tarkoittaa, että politiikka elää taustaprosessin kokoonpanossa, mikä käytännössä on kaikki vertaiset tai ei yhtään.
Erilliset palvelinprosessit omine osoitevarantoineen ja portteineen ovat toimiva keskitie. Jokainen prosessi kantaa täsmälleen yhden käyttöpäätöksen, joten kahdella ryhmällä voi olla eri säännöt ilman politiikkamatriisia. Isäntä voi reitittää varantojen välillä, kun se on tarkoitus, ja silloin palomuuri näkee nämä virrat, koska ne ylittävät isännän. Hinta on lisäportit, lisävarmenne ja profiili ryhmää kohden.
Edelleenlähetyspisteen valinta
Valitse ytimen edelleenlähetys, kun palomuuri on politiikkamoottori, kun tarvitset lokitusta virroittain tai kun laskenta on tärkeää. Hinta on läpäisykyky isäntäpinon läpi ja enemmän ylläpidettäviä sääntöjä. Etu on, että jokainen olemassa oleva työkalu laskureista virtojen vientityökaluihin kuvaa liikenteen jälleen. Pienellä palvelimella tämä hinta on näkymätön; kiireisellä välityspalvelimella ei.
Valitse prosessin sisäinen edelleenlähetys, kun vertaisliikenne on joko kokonaan sallittua tai kokonaan kiellettyä ja palvelin on mitoitettu siihen. Hinta on, että laskurit, jonokurit ja yhteyksien seuranta eivät enää kuvaa sisäisiä virtoja; se on hyväksyttävää vain, jos kukaan ei myöhemmin nojaa niihin.
Minkä tahansa valitsetkin, kirjoita se palomuurisääntöjen viereen. Sääntöjoukko, joka näyttää sallivan vertaisliikenteen, vaikka taustaprosessi päättää joka tapauksessa, johtaa harhaan seuraavaa henkilöä, joka selvittää epäonnistunutta siirtoa. Jokainen, joka lukee vain säännöt, olettaa ytimen olevan portti.
Mitä tarkistaa ennen sääntöjen muuttamista
Lue kokoonpano, jonka palvelin todella latasi, älä tiedostoa, jonka muistat muokanneesi, ja varmista, onko vertaisasetus läsnä. Jos muutit sitä, varmista, että palvelu latautui uudelleen eikä vain kirjoittanut tiedostoa levylle uudelleen.
Toista sitten testi asiakkaalta palvelimelle suuntautuvalla virralla todistaaksesi, että sääntö ylipäätään täsmää, ja tarkista työnnetyt reitit, koska puuttuva reitti näyttää asiakkaan puolelta täsmälleen palomuurin estolta. Muuta sääntöjen järjestystä vasta kun tiedät, mikä edelleenlähetyspiste päätöksen omistaa.