World of Tanks Proxy: Tünelin Kapsadığı ve Kapsamadığı Akışlar

Bir proxy kurulumunun oyunda beklendiği gibi çalışmamasının nedeni çoğu zaman yanlış kimlik bilgisi değil, yanlış kapsamdır. World of Tanks istemcisi aynı anda hesap servisine, savaş sunucusuna, başlatıcının yama kaynağına ve portal sayfalarına konuşur. Bu dördü aynı protokolü kullanmaz ve bu yüzden aynı kuraldan etkilenmez.

Ayrımın kritik parçası şudur: savaş oturumu ağırlıklı olarak UDP taşır. Klasik bir HTTP proxy yalnızca TCP tünelleyebildiğinden oyun oturumu o tünele hiç girmez. SOCKS5 ancak UDP ASSOCIATE yöntemi hem proxy sunucusunda hem oyun istemcisinde destekleniyorsa UDP taşıyabilir ve masaüstü oyun istemcilerinin çoğu bu yöntemi kullanmaz. Geriye kalan kapsam giriş, mağaza, portal ve indirme trafiğidir; bu da azımsanacak bir alan değildir.

İkinci nokta beklentiyle ilgilidir. Proxy bir hızlandırıcı değil, bir yönlendirme kararıdır; araya koyduğu durak gecikmeyi genellikle artırır. Aşağıdaki bölümler hangi senaryonun gerçekten fayda ürettiğini, hangisinin yalnızca karmaşıklık eklediğini ayırıyor.

İstemci gerçekte kaç ayrı uç noktaya konuşuyor?

Başlatıcıyı açtığınızda konuşulan ilk yer hesap servisidir. Burada bir oturum jetonu üretilir ve karşı tarafta görünen adres, proxy kullanıyorsanız çıkış sunucusunun adresidir. Bu aşama sıradan bir HTTPS isteğidir; tünelden sorunsuz geçer ve kurulumun doğru olup olmadığını ilk anlayacağınız yer de burasıdır.

İkinci uç nokta savaş sunucusudur. Oyun burada durum güncellemelerini sürekli ve küçük paketler hâlinde alışveriş eder; gecikmeye duyarlı olan bölüm yalnızca budur. Üçüncüsü başlatıcının yama dağıtımıdır ve hacimce en büyük trafik buradan akar, çünkü sürüm paketleri bir içerik dağıtım ağından çekilir. Dördüncüsü portal, mağaza ve envanter sayfalarıdır; bunlar teknik olarak tarayıcı trafiğinden farksızdır.

Bu dördünün üstüne kabile sohbeti, arkadaş listesi ve çökme raporu gibi yan servisler biner. Kurulumdan sonra tek bir ekranı açıp “çalışıyor” demek yanıltıcıdır; hepsini ayrı ayrı deneyin. Başlatıcı açılıyor ama savaşa girilemiyorsa sorun kimlik doğrulamada değil, kuralın kapsamındadır ve bu iki durumun çözümü birbirine benzemez.

Hangi akışın hangi protokolü kullandığını bilmeden yazılan kural her zaman yarım kapsar. UDP’nin bir tünelden nasıl geçebildiğini merak ediyorsanız SOCKS5 UDP desteği yazısı mekanizmayı adım adım gösteriyor; oradaki koşulların ikisi birden sağlanmadıkça oyun akışı tünel dışında kalır.

Eş bağlantı, NAT tipi ve delik açma nerede devreye giriyor?

NAT tipi tartışması büyük ölçüde oyuncuların birbirine doğrudan bağlandığı yapımlardan gelir. Bu oyunun savaş oturumu ise sunucu otoriteli çalışır: istemciniz başka bir oyuncunun makinesine değil, yayıncının küme sunucusuna bağlanır. Bağlantıyı siz başlattığınız için yönlendiricinizin adres çevirme tablosunda dönüş yolu kendiliğinden açılır ve ev kullanıcısının port yönlendirmeye ihtiyacı olmaz.

Delik açma (hole punching) iki tarafın da adres çevirisi arkasında olduğu durumlarda anlam kazanır. Aracı bir sunucu, iki eşin dışarıdan görünen adres ve port bilgisini karşılıklı paylaştırır; ardından her iki taraf aynı anda dışarı paket gönderir ve eşlemeler iki yönlü açılmış olur. Sesli iletişim bileşenleri ile bazı başlatıcıların eş destekli yama dağıtımı bu tekniğe yaklaşır. Bir proxy devredeyken mekanizma bozulur, çünkü karşı tarafın gördüğü adres artık sizinki değil, çıkış sunucusunundur ve o adres üzerinde sizin denetiminiz yoktur.

Tablonun üstüne bir katman daha biner: taşıyıcı seviyesinde adres paylaşımı. Mobil hatların ve bazı ev bağlantılarının arkasında birden çok abone tek bir genel adresi paylaşır ve size ait, denetleyebileceğiniz bir gelen eşleme yoktur. CGNAT davranışı bu nedenle proxy kararından önce anlaşılmalıdır. Proxy çıkışı da benzer bir çeviri katmanı ekler ama ikisi aynı şey değildir; proxy ile NAT arasındaki fark ayrımı net biçimde koyuyor.

