Zablokujte jeden cílový rozsah pro každý klientský fond VPN
Jedno pravidlo nftables dokáže zamítnout cílový prefix pro povolený fond VPN, aniž by se dotklo vlastního provozu brány. Sladťte háček a pozici.
Jedno pravidlo dokáže udržet povolený fond VPN mimo cílový rozsah, aniž by narušilo cokoli dalšího, co brána dělá. Pravidlo samo je krátké; o tom, zda bude fungovat, rozhoduje háček, ve kterém žije, a jeho pozice v řetězci. Když se v těchto dvou věcech spletete, dostanete firewall, který vypadá správně a chová se nekonzistentně. Začněte tím, co paket dělá, když ho pravidlo vidí.
Co pravidlo skutečně porovnává
Pravidlo porovnává tři věci najednou: vstupní rozhraní, zdrojový prefix a cílový prefix. Všechny tři musí platit, než se drop použije, a právě to ho drží úzké. Číst ho jako jeden výraz je snazší než jako tři oddělené politiky.
Porovnání rozhraní odlišuje přeposílaný klientský provoz od vlastních spojení brány. Bez něj by pravidlo, které uvádí jen zdrojový fond, ovlivnilo i pakety, které brána sama vytváří z této adresy, pokud k tomu někdy dojde. Zdrojový prefix omezuje politiku na povolené klienty a cílový prefix na jeden rozsah. Čtěte pravidlo jako průnik, ne jako seznam.
Než cokoli upravíte, zapište si tři hodnoty: název tunelového rozhraní, fond, který server přiděluje, a prefix, který chcete zamítnout. Překlep v kterékoli z nich vytvoří pravidlo, které se čistě naparsuje a nic nechrání. Tyto tři hodnoty držte v záznamu o změně vedle pravidla.
Háček rozhoduje, na koho se pravidlo vztahuje
Řetězec netfilter je připojen k háčku a háček rozhoduje, které pakety řetězec vůbec vidí. Háček forward vidí provoz směrovaný přes bránu, což je provoz od klienta k cíli. Všechno ostatní v řetězci míří na jiné publikum.
Háček input vidí provoz adresovaný samotné bráně, takže pravidlo umístěné tam řídí přístup k jejím vlastním službám, nikoli tranzit. Háček output vidí provoz, který brána sama vytváří, což je opak toho, co politika klientského fondu potřebuje. Názvy řetězců jsou libovolné štítky, které zvolil ten, kdo ruleset napsal, takže háček z názvu neodvozujte. Ověřte, kam je řetězec připojen, než budete předpokládat, co může porovnat.
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
Přečtení připojení je jednoradová kontrola, která zabrání tomu, aby pravidlo skončilo v řetězci, který paket nikdy nevidí.
Umístěte pravidlo před široké přijetí
Pravidla se vyhodnocují v pořadí a první verdikt vyhrává. Široké přijetí dříve v řetězci ukončí vyhodnocení pro pakety, které porovná, takže drop přidaný potom se pro ně nikdy nespustí. Toto pravidlo pořadí je celý důvod, proč správně vypadající pravidlo nemusí mít žádný účinek.
Vložte pravidlo před přijetí, místo abyste ho přidávali na konec. Pokud řetězec již obsahuje obecné přijetí pro tunelové rozhraní, musí nové pravidlo stát před ním, jinak je jen dekorativní. Kontrolujte výsledné pořadí, ne soubor, který jste upravili, protože ruleset složený z několika souborů nemusí odpovídat žádnému z nich. Poté to potvrďte testovacím paketem z fondu.
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.confTřetí příkaz soubor naparsuje bez použití, což zachytí syntaktické chyby dříve, než se stanou výpadkem. Aplikujte s plánem návratu, protože chybné pravidlo v řetězci forward může přerušit tunel, přes který pracujete.
Existující toky se o vaše nové pravidlo nestarají
Záznam conntrack vytvořený předtím, než pravidlo existovalo, nadále odpovídá dřívějšímu přijetí. Proto nový drop někdy vypadá, že funguje pro nová spojení, a nedělá nic pro to, které se testuje.
Přečtěte si porovnání stavu na začátku řetězce. Pokud přijímá provoz established a related před vaším pravidlem, každý tok, který už probíhá, pokračuje, dokud se nezavře. To je obvykle chování, které u nouzového pravidla chcete, a je matoucí, když očekáváte okamžité přerušení. Před nasazením se rozhodněte, jaký účinek chcete. Test, který znovu použije otevřené spojení, vám řekne špatný příběh.
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'První příkaz ukazuje, zda tok existuje, a druhý ukazuje, zda ho časné pravidlo stavu stále přijímá. Oba jsou jen pro čtení a bezpečné během incidentu.
Co toto pravidlo není
Pravidlo není černá listina domén, politika IPv6 ani omezení jednotlivého účtu aplikace.
Každé z toho potřebuje vlastní mechanismus. Blokování domény musí překládat názvy, což paketový filtr nedělá. Provoz IPv6 potřebuje vlastní porovnání, protože výraz ip nic neříká o paketech ip6. Omezení na úrovni aplikace patří službě nebo autentizované proxy, ne porovnání prefixu. Právě oddělení těchto požadavků brání tomu, aby se po jednom úzkém pravidle chtěly čtyři práce.
Smlouva, kterou toto pravidlo plní, je přesná: provoz z povoleného fondu na jeden cílový prefix je zamítnut, zatímco nesouvisející provoz brány si zachovává svou stávající politiku. Napište tu větu vedle pravidla a další člověk bude vědět, k čemu bylo.