Stellaris İçin Proxy: Kapsam, UDP ve NAT Gerçekleri

Eş-eş bağlantı, NAT tipi ve delik açma

Oyunculardan birinin oturumu taşıdığı modelde bağlantı, iki ev ağı arasında kurulur. Her iki taraf da NAT arkasındadır: yönlendirici, iç ağdaki adresi dış adrese eşler ve dışarıdan gelen bir bağlantıyı ancak daha önce açılmış bir eşleme varsa içeri alır. Bu yüzden iki NAT arasında bağlantı kurmak için delik açma (hole punching) denen bir el sıkışma yöntemi kullanılır: iki taraf da aynı anda dışarı paket gönderir ve yönlendiricilerde karşılıklı eşleme oluşur.

Proxy bu tabloya girmez. Bir proxy çıkışı, delik açma için gereken kaynak port davranışını korumaz; üstelik araya giren düğüm eşlemeyi kendi üzerinden kurar ve karşı tarafa sizin yönlendiricinizin değil çıkışın adresi görünür. Çoğu kurulumda bunun sonucu, eş-eş oturumun proxy üzerinden hiç kurulamamasıdır. NAT ile proxy’nin neden farklı işler yaptığı proxy ve NAT arasındaki fark yazısında karşılaştırılıyor.

Simetrik NAT ya da taşıyıcı düzeyinde adres paylaşımı (CGNAT) kullanan bir hatta durum daha da sıkışır: dışarıdan gelen bağlantı kabul edilmez ve yönlendiricide port yönlendirme ayarı bile yapamazsınız. Bu durumda işe yarayan çözüm proxy değil, sağlayıcıdan gerçek bir genel adres istemek ya da barındırma işini bağlantısı uygun olan oyuncuya bırakmaktır.

Bir ayrımı da netleştirmek gerekir: delik açma bir güvenlik önlemini aşma yöntemi değildir, iki tarafın da isteyerek katıldığı standart bir bağlantı kurma tekniğidir. İki oyuncu birbirine bağlanmak istediğinde yönlendiricilerin bu isteği tanıyabilmesi için gereken adımdır. Proxy’nin bu adımı desteklememesi bir eksiklik değil, tasarımının doğal sonucudur: proxy istemci adına bağlantıyı kendisi kurar, sizin soketinizin dış dünyadaki izini korumaz.

Kurulum sonrası doğrulama: neyi nasıl kanıtlarsınız?

Kural yazmak, trafiğin gerçekten oradan geçtiğini göstermez. Doğrulamanın ilk adımı çıkış adresini okumaktır; ikinci adım hangi süreçlerin kapsandığını ölçmektir. İkisi farklı sorulardır ve farklı araçlar ister.

Alan adı çözümü çoğu kurulumda gözden kaçan yerdir. SOCKS5 kullanırken istemci hedefi kendi ağında çözüp proxy’ye yalnızca IP verebilir; bu durumda hangi sunucuya bağlandığınız yerel DNS sunucunuza görünür ve size yakın bir dağıtım düğümü seçilirken bağlantı başka ülkeden çıkar. DNS leak testi bunu ölçer.

İkinci kontrol, proxy’nin isteğe başlık ekleyip eklemediğidir. Bazı çıkışlar X-Forwarded-For ya da Via başlığı ekler; bu, karşı tarafın bağlantının bir ara düğümden geldiğini ilk istekte görmesi demektir. Proxy anonimlik testi hangi başlıkların taşındığını raporlar.

Üçüncüsü dayanıklılık kontrolüdür. Bir oyun istemcisi ve arka plandaki güncelleme servisi birlikte beklediğinizden fazla eşzamanlı bağlantı açar; tavan dolduğunda belirti hata mesajı değil sessiz kopmadır. Limitin ne anlama geldiğini ve nasıl planlanacağını eşzamanlı bağlantı limiti yazısı anlatıyor.

Hangi çıkış türü, hangi lokasyon?

Tür seçimi işin niteliğine bağlıdır. İndirme ağırlıklı bir kullanımda belirleyici değişken bant genişliğidir; burada datacenter çıkış hem en hızlı hem en ucuz seçenektir. Ev ağı profiline yakın bir çıkış gerektiğinde residential ya da ISP tercih edilir, ama bunların bant genişliği hatta bağlıdır ve büyük transferlerde maliyeti hızla büyür.

Lokasyon kararında tek kural vardır: yolu uzatmayın. Çıkışı hem size hem hedefe yakın tutmak gereksiz kıtalar arası turu engeller. Türkiye’den bağlanıp Türkiye’deki bir arkadaşınızla oynuyorsanız başka bir kıtadaki bir çıkış yalnızca zarar getirir.