Kuralı yönlendiriciye yazmak neyi değiştirir?

Ev tipi yönlendiricilerin çoğunda doğrudan bir “proxy” alanı bulunmaz; olan şey ya bir tünel istemcisidir ya da belirli trafiği bir adrese yönlendiren bir kuraldır. Bu ayrım sonucu doğrudan etkiler. Cihaza yazılan ayar yalnızca o cihazı kapsar, buna karşılık o cihazdaki her süreci etkiler. Ağ geçidine yazılan kural ise tüm cihazları kapsar: konsollar, televizyonlar ve akıllı ev cihazları dâhil.

Oyun için bu genelde istediğinizden geniş bir kapsamdır. Aynı ağdaki ikinci bilgisayarın güncellemeleri, telefonların arka plan senkronizasyonu ve video servisleri de aynı çıkıştan akmaya başlar. Kotalı bir havuzda bunun sonucu birkaç saat içinde görünür. Kapsamı daraltmanın en pratik yolu kuralı oyunun çalıştığı makineye, mümkünse yalnızca ilgili sürece yazmaktır.

Ağ geçidi tarafındaki seçenekler için yönlendirici üzerinden proxy kullanımı, tek makine için Windows 11 proxy ayarları adımları gösteriyor. İkisini aynı anda etkin bırakmayın: çift katman hangi kuralın geçerli olduğunu belirsizleştirir ve bir arıza çıktığında nereye bakacağınızı bilemezsiniz.

Hesap katmanı: iki adımlı doğrulama ve konum tutarlılığı

Yayıncı hesabı yalnızca bu oyuna değil, aynı kimlikle erişilen diğer başlıklara ve portal hizmetlerine de açılan bir anahtardır. Bu yüzden hesap tarafındaki en değerli önlem proxy değil, iki adımlı doğrulamadır. Çıkış adresiniz ne olursa olsun, ikinci faktör olmadan bir giriş denemesi tamamlanmaz; proxy bu korumanın yerine geçmez ve geçmeye de çalışmamalıdır.

Proxy’nin hesap tarafında ürettiği asıl etki konum tutarlılığıdır. Yıllardır tek bir ülkeden açılan bir hesap bir anda başka bir kıtadan giriş yaparsa bu, servis tarafında olağandışı bir değişimdir ve ek doğrulama istenebilir. Çözüm karmaşık değildir: çıkış ülkesini hesabın olağan ülkesiyle aynı tutun, gerekmedikçe değiştirmeyin ve değiştirmeniz gerekiyorsa bunu iki uç arasında gidip gelerek değil, bir kez yapın.

Üçüncü nokta oturumun kendisidir. Oturum bir jetonla taşınır; adres değişse bile jeton aynı kalır. Yani rotasyonlu bir çıkış oturumu “yenilemez”, yalnızca aynı oturumun görünen konumunu oynatır. Giriş yapılan senaryolarda sabit bir çıkış her zaman daha tutarlı bir tablo üretir; rotating proxy asıl olarak oturum gerektirmeyen, açık veri okunan işler için tasarlanmıştır.

Giriş isteği tünelden geçerken sırayla ne oluyor?

HTTP proxy üzerinden bir HTTPS hedefine gidildiğinde ilk mesaj şifreli değildir: istemci proxy’ye CONNECT sunucu.example:443 biçiminde hedefi düz metin olarak bildirir. Proxy hedefe TCP bağlantısını açar ve başarılıysa istemciye tünelin kurulduğunu bildirir. TLS el sıkışması ancak bundan sonra başlar ve uçtan uca istemci ile hedef arasında yürür; proxy taşıdığı baytları okuyamaz.

Bunun pratik karşılığı ikili bir tablodur. Proxy sağlayıcısı parolanızı veya oyun içi yazışmanızı göremez, ama hangi ana bilgisayara bağlandığınızı görür ve kaydedebilir. Log kayıtları ve gizlilik bu ayrımı açıyor; sahibi belirsiz ücretsiz çıkışlarda temkinli olmanın nedeni de burada yatıyor.

Dizinin son adımı kritik olanıdır. İstemci savaş oturumu için UDP akışını başlattığında bu akış CONNECT tünelinden geçmez, çünkü o tünel tanım gereği yalnızca TCP taşır. Akış ya doğrudan olağan hattınızdan çıkar ya da ağ bu trafiği engelliyorsa hiç kurulamaz. Belirti tanıdıktır: giriş başarılı, ana ekran açılıyor, savaşa girerken bağlantı kurulamıyor.

Bu noktada iki yol vardır. Ya UDP akışını olağan hattınızda bırakırsınız — ki çoğu kurulumda doğru karar budur — ya da hem proxy sunucusu hem istemci tarafı UDP ASSOCIATE destekliyorsa SOCKS5 üzerinden taşımayı denersiniz. İkincisinin çalıştığını varsaymayın, ölçün; çalışmadığında belirti sessizdir ve kurulum doğru görünmeye devam eder.