Pse rregulli juaj i iptables nuk e sheh kurrë trafikun VPN përmes urës

Dy makina virtuale në të njëjtin host arrijnë LAN-in përmes një ure, dhe një rregull i vendosur në zinxhirin ip forward tregon një numërues që nuk lëviz kurrë. Kornizat janë reale, trafiku po kalon, dhe rregulli thjesht nuk është në rrugën e tij. Krahasimi i dy mënyrave se si Linux e shfaq trafikun përmes urës shpjegon këtë heshtje, dhe shpjegon gjithashtu pse ngarkimi i një moduli të vjetër është një përgjigje më e keqe sesa duket.

Dy rrugë përmes një hosti

Një paketë mund ta lërë këtë host në dy mënyra shumë të ndryshme, dhe ndryshimi vendos cilat grepa do ta shohin. Nëse destinacioni është përtej një porte fizike dhe korniza komutohet midis dy porteve të urës, hosti përcjell një kornizë Ethernet; kodi i rrugëtimit nuk konsultohet, dhe nuk ndodh asnjë hap i rrugëtuar. Nëse destinacioni është vetë hosti, ose një rrjet i arritshëm përmes një ndërfaqeje tuneli, paketa rrugëtohet dhe grepat e shtresës IP vërtet zbatohen. Mbajeni këtë degëzim në mendje, sepse çdo pyetje e mëvonshme për zinxhirët dhe familjet rrjedh nga ajo se cilën nga dy rrugët zgjedh një kornizë.

Ai dallim është e gjithë historia pas një rregulli që nuk numëron asgjë. Një kornizë përmes urës nga veth9a1 në enp3s0 kalon urën, jo pirgun IP, kështu që një zinxhir ip forward nuk sheh asgjë për të përputhur. Emrat e ndërfaqeve në një shembull më të vjetër nuk përcaktojnë cilën rrugë keni, dhe për këtë arsye hapi i parë është të shikoni topologjinë dhe jo grupin e rregullave.

Një tunel shton një rast të tretë që meriton një emër. Një pajisje TUN u dorëzon paketat IP hostit, kështu që ato rrugëtohen dhe vërtet kalojnë nëpër zinxhirë IP, ndërsa një pajisje TAP e lidhur me një urë dorëzon korniza dhe sillet si rasti i urës. Lloji i pajisjes, jo emri i produktit, vendos.

Krahasoni dy familjet që mund të shohin një kornizë përmes urës

Linux mbështet filtrimin vendas të urës përmes familjes bridge të nftables, dhe nuk ka nevojë për asnjë modul të vjetër për të inspektuar dhe hedhur poshtë kornizat gjatë fluturimit. Dokumentacioni i urës i vetë kernelit e jep atë rekomandim drejtpërdrejt, gjë që ia vlen ta dini përpara se një rezultat kërkimi t'ju thotë të ngarkoni një modul.

Përdorimi i komandës nft në vend të iptables nuk e vendos vetvetiu një rregull në familjen e duhur. Një zinxhir i deklaruar në familjen bridge sheh kornizat; një zinxhir i deklaruar në ip, ip6 ose inet nuk i sheh, pavarësisht se cili binar e krijoi. Familja është veti e zinxhirit, jo e mjetit që e shkruajti.

Rruga e vjetër funksionon ndryshe, dhe pikërisht për këtë ia vlen të krahasoni në vend që të zgjidhni anë nga zakoni. Ngarkimi i br_netfilter dhe aktivizimi i cilësimeve bridge-nf-call e shfaq përsëri trafikun IPv4 dhe IPv6 përmes urës nëpër grepat e shtresës IP, kështu që një rregull i zakonshëm iptables më në fund mund të përputhet me të. Kornizat nuk ndryshojnë; ndryshon grupi i grepa që ato kalojnë, që do të thotë se çdo rregull ekzistues i hostit ka tani një audiencë të re.

Lexoni rrugën efektive përpara se të shtoni një rregull

Tre komanda përcaktojnë ku jeni: me çfarë është lidhur ura, nëse moduli i vjetër është aktiv, dhe cilët zinxhirë ekzistojnë tashmë në familjen bridge. Ekzekutoni ato përpara se të shkruani gjë, sepse përgjigja vendos cilin nga dy modelet po zgjerohet. Kapërcimi i këtij hapi është mënyra se si një rregull i saktë përfundon në një zinxhir nëpër të cilin nuk kalon asgjë.

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

Dalja i ndan rastet pastër. Portet e listuara nën urë ju thonë cilat ndërfaqe komutohen; një rezultat bosh i lsmod do të thotë asnjë dukshmëri në shtresën IP të kornizave përmes urës; një zinxhir forward ekzistues i familjes bridge do të thotë që ka tashmë një pronar të politikës dhe që rregulli juaj i takon atje, jo një zinxhiri të ri të vetin.

Më pas shtoni një rregull të lehtë për t'u rilexuar, me një numërues dhe pa ndryshuar verdiktin, dhe kaloni një rrjedhë përfaqësuese përmes urës. Një numërues që lëviz provon që korniza arriti rregullin. Kjo është e gjitha që provon, prandaj vazhdoni edhe me rrugën e refuzuar, pasi një politikë që pranon gjithçka prodhon gjithashtu një numërues që lëviz.

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

Ku moduli i vjetër ndryshon sjelljen

Aktivizimi i rrugës së vjetër në një urë në punë nuk është akt neutral i shtimit të dukshmërisë. Rregullat që më parë ishin të paarritshme për trafikun përmes urës bëhen të arritshme, përfshirë rregulla hosti të shkruara për një ndërfaqe tjetër, dhe një politikë drop e parazgjedhur në zinxhirin ip forward mund të zbatohet befas për korniza që më parë kalonin të paprekura. Në një host që administrohet përmes asaj ure, rezultati është bllokim pa konsolë. Ky nuk është një regjim dështimi hipotetik; është pasoja e zakonshme e zgjerimit të një grupi grepa në një makinë që e arrini përmes rrugës që sapo zgjeruat.

Sekuenca më e sigurt është të vendosni cila familje zotëron politikën, t'i shkruani rregullat atje, dhe të mbani një rrugë rikuperimi të pavarur përpara se të ndryshoni çdo sysctl. Nëse dy familje mbajnë rregulla, dokumentoni cila është autoritare; dy politika që mbivendosen janë mënyra se si një paketë pranohet në një vend dhe hidhet poshtë në një tjetër pa asnjë skedar të vetëm për të lexuar.

Vetë izolimi ende kërkon një dizajn të plotë. Lejimi i një burimi drejt një destinacioni provon vetëm që një rrjedhë funksionon, ndërsa kërkesa zakonisht është që një VM të mos arrijë fqinjët e saj ose hostin. Numëruesit në rregullat e refuzimit kanë më shumë rëndësi sesa numëruesi në rregullin e pranimit, sepse numëruesi i pranimit është ai që ju tashmë prisnit të lëvizte.

Së fundi, mbajeni rastin e hyrjes së hostit veçmas. Trafiku i drejtuar në IP-në e vetë urës mbërrin në input, jo në forward, dhe një rregull në forward nuk do ta shohë kurrë, cilën familje të zgjidhni. Tre raste, dy familje, një mësim: rruga vendos grepin, dhe grepi vendos nëse rregulli juaj ekziston fare.