Bezlogová VPN

Co vlastně znamená „soukromá VPN“ a proč je důležitá

Soukromá VPN (virtuální privátní síť) je služba, která šifruje přenos mezi vaším zařízením a výstupním serverem provozovatele VPN. Cílem je chránit metadata a obsah před poskytovatelem připojení, síťovou infrastrukturou a vybranými modely sledování. „Soukromá“ v praxi znamená, že provozovatel minimalizuje sběr dat, neprovádí komerční profilování a technicky omezuje možnost zpětné identifikace uživatele. Klíčovou součástí marketingu těchto služeb jsou no-log (bezlogová) tvrzení – příslib, že služba „neuchovává žádné záznamy“ o vaší aktivitě.

Logy nejsou jen „historie webu“: typologie dat

Pojem „log“ je nadmnožinou mnoha dat. Při hodnocení tvrzení „no-log“ je důležité rozlišovat, jaké logy, na jak dlouho a za jakým účelem se evidují:

Provozní metadata: čas připojení/odpojení, délka relace, IP adresa klienta, přidělená VPN IP, objem přenesených dat, chybové kódy. Často se používají k řešení incidentů a řízení kapacity.
Aplikační logy: zprávy klienta/daemona (např. chybová hlášení WireGuard/OpenVPN), výsledky autentizace, stav tunelu. Mohou být dočasné nebo trvalé.
Bezpečnostní události: detekce zneužití (DDoS, spam, port scanning), systémové události (SELinux/AppArmor), IDS/IPS záznamy.
Účetní údaje: fakturační údaje, e-mail účtu, tokeny platby, historie předplatného. Nejsou „síťové logy“, ale spojitelnost s účtem je důležitá.
Síťový obsah: DNS požadavky, HTTP hlavičky, payloady. Soukromé VPN by je neměly ukládat ani inspektovat, s výjimkou explicitně aktivovaných filtrů (např. blokátor reklam) – pak je klíčové, jak jsou implementovány.

„No-log“ jako škála, nikoliv binární stav

Absolutní „žádné logy“ je technicky a provozně nepravděpodobné. Reálná interpretace je škála od přísné minimalizace a krátkodobého, volatilního bufferování až po dlouhodobé trvalé ukládání. Seriózní služby přesně definují, jaká data:

se nikdy nesbírají (např. zdrojová IP klienta na trvalém úložišti),
se sbírají dočasně (v RAM, rotujících kruhových bufferech) a s jakým TTL,
se agregují/anonymizují (telemetrie výkonu bez identifikátorů),
se sbírají trvale z účetních důvodů a jsou právně oddělena od síťové vrstvy.

Technické architektury podporující minimální logování

Samotné prohlášení nestačí – rozhoduje implementace. Důležité prvky:

Diskless/RAM-only serverové image: systémové oddíly v RAM (tmpfs) a neměnitelný obraz (immutable), který se při restartu obnoví do čistého stavu.
Centrální syslog vypnutý nebo přesměrovaný do volatilních bufferů s velmi krátkou retencí a bez trvalých rotačních logů.
Ephemerální klíče a Perfect Forward Secrecy: krátkodobě existující klíče (TLS-ECDHE, WireGuard s pravidelným rekey), aby kompromitace klíče neohrozila zpětně historický provoz.
Oddělení kontrolní a datové roviny: autentizace účtu probíhá mimo datové uzly (např. přes tokeny), aby servery neviděly identifikátory účtů.
Vlastní autoritativní DNS bez retence nebo DNS over TLS/HTTPS s lokální rekurzí a vypnutými debug logy.
Konfigurace WireGuard/OpenVPN tak, aby nevznikaly implicitní logy (např. vypnutý Log/Log-append v OpenVPN, vhodná úroveň LogLevel v systemd-journald, anonymizace peer ID ve správě WireGuard).
Automatické „wiping hooks“ při rotaci uzlů, selháních a aktualizacích – nulování swapu, RAM a ephemerálního úložiště.

