Hvers vegna iptables-reglan þín sér aldrei VPN-umferð yfir brú

Tvær sýndarvélar á sama hýsli ná LAN-inu í gegnum brú, og regla sem sett er í ip forward-keðjuna sýnir teljara sem hreyfist aldrei. Rammarnir eru raunverulegir, umferðin fer í gegn, og reglan er einfaldlega ekki á leið hennar. Samanburður á þeim tveimur leiðum sem Linux sýnir umferð yfir brú á útskýrir þessa þögn, og hann útskýrir líka hvers vegna að hlaða einu gömlu mótúli er verri svar en það virðist.

Tvær leiðir í gegnum eitt hýsil

Pakki getur yfirgefið þetta hýsil á tvo mjög ólíka vegu, og munurinn ræður því hvaða krókar sjá hann. Ef áfangastaðurinn er handan við líkamlega tengi og ramminn er skipt milli tveggja brúartenga, sendir hýsillinn Ethernet-ramma áfram; ekki er leitað til leiðarstýrikóðans, og engin leiðarstýrð stökk eiga sér stað. Ef áfangastaðurinn er hýsillinn sjálfur, eða net sem næst í gegnum göngutengi, er pakkinn leiðarstýrður og krókar IP-lagsins eiga sannarlega við. Hafðu þessa klofning í huga, því sérhver síðari spurning um keðjur og fjölskyldur leiðir af því hvorri af tveimur leiðunum rammi fer.

Sá munur er öll saga reglu sem telur ekki neitt. Rammi yfir brú frá veth9a1 til enp3s0 fer yfir brúna, ekki IP-stakkinn, svo ip forward-keðja sér ekkert til að passa við. Tengjanöfn í eldra dæmi ráða ekki hvorri leið þú hefur, og þess vegna er fyrsta skrefið að líta á topólógíuna frekar en reglusafnið.

Göng bæta við þriðja tilfellinu sem er þess virði að nefna. TUN-tæki skilar IP-pökkum til hýsilsins, svo þeir eru leiðarstýrðir og fara sannarlega í gegnum IP-keðjur, á meðan TAP-tæki sem er tengt við brú skilar römmum og hagar sér eins og brúartilfellið. Tækjategundin, ekki vörumerkið, ræður.

Berðu saman fjölskyldurnar tvær sem geta séð ramma yfir brú

Linux styður innbyggða brúarsíun í gegnum bridge-fjölskyldu nftables, og það þarf enga gamla mótúla til að skoða og sleppa römmum á ferðinni. Brúarskjöl kjarnans sjálfs gefa þá tillögu beint, sem er þess virði að vita áður en leitarniðurstaða segir þér að hlaða mótúli.

Notkun nft-skipunarinnar í stað iptables setur ekki, eitt sér, reglu í réttu fjölskylduna. Keðja sem er skilgreind í bridge-fjölskyldunni sér ramma; keðja sem er skilgreind í ip, ip6 eða inet sér þá ekki, sama hvaða tvíundaskrá bjó hana til. Fjölskyldan er eiginleiki keðjunnar, ekki tólsins sem sló hana inn.

Gamla leiðin virkar öðruvísi, og þess vegna á að bera saman frekar en að velja hlið af vana. Að hlaða br_netfilter og virkja bridge-nf-call stillingarnar sýnir aftur IPv4- og IPv6-umferð yfir brú í gegnum króka IP-lagsins, svo venjuleg iptables-regla geti loksins passað við hana. Rammarnir breytast ekki; safnið af krókum sem þeir fara í gegnum breytist, sem þýðir að sérhver fyrirliggjandi hýslisregla hefur nú nýjan áheyrendahóp.

Lestu virku leiðina áður en þú bætir við reglu

Þrjár skipanir staðfesta hvar þú ert: við hvað brúin er tengd, hvort gamli mótullinn sé virkur, og hvaða keðjur eru þegar í bridge-fjölskyldunni. Keyrðu þær áður en þú skrifar nokkuð, því svarið ræður hvorri af tveimur hönnununum þú ert að útvíkka. Að sleppa þessu skrefi er leiðin sem rétt regla endar í keðju sem ekkert fer í gegnum.

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

Úttakið aðgreinir tilfellin skýrt. Tengi sem eru skráð undir brúnni segja þér hvaða tengi eru skipt; tómt lsmod-niðurstaða þýðir enga sýnileika á IP-laginu á römmum yfir brú; fyrirliggjandi forward-keðja bridge-fjölskyldunnar þýðir að stefnueigandi er þegar til og að reglan þín á þangað frekar en í nýja keðju fyrir sig.

Bættu síðan við einni reglu sem er auðlesin aftur, með teljara og án þess að breyta úrskurðinum, og sendu eitt fulltrúaflæði í gegnum brúna. Teljari sem hreyfist sannar að ramminn hafi náð reglunni. Það er allt sem hann sannar, svo fylgdu honum eftir með leyfislausu leiðinni líka, því stefna sem samþykkir allt framleiðir líka hreyfanlegan teljara.

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

Hvar gamli mótullinn breytir hegðun

Að virkja gömlu leiðina á brú í notkun er ekki hlutlaus athöfn að bæta við sýnileika. Reglur sem áður voru óaðgengilegar fyrir umferð yfir brú verða aðgengilegar, þar á meðal hýslisreglur skrifaðar fyrir annað tengi, og sjálfgefin drop-stefna í ip forward-keðjunni getur skyndilega átt við ramma sem áður fóru ósnortnir í gegn. Á hýsli sem er stýrt í gegnum þá brú er niðurstaðan lokun án stjórnborðs. Þetta er ekki ímyndað bilunarmynstur; þetta er venjuleg afleiðing af að útvíkka safn króka á vél sem þú nærð í gegnum leiðina sem þú varst að útvíkka.

Öruggari röðin er að ákveða hvaða fjölskylda á stefnuna, skrifa reglurnar þar, og halda óháðri endurheimtarleið áður en einhverju sysctl er breytt. Ef tvær fjölskyldur halda báðar reglum, skjalfestu hvor er valdber; tvær stefnur sem skarast eru leiðin sem pakki er samþykktur á einum stað og látinn falla á öðrum án þess að ein skrá sé til að lesa.

Einangrunin sjálf þarf enn heildarhönnun. Að leyfa einni uppsprettu til eins áfangastaðar sannar aðeins að eitt flæði virki, en krafan er yfirleitt sú að VM geti ekki náð til nágranna sinna eða hýsilsins. Teljarar á synjunarreglunum skipta meira máli en teljarinn á samþykktarreglunni, því samþykktarteljarinn er sá sem þú bjóst þegar við að myndi hreyfast.

Að lokum, haltu hýslisinntakstilfellinu aðskildu. Umferð sem er beint að eigin IP brúarinnar kemur á input, ekki forward, og regla í forward mun aldrei sjá hana, sama hvaða fjölskyldu þú velur. Þrjú tilfelli, tvær fjölskyldur, ein lexía: leiðin ræður króknum, og krókurinn ræður því hvort reglan þín er yfirleitt til.