De ce am renunțat la WireGuard?

Ca să scrii un VPN, primul lucru pe care îl faci este să deschizi pagina WireGuard. E mic, e auditat, e rapid, e în nucleul Linux. De acolo am pornit și noi. Apoi am luat un alt drum, cu câteva greșeli pe parcurs, mai ales una; am ajuns să facem un fork al lui Quinn.

Iată traseul complet, cu câteva cifre limpezi. Îl publicăm pentru orice folos: chiar dacă nu atingeți niciodată Warren, ar trebui să plecați de aici cu un bagaj mai bun. S-ar putea, de pildă, să duceți în producție un bug BBR fără să știți.

Cartea albă este mult mai detaliată și mai completă. Articolul acesta există ca să o facă mai accesibilă, adresându-se totuși unui public tehnic. Împărtășim totul fără rețineri, ca să puteți pune la încercare, testa și consolida mai departe alegerile făcute.

#Trei motive, în slujba obiectivelor noastre

Nu am luat această decizie din cauza unor defecte majore ale lui WireGuard. Ceea ce voiam să construim ne-a dus în mod firesc în altă parte.

Semnătura. Un tunel WireGuard „gol" este blocat sau limitat pe rețelele care filtrează UDP, ori de îndată ce inspecția profundă îi recunoaște semnătura. Ca să îl faci discret, trebuie să stivuiești deasupra un strat de obfuscare, prin urmare să întreții acel strat pe viață, separat de transport. Iar un mod discret pe care trebuie să îl activezi este un mod discret pe care poți uita să îl activezi.

Funcțiile care lipsesc. Multi-hop cifrat cap la cap, port forwarding în bandă, apărarea împotriva analizei de trafic (DAITA). WireGuard nu oferă nici negociere de capabilități, nici canal de control în bandă, nici extensibilitate a handshake-ului. Fiecare dintre aceste trei funcții ar trebui deci altoită pe deasupra, cu propriul canal de control și propria întreținere. Trei altoiuri, trei suprafețe de atac, trei lucruri care trebuie să îmbătrânească împreună.

Identitatea dublă. Identitatea unui tunel WireGuard se sprijină pe o cheie proprie tunelului, distinctă de identitatea criptografică a utilizatorului. Două identități de sincronizat, deci două suprafețe de corelare. Noi voiam una singură.

Cele trei duc spre aceeași concluzie, iar ea ne-a hotărât alegerile și dezvoltările: proprietățile de care avem nevoie nu trebuie altoite pe transport, ele trebuie purtate de transport.

#O greșeală de început: Iroh

Raționamentul de mai sus duce firesc la QUIC.

Prima noastră abordare a fost Iroh, o stivă P2P construită peste QUIC. Pe hârtie este perfectă: identitate de nod deja aliniată pe o cheie publică, traversare NAT și multipath native.

La utilizare, Iroh aducea mai ales greutate. Mii de linii nefolosite în cazul nostru. Un API care se schimbă în fiecare săptămână. O clasă de buguri de traversare NAT pe care nu am reușit să o rezolvăm. Și o coadă lungă de dependențe tranzitive.

Punctul pe care ne-a luat ceva timp să îl numim: în topologia Warren, un client se adresează unui server de ieșire cunoscut. Traversarea NAT și multipath, cele două funcții de frunte ale lui Iroh, nu foloseau absolut la nimic. Plăteam prețul întreg pentru funcționalități pe care aplicația nu le apela niciodată.

#Pivotul, mai 2026

Am renunțat la Iroh și am trecut la Quinn, implementarea Rust de referință a QUIC, fără stratul P2P. Migrarea a durat câteva zile.

Rezultatele:

• variabilitatea debitului mult redusă
• binare reduse la mai puțin de jumătate
• arbore de dependențe adus de la optzeci de crate la aproximativ douăzeci și cinci

Regula pe care am reținut-o se aplică mult dincolo de un VPN: o fundație modestă și înțeleasă este de preferat uneia ambițioase și cețoase. O dependență pe care nu o stăpânești complet este deopotrivă o datorie de securitate și o datorie tehnică.

#Ce ne dă QUIC

Cinci proprietăți structurale, și niciuna nu este o opțiune la care trebuie să te gândești să o activezi.

Discreția nativă. Traficul se confundă cu HTTP/3 pe portul 443. Obfuscarea este chiar protocolul.

Un canal de control în bandă. Fluxuri fiabile, negociere de capabilități, handshake extensibil. Multi-hop și port forwarding trăiesc în interiorul protocolului, în loc să fie altoite alături.

