Satisfactory Proxy: Hangi İstemci Nereye Bağlanır?

SOCKS5 datagram taşırken gerçekte ne yapar?

UDP’yi bir proxy üzerinden geçirmenin standart yolu SOCKS5 protokolünün UDP ASSOCIATE komutudur. İstemci önce proxy ile bir TCP kontrol bağlantısı kurar, bu bağlantı üzerinden datagram aktarımı ister ve proxy kendisine ait bir aktarma adresi bildirir. Bundan sonra her datagram bu adrese gönderilir.

Kritik ayrıntı şu: istemci datagramı olduğu gibi gönderemez. Her paketin başına, hedefi bildiren küçük bir başlık eklemek zorundadır — ayrılmış alan, parçalama göstergesi, adres türü, hedef adres ve port. Proxy bu başlığı okuyup yükü gerçek hedefe iletir, dönen yanıta aynı başlığı ekleyerek geri verir.

Bu yüzden UDP desteği bir seçenek kutusu değil, istemci tarafında protokol bilgisi gerektiren bir yetenektir. Bir oyun istemcisi bu başlığı üretmiyorsa, proxy ne kadar yetenekli olursa olsun oyun trafiği tünele girmez. SOCKS5 ile önceki sürüm arasındaki fark da tam burada belirginleşir; SOCKS4 ve SOCKS5 farkı yazısı bu ayrımı ayrıntılandırıyor.

Kampüs ve kurumsal ağlarda kapalı portlar

Üniversite ve işyeri ağlarının çoğu, dışarı çıkan trafiği tanımlı bir kümeye sınırlar. Tipik politika şudur: web trafiği serbest, geri kalan her şey kapalı. Bu tür bir ağda oyun oturumunun kurulamaması beklenen sonuçtur ve nedeni sizin yapılandırmanız değil, ağın kural setidir.

Böyle bir ağda proxy neyi çözer, neyi çözmez? Çözebildiği şey uygulama katmanıdır: launcher’ın erişemediği bir uç noktaya web trafiği olarak ulaşmak mümkün olabilir. Çözemediği şey ise taşıma katmanıdır — çıkışa giden UDP zaten engelleniyorsa, o engelin arkasında bir proxy tanımlamak durumu değiştirmez. Port numaralarının ne anlattığı konusunda proxy port numaraları yazısı yardımcı olur.

Doğru adım idari olandır: ağ yöneticisine hangi hedefe, hangi protokolle ve hangi amaçla erişmek istediğinizi yazılı olarak iletmek. Kurumsal ağlarda bu tür istekler nadir değildir ve çoğu zaman tanımlı bir istisna ile çözülür. Ağ politikasını teknik yollarla dolanmaya çalışmak hem kurum kurallarına aykırıdır hem de kalıcı bir çözüm üretmez. Konunun genel çerçevesi okul ve işyeri ağlarında erişim engelleri yazısında.

Ağ tarafında ayrıca bir doğrulama adımı var: engelin gerçekten ağda mı yoksa istemcide mi olduğunu ayırmak. Aynı bağlantıyı başka bir cihazdan ve mümkünse başka bir hattan deneyin. Proxy kontrol aracı çıkışın canlı olup olmadığını söyler; bu ikisi birleştiğinde sorunun katmanı netleşir.

Kısıtlı ağlarda sık rastlanan bir ara tablo daha var: trafiğin serbest ama denetimli olması. Kurum, çıkan web trafiğini kendi denetim noktasından geçiriyorsa bağlantı kurulur ama araya giren katman TLS oturumunu kendi sertifikasıyla yeniden kurar. Bunun belirtisi launcher tarafında sertifika uyarısı ya da doğrulama hatasıdır. Böyle bir ortamda ikinci bir proxy zinciri eklemek teşhisi zorlaştırmaktan başka bir işe yaramaz; önce mevcut denetim noktasının davranışını öğrenmek gerekir.

Hizmet şartları, sunucu kuralları ve hile önleme

Bir ara sunucu kullanmak, bağlandığınız hizmetin kurallarını değiştirmez. Yayıncının sözleşmesi, mağaza platformunun şartları ve katıldığınız topluluk sunucusunun kendi kuralları aynen geçerli kalır. Proxy yalnızca bağlantının hangi adresten geldiğini değiştirir; bu adres de sunucu tarafında kayıt altındadır.

Bu sayfa hile önleme mekanizmalarına müdahale, hesap yaptırımlarını etkisiz kılma veya bölgesel kısıtları dolanma amacı taşımaz. Teknik olarak da bu beklenti yanlıştır: istemci bütünlüğünü denetleyen sistemler ağ adresine bakmaz, çalışan süreci ve oyun içi davranışı inceler. Adres değiştirmek bu denetimin girdisi değildir.

Buna karşılık meşru ihtiyaçlar gerçektir. Barındırdığınız bir sunucunun dışarıdan erişilebilirliğini farklı bir noktadan doğrulamak, mağaza sayfalarının bölgesel görünümünü incelemek, kurumsal bir ağdan çıkarken sabit bir adres kullanmak. Bu senaryolarda proxy bir görünürlük ve yönlendirme aracıdır ve bu haliyle sözleşmelerle çelişmez.

