Blokirajte jedan raspon odredišta za svaki VPN klijentski pool

Jedno pravilo može držati dopušteni VPN pool podalje od raspona odredišta, a da ne poremeti ništa drugo što gateway radi. Samo pravilo je kratko; dijelovi koji odlučuju hoće li raditi jesu hook u kojem živi i njegova pozicija u lancu. Ako ta dva pogriješite, dobivate firewall koji izgleda ispravno i ponaša se nedosljedno. Pođite od toga šta paket radi kada ga pravilo vidi.

Šta pravilo zapravo uparuje

Pravilo uparuje tri stvari odjednom: ulazni interfejs, prefiks izvora i prefiks odredišta. Sva tri moraju biti tačna prije nego što se primijeni drop, i to ga čini uskim. Čitati ga kao jedan izraz lakše je nego kao tri odvojene politike.

Uparivanje interfejsa razlikuje proslijeđeni klijentski promet od vlastitih veza gatewaya. Bez njega bi pravilo koje navodi samo pool izvora uticalo i na pakete koje gateway sam generiše 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 listu.

Zapišite tri vrijednosti prije nego što bilo šta mijenjate: naziv tunelskog interfejsa, pool koji server dodjeljuje i prefiks koji namjeravate odbiti. Greška u kucanju 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 pored pravila.

Hook odlučuje na koga se pravilo primjenjuje

netfilter lanac je prikačen na hook, i hook odlučuje koje pakete lanac uopće vidi. Hook forward vidi promet koji se rutira kroz gateway, 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 gatewayu, pa pravilo smješteno tamo upravlja pristupom njegovim vlastitim servisima, a ne tranzitom. Hook output vidi promet koji gateway sam stvara, što je suprotno od onoga što politika klijentskog poola treba. Nazivi lanaca su proizvoljne oznake koje je odabrao onaj ko je napisao ruleset, pa ne zaključujte hook iz naziva. Provjerite gdje je lanac prikačen prije nego što pretpostavite šta može upariti.

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

Postavite pravilo prije širokog prihvatanja

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

Umetnite pravilo prije prihvatanja umjesto da ga dodajete na kraj. Ako lanac već sadrži opće prihvatanje za tunelski interfejs, novo pravilo mora biti prije njega, inače je samo ukras. Provjerite rezultujući red, a ne datoteku koju ste uredili, jer ruleset 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 komanda parsira datoteku bez primjene, što hvata sintaksne greš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 uparivati ranije prihvatanje. Zato novi drop ponekad izgleda da radi za svježe veze, a ne radi ništa za onu koja se testira.

Pročitajte uparivanje stanja na vrhu lanca. Ako prihvata established i related promet prije vašeg pravila, svaki tok koji je već u toku nastavlja teći dok se ne zatvori. To je obično ponašanje koje želite za hitno pravilo, i zbunjujuće je kada očekujete trenutni prekid. Odlučite koji efekat želite prije postavljanja. Test koji ponovo 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 komanda pokazuje postoji li tok, a druga pokazuje nastavlja li rano pravilo stanja da ga prihvata. Obje su samo za čitanje i sigurne za izvođenje tokom incidenta.

Šta ovo pravilo nije

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

Svako od toga treba svoj mehanizam. Blokiranje domena mora razriješiti imena, što paketni filter ne radi. IPv6 promet treba vlastito uparivanje, jer izraz ip ne govori ništa o ip6 paketima. Ograničenje na nivou aplikacije pripada servisu ili autentificiranom proxyju, a ne uparivanju prefiksa. Upravo razdvajanje tih zahtjeva sprječava da se jedno usko pravilo pita za četiri posla.

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