O singură identitate. TLS 1.3 este integrat în transport, iar autentificarea mutuală se face cu Raw Public Keys (RFC 7250), în Ed25519, verificate direct, fără CA.

Datagramele IP. Pachetele IP călătoresc 1:1 în cadre DATAGRAM (RFC 9221).

Migrarea conexiunii. O trecere de la Wi-Fi la Ethernet sau la rețeaua celulară este detectată și absorbită.

La performanță, pe bare-metal 10 GbE cu AMD EPYC Zen4, între două mașini din același centru de date, un singur tunel susține stabil între 5,5 și 7 Gbit/s. Un server duce peste cinci mii de sesiuni simultane la sub zece la sută încărcare a procesorului. Iar cu 2% pierdere injectată pe un flux, acolo unde un controler de congestie clasic se prăbușește la câțiva megabiți pe secundă, BBR menține câteva sute.

#Forkul nostru de Quinn

Forkul este aici: github.com/WarrenBrowse/warren-quinn

Este publicat sub MIT OR Apache-2.0, ca și upstream, cu crate redenumite (warren-quinn, warren-quinn-proto, warren-quinn-udp), ca nimeni să nu aibă nevoie de un [patch.crates-io]. Fiecare divergență este izolată într-un patch documentat, iar forkul este resincronizat când upstream avansează.

Trei delta merită ocolul chiar și în afara unui VPN.

Bugul BBR. Două defecte în care o conexiune app-limited rămâne blocată în STARTUP și își lasă cwnd să crească nemărginit. În producție am observat ferestre de o jumătate de gigaoctet. Rulați Quinn cu BBR pe trafic app-limited și îl puteți vedea. Patch-ul respectă specificația și este destinat upstream-ului.

AQM pe coada de datagrame. FQ-CoDel (RFC 8289 și RFC 8290), cozi per flux, planificare DRR, izolarea fluxurilor. Capetele de coadă al căror sojourn time ține coada peste target un interval întreg sunt eliminate din față. Fără asta, un singur flux lacom ruinează latența tuturor celorlalte din tunel.

Bufferul de emisie dimensionat pe BDP. clamp(4 × EWMA(bw × min_rtt), 1 MiB, configurat). Pe ultimele mile lente, adâncimea cozii scade de la 16 MiB la aproximativ 1 MiB. Este bufferbloat în minus, pe gratis.

Mai există și dimensionarea GSO (MAX_TRANSMIT_DATAGRAMS de la 20 la 80, MAX_TRANSMIT_SEGMENTS de la 10 la 40), auto-dimensionarea bufferelor de socket pe Unix și Windows, și un datapath rapid pentru Apple.

#MTU

Să treci pachete IP prin cadre DATAGRAM QUIC este ușor. Să le treci fără să rupi jumătate din internet, mult mai puțin.

Soluțiile noastre:

• Pornim de la un prag prudent de 1280 de octeți, sondăm în sus când calea nativă o permite și nu coborâm niciodată sub 1200 de octeți, minimul pe care QUIC îl garantează cap la cap.
• Pentru fluxurile TCP, MSS clamping pe pachetele SYN, de ambele părți ale tunelului. Cele două capete se dimensionează singure, fără să depindă de ICMP, ceea ce rezolvă cazul căilor unde ICMP este filtrat și unde PMTUD intră în zid.
• Pentru celelalte fluxuri, un pachet prea mare este eliminat, iar emițătorul lui primește un ICMP Fragmentation Needed real în IPv4, sau ICMPv6 Packet Too Big în IPv6, cu dimensiunea corectă.
• Pe rezerva TCP, unde stiva poate fragmenta singură, PMTUD este dezactivat și bugetul intern plafonat la 1100 de octeți, dimensiunea care traversează acest transport fără să cadă într-o gaură neagră.

#Handshake-ul

SNI și începutul mesajului ClientHello sunt fragmentate pe cel puțin două datagrame UDP umplute, cu un prag de padding pe pachetul Initial și un plafon pe dimensiunea primului fragment CRYPTO.

Este o apărare precisă împotriva unui extractor de SNI documentat al Marelui Firewall chinezesc și împotriva unui atac de extragere pasivă publicat în 2025. Este activă implicit, pe toate conexiunile, fără nimic de configurat.

#Legături

• Motorul, sub AGPL-3.0: github.com/WarrenBrowse/warrenguard
• Forkul lui Quinn, sub MIT OR Apache-2.0: github.com/WarrenBrowse/warren-quinn
• Cartea albă, 33 de secțiuni, acoperă tot ce se află în acest articol și mult mai mult