S relativně novou VPN jménem WireGuard, jste se již na Rootu mohli podrobně seznámit. Je asi zbytečné popisovat všechny její výhody, zmíním proto jen ty relevantní pro tento článek. VPN minimálně zatěžuje systém, kde je používána a proto je možné udržovat současně desítky tunelů bez znatelné ztráty výkonu.
Je v zásadě symetrická a pokud se komunikující strany vidí přímo, není rozdíl mezi serverem a klientem. V neposlední řadě je pak „vytočení“ VPN naprosto bleskurychlé. V podstatě se chová stejně jako tunely IPsec, jen bez otravného boje s množinou povolených šifer a různými vzájemně nekompatibilními rozšířeními jednotlivých výrobců.
WireGuard bývá srovnáván s OpenVPN, někdy poměrně nekriticky. OpenVPN sice nemá takovou propustnost, ale zase se daleko více chová jako VPN: umožňuje poslat na klienta routy, DNS servery, prostě centrálně ovlivňovat konfiguraci, takže změna topologie sítě neznamená, že je potřeba každého klienta rekonfigurovat. Čistý WireGuard nic takového nenabízí, proto vnikají různé nadstavby, které obalují samotný protokol WireGuard dalšími službami.
Minimální režie nepoužívaných spojení přes WireGuard umožňuje vytvoření mesh sítě, kde komunikuje každý s každým, jen šifrovaně. Pokud mezi komunikujícími stranami nejsou stavové firewally, vydrží spojení v podstatě neomezeně dlouho otevřené. Případně je možné použít keepalive, který stavové firewally přesvědčí, že spojení je stále potřeba.
Stavět síť, kde komunikuje každý s každým, je nemyslitelné bez automatizace, která zajistí výměnu šifrovacích klíčů a routovacích pravidel mezi členy sítě. Existují komerční i cloudové projekty, které problém řeší. Asi nejznámější jsou Tailscale (i o něm byl na Rootu již článek) a Zerotier. Já ale preferuji řešení, které lze provozovat na vlastní infrastruktuře.
Tím se dostáváme ke dvěma projektům, které dneska představím. Netbird (donedávna používal jméno Wiretrustee) a Netmaker. Mě při testování zaujal více Netbird, ale u vás to může být jinak. Rovnou prozradím, že pokud má být součástí sítě zařízení, kde nelze spustit klientskou aplikaci a přesto potřebujete sdílet jeho šifrovací klíče (např. MikroTik), bude jedinou volbou Netmaker. Druhou doménou Netmakeru je Kubernetes.
Naopak: pokud chcete používat PresharedKey bude pro vás jedinou volbou Netbird. Ale pokud budete tento článek číst ve vzdálenější budoucnosti, jistě se to změní. Mám ho rozepsaný asi tři měsíce a mezitím udělaly oba projekty slušný kus práce.
Netbird
U nástroje Netbird musíte mít na každém komunikujícím uzlu sítě klienta, kterému se říká agent. Klient vygeneruje privátní klíč pro daný uzel (a ten tedy nikdy klienta neopustí) a jeho veřejnou část poskytne serveru. Na oplátku od něj získá konfiguraci, podle které potom nakonfiguruje systémový WireGuard. Že je zde použit systémový (jaderný) WireGuard není samozřejmostí, například zmíněný Tailscale používá sice stejný protokol, ale jeho implementaci v uživatelském prostoru.
Současně agent ověří, jestli je možná přímá komunikace s ostatními uzly a pokud není, spustí s pomocí STUN a WebRTC proxy, která pakety zašifrované WireGuardem směruje k ostatním uzlům sítě. Síť se snaží být maximálně nezávislá na prostřednících, aby mohly komunikovat všechny uzly, které se v daném okamžiku vidí. Případný výpadek serveru znamená jen, že není možné měnit topologii sítě, ale ne, že by se všechna spojení rozpadla.
Základní nastavení je, že každý uzel může komunikovat s každým uzlem. Server umožňuje vytváření skupin klientů/uzlů sítě, které spolu mohou komunikovat. To ovlivňuje které veřejné klíče jsou na klienty distribuovány. Klient dostane informace pouze o protistranách, se kterými má společné skupiny.
Propojení sítí pomocí Netbird.io
Některé uzly je možné povýšit na routery a takové uzly potom mohou do mesh sítě propagovat adresní rozsah, do kterého jsou připojeny a volitelně NATovat pakety pocházející z mesh sítě za svou IP adresu, aby například ostatní stanice v síti nemusely mít routu do mesh sítě přes IP adresu daného uzlu. Případně mohou pro celou mesh síť zajišťovat konektivitu z a do internetu.
Nebudu popisovat, jak konkrétně probíhá instalace, není to nijak složité. Na straně serveru si ve většině případů spustíte čtyři dockerovské kontejnery: samotný management server, GUI pro jeho administraci, službu umožňující najít komunikující protistrany, když se vidí přímo, a STUN/TURN server pro ty, kdo se kvůli NATu přímo nevidí. Jediné, co vás může překvapit je, že server neudržuje žádnou databázi uživatelů, kompletně závisí na externím IdP (identity provider).
Dalším krokem je instalace klienta (agenta) na všechny komunikující uzly. Klient se se serverem může spojit přes token (setup key), který se vygeneruje v UI serveru, což se hodí především pro automatizované instalace. Token má nastaveno, pro kolik klientů smí být použit. Druhou možností je spuštění internetového prohlížeče a klient je pak spárován se serverem pouhým přihlášením uživatele k serveru.
Netmaker
Instalace nástroje Netmaker opět nepřináší žádná překvapení. Dodává se ve formě dockerovských kontejnerů, důvěřivější admini mohou celou instalaci provést dodaným shellovým skriptem. Databázi uživatelů má vlastní, ale opět umožňuje použití externího poskytovatele identity. Protože se primárně orientuje na nasazení v kontejnerech, probíhá připojení klientů do mesh sítě pouze přes token.
Konfigurace je složitější, protože je možné nastavit pro každou mesh síť daleko více voleb. Většina instalací ale asi vystačí s výchozími hodnotami. Přijemné je, že Netmaker podporuje jak IPv4 mesh, tak IPv6 mesh, byť IPv6 asi nebude první volbou pro mesh stavěný na privátních IP adresách.
Architektura sítě s nástrojem Netmaker
Zajímavou funkcionalitou je možnost zapojit do meshe i klienty, na kterých není možné spustit klienta Netmaker. To zahrnuje třeba routery firmy MikroTik. K připojení takových klientů slouží takzvaná Ingres Gateway. Server pro takového klienta vygeneruje wireguardový konfigurační soubor, který obsahuje parametry připojení k Ingres Gateway. V rámci meshe pak šíří routy potřebné pro komunikaci s oním klientem. Při generování konfigurace pro externího klienta server generuje i jeho soukromý klíč, což znamená, že jej samozřejmě zná. U běžných uzlů sítě s nainstalovaným nativním klientem je soukromý klíč generován přímo na daném uzlu a server jej nezná.
Kromě připojení externích klientů lze Ingress Gateway použít i pro běžný příchozí provoz, typicky DNAT portů na různé uzly meshe. Pro odchozí provoz se použijí Egress Gateway. Jedná se o klasické NATy, které maškarádují provoz meshe za svou IP adresu. Egress Gateway lze tedy provozovat jen na Linuxu.
Za zmínku stojí, že klient Netmaker modifikuje /etc/hosts, aby umožnil používat jména ostatních uzlů místo jejich IP adresy. To je pro mě poněkud kontroverzní, ale uznávám, že je to celkem jednoduchá metoda, jak umožnit uživatelům používání jmen místo IP adres.
Bezpečnost
Problémem v takovýchto sítích je bezpečnost. Pokud máte na klientu tucty tunelů, těžko si všimnete, že je tam o jeden více. U Netmakeru celá bezpečnost stojí a padá s tím, jestli lze důvěřovat serveru, že do sítě nepouští žádné neautorizované klienty.
Netbird je trochu paranoidnější, nabízí totiž řešení v podobě PresharedKey. To je statický klíč, který umí WireGuard přímo používat a dokáže pak komunikovat jen s protistranami, které mají stejný klič. U Netbirdu není klíč distribuován ze serveru, server jej dokonce ani nezná. Předpokládá se, že administrátor jej ke všem účastníkům sítě dopraví jiným způsobem a netbirdový klient jen zajišťuje, že každé jím vytvořené spojení jej bude mít v konfiguraci zahrnuto. Pokud tedy někdo úspěšně napadne server a přidá si vlastní uzel sítě nebo zmanipuluje klienta, aby vygeneroval konfiguraci i pro parazitický uzel, neměl by parazitický uzel bez znalosti PresharedKey komunikovat s ostatními uzly sítě.
V každém případě však doporučuji od určité velikosti sítě posuzovat provoz meshe stejně jako provoz z internetu, tedy nevystavovat na něm zbytečně služby, které ostatní uzly v síti nepotřebují a nepovažovat IP adresu protistrany za jediný prostředek identifikace.
Vývoj běží
Jsem celkem zvědavý, jak si tyto projekty povedou v budoucnu. Oba mají kolem sebe komunitu, ale primárně jsou vyvíjeny v rámci komerčních aktivit a žijí z placené podpory. Oba poměrně rychle přidávají nové funkcionality. Mají i další konkurenty, propojení sítí skrz NATované sítě je evidentně téma, která trápí hodně lidí. Ostatní ale obvykle tunelují provoz jinými způsoby a nevyužívají výhod jaderné implementace WireGuardu.
ČLÁNKY DO MAILU