VPN nasıl çalışır? Normal insanlar için teknik açıklama

VPN nasıl çalışır? Cihazın seçtiğin bir sunucuya şifreli tünel kurar, her paketi onun üzerinden gönderir, ve o sunucu trafiğini kendi IP'sini kullanarak gerçek hedefe iletir. Sen ile VPN sunucusu arasındaki ağı izleyen birine, gördükleri tek bir adrese giden şifreli gürültü. VPN sunucusunun ötesini izleyen birine, trafiğin sunucudan geldiği gibi görünür, senden değil.

30 saniyelik versiyon bu. Bu yazının geri kalanı her adımı gerçek protokol detayıyla açar — çünkü "şifreli tünel" çok ilginç makineyi gizleyen bir ifade. VPN handshake'i sırasında gerçekte ne olur, paket seviyesinde encapsulation ne demek, DNS'in neden tünel üzerinden ayrı gitmesi gerekir, IP maskeleme nasıl çalışır (sihir değil, NAT) ve üç ana protokolün boru sisteminde nasıl farklı olduğunu anlatacağız.

Ağ derecesi olmadan sistemi anlamak isteyenler için yazıldı.

30 saniyelik versiyon

Bir VPN istemcisi kurar ve connect'e basarsın. Perde arkasında:

1. İstemci ve sunucu handshake yapar. Kim olduklarını birbirlerine kanıtlarlar ve paylaşılan şifreleme anahtarları üzerinde anlaşırlar. Bir veya iki round trip.
2. OS trafiği tünele yönlendirir. İstemci OS'a "her şeyi bu sanal ağ adaptörü üzerinden gönder" der. Tünel artık varsayılan rota.
3. Her paket şifrelenir, sarılır ve gönderilir. Orijinal paket (mesela Wikipedia'ya yönelik) şifrelenir ve VPN sunucusuna adreslenmiş yeni bir dış paketin içine konur. Ağın bakış açısından, sadece VPN sunucusuyla konuşuyorsun.
4. Sunucu açar ve iletir. İç paketi şifre çözer, hedef olarak Wikipedia'yı görür ve kendi IP'sini kaynak olarak kullanarak iletir. Wikipedia sunucuya yanıtlar, sunucu süreci tersine çevirir.
5. DNS aynı tünelden geçer. wikipedia.org araması şifreli tünel üzerinde çalışır ve VPN sağlayıcısının DNS sunucusunda çözülür, ISP'inkinde değil.

Tüm boru hattı bu. Geri kalanı her adımın nasıl uygulandığındaki varyasyon.

Adım 1: handshake ve anahtar değişimi

Şifreleme yalnızca her iki taraf da bir anahtar üzerinde anlaştığında çalışır. Handshake o anahtarı, her byte'ın potansiyel olarak izlendiği bir ağ üzerinde kurar.

Modern VPN protokolleri bunun için Diffie-Hellman veya eliptik eğri varyantı X25519 kullanır. İki taraf birer public-private anahtar çifti üretir, public yarıları değişir ve o sırrın hiçbir zaman teli geçmediği halde aynı paylaşılan sırrı bağımsız olarak hesaplar. Her byte'ı yakalayan bir dinleyici onu türetemez.

Her protokol bunu farklı uygular:

WireGuard. Bir round trip. İstemcin Noise-protocol başlatma gönderir; içinde geçici public anahtarın ve kimliğin (sunucunun statik public anahtarıyla şifrelenmiş). Sunucu kendi geçici public anahtarıyla yanıtlar. Her iki taraf da HKDF aracılığıyla simetrik oturum anahtarları türetir ve veri göndermeye başlar. Sağlıklı ağda handshake süresi: 100 ms veya altı.

OpenVPN. Tam TLS 1.2 veya TLS 1.3 handshake'i, bir tarayıcının HTTPS sitesine bağlanırken yaptığı aynı gidiş gelişler. ClientHello, ServerHello, sertifika değişimi, anahtar değişimi, tamamlandı. Daha çok round trip, daha çok byte, daha çok CPU. Handshake süresi: yavaş ağlarda 500 ms ile bir saniyenin üzerinde.

VLESS Reality. Gerçek meşru bir web sitesine (SNI hedefi) TLS 1.3 handshake. Reality protokolü bağlantıyı o hedefin TLS sertifikasına kriptografik olarak bağlarken trafiği farklı bir VPN sunucusuna yönlendirir. Bir ağ gözlemcisine handshake, SNI hedefini ziyaret eden birinden ayırt edilemez. VPN kimlik doğrulaması TLS oturumu içinde UUID kimliği üzerinden olur.

Handshake'ten sonra her tarafın simetrik oturum anahtarları var. Simetrik şifreleme hızlı; asimetrik (public-key) yavaş. Handshake ucuz simetrik oturumu verimli kurar. HTTPS aynı paterni aynı sebep için kullanır.

Adım 2: encapsulation, fiziksel tunneling değil

"Tünel" kelimesi insanların bazı fiziksel ayrımları, halka açık internete paralel özel bir yolu hayal etmesine sebep olur. Gerçeklik daha ilginç. VPN tüneli sadece encapsulation: bir paketi başka bir paketin içine koymak.

Wikipedia'ya yönelmiş normal bir IP paketi düşün. Bir başlığı (kaynak: cihazın, hedef: Wikipedia'nın IP'si) ve bir payload'u (HTTP isteğin) var. Tünel ayaktayken istemcin tüm paketi alır, şifreler ve VPN sunucusuna adreslenmiş yeni bir dış paketin içine sokar. Orijinal paket artık yeni zarfın içinde gizli.

Sen ile VPN sunucusu arasındaki yönlendiriciler sadece dış zarfı görür. "Bunu VPN sunucusuna gönder" diyen dış başlığa göre yönlendirirler. Geldikten sonra sunucu payload'ı şifre çözer, içindeki orijinal paketi bulur ve ileri iletir.

Bu hile (bir IP paketinin başkasını sarması) internetteki her "tunneling" protokolünün arkasındaki mekanizma. GRE, IPsec, WireGuard, OpenVPN: aynı temanın varyasyonları. Encapsulation, VPN istemcisinin kurduğu sanal ağ adaptöründe olur (Windows'ta Wintun, Linux'ta TUN, macOS'ta utun). OS normal bir ağ arayüzü görür; VPN istemcisi oraya yönlendirilen her paketi keser, şifreler ve sonucu gerçek ağ üzerinden gönderir.

Adım 3: transit sırasında şifreleme

Handshake oturum anahtarları ürettikten sonra protokol bunları her trafik paketini şifrelemek için kullanır. Şifre seçimi hem güvenlik hem performans için önemli.

ChaCha20-Poly1305. Yerleşik kimlik doğrulamalı stream cipher. Donanım AES hızlandırması olmayan cihazlarda hızlı (eski telefonlar, düşük-uçlu router'lar). WireGuard yalnızca bunu kullanır. OpenVPN destekler. ChaCha20 son on yılda tasarlanan protokoller için modern varsayılan.

AES-256-GCM. Block-cipher karşılığı. 2010'dan beri her Intel ve AMD CPU'sundaki AES-NI donanım talimatları bunu masaüstü donanımda en hızlı seçenek yapar. OpenVPN'in modern varsayılanı. WireGuard kullanmaz (WireGuard yazarları gömülü kullanım için AES-NI bağımlılığını önlemek üzere bilerek ChaCha20 seçti).

AES-128-GCM. Aynı aile, daha küçük anahtar. Marjinal olarak daha hızlı, marjinal olarak daha az paranoyak. Modern protokoller varsayılan olarak 256.

"GCM" ve "Poly1305" kısımları önemli: kimlik doğrulama tag'leri. Şifreleme tek başına saldırganın trafiğini okuyamayacağını söyler; kimlik doğrulama saldırganın tespit edilmeden değiştiremeyeceğini söyler. Şifreleyen ama kimlik doğrulamayan VPN bozuktur. Her modern protokol kimlik doğrulamalı şifreleme (AEAD) kullanır.

Her paket replay saldırılarını önleyen bir sayaçla bağımsız olarak şifrelenir. Saldırgan paket yakalayıp daha sonra yeniden gönderirse, sayaç kontrolü başarısız olur ve alıcı atar.

Adım 4: tünel üzerinden DNS çözümü

DNS, wikipedia.org'u bir IP adresine çeviren sistem. Varsayılan olarak OS'un DNS sorgularını DHCP tarafından verilen resolver'a gönderir; bu genelde ISP'in. Bu herhangi bir web trafiğinden önce olur.

DNS yönetimi olmadan VPN kötü sızdırır. Tüneli bağlarsın, tarayıcın OS'tan bank.com aramasını ister, OS aramayı ISP'in DNS sunucusuna gönderir (tünelin dışına), ve ISP'in şifreli tünel asıl trafik için işini yapsa bile ziyaret ettiğin her domain'in listesini alır.

Doğru uygulanan VPN istemcisi DNS'i tünelden yönlendirir. Birkaç mekanizma:

Sistem DNS resolver'ını değiştir. İstemci OS ağ yapılandırmasındaki DNS sunucusunu yalnızca tünel üzerinden ulaşılabilir VPN sağlayıcısının resolver'ına ayarlar. Standart yaklaşım.

Firewall kurallarıyla DNS sızıntılarını blokla. Windows'ta VPN istemcisi tünel dışındaki herhangi bir arayüzde DNS sorgularını bloklamak için Windows Filtering Platform (WFP) filtreleri kullanır. Kemer ve pantolon askısı: bir şey yanlış arayüzden DNS sorgusu göndermeye çalışsa bile firewall atar.

Smart-multi-homed name resolution'ı devre dışı bırak. Windows varsayılan olarak DNS sorgularını birden fazla ağ arayüzüne paralel gönderir ve ilk yanıt veren her ne ise onu kullanır. SMHNR adlı bu Windows özelliği, VPN aktifken bile her sorguda orijinal ISP-sağlanan resolver'a DNS sorgularını sızdırır. Doğru bir VPN istemcisi NRPT (Name Resolution Policy Table) veya registry girişleri aracılığıyla SMHNR'ı devre dışı bırakır.

Tünel yalnızca-IPv4 ise IPv6'yı blokla. Ağın IPv6 destekliyorsa ve VPN IPv6 tunellemiyorsa, IPv6 DNS sorguları tüneli tamamen atlar. Ya IPv6'yı tunelle ya da düpedüz blokla.

DNS yönetimi, çoğu VPN'in ince şekillerde başarısız olduğu yer. Trafiği şifreleyip DNS sızdıran VPN, ISP'ine VPN olmadan sahip olacakları aynı metadata'yı verir. DNS sızıntıları üzerine daha derin bir yazımız var.

Adım 5: NAT ile IP maskeleme

VPN sunucusu iç paketi Wikipedia'ya ilettiğinde bir seçim yapması gerekir: Wikipedia yanıtı nereye göndereceğini nasıl bilir?

Cevap Network Address Translation (NAT). VPN sunucusu giden paketin kaynak IP'sini tünel-tarafı IP'inden kendi public IP'sine yeniden yazar ve eşlemeyi NAT tablosunda kaydeder. Wikipedia yanıtladığında sunucu eşlemeye bakar, hedefi tünel IP'ine geri yazar, paketi şifreler ve tünel üzerinden geri gönderir. Ev router'ının kullandığı aynı NAT, sadece ölçekte.

Wikipedia'nın bakış açısından, isteğin kaynağı VPN sunucusunun public IP'si. Wikipedia o bağlantıdan ev IP'ini türetemez. Bilinen VPN çıkış listelerine karşı IP'yi çapraz kontrol ederlerse VPN kullandığını türetebilirler (çoğu büyük site dolandırıcılık tespiti için yapar) ama seni özel olarak tanımlayamazlar.

Bu aynı zamanda "paylaşılan IP'lerin" neden gizlilik artısı ve kullanılabilirlik eksisi olduğunu da açıklar. Yüzlerce kişi aynı IP'den çıkıyorsa, bir siteye giden trafik herhangi birine atfedilemez. Dezavantaj: paylaşılan IP'ler güvenmeyen siteler tarafından bayrak çekilmesi veya rate-limit'e maruz kalması daha olası (bazı bankalar, bazı captcha'lar, bazı yayın servisleri).

Adım 6: OS yönlendirme hilesi

VPN istemcisi OS'u trafiği tünele göndermeye nasıl ikna eder? Bireysel soketleri keserek değil. Standart yaklaşım sanal bir ağ adaptörü kurmak ve yönlendirme tablosunu o adaptör varsayılan rota olacak şekilde değiştirmek.

İstemci ekler:

• Sanal adaptör üzerinden yeni varsayılan rota (genelde mevcut varsayılanı kaldırmadan üzerine binecek şekilde split rotalar 0.0.0.0/1 ve 128.0.0.0/1 olarak).
• Şifreli dış paketlerin gerçekten cihazından çıkabilmesi için VPN sunucusunun IP'si için orijinal fiziksel adaptör üzerinden spesifik rota.
• DNS sunucusu tünel-tarafı resolver'a ayarlanır.

Her giden paket (VPN sunucusuna adreslenenler dışında) artık sanal adaptöre yönlendirilir. VPN istemcisi onları alır, şifreler, encapsulate eder ve sonucu fiziksel adaptör üzerinden gönderir. Kill switch özelliği aynı katmanda yaşar: tünel düşerse, istemci ya rotaları var olmayan bir gateway'e yönelmeye devam ettirir (trafik blackhole olur) ya da tünel yeniden bağlanana kadar trafiği bloklayan firewall kuralları kurar.

Protokoller boru sisteminde nasıl farklı

Ortak iskeleti kapsadık. Her protokol detayları farklı doldurur.

WireGuard. Yalnızca UDP. Sabit boyutlu handshake (148 byte başlatma, 92 byte yanıt). Yalnızca ChaCha20-Poly1305. Oturum durumu IP/port çifti yerine statik kimliklerle anahtarlandığı için ağlar arasında zarif şekilde dolaşır. Kullanıcı alanı uygulamaları (boringtun, Fexyn'in kullandığı) var ama kernel uygulamaları da mevcut. Bağlantı süresi üçünün en düşüğü: bir saniyenin altında, sıkça 500 ms warm altında.

OpenVPN. UDP veya TCP. TLS-tabanlı kontrol kanalı, ayrı veri kanalı. Yapılandırılabilir şifre (modern: AES-256-GCM veya ChaCha20-Poly1305). Sadece kullanıcı alanı, daha büyük kod tabanı, daha çok yapılandırma düğmesi. Daha yavaş handshake, paket başına daha büyük ek yük. Uyumluluk gazisi: WireGuard'ın çalışmadığı ağlarda çalışır, özellikle bağlantının genel şifreli TCP akışına benzediği TCP modunda.

VLESS Reality. Yalnızca TCP. Tüm amaç bir ağ gözlemcisine sıradan HTTPS gibi görünmek. Handshake gerçek meşru siteye (hem istemci hem sunucuda SNI hedefi olarak yapılandırılmış) gerçek bir TLS 1.3 handshake. O TLS oturumu içinde VLESS protokolü kimlik (UUID) ve trafik taşır. Kullandığımız Vision flow (xtls-rprx-vision) VPN trafiği için düşük ek yüklü iç çerçeveleme ekler. Ham throughput için WireGuard'dan daha yavaş ama WireGuard ve OpenVPN'in açıkça bloklandığı ortamlarda hayatta kalır.

Modern bir istemci ağ başına seçer. Hızlı, açık ağlar: WireGuard. WireGuard'ı bloklayan ama genel TLS'e izin veren ağlar: VLESS Reality. İkisini de bloklayan ama OpenVPN-şekilli trafiğe izin veren ağlar: son fallback olarak OpenVPN. Fexyn'in rotation engine'i bunu otomatik yapar.

ISP'in VPN açık vs kapalı gördüğü

VPN kapalı. ISP'in bağlandığın her sunucunun IP'sini, DNS aracılığıyla aradığın domainleri ve verinin ne zaman aktığını görür. HTTPS içeriğini okuyamazlar ama TLS handshake'lerinde domain olan SNI'yi okuyabilirler — bu onlara farklı bir açıdan aynı domain görünürlüğünü verir.

VPN açık, iyi-uygulanan istemci. ISP'in bir IP (VPN sunucusu), ona akan şifreli byte'lar ve zamanlama paternleri görür. DNS sorguları tünel üzerinden geçer, böylece ISP onları okuyamaz. SNI artık gerçek trafiğin için görünmez, çünkü ISP'in gördüğü tek TLS handshake VPN sunucusuna (veya Reality ile SNI hedefine, ki genelde hedefin hakkında hiçbir şey ifşa etmeyen popüler bir site). ISP'in genelde VPN kullandığını fingerprint edebilir ama hangi siteleri ziyaret ettiğini değil.

Güven kayması bu listede görünür. ISP'in sahip olduğu her şeyi kaybeder. VPN sağlayıcısı kazanır. Loglama politikası ve sağlayıcı güveni herhangi tek bir teknik özellikten daha çok önemli.

Performans ek yükü

VPN iki maliyet ekler: CPU'nda şifreleme işi ve trafik yolunda ekstra hop.

CPU. Modern AES ve ChaCha20 tek bir core'da çoklu gigabit/saniye hareket eder. Tipik ev internetinde (1 Gbps altı) CPU ek yükü görünmez.

Gecikme. Hop ekleme, sen, VPN sunucusu ve hedef arasındaki coğrafi mesafeye orantılı gecikme ekler. Yakın çıkış 5-20 ms ekler; kıtalararası hop 100 ms veya daha fazla ekler. Gezinme ve yayın bunu iyi emer; rekabetçi oyun emmez.

Throughput. WireGuard paket başına yaklaşık 60 byte ekler (dış IP/UDP başlıkları artı kimlik doğrulama tag'i), 1500 byte MTU'da yaklaşık %4 çerçeveleme ek yükü. OpenVPN'in ek yükü %10'a yakın. Gerçek throughput etkisi genelde paket başına matematikten daha büyük çünkü VPN sunucusu kullanıcı sayısı için yetersiz boyutlandırılmışsa darboğaz olabilir. Kendi testimizde WireGuard sağlıklı bağlantıda toplam bant genişliğinin %5-10'una mal oluyor; OpenVPN %15-25'ine. VLESS Reality TLS çerçevelemesi nedeniyle daha fazla varyansla aralarında.

Sonuç

VPN trafiğini şifreleyerek ve encapsulate ederek, seçilen bir sunucu üzerinden göndererek ve NAT ile ileri ileterek çalışır. Handshake oturum anahtarları kurar. Encapsulation yönlendiricilerin sadece dış paketi görmesini sağlar. DNS, kill switch ve yönlendirme tablosu değişiklikleri aksi takdirde gerçek ağ kimliğini sızdıracak uç durumları yakalar.

Mekanizma iyi anlaşılmış ve sihirli değil. Gizlilik avantajı hangi tarafın üzerinden yönlendirdiğine ve gördüğüyle ne yaptığına bağlı. Ağ koşullarına eşleşen bir protokol, güven gereksinimlerine eşleşen bir sağlayıcı ve sızıntı vektörlerini (DNS, IPv6, SMHNR, kill switch) düzgün yöneten bir istemci seç.

SSS

Şifreli, encapsulate edilmiş IP paketleri. Orijinal paketin (gerçek kaynağı ve hedefiyle) şifrelenir ve VPN sunucusuna adreslenmiş yeni bir dış paketin içine konur. Ağı izleyen birine gördükleri tek şey dış paket.

Handshake adımı, public-key kriptografisi (WireGuard'da X25519, OpenVPN ve Reality için TLS'te RSA veya ECDHE) kullanarak o anahtarlar hiçbir zaman teli geçmeden simetrik oturum anahtarları kurar. İki tarafın da oturum anahtarları olduğunda, her paket yerleşik kimlik doğrulamayı içeren hızlı simetrik şifre (ChaCha20-Poly1305 veya AES-256-GCM) ile şifrelenir.

DNS aramaları web trafiğinden önce olur ve tünelden bağımsız olarak sızabilir. Varsayılan olarak OS'un DNS'i DHCP tarafından verilen resolver'a gönderir; bu genelde ISP'in. Bir VPN istemcisi DNS'i tünele aktif olarak yönlendirmeli ve sızıntı yollarını (Windows SMHNR, IPv6 fallback, OS DNS'ini atlayan tarayıcı DoH) bloklamalı.

TUN sanal layer-3 (IP) arayüzü; TAP sanal layer-2 (Ethernet) arayüzü. VPN'ler neredeyse her zaman TUN kullanır çünkü sadece IP paketleri taşımaları gerekir. TAP yerel ağları köprülemek gibi Ethernet emülasyonu gerektiren kullanım durumları için.

Evet, sıkça. WireGuard paketlerinin tanınabilir şekli vardır; UDP üzerinde OpenVPN'in ayırt edici başlığı vardır. Şifreli trafiğin bile fingerprinting araçlarının kullanabileceği boyut ve zamanlama paternleri vardır. VLESS Reality en dirençli olanı çünkü gerçek popüler siteye gerçek TLS taklit ediyor. "Şifreli" ve "tespit edilemez" farklı sorunlar.

Kill switch olmadan, OS orijinal varsayılan rotaya geri döner ve trafik gerçek IP'inden açıkça akar. Kill switch ile istemci ya yönlendirme tablosunu (artık var olmayan) tünel gateway'ine yönelmeye devam ettirir (trafik blackhole) ya da tünel yeniden bağlanana kadar tüm trafiği bloklayan firewall kuralları kurar.

Evet, ağ operatörüne karşı. Wi-Fi erişim noktası VPN sunucusuna şifreli tünel görür. Trafiğini okuyamazlar, hangi siteleri ziyaret ettiğini göremezler veya içerik enjekte edemezler. HTTPS bunun çoğunu zaten korur; VPN derinlemesine savunma ekler ve SNI gibi metadata'yı korur.

Daha küçük handshake (bir round trip vs. birkaç), paket başına daha küçük ek yük, optimize edilmesi daha kolay basit kod tabanı ve müzakere ek yükünü önleyen kasıtlı tek-şifre tasarımı. WireGuard 2015'te eski protokollerin derslerini akılda tutarak tasarlandı.

Ağda: hayır. ISP'in göreceği gibi VPN sunucusuna şifreli byte görürler. Cihazda: belki. İş cihazında kurumsal yönetim yazılımı (MDM, EDR) varsa, o yazılım VPN'e girmeden önce OS seviyesinde trafiği okuyabilir. Ağ katmanı gizliliği gerçek; cihaz katmanı gizliliği cihaza bağlı.