Delta Force için Proxy: Kapsam, Protokol ve Mağaza Katmanı

Delta Force gibi büyük haritalı ve kalabalık modlu bir nişancıda ağ davranışı iki ayrı karaktere bölünür. Bir tarafta hesap, mağaza, sezon içeriği ve pazar yeri gibi tamamen web mantığıyla çalışan istekler vardır. Diğer tarafta, oyunun oynanışını taşıyan sürekli ve küçük paketli bir akış bulunur.

Proxy bu ikisine aynı biçimde davranmaz ve bu, kullanıcıların en sık yanıldığı noktadır. Web katmanı bir tarayıcı kadar uysal davranır; oyun akışı ise yapılandırmanızı çoğu kurulumda görmez bile. Aradaki farkı bilmeden yapılan her ayar, sonuçları yanlış okumaya yol açar.

Aşağıdaki bölümler kuralı hangi seviyeye yazarsanız neyi kapsayacağınızı, ağ cihazının gerçekte ne sunduğunu ve mağaza tarafındaki trafiğin nasıl davrandığını sırayla ele alıyor.

Yönlendiriciye proxy yazılabilir mi?

Ev ve küçük ofis yönlendiricilerinin arayüzünde “proxy” başlığı görmek yaygın değildir. Bu cihazların sunduğu şey genellikle başka üç şeydir: adres dönüştürme (NAT), port yönlendirme ve bazen bir tünel istemcisi. Bunların hiçbiri, ağdaki tek bir uygulamanın isteklerini bir proxy sunucusuna gönderme işi değildir. NAT ile proxy’nin neden farklı katmanlarda durduğunu NAT ve proxy farkı yazısı açıklıyor.

Cihaz seviyesinde gerçekten proxy çalıştırmanın yolu şeffaf (transparent) yönlendirmedir: cihaz belirli portlara giden trafiği yakalar ve bir ara sunucuya iletir. HTTPS söz konusu olduğunda bu yöntemin bedeli ağırdır, çünkü şifreli oturumu açıp yeniden kurmak gerekir. Bu da istemciye kendi sertifikasını tanıtan bir yapı demektir; oyun istemcileri böyle bir yapıyla karşılaştığında bağlantıyı çoğunlukla reddeder. Konunun teknik tarafı TLS sertifika doğrulaması yazısında duruyor.

Bu yüzden pratikte doğru yer cihaz değil, makinedir. Kuralı oyun makinesine yazdığınızda kapsamı da sınırlayabilirsiniz; ağın tamamını kapsayan bir çözüm, konsol ve akıllı televizyon gibi ayarı olmayan cihazlar için cazip görünse de oyun trafiğinde beklenen faydayı vermez. Yönlendirici üzerinden proxy kullanımı yazısı hangi senaryoda hangisinin işe yaradığını karşılaştırıyor.

İki dünya: web isteği ile oyun paketi

Web katmanındaki her şey — giriş, sezon sayfası, mağaza, pazar yeri, arkadaş listesi — TCP üzerinde TLS ile yürür. Bir HTTP proxy bu istekleri CONNECT yöntemiyle açtığı tünelden taşır ve karşı taraf çıkış adresinizi görür. Bu kısım tarayıcıdaki davranışla neredeyse birebir aynıdır; beklentinizi buraya kurarsanız yanılmazsınız.

Oyun akışı farklıdır. Oynanışı taşıyan paketler küçük, sık ve zaman kritiktir; kaybolan bir paketi beklemek, akışı durdurmaktan daha kötü sonuç verir. Bu nedenle taşıma tarafında UDP tercih edilir. CONNECT tüneli TCP taşıdığı için bu paketler tünele girmez; işletim sistemi onları olağan arayüzden gönderir.

SOCKS5 protokolünün UDP ASSOCIATE komutu bu boşluğu kapatmak için vardır, ama iki koşul birlikte sağlanmalıdır: sunucu bu komutu desteklemeli ve istemci onu kullanmayı bilmelidir. Oyun istemcileri sistem proxy ayarını UDP tarafı için genellikle okumaz. Dolayısıyla gerçekçi beklenti, proxy’nin web katmanını kapsaması, oyun akışının kapsam dışında kalmasıdır.

Ad çözümlemesi de bu ayrımın bir parçasıdır. İstemci alan adını kendi ağında çözerse hedef sizin DNS sunucunuza görünür ve size yakın bir düğüm dönebilir; bağlantı ise uzaktaki çıkıştan kurulur. SOCKS5’te çözümlemenin nerede yapıldığı bu davranışın kaynağını gösteriyor.

IPv6 açık kaldığında ne olur?

Kurulumun sessizce boşa düştüğü bir durum daha var. Çıkışınız yalnızca IPv4 adres veriyorsa ama cihazınızda IPv6 etkinse, IPv6 üzerinden erişilebilen bir hedefe yapılan istek proxy’yi tamamen atlayabilir; işletim sistemleri çoğu kurulumda IPv6’yı önceler. Belirtisi yoktur: sayfa açılır, hata çıkmaz, kurulum çalışıyor görünür. Karşı tarafın gördüğü adres ise sizin kendi adresinizdir.