Paylaşım derecesi de türden az önemli değildir. Kalabalık bir havuzdaki çıkış, doğru türde olsa bile yoğun saatlerde değişken davranır. Uzun süren bir oturumda bu değişkenlik, tek seferlik ölçümde görünmeyen kopmalar olarak karşınıza çıkar.

Adres türü ayrıca teşhis kolaylığını da belirler. Statik bir çıkışta bir sorunla karşılaştığınızda değişkeni sabitlemiş olursunuz: aynı adresten tekrar deneyip sonucu karşılaştırabilirsiniz. Havuzdan her seferinde farklı bir adres veren bir kurulumda ise aynı testi iki kez yapamazsınız, çünkü ikinci denemede bambaşka bir yol üzerinden çıkmış olursunuz. Uzun oturumlu bir oyunda bu, ürün özelliklerinden okunmayan ama sahada en çok hissedilen farktır.

Belirti ve neden: hızlı teşhis tablosu

Sertifika uyarısı bu listedeki en ciddi maddedir. Düzgün kurulmuş bir HTTPS proxy’si TLS oturumuna karışmaz, yalnızca şifreli baytları taşır. Uyarı görüyorsanız trafiğiniz bir yerde açılıp yeniden şifreleniyor demektir; hesap bilgisi taşıyan bir oturumda bunu geçmek, kimlik bilgilerinizi araya giren tarafa okunabilir hâlde vermek olur.

Diğer maddelerin ortak yöntemi aynıdır: tek seferde tek değişken. Çıkışı, protokolü ve kural katmanını birlikte değiştirirseniz sonuç ne olursa olsun nedenini öğrenemezsiniz. Denediklerinizi kısa bir listeye yazmak, ikinci kez aynı yolu dolaşmanızı önler.

Gecikme bütçesi ve uzun oturumlarda süreklilik

Proxy araya bir durak koyar; toplam yol uzar. Bu nedenle proxy kurmak oyunun gecikmesini iyileştirmez, çoğu kurulumda bir miktar artırır. Tur temposunun yavaş olduğu bir oyunda birkaç on milisaniye hissedilmez, ama uzun oturumlarda asıl mesele gecikme değil süreklilik olur: kısa bir kesinti bile eşitlemeyi bozar ve oturumdan düşmenize yol açabilir.

Sürekliliği etkileyen üç şey vardır. Birincisi çıkışın yükü: paylaşımlı havuzlarda yoğun saatler ölçümü değiştirir. İkincisi oturum penceresidir: sticky süresi iş oturumunuzdan kısa ayarlanmışsa adres siz fark etmeden değişir ve bağlantı düşer. Üçüncüsü ev hattınızın kendi kararlılığıdır; proxy bunu düzeltmez, üzerine kendi payını ekler.

Ölçümü bir kez yapıp bırakmayın. Aynı çıkışı günün farklı saatlerinde ölçmek, tek seferlik bir testin gizlediği değişkeni açığa çıkarır. Uzun bir oturum planlıyorsanız ölçümü oturumun başlayacağı saatte yapın.

Son olarak kapsam kararını yeniden hatırlatmak gerekir: bu oyunda proxy’den beklenebilecek şey erişim ve denetlenebilirliktir. Kendi hattınızdan, kendi ülkenizden, tanıdığınız oyuncularla oynuyorsanız araya katman koymanın somut bir karşılığı yoktur.

Uyum, gizlilik ve proxy’nin gereksiz olduğu durumlar

Bu sayfa erişim, gizlilik ve ağ yönetimi senaryolarını konu alır. Oyunların ve mağazaların kullanım koşullarına uymak kullanıcının sorumluluğundadır; hesap çoğaltma, otomatik oynatma ya da oyunun güvenlik önlemlerine müdahale eden hiçbir kullanım burada anlatılmaz ve önerilmez.

Gizlilik tarafında bilinmesi gereken şey nettir: proxy sağlayıcısı şifreli içeriği okuyamaz, ama hangi adreslere bağlandığınızı görebilir ve kaydedebilir. Bu yüzden sağlayıcı seçimi teknik bir karardan çok bir güven kararıdır. Kayıt politikasını okumadan hesap bilgisi taşıyan bir akışı bir çıkışa emanet etmeyin.

Proxy’nin gerçekten işe yaradığı durumlar dardır: kurum ya da kampüs ağından çıkarken denetlenebilir tek bir adres kullanmak, birden çok makineyi tek bir çıkıştan yönetmek, bir mağaza sayfasının başka bir ülkeden nasıl göründüğünü kaydetmek ya da bir ağ sorununun kaynağını yolu değiştirerek ayırt etmek. Bunların dışında kalan çoğu senaryoda doğru cevap, katmanı hiç eklememektir.