Bakit hindi kailanman nakikita ng iyong iptables rule ang naka-bridge na VPN traffic

Dalawang virtual machine sa parehong host ang nakakarating sa LAN sa pamamagitan ng isang bridge, at ang panuntunang inilagay sa ip forward chain ay nagpapakita ng counter na hindi gumagalaw. Totoo ang mga frame, dumadaan ang trapiko, at wala lang talaga ang panuntunan sa landas nito. Ang paghahambing ng dalawang paraan ng paglalantad ng Linux sa trapikong dumadaan sa bridge ay nagpapaliwanag sa katahimikang ito, at nagpapaliwanag din ito kung bakit ang pag-load ng isang lumang module ay mas masamang sagot kaysa sa tila.

Dalawang landas sa isang host

Ang isang packet ay maaaring umalis sa host na ito sa dalawang lubos na magkaibang paraan, at ang pagkakaiba ang nagtatakda kung aling mga hook ang makakakita nito. Kung ang destinasyon ay lampas sa isang pisikal na port at ang frame ay inililipat sa pagitan ng dalawang port ng bridge, ipinapasa ng host ang isang Ethernet frame; hindi tinatanong ang routing code, at walang rutadong paglukso na nangyayari. Kung ang destinasyon ay ang host mismo, o isang network na naaabot sa pamamagitan ng tunnel interface, ang packet ay niruruta at tunay na gumagana ang mga hook ng IP layer. Tandaan ang sangandaan na ito, dahil ang bawat susunod na tanong tungkol sa mga chain at pamilya ay nagmumula sa kung alin sa dalawang landas ang tinatahak ng isang frame.

Ang pagkakaibang iyon ang buong kuwento sa likod ng isang panuntunang walang binibilang. Ang frame na dumadaan sa bridge mula veth9a1 patungong enp3s0 ay tumatawid sa bridge, hindi sa IP stack, kaya walang makikitang itutugma ang ip forward chain. Hindi tinutukoy ng mga pangalan ng interface sa mas lumang halimbawa kung aling landas mayroon ka, at iyon ang dahilan kung bakit ang unang hakbang ay tingnan ang topolohiya at hindi ang set ng mga patakaran.

Nagdaragdag ang tunnel ng ikatlong kaso na karapat-dapat pangalanan. Ang TUN device ay naghahatid ng mga IP packet sa host, kaya ang mga ito ay niruruta at talagang dumadaan sa mga IP chain, samantalang ang TAP device na nakakabit sa bridge ay naghahatid ng mga frame at kumikilos tulad ng kaso ng bridge. Ang uri ng device, hindi ang pangalan ng produkto, ang nagtatakda.

Ihambing ang dalawang pamilya na nakakakita ng frame na dumaraan sa bridge

Sinusuportahan ng Linux ang katutubong pag-filter ng bridge sa pamamagitan ng bridge family ng nftables, at hindi ito nangangailangan ng anumang lumang module upang suriin at itapon ang mga frame habang lumilipad. Ang dokumentasyon ng bridge ng kernel mismo ay direktang nagbibigay ng rekomendasyong iyon, na dapat malaman bago sabihin ng resulta ng paghahanap na mag-load ka ng module.

Ang paggamit ng nft command sa halip na iptables ay hindi naglalagay ng panuntunan sa tamang pamilya nang mag-isa. Ang chain na idineklara sa bridge family ay nakakakita ng mga frame; ang chain na idineklara sa ip, ip6 o inet ay hindi nakakakita, anuman ang binary na gumawa nito. Ang pamilya ay katangian ng chain, hindi ng kasangkapan na nag-type nito.

Iba ang paggana ng lumang landas, at iyon ang dahilan upang ihambing sa halip na pumili ng panig dahil sa ugali. Ang pag-load ng br_netfilter at pagpapagana ng mga setting ng bridge-nf-call ay muling naglalantad ng IPv4 at IPv6 na trapikong dumadaan sa bridge sa pamamagitan ng mga hook ng IP layer, kaya ang isang ordinaryong iptables rule ay sa wakas ay makakatugma nito. Hindi nagbabago ang mga frame; ang set ng mga hook na dinaraanan nila ay nagbabago, na nangangahulugang may bagong madla na ngayon ang bawat umiiral na panuntunan ng host.

