Decentralizované tunelovací protokoly a P2P onion routing

Přechod od centralizovaného k decentralizovanému tunelování

Také vás občas zamrazí, když si uvědomíte, že váš „soukromý“ poskytovatel VPN je v podstatě jen předražený prostředník sedící na hromadě vašich nešifrovaných logů? Je to trochu ironie – vyměnili jsme slídění poskytovatelů internetového připojení (ISP) za jediný firemní uzel, který může vše sledovat. Přesně proto se ale trend decentralizovaného tunelování konečně dostává do širšího povědomí.

Tradiční architektura VPN je reliktem éry „klient-server“ z počátku milénia. Připojíte se k „zabezpečené“ bráně, která je však pro hackery a státní složky jen obřím neonovým terčem. Pokud tento jediný server vypadne nebo je zabaven, váš štít na ochranu soukromí okamžitě zmizí.

• Centralizované „Honey Poty“: Když miliony uživatelů směrují provoz přes hrstku datových center vlastněných jednou firmou, vzniká kritický bod selhání (single point of failure), který je pro útočníky příliš lákavým soustem.
• Paradox důvěry: V podstatě jen slepě věříte slibu ředitele firmy v daňovém ráji, že neukládá žádné záznamy. Bez open-source auditu jejich backendu ale letíte v mlze.
• Úzká hrdla při škálování: Všimli jste si někdy, jak v pátek večer padá rychlost? Je to proto, že centralizované uzly nezvládají nárazové zatížení moderního 4K streamování a náročné vývojářské práce.

Směřujeme k logice „Map & Encap“ (mapování a enkapsulace), kde síť nespoléhá na centrální mozek. Namísto jednoho poskytovatele využíváme uzly dVPN (decentralizované VPN), kde může kdokoli sdílet svou šířku pásma. Tato architektura – konkrétně například APT (A Practical Tunneling Architecture) – umožňuje internetu škálovat díky oddělení koncových adres („edge“) od tranzitního jádra („transit core“).

V rámci frameworku APT používáme vstupní tunelové routery (ITR) a výstupní tunelové routery (ETR). Představte si ITR jako „vstupní bránu“, která vezme vaše běžná data a zabalí je do speciální tunelové hlavičky (enkapsulace). ETR je pak „výstupní brána“, která data v cíli opět vybalí. Výchozí mappery (DM) fungují jako adresářová služba, která ITR přesně řekne, ke kterému ETR má paket poslat. Díky tomu si páteřní routery nemusí pamatovat každé jednotlivé zařízení na planetě.

Představte si maloobchodní řetězec, který potřebuje zabezpečit data z pokladních terminálů v 500 pobočkách, aniž by platil astronomické částky za MPLS okruhy. Namísto centrálního uzlu využijí VPN službu založenou na uzlech, kde každá prodejna funguje jako malý bod v mesh síti. Pokud v jedné prodejně vypadne internet, P2P síť automaticky přesměruje tunel přes sousední uzel.

Pro vývojáře to znamená práci s nástroji, jako jsou rozhraní WireGuard, která nejsou vázána na statickou IP adresu. Konfigurace na linuxovém zabezpečeném uzlu může vypadat například takto:

[Interface]
PrivateKey = <VAŠ_KLÍČ_UZLU>
Address = 10.0.0.5/32
ListenPort = 51820

[Peer]
PublicKey = <KLÍČ_VZDÁLENÉHO_DVPN_UZLU>
AllowedIPs = 0.0.0.0/0
Endpoint = 192.168.1.100:51820

PersistentKeepalive = 25

Toto nastavení je mnohem odolnější, protože „mapování“ cesty paketu je distribuováno po celé síti, nikoliv schováno v databázi v centrále nějaké korporace. Upřímně, je nejvyšší čas, abychom se přestali prosit o povolení k vlastnímu soukromí.

Příště: Hloubková analýza architektury P2P onion routingu, kde se podíváme na to, jak tyto pakety skutečně přežívají skoky mezi uzly.

Detailní vhled do architektury P2P onion routingu

Napadlo vás někdy, jak datový paket vlastně přežije průchod třemi různými VPN tunely a dvěma konverzemi protokolů, aniž by ztratil integritu nebo svá metadata? Je to v podstatě digitální „Počátek“ (Inception) – pokud architekturu nenastavíme správně, celý systém se zhroutí do chaosu ztracených paketů a masivní latence.