Jurisdikce a regulace: co může provozovatele přinutit logovat

Právní prostředí má zásadní vliv. Je třeba sledovat:

Uchovávání provozních údajů (data retention): pokud země vyžaduje plošné uchovávání metadat, „no-log“ může přijít do rozporu s právem.
Rozsah a utajení příkazů: gag orders, nástroje typu „technical capability notices“ či national security letters mohou nařídit zavedení cíleného logování.
Extraterritorialita: nadnárodní působnost a dohody (MLAT) mohou rozšířit dosah orgánů mimo domovskou zemi provozovatele.
Struktura společnosti: holdingy v různých zemích, provoz serverů u třetích stran (colocation, cloud), smluvní podmínky poskytovatelů infrastruktury.

Audit, ověřitelnost a důkazní břemeno

Důvěryhodná „no-log“ tvrzení by měla být externě ověřitelná:

Nezávislé audity kódu a procesů (např. posouzení konfigurace journald, OpenVPN/WireGuard, DNS, SIEM) – s veřejnou zprávou a popisem zjištění/výhrad.
Penetrační testy a red-team hodnocení, pokrývající i snahy extrahovat logy z běžících uzlů a orchestrace.
Reprodukce buildu (reproducible builds) klientů a pokud možno i serverového image; hashované artefakty s ověřitelnými podpisy.
Případové důkazy (např. konfiskace serveru, kde se nic nenašlo) jsou zajímavé, ale nikdy nejsou univerzálním důkazem – mohly se týkat jiného data či uzlu.
Průběžné transparentní reporty (počet žádostí orgánů, kolik bylo splněno/odmítnuto, zda došlo k real-time logování a na jakou dobu).

DNS, IP pooly a riziko korelace

I bez logů lze provoz do jisté míry korelovat:

Velikost a diverzita IP poolu: malé pooly usnadňují mapování uživatelů v čase; rotace a sdílená IP jsou vhodné proti profilování.
Vlastní vs. pronajaté AS: vlastní autonomní síť s kontrolou směrování a ROA/ROV politiky snižuje závislost na třetích stranách.
DNS otisky: používání společných resolverů bez retence a lokální rekurze minimalizuje unikátnost dotazů.
Časové a velikostní vzory: proti korelaci pomáhají padding, multiplexing, v některých případech multihop či Decoy Routing (experimentální).

WireGuard vs. OpenVPN: implikační rozdíly pro logování

WireGuard je štíhlejší, s menším prostorem pro chybovou konfiguraci. Udržuje mapování veřejných klíčů na interní IP (peer mapping). Pokud se spravuje neopatrně (např. zapisování stavu do trvalého logu), může to oslabit „no-log“ přístup. OpenVPN má bohatší telemetrii a různé úrovně logování; správná politika vyžaduje vypnutí trvalých logů, omezení detailů a přísné rotace. V obou případech je důležitá politika logování orchestrací (systemd, Docker/Containerd, Kubernetes), protože právě ta může potichu uchovávat události na pozadí.

Platby, identita a separace dat

„No-log“ se často netýká účetnictví. Pro vyšší soukromí:

Oddělené identity: jiný e-mail pouze pro VPN; nepoužívat firemní či školní účty.
Způsob platby: vliv na spojitelnost (bankovní karta vs. anonymní platby). Provozovatel by měl oddělit fakturační systémy od provozní vrstvy.
Minimální telemetrie v klientech: vypínatelná diagnostika, žádné trvalé identifikátory, jasný seznam odesílaných polí.

Warrant canary, zákonné žádosti a reakční procesy

Warrant canary (pravidelně obnovované prohlášení, že poskytovatel nedostal tajný příkaz) může být užitečným signálem, ale není právně závazný. Důležitější jsou:

