Pse nftables nuk e sheh trafikun e OpenVPN midis klientëve
Trafiku midis palëve dorëzohet brenda procesit të VPN, prandaj numëruesit e përcjelljes nuk lëvizin kurrë. Për ta numëruar, duhet të zgjidhni midis rrugës së kernelit dhe rrugës së procesit.
Dy klientë në një server shkëmbejnë skedarë, transferimi ka sukses, dhe çdo rregull përcjelljeje që drejtoni te tuneli raporton zero paketa. Rregullat nuk janë prishur dhe zinxhiri nuk është në vend të gabuar. Kur përcjellja midis palëve është e aktivizuar, paketa dorëzohet brenda procesit të serverit dhe stiva e hostit nuk bëhet kurrë router, prandaj muri i zjarrit të kernelit nuk ka çfarë të numërojë. Kuptimi i kësaj ndarjeje vendos nëse e mbani shkurtesën apo e rindërtoni rrugën përmes kernelit.
Ndiqni një paketë përmes serverit
Në një tunel të rrugëzuar, daemoni i dorëzon paketën e dekriptuar të çdo klienti pajisjes së tunelit. Prej andej hosti e rrugëzon, grepi i përcjelljes ekzekutohet, dhe një rregull që përputhet me pajisjen e tunelit mund ta numërojë ose ta hedhë trafikun. Kjo është rruga që supozojnë shumica e shembujve të murit të zjarrit.
| Forwarding path | Who decides | What the host firewall sees |
|---|---|---|
| Kernel routing between clients | Host routing table and forward rules | Every inner packet, with interface names |
| Peer forwarding inside the server process | The VPN daemon's own peer table | Only the outer encrypted transport |
Shkurtesa e heq hostin nga mesi. Paketa e dekriptuar e një sesioni i dorëzohet një sesioni tjetër brenda daemonit, dhe paketa e brendshme nuk emetohet kurrë në pajisjen e tunelit dhe nuk rrugëzohet nga hosti. Trafiku i inkapsuluar prapë kalon ndërfaqen fizike, prandaj një kapje e jashtme duket e zënë ndërsa rregullat e brendshme heshtin. Një kapje e marrë në pajisjen e tunelit nuk tregon absolutisht asgjë, gjë që habit këdo që pret ta shohë transferimin atje. Kjo asimetri është mënyra më e shpejtë për ta njohur shkurtesën nga jashtë daemonit.
Testi me numërues që vendos cila rrugë u ekzekutua
Lidhni një numërues te rregulli që duhet të zbatohet, ekzekutoni një transferim midis dy klientëve që ai rregull duhet t'i bllokojë, dhe më pas lexoni numëruesin.
sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward
Nëse transferimi ka sukses dhe numëruesi mbetet në zero, kerneli nuk i ka trajtuar kurrë ato paketa, dhe asnjë redaktim i rregullave nuk e ndryshon këtë. Përsëritni të njëjtin test kundër një shërbimi në vetë serverin, sepse ai rrjedhë vërtet kalon përmes stivës së hostit dhe numëruesi i tij lëviz. Krahasimi i dy rezultateve është ai që jep përgjigjen.
Dy detaje parandalojnë një lexim të gabuar. Një emër ndërfaqeje i shkruar në një etiketë zinxhiri nuk filtron asgjë më vete, sepse përputhja ndodh në fushat e ndërfaqes brenda rregullave. Dhe një dizajn me urë i shtresës 2 sillet përsëri ndryshe: atje klientët ndajnë një domen transmetimi, prandaj zbulimi i palëve është i pritur dhe jo një defekt rrugëzimi.
Një komutator nuk është listë aksesi
Kjo është pjesa që kushton një pasdite. Përcjellja midis palëve është një cilësim i vetëm ndezur ose fikur, dhe sa kohë është ndezur daemoni është pika e vetme e përcjelljes. Muri i zjarrit i hostit nuk mund të shprehë kush mund të arrijë kë, dhe skedarët për klient nuk e kthejnë komutatorin në një matricë politikash.
Nëse ju nevojiten rregulla për çdo palë, zgjedhja është midis heqjes dorë nga shkurtesa dhe heqjes dorë nga muri i zjarrit i hostit si kontroll. Fikja e saj rikthen përcjelljen e kernelit, e cila kërkon përcjellje IP në server dhe rregulla të qarta për rrjedhat që dëshironi. Mbajtja ndezur do të thotë që politika jeton në konfigurimin e daemonit, që në praktikë është të gjitha palët ose asnjë.
Procese serveri të veçanta me pishinat e tyre të adresave dhe portat janë rruga e mesme e zbatueshme. Çdo proces mban saktësisht një vendim aksesi, prandaj dy grupe mund të kenë rregulla të ndryshme pa një matricë politikash. Hosti mund të rrugëzojë midis pishinave kur kjo është e synuar, dhe atëherë muri i zjarrit i sheh ato rrjedha sepse kalojnë përmes hostit. Kostoja janë porta shtesë, certifikata shtesë dhe një profil për grup.
Zgjedhja e pikës së përcjelljes
Zgjidhni përcjelljen e kernelit kur muri i zjarrit është motori i politikës, kur ju nevojitet regjistrim për çdo rrjedhë, ose kur kontabiliteti ka rëndësi. Kostoja është xhiroja përmes stivës së hostit dhe më shumë rregulla për t'u mirëmbajtur. Përfitimi është që çdo mjet ekzistues, nga numëruesit te eksportuesit e rrjedhave, e përshkruan përsëri trafikun. Në një server të vogël kjo kosto është e padukshme; në një rele të zënë nuk është.
Zgjidhni përcjelljen brenda procesit kur trafiku midis palëve është ose plotësisht i lejuar ose plotësisht i ndaluar dhe serveri është dimensionuar për këtë. Kostoja është që numëruesit, disiplinat e radhës dhe gjurmimi i lidhjeve nuk i përshkruajnë më rrjedhat e brendshme; kjo është e pranueshme vetëm nëse më vonë askush nuk mbështetet te ato.
Çfarëdo që të zgjidhni, shkruajeni pranë rregullave të murit të zjarrit. Një grup rregullash që duket se lejon trafikun midis palëve ndërsa daemoni vendos gjithsesi i jep drejtim të gabuar personit të ardhshëm që do të korrigjojë një transferim të dështuar. Kush lexon vetëm rregullat do të supozojë se kerneli është porta.
Çfarë të verifikohet përpara se të ndryshohen rregullat
Lexoni konfigurimin që serveri ka ngarkuar vërtet, jo skedarin që mbani mend se e keni redaktuar, dhe konfirmoni nëse opsioni i palëve është i pranishëm. Nëse e keni ndryshuar, sigurohuni që shërbimi u ringarkua dhe nuk rishkruajti vetëm një skedar në disk.
Pastaj përsëritni testin me një rrjedhë nga klienti te serveri për të provuar se rregulli përputhet qoftë edhe pak, dhe kontrolloni rrugët e shtyra, sepse një rrugë që mungon duket nga ana e klientit saktësisht si një bllokim i murit të zjarrit. Ndryshoni rendin e rregullave vetëm pasi të dini cila pikë përcjelljeje e zotëron vendimin.