V P2P onion routing sestavě si nepředáváme jen „horký brambor“. Každý uzel (node) rozhoduje o tom, jak data „zabalí“. Když zde mluvíme o vrstvách „cibule“ (onion), pracujeme se dvěma hlavními operacemi:

• Zapouzdření (encapsulation): Vezmeme celý IPv4 paket a vložíme jej do IPv6 hlavičky (nebo naopak). Původní hlavička se pro vnější vrstvu stává pouhými „daty“.
• Konverze (conversion): Skutečné přepsání hlavičky, podobně jako u NAT-PT. Je to sice „destruktivnější“ metoda, ale u staršího hardwaru (legacy hardware) je někdy nezbytná.

Ve Web3 VPN může váš vstupní uzel zapouzdřit provoz pomocí protokolu WireGuard, zatímco relay uzel přidá další vrstvu šifrování, než data dorazí k výstupnímu uzlu. Díky tomu je blokování mnohem obtížnější než u tradičního Toru, protože „mapování“ nevisí na veřejném seznamu relay uzlů, ale je objevováno dynamicky v rámci mesh sítě.

Tradiční směrování (routing) využívá metodu „distance-vector“ (kolik skoků zbývá k cíli?). V P2P onion síti to ale nestačí. Musíte znát stav paketu. Pokud mám IPv4 paket, nemůžu ho jen tak poslat přes relay uzel, který podporuje pouze IPv6.

Jak uvádí studie Lamali et al. (2019), místo toho používáme stack-vector. Ten nahrazuje jednoduchou „vzdálenost“ takzvaným „protokolovým zásobníkem“ (protocol stack). Uzlu to říká: „Aby se tento paket dostal do cíle, potřebuješ tuto specifickou sekvenci zapouzdření.“ Studie prokázala, že i když je nejkratší cesta exponenciálně dlouhá, maximální potřebná výška protokolového zásobníku je ve skutečnosti polynomiální – konkrétně nanejvýš λn², kde n je počet uzlů.

Pro vývojáře je to zásadní zjištění. Znamená to, že nepotřebujeme konfigurační soubor o 5 000 řádcích pro správu vnořených tunelů. Uzly se tento „stack“ naučí samy. Například poskytovatel zdravotní péče, který se snaží propojit starší IPv4 vybavení vzdálené kliniky s moderním IPv6 datovým centrem, může nechat P2P uzly, aby si koncové body tunelu vyjednaly automaticky.

Pokud provádíte hardening uzlu, pravděpodobně sledujete, jak tyto zásobníky vypadají ve vašich rozhraních. Zde je hrubá představa o tom, jak může uzel zpracovat „cache hit“ pro konkrétní stack:

# Výstup tohoto příkazu ukazuje přesnou sekvenci zapouzdření 
# (např. IPv4 zabalené ve WireGuardu, který je zabalen v IPv6), abyste mohli trasu debugovat.
dvpn-cli route-lookup --dest 10.0.0.5 --current-stack "ipv4.wireguard.ipv6"

ip link add dev dvpn0 type wireguard
wg setconf dvpn0 /etc/wireguard/stack_config.conf

Krása tohoto řešení spočívá v tom, že mesh síť si poradí s výpadky sama. Pokud relay uzel vypadne, logika stack-vectoru najde „nejkratší proveditelnou cestu“ pomocí jiné sady zapouzdření. Je to samoopravný systém. Upřímně, jakmile to uvidíte v akci, návrat k statickým VPN tunelům vám bude připadat jako používání rotačního telefonu ve světě 5G.

Příště: Bezpečnostní výzvy v decentralizovaném přístupu k internetu, protože důvěřovat náhodným uzlům, to je úplně jiná disciplína.

Bezpečnostní výzvy v decentralizovaném přístupu k internetu

Pokud si myslíte, že přechod na P2P síť jako mávnutím kouzelného proutku vyřeší všechny vaše problémy s bezpečností, mám pro vás špatnou zprávu – v podstatě jen měníte jednu korporátní „vševědoucí krabičku“ za digitální divoký západ. Přechod z centralizované VPN na dVPN (decentralizovanou VPN) je sice skvělý pro soukromí, ale přináší zcela novou sadu komplikací.

