Wêrom't jo iptables-regel nea VPN-ferkear oer in brêge sjocht

Twa firtuele masines op deselde host berikke it LAN fia in brêge, en in regel yn 'e ip forward-keatling toant in teller dy't nea beweecht. De frames binne echt, it ferkear giet troch, en de regel sit gewoan net op syn paad. It ferlykjen fan 'e twa manieren wêrop't Linux ferkear oer in brêge sjen lit, ferklearret dy stilte, en it ferklearret ek wêrom't it laden fan ien âld module in minner antwurd is as it liket.

Twa paden troch ien host

In pakket kin dizze host op twa hiel ferskillende manieren ferlitte, en it ferskil beslút hokker heaken it sjogge. As de bestimming foarby in fysike poarte leit en it frame wurdt tusken twa brêgepoarten skakele, dan stjoert de host in Ethernet-frame troch; de routingkoade wurdt net rieplachte, en der bart gjin routearre hop. As de bestimming de host sels is, of in netwurk dat fia in tunnelinterface berikt wurdt, dan wurdt it pakket routearre en jilde de heaken fan 'e IP-laach wol. Hâld dy splitsing yn 't sin, want elke lettere fraach oer keatlingen en famyljes folget út hokker fan 'e twa in frame nimt.

Dat ûnderskie is it hiele ferhaal efter in regel dy't neat telt. In frame oer de brêge fan veth9a1 nei enp3s0 stekt de brêge oer, net de IP-stapel, dus in ip forward-keatling sjocht neat om te passen. Ynterface-nammen yn in âlder foarbyld beslute net hokker paad jo hawwe, en dêrom is de earste stap om nei de topology te sjen ynstee fan nei de regelsamling.

In tunnel foeget in tredde gefal ta dat it neamen wurdich is. In TUN-apparaat leveret IP-pakketten oan 'e host, dus dy wurde routearre en geane wol troch IP-keatlingen, wylst in TAP-apparaat dat oan in brêge fêst sit frames leveret en him gedraacht as it brêgegefal. It apparaattype, net de produktnamme, beslút.

Ferlykje de twa famyljes dy't in frame oer in brêge sjen kinne

Linux stipet native brêgefiltring fia de bridge-famylje fan nftables, en it hat gjin âld module nedich om frames yn 'e flecht te besjen en fuort te smiten. De brêgedokumintaasje fan 'e kernel sels jout dy oanbefelling direkt, wat it witten wurdich is foardat in sykresultaat jo fertelt in module te laden.

It brûken fan it nft-kommando ynstee fan iptables set op himsels gjin regel yn 'e goede famylje. In keatling dy't yn 'e bridge-famylje ferklearre is, sjocht frames; in keatling dy't yn ip, ip6 of inet ferklearre is, sjocht se net, hokker binaire it ek makke hat. De famylje is in eigenskip fan 'e keatling, net fan it ark dat him typt hat.

It âlde paad wurket oars, en dat is de reden om te ferlykjen ynstee fan gewoantegetrou in kant te kiezen. It laden fan br_netfilter en it oansetten fan 'e bridge-nf-call-ynstellings lit ferkear oer de brêge fan IPv4 en IPv6 wer fia de heaken fan 'e IP-laach sjen, sadat in gewoane iptables-regel it einlings passe kin. De frames feroarje net; de set heaken dêr't se trochhinne geane, feroaret, wat betsjut dat elke besteande hostregel no in nij publyk hat.

Lês it effektive paad foardat jo in regel tafoegje

Trije kommando's stelle fêst wêr't jo binne: wêr't de brêge oan fêst sit, oft it âlde module aktyf is, en hokker keatlingen al yn 'e bridge-famylje besteane. Rin se foardat jo wat skriuwe, want it antwurd beslút hokker fan 'e twa ûntwerpen jo útwreidzje. Dizze stap oerslaan is hoe't in korrekte regel yn in keatling bedarret dêr't neat trochhinne giet.

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

De útfier skiedt de gefallen skjin. Poarten dy't ûnder de brêge neamd wurde, fertelle jo hokker interfaces skakele wurde; in leech lsmod-resultaat betsjut hielendal gjin sichtberens op 'e IP-laach fan frames oer de brêge; in besteande forward-keatling fan 'e bridge-famylje betsjut dat der al in beliedseigner is en dat jo regel dêr heart ynstee fan yn in nije eigen keatling.

Tafoegje dan ien regel dy't maklik werom te lêzen is, mei in teller en sûnder it oardiel te feroarjen, en stjoer ien represintative stream troch de brêge. In teller dy't beweecht, bewisset dat it frame de regel berikt hat. Dat is alles wat it bewisset, dus folgje it ek mei it wegere paad, want in belied dat alles akseptearret, jout ek in beweegjende teller.

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

Wêr't it âlde module gedrach feroaret

It âlde paad oansette op in draaiende brêge is gjin neutrale die fan sichtberens tafoegje. Regels dy't earder ûnberikber wiene foar ferkear oer de brêge wurde berikber, ynklusyf hostregels skreaun foar in oare interface, en in standert drop-belied yn 'e ip forward-keatling kin ynienen jilde foar frames dy't earder ûnoantaaste trochgiene. Op in host dy't oer dy brêge beheard wurdt, is it resultaat in bûtensluting sûnder konsole. Dat is gjin hypotetyske foutmodus; it is it gewoane gefolch fan it útwreidzjen fan in set heaken op in masine dêr't jo by komme fia it paad dat jo krekt útwreide hawwe.

De feiliger folchoarder is om te besluten hokker famylje it belied besit, de regels dêr te skriuwen, en in ûnôfhinklik herstempel te hâlden foardat jo in sysctl feroarje. As twa famyljes beide regels hâlde, dokumintearje dan hokker autoritatyf is; twa oerlaapjende beliedsregels binne hoe't in pakket op ien plak akseptearre en op in oar plak wegere wurdt sûnder ien bestân om te lêzen.

Isolearring sels hat noch altyd in folslein ûntwerp nedich. Ien boarne nei ien bestimming tastean bewisset allinnich dat ien stream wurket, wylst de eask meastentiids is dat in VM syn buorlju of de host net berikke kin. Tellen op 'e wegeringsregels binne wichtiger as de teller op 'e akseptaasjeregel, want de akseptaasjeteller is dejinge dêr't jo al fan ferwachten dat er bewege soe.

Hâld ta beslút it host-ynfier gefal apart. Ferkear dat nei de eigen IP fan 'e brêge oanwiisd is, komt by input oan, net by forward, en in regel yn forward sil it nea sjen, hokker famylje jo ek kieze. Trije gefallen, twa famyljes, ien les: it paad beslút de heak, en de heak beslút oft jo regel uberhaupt bestiet.