Kimlik doğrulama ve erişim yönetimi

Proxy sağlayıcıları erişimi iki yöntemden biriyle verir: kullanıcı adı ve parola ile ya da adres yetkilendirmesiyle. İkisinin farkı, birden fazla cihazdan çalıştığınızda ortaya çıkar. Adres yetkilendirmesi sabit hatlarda pratiktir ama hattınız her yenilendiğinde erişiminizi kaybedersiniz; kullanıcı adı–parola her yerden çalışır ama paylaşılabilir bir sırdır. Yöntemlerin ayrıntısı proxy kimlik doğrulama yöntemleri yazısında.

Launcher tarafında bir başka ayrıntı önem kazanır: bazı indirme istemcileri proxy kimlik doğrulamasını yalnızca temel yöntemle destekler, bazıları da hiç desteklemez. Kimlik doğrulamalı bir çıkışta indirmenin başlamaması çoğu zaman bu uyumsuzluktan kaynaklanır ve çözüm adres yetkilendirmesine geçmektir.

Tablodaki ikinci satır en çok zaman kaybettiren maddedir. Oyun istemcisi için ayrı bir ayar bulunmadığında, sistem ayarının onu da kapsadığı varsayılır; oysa istemci sistem ayarını okumadığı sürece hiçbir şey değişmez. Bu varsayımı ölçümle sınamak, teşhisi kısaltan tek adımdır.

HTTPS tünelleme: CONNECT gerçekte ne yapar?

Launcher trafiğinin tamamına yakını HTTPS olduğu için, proxy’nin bu trafiği nasıl taşıdığını bilmek teşhiste işe yarar. İstemci proxy’ye CONNECT hedef.example:443 biçiminde bir istek gönderir; proxy hedefe TCP bağlantısı açar ve başarılı olursa iki taraf arasında ham bayt akışını iletmeye başlar. TLS el sıkışması bu tünelin içinde, istemci ile hedef arasında gerçekleşir.

Bunun iki pratik sonucu var. Birincisi, proxy şifreli içeriği okuyamaz; taşıdığı baytların anlamına erişimi yoktur. İkincisi, proxy hangi ana bilgisayara bağlandığınızı düz metin olarak görür ve kaydedebilir. Bu ayrım sağlayıcı seçimini bir güven kararına dönüştürür. Yöntemin ayrıntısı HTTP CONNECT metodu yazısında anlatılıyor.

Üçüncü sonuç teşhisle ilgilidir: tünel kurulurken alınan hata, hedeften değil proxy’den gelir. Proxy kimlik doğrulama istiyorsa bunu tünel açılmadan önce bildirir; hedefe hiç ulaşılmamıştır. Bu yüzden launcher’ın verdiği hata metnini okurken, hatanın proxy katmanında mı yoksa hedefte mi doğduğunu ayırt etmek gerekir.

Sertifika uyarısı ise ayrı bir kategoridir. Doğru çalışan bir tünelde proxy TLS oturumuna karışmaz. Uyarı görüyorsanız trafiğiniz açılıp yeniden şifreleniyor demektir; kurumsal ağ dışında bu, durup çıkışı sorgulamanız gereken bir işarettir.

Kurulum sonrası doğrulama sırası

Kurulumun bittiği an değil, doğrulamanın bittiği an güvenilir kurulumdur. Sıra şöyledir: önce çıkışın canlılığı, sonra kapsamın doğruluğu, en sonda performansın ölçülmesi. Bu sırayı bozmak, sonuçları birbirine karıştırır.

• Çıkışın yanıt verdiğini bağımsız bir araçla doğrulayın; kimlik bilgisi hatasını burada yakalayın.
• Launcher açıkken görünen adresin beklediğiniz çıkış olduğunu kontrol edin.
• Oyun istemcisini ayrı değerlendirin; sistem ayarının onu kapsadığını varsaymayın.
• Bir güncelleme indirirken hızın ve sürekliliğin kabul edilebilir olduğunu gözlemleyin.
• Ölçümleri öncesi ve sonrası olarak, aynı araçla ve benzer saatlerde alın.

Bu listede en çok atlanan madde üçüncüsüdür. Oyun istemcisinin proxy kapsamı dışında kaldığını görmek hayal kırıklığı yaratabilir ama doğru bilgi, yanlış beklentiden iyidir: kapsamı bilerek kurulan bir yapılandırma, sorun çıktığında nereye bakacağınızı da söyler.

Doğrulamayı kolaylaştıran bir alışkanlık, her yapılandırma için kısa bir kayıt tutmaktır: hangi yazılıma hangi çıkış tanımlandı, kimlik doğrulama hangi yöntemle yapılıyor, ölçüm hangi tarihte alındı. Üç ayrı yazılımın bulunduğu bir kurulumda bu kayıt, birkaç hafta sonra “burayı neden böyle ayarlamıştım” sorusunun cevabını verir. Aynı kayıt, bir güncelleme sonrası davranış değiştiğinde de karşılaştırma zemini sağlar.

Son olarak, değişiklikleri teker teker yapın. Çıkışı, protokolü ve istemci ayarını aynı anda değiştirdiğinizde iyileşmenin kaynağını bilemezsiniz; sorun tekrarladığında da baştan başlarsınız.