Jak můžete důvěřovat prvnímu uzlu, když se připojujete k síti? Vzhledem k tomu, že neexistuje žádný centrální seznam, většina dVPN využívá takzvané Seed Nodes (vstupní uzly) nebo DHT (Distributed Hash Table) Bootstrapping. Váš klient se připojí k několika pevně kódovaným, známým „seed“ adresám, aby získal seznam ostatních aktivních peerů, a odtud již prozkoumává mesh síť samostatně.

Jakmile jste uvnitř, využíváme model sítě důvěry (web of trust), kde uzly vzájemně ověřují své sousedy.

• Ověřování mezi sousedy (Neighbor-to-Neighbor Verification): Předtím, než je uzlu povoleno vysílat informace o mapování sítě, jeho peeři ověří jeho identitu prostřednictvím navázaných spojení.
• Šíření podpisů (Signature Flooding): Jakmile je klíč podepsán dostatečným počtem důvěryhodných sousedů, je rozeslán (flooded) skrze celou mesh strukturu.
• Detekce škodlivých uzlů: Pokud uzel začne tvrdit, že může směrovat provoz pro rozsah IP adres, který ve skutečnosti nevlastní, skutečný vlastník zaznamená tento konfliktní vzkaz a spustí poplach.

Největším úskalím u P2P sdílení šířky pásma je churn (kolísání/odpojování uzlů). Na rozdíl od serveru v datovém centru s dostupností 99,99 % může domácí dVPN uzel zmizet jen proto, že něčí kočka zakopla o napájecí kabel. K řešení tohoto problému používáme systém oznamování poruch založený na datech. Namísto toho, aby se celá síť snažila udržovat „dokonalou“ mapu, je výpadek řešen lokálně v momentě, kdy se paket skutečně nepodaří doručit.

Default Mapper (DM) obstarává tu nejtěžší práci – vybere novou trasu a instruuje ITR (Ingress Tunnel Router), aby aktualizoval svou lokální mezipaměť (cache). To spoléhá na efektivitu λn², o které jsme mluvili dříve, aby přesměrování proběhlo bleskově.

Dále nás čeká: Jak zůstat v obraze v revoluci soukromí, kde se podíváme na technickou údržbu těchto uzlů.

Jak držet krok s revolucí v oblasti soukromí

Je až neuvěřitelné, jak rychle se prostředí digitálního soukromí mění, že? Zůstat v obraze už dávno neznamená jen občasné čtení blogů; jde o hluboké pochopení toho, jak nové protokoly reálně nakládají s vašimi datovými pakety.

Oblast decentralizovaných VPN (dVPN) je sice plná prázdných slibů o „cestě na měsíc“, ale skutečná hodnota leží v technických specifikacích. Vezměme si například, jak síť řeší ochranu proti úniku IPv6 (IPv6 leak protection). U tradičních VPN se často stává, že IPv6 provoz tunel úplně obejde, čímž odhalí vaši skutečnou IP adresu. V kontextu dVPN se proto často využívají mechanismy jako NAT64 nebo 464XLAT. Ty vynucují překlad IPv6 provozu na IPv4 (nebo naopak) přímo na úrovni uzlu (node), čímž zajistí, že data zůstanou uvnitř šifrované cesty „stack-vector“ a neuniknou přes lokální bránu.

• Sledujte commity: Nevěřte jen webovým prezentacím, kontrolujte GitHub. Pokud projekt neaktualizoval svou implementaci protokolu WireGuard nebo logiku vyhledávání uzlů (node-discovery) déle než půl roku, pravděpodobně jde o „zombie“ projekt.
• Auditní zprávy: Skutečné nástroje pro ochranu soukromí investují do nezávislých bezpečnostních auditů od třetích stran.
• Komunitní fóra: Specializované vývojářské Discordy jsou místem, kde se řeší reálné technické postupy a „how-to“.

Pokud to myslíte vážně, pravděpodobně už experimentujete s vlastními konfiguracemi. Zde je rychlý způsob, jak si ověřit, zda váš aktuální tunel skutečně respektuje decentralizovanou trasu:

ip route show dev dvpn0
traceroute -n -i dvpn0 1.1.1.1

Viděl jsem už spoustu nastavení, kde si uživatelé mysleli, jak jsou „neviditelní“, přitom ale stačilo jedno špatně nakonfigurované volání API a jejich reálná IP adresa byla venku. Je to neustálá hra na kočku a myš.

Příště se podíváme na tržiště s šířkou pásma a odměny v rámci DePIN, protože účty za elektřinu někdo zaplatit musí.

