Merkeziyetsiz Tünelleme ve P2P Onion Yönlendirme Rehberi

Merkeziyetçi yapıdan merkeziyetsiz tünellemeye geçiş

"Gizli" VPN sağlayıcınızın aslında düz metin günlüklerinizden (log) oluşan bir dağın tepesinde oturan, süslenmiş bir aracıdan ibaret olduğunu fark ettiğinizde o tuhaf ürpertiyi hiç hissettiniz mi? İnternet Servis Sağlayıcısı (ISS) gözetlemesini, tek bir kurumsal darboğazla takas etmiş olmamız tam bir ironi; ancak merkeziyetsiz tünellemeye (decentralized tunneling) geçişin nihayet ana akım haline gelmesinin nedeni de tam olarak bu.

Geleneksel VPN mimarisi, 2000'lerin başındaki istemci-sunucu (client-server) zihniyetinden kalma bir yadigardır. "Güvenli" bir ağ geçidine bağlanırsınız, ancak bu ağ geçidi hackerlar ve devlet aktörleri için devasa bir neon tabela gibidir. Eğer o tek sunucu çökerse veya el konulursa, gizlilik kalkanınız anında yok olur.

• Merkezi Veri Tuzakları (Honey Pots): Milyonlarca kullanıcı, tek bir şirkete ait bir avuç veri merkezi üzerinden trafik yönlendirdiğinde, saldırganlar için görmezden gelinemeyecek kadar cazip bir "tek hata noktası" (single point of failure) oluşur.
• Güven Paradoksu: Vergi cennetindeki bir CEO'nun kayıt tutmadığına dair verdiği söze güvenmek zorundasınız; ancak arka uç sistemlerinin açık kaynaklı denetimi olmadan, aslında tamamen körü körüne hareket ediyorsunuz.
• Ölçeklenebilirlik Darboğazları: Bir Cuma gecesi hızınızın aniden düştüğünü hiç fark ettiniz mi? Bunun sebebi, merkezi düğümlerin (nodes) modern 4K yayın akışı ve yoğun geliştirici iş yüklerinin getirdiği anlık trafik patlamalarını kaldıramamasıdır.

Artık ağın merkezi bir beyne dayanmadığı "Haritala ve Kapsülle" (Map & Encap) mantığına doğru ilerliyoruz. Tek bir sağlayıcı yerine, herkesin bant genişliğini paylaşabildiği dVPN (Merkeziyetsiz VPN) düğümlerini kullanıyoruz. Bu mimari —özellikle APT (Pratik Tünelleme Mimarisi) gibi yapılar— "uç" (edge) adreslerini "iletim çekirdeğinden" (transit core) ayırarak internetin ölçeklenmesini sağlar.

APT çerçevesinde, Giriş Tünel Yönlendiricileri (ITR) ve Çıkış Tünel Yönlendiricileri (ETR) kullanılır. ITR'yi, normal verilerinizi alıp özel bir tünel başlığıyla saran (kapsülleme/encapsulation) bir "giriş kapısı" olarak düşünebilirsiniz. ETR ise bu paketi varış noktasında açan "çıkış kapısıdır". Varsayılan Haritalayıcılar (DM) ise bir rehber hizmeti gibi çalışarak ITR'ye paketi tam olarak hangi ETR'ye göndereceğini söyler; böylece çekirdek yönlendiricilerin dünyadaki her bir cihazı tek tek ezberlemesine gerek kalmaz.

Deasa bir MPLS faturası ödemeden 500 farklı lokasyondaki satış noktası (POS) verilerini güvence altına almaya çalışan bir perakende zincirini düşünün. Merkezi bir merkez (hub) yerine, her mağazanın bir ağ (mesh) içindeki küçük bir sıçrama noktası (hop) olarak görev yaptığı düğüm tabanlı bir VPN hizmeti kullanırlar. Eğer bir mağazanın interneti kesilirse, P2P ağı tüneli otomatik olarak komşu bir düğüm üzerinden yeniden yönlendirir.

Geliştiriciler için bu, statik bir IP'ye bağlı olmayan WireGuard arayüzleriyle çalışmak anlamına gelir. Güçlendirilmiş bir Linux düğümünde yapılandırma şuna benzer görünebilir:

