Mi az a VPN-protokoll, és miért számít a választás
A protokoll az app és a szerver közötti megállapodás: hogyan cserélnek kulcsokat, hogyan titkosítják és csomagolják be a csomagokat, hogyan áll helyre egy megszakadt kapcsolat. Az előfizetésed általában többet is tartalmaz; az app kapcsolatonként választ egyet, a váltás pedig egy menüpont, nem elköteleződés.
A választás három helyen mutatkozik meg. Az átviteli sebesség és az akkumulátor-fogyasztás azért tér el, mert a protokollok csomagonként más-más mennyiségű CPU-t használnak. A stabilitás akkor különbözik, amikor hálózatok között váltasz, vagy szigorú tűzfal mögött ülsz. És más a láthatóság is: egyes alagutakat a hálózati eszközök játszi könnyedséggel VPN-forgalomként sorolnak be, másokat épp azért építettek, hogy kerüljék a besorolást. Egyik protokoll sem nyer mindhárom téren — ezért létezik a menü.
WireGuard: sebesség és kis kódbázis
2026-ban a WireGuard az alapértelmezett válasz. Nagyjából négyezer sornyi kernelkód a régebbi megoldások több százezer sorával szemben, egyetlen modern titkosítási csomag (ChaChaCha20-Poly1305) egy egyeztetési mátrix helyett, és egy kézfogás, amely egyetlen oda-vissza út alatt lezajlik. A gyakorlatban ez közel vonalsebességű átvitelt jelent átlagos hardveren, gyors újracsatlakozást és mérsékelt akkumulátor-fogyasztást telefonon.
Ennek két tervezési sajátossággal fizet meg. Először: egy szabványos WireGuard-szerver minden peernek rögzített címet ad az alagúton belül, ezért a szolgáltatónak saját réteget kell hozzáadnia — belső címek rotálása, a peer állapotának törlése lecsatlakozás után —, hogy ne jöjjön létre felhasználónként állandó azonosító; hogy ez megtörténik-e, az a szolgáltatón múlik, nem a protokollon. Másodszor: a WireGuard UDP felett fut, jellegzetes kézfogási mintával, így a VPN-forgalmat azonosítani kívánó hálózati eszközök könnyen kiszúrják, az ismeretlen UDP-t eldobó hálózatok pedig teljesen megakasztják.
OpenVPN: kiforrottság és rugalmasság
Az OpenVPN a 2000-es évek eleje óta van éles használatban, és ez a kor az előnye: két évtizednyi átvizsgálás, támogatás gyakorlatilag minden platformon és routeren, és konfigurációs lehetőségek szinte bármilyen hálózati elrendezéshez. Futhat UDP felett a sebességért vagy TCP felett az elérhetőségért, és a 443-as TCP-porton legalább azt a portot használja, amelyet a tűzfalak ritkán zárnak le — bár a TLS-kézfogása így is eltér egy böngészőétől, ezért a besorolás továbbra is lehetséges.
Az ár a súly. Az OpenVPN felhasználói térben dolgozza fel a csomagokat, minden csomagnál átlépve a kernelhatárt, így ugyanazon a hardveren az átviteli sebessége jellemzően töredéke a WireGuardénak, az újracsatlakozás pedig nem azonnali, hanem másodpercekben mérhető. A kódbázis és az OpenSSL-függőség nagyságrendekkel nagyobb, ami nagyobb auditálandó felületet jelent. Továbbra is ez a megfelelő eszköz régi routereken, tanúsítványt igénylő vállalati környezetben és olyan hálózatokon, ahol az UDP használhatatlan.
IKEv2/IPsec: telefonra tervezve
Az IKEv2 megkülönböztető jellemzője a MOBIKE, egy szabványos kiterjesztés, amelynek köszönhetően a felépített alagút túléli a hálózati cím változását. Kilépsz a Wi-Fi hatóköréből LTE-re, és a munkamenet új kézfogás nélkül vándorol át — pontosan az az esemény, amely más protokollokat hívás közben megszakít. Az iOS és az Android natív támogatása, a titkosítást az operációs rendszer IPsec-moduljára bízva, alacsonyan tartja az akkumulátor-fogyasztást, ezért gyakori alapértelmezés a mobilappokban.
A gyengéi környezetiek. Az IKEv2-nek szüksége van az 500-as és 4500-as UDP-portra, amelyeket a korlátozó hálózatok — szállodai Wi-Fi, irodai tűzfalak — gyakran blokkolnak, saját TCP-tartaléka pedig nincs. A konfigurációja is kevésbé átlátható, mint a WireGuardé: az IPsec-paraméterek egyeztetés útján dőlnek el, és egy rosszul beállított szerver a tervezettnél gyengébb beállításoknál is megállapodhat. Mobilon erős választás, ellenséges hálózatokon törékeny.
Xray/VLESS: alagút, amely HTTPS-nek látszik
A VLESS az Xray projekt könnyűsúlyú átviteli protokollja: minimális keretezés, saját beépített titkosítás nélkül, úgy tervezve, hogy egy valódi TLS-munkameneten belül fusson. Mivel a titkosítási réteg szabványos TLS — ugyanaz a protokoll, amelyet minden weboldal használ —, egy 443-as porton futó VLESS-kapcsolat kívülről egy szokásos tanúsítvány-kézfogásnak és egy azt követő, átláthatatlan titkosított adatfolyamnak látszik, vagyis pontosan úgy néz ki, mint bármely HTTPS-munkamenet.
Ez olyan hálózatokon számít, amelyek felismerik, majd lassítják vagy eldobják az ismert VPN-protokollokat. Ahol a WireGuard kézfogása vagy az OpenVPN TLS-sajátosságai elárulják az alagutat, egy jól beállított Xray-végpont a statisztikán kívül semmilyen megkülönböztető mintát nem ad az osztályozónak. Az ára: több mozgó alkatrész a szerveren, a TLS-feldolgozás (és nem a kernelszintű hálózatkezelés) által korlátozott sebesség, valamint a mainstream protokollokhoz képest kisebb kliens-ökoszisztéma. Az Aurora a mindennapi sebességhez WireGuardot használ, a saját csomópontjain pedig Xray/VLESS-t azokhoz a hálózatokhoz, ahol a hagyományos alagutak megbízhatatlanok.
Melyik protokollt válaszd
Kezdd a WireGuarddal, és csak akkor válts, ha valami konkrét dolog nem működik. A gyakorlati útmutató:
- Alapértelmezés, sebesség, játék, nagy letöltések — WireGuard
- Telefon, amely egész nap Wi-Fi és mobiladat között ugrál — IKEv2, vagy WireGuard, ha az újracsatlakozás elég gyorsnak tűnik
- Szigorú tűzfal, amely csak webforgalmat enged át — OpenVPN TCP 443-on, vagy még inkább Xray/VLESS
- Hálózat, ahol a felismerhető VPN-protokollok elakadnak vagy megszakadnak — Xray/VLESS TLS felett
- Régi router vagy vállalati tanúsítványkövetelmény — OpenVPN
- Nem vagy biztos benne — hagyd az appot automatikus módban, és engedd, hogy ebben a sorrendben váltson tartalékra