Blokeeri igale VPN-i kliendikogumile üks sihtvahemik

Üks reegel suudab hoida lubatud VPN-i kogumi sihtvahemikust eemal, häirimata midagi muud, mida lüüs teeb. Reegel ise on lühike; selle toimimise otsustavad konks, milles see elab, ja selle asukoht ahelas. Nende kahega eksides saad tulemüüri, mis näeb õige välja ja käitub ebajärjekindlalt. Alusta sellest, mida pakett teeb, kui reegel seda näeb.

Mida reegel tegelikult sobitab

Reegel sobitab korraga kolme asja: sisendliidest, lähteprefiksit ja sihtprefiksit. Kõik kolm peavad olema tõesed enne, kui drop rakendub, ja just see hoiab selle kitsana. Seda on lihtsam lugeda ühe avaldisena kui kolme eraldi poliitikana.

Liidese sobivus eristab edasisaadetud kliendiliiklust lüüsi enda ühendustest. Ilma selleta mõjutaks reegel, mis nimetab ainult lähtekogumit, ka pakette, mida lüüs ise sellest aadressist genereerib, kui see kunagi juhtub. Lähteprefiks piirab poliitika lubatud klientidega ja sihtprefiks ühe vahemikuga. Loe reeglit lõikepunktina, mitte loendina.

Kirjuta kolm väärtust enne, kui midagi muudad: tunneliliidese nimi, kogum, mille server välja jagab, ja prefiks, mille kavatsed keelata. Trükiviga ükskõik millises neist annab reegli, mis parsitakse puhtalt ja ei kaitse midagi. Hoia need kolm väärtust muudatuse kirjes reegli kõrval.

Konks otsustab, kelle kohta reegel kehtib

netfilteri ahel on konksu külge kinnitatud ja konks otsustab, milliseid pakette ahel üldse näeb. Konks forward näeb liiklust, mis suunatakse läbi lüüsi, ja just see on liiklus kliendilt sihtkohta. Kõik muu ahelas on suunatud teisele publikule.

Konks input näeb liiklust, mis on adresseeritud lüüsile endale, seega seal asuv reegel reguleerib juurdepääsu selle enda teenustele, mitte transiiti. Konks output näeb liiklust, mille lüüs ise loob, mis on vastupidine sellele, mida kliendikogumi poliitika vajab. Ahelate nimed on meelevaldsed sildid, mille valis see, kes reeglistiku kirjutas, seega ära tuleta konksu nimest. Kontrolli, kuhu ahel on kinnitatud, enne kui eeldad, mida see sobitada suudab.

Kinnituse lugemine on üherealise kontroll, mis hoiab ära reegli sattumise ahelasse, mis ei näe paketti kunagi.

Paiguta reegel laia accepti ette

Reegleid hinnatakse järjekorras ja esimene otsus võidab. Lai accept varem ahelas lõpetab hindamise nende pakettide jaoks, mida see sobitab, seega hiljem lisatud drop ei käivitu nende jaoks kunagi. See järjestusreegel on kogu põhjus, miks õige välimusega reegel võib mõju mitte avaldada.

Sisesta reegel enne accepti, mitte ära lisa seda lõppu. Kui ahelas on juba tunneliliidese üldine accept, peab uus reegel olema selle ees, muidu on see ainult dekoratiivne. Kontrolli tulemuseks olevat järjekorda, mitte faili, mida muutsid, sest mitmest failist kokku pandud reeglistik ei pruugi ühegagi neist kattuda. Seejärel kinnita kogumist pärit testpaketiga.

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

Kolmas käsk parsib faili ilma seda rakendamata, mis püüab süntaksivead enne, kui neist saab katkestus. Rakenda tagasipöördumisplaaniga, sest vale reegel forward-ahelas võib lõigata tunnelit, mille kaudu töötad.

Olemasolevad vood ei hooli sinu uuest reeglist

Enne reegli olemasolu loodud conntrack-kirje jätkab varasema accepti sobitamist. Seetõttu näib uus drop mõnikord toimivat värskete ühenduste puhul ja mitte tegevat midagi selle puhul, mida testitakse.

Loe olekute sobivust ahela ülaosas. Kui see võtab vastu established ja related liiklust enne sinu reeglit, jätkab iga juba käimasolev voog voolamist, kuni sulgub. Tavaliselt on see käitumine, mida hädaolukorra reegli puhul tahad, ja see on segane, kui ootad kohest katkestust. Otsusta enne juurutamist, millist mõju tahad. Test, mis kasutab avatud ühendust uuesti, räägib sulle vale loo.

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

Esimene käsk näitab, kas voog on olemas, ja teine näitab, kas varajane olekureegel võtab seda endiselt vastu. Mõlemad on kirjutuskaitstud ja intsidendi ajal ohutud käivitada.

Mida see reegel ei ole

Reegel ei ole domeenide must nimekiri, IPv6 poliitika ega üksiku rakendusekonto piirang.

Kõik need vajavad oma mehhanismi. Domeeni blokeerimine peab nimesid lahendama, mida paketifilter ei tee. IPv6 liiklus vajab oma sobivust, sest avaldis ip ei ütle ip6 pakettide kohta midagi. Rakendustasandi piirang kuulub teenusele või autenditud puhverserverile, mitte prefiksi sobivusele. Nende nõuete lahus hoidmine hoiab ära selle, et ühelt kitsalt reeglilt nõutakse nelja tööd.

Leping, mille see reegel annab, on täpne: liiklus lubatud kogumist ühte sihtprefiksisse keelatakse, samal ajal kui seostamatu lüüsi liiklus säilitab oma kehtiva poliitika. Kirjuta see lause reegli kõrvale ja järgmine inimene teab, milleks see oli.