[Interface]
PrivateKey = <DÜĞÜM_ÖZEL_ANAHTARINIZ>
Address = 10.0.0.5/32
ListenPort = 51820

[Peer]
PublicKey = <UZAK_DVPN_DÜĞÜM_ANAHTARI>
AllowedIPs = 0.0.0.0/0
Endpoint = 192.168.1.100:51820

PersistentKeepalive = 25

Bu kurulum çok daha dirençlidir; çünkü bir paketin nereye gitmesi gerektiğine dair "haritalama" işlemi, bir kurumsal genel merkezdeki veritabanına hapsedilmek yerine tüm ağa (mesh) dağıtılmıştır. Doğrusunu söylemek gerekirse, gizli kalmak için birilerinden izin istemeyi bırakmamızın vakti çoktan gelmişti.

Sırada: Bu paketlerin ağ üzerindeki sıçramalardan nasıl sağ çıktığını inceleyeceğimiz P2P onion yönlendirme mimarisine derin bakış.

P2P onion yönlendirme mimarisine derinlemesine bakış

Bir veri paketinin, üç farklı VPN tünelinden ve iki protokol dönüşümünden geçerken nasıl olup da "aklını kaçırmadan" veya meta verilerini kaybetmeden hayatta kaldığını hiç merak ettiniz mi? Bu durum aslında dijital bir "Inception" (Başlangıç) senaryosu gibidir; eğer mimariyi doğru kurmazsanız, tüm yapı paket kayıpları ve devasa gecikme süreleri (latency) içinde çöker.

P2P onion yönlendirme kurulumunda sadece "sıcak patates" oynamıyoruz. Her düğüm (node), veriyi nasıl "sarmalayacağına" kendisi karar verir. Buradaki "onion" (soğan) katmanlarından bahsettiğimizde, iki ana hamle ile karşı karşıyayız:

• Kapsülleme (Encapsulation): Bir IPv4 paketinin tamamını alıp bir IPv6 başlığına (header) yerleştirmek (veya tam tersi). Orijinal başlık, dış katman için artık sadece "veri" haline gelir.
• Dönüştürme (Conversion): NAT-PT protokolünde olduğu gibi başlığı doğrudan yeniden yazmak. Bu yöntem daha "yıkıcıdır" ancak eski nesil donanımlar için bazen zorunludur.

Bir Web3 VPN ağında, giriş düğümünüz trafiğinizi WireGuard ile kapsülleyebilirken, bir aktarım (relay) düğümü veri çıkış düğümüne ulaşmadan önce başka bir şifreleme katmanı daha ekleyebilir. Bu yöntem, geleneksel Tor ağından çok daha zor engellenir; çünkü "eşleştirme" (mapping) halka açık bir aktarıcı listesinde tutulmaz, ağ (mesh) üzerinden dinamik olarak keşfedilir.

Geleneksel yönlendirme, "mesafe-vektörü" (hedefe kaç durak -hop- var?) mantığını kullanır. Ancak bir P2P onion ağında bu yeterli değildir. Paketin durumunu (state) bilmeniz gerekir. Eğer elimde bir IPv4 paketi varsa, bunu doğrudan sadece IPv6 destekleyen bir aktarıcıya gönderemem.

Lamali ve ark. (2019) tarafından yapılan çalışmada ele alındığı üzere, bunun yerine bir yığın-vektörü (stack-vector) kullanıyoruz. Bu yöntem, basit "mesafe" kavramını bir "protokol yığını" ile değiştirir. Düğüme şunu söyler: "Bu paketi hedefine ulaştırmak için şu spesifik kapsülleme dizisine ihtiyacın var." Çalışma, en kısa yol üstel olarak uzun olsa bile, gereken maksimum protokol yığını yüksekliğinin aslında polinom düzeyinde olduğunu kanıtladı — spesifik olarak en fazla λn² (burada n, düğüm sayısıdır).

Bu, geliştiriciler için devrim niteliğindedir. İç içe geçmiş tünelleri yönetmek için 5.000 satırlık yapılandırma dosyalarına ihtiyacımız olmadığı anlamına gelir; düğümler yığını kendileri "öğrenir". Örneğin, uzak bir klinikteki eski IPv4 cihazlarını modern bir IPv6 veri merkezine bağlamaya çalışan bir sağlık kuruluşu, P2P düğümlerinin tünel uç noktalarını otomatik olarak müzakere etmesine izin verebilir.