Çözüm iki yoldan biridir: IPv6 destekli bir çıkış kullanmak ya da o profilde IPv6’yı devre dışı bırakmak. Hangisini seçerseniz seçin, kurulumdan sonra görünen adresi mutlaka doğrulayın; bu kontrolü atlamak, sonraki her ölçümü anlamsız kılar çünkü hangi yolun kullanıldığını bilmezsiniz.

Hangi istek proxy’den fayda görür?

Kararı kolaylaştıran iki eksen vardır: isteğin gecikmeye ne kadar duyarlı olduğu ve proxy ile kapsanmasının ne kadar mümkün olduğu. Mağaza ve hesap sayfaları düşük duyarlılık–yüksek kapsanabilirlik köşesinde durur; buralarda proxy hem çalışır hem işe yarar. Maç içi akış ise tam karşı köşededir: hem en duyarlı hem de pratikte kapsanamayan trafiktir.

Arada kalan iki kalem dikkat ister. Yama indirme kapsanabilir ama bant genişliği maliyeti yüksektir; kotalı bir çıkışta bunu bilerek yapmak gerekir. Eşleşme kuyruğu ise kapsanabilir olmasına rağmen gecikmeye duyarlıdır: uzak bir çıkış, kuyruk isteklerini yavaşlatarak oyunu menüde bekletebilir.

Bu haritayı bir kez çıkardığınızda kurulum kararı kendiliğinden sadeleşir. Amacınız mağaza ve hesap katmanında farklı bir ülkeden görünmekse dar kapsamlı bir kural yeterlidir. Amacınız oyunun kendi bağlantısını değiştirmekse, elinizdeki araç bu iş için tasarlanmamıştır ve sonuç hayal kırıklığı olur.

Mağaza, pazar yeri ve hesap ekranları

Oyunun mağaza tarafı bir web uygulamasıdır ve proxy karşısında tahmin edilebilir davranır: çıkış hangi ülkedeyse sayfa o ülkenin arayüz dilini, para birimini ve içerik düzenini gösterebilir. Bir kampanyanın başka bir pazarda nasıl sunulduğunu doğrulamak isteyen içerik ve pazarlama ekipleri için bu, işin doğal bir parçasıdır.

Burada bir sınır çizmek gerekir. Görünümü doğrulamak ile satın alma koşullarını esnetmek aynı şey değildir; ikincisi yayıncının hizmet şartlarının konusudur ve bu sayfanın önerdiği bir kullanım değildir. Bölgesel görünüm araştırmasının nasıl kurgulandığını mağaza içi bölgesel araştırma yazısı yöntem tarafından anlatıyor.

Hesap ekranları ayrı bir dikkat ister. Şifre değişimi, ödeme yöntemi ve güvenlik ayarları gibi sayfalar, oturumun geldiği yeri daha sıkı değerlendirir. Bu ekranlarda çıkışı ansızın değiştirmek ek doğrulama tetikleyebilir; hesap işlerini olağan çıkışınızdan yapmak, sonradan kurtarma süreciyle uğraşmaktan basittir.

Pazar yeri ve envanter sayfaları, arayüzü besleyen çok sayıda küçük istek üretir. Bu istekler paralel açıldığı için eşzamanlı bağlantı tavanınızı beklediğinizden hızlı doldurabilir; sayfa yarım yüklenmiş gibi görünür. Sorun genelde çıkışın hızı değil, açık bağlantı sayısı sınırıdır.

Bir oturumun protokol dağılımı

Bir oyun oturumunda taşınan verinin nereye dağıldığını görmek, kurulum kararını somutlaştırır. Hacmin büyük bölümü oynanışı taşıyan akıştan gelir ve bu akış tünelin dışındadır. Web istekleri sayıca fazla olsa da hacimde küçük kalır; buna karşılık proxy’nin gerçekten etkilediği tek kalem odur.

Bu dağılım, kota planlamasını da yönlendirir. Aktarılan veriye göre ücretlendirilen bir çıkışta yalnızca web katmanını taşıyorsanız aylık tüketim ölçülü kalır. Yama indirmeyi de aynı çıkıştan geçirdiğiniz anda tablo değişir ve maliyet birkaç güncellemeyle katlanır. Hesaplamanın nasıl yapılacağını bant genişliği hesaplama yazısı örnekliyor.

Üçüncü fayda teşhistedir. Bir sorunun hangi katmandan geldiğini anlamak için önce o katmanın hacimdeki payına bakmak işe yarar: mağaza sayfası açılmıyorsa mesele web katmanındadır ve proxy ilgilidir; oyun içinde sıçrama yaşıyorsanız proxy büyük olasılıkla ilgisizdir, çünkü o akış zaten tünelden geçmiyordur.

Çıkış türü bu tabloyu nasıl değiştirir?

Datacenter proxy yüksek bant genişliği ve düşük maliyetle web katmanını rahat taşır. Residential proxy tipik bir ev bağlantısına benzer bir profil sunar ama hattın değişkenliğini de getirir. Seçim, hangi katmanı taşıyacağınıza göre yapılır; hacmi büyük işlerde tür kadar kota modeli de belirleyicidir.