LoL Proxy: İstemci Trafiği, Ağ Engelleri ve UDP Gerçeği

League of Legends — kısaca LoL — ile proxy ilişkisini anlamanın en hızlı yolu, ortada tek bir “oyun bağlantısı” olmadığını kabul etmektir. İstemci açıldığında giriş, yama denetimi, mağaza sayfaları ve arkadaş listesi gibi işler sıradan web trafiği gibi davranır. Maç kabul edildiğinde devreye giren süreç ise bambaşka bir kanal kurar ve bu kanalın öncelikleri farklıdır.

Bu ayrım, kurulum sonrası yaşanan kafa karışıklığının neredeyse tamamını açıklar. İstemci sorunsuz açılır, mağaza yüklenir, profil görünür; ama maç ekranında bağlantı kurulamaz. Ayarınız yanlış değildir, yalnızca kapsamı sandığınızdan dardır.

İkinci nokta baştan net olsun: burada bölge değiştirme, hesap çoğaltma veya oyunla birlikte çalışan koruma bileşenlerini etkisiz kılma anlatılmaz. Konu erişim teşhisi, yönetilen ağ davranışı ve trafiğin hangi bölümünün gerçekten yönlendirilebildiğidir. Riot’un hizmet şartlarına uyum kullanıcının sorumluluğundadır.

İstemci ağda kaç ayrı iş yapıyor?

İstemci penceresi, içine gömülü bir tarayıcı motoruyla çizilen bir arayüzdür. Gördüğünüz mağaza, profil, maç geçmişi ve etkinlik sayfaları arka planda HTTPS istekleriyle gelir; taşıma tarafında bunlar TCP üzerinde yürüyen, sıra garantisi isteyen, kaybı tolere etmeyen isteklerdir. Bu aile, tarayıcınızın yaptığı işten yapısal olarak farklı değildir ve bu yüzden bir proxy ayarının kapsamına girmeye en yatkın kısımdır.

Maç başladığında tablo değişir. Gerçek zamanlı durum güncellemesi taşıyan kanal, bir paketin geç gelmesindense hiç gelmemesini tercih eder: kaybolan bir konum güncellemesini yeniden istemek anlamsızdır, çünkü bir sonraki güncelleme zaten yoldadır. Bu davranış taşıma katmanında UDP ile karşılanır ve klasik bir HTTP proxy’si UDP taşımaz. HTTPS için kurulan CONNECT tüneli yalnızca TCP baytlarını aktarır.

Yama günü ile sıradan bir akşam aynı şey değildir

Yama indirme, hacim olarak bütün diğer kalemleri gölgede bırakır ve bir içerik dağıtım ağından toplu halde gelir. Burada önemli olan gecikme değil, çıkışınızın bant genişliği ve kotasıdır. Veri üzerinden ücretlendirilen bir çıkış kullanıyorsanız tek bir büyük yama, aylık planınızın hatırı sayılır bir bölümünü tek seferde tüketebilir. Buna karşılık aynı çıkışın maç akşamındaki tek işi, küçük ama sık paketleri zamanında taşımaktır.

Kampüs ve kurumsal ağda hangi kapı kapalı kalıyor?

Yönetilen ağların çoğu dışarı çıkan trafiği dar bir kümeye indirir: TCP 443, çoğu zaman TCP 80 ve ad çözümü için ayrılmış kanal. Geri kalan her şey sessizce düşürülür. Bu politikanın oyun istemcisindeki görüntüsü çok tipiktir — giriş yapılır, yama iner, mağaza açılır, ancak maç kurulurken bağlantı bir türlü tamamlanmaz. Sebep istemcide değil, ağ kenarındaki kuraldadır.

Bu noktada proxy’nin ne yapıp ne yapamayacağını ayırmak gerekir. Ağınız 443 üzerinden bir proxy sunucusuna ulaşmanıza izin veriyorsa, o proxy üzerinden TCP tabanlı işlerinizi taşıyabilirsiniz. Ama proxy bir tünel açsa bile taşıdığı şey TCP’dir; ağ kenarında UDP kapalıysa maç akışı yine geçmez. “Proxy kurayım, her şey düzelir” beklentisi tam burada kırılır.

Doğru yol, kuralı dolanmak değil kuralı öğrenmektir. Kampüs ve iş yeri ağlarında oyun trafiği çoğu kurumda kabul edilebilir kullanım politikasının dışındadır; ağ ekibine sormadan yapılan denemeler hem işe yaramaz hem de hesap değil cihaz düzeyinde yaptırım doğurabilir. Bu tür ortamlarda erişim engellerinin nasıl sınıflandırıldığını okul ve iş yeri ağlarında erişim engelleri yazısı ayrıntılandırıyor.