Bir düğümü güçlendiriyorsanız (hardening), muhtemelen arayüzlerinizde bu yığınların nasıl göründüğüne bakıyorsunuzdur. Bir düğümün belirli bir yığın için "önbellek isabetini" (cache hit) nasıl işleyebileceğine dair kaba bir fikir şöyledir:

# Bu komutun çıktısı, yolun hata ayıklamasını yapabilmeniz için 
# tam kapsülleme dizisini gösterir (örneğin, IPv6 içine sarılmış, 
# WireGuard içine sarılmış IPv4).
dvpn-cli route-lookup --dest 10.0.0.5 --current-stack "ipv4.wireguard.ipv6"

ip link add dev dvpn0 type wireguard
wg setconf dvpn0 /etc/wireguard/stack_config.conf

Buradaki asıl güzellik, ağın (mesh) hataları kendi kendine çözmesidir. Bir aktarım düğümü çökerse, yığın-vektörü mantığı farklı bir kapsülleme seti kullanarak "mümkün olan en kısa yolu" bulur. Bu, kendi kendini iyileştiren (self-healing) bir yapıdır. Açıkçası, bunu bir kez iş başında gördükten sonra statik VPN tünellerine geri dönmek, 5G dünyasında çevirmeli telefon kullanmak gibi hissettiriyor.

Sırada: Merkeziyetsiz internet erişiminde güvenlik zorlukları var; çünkü rastgele düğümlere güvenmek tamamen farklı bir uzmanlık alanı gerektiriyor.

Merkeziyetsiz internet erişiminde güvenlik zorlukları

P2P (uçtan uca) bir ağa geçmenin tüm güvenlik sorunlarınızı sihirli bir değnekle çözeceğini düşünüyorsanız size kötü bir haberim var: Aslında tek bir kurumsal "merkezi kutu" yerine dijital bir "vahşi batı" ile takas yapıyorsunuz. Merkezi bir VPN'den merkeziyetsiz bir yapıya (dVPN) geçmek gizlilik için harikadır, ancak beraberinde tamamen yeni bir dizi zorluk getirir.

Ağa katıldığınızda ilk düğüme (node) nasıl güvenebilirsiniz? Merkezi bir liste olmadığı için çoğu dVPN, Tohum Düğümler (Seed Nodes) veya DHT (Dağıtık Karma Tablosu) Önyükleme yöntemini kullanır. İstemciniz, diğer aktif eşlerin listesini almak için önceden tanımlanmış birkaç güvenilir "tohum" adrese bağlanır ve oradan ağın geri kalanını kendi başına keşfeder.

İçeri girdiğinizde, düğümlerin komşularını doğruladığı bir güven ağı (web of trust) modeli kullanırız:

• Komşudan Komşuya Doğrulama: Bir düğümün haritalama bilgilerini yayınlamasına izin verilmeden önce, eşleri yerleşik bağlantılar üzerinden o düğümün kimliğini doğrular.
• İmza Yayılımı (Signature Flooding): Bir anahtar yeterli sayıda güvenilir komşu tarafından imzalandığında, tüm ağa yayılır.
• Kötü Niyetli Düğüm Tespiti: Eğer bir düğüm, aslında sahip olmadığı bir IP aralığı için trafik yönlendirebileceğini iddia etmeye başlarsa, gerçek sahip bu çelişkili mesajı görür ve bir uyarı tetikler.

P2P bant genişliği paylaşımındaki en büyük risk ise ayrılma (churn) oranıdır. %99,99 çalışma süresine sahip bir veri merkezi sunucusunun aksine, ev tabanlı bir dVPN düğümü, birinin kedisi güç kablosuna takıldığı için anında yok olabilir. Bunu çözmek için veri odaklı hata bildirimi sistemi kullanıyoruz. Tüm ağın "mükemmel" bir harita tutmaya çalışması yerine, hata bir paket iletilemediği anda yerel olarak yönetilir.

