Miksi iptables-sääntösi ei koskaan näe sillan kautta kulkevaa VPN-liikennettä

Kaksi virtuaalikonetta samalla isännällä saavuttaa LANin sillan kautta, ja ip forward -ketjuun sijoitettu sääntö näyttää laskuria, joka ei koskaan liiku. Kehykset ovat todellisia, liikenne kulkee, ja sääntö ei yksinkertaisesti ole sen polulla. Sen vertaaminen, miten Linux tuo sillan kautta kulkevan liikenteen näkyviin kahdella tavalla, selittää tämän hiljaisuuden, ja se selittää myös, miksi yhden vanhan moduulin lataaminen on huonompi vastaus kuin miltä näyttää.

Kaksi polkua yhden isännän läpi

Paketti voi lähteä tältä isännältä kahdella hyvin erilaisella tavalla, ja ero ratkaisee, mitkä koukut sen näkevät. Jos kohde on fyysisen portin takana ja kehys kytketään kahden sillan portin välillä, isäntä välittää Ethernet-kehyksen; reitityskoodilta ei kysytä, eikä reititettyä hyppyä tapahdu. Jos kohde on isäntä itse tai verkko, johon päästään tunneliliitännän kautta, paketti reititetään ja IP-kerroksen koukut todella pätevät. Pidä tämä haarautuma mielessä, sillä jokainen myöhempi kysymys ketjuista ja perheistä seuraa siitä, kumman kahdesta polusta kehys valitsee.

Tuo ero on koko tarina säännön takana, joka ei laske mitään. Sillan kautta kulkeva kehys veth9a1:sta enp3s0:een ylittää sillan, ei IP-pinoa, joten ip forward-ketju ei näe mitään sovitettavaa. Vanhemman esimerkin liitännänimet eivät ratkaise, kumpi polku sinulla on, ja siksi ensimmäinen askel on katsoa topologiaa eikä sääntöjoukkoa.

Tunneli lisää kolmannen tapauksen, joka ansaitsee nimen. TUN-laite toimittaa IP-paketit isännälle, joten ne reititetään ja ne todella kulkevat IP-ketjujen läpi, kun taas siltaan liitetty TAP-laite toimittaa kehyksiä ja käyttäytyy kuin siltautunut tapaus. Laitteen tyyppi, ei tuotteen nimi, ratkaisee.

Vertaa kahta perhettä, jotka voivat nähdä sillan kautta kulkevan kehyksen

Linux tukee natiivia sillansuodatusta nftablesin bridge-perheen kautta, eikä se tarvitse mitään vanhaa moduulia kehysten tutkimiseen ja pudottamiseen lennossa. Ytimen oma siltadokumentaatio antaa tämän suosituksen suoraan, mikä kannattaa tietää ennen kuin hakutulos kertoo sinulle moduulin lataamisesta.

nft-komennon käyttäminen iptablesin sijaan ei itsessään aseta sääntöä oikeaan perheeseen. bridge-perheessä ilmoitettu ketju näkee kehykset; ip-, ip6- tai inet-perheessä ilmoitettu ketju ei näe, riippumatta siitä, mikä binaari sen loi. Perhe on ketjun ominaisuus, ei sitä kirjoittaneen työkalun.

Vanha polku toimii toisin, ja siksi kannattaa vertailla eikä valita puolta tottumuksesta. br_netfilter:n lataaminen ja bridge-nf-call-asetusten ottaminen käyttöön tuo sillan kautta kulkevan IPv4- ja IPv6-liikenteen jälleen IP-kerroksen koukkujen kautta näkyviin, joten tavallinen iptables-sääntö voi vihdoin sovittaa sen. Kehykset eivät muutu; muuttuu se koukkujen joukko, jonka ne ylittävät, mikä tarkoittaa, että jokaisella olemassa olevalla isännän säännöllä on nyt uusi yleisö.

Lue tehollinen polku ennen säännön lisäämistä

Kolme komentoa selvittävät, missä olet: mihin silta on liitetty, onko vanha moduuli aktiivinen ja mitkä ketjut ovat jo olemassa bridge-perheessä. Aja ne ennen kuin kirjoitat mitään, sillä vastaus ratkaisee, kumpaa kahdesta mallista olet laajentamassa. Tämän vaiheen väliin jättäminen on se tapa, jolla oikea sääntö päätyy ketjuun, jonka läpi mikään ei kulje.

bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"

Tuloste erottaa tapaukset puhtaasti. Sillan alla luetellut portit kertovat, mitkä liitännät on kytketty; tyhjä lsmod-tulos tarkoittaa, ettei sillan kautta kulkevista kehyksistä ole lainkaan näkyvyyttä IP-kerroksessa; olemassa oleva bridge-perheen forward-ketju tarkoittaa, että käytännön omistaja on jo olemassa ja että sääntösi kuuluu sinne eikä uuteen omaan ketjuun.

Lisää sitten yksi sääntö, joka on helppo lukea takaisin, laskurilla ja tuomiota muuttamatta, ja lähetä yksi edustava virtaus sillan läpi. Liikkuva laskuri todistaa, että kehys saavutti säännön. Se on kaikki, mitä se todistaa, joten seuraa sitä myös kielletyllä polulla, sillä käytäntö, joka hyväksyy kaiken, tuottaa myös liikkuvan laskurin.

nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter accept

Missä vanha moduuli muuttaa käyttäytymistä

Vanhan polun ottaminen käyttöön käynnissä olevassa sillassa ei ole neutraali näkyvyyden lisäämisen teko. Säännöt, jotka olivat aiemmin tavoittamattomia sillan kautta kulkevalle liikenteelle, tulevat tavoitettaviksi, mukaan lukien toiselle liitännälle kirjoitetut isännän säännöt, ja ip forward -ketjun oletusarvoinen drop-käytäntö voi yhtäkkiä soveltua kehyksiin, jotka ennen kulkivat koskemattomina. Isännällä, jota hallitaan tuon sillan kautta, seuraus on lukkiutuminen ilman konsolia. Tämä ei ole hypoteettinen vikatila; se on tavallinen seuraus koukkujoukon laajentamisesta koneessa, johon pääset juuri laajentamasi polun kautta.

Turvallisempi järjestys on päättää, mikä perhe omistaa käytännön, kirjoittaa säännöt sinne ja säilyttää riippumaton palautumispolku ennen minkään sysctl-arvon muuttamista. Jos kaksi perhettä pitää sääntöjä, dokumentoi, kumpi on valtuutettu; kaksi päällekkäistä käytäntöä ovat se tapa, jolla paketti hyväksytään yhdessä paikassa ja pudotetaan toisessa ilman yhtäkään luettavaa tiedostoa.

Eristäminen itsessään tarvitsee yhä täydellisen suunnittelun. Yhden lähteen salliminen yhteen kohteeseen todistaa vain, että yksi virtaus toimii, kun taas vaatimus on yleensä se, ettei VM pääse naapureihinsa tai isäntään. Hylkäyssääntöjen laskurit ovat tärkeämpiä kuin hyväksyntäsäännön laskuri, koska hyväksyntälaskuri on se, jonka jo odotit liikkuvan.

Lopuksi pidä isännän syötetapaus erillään. Sillan omaan IP-osoitteeseen osoitettu liikenne saapuu inputiin, ei forwardiin, eikä forwardin sääntö näe sitä koskaan, minkä perheen valitsetkin. Kolme tapausta, kaksi perhettä, yksi opetus: polku ratkaisee koukun, ja koukku ratkaisee, onko sääntösi ylipäätään olemassa.