Wireguard - vynikající VPN

Pokud byste chtěli obecný koncepční přehled o tom, o čem WireGuard je, čtěte dále zde. Poté můžete přejít k instalaci a přečíst si pokyny pro rychlý start, jak ji používat.

Pokud vás zajímá vnitřní vnitřní fungování, mohlo by vás zajímat stručné shrnutí protokolu nebo jít více do hloubky tím, že si přečtete technický dokument, který podrobněji popisuje protokol, kryptografii a základy. Pokud máte v úmyslu implementovat WireGuard pro novou platformu, přečtěte si prosím poznámky pro různé platformy.

WireGuard bezpečně zapouzdřuje IP pakety přes UDP. Přidáte rozhraní WireGuard, nakonfigurujete jej pomocí svého soukromého klíče a veřejných klíčů vašich kolegů a poté přes něj posíláte pakety. Všechny problémy distribuce klíčů a push konfigurací jsou mimo rozsah WireGuard; to jsou problémy, které je lepší nechat pro jiné vrstvy, abychom neskončili s nadýmáním IKE nebo OpenVPN. Oproti tomu více napodobuje model SSH a Mosh; obě strany mají navzájem své veřejné klíče a pak si mohou jednoduše začít vyměňovat pakety přes rozhraní.

Srdcem WireGuardu je koncept nazvaný směrování pomocí šifrovacíh klíčů (Cryptokey Routing), který funguje tak, že spojuje veřejné klíče se seznamem IP adres tunelu, které jsou povoleny v tunelu. Každé síťové rozhraní má soukromý klíč a seznam partnerů. Každý peer má veřejný klíč. Veřejné klíče jsou krátké a jednoduché a používají je kolegové ke vzájemné autentizaci. Lze je předat pro použití v konfiguračních souborech jakoukoli metodou (třeba je nadiktovat telefonem), podobně jako je možné poslat svůj veřejný klíč SSH příteli pro přístup k shellu serveru.

Server může mít například konfiguraci:

A klientský počítač může mít třeba tuto:

V konfiguraci serveru bude každý peer (klient) schopen posílat pakety do síťového rozhraní se zdrojovou IP odpovídající jeho odpovídajícímu seznamu povolených IP adres. Například, když server přijme paket od peer gN65BkIK…​, poté, co byl dešifrován a ověřen, je-li jeho zdrojová IP adresa 10.10.10.230, je povolen vstup na rozhraní; jinak se zahazuje.

Když chce síťové rozhraní v konfiguraci serveru odeslat paket peerovi (klientovi), podívá se na cílovou IP tohoto paketu a porovná ji se seznamem povolených IP každého peeru, aby zjistil, kterému peeru jej poslat. Pokud je například síťové rozhraní požádáno o odeslání paketu s cílovou IP 10.10.10.230, zašifruje jej pomocí veřejného klíče peer gN65BkIK…​ a poté jej odešle na nejnovější internetový koncový bod tohoto peeru.

V konfiguraci klienta bude jeho jediný peer (server) moci posílat pakety do síťového rozhraní s libovolnou zdrojovou IP (protože 0.0.0.0/0 je zástupný znak). Například, když je paket přijat od peera HIgo9xNz…​, pokud se dešifruje a autentizuje správně, s jakoukoli zdrojovou IP, pak je povolen vstup na rozhraní; jinak se zahazuje.

V konfiguraci klienta, když chce síťové rozhraní poslat paket svému jedinému peeru (serveru), zašifruje pakety pro jednoho peer s libovolnou cílovou IP adresou (protože 0.0.0.0/0 znamená libovolnou adresu). Pokud je například síťové rozhraní požádáno o odeslání paketu s libovolnou cílovou IP adresou, zašifruje jej pomocí veřejného klíče jednoho peer HIgo9xNz…​ a poté jej odešle na nejnovější internetový koncový bod jednoho peer.

Jinými slovy, při odesílání paketů se seznam povolených IP chová jako jakási směrovací tabulka a při příjmu paketů se seznam povolených IP chová jako jakýsi seznam řízení přístupu.

To je to, co nazýváme Cryptokey Routing Table: jednoduchá asociace veřejných klíčů a povolených IP adres.

Pro kterékoli pole lze použít libovolnou kombinaci IPv4 a IPv6. WireGuard je v případě potřeby plně schopen zapouzdřit jeden do druhého.

