Blokirajte jedan raspon odredišta za svaki VPN klijentski pool

Jedno pravilo može držati dopušteni VPN pool daleko od raspona odredišta, a da ne poremeti ništa drugo što pristupnik radi. Samo pravilo je kratko; dijelovi koji odlučuju hoće li raditi jesu hook u kojem živi i njegov položaj u lancu. Pogriješite li u ta dva, dobivate vatrozid koji izgleda ispravno i ponaša se nedosljedno. Pođite od onoga što paket radi kad ga pravilo vidi.

Što pravilo zapravo uspoređuje

Pravilo uspoređuje tri stvari odjednom: ulazno sučelje, prefiks izvora i prefiks odredišta. Sva tri moraju biti istinita prije nego se primijeni drop, i to ga čini uskim. Čitati ga kao jedan izraz lakše je nego kao tri odvojene politike.

Uspoređivanje sučelja razlikuje proslijeđeni klijentski promet od vlastitih veza pristupnika. Bez njega bi pravilo koje navodi samo pool izvora utjecalo i na pakete koje pristupnik sam stvara s te adrese, ako se to ikad dogodi. Prefiks izvora ograničava politiku na dopuštene klijente, a prefiks odredišta na jedan raspon. Čitajte pravilo kao presjek, a ne kao popis.

Zapišite tri vrijednosti prije nego što bilo što promijenite: naziv tunelskog sučelja, pool koji poslužitelj dijeli i prefiks koji namjeravate odbiti. Pogreška u tipkanju u bilo kojoj od njih daje pravilo koje se čisto parsira i ništa ne štiti. Držite te tri vrijednosti u zapisu o promjeni pokraj pravila.

Hook odlučuje na koga se pravilo primjenjuje

netfilter lanac pričvršćen je na hook, i hook odlučuje koje pakete lanac uopće vidi. Hook forward vidi promet koji se usmjerava kroz pristupnik, a to je promet od klijenta prema odredištu. Sve ostalo u lancu usmjereno je na drugu publiku.

Hook input vidi promet upućen samom pristupniku, pa pravilo smješteno tamo upravlja pristupom njegovim vlastitim uslugama, a ne tranzitom. Hook output vidi promet koji pristupnik sam stvara, što je suprotno od onoga što politika klijentskog poola treba. Nazivi lanaca proizvoljne su oznake koje je odabrao onaj tko je napisao skup pravila, pa ne zaključujte hook iz naziva. Provjerite gdje je lanac pričvršćen prije nego pretpostavite što može usporediti.

Čitanje priključka provjera je u jednom retku koja sprječava da pravilo sleti u lanac koji nikad ne vidi paket.

Postavite pravilo prije širokog prihvaćanja

Pravila se ocjenjuju po redu i prva presuda pobjeđuje. Široko prihvaćanje ranije u lancu završava ocjenjivanje za pakete koje uspoređuje, pa se drop dodan poslije za njih nikad ne izvršava. To pravilo reda cijeli je razlog zašto ispravno pravilo može nemati učinka.

Umetnite pravilo prije prihvaćanja umjesto da ga dodajete na kraj. Ako lanac već sadrži opće prihvaćanje za tunelsko sučelje, novo pravilo mora biti prije njega, inače je samo ukras. Provjerite rezultirajući red, a ne datoteku koju ste uredili, jer skup pravila sastavljen od nekoliko datoteka možda ne odgovara nijednoj pojedinačno. Zatim potvrdite testnim paketom iz poola.

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ća naredba parsira datoteku bez primjene, što hvata sintaksne pogreške prije nego postanu prekid. Primijenite s planom vraćanja, jer pogrešno pravilo u lancu forward može presjeći tunel preko kojeg radite.

Postojeći tokovi ne mare za vaše novo pravilo

conntrack zapis stvoren prije nego što je pravilo postojalo nastavlja se podudarati s ranijim prihvaćanjem. Zato novi drop ponekad izgleda da radi za svježe veze, a ne radi ništa za onu koja se testira.

Pročitajte uspoređivanje stanja na vrhu lanca. Ako prihvaća established i related promet prije vašeg pravila, svaki tok koji je već u tijeku nastavlja teći dok se ne zatvori. To je obično ponašanje koje želite za hitno pravilo, i zbunjujuće je kad očekujete trenutačni rez. Odlučite koji učinak želite prije postavljanja. Test koji ponovno koristi otvorenu vezu ispričat će vam pogrešnu priču.

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

Prva naredba pokazuje postoji li tok, a druga pokazuje nastavlja li rano pravilo stanja da ga prihvaća. Obje su samo za čitanje i sigurne za izvođenje tijekom incidenta.

Što ovo pravilo nije

Pravilo nije crna lista domena, IPv6 politika ili ograničenje na pojedinačni račun aplikacije.

Svako od toga treba vlastiti mehanizam. Blokiranje domena mora razriješiti imena, što paketni filtar ne radi. IPv6 promet treba vlastito uspoređivanje, jer izraz ip ne govori ništa o ip6 paketima. Ograničenje na razini aplikacije pripada usluzi ili autentificiranom proxyju, a ne uspoređivanju prefiksa. Upravo razdvajanje tih zahtjeva sprječava da se od jednog uskog pravila traži četiri posla.

Ugovor koji ovo pravilo isporučuje precizan je: promet iz dopuštenog poola prema jednom prefiksu odredišta odbija se, dok nepovezani promet pristupnika zadržava svoju postojeću politiku. Napišite tu rečenicu pokraj pravila i sljedeća osoba znat će čemu je služilo.