Zakaj vaše pravilo iptables nikoli ne vidi prometa VPN prek mostu

Dve virtualni napravi na istem gostitelju dosežeta LAN prek mostu, pravilo v verigi ip forward pa kaže števec, ki se nikoli ne premakne. Okviri so resnični, promet teče, in pravilo preprosto ni na njegovi poti. Primerjava dveh načinov, kako Linux izpostavi promet prek mostu, pojasnjuje to tišino in tudi to, zakaj je nalaganje enega starega modula slabši odgovor, kot se zdi.

Dve poti skozi enega gostitelja

Paket lahko zapusti tega gostitelja na dva zelo različna načina, in razlika odloča, kateri kavlji ga vidijo. Če je cilj za fizičnim vratom in se okvir preklaplja med dvema vratoma mostu, gostitelj posreduje okvir Ethernet; koda za usmerjanje ni vprašana in ne zgodi se noben usmerjen skok. Če je cilj gostitelj sam ali omrežje, doseženo prek vmesnika tunela, se paket usmeri in kavlji plasti IP res veljajo. Imejte to razcepko v mislih, ker vsako poznejše vprašanje o verigah in družinah izhaja iz tega, katero od dveh poti okvir izbere.

Ta razlika je vsa zgodba za pravilom, ki ničesar ne šteje. Okvir prek mostu od veth9a1 do enp3s0 prečka most, ne sklada IP, zato veriga ip forward ne vidi ničesar za ujemanje. Imena vmesnikov v starejšem primeru ne določajo, katero pot imate, zato je prvi korak pogled na topologijo in ne na nabor pravil.

Tunel doda tretji primer, ki si zasluži ime. Naprava TUN dostavi pakete IP gostitelju, zato se ti usmerijo in res gredo skozi verige IP, medtem ko naprava TAP, priključena na most, dostavi okvire in se obnaša kot primer mostu. Odloča vrsta naprave, ne ime izdelka.

Primerjajte družini, ki lahko vidita okvir prek mostu

Linux podpira izvorno filtriranje mostu prek družine bridge v nftables in ne potrebuje nobenega starega modula za pregledovanje in zavrženje okvirov med letom. Dokumentacija mostu samega jedra to priporočilo podaja neposredno, kar velja vedeti, preden vam rezultat iskanja reče, naj naložite modul.

Uporaba ukaza nft namesto iptables sama po sebi ne postavi pravila v pravo družino. Veriga, deklarirana v družini bridge, vidi okvire; veriga, deklarirana v ip, ip6 ali inet, jih ne vidi, ne glede na to, katera binarna datoteka jo je ustvarila. Družina je lastnost verige, ne orodja, ki jo je vtipkalo.

Stara pot deluje drugače in prav zato velja primerjati, namesto da bi iz navade izbrali stran. Nalaganje br_netfilter in vklop nastavitev bridge-nf-call znova izpostavi promet IPv4 in IPv6 prek mostu skozi kavlje plasti IP, tako da se lahko običajno pravilo iptables končno ujame z njim. Okviri se ne spremenijo; spremeni se nabor kavljev, skozi katere gredo, kar pomeni, da ima vsako obstoječe pravilo gostitelja zdaj novo občinstvo.

Preberite dejansko pot, preden dodate pravilo

Trije ukazi ugotovijo, kje ste: na kaj je priključen most, ali je stari modul aktiven in katere verige v družini bridge že obstajajo. Zaženite jih, preden karkoli napišete, ker odgovor odloča, katero od dveh zasnov razširjate. Preskok tega koraka je način, kako pravilno pravilo konča v verigi, skozi katero ne gre nič.

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

Izhod primere čisto loči. Vrata, navedena pod mostom, vam povedo, kateri vmesniki se preklapljajo; prazen rezultat lsmod pomeni nobene vidnosti na plasti IP za okvire prek mostu; obstoječa veriga forward družine bridge pomeni, da lastnik politike že obstaja in da vaše pravilo spada tja, ne v novo lastno verigo.

Nato dodajte eno pravilo, ki se zlahka prebere nazaj, s števcem in brez spremembe razsodbe, in pošljite skozi most en reprezentativen tok. Števec, ki se premakne, dokazuje, da je okvir dosegel pravilo. To je vse, kar dokazuje, zato mu sledite tudi z zavrnjeno potjo, saj politika, ki sprejme vse, prav tako ustvari premikajoč se števec.

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

Kje stari modul spremeni vedenje

Vklop stare poti na delujočem mostu ni nevtralno dejanje dodajanja vidnosti. Pravila, ki so bila prej nedosegljiva za promet prek mostu, postanejo dosegljiva, vključno s pravili gostitelja, napisanimi za drug vmesnik, in privzeta politika drop v verigi ip forward se lahko nenadoma uporabi za okvire, ki so prej šli nepoškodovani. Na gostitelju, ki se upravlja prek tega mostu, je rezultat zaklep brez konzole. To ni hipotetični način odpovedi; to je običajna posledica razširitve nabora kavljev na stroju, do katerega pridete po pravkar razširjeni poti.

Varnejše zaporedje je odločiti, katera družina ima politiko, tam napisati pravila in ohraniti neodvisno pot za obnovitev, preden spremenite kateri koli sysctl. Če imata pravila obe družini, dokumentirajte, katera je referenčna; dve prekrivajoči se politiki sta način, kako je paket sprejet na enem mestu in zavržen na drugem brez ene same datoteke za branje.

Izolacija sama še vedno potrebuje celovito zasnovo. Dovoljenje enega vira do enega cilja dokazuje le, da en tok deluje, medtem ko je zahteva običajno ta, da VM ne more doseči svojih sosedov ali gostitelja. Števci na pravilih zavrnitve so pomembnejši od števca na pravilu sprejema, ker je števec sprejema tisti, za katerega ste že pričakovali, da se bo premaknil.

Na koncu imejte primer vhoda gostitelja ločeno. Promet, naslovljen na lastni IP mostu, prispe na input, ne na forward, in pravilo v forward ga ne bo nikoli videlo, katero družino koli izberete. Trije primeri, dve družini, ena lekcija: pot odloča o kavlju, kavelj pa o tem, ali vaše pravilo sploh obstaja.