World of Warships Proxy: Protokol Sınırları ve Hesap Katmanı

Bu oyunun ağ davranışını anlamanın kısa yolu, trafiği “gecikmeye duyarlı” ve “hacme duyarlı” diye ikiye ayırmaktır. Deniz savaşı oturumu birinci gruptadır: küçük paketler, sık aralık, düşük tolerans. Portal, mağaza, envanter ve yama dağıtımı ikinci gruptadır: büyük aktarım, gecikmeye kayıtsız.

Proxy bu iki gruba aynı şekilde davranmaz. HTTPS üzerinden ilerleyen her şey CONNECT tüneliyle taşınabilir; oyun akışı ise taşıma katmanında UDP kullandığı için yalnızca UDP ASSOCIATE destekleyen bir SOCKS5 çıkışı ve bunu kullanabilen bir istemci varsa tünele girer. Bu koşul pratikte nadiren sağlanır, dolayısıyla proxy’nin kapsamı kendiliğinden giriş, mağaza ve indirme tarafına daralır.

Üçüncü bir gerçek de baştan söylenmeli: bu kurulum bir performans önlemi değildir. Ek durak gecikmeyi genellikle artırır. Buradaki kazanç hız değil, hangi trafiğin hangi adresten çıktığı üzerinde denetim kurmaktır.

Dört akış, dört farklı profil

Kurulum kararlarının çoğu, akışların profilini bir kez çıkardıktan sonra kendiliğinden netleşir. Giriş ve oturum trafiği tamamen TCP üzerinde yürür, gecikmeye orta düzeyde duyarlıdır ve bir tünelden sorunsuz geçer. Deniz savaşı oturumu bunun tam tersidir: UDP ağırlıklıdır, gecikmeye çok duyarlıdır ve tünel kapsamına girmesi istisnaidir.

Yama dağıtımı üçüncü profildir. Neredeyse tamamen TCP üzerindedir, gecikmeye kayıtsızdır, buna karşılık hacim tarafında baskındır. Mağaza ve envanter sayfaları dördüncüsüdür ve teknik olarak sıradan web trafiğinden ayırt edilemez; proxy kapsamına en kolay giren, en az sürtünme üreten bölüm burasıdır.

Profil çıkarmanın pratik faydası şudur: hangi akışı tünele alacağınıza ideolojiyle değil ölçütle karar verirsiniz. Gecikmeye duyarlı olanı tünel dışında bırakmak, hacme duyarlı olanı kotalı bir çıkıştan uzak tutmak ve geri kalanı yönlendirmek çoğu kurulumda en dengeli sonucu verir.

İki protokolün taşıdığı yük, kimlik doğrulama biçimi ve uygulama uyumu bakımından nerede ayrıştığını görmek isterseniz HTTP ve SOCKS5 farkı karşılaştırması bu ayrımı ayrıntılı biçimde kuruyor.

Hesap katmanında asıl önlem nedir?

Hesap güvenliği tartışmasında proxy’nin yeri dar ve nettir: çıkış adresini değiştirir, kimliği değiştirmez. Oturum bir jetonla taşınır ve adres değişse de jeton aynı kalır. Dolayısıyla “IP değiştirerek hesabı korumak” diye bir mekanizma yoktur; koruma, ikinci faktörle ve güçlü bir parolayla kurulur.

İkinci faktör açıkken bir giriş denemesi, doğru parolayla bile tek başına tamamlanamaz. Bu, çıkışınız paylaşımlı bir havuzdaysa özellikle değerlidir, çünkü aynı adresten geçen başka trafiğin davranışını siz denetlemezsiniz. Paylaşımlı ve ayrılmış çıkış arasındaki bu fark paylaşımlı ve özel proxy karşılaştırmasında ayrıntılandırılıyor.

Konum değişimi ayrı bir başlıktır. Uzun süre tek bir ülkeden açılan bir hesabın aniden başka bir kıtadan görünmesi, servis tarafında olağandışı bir durumdur ve ek doğrulama tetikleyebilir. Bunun çaresi çıkışı hesabın olağan ülkesiyle hizalamak ve gereksiz yere ülkeler arasında gezinmemektir. Seyahat gibi meşru bir nedenle konum gerçekten değiştiyse, kalıcı bir çıkış seçip orada kalmak en az sürtünmeli yoldur.