Ortak öğrenci evi, yurt ve internet kafe gibi paylaşılan hatlarda ise sorun genellikle kural değil kalabalıktır: aynı çıkış adresini çok sayıda kişi kullanır, adres taşıyıcı seviyesinde paylaşılmıştır ve dışarıdan gelen bağlantılar için tutulan eşleme kısa ömürlüdür. Bu ortamda sabit bir çıkış kullanmak, en azından bağlantınızın hangi adresten göründüğünü öngörülebilir kılar.

Mağaza, pazar yeri ve hesap sayfaları neden ayrı davranır?

İstemcinin içindeki mağaza ve profil ekranları, gömülü tarayıcıya servis edilen web sayfalarıdır. Bu yüzden bir sistem geneli proxy ayarından etkilenme ihtimalleri, maç sürecine göre çok daha yüksektir. Pratikte gördüğünüz tablo genellikle şudur: sayfa içerikleri çıkış üzerinden gelir, arayüz dili ve para birimi sunucu tarafındaki hesap ayarına göre çizilir.

Burada sık yapılan bir varsayımı düzeltmek gerekir. Çıkış adresinizin ülkesi, hesabınızın bağlı olduğu bölgeyi değiştirmez. Bölge hesabın bir özelliğidir; sunucu listesi, arkadaş listesi ve satın alınmış içerik o bölgeye bağlıdır. Ağ yolunu değiştirmek bu bağlamı taşımaz. Bölge değişikliği isteyen kullanıcılar için doğru adres oyunun kendi resmî hizmetidir, bir çıkış ayarı değil.

Ödeme adımı neden ayrı bir katman?

Satın alma akışı yalnızca hangi sayfayı gördüğünüzle ilgilenmez; kartın verildiği ülke, fatura adresi ve hesap bölgesi birlikte değerlendirilir. Bu üçü ile bağlantının geldiği yer arasındaki uyumsuzluk, ek doğrulama veya reddedilen işlem olarak geri döner. Bölgesel fiyat farklarını araştırmak ile başka bir bölgeden satın almaya çalışmak farklı işlerdir; ikincisi çoğu platformun kullanım şartlarına ve ödeme koşullarına aykırıdır. Yalnızca fiyat görünümünü inceleyen araştırma senaryoları için oyun mağazalarında bölgesel fiyat araştırması yazısına bakabilirsiniz.

Hesap sayfaları tarafında dikkat edilecek nokta tutarlılıktır. Oturum çerezi bir yerde açıldıktan sonra sizinle taşınır; adresin birkaç dakika içinde birbirinden uzak ülkeler arasında sıçraması, platform tarafında olağan bir kullanım örüntüsüne benzemez. Giriş yapılan her senaryoda sabit (sticky) bir çıkış, dönen bir havuzdan daha az sürtünme üretir.

SOCKS5’in UDP ASSOCIATE yöntemi nerede işe yarar, nerede biter?

SOCKS5 protokolü UDP taşımak için ayrı bir yöntem tanımlar. İstemci önce proxy ile bir TCP denetim kanalı kurar, kimlik doğrulamasını yapar ve ardından bir UDP ilişkilendirme isteği gönderir. Proxy bu isteğe, datagramları göndereceği bir aktarma adresi ve portuyla yanıt verir. İstemci bundan sonra UDP paketlerini, asıl hedefi belirten küçük bir başlıkla sarmalayıp bu aktarma noktasına yollar.

Tanım bu kadar net olsa da pratikte üç koşulun aynı anda sağlanması gerekir. Birincisi, proxy sunucusu bu yöntemi gerçekten uygulamalıdır; sağlayıcıların önemli bir bölümü yalnızca TCP bağlantılarına izin verir. İkincisi, istemci bunu konuşabilmelidir; oyun istemcilerinin çoğunda bir SOCKS5 ayar alanı bulunmaz, dolayısıyla araya sistem seviyesinde bir yönlendirici katman koymadan kullanılamaz. Üçüncüsü, aradaki ağ UDP’ye izin vermelidir.

Dördüncü ve çoğu zaman gözden kaçan ayrıntı şudur: UDP ilişkilendirmesi, onu doğuran TCP denetim kanalına bağlıdır. O kanal düşerse aktarma da kapanır ve oyun ortasında sessiz bir kopma yaşarsınız. Yöntemin adım adım işleyişi ve sağlayıcı tarafındaki gereksinimler SOCKS5 UDP desteği yazısında ayrıntılı olarak ele alınıyor.