Free Fire Proxy: Mobil İstemcide Kapsam ve NAT Davranışı

Free Fire mobil bir istemcidir; masaüstü sürümü yoktur ve bu durum proxy tartışmasını baştan daraltır. Telefonda tek bir kutucukla “tüm trafiği yönlendirme” imkânı yoktur: Wi-Fi ağına tanımlanan HTTP proxy yalnızca o ağda ve yalnızca o ayarı okuyan uygulamalarda çalışır, mobil veri bağlantısını hiç kapsamaz.

İkinci sınır taşıma katmanındadır. Giriş, mağaza, olay sayfaları ve güncelleme indirmeleri TCP üzerinde HTTPS ile yürür; maç sırasındaki hareket ve atış paketleri ise gecikmeye duyarlı olduğu için UDP ile taşınır. HTTP proxy UDP taşımaz, dolayısıyla maç akışı doğal olarak kapsam dışındadır.

Bu sayfa üç başlığı ayrı ayrı ele alıyor: yapılandırmanın kapsamı, adres çevirisinin (NAT) bu tabloda nereye oturduğu ve çıkış değiştirmeden önce hesap güvenliği tarafında yapılması gerekenler.

Telefonda yapılandırmayı nereye tanımlarsınız?

İlk seçenek Wi-Fi ağının gelişmiş ayarlarındaki HTTP proxy alanıdır. Bu ayar ağa bağlıdır: başka bir ağa geçtiğinizde devre dışı kalır, mobil veriye düştüğünüzde ise hiç uygulanmaz. Kapsamı da sınırlıdır; yalnızca sistem ayarını okuyan uygulamaların TCP istekleri bu yoldan gider. Kurulum adımları Android ve iPhone için ayrı ayrı anlatılıyor.

İkinci seçenek uygulama bazlı kuraldır. Burada yönlendirme belirli uygulamalara uygulanır; diğer uygulamalar olağan hattından çıkmaya devam eder. Kapsam daha öngörülebilirdir ama her cihazda aynı kolaylıkla kurulamaz ve yine yalnızca TCP tarafını kapsar.

Üçüncü seçenek ağın kendisidir: yönlendirici üzerinde yapılan bir yönlendirme, o ağa bağlı tüm cihazları kapsar. Geniş kapsam avantaj gibi görünse de çoğu senaryoda aşırıdır; televizyondan akıllı prize kadar her cihazın trafiği aynı çıkıştan geçmeye başlar.

Hangi noktayı seçerseniz seçin, kurulumu bitirdiğinizde doğrulama yapın. Aynı cihazın tarayıcısından çıkış adresinizi kontrol edin; uygulamanın içinden bakarak karar vermeyin, çünkü uygulama sistem ayarını okumuyor olabilir.

Yönlendirici seviyesinde ne mümkün, ne değil?

Ev tipi yönlendiricilerin çoğunda “proxy istemcisi” diye bir özellik yoktur. Arayüzdeki proxy alanı genellikle yönlendiricinin kendi güncelleme isteklerini ilgilendirir, ağa bağlı cihazların trafiğini değil. Ağ seviyesinde gerçek bir yönlendirme için üretici yazılımının değiştirilmesi ve TCP oturumlarını proxy’ye aktaran ek bir bileşen kurulması gerekir.

Böyle bir kurulumda bile kapsam eksik kalır. Aktarım TCP oturumlarını taşır; UDP datagramları kapsam dışındadır, yani maç akışı yine doğrudan çıkar. Ayrıca ad çözümünü ayrıca ele almanız gerekir: cihazlar alan adını yerel ağda çözmeye devam ederse hedefiniz sağlayıcınıza görünür. Bu ayrımın nasıl işlediği SOCKS5’te DNS nerede çözülür? yazısında anlatılıyor.

Kapsamın genişlemesi yeni sorunlar da getirir. Ağdaki her cihaz aynı çıkışı paylaştığında eşzamanlı bağlantı limiti çabuk dolar, ölçülü bir pakette kota hızla erir ve bir arıza tüm evi etkiler. Bu nedenle yönlendirici katmanı, tek bir oyunun hesap trafiğini yönetmek için genellikle yanlış araçtır. Genel çerçeve için yönlendirici üzerinden proxy kullanımı yazısına bakabilirsiniz.

Adres çevirisi, NAT tipi ve delik açma nereye oturur?

NAT, özel ağdaki adresleri tek bir genel adrese çeviren mekanizmadır. Oyun tarafında “NAT tipi” diye anılan sınıflandırma, bu çevirinin dışarıdan gelen paketleri nasıl karşıladığını tarif eder. Çeviri, aynı iç bağlantı için her hedefte aynı dış portu kullanıyorsa dışarıdaki bir eşin sizi bulması kolaydır; her hedef için ayrı port açan simetrik davranışta ise bu neredeyse imkânsız hâle gelir.

Delik açma (hole punching) tam olarak buraya girer: iki taraf da önce dışarıya bir paket gönderip kendi çeviri kaydını oluşturur, sonra öğrenilen adres ve port üzerinden birbirine ulaşmayı dener. Bu yöntem yalnızca çeviri davranışı öngörülebilir olduğunda işler. Free Fire gibi mobil oyunlarda maç trafiği genellikle ayrılmış sunucular üzerinden yürür, ama ses ve bazı eş özellikleri bu davranışa duyarlıdır.

Araya bir proxy koyduğunuzda tabloya ikinci bir çeviri katmanı eklenmiş olur. Mobil operatör çıkışları zaten CGNAT arkasındadır; yani dışarıdan gelen bağlantıyı kabul edecek bir genel adresiniz hiç yoktur. Sonuç şudur: proxy NAT tipini iyileştirmez, çoğu durumda daha kısıtlayıcı bir tabloya yol açar. İki mekanizmanın farkı proxy ve NAT arasındaki fark yazısında karşılaştırılıyor.

Çıkışı değiştirmeden önce hesabı sağlama alın

Mobil oyun hesaplarında en sık görülen kayıp, misafir oturumuyla oynanan ilerlemenin cihaz değiştiğinde kurtarılamamasıdır. Bu yüzden sıralama nettir: önce hesabı kalıcı bir kimliğe bağlayın, sonra iki adımlı doğrulamayı açın, ancak ondan sonra ağ tarafında bir değişikliğe girişin.

İki adımlı doğrulama açıkken bağlantı noktanızın değişmesi çok daha az sorun çıkarır, çünkü platformun elinde sizi tanıyacak ikinci bir kanal vardır. Kurtarma adresinizin güncel olduğundan emin olun; erişimi kaybettiğinizde tek dayanağınız o adres olur.

Konum tarafında ilke basittir: ani sıçrama yapmayın. Bir hesabın bugüne kadar hep aynı ülkeden bağlanıp bir anda uzak bir ülkeden görünmesi, platformun risk değerlendirmesinde beklenen bir davranış değildir ve ek doğrulama isteğiyle sonuçlanır. Bu istek bir cezalandırma değil koruma mekanizmasıdır; onu etkisiz kılmaya çalışmak değil, tutarlı davranmak doğru yaklaşımdır.

• Hesabı kalıcı bir kimliğe bağlamadan çıkış değiştirmeyin.
• Kurtarma adresini ve iki adımlı doğrulamayı önceden hazır edin.
• Çıkış ülkesini hesabın olağan ülkesiyle tutarlı seçin.
• Sabit (sticky) çıkış kullanın; her istekte değişen adres tablo bozar.