Üçüncü önlem operasyoneldir: erişim bilgilerini paylaşmayın ve aynı anda hem bir tünel istemcisi hem proxy çalıştırmayın. Çift katman, bir sorun çıktığında hangi bileşenin sorumlu olduğunu anlamayı neredeyse imkânsız kılar.

Koruma bileşenleri ve hizmet şartları proxy’yi nerede sınırlar?

Online oyunların istemci bütünlüğünü denetleyen bileşenleri vardır ve bunların amacı oyun deneyimini korumaktır. Bu sayfa o bileşenlerle ilgili herhangi bir müdahale yöntemi anlatmaz, ima etmez; proxy de böyle bir amaç için uygun bir araç değildir. Ağ katmanındaki bir yönlendirme kararı, istemci tarafındaki bütünlük denetimleriyle ilgisizdir.

Uyum perspektifinden bakıldığında üç sınır sayılabilir. Birincisi, hesabın kayıtlı olduğu bölge ve o bölgeye bağlı kurallar yayıncı tarafından belirlenir; ağ katmanından yapılacak değişiklikler bu kaydı etkilemez. İkincisi, aynı kişinin birden fazla hesapla avantaj üretmesi hizmet şartlarında genellikle sınırlanır ve bu sayfa böyle bir kullanım için yazılmamıştır. Üçüncüsü, ödeme ve mağaza kuralları hesabın faturalandırma bilgilerine bağlıdır, bağlantının geldiği adrese değil.

Proxy’nin meşru ve tartışmasız kullanım alanları ise geniştir: kurumsal ağ yönetimi, hangi akışın hangi kapıdan çıktığını gözlemleme, erişim sorunlarının kaynağını ayırt etme, portal sayfalarının başka bir ülkeden nasıl göründüğünü doğrulama ve test ortamlarında sabit bir çıkış kullanma. Bu senaryoların hiçbiri bir korumayı hedef almaz.

UDP bir tünelden nasıl geçer, geçemediğinde ne olur?

SOCKS5’in UDP tarafı çoğu kullanıcının duyduğu ama az kişinin gerçekten gördüğü bir mekanizmadır. İstemci önce proxy ile TCP üzerinden bir denetim bağlantısı kurar ve UDP ASSOCIATE ister. Proxy kabul ederse istemciye datagramları göndereceği bir adres ve port bildirir. Bundan sonra her datagram doğrudan hedefe değil, bu aktarım noktasına gönderilir.

Önemli ayrıntı şudur: istemci datagramı olduğu gibi göndermez, başına küçük bir başlık ekler. Bu başlık ayrılmış alanı, parçalanma numarasını, adres türünü ve hedef adres ile port bilgisini taşır; asıl yük bunların ardından gelir. Yani oyun istemcisinin yalnızca “SOCKS5 destekliyorum” demesi yetmez, bu çerçeveyi üretebiliyor olması gerekir. Uygulamaların çoğu SOCKS5’i yalnızca TCP için uygular ve UDP tarafını hiç ele almaz.

Koşullar sağlanmadığında olan şey sessizdir ve kafa karıştırıcıdır. İstemci datagramları olağan hattından göndermeye devam eder; kurulum çalışıyor görünür, giriş yapılır, menüler açılır, ama oyun akışı hiçbir zaman tünelden geçmemiştir. Ağınız UDP çıkışını tamamen engelliyorsa bu kez akış hiç kurulamaz ve belirti bir bağlantı hatası olur.

Mekanizmanın ayrıntıları ve hangi istemcilerin bunu gerçekten desteklediği SOCKS5 UDP desteği yazısında; sürüm farkının neden önemli olduğu ise SOCKS4 ve SOCKS5 karşılaştırmasında ele alınıyor. Kısacası: varsaymayın, deneyin ve sonucu ölçün.