Basahin ang epektibong landas bago magdagdag ng panuntunan

Tatlong utos ang nagtatakda kung nasaan ka: kung ano ang nakakabit sa bridge, kung aktibo ang lumang module, at kung anong mga chain ang umiiral na sa bridge family. Patakbuhin ang mga ito bago magsulat ng anuman, dahil ang sagot ang nagtatakda kung alin sa dalawang disenyo ang pinalalawak mo. Ang paglampas sa hakbang na ito ay kung paano napupunta ang isang tamang panuntunan sa isang chain na walang dumadaan.

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

Malinis na inihihiwalay ng output ang mga kaso. Ang mga port na nakalista sa ilalim ng bridge ay nagsasabi kung aling mga interface ang inililipat; ang walang laman na resulta ng lsmod ay nangangahulugang walang anumang visibility sa IP layer ng mga frame na dumaraan sa bridge; ang umiiral na forward chain ng bridge family ay nangangahulugang may may-ari na ng patakaran at doon nabibilang ang iyong panuntunan, hindi sa bago nitong sariling chain.

Pagkatapos, magdagdag ng isang panuntunan na madaling basahin pabalik, may counter at hindi binabago ang hatol, at magpadala ng isang kinatawang daloy sa bridge. Ang gumagalaw na counter ay nagpapatunay na naabot ng frame ang panuntunan. Iyon lang ang pinatutunayan nito, kaya sundan ito ng tinanggihang landas din, dahil ang patakarang tumatanggap ng lahat ay gumagawa rin ng gumagalaw na counter.

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

Saan binabago ng lumang module ang pag-uugali

Ang pagpapagana ng lumang landas sa isang tumatakbong bridge ay hindi neutral na gawain ng pagdaragdag ng visibility. Ang mga panuntunang dating hindi maabot para sa trapikong dumadaan sa bridge ay nagiging maabot, kabilang ang mga panuntunan ng host na isinulat para sa ibang interface, at ang default na drop na patakaran sa ip forward chain ay biglang maaaring magamit sa mga frame na dating dumaraan nang hindi nagagalaw. Sa isang host na pinamamahalaan sa pamamagitan ng bridge na iyon, ang resulta ay lockout na walang console. Hindi ito hipotetikal na mode ng pagpalya; ito ang ordinaryong bunga ng pagpapalawak ng set ng mga hook sa isang makina na naaabot mo sa landas na kalalaki mo lang na pinalawak.

Ang mas ligtas na pagkakasunod-sunod ay magpasya kung aling pamilya ang may-ari ng patakaran, isulat ang mga panuntunan doon, at panatilihin ang independiyenteng landas ng pagbawi bago baguhin ang anumang sysctl. Kung dalawang pamilya ang may mga panuntunan, idokumento kung alin ang may awtoridad; ang dalawang magkapatong na patakaran ang paraan kung paano tinatanggap ang isang packet sa isang lugar at itinatapon sa iba nang walang kahit isang file na mababasa.

Ang paghihiwalay mismo ay nangangailangan pa rin ng kumpletong disenyo. Ang pagpayag sa isang pinagmulan patungo sa isang destinasyon ay nagpapatunay lamang na gumagana ang isang daloy, samantalang ang pangangailangan ay karaniwang hindi maabot ng isang VM ang mga kapitbahay nito o ang host. Mas mahalaga ang mga counter sa mga panuntunan ng pagtanggi kaysa sa counter sa panuntunan ng pagtanggap, dahil ang counter ng pagtanggap ang siyang inaasahan mo nang gagalaw.

Sa huli, ihiwalay ang kaso ng input ng host. Ang trapikong naka-address sa sariling IP ng bridge ay dumarating sa input, hindi sa forward, at ang panuntunan sa forward ay hindi kailanman makakakita nito, anuman ang pamilyang piliin mo. Tatlong kaso, dalawang pamilya, isang aral: ang landas ang nagtatakda ng hook, at ang hook ang nagtatakda kung umiiral man ang iyong panuntunan.