Miks sinu iptables-reegel ei näe kunagi silla kaudu liikuvat VPN-liiklust

Kaks virtuaalmasinat samal hostil jõuavad LAN-i läbi silla, ja ip forward-ahelasse paigutatud reegel näitab loendurit, mis ei liigu kunagi. Kaadrid on reaalsed, liiklus liigub, ja reegel lihtsalt ei ole selle teel. Kahe viisi võrdlemine, kuidas Linux silla kaudu liikuvat liiklust paljastab, seletab seda vaikust, ja see seletab ka, miks ühe vana mooduli laadimine on halvem vastus, kui see paistab.

Kaks teed läbi ühe hosti

Pakett võib sellest hostist lahkuda kahel väga erineval viisil, ja erinevus otsustab, millised konksud seda näevad. Kui sihtkoht on väljaspool füüsilist porti ja kaader lülitatakse kahe silla pordi vahel, edastab host Etherneti kaadri; marsruutimiskoodi ei küsita ja ühtegi marsruuditud hüpet ei toimu. Kui sihtkoht on host ise või võrk, kuhu jõutakse tunneliliidese kaudu, marsruuditakse pakett ja IP-kihi konksud kehtivad tõesti. Hoia see hargnemine meeles, sest iga hilisem küsimus ahelate ja perekondade kohta tuleneb sellest, millise kahest teest kaader valib.

See eristus on kogu lugu reegli taga, mis ei loe midagi. Silla kaudu liikuv kaader veth9a1-st enp3s0-ni läbib silda, mitte IP-pinu, seega ip forward-ahel ei näe midagi, millega sobida. Vanemas näites olevad liidesenimed ei otsusta, milline tee sul on, ja seepärast on esimene samm vaadata topoloogiat, mitte reeglistikku.

Tunnel lisab kolmanda juhtumi, mis väärib nimetamist. TUN-seade toimetab IP-paketid hostile, seega need marsruuditakse ja läbivad tõesti IP-ahelaid, samas kui sillaga ühendatud TAP-seade toimetab kaadrid ja käitub nagu silla juhtum. Seadme tüüp, mitte toote nimi, otsustab.

Võrdle kahte perekonda, mis suudavad silla kaudu liikuvat kaadrit näha

Linux toetab kohalikku silla filtreerimist nftablesi bridge-perekonna kaudu ja ei vaja lennu ajal kaadrite kontrollimiseks ja kõrvaleheitmiseks ühtegi vana moodulit. Kerneli enda silla dokumentatsioon annab selle soovituse otse, mida tasub teada enne, kui otsingutulemus ütleb sul moodulit laadida.

Käsu nft kasutamine iptablesi asemel ei paiguta iseenesest reeglit õigesse perekonda. bridge-perekonnas deklareeritud ahel näeb kaadreid; ip, ip6 või inet-is deklareeritud ahel ei näe, ükskõik milline binaarfail selle lõi. Perekond on ahela omadus, mitte tööriista oma, mis selle trükkis.

Vana tee toimib teisiti, ja seetõttu tasub võrrelda, mitte harjumusest poolt valida. br_netfilter laadimine ja bridge-nf-call seadete lubamine paljastab silla kaudu liikuva IPv4- ja IPv6-liikluse taas IP-kihi konksude kaudu, nii et tavaline iptables-reegel saab sellega lõpuks sobida. Kaadrid ei muutu; muutub konksude hulk, mida need läbivad, mis tähendab, et igal olemasoleval hosti reeglil on nüüd uus publik.

Loe tegelik tee enne reegli lisamist

Kolm käsku teevad kindlaks, kus sa oled: millega sild on ühendatud, kas vana moodul on aktiivne ja millised ahelad on bridge-perekonnas juba olemas. Käivita need enne, kui midagi kirjutad, sest vastus otsustab, millist kahest disainist sa laiendad. Selle sammu vahelejätmine on viis, kuidas õige reegel satub ahelasse, mida miski ei läbi.

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

Väljund eristab juhtumeid puhtalt. Silla all loetletud pordid ütlevad, millised liidesed on lülitatud; tühi lsmod tulemus tähendab, et silla kaudu liikuvate kaadrite IP-kihil pole mingit nähtavust; olemasolev bridge-perekonna forward-ahel tähendab, et poliitika omanik on juba olemas ja sinu reegel kuulub sinna, mitte uude omaloodud ahelasse.

Seejärel lisa üks reegel, mida on lihtne tagasi lugeda, loenduriga ja ilma otsust muutmata, ja saada üks esinduslik voog läbi silla. Liikuv loendur tõestab, et kaader jõudis reeglini. See on kõik, mida see tõestab, seega järgi seda ka keelatud teega, sest poliitika, mis võtab vastu kõik, tekitab samuti liikuva loenduri.

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

Kus vana moodul käitumist muudab

Vana tee lubamine töötaval sillal ei ole neutraalne nähtavuse lisamise toiming. Reeglid, mis olid varem silla kaudu liikuva liikluse jaoks kättesaamatud, muutuvad kättesaadavaks, sealhulgas hosti reeglid, mis on kirjutatud teise liidese jaoks, ja ip forward-ahela vaikimisi drop-poliitika võib äkki kehtida kaadritele, mis varem läksid puutumata mööda. Hostil, mida hallatakse selle silla kaudu, on tulemuseks lukustus ilma konsoolita. See ei ole hüpoteetiline tõrkerežiim; see on tavaline tagajärg konksude hulga laiendamisele masinas, kuhu sa jõuad tee kaudu, mille sa just laiendasid.

Turvalisem järjekord on otsustada, milline perekond poliitikat omab, kirjutada reeglid sinna ja hoida sõltumatut taasteteed enne mis tahes sysctli muutmist. Kui kaks perekonda hoiavad mõlemad reegleid, dokumenteeri, milline on autoriteetne; kaks kattuvat poliitikat on viis, kuidas pakett võetakse vastu ühes kohas ja heidetakse kõrvale teises ilma ühegi loetava failita.

Isolatsioon ise vajab endiselt täielikku disaini. Ühe allika lubamine ühte sihtkohta tõestab ainult, et üks voog töötab, samas kui nõue on tavaliselt see, et VM ei pääseks oma naabritele ega hostile ligi. Keeldumisreeglite loendurid on tähtsamad kui lubamisreegli loendur, sest lubamise loendur on see, mille puhul sa juba eeldasid, et see liigub.

Lõpuks hoia hosti sisendi juhtum eraldi. Silla enda IP-le adresseeritud liiklus saabub input-i, mitte forward-i, ja forward-is olev reegel ei näe seda kunagi, ükskõik millise perekonna valid. Kolm juhtumit, kaks perekonda, üks õppetund: tee otsustab konksu ja konks otsustab, kas sinu reegel üldse olemas on.