Mystic, naš VPN protokol: po čemu se razlikuje i zašto je kod zatvoren tri godine

Pravimo Mystic, sopstveni VPN protokol i jezgro u Rust-u koje se može ponovo koristiti u našim VPN proizvodima. Specifikaciju smo završili 21. oktobra 2026: zahteve, format protokola, arhitekturu, model pretnji i plan testiranja. Sledeći korak je implementacija.

Ovo je najava eksperimentalnog protokola, a ne gotovog proizvoda. Merenja još nema, i namerno ne dajemo tvrdnje o brzini ili dostupnosti koje nismo izmerili. U nastavku objašnjavamo zašto nam treba sopstveni protokol, kako je napravljen, po čemu se razlikuje od postojećih, zašto ćemo ga koristiti u svojim proizvodima i zašto će izvorni kod ostati zatvoren najmanje tri godine.

Zašto nam treba sopstveni protokol

Naše VPN aplikacije danas rade na tuđim motorima. To su dobri motori, ali je svaki pravljen za svoje uslove: jedni su brzi UDP tuneli, drugi prenose saobraćaj preko TLS-a ili QUIC-a, a treći su proksiji, a ne pravi mrežni tuneli. Proizvod koji mora da radi u veoma različitim mrežama na kraju kombinuje nekoliko njih, i svaki ima svoju konfiguraciju, svoj životni ciklus i svoje kvarove.

Treba nam jedno jezgro koje pripada nama. Ono treba da održava jednu vezu dok se mreža menja, da troši dodatni saobraćaj samo kada je potrebno i u poznatim granicama, da se poveže sa našim postojećim bekendom i da radi u svim našim proizvodima, od Linux servera do mobilnih aplikacija.

Šta je Mystic

Mystic je pravi L3 tunel: prenosi IPv4 i IPv6 saobraćaj celog uređaja, a DNS ide kroz tunel. Ako tunel padne, klijent blokira direktan izlaz na mrežu, uključujući IPv6 i DNS, umesto da tiho propusti saobraćaj mimo njega.

Glavne odluke u dizajnu:

• ✦Standardna kriptografija. Rukovanje je Noise IK iz istog Noise okvira na kom je napravljen WireGuard. Transporti koriste obične TLS 1.3 i QUIC. Sopstvene šifre ne izmišljamo.
• ✦Tri prava transporta. Običan UDP za brzinu, HTTP/3 preko QUIC-a i HTTP/2 preko TLS 1.3. To su prave implementacije protokola, a ne imitacija njihovih zaglavlja.
• ✦Jedna logička sesija. Kada se putanja pogorša, veza prelazi na drugi transport. Sesija i IP adresa korisnika unutar tunela ostaju iste, a svaka putanja ima sopstvene ključeve.
• ✦Adaptivni režimi. Podrazumevano radi laki režim, čiji je cilj brzina bliska WireGuard-u. Režimi sa maskiranjem uključuju se kada mreža postane lošija.
• ✦Maskiranje po stvarnim snimcima. U jačim režimima veličine paketa i pauze između njih prate statističke profile snimljene sa stvarnog saobraćaja. Profili su potpisani i prihvataju se samo provereni.
• ✦Strog budžet za dodatni saobraćaj. Dopunjavanje i pozadinski saobraćaj mogu da dodaju najviše 10% korisnim bajtovima u svakom smeru tokom sesije. Pozadinski saobraćaj ide samo kroz autentifikovani tunel i nikada se ne šalje servisima trećih strana.
• ✦Kontrola kod operatera. Svaki čvor čuva sopstvenu listu korisnika. Isključivanje ili brisanje korisnika projektovano je tako da u roku od jedne sekunde zaustavi sve njegove veze na svim transportima, a privremena nedostupnost bekenda ne isključuje one koji već imaju pristup.
• ✦Prenosivo jezgro. Jezgro u Rust-u ne zavisi od TUN uređaja, baze podataka, HTTP API-ja ni Linux sistemskih poziva. Isti kod treba sada da radi na Linux-u, a kasnije u aplikacijama za iOS i Android.

Po čemu se Mystic razlikuje od postojećih protokola

Većina gradivnih blokova Mystic-a već negde postoji. Više transporta, dopunjavanje saobraćaja i pravi HTTP stekovi nisu novost, i ne tvrdimo da smo bilo šta od toga izmislili. Novo je kombinacija: jedna L3 sesija preko više transporta, adaptivni kontroler sa merljivom cenom i SDK koji je naš.

Mystic ćemo upoređivati sa ovim protokolima na istom hardveru, sa fiksiranim verzijama i podešavanjima. Metodologiju planiramo da objavimo zajedno sa rezultatima, uključujući slučajeve u kojima Mystic gubi.

