Bllokoni një interval destinacioni për çdo grup klientësh VPN

Një rregull mund ta mbajë një grup VPN të pranuar larg një intervali destinacioni pa shqetësuar asgjë tjetër që bën porta. Rregulli vetë është i shkurtër; pjesët që vendosin nëse funksionon janë hook-u ku jeton dhe pozicioni i tij në zinxhir. Nëse i gaboni këto dy, merrni një firewall që duket i saktë dhe sillet në mënyrë jo konsistente. Filloni nga ajo që bën paketa kur rregulli e sheh atë.

Çfarë përputh vërtet rregulli

Rregulli përputh tre gjëra njëherësh: një ndërfaqe hyrëse, një prefiks burimi dhe një prefiks destinacioni. Të tre duhet të jenë të vërteta përpara se të zbatohet drop-i, dhe kjo është ajo që e mban të ngushtë. Leximi i tij si një shprehje e vetme është më i lehtë sesa si tre politika të ndara.

Përputhja e ndërfaqes është ajo që dallon trafikun e klientëve të përcjellë nga lidhjet e vetë portës. Pa të, një rregull që përmend vetëm grupin e burimit do të prekte edhe paketat që porta vetë gjeneron nga ajo adresë, nëse ndonjëherë ndodh. Prefiksi i burimit e kufizon politikën tek klientët e pranuar, dhe prefiksi i destinacionit tek një interval i vetëm. Lexojeni rregullin si një kryqëzim dhe jo si një listë.

Shkruani tre vlerat përpara se të modifikoni çdo gjë: emrin e ndërfaqes së tunelit, grupin që shpërndan serveri dhe prefiksin që synoni të refuzoni. Një gabim shtypi në ndonjë prej tyre prodhon një rregull që analizohet pastër dhe nuk mbron asgjë. Mbani ato tre vlera në regjistrin e ndryshimeve pranë rregullit.

Hook-u vendos se kujt i zbatohet rregulli

Një zinxhir netfilter është i lidhur me një hook, dhe hook-u vendos cilat paketa zinxhiri sheh në të vërtetë. Hook-u forward sheh trafikun e rrugëzuar përmes portës, dhe ky është pikërisht trafiku nga klienti në destinacion. Çdo gjë tjetër në zinxhir është e drejtuar drejt një publiku tjetër.

Hook-u input sheh trafikun e adresuar drejt vetë portës, kështu që një rregull i vendosur atje rregullon aksesin në shërbimet e saj dhe jo tranzitin. Hook-u output sheh trafikun që porta vetë krijon, dhe ky është e kundërta e asaj që i duhet një politike grupi klientësh. Emrat e zinxhirëve janë etiketa arbitrare të zgjedhura nga ai që shkroi grupin e rregullave, prandaj mos e nxirrni hook-un nga emri. Kontrolloni ku është lidhur zinxhiri përpara se të supozoni çfarë mund të përputhë.

Leximi i lidhjes është një kontroll një rresht që parandalon që një rregull të përfundojë në një zinxhir që nuk e sheh kurrë paketën.

Vendoseni rregullin përpara accept-it të gjerë

Rregullat vlerësohen sipas radhës dhe vendimi i parë fiton. Një accept i gjerë më herët në zinxhir e përfundon vlerësimin për paketat që përputh, kështu që një drop i shtuar më pas nuk ekzekutohet kurrë për ato. Ai rregull radhe është e gjithë arsyeja pse një rregull që duket i saktë mund të mos ketë asnjë efekt.

Futni rregullin përpara accept-it në vend që ta shtoni në fund. Nëse zinxhiri përmban tashmë një accept të përgjithshëm për ndërfaqen e tunelit, rregulli i ri duhet t'i paraprijë atij, përndryshe është thjesht dekorativ. Kontrolloni radhën që rezulton dhe jo skedarin që modifikuat, sepse një grup rregullash i ndërtuar nga disa skedarë mund të mos përputhet me asnjë prej tyre. Më pas konfirmoni me një paketë testuese nga grupi.

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

Komanda e tretë e analizon skedarin pa e zbatuar, gjë që kap gabimet sintaksore përpara se të bëhen ndërprerje. Zbatojeni me një plan kthimi prapa, sepse një rregull i gabuar në një zinxhir forward mund të presë tunelin përmes të cilit punoni.

Rrjedhat ekzistuese nuk merren me rregullin tuaj të ri

Një hyrje conntrack e krijuar përpara se rregulli të ekzistonte vazhdon t'i përputhet accept-it të mëparshëm. Kjo është arsyeja pse një drop i ri ndonjëherë duket se funksionon për lidhje të reja dhe nuk bën asgjë për atë që po testohet.

Lexoni përputhjen e gjendjes në krye të zinxhirit. Nëse pranon trafik established dhe related përpara rregullit tuaj, çdo rrjedhë e nisur vazhdon të rrjedhë derisa të mbyllet. Zakonisht ky është sjellja që dëshironi për një rregull urgjence, dhe është konfuze kur prisni një prerje të menjëhershme. Vendosni çfarë efekti dëshironi përpara se ta vendosni. Një test që ripërdor një lidhje të hapur do t'ju tregojë një histori të gabuar.

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

Komanda e parë tregon nëse ekziston një rrjedhë, dhe e dyta nëse një rregull i hershëm gjendjeje vazhdon ta pranojë atë. Të dyja janë vetëm lexim dhe të sigurta për t'u ekzekutuar gjatë një incidenti.

Çfarë nuk është ky rregull

Rregulli nuk është një listë e zezë domenesh, një politikë IPv6 ose një kufizim mbi një llogari të vetme aplikacioni.

Secila prej tyre kërkon mekanizmin e vet. Një bllokim domeni duhet të zgjidhë emra, gjë që një filtër paketash nuk e bën. Trafiku IPv6 kërkon përputhjen e vet, sepse një shprehje ip nuk thotë asgjë për paketat ip6. Një kufizim në nivel aplikacioni i takon shërbimit ose një proxy të autentikuar, jo përputhjes së prefiksit. Pikërisht mbajtja e këtyre kërkesave të ndara parandalon që një rregull i ngushtë të kërkohet të bëjë katër punë.

Kontrata që ofron ky rregull është e saktë: trafiku nga një grup i pranuar drejt një prefiksi destinacioni refuzohet, ndërsa trafiku i palidhur i portës mban politikën e tij ekzistuese. Shkruajeni atë fjali pranë rregullit, dhe personi tjetër do të dijë për çfarë ishte.