Varsayılan Haritalayıcı (DM), yeni bir yol seçerek ve Giriş Tünel Yönlendiricisine (ITR) yerel önbelleğini güncellemesini söyleyerek ağır iş yükünü üstlenir. Bu süreç, yeniden yönlendirmenin hızlı kalmasını sağlamak için daha önce bahsettiğimiz λn² verimliliğine dayanır.

Sırada: Bu düğümlerin teknik bakımını inceleyeceğimiz gizlilik devriminde güncel kalmak konusu var.

Gizlilik Devrimini Yakından Takip Etmek

Gizlilik ekosisteminin ne kadar hızlı değiştiği gerçekten inanılmaz, değil mi? Güncel kalmak sadece blog yazıları okumaktan ibaret değil; asıl mesele, bu yeni protokollerin veri paketlerinizi gerçekte nasıl işlediğini kavramaktır.

Merkeziyetsiz VPN (dVPN) dünyası sürekli "uçuşa geçecek" projelerin gürültüsüyle dolu, ancak asıl hazine teknik detaylarda gizlidir. Örneğin, bir ağ IPv6 sızıntı korumasını (IPv6 leak protection) nasıl yönetiyor? Geleneksel bir VPN'de, IPv6 trafiği genellikle tüneli tamamen devre dışı bırakarak gerçek IP adresinizin sızmasına neden olur. dVPN bağlamında ise genellikle NAT64 veya 464XLAT yapılarını kullanıyoruz. Bu yöntem, IPv6 trafiğini düğüm (node) seviyesinde IPv4'e (veya tam tersine) dönüştürülmeye zorlar; böylece veriler yerel bir ağ geçidinden dışarı sızmak yerine, şifrelenmiş "yığın-vektör" (stack-vector) yolu içinde kalır.

• Commit'leri takip edin: Sadece web sitesindeki vaatlere güvenmeyin; GitHub'ı kontrol edin. Eğer bir proje WireGuard entegrasyonunu veya düğüm keşif (node-discovery) mantığını son altı aydır güncellemediyse, o proje muhtemelen "zombi" durumundadır.
• Denetim raporları: Gerçek gizlilik araçları, üçüncü taraf güvenlik denetimleri için bütçe ayırır ve bu raporları paylaşır.
• Topluluk forumları: Uzman geliştirici Discord kanalları gibi platformlar, işin gerçek "mutfağının" döndüğü yerlerdir.

Eğer bu konuda ciddiyseniz, muhtemelen halihazırda özel yapılandırmalarla uğraşıyorsunuzdur. Mevcut tünelinizin merkeziyetsiz rotaya gerçekten sadık kalıp kalmadığını kontrol etmenin hızlı bir yolu şudur:

ip route show dev dvpn0
traceroute -n -i dvpn0 1.1.1.1

İnsanların "gizlendiğini" sandığı ancak basit bir hatalı yapılandırılmış API çağrısının gerçek IP'lerini sızdırdığı pek çok kurulum gördüm. Bu, bitmek bilmeyen bir kedi-fare oyunudur.

Sıradaki konumuz: Bant genişliği pazaryeri ve DePIN ödülleri; çünkü günün sonunda birilerinin o elektrik faturasını ödemesi gerekiyor.

Bant Genişliği Pazaryeri ve DePIN Ödülleri

Veri paketlerinin nasıl taşındığından bahsettik, ancak gerçekçi olalım; hiç kimse sadece iyilik olsun diye sonsuza kadar yüksek hızlı bir çıkış düğümü (exit node) işletmez. İşte bu noktada "Bant Genişliğinin Airbnb'si" konsepti veya yaygın adıyla DePIN (Merkeziyetsiz Fiziksel Altyapı Ağları) devreye giriyor.

• Bant Genişliği Madenciliği (Bandwidth Mining): Sadece bir düğümü (node) çevrimiçi tutarak ve trafiği yönlendirerek kripto ödülleri kazanırsınız.
• Tokenlaştırılmış Kaynaklar: Ağın yerel tokenını kullanmak, aktarılan her megabayt için mikro ödemeler yapılabilmesine olanak tanır.
• Teşvik Uyumu: Ödüller, çalışma süresi (uptime) ve "hizmet kalitesine" göre ağırlıklandırılır.