Šta obećavamo, a šta ne

Za prvu zatvorenu betu postavili smo merljive ciljeve:

• ✦u lakom režimu najmanje 80% propusnosti WireGuard-a u korisničkom prostoru na istoj mašini;
• ✦najviše 5 ms dodatnog kašnjenja na 95. percentilu;
• ✦najviše 10% dodatnog saobraćaja za dopunjavanje i pozadinski saobraćaj;
• ✦opoziv pristupa u roku od jedne sekunde.

To su ciljevi za prijem, a ne rezultati. Ako ih prototip ne dostigne, u aplikacijama zadržavamo postojeće protokole i ne prebacujemo korisnike na Mystic.

Jednako je važno šta Mystic ne obećava. Nije neotkriv: pravi TLS i QUIC i pažljivo maskiranje otežavaju analizu saobraćaja, ali je ne čine nemogućom, i taj rizik ćemo meriti na podacima na kojima sistem nije podešavan. Ne može da pomogne ako je IP adresa servera blokirana na svim transportima. I nije alat za anonimnost: kao i kod svakog VPN-a sa jednim čvorom, čvor vidi vaš saobraćaj na izlasku iz tunela. Ono što možemo da obećamo je minimum logova: čvor ne beleži odredišne adrese ni sadržaj saobraćaja, metrike nemaju oznake pojedinačnih korisnika, a radni logovi se čuvaju sedam dana.

Zašto ćemo ga koristiti u svojim proizvodima

• ✦Jedno jezgro za sve aplikacije. Prestajemo da održavamo zasebne integracije tuđih motora i dobijamo jedan životni ciklus sesije na Linux-u, iOS-u i Android-u.
• ✦Sopstveni format protokola i SDK. Sami odlučujemo kada i kako se protokol menja i ne čekamo tuđu mapu puta.
• ✦Kontrolisana cena. Dodatni saobraćaj je uvek u poznatom budžetu, pa se kapacitet servera i troškovi mogu planirati.
• ✦Integracija bez prepisivanja. Mystic se povezuje sa našim postojećim bekendom preko API-ja za upravljanje. Naplata i nalozi ostaju gde su bili.
• ✦Brza kontrola pristupa. Opoziv pristupa i promena ključeva deo su protokola, a ne dodatak.

Prelazak će biti postepen i opcion. Prvi korisnici dobiće Mystic tek posle nezavisne bezbednosne provere, a postojeći protokoli ostaju u našim aplikacijama kao alternativa.

Zašto je kod zatvoren najmanje tri godine

Izvorni kod Mystic-a nećemo objaviti najmanje tri godine, dakle ne pre oktobra 2029. Da li ćemo ga posle toga otvoriti, zavisiće od zrelosti protokola.

Važno je precizno reći zašto. Zatvoren kod ne štiti korisnike. Njihova bezbednost počiva na standardnoj kriptografiji i nezavisnoj proveri, a rizik od analize saobraćaja smanjuju dizajn protokola i merenja, a ne skrivanje koda. Naši razlozi su praktični:

• ✦Format protokola će se menjati. Prva verzija je eksperimentalna, a nezavisna provera može da zahteva izmene. Objaviti je sada značilo bi pozvati tuđe implementacije formata koji nameravamo da menjamo.
• ✦Prvo provera, pa tuđi projekti. Ne želimo da drugi grade proizvode na protokolu koji još nije prošao spoljnu kriptografsku proveru i stvarna merenja.
• ✦Fokus. Mi smo mali studio. Podrška otvorenom protokolu znači issues, kompatibilnost i rad sa zajednicom, a to vreme sada pripada proizvodu.
• ✦Napravljen je pre svega za naše proizvode. Jezgro, API i alati za operatere projektovani su oko našeg bekenda i naših aplikacija.

U međuvremenu planiramo da ovde pišemo o napretku i podelimo rezultate merenja kada ih budemo imali.

Šta sledi

Plan ima pet faza. Prva je ponovljiva izgradnja i ugovori. Druga je šifrovani UDP tunel sa zaštitom od ponavljanja. Treća dodaje HTTP/3 i HTTP/2, prenos sesije i trenutni opoziv pristupa. Četvrta donosi snimljene profile saobraćaja i budžete. Peta obuhvata merenja, fuzzing, oporavak posle kvarova i nezavisnu bezbednosnu proveru, posle čega se odlučuje o zatvorenoj beti. Naša procena je 12 do 16 inženjerskih nedelja plus spoljna provera. Datum izdanja ne navodimo: deo posla je istraživanje, a provera može da promeni protokol.

Prvo izdanje cilja Linux server i klijent za komandnu liniju. Aplikacije za iOS i Android na istom jezgru izaći će u posebnom izdanju.