Blocați un interval de destinație pentru fiecare pool de clienți VPN

O regulă poate ține un pool VPN admis departe de un interval de destinație fără să deranjeze nimic altceva din ce face gateway-ul. Regula în sine este scurtă; părțile care decid dacă funcționează sunt cârligul în care trăiește și poziția ei în lanț. Dacă greșiți aceste două, obțineți un firewall care pare corect și se comportă inconsecvent. Începeți de la ce face pachetul când regula îl vede.

Ce compară de fapt regula

Regula compară trei lucruri simultan: o interfață de intrare, un prefix sursă și un prefix de destinație. Toate trei trebuie să fie adevărate înainte de a se aplica drop-ul, și asta o ține îngustă. Citirea ei ca o singură expresie este mai simplă decât ca trei politici separate.

Potrivirea interfeței este ceea ce distinge traficul clienților redirecționat de conexiunile proprii ale gateway-ului. Fără ea, o regulă care numește doar pool-ul sursă ar afecta și pachetele pe care gateway-ul le generează el însuși de la acea adresă, dacă se întâmplă vreodată. Prefixul sursă limitează politica la clienții admiși, iar prefixul de destinație o limitează la un singur interval. Citiți regula ca o intersecție și nu ca o listă.

Notați cele trei valori înainte de a edita ceva: numele interfeței tunelului, pool-ul pe care serverul îl distribuie și prefixul pe care intenționați să îl refuzați. O greșeală de tastare în oricare dintre ele produce o regulă care se analizează curat și nu protejează nimic. Păstrați cele trei valori în registrul de modificări lângă regulă.

Cârligul decide asupra cui se aplică regula

Un lanț netfilter este atașat unui cârlig, și cârligul decide ce pachete vede lanțul de fapt. Cârligul forward vede traficul rutat prin gateway, iar acesta este exact traficul de la client la destinație. Orice altceva din lanț vizează un alt public.

Cârligul input vede traficul adresat gateway-ului însuși, așa că o regulă plasată acolo guvernează accesul la propriile servicii și nu tranzitul. Cârligul output vede traficul pe care gateway-ul îl originează, ceea ce este opusul a ceea ce are nevoie o politică de pool de clienți. Numele lanțurilor sunt etichete arbitrare alese de cel care a scris setul de reguli, așa că nu deduceți cârligul din nume. Verificați unde este atașat lanțul înainte de a presupune ce poate compara.

Citirea atașării este o verificare de o linie care împiedică o regulă să ajungă într-un lanț care nu vede niciodată pachetul.

Plasați regula înaintea acceptării largi

Regulile sunt evaluate în ordine, iar primul verdict câștigă. O acceptare largă mai sus în lanț încheie evaluarea pentru pachetele pe care le potrivește, așa că un drop adăugat după aceea nu rulează niciodată pentru ele. Acea regulă de ordine este întregul motiv pentru care o regulă care pare corectă poate să nu aibă niciun efect.

Inserați regula înaintea acceptării în loc să o adăugați la final. Dacă lanțul conține deja o acceptare generală pentru interfața tunelului, noua regulă trebuie să o precedă, altfel este doar decorativă. Verificați ordinea rezultată, nu fișierul pe care l-ați editat, pentru că un set de reguli asamblat din mai multe fișiere poate să nu corespundă niciunuia. Apoi confirmați cu un pachet de test din pool.

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

A treia comandă analizează fișierul fără a-l aplica, ceea ce prinde erorile de sintaxă înainte de a deveni o întrerupere. Aplicați cu un plan de revenire, fiindcă o regulă greșită într-un lanț forward poate tăia tunelul pe care lucrați.

Fluxurile existente nu se sinchisesc de noua dumneavoastră regulă

O intrare conntrack creată înainte ca regula să existe continuă să corespundă acceptării anterioare. De aceea un drop nou pare uneori că funcționează pentru conexiuni noi și nu face nimic pentru cea care este testată.

Citiți potrivirea de stare din capul lanțului. Dacă acceptă trafic established și related înaintea regulii dumneavoastră, fiecare flux deja în curs continuă să curgă până se închide. De obicei acesta este comportamentul dorit pentru o regulă de urgență, și este derutant când așteptați o tăiere imediată. Decideți ce efect doriți înainte de implementare. Un test care refolosește o conexiune deschisă vă va spune o poveste greșită.

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

Prima comandă arată dacă există un flux, iar a doua arată dacă o regulă de stare timpurie îl mai acceptă. Ambele sunt doar de citire și sigure în timpul unui incident.

Ce nu este această regulă

Regula nu este o listă neagră de domenii, o politică IPv6 sau o restricție asupra unui cont individual de aplicație.

Fiecare dintre acestea are nevoie de propriul mecanism. Un blocaj de domeniu trebuie să rezolve nume, ceea ce un filtru de pachete nu face. Traficul IPv6 are nevoie de propria potrivire, pentru că o expresie ip nu spune nimic despre pachetele ip6. O restricție la nivel de aplicație aparține serviciului sau unui proxy autentificat, nu unei potriviri de prefix. Tocmai păstrarea separată a acestor cerințe împiedică o singură regulă îngustă să fie pusă să facă patru treburi.

Contractul pe care îl oferă această regulă este precis: traficul dintr-un pool admis către un prefix de destinație este refuzat, în timp ce traficul nelegat al gateway-ului își păstrează politica existentă. Scrieți acea propoziție lângă regulă, și următoarea persoană va ști pentru ce a fost.