Tržiště s šířkou pásma a odměny v rámci DePIN

Dosud jsme probírali, jakým způsobem se pohybují datové pakety, ale buďme upřímní – nikdo nebude provozovat vysokorychlostní výstupní uzel (exit node) věčně jen z čisté dobroty srdce. Právě zde přichází na řadu koncept „Airbnb pro šířku pásma“, neboli to, co odborníci nazývají DePIN (decentralizované sítě fyzické infrastruktury).

• Těžba šířky pásma (Bandwidth Mining): Získáváte kryptoměnové odměny jen za to, že udržujete uzel online a směrujete skrze něj provoz.
• Tokenizace zdrojů: Použití nativního síťového tokenu umožňuje provádět mikroplatby za každý přenesený megabajt.
• Soulad pobídek: Odměny jsou váženy podle doby provozu (uptime) a „kvality služeb“ (QoS).

Hlavní technickou překážkou je: jak poznat, že uzel nelže o objemu dat, který skutečně odbavil? K tomu využíváme protokoly Proof of Bandwidth (doklad o šířce pásma). Tento proces zahrnuje „vyzyvatelský“ uzel (challenger), který posílá šifrovaná testovací data „prokazujícímu“ uzlu (prover) a měří jeho odezvu. Pokud čísla nesouhlasí, chytrý kontrakt platbu neuvolní.

Pokud by odměny nebyly správně naprogramovány, uzly by mohly upřednostňovat pouze vysoce profitabilní provoz. Abychom tomu zabránili, mnoho sítí využívá „staking“. Provozovatel musí složit tokeny jako kolaterál (záruku). Pokud poskytuje nekvalitní služby, o svůj podíl (stake) přichází.

V další části: Praktická implementace a budoucnost internetové svobody ve Web3 – aneb jak to všechno spojit dohromady.

Praktická implementace a budoucnost internetové svobody ve světě Web3

Budoucnost internetové svobody ve Web3 nepředstavuje žádný náhlý zlom nebo „přepnutí vypínače“. Půjde spíše o postupný, mírně chaotický proces, kdy decentralizované protokoly budou existovat paralelně s našimi současnými optickými trasami.

Nemusíme znovu vynalézat celý internet. Krása tohoto architektonického posunu spočívá v tom, že je navržen pro „unilaterální nasazení“. Jediný poskytovatel může začít nabízet tyto služby klidně dnes. K propojení těchto „ostrovů“ P2P sítí využíváme výchozí mapovače (Default Mappers – DM).

• Koexistence s původním hardwarem: Váš domácí router ani nemusí vědět, že komunikuje s P2P sítí. Lokální brána (gateway) se postará o veškerou logiku mapování a enkapsulace (Map & Encap).
• Přemostění mezer: Když paket potřebuje odejít na „běžný“ web, výstupní uzel (ETR) zajistí jeho dekapsulaci.
• Uživatelsky přívětivá abstrakce: Pro běžného uživatele se systém tváří jako jednoduchá aplikace, i když na pozadí spravuje komplexní směrování pomocí stavových vektorů (stack-vector routing).

Z pohledu vývojáře je cílem dosáhnout toho, aby tyto tunely byly „automatické“. Zde je rychlá ukázka toho, jak by uzel mohl kontrolovat mapování v rámci „ostrova“:

dvpn-cli map-query --dest 192.168.50.1

[DEBUG] Cache miss. Querying DM anycast...
[INFO] Received MapRec: Destination reachable via ETR 203.0.113.5

Konečným cílem je síť, kterou je v podstatě nemožné vypnout. Když zkombinujete blockchainovou VPN s P2P onion routingem, vytváříte systém, který nemá žádný centrální bod selhání. Jak jsme již zmínili, komplexita λn² nám umožňuje dosáhnout hlubokého, vícevrstvého soukromí, aniž by došlo ke kolapsu sítě.

Budoucnost sdílení šířky pásma (bandwidth sharing) není jen o tom, jak ušetřit pár korun. Jde o globální konektivitu, která obchází digitální bariéry a cenzuru. Momentálně je to sice trochu nepřehledné a příkazy v terminálu mohou být otravné, ale základy jsou položeny. Internet byl od začátku zamýšlen jako decentralizovaný – my jen konečně budujeme architekturu, která zajistí, aby takový i zůstal. Každopádně, je na čase přestat o tom jen mluvit a začít spouštět uzly. Buďte tam venku v bezpečí.