Naraka: Bladepoint ve Proxy: Kapsam, Hesap Güvenliği ve Uyum

Naraka: Bladepoint için proxy kurmayı düşünen çoğu kullanıcı, tek bir ayarın oyunun tamamını kapsadığını varsayar. Uygulamanın ağ davranışı bunu doğrulamaz: istemci aynı anda bir kimlik servisiyle, bir içerik dağıtım altyapısıyla, bir mağaza katmanıyla ve bir tur oturumuyla konuşur. Bu dördü aynı taşıma protokolünü kullanmaz, dolayısıyla aynı kuralla yönlendirilmez.

Pratikte bunun karşılığı nettir: tarayıcınızda veya sisteminizde tanımladığınız bir proxy, oyunun web tarafındaki isteklerini kapsayabilir; tur sırasında üretilen küçük ve sık paketler ise büyük olasılıkla olağan hattınızdan çıkmaya devam eder. Kurulumu değerlendirirken “çalışıyor mu” sorusunu tek bir ekrana bakarak yanıtlamak bu yüzden yanıltıcıdır.

İkinci başlık hesap tarafıdır. Proxy bir kimlik değiştirme aracı değildir; yalnızca isteğin nereden geldiğini değiştirir. Oturum jetonunuz, cihaz parmak iziniz, platform hesabınızın kayıtlı ülkesi ve ödeme aracınız aynı kalır. Bu sayfa boyunca kapsam, güvenlik ve uyum üç ayrı başlık olarak ele alınıyor.

İstemci ağ üzerinde kaç ayrı işi aynı anda yürütür?

Bir oturumu baştan sona izlerseniz dört istek ailesi görürsünüz. Birincisi kimlik katmanıdır: platform hesabınızla oturum açılır, oyun profiliniz eşleştirilir ve envanter verisi çekilir. Bunlar HTTPS üzerinde taşınan, boyutu küçük ama oturumun kurulması için zorunlu isteklerdir. İkincisi mağaza, etkinlik ve görev ekranlarıdır; oyunun içinden açılsalar da arka planda web isteği gibi davranırlar ve TCP üzerinde çalışırlar.

Üçüncüsü içerik dağıtımıdır. Karakter paketleri, sezon içeriği ve düzeltme yamaları hacmin ezici çoğunluğunu üretir; bir yama gününde aktarılan veri, aylarca süren normal oynanışın toplamını geçebilir. Dördüncüsü ise turun kendisidir: hareket, nişan, kanca kullanımı ve isabet bilgisi gecikmeye çok duyarlı, küçük ve sık paketler hâlinde taşınır. Bu ailenin ağırlıklı olarak UDP üzerinde çalışması, proxy tartışmasının merkezindeki teknik gerçektir.

HTTP/HTTPS proxy’si bir CONNECT tüneli açar ve o tünel yalnızca TCP taşır. Dolayısıyla sistem geneli bir HTTP proxy’si tanımlasanız bile tur paketleri o tünele girmez. SOCKS5’te ise UDP ASSOCIATE adında bir mekanizma vardır; ancak bunun çalışması için hem proxy sunucusunun bu yöntemi açık tutması hem de oyun istemcisinin SOCKS5 üzerinden UDP göndermeyi desteklemesi gerekir. Oyun istemcilerinin büyük çoğunluğu bu ikinci koşulu sağlamaz. Mekanizmanın nasıl kurulduğu SOCKS5 UDP desteği yazısında ayrıntılı anlatılıyor.

Farklı bir ülkeden giriş yapınca hesap tarafında ne olur?

Hesap servisleri, oturum açma isteğini yalnızca parolayla değerlendirmez. İsteğin geldiği ağ, daha önce kullandığınız cihaz ve giriş zamanı birlikte bakılan sinyallerdir. Birkaç ay boyunca aynı ülkeden bağlanan bir hesap aniden başka bir kıtadan giriş denediğinde, bu servisler ek doğrulama isteyebilir. Bu bir ceza değil, olağan bir koruma davranışıdır ve proxy kullanan kullanıcıların en sık karşılaştığı sürtünmedir.

Bu yüzden proxy kararını hesabın alışkanlıklarıyla birlikte vermeniz gerekir. Çıkış ülkesini olağan kullanım ülkenizle tutarlı tutmak, ani sıçramalardan kaçınmak ve aynı gün içinde birbirinden uzak adresler arasında geçiş yapmamak bu sürtünmenin çoğunu ortadan kaldırır. Rotating bir havuz üzerinden giriş yapmak, oturumun her isteğini farklı bir adresten göndermek anlamına geldiği için hesap servislerinde en zor karşılanan senaryodur; giriş yapılan işlerde sticky bir çıkış tercih edin.