Formální postup pro právní žádosti: co poskytovatel předá, když je vyzván ke spolupráci, a jaké má mechanismy, pokud logy nemá.
Dokumentovaná nemožnost cíleného logování bez změny infrastruktury: např. pouze s fyzickým zásahem a redeployem podepsaného image.
Interní princip minimálních privilegií: aby jednotlivci neměli přístup k infrastruktuře, kde by mohli logy zapnout bez detekce (four-eyes princip, M z N podpisy).

Limity VPN a falešná očekávání

VPN neřeší vše. Přehled hlavních limitů:

Fingerprinting prohlížeče a cookies: ochrana vyžaduje hardening prohlížeče, izolaci profilů a blokování trackerů.
Malware a kompromitované zařízení: pokud je endpoint napadený, VPN nepomůže.
Geolokační služby a mobilní identifikátory: aplikace mohou odesílat identifikátory, které VPN neodstraní.
Boj proti dobře financovaným aktérům: korelace na úrovni backbone a vícenásobné sledování překračují možnosti běžné VPN.

Metodika hodnocení „no-log“ tvrzení pro organizace

Pokud organizace posuzuje VPN pro citlivé použití, doporučuje se formální metodika:

Požadavky a hrozby: definujte ohrožující subjekty (ISP, cloud provider, orgány činné v trestním řízení, konkurenti, insider) a potřebu forenzní stopy vs. soukromí.
Dokumentace a architektura: vyžádejte detailní diagramy datových toků, konfigurace logování (journald, syslog, SIEM), politiky retence a mazání.
Důkazy: audity třetích stran, výsledky red teamu, SBOM klientů, podpisové klíče, postupy reprodukovatelných buildů.
Technické testy: vlastní měření DNS úniků, kontrola IPv6, WebRTC, behaviorální testy logování (např. generování chyb a sledování, zda se trvale ukládají).
Právní due diligence: analýza jurisdikce, smlouvy s colocation/cloud partnery, procesy při příkazech na cílené logování.
Operativa: rotační cykly serverů, patch management, detekce konfigurací mimo šablony (drift detection), přístupové politiky (JIT, PAM, audit trail).

Implementační doporučení pro provozovatele VPN

Jste-li poskytovatel a chcete „no-log“ tvrzení podložit realitou:

Navrhněte infra-as-code se stateless uzly a automatizovanou verifikací konfigurace (CIS benchmarky, vlastní OPA politiky).
Zaveďte kryptografické atestace serverů (např. TPM/SEV-SNP) a publikujte verifikační procedury pro uživatele.
Udržujte rozpočty logů rovné nule pro datovou rovinu; pro control-plane logy nastavte krátké TTL v RAM a formalizovaný důvod existence.
Oddělte telemetrii výkonu (agregovanou, bez identifikátorů) od jakýchkoli identifikovatelných metadat.
Zveřejňujte transparentní reporty, warrant canary a harmonogram nezávislých auditů.

Praktická kontrola pro jednotlivce: rychlý checklist

Má poskytovatel jasně specifikováno, které logy nevede, které vede dočasně a proč?
Existují aktuální audity a nejsou to jen marketingová tvrzení? Je dostupný plný report?
Běží servery diskless/RAM-only? Jaké jsou důkazy (fotky racků, atestační podpisy, technické whitepapery)?
Má vlastní autoritatívní DNS s nulovou retencí a řešené úniky (IPv6, WebRTC)?
Umožňuje multihop nebo rotaci exitů a má široký IP pool?
Je klient open-source a podepsaný? Dá se build reprodukovat?
Jaké jsou reakce na právní žádosti v minulosti? Existují zveřejněné precedensy?

Etické a regulační aspekty: „soukromí“ vs. odpovědnost

Poskytovatelé balansují mezi soukromím uživatelů a prevencí zneužití. Odpovědný přístup zahrnuje jasné Podmínky užívání, techniky vzdělávání uživatelů (např. o limitech VPN) a proporcionální síťovou obranu proti zneužití, která nevyžaduje plošné logování (např. rate limiting, reput