Vzhledem k tomu, že všechny pakety odesílané na rozhraní WireGuard jsou šifrované a ověřené, a protože existuje tak těsné spojení mezi identitou peera a povolenou IP adresou peera, správci systému nepotřebují složitá rozšíření firewallu, jako např. IPsec, ale spíše se mohou jednoduše shodovat na „je to z této IP? na tomto rozhraní?“ a mít jistotu, že jde o bezpečný a autentický paket. To značně zjednodušuje správu sítě a řízení přístupu a poskytuje mnohem větší jistotu, že vaše pravidla iptables skutečně dělají to, co jste jim zamýšleli.

Konfigurace klienta obsahuje počáteční koncový bod jeho jednoho peer (serveru), takže ví, kam má odeslat šifrovaná data, než přijme šifrovaná data. Konfigurace serveru nemá žádné počáteční koncové body svých vrstevníků (klientů). Důvodem je, že server zjišťuje koncový bod svých protějšků zkoumáním, odkud pocházejí správně ověřená data. Pokud server sám změní svůj vlastní koncový bod a odešle data klientům, klienti objeví nový koncový bod serveru a aktualizují konfiguraci stejně. Klient i server odesílají šifrovaná data na nejnovější koncový bod IP, pro který autenticky dešifrovali data. Na obou koncích tedy existuje plný IP roaming.

WireGuard odesílá a přijímá šifrované pakety pomocí síťového jmenného prostoru, ve kterém bylo rozhraní WireGuard původně vytvořeno. To znamená, že můžete vytvořit rozhraní WireGuard ve svém hlavním síťovém jmenném prostoru, který má přístup k internetu, a poté jej přesunout do síťového jmenného prostoru patřícího kontejneru Docker jako jediné rozhraní tohoto kontejneru. Tím je zajištěno, že jediný možný způsob, jakým je kontejner schopen přistupovat k síti, je prostřednictvím zabezpečeného šifrovaného tunelu WireGuard.

Před podrobným vysvětlením skutečných příkazů může být velmi poučné nejprve sledovat, jak je používají dva kolegové konfigurovaní vedle sebe:

Ve výchozím nastavení se WireGuard snaží být co nejtišší, když není používán; není to upovídaný protokol. Z velké části přenáší data pouze tehdy, když si peer přeje posílat pakety. Když není požádán o odeslání paketů, přestane odesílat pakety, dokud nebude znovu požádán. Ve většině konfigurací to funguje dobře. Pokud je však peer za NATem nebo firewallem, může si přát, aby mohl přijímat příchozí pakety, i když žádné pakety neodesílá. Protože NAT a stavové firewally sledují „spojení“, pokud si peer za NAT nebo firewallem přeje přijímat příchozí pakety, musí udržovat mapování NAT/firewallu v platnosti tím, že bude pravidelně zasílat pakety udržující aktivitu. Tomu se říká trvalé udržování života (keep alive). Když je tato možnost povolena, paket udržující aktivitu je odeslán do koncového bodu serveru jednou za sekundu. Rozumný interval, který funguje s širokou škálou firewallů, je 25 sekund. Nastavením na 0 se tato funkce vypne, což je výchozí nastavení, protože většina uživatelů to nebude potřebovat, a díky tomu bude WireGuard o něco upovídanější. Tato funkce může být specifikována přidáním pole PersistentKeepalive = do protějšku v konfiguračním souboru nebo nastavením persistent-keepalive na příkazovém řádku. Pokud tuto funkci nepotřebujete, nepovolujte ji. Ale pokud jste za NAT nebo firewallem a chcete přijímat příchozí spojení dlouho poté, co síťový provoz utichl, tato možnost udrží „spojení“ v očích NAT otevřené.

Wireguard beží na velkém množství operačních systémů (Windows, MacOS, Android, iOS, fůra Linuxů, OpenBSD, FreeBSD, OpenWRT, Termux), podrobnosti najdete na stránce autora Installation

Příklady konfigurace budou na cvičení v OU5.

Wireguard síť si zvolíme 172.16.48.0/24. Všechny operace budeme provádět jako root v terminálu. Roota získáme pomocí příkazu sudo su.

Wireguard home site

Wireguard git

Wireguard na Raspberry Pi PicoW — kompletní rozchození

Daniel Hope: oznámení o portu Wireguardu na embedded platformy s IP stackem lwIP

a k tomu Github