Užblokuokite vieną paskirties diapazoną kiekvienam VPN klientų telkiniui

Viena taisyklė gali laikyti leidžiamą VPN telkinį atokiau nuo paskirties diapazono, netrukdydama nieko kito, ką daro šliuzas. Pati taisyklė trumpa; ar ji veiks, lemia kablys, kuriame ji gyvena, ir jos vieta grandinėje. Suklydus šiuose dviejuose, gaunasi ugniasienė, kuri atrodo teisinga ir elgiasi nenuosekliai. Pradėkite nuo to, ką daro paketas, kai taisyklė jį mato.

Ką taisyklė iš tikrųjų atitinka

Taisyklė vienu metu atitinka tris dalykus: įvesties sąsają, šaltinio prefiksą ir paskirties prefiksą. Visi trys turi būti teisingi, kad būtų pritaikytas drop, ir tai ją išlaiko siaurą. Skaityti ją kaip vieną išraišką lengviau nei kaip tris atskiras politikas.

Sąsajos atitikimas atskiria persiunčiamą klientų srautą nuo paties šliuzo jungčių. Be jo taisyklė, nurodanti tik šaltinio telkinį, paveiktų ir paketus, kuriuos pats šliuzas generuoja iš to adreso, jei taip kada nors nutinka. Šaltinio prefiksas apriboja politiką leidžiamiems klientams, o paskirties prefiksas – vienu diapazonu. Skaitykite taisyklę kaip sankirtą, o ne kaip sąrašą.

Užsirašykite tris reikšmes prieš ką nors redaguodami: tunelio sąsajos pavadinimą, telkinį, kurį dalija serveris, ir prefiksą, kurį ketinate atmesti. Rašybos klaida bet kurioje iš jų duoda taisyklę, kuri švariai išanalizuojama ir nieko neapsaugo. Laikykite šias tris reikšmes pakeitimų įraše šalia taisyklės.

Kablys nusprendžia, kam taisyklė taikoma

netfilter grandinė prijungiama prie kablio, ir kablys nusprendžia, kuriuos paketus grandinė apskritai mato. forward kablys mato srautą, maršrutizuojamą per šliuzą, ir būtent tai yra srautas nuo kliento iki paskirties. Visa kita grandinėje nukreipta į kitą auditoriją.

input kablys mato srautą, adresuotą pačiam šliuzui, todėl ten patalpinta taisyklė valdo prieigą prie jo paties paslaugų, o ne tranzitą. output kablys mato srautą, kurį šliuzas pats sukuria, ir tai yra priešingybė tam, ko reikia klientų telkinio politikai. Grandinių pavadinimai yra savavališkos etiketės, kurias pasirinko taisyklių rinkinio autorius, todėl ne spėkite kablio iš pavadinimo. Patikrinkite, kur grandinė prijungta, prieš manydami, ką ji gali atitikti.

Prijungimo perskaitymas yra vienos eilutės patikra, kuri neleidžia taisyklei atsidurti grandinėje, kuri niekada nemato paketo.

Padėkite taisyklę prieš platų accept

Taisyklės vertinamos iš eilės, ir pirmasis sprendimas laimi. Platus accept anksčiau grandinėje užbaigia vertinimą tiems paketams, kuriuos jis atitinka, todėl po jo pridėtas drop jiems niekada nevykdomas. Ši eilės taisyklė yra visa priežastis, kodėl teisingai atrodanti taisyklė gali neturėti poveikio.

Įterpkite taisyklę prieš accept, o ne pridėkite ją gale. Jei grandinėje jau yra bendras accept tunelio sąsajai, nauja taisyklė turi būti prieš jį, kitaip ji tėra puošmena. Tikrinkite gautą eilę, o ne failą, kurį redagavote, nes iš kelių failų surinktas taisyklių rinkinys gali neatitikti nė vieno jų. Tada patvirtinkite bandomuoju paketu iš telkinio.

sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf

Trečioji komanda analizuoja failą jo nepritaikydama, ir tai pagauna sintaksės klaidas, kol jos netapo sutrikimu. Taikykite su atsaukimo planu, nes klaidinga taisyklė forward grandinėje gali nutraukti tunelį, per kurį dirbate.

Esami srautai nekreipia dėmesio į jūsų naują taisyklę

conntrack įrašas, sukurtas iki taisyklės atsiradimo, toliau atitinka ankstesnį accept. Štai kodėl naujas drop kartais atrodo veikiantis naujiems ryšiams ir nieko nedarantis tam, kuris testuojamas.

Perskaitykite būsenos atitikimą grandinės viršuje. Jei jis priima established ir related srautą prieš jūsų taisyklę, kiekvienas jau vykstantis srautas teka toliau, kol užsidaro. Paprastai tai yra elgsena, kurios norite avarinei taisyklei, ir ji klaidina, kai tikitės nedelsiant nutraukti. Nuspręskite, kokio poveikio norite, prieš diegdami. Testas, kuris pakartotinai naudoja atvirą ryšį, papasakos neteisingą istoriją.

sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'

Pirmoji komanda rodo, ar srautas egzistuoja, o antroji – ar ankstyva būsenos taisyklė jį vis dar priima. Abi yra tik skaitomos ir saugios vykdyti incidento metu.

Kas ši taisyklė nėra

Taisyklė nėra domenų juodasis sąrašas, IPv6 politika ar apribojimas vienai programos paskyrai.

Kiekvienam iš jų reikia savo mechanizmo. Domeno blokavimas turi išspręsti vardus, ko paketų filtras nedaro. IPv6 srautui reikia savo atitikimo, nes ip išraiška nieko nesako apie ip6 paketus. Programos lygmens apribojimas priklauso paslaugai ar autentifikuotam tarpiniam serveriui, o ne prefikso atitikimui. Būtent šių reikalavimų atskyrimas neleidžia vienai siaurai taisyklei primesti keturių darbų.

Sutartis, kurią ši taisyklė suteikia, yra tiksli: srautas iš leidžiamo telkinio į vieną paskirties prefiksą atmetamas, o nesusijęs šliuzo srautas išlaiko savo galiojančią politiką. Užrašykite šį sakinį šalia taisyklės, ir kitas žmogus žinos, kam ji buvo.