İki adımlı doğrulamayı proxy’nin alternatifi gibi görmeyin; ikisi farklı sorunları çözer. Proxy isteğin nereden geldiğini değiştirir, iki adımlı doğrulama ise parolanız ele geçse bile oturum açılmasını engeller. Yeni bir çıkış denemeden önce doğrulama yöntemini kurmuş olmak, ek doğrulama ekranıyla karşılaştığınızda işin tıkanmamasını sağlar. Kurtarma e-postanızın erişilebilir olduğundan ve doğrulama uygulamanızın yedeklendiğinden emin olun.

• Çıkışı değiştirmeden önce iki adımlı doğrulamayı etkinleştirin ve yedek kodları saklayın.
• Oyun hesabınızın bağlı olduğu platform hesabında da aynı korumayı açın.
• Aynı oturum içinde ülke değiştirmeyin; değişiklik gerekiyorsa oturumu kapatıp yeniden açın.
• Proxy erişim bilgilerinizi oyun arkadaşlarınızla paylaşmayın; paylaşılan çıkış paylaşılan risktir.

Anti-cheat ve hizmet şartları: sınır tam olarak nerede?

Rekabetçi oyunlar istemci bütünlüğünü denetleyen bir katman çalıştırır. Bu katman genellikle sistem düzeyinde kurulur, süreçleri ve belleği gözlemler ve beklenmedik bir müdahale gördüğünde oturumu sonlandırır. Ağ tarafındaki bir proxy bu denetimin doğrudan hedefi değildir; ama trafiği yakalayıp yeniden şifreleyen, istemcinin ağ çağrılarına araya girerek müdahale eden araçlar farklı bir kategoridedir ve sorun çıkarabilir.

Uyum açısından ayrım şu şekilde kurulur. Kendi bağlantınızı bir ara sunucu üzerinden çıkarmak, kurumsal ağlarda olağan bir yönetim pratiğidir. Buna karşılık oyunun erişim kurallarını dolanmaya, birden çok hesabı aynı anda yönetmeye ya da eşleştirme sistemini yanıltmaya dönük her kullanım hizmet şartlarıyla çelişir. Bu sayfa yalnızca birinci kategoriyi anlatır ve ikinci kategoriyi önermez.

Pratik sonuç: proxy’yi oyunun kendisine değil, oyunun etrafındaki web katmanına uygulayın. Hesap paneli, destek formu, topluluk sayfaları ve mağaza görünümü için tarayıcıya özel bir profilde proxy kullanmak hem işinizi görür hem de istemcinin ağ davranışını değiştirmez. Oyun sürecini bir tünele sokmaya çalışmak, kazanç üretmeden risk ve gecikme eklemenin en hızlı yoludur.

Kapsam kararı: hangi istek tünele girer, hangisi girmez?

Kapsam sorusunu iki kümeyle düşünmek en pratiğidir. Birinci kümede TCP üzerinde taşınan ve bir proxy istemcisinin okuyabildiği istekler vardır: hesap ve giriş sayfaları, mağaza ve etkinlik ekranları, launcher’ın indirme istekleri, destek ve topluluk formları. İkinci kümede ise tünelin dışında kalanlar bulunur: tur içi paket akışı, ses sohbeti ve bazı istemcilerde QUIC üzerinden yapılan istekler.

İki kümenin kesişiminde tek bir konu durur: alan adı çözümü. Hedef adını kimin çözdüğü, hangi içerik dağıtım düğümüne yönlendirileceğinizi belirler. HTTP proxy’de istemci hedefi CONNECT sunucu.example:443 biçiminde bildirir ve çözümü proxy yapar. SOCKS5’te davranış istemciye bağlıdır; adresi kendi ağında çözen bir istemci proxy’ye yalnızca IP verir. Bu ayrımın sonuçları CONNECT metodu ve HTTPS tünelleme yazısında adım adım anlatılıyor.

Protokol seçerken uyumluluğu belirleyici alın. Tarayıcı işlerinde HTTP ve SOCKS5 çıkışların ikisi de çalışır; oyun launcher’ları ve yardımcı araçlar ise çoğu zaman yalnızca bir alan sunar. Panelinizde hangi satırın hangi protokole ait olduğunu okumadan değerleri istemciye yazmak, kurulum hatalarının en yaygın başlangıcıdır. Kimlik doğrulamanın kullanıcı adı–parola ile mi yoksa IP yetkilendirmesiyle mi yapıldığını da aynı anda netleştirin; kimlik doğrulama yöntemleri arasındaki fark sahada sık karıştırılır.