Karşılaşılan en büyük teknik engel ise şudur: Bir düğümün işlediği trafik miktarı hakkında yalan söylemediğinden nasıl emin olabilirsiniz? Bunun için Bant Genişliği Kanıtı (Proof of Bandwidth) protokollerini kullanıyoruz. Bu süreçte, bir "meydan okuyucu" (challenger) düğüm, "kanıtlayıcı" (prover) düğüme şifrelenmiş anlamsız veriler gönderir ve yanıt süresini ölçer. Eğer rakamlar birbirini tutmazsa, akıllı sözleşme ödemeyi serbest bırakmaz.

Eğer ödül sistemini doğru kodlamazsak, düğümler sadece yüksek ödeme yapan trafiğe öncelik verebilir. Bunu engellemek için birçok ağ "stake etme" (pay kanıtı) yöntemini kullanır. Teminat olarak belirli bir miktar token yatırmanız gerekir; eğer kalitesiz hizmet sunarsanız, yatırdığınız bu teminatı kaybedersiniz.

Sırada: Tüm bu parçaları bir araya getiren Pratik Uygulamalar ve Web3 İnternet Özgürlüğünün Geleceği.

Web3 İnternet Özgürlüğünün Pratik Uygulaması ve Geleceği

Web3 internet özgürlüğünün geleceği, tek bir tuşa basılarak gerçekleşecek devasa bir "devrim" anından ibaret değil. Aksine bu süreç, merkeziyetsiz protokollerin mevcut fiber hatlarımızla yan yana var olduğu, kademeli ve karmaşık bir gelişim süreci olacak.

Tüm interneti en baştan icat etmemize gerek yok. Bu mimari dönüşümün güzelliği, "tek taraflı yaygınlaştırma" (unilateral deployment) için tasarlanmış olmasıdır. Tek bir sağlayıcı bile bugün bu hizmetleri sunmaya başlayabilir. Bu P2P (eşten eşe) ağ "adacıkları" arasında köprü kurmak için Varsayılan Eşleştiriciler (DM - Default Mappers) kullanıyoruz.

• Eski Nesil Donanımlarla Birlikte Çalışma: Evinizdeki yönlendiricinin (router) bir P2P ağıyla konuştuğunu bilmesine bile gerek yoktur. Yerel bir ağ geçidi (gateway), "Eşleştir ve Kapsülle" (Map & Encap) mantığını arka planda halleder.
• Boşlukları Doldurmak: Bir veri paketinin "normal" bir web sitesine gitmesi gerektiğinde, çıkış düğümü (ETR - Egress Tunnel Router) kapsülden çıkarma işlemini yönetir.
• Kullanıcı Dostu Soyutlama: Teknik bilgisi olmayan kullanıcılar için bu süreç, arka planda karmaşık yığın-vektör yönlendirmelerini yönetse bile basit bir uygulama gibi görünür.

Geliştirici perspektifinden bakıldığında hedef, bu tünelleri "otomatik" hale getirmektir. Bir düğümün (node) bir "adacık" eşlemesini nasıl kontrol edebileceğine dair hızlı bir bakış:

dvpn-cli map-query --dest 192.168.50.1

[DEBUG] Cache miss. Querying DM anycast...
[INFO] Received MapRec: Destination reachable via ETR 203.0.113.5

Nihai hedef, kapatılması temelde imkansız olan bir ağdır. Bir blokzinciri VPN'ini P2P onion yönlendirmesi ile birleştirdiğinizde, "kapatma düğmesi" olmayan bir sistem yaratmış olursunuz. Daha önce belirttiğimiz gibi, λn² karmaşıklığı sayesinde ağ çökmeden derin ve çok katmanlı bir gizlilik sağlayabiliyoruz.

Bant genişliği paylaşımının (bandwidth sharing) geleceği sadece birkaç kuruş tasarruf etmekten ibaret değil; dijital duvarları aşan küresel bir bağlantı kurmakla ilgilidir. Şu an işler biraz karışık görünebilir ve terminal komutları uğraştırıcı olabilir, ancak temel atıldı. İnternet her zaman merkeziyetsiz olması için tasarlanmıştı; biz sadece onun bu şekilde kalmasını sağlayacak mimariyi nihayet inşa ediyoruz. Her neyse, artık üzerine konuşmayı bırakıp düğümleri (node) ayağa kaldırma vakti. Güvende kalın.