Protokol WireGuard představuje jednoduchý způsob, jak vytvořit šifrovaný a autentizovaný tunel mezi libovolným množstvím počítačů. K tomu je potřeba, aby si každý uzel vygeneroval pár soukromého a veřejného klíče, ten veřejný předal všem ostatním uzlům a nakonfiguroval jejich veřejné klíče spolu s jim přidělenými IP adresami uvnitř tunelu a vnějšími IP adresami a čísly portů, na kterých jsou protistrany k zastižení.
Co se dozvíte v článku
Už z tohoto popisu je zřejmé, že pro netriviální množství uzlů začíná množství nutné administrativy neúměrně narůstat a bude potřeba ho automatizovat. Dále vzhledem k tomu, že WireGuard nepoužívá žádné certifikáty, ale pracuje přímo s klíči, není v podstatě možné klíč vyměnit bez výpadku, leda že by v jeden okamžik zároveň všechny protistrany změnily veřejný klíč. Vůbec nejhorší ovšem je střet s realitou dnešního internetu, na kterém rozhodně neplatí, že jakékoli dva uzly spolu mohou přímo komunikovat.
Překonáváme firewally a NATy
Tou nejjednodušší překážkou je stavový firewall, který blokuje všechna spojení, která nejsou iniciovaná zevnitř. Spojení dvou zařízení, která jsou obě za takovými firewally, je snadné: stačí, když se o spojení budou pokoušet obě strany zároveň. Vzhledem k tomu, že se jedná o datagramy protokolu UDP, nemá firewall jak poznat, že příchozí datagram z adresy a portu souseda není ve skutečnosti odpovědí dříve prošlý odchozí datagram tamtéž, takže jej propustí.
Situace začne být složitější, když do cesty vstoupí NAT. V jednodušších případech, kdy je příslušná kombinace zdrojové adresy a čísla portu přeložena na stále stejnou kombinaci jiné adresy a čísla portu, je možné problém vyřešit s pomocí prostředníka, který dvěma komunikujícím stranám prozradí přeložené adresy a čísla portů. Vtipné řešení tohoto problému pomocí protokolu DNS-SD před časem publikoval Jordan Whited.
Jenže pak jsou tu i NATy, které se chovají záludněji a překládají nejen v závislosti na zdrojové adrese a čísle portu, ale v závislosti na celé pětici zdrojové a cílové adresy, zdrojového a cílového portu a protokolu. Chová se tak například linuxové jádro. A konečně jsou tu i sítě, kde UDP vůbec nefuguje, případně funguje jen port 53, ale jen k místnímu resolveru. Překonat takovéto překážky je pro WireGuard neřešitelný problém.
Tailscale jako WireGuard, který funguje vždy a všude
Tailscale je komerční VPN řešení, které si lze do jisté míry představit jako nadstavbu nad WireGuard. Skládá se ze tří částí. Proprietární centrální registrační systém, který je k dispozici pouze jako služba, se stará o registraci zařízení do sítě, distribuci veřejných klíčů a přidělování IP adres. Open source klient pak vychází z implementace protokolu WireGuard v jazyce Go. Ta je doplněna o podporu překonávání NATů a firewallů a komunikaci s centrálou.
Třetí částí je síť retranslačních serverů DERP (Detour Encrypted Routing Protocol) po celém světě. Jedná se o servery poslední záchrany, které předávají data v případě, kdy přímé spojení mezi danými uzly není (prozatím nebo trvale) možné. Je přitom zachován princip koncového šifrování a autentizace: veškerá data jsou podepsána a zašifrována privátními klíči, které nikdy neopustí klienta.
Zkoušíme bezplatnou verzi
Služba je k dispozici v několika předplatných, nechybí ani základní verze zdarma. Ta má dvě základní omezení: uživatelský účet (zvaný doména) může mít přiřazeného pouze jednoho správce a nelze připojovat celé podsítě, jen jednotlivé počítače. Těch může být až sto. Administrační panel je od začátku navržen pro propojení pomocí Single-Sign-On, nenabízí tedy vůbec možnost vytvořit lokální účet. Uživatelé bezplatné služby mají v době psaní tohoto článku k dispozici přihlášení pomocí účtů Google nebo Microsoft.
Po prvním přihlášení se objeví ovládací panel s přehledem všech registrovaných klientů. Nebude prázdný, bude v něm první klient s názvem hello-ipn-dev
, který jednak pomůže v testování, jednak pěkně ilustruje další zajímavou funkci: jednotlivé domény mohou servery mezi sebou sdílet. Také je vidět, že tento ukázkový server má snadno zapamatovatelnou adresu 100.101.102.103
. Jako běžní uživatelé mít takové štěstí nebudeme, každý klient dostane přidělenou náhodnou adresu z rozsahu 100.64.0.0/10
, který je podle RFC 6598 vyhrazen pro Carrier-Grade NAT. Webové rozhraní nezobrazuje, že kromě IPv4 má i každý klient přidělenou svou pevnou IPv6 adresu z rozsahu ULA fd7a:115c:a1e0::/48
− je vidět, že náhodný identifikátor prefixu podezřele připomíná název služby.
Nyní už stačí jen nainstalovat klienta tailscale
na každý z počítačů, které chceme propojit. Některé distribuce mají klienta v repozitářích, pro jiné je k dispozici repozitář od výrobce. Propojení se odehrává buď otevřením webové adresy, kterou klient po instalaci vypíše na terminál, nebo je naopak možné z webového rozhraní vygenerovat token, který se zadá jako volba příkazového řádku při prvním spuštění klienta. Tím je instalace hotova.
Směrovací tabulka číslo 52
Za pozornost stojí způsob, jakým klient zasahuje do směrovací tabulky operačního systému. Na první pohled do ní totiž na Linuxu nezasahuje vůbec. Místo ní používá jinou tabulku s číslem 52, kterou pomocí ip rule
zařadí před hlavní směrovací tabulku. Zatímco pro IPv6 je do VPN rozhraní nasměrován celý rozsah /48, pro IPv4 obsahuje jednotlivé záznamy pouze pro adresy sousedů, které jsou členy naší domény:
# ip -6 rou show table 52
fd7a:115c:a1e0::/48 dev tailscale0 metric 1024 pref medium
# ip -4 rou show table 52
100.100.100.100 dev tailscale0 scope link
100.101.102.103 dev tailscale0 scope link
Díky tomuto opatření je nepravděpodobné, že by došlo ke konfliktu s adresami jiných sítí i v případě, že se daný adresní rozsah používá i v jiné lokální síti, například na přímo připojeném LTE modemu. Kromě testovacího uzlu 100.101.102.103
je k dispozici také adresa 100.100.100.100
, která může sloužit jako magický DNS forwarder.
Magické DNS
Protože adresy uzlů jsou přidělovány náhodně a nelze je uživatelsky změnit, je praktické používat místo nich DNS jména. V ovládacím panelu je možné nastavit adresy DNS resolverů, který budou používat všechna zařízení v doméně. Může se jednat jak o veřejné adresy dostupné z celého Internetu, tak i o privátní adresy uvnitř domény. O jejich nastavení do příslušného operačního systému se postará klient − na Linuxu to vzhledem k diverzitě prostředí není úplně triviální úkol.
Ve výchozím stavu nejsou žádné DNS servery nastaveny, pak klient do nastavení nezasahuje. Třetí možností, která je nyní v režimu beta, je právě Magic DNS. Při této funkci je nastavena prohledávací doména ve tvaru <jméno účtu>.beta.tailscale.net
a veškeré DNS dotazy předávány na adresu 100.100.100.100
. Tato IP adresa je ve skutečnosti obsluhována lokálně uvnitř klienta. Ten dokáže sám odpovídat na dotazy týkající se uzlů v rámci své domény, zbytek předává dál. Výsledkem tedy je, že krátká jména jednotlivých uzlů se překládají na příslušné IP adresy. V době testování šlo pouze o IPv4 adresy.
Tunelování veškerého provozu
Primárním účelem služby je vybudování důvěryhodné sítě vzájemně propojených počítačů. Od verze 1.6 je ale podporována funkce Exit Nodes, která umožňuje přesměrovat výchozí bránu na vybraný jiný uzel v síti a tak tunelovat veškerý provoz. Protože jde o citlivou funkci, je potřeba k její aktivaci dvojí schválení: jednak musí být klient, který má nabízet funkci výstupního uzlu, spuštěn s volbou -advertise-exit-node
, jednak musí být funkce aktivována ve webovém ovládacím panelu. Na výstupním uzlu je IPv4 i IPv6 provoz NATován pomocí pravidel iptables
. Každý klient si pak může vybrat, přes který uzel bude provoz tunelovat.
Příkazový řádek odhalí cestu dat
Součástí instalace linuxového klienta tailscaled
je také ovládací utilita tailscale
. Ta nabízí některé zajímavé příkazy:
tailscale status
vypíše adresy a jména všech uzlů v doméně a přidá informaci o způsobu připojení k těm, se kterými je komunikováno.tailscale netcheck
analyzuje síťové prostředí a vypíše zjištěné IP adresy, typ NATu, nebo třeba latenci k jednotlivým přeposílačům poslední záchrany DERP.tailscale ping <jméno>
se pokusí navázat spojení s daným uzlem. Přitom vypisuje nejen informaci o latenci, ale i informaci o způsobu, jakým bylo spojení navázáno. Obvykle je spojení nejprve realizováno přes servery poslední záchrany, zatímco se na pozadí spustí proces propichování NATů a firewallů.
# tailscale ping 100.101.102.103 pong from hello.ipn.dev (100.101.102.103) via DERP(fra) in 618ms pong from hello.ipn.dev (100.101.102.103) via DERP(fra) in 12ms pong from hello.ipn.dev (100.101.102.103) via 18.196.71.179:41641 in 5ms
Je to zcela bezpečné?
Podle dostupných informací se zdá, že bezpečnost celého řešení je srovnatelná s bezpečností samotného WireGuardu − soukromý klíč je vygenerován klientem po instalaci a nikdy jej neopustí, takže do obsahu komunikace nemůže nikdo zasahovat. Zdá se ale, že tu je jedna slabina, o které na firemním blogu moc nepíší. Centrální koordinační server totiž automaticky předává všem uzlům veřejné klíče všech ostatních a dokáže i klíče kdykoli vyměnit. Uživatel přitom nemá žádným běžným rozhraním možnost ani zjistit, jaké veřejné klíče jednotlivé uzly používají, natož aby byl upozorněn na jejich výměnu. Kdo se tedy zmocní centrálního serveru, dokáže do komunikace vstoupit provedením útoku typu Man-in-the-Middle.
Tento problém přitom není snadné odstranit a zároveň přitom neznemožnit pravidelné výměny klíčů a také jednoduché připojování nových zařízení. Nezbývá tedy, než provozovateli přiměřeně důvěřovat, že takový útok na šifrované spojení nedopustí ani nedbalostí a především nespoléhat na takovouto VPN jako jediný prostředek k zabezpečení opravdu citlivých dat. Což ostatně není dobrý nápad s žádnou VPN.
Nové funkce stále přibývají
Od prvního veřejného vydání uplynul právě rok, poslední vydání 1.6 s podporou IPv6 uvnitř tunelu a funkcí Exit Nodes vyšlo před necelým měsícem a vývoj stále probíhá. Služba se snaží prosadit jako náhrada centralizovaných firemních VPN koncentrátorů a snaží se proto nabízet i funkce, na kterých některé korporace lpí, jako možnost omezit komunikaci mezi jednotlivými uzly, nebo centrální sběr provozních dat a to i v případě, že data přes žádný centrální uzel neprocházejí.
Instalace klienta na všechny běžné operační systémy je extrémně jednoduchá. Na všech platformách včetně Linuxu se používá userspace implementace v jazyce Go, což sice znamená o něco horší výkon proti originálnímu modulu jádra, ale zase je jednoduché klienta nainstalovat na jakoukoli distribuci bez nutnosti překládat speciální moduly pro každé jádro.
Na rozdíl od všech ostatních komerčních VPN produktů je tu velmi dobrá podpora pro IPv6 jak uvnitř, tak i vně tunelu, byť je zde stále prostor pro zlepšení. Ať už jste administrátor cloudových služeb na volné noze nebo velká korporace přemýšlející nad výměnou zastarávajícího centrálního VPN koncentrátoru, použití Tailscale rozhodně stojí za zvážení.
Tento článek vznikl bez podpory či vědomí společnosti Tailscale.