Zašto vaše iptables pravilo nikad ne vidi VPN saobraćaj kroz most

Dvije virtualne mašine na istom hostu dolaze do LAN-a preko mosta, a pravilo postavljeno u ip forward lanac pokazuje brojač koji se nikad ne pomjera. Okviri su stvarni, saobraćaj prolazi, a pravilo jednostavno nije na njegovom putu. Poređenje dva načina na koja Linux izlaže saobraćaj kroz most objašnjava tu tišinu i objašnjava i zašto je učitavanje jednog zastarjelog modula gori odgovor nego što izgleda.

Dva puta kroz jedan host

Paket može napustiti ovaj host na dva vrlo različita načina, a ta razlika odlučuje koje će ga kuke vidjeti. Ako je odredište iza fizičkog porta i okvir se prebacuje između dva porta mosta, host prosljeđuje Ethernet okvir; rutirajući kod se ne poziva i nema rutiranog skoka. Ako je odredište sam host ili mreža dostupna kroz tunelski interfejs, paket se rutira i kuke IP sloja se zaista primjenjuju. Imajte tu račvu na umu, jer svako kasnije pitanje o lancima i familijama slijedi iz toga koji od dva puta okvir zauzme.

Ta razlika je cijela priča iza pravila koje ništa ne broji. Okvir kroz most od veth9a1 do enp3s0 prelazi most, a ne IP stek, pa lanac ip forward ne vidi ništa za uparivanje. Imena interfejsa u starijem primjeru ne odlučuju koji put imate, zato je prvi korak pogledati topologiju, a ne skup pravila.

Tunel dodaje treći slučaj koji vrijedi imenovati. TUN uređaj dostavlja IP pakete hostu, pa se oni rutiraju i zaista prolaze kroz IP lance, dok TAP uređaj priključen na most dostavlja okvire i ponaša se kao slučaj s mostom. Tip uređaja, a ne ime proizvoda, odlučuje.

Uporedite dvije familije koje mogu vidjeti okvir kroz most

Linux podržava izvorno filtriranje mosta kroz bridge familiju nftablesa i ne treba mu nikakav zastario modul da pregleda i odbaci okvire u letu. Sama dokumentacija o mostu kernela daje tu preporuku izravno, što vrijedi znati prije nego vam rezultat pretrage kaže da učitate modul.

Korištenje nft komande umjesto iptablesa samo po sebi ne stavlja pravilo u pravu familiju. Lanac deklarisan u bridge familiji vidi okvire; lanac deklarisan u ip, ip6 ili inet ne vidi, bez obzira na to koji ga je binarni fajl napravio. Familija je svojstvo lanca, a ne alata koji ga je otkucao.

Zastarjeli put radi drugačije i zato treba porediti, a ne birati stranu po navici. Učitavanje br_netfilter i uključivanje bridge-nf-call postavki ponovo izlaže saobraćaj IPv4 i IPv6 kroz most kroz kuke IP sloja, pa obično iptables pravilo konačno može da ga upari. Okviri se ne mijenjaju; mijenja se skup kuka kroz koje prolaze, što znači da svako postojeće pravilo hosta sada ima novu publiku.

Pročitajte efektivni put prije dodavanja pravila

Tri komande utvrđuju gdje ste: na šta je most priključen, da li je zastarjeli modul aktivan i koji lanci već postoje u bridge familiji. Pokrenite ih prije nego što bilo šta napišete, jer odgovor odlučuje koji od dva dizajna proširujete. Preskakanje ovog koraka je način na koji ispravno pravilo završi u lancu kroz koji ništa ne prolazi.

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

Izlaz čisto razdvaja slučajeve. Portovi navedeni pod mostom kažu koji se interfejsi prebacuju; prazan rezultat lsmod znači nikakvu vidljivost okvira kroz most na IP sloju; postojeći forward lanac bridge familije znači da vlasnik politike već postoji i da vaše pravilo pripada tamo, a ne u novi vlastiti lanac.

Zatim dodajte jedno pravilo koje se lako čita unazad, s brojačem i bez promjene verdikta, i propustite jedan reprezentativni tok kroz most. Brojač koji se pomjera dokazuje da je okvir stigao do pravila. To je sve što dokazuje, zato ga ispratite i odbijenim putem, jer politika koja prihvata sve takođe proizvodi brojač koji se pomjera.

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

Gdje zastarjeli modul mijenja ponašanje

Uključivanje zastarjelog puta na mostu koji radi nije neutralan čin dodavanja vidljivosti. Pravila koja su ranije bila nedostupna za saobraćaj kroz most postaju dostupna, uključujući pravila hosta pisana za drugi interfejs, a zadana drop politika u ip forward lancu može se odjednom primijeniti na okvire koji su prije prolazili netaknuti. Na hostu kojim se upravlja kroz taj most rezultat je zaključavanje bez konzole. To nije hipotetički način kvara; to je uobičajena posljedica proširenja skupa kuka na mašini do koje dolazite kroz put koji ste upravo proširili.

Sigurniji slijed je odlučiti koja familija posjeduje politiku, napisati pravila tamo i zadržati nezavisan put za oporavak prije promjene bilo kojeg sysctl-a. Ako dvije familije drže pravila, dokumentujte koja je mjerodavna; dvije politike koje se preklapaju su način na koji paket biva prihvaćen na jednom mjestu i odbačen na drugom bez ijednog fajla za čitanje.

Izolacija sama po sebi još uvijek traži potpun dizajn. Dopuštanje jednog izvora ka jednom odredištu dokazuje samo da jedan tok radi, dok je zahtjev obično da VM ne može doći do svojih susjeda ili hosta. Brojači na pravilima odbijanja važniji su od brojača na pravilu prihvatanja, jer brojač prihvatanja je onaj koji ste već očekivali da će se pomjeriti.

Konačno, držite slučaj ulaza hosta odvojeno. Saobraćaj upućen vlastitom IP-u mosta stiže na input, a ne na forward, i pravilo u forward-u ga nikad neće vidjeti bez obzira koju familiju odabrali. Tri slučaja, dvije familije, jedna lekcija: put odlučuje kuku, a kuka odlučuje postoji li vaše pravilo uopšte.