Zabraňte tomu, aby na sebe klienti VPN v tunelu dosáhli

Dva klienti mohou oba otevřít jump host a přesto nemají co dělat, aby otevírali jeden druhého. Dosáhnout služby je rozhodnutí o předávání, kdežto dosáhnout partnera je rozhodnutí politiky, a většina stacků VPN je drží v oddělených objektech. Nic, co nastavíte pro první, nevynucuje druhé. Úkol tedy není přidat pravidlo, ale najít objekt, který na tomto serveru rozhoduje o provozu mezi partnery, napsat do něj zákaz a dokázat ho z klienta.

Trasa ke sdílené službě není povolení mezi partnery

Inzerování klientské podsítě říká partnerovi, jak poslat paket po drátě k adrese jiného klienta. Zda bude paket doručen, se rozhoduje potom, tím, co ho předává. Na linuxové bráně je to řetěz FORWARD; uvnitř daemonu v uživatelském prostoru je to vlastní tabulka relací tunelu. Trasa odpovídá na dosažitelnost a povolení nechává nedotčené.

Proto kontrola izolace, která čte jen trasy, nic nedokazuje. /24 lze poslat každému klientovi, zatímco každý paket mezi partnery se zahodí na háku předávání. Nebezpečný je opačný případ: žádné výslovné pravidlo, povolující výchozí nastavení a izolace, která existuje jen proto, že ji nikdo neotestoval.

Napište požadavek na jeden řádek, než otevřete terminál. Dosáhněte na blok služeb a jump host, na nic jiného v bloku klientů nedosahujte.

Zjistěte, kdo paket mezi partnery skutečně předává

Dvě chování serveru vypadají z klientské strany stejně a vyžadují různá pravidla. Buď jádro předá paket znovu ven rozhraním tunelu, nebo ho daemon zkopíruje mezi relacemi a jádro ho nikdy nevidí.

WireGuard patří do první skupiny: nemá přepínač mezi partnery, takže paket z 10.8.0.4 na 10.8.0.5 dorazí na wg0, narazí na hák předávání a je znovu směrován z wg0, když AllowedIPs pokrývá obě adresy. OpenVPN je druhá skupina, jakmile je v konfiguraci serveru client-to-client, protože tato direktiva předává paket mezi relacemi v uživatelském prostoru. Než něco napíšete, zkontrolujte v načtené konfiguraci tuto direktivu. Pravidlo jádra, které nikdy nevidí provoz, nelze odlišit od pravidla, které funguje, a právě tak skončí nasazení zcela bez izolace.

Čtěte efektivní konfiguraci, ne soubor, o kterém předpokládáte, že je načtený, protože distribuční balíčky přinášejí vlastní vkládání. Pokud předává daemon, zákaz patří do jeho vlastních ovládacích prvků pro jednotlivé klienty a hostitelský firewall filtruje jen provoz adresovaný hostiteli. Pokud předává jádro, hák předávání je jediné místo, na kterém záleží.

Směrovaná a překládaná nasazení potřebují ještě jednu kontrolu: zdroj, který vidí vzdálený klient, nemusí být ten, který čekáte. Pravidlo odpovídající klientské podsíti pak neodpovídá ničemu. Poznamenejte si adresu, která přežije překlad, než napíšete shodu, a dávejte přednost shodě dvojice rozhraní před hádáním adres NAT.

Dejte každé adrese identitu, kterou lze zrušit samostatně

Izolace se zhroutí, jakmile dvě zařízení sdílejí jeden údaj. Pravidlo navázané na tuto identitu je nemůže oddělit a zrušení ztraceného notebooku zruší celou skupinu. Certifikáty pro každé zařízení nebo klíče pro každého partnera drží zrušení lokálně a politiku čitelnou, protože každá adresa odpovídá právě jednomu člověku nebo stroji. Kde to návrh neumí, řekněte to v runbooku, místo abyste pravidlo popisovali jako jemné.

Přidělování adres musí souhlasit s politikou. Rezervujte blok pro služby, blok pro klienty a rozdávejte klientské adresy z fondu, který ovládáte, ne z rozsahu pro prvního příchozího. Pokud server překládá nebo můstkuje, držte mapovací tabulku vedle konfigurace, protože právě ji další čtenář potřebuje k opětovnému odvození pravidla.

Umístěte zákaz tam, kde paket přechází tunel

Na bráně, která předává provoz WireGuard, případ pokrývají dvě pravidla: povolte blok služeb a pak zahoďte zbytek bloku klientů. Dvojice rozhraní je stejně důležitá jako adresy, protože shoda jen podle cíle zachytí i provoz přicházející z LAN. Načtěte je v tomto pořadí, aby se povolení vyhodnotilo první.

S nftables jde dvojice do existující tabulky inet filter, povolení první a zahození druhé. Obě shody připínají dvojici rozhraní i adresy.

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

Po načtení si řetěz přečtěte zpět, místo abyste věřili návratovému kódu, a potvrďte, že obě pravidla stojí v pořadí, které jste zamýšleli. Přidejte odpovídající pravidla ip6 pro fond IPv6, jinak je dvojice v4 na dual-stack tunelu jen dekorace. Pokud server už má povolující politiku předávání, přidejte zahození, místo abyste řetěz nahradili celý.

Když je na OpenVPN zapnuto client-to-client, tato pravidla předávání nikdy neodpovídají provozu mezi partnery a zákaz musí žít ve vlastních ovládacích prvcích daemonu. Pravidla jádra pro provoz adresovaný hostiteli ponechte, ale nepočítejte je jako ovládací prvek izolace.

Dokažte zákaz z klienta, ne ze serveru

Testování z brány nic nedokazuje, protože lokálně vytvořený provoz jde výstupní cestou a nikdy nepřekročí hák předávání. Použijte dva skutečné klienty: jeden, který má dosáhnout služby, jeden, který má být odmítnut. Nejprve spusťte případ povolení, aby si rozbitý tunel nepletli s fungující politikou.

Z povoleného klienta potvrďte, že služba odpovídá na svém portu. Ze stejného klienta zkuste adresu partnera a čekejte tiché zahození, ne odmítnutí:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

Zahozený paket a partner offline vypadají oba jako vypršení, takže než něco uzavřete, zkontrolujte čítače. Potvrďte, že čítač pravidla zahození roste, zatímco je partner prokazatelně dostupný. Zopakujte přes IPv6, kde chybějící pravidlo ip6 nechává zákaz v4 vypadat účinně. Zapište přijaté a odmítnuté výsledky do runbooku s datem, protože příští migrace pravidlo znovu odvodí.