Makale içeriği

Tanıdık bir durum: bir proxy ayarladınız, tarayıcı siteleri açıyor, veri kazıyıcı verileri topluyor, her şey mükemmel görünüyor. Ama sonra bir görüntülü arama başlatıyorsunuz ve karşınızdaki kişi sizi duymuyor. Veya çevrimiçi bir oyuna giriyorsunuz ve maç bağlanmıyor. Veya bir sesli sohbet başlatıyorsunuz ve sessiz kalıyor. Proxy çalışıyor değil mi? Çalışıyor. Ama derin bir seviyede bir şey bozuk ve bunu ulaşım bilgisi olmadan anlamak neredeyse imkansız.

Nedeni neredeyse her zaman aynıdır: proxy'niz UDP trafiğini geçirmiyor. Ve bu bir arıza değil, temel bir özelliktir. Bazı proxy türleri standart olarak UDP ile çalışabilir, bazıları ise prensipte çalışamaz. Bu iki dünya arasındaki fark, internette gerçek iletişiminizin çalışıp çalışmayacağını veya yalnızca web sayfalarını yükleyip yükleyemeyeceğinizi belirler.

Bu kılavuzda, konuyu en temelden pratik kontrol araçlarına kadar ele alacağız. SOCKS5 protokolündeki UDP ASSOCIATE komutunun nasıl çalıştığını, HTTP proxy'nin CONNECT yöntemiyle neden fiziksel olarak datagram iletemediğini, UDP olmadan kullanıcının tam olarak neyi kaybettiğini ve herhangi bir proxy'yi gerçek UDP desteği için birkaç dakika içinde nasıl test edebileceğinizi öğreneceksiniz. Sadece ulaşım katmanı hakkında konuşacağız: proxy türleri arasında seçim yapma veya belirli uygulamaları yapılandırma talimatları olmadan.

Temeller: TCP vs UDP, Datagramlar ve Proxy Çalışma Seviyesi

UDP'nin proxy altyapısında neden bu kadar hassas olduğunu anlamak için, taşıma katmanının temel kavramlarına dönmemiz gerekiyor. Endişelenmeyin: her şeyi basit benzetmelerle açıklayacağız.

İki Taşıma Protokolü, İki Felsefe

İnternette veriler iki ana taşıma protokolü üzerinden iletilir: TCP (Transmission Control Protocol) ve UDP (User Datagram Protocol). Her ikisi de IP üzerinde çalışır, ancak tamamen farklı davranırlar.

TCP, sürekli onay alan bir telefon görüşmesine benzer. Veri alışverişine başlamadan önce, iki taraf bir el sıkışma prosedürü ile bir bağlantı kurar. Gönderilen her paket alıcı tarafından onaylanır. Bir şey kaybolursa, yeniden gönderilir. Paketlerin sırası garanti edilir. Güvenilir, sıralı ama nispeten yavaş bir akıştır. TCP, web sayfaları yüklemek, dosya indirmek, e-posta göndermek gibi her veri parçasının ve doğru sırasının önemli olduğu her yerde idealdir.

UDP, teslimat bildirimi olmadan kartpostal göndermeye benzer. Bir datagramı ağa atar ve onay beklemez. Bağlantı kurulumu yoktur, teslimat garantisi yoktur, sıra garantisi yoktur. Paket kaybolabilir, iki kez gelebilir veya karışık sırada gelebilir ve protokol bunu umursamaz. Kulağa bir eksiklik gibi mi geliyor? Sadece ilk bakışta. İşte bu basitlik UDP'ye ana avantajını verir: hız ve minimum gecikme.

Datagram Nedir

Datagram, UDP'de bağımsız bir veri parçasıdır. TCP'de veriler sürekli bir bayt akışı olarak akarken, UDP'de her paket kendi kendine yeterlidir. Hedef adresi, bağlantı noktasını ve yükü içerir. Datagram, kendisinden önce veya sonra gönderilen datagramlar hakkında hiçbir şey bilmez. Bu, genel bir yazışmada numarasız ayrı mektuplar gibidir.

Bu konumuz için neden önemli? Çünkü sürekli bir TCP akışını iletebilen bir proxy, mutlaka bağımsız datagramları iletebilecek anlamına gelmez. Bunlar, uygulama açısından temelde farklı görevlerdir.

Proxy Zincirde Tam Olarak Nerede Yaşar

Ağ modelini bir binanın katları olarak düşünelim. Alt katlarda fiziksel sinyal iletimi ve IP adresleme vardır. Üstte TCP ve UDP ile taşıma katmanı. Daha da üstte HTTP, DNS, arama protokolleri gibi uygulama katmanı.

Proxy sunucusu, sizinle hedef kaynak arasında duran bir aracıdır. Ancak hangi seviyede çalıştığı, türüne bağlıdır. Ve işte burada işler ilginçleşiyor.

  • HTTP proxy başlangıçta uygulama katmanı HTTP'yi anlar. HTTP isteklerini okur, başlıkları görür, bunları değiştirebilir ve önbelleğe alabilir. Bu, TCP üzerinde belirli bir uygulama protokolü için tasarlanmış bir proxydir.
  • SOCKS proxy daha alt seviyede, taşıma katmanına daha yakın çalışır. Uygulama protokolünün içeriğine girmez, sadece bağlantıları iletir. Bu nedenle SOCKS daha evrenseldir: HTTP veya egzotik bir şey olsun, ne ilettiğiniz umurunda değildir.

Çalışma seviyesindeki bu fark, tüm hikayenin köküdür. HTTP proxy, TCP üzerinde HTTP dünyasına hapsolmuştur. SOCKS5 ise evrensel bir taşıma aracısı olarak tasarlanmıştır ve bu nedenle spesifikasyonuna UDP iletim mekanizması eklenmiştir.

Derin Dalış: SOCKS5 UDP'yi Nasıl İletir

SOCKS5 protokolü RFC 1928 standardında açıklanmıştır. Kompakt, zarif bir protokoldür ve mantığını anlamak, proxy ile ciddi şekilde çalışan herkes için faydalıdır. Şimdi komutlarını ve UDP iletiminin özel yapısını inceleyelim.

SOCKS5'in Üç Komutu: CONNECT, BIND, UDP ASSOCIATE

İstemci SOCKS5 sunucusuna bağlanıp kimlik doğrulama aşamasını geçtikten sonra, üç komuttan birini içeren bir istek gönderir. Her komut hangi tür işlemin gerektiğini belirtir.

  • CONNECT (kod 0x01) en yaygın komuttur. Proxy'ye şunu söyler: benim için belirtilen adrese ve bağlantı noktasına giden bir TCP bağlantısı kur ve ardından baytları her iki yönde ilet. Tarayıcınız SOCKS5 üzerinden internete girdiğinde tam olarak bu komutu kullanır. Günlük trafiğin %99'u CONNECT üzerinden gider.
  • BIND (kod 0x02) gelen bağlantılar içindir. Klasik FTP gibi sunucunun istemciye geri bağlantı başlattığı protokoller için gereklidir. Proxy bir dinleme portu açar ve gelen bağlantıyı bekler. Bugün BIND nadiren kullanılır.
  • UDP ASSOCIATE (kod 0x03) konuşmamızın yıldızı. Bu komut, proxy üzerinden UDP datagramlarını iletmek için bir ilişkilendirme oluşturur. SOCKS5'in ses, video, oyunlar, QUIC ve UDP üzerinden DNS ile çalışmasını sağlayan şey budur.

UDP ASSOCIATE İçten Nasıl Çalışır

İşte sıklıkla yanlış anlaşılmaya neden olan güzel bir mimari hile var. UDP ASSOCIATE komutu TCP bağlantısı üzerinden gönderilir. Evet, yanlış duymadınız: UDP iletmeye başlamak için istemci, proxy ile bir yönetim TCP bağlantısı kurar ve bu bağlantı üzerinden komutu gönderir.

UDP iletmek istiyorsak neden bir yönetim TCP bağlantısına ihtiyacımız var? Bunun birkaç nedeni var ve pratiklik açısından dahice.

  1. Kimlik doğrulama ve parametre anlaşması TCP üzerinden güvenilir bir şekilde yapılır. UDP bunun için uygun değildir çünkü güvenilir değildir.
  2. Yönetim TCP bağlantısı, UDP ilişkilendirmesinin canlılık göstergesi olarak hizmet eder. TCP bağlantısı açık olduğu sürece, UDP ilişkilendirmesi etkindir. İstemci yönetim TCP bağlantısını kapattığı anda, proxy derhal kaynakları serbest bırakmalı ve datagram iletimini durdurmalıdır. Bu, yaşam süresini yönetmek için zarif bir yoldur.

UDP ASSOCIATE komutunu aldıktan sonra, proxy sunucusu UDP için özel bir röle portu ayırır ve yanıtta istemciye adresini ve numarasını bildirir. İstemci datagramlarını tam olarak bu röle portuna gönderecek, proxy ise bunları hedefe iletecek ve yanıtları geri gönderecektir.

Röle Portu ve Bağlama Adresinin Rolü

UDP ASSOCIATE yanıtında sunucu, BND.ADDR ve BND.PORT alanlarını döndürür. Bunlar, istemcinin iletim için UDP datagramlarını göndermesi gereken adres ve bağlantı noktasıdır. Önemli bir nüans: yanıttaki adres, istemcinin TCP üzerinden bağlandığı adresten farklı olabilir. Yetenekli bir istemci, özellikle sunucu sıfır adres döndürdüğünde (yönetim bağlantısıyla aynı ana bilgisayarı kullan anlamına gelir) bu adresi doğru yorumlamalıdır.

İşte bu aşamada birçok uygulama tökezler. BND.ADDR'nin yanlış işlenmesi, istemcinin datagramları yanlış yere göndermesine neden olur ve UDP iletimi, ilişkilendirme resmen kurulmuş olmasına rağmen sessizce çalışmaz.

SOCKS5'te UDP Datagram Kapsülleme Formatı

Bir UDP datagramını doğrudan röle portuna göndermek mümkün değildir. Proxy, onu nereye ileteceğini bilmelidir. Bu nedenle, istemci tarafından röle portuna gönderilen her UDP datagramı, özel bir SOCKS5 başlığıyla sarılır. Alanlarına göre inceleyelim, çünkü bu yapıyı anlamak konuyu gerçekten bilen kişiyi ayırır.

UDP kapsülleme başlığı aşağıdaki alanlardan oluşur:

  • RSV (2 bayt) ayrılmış alan, her zaman sıfırlarla doldurulur. Gelecek için bırakılmış, ancak şu anda kullanılmıyor.
  • FRAG (1 bayt) parça numarası. Bu alan büyük datagramların parçalanması içindir. Değer 0, datagramın ayrı olduğu ve parçalanmadığı anlamına gelir. Pratikte, SOCKS5 üzerinden UDP parçalaması neredeyse hiç kimse tarafından uygulanmaz ve çoğu sunucu ve istemci yalnızca FRAG değeri sıfır olanlarla çalışır.
  • ATYP (1 bayt) hedef adres türü. IPv4 için 0x01, alan adı için 0x03, IPv6 için 0x04 olabilir. Bu alan, proxy'ye sonraki adres alanını hangi formatta okuyacağını söyler.
  • DST.ADDR (değişken uzunluk) datagramın hedef adresi. Uzunluğu ATYP'ye bağlıdır: IPv4 için 4 bayt, IPv6 için 16 bayt; alan adı için ilk bayt uzunluğu belirtir ve ardından ad gelir.
  • DST.PORT (2 bayt) ağ bayt sırasında hedef bağlantı noktası.
  • DATA asıl yük, yani uygulamanın orijinal UDP datagramı.

Proxy, röle portunda böyle sarılmış bir datagram aldığında, SOCKS5 başlığını kaldırır, hedef adresi ve bağlantı noktasını okur ve temiz yükü sıradan bir UDP paketi olarak hedefe gönderir. Bir yanıt geldiğinde, proxy ters işlemi yapar: yanıt datagramını aynı başlıkla sarar ve istemciye röle portuna gönderir.

Şemanın zarafetine dikkat edin. İstemci asla UDP üzerinden doğrudan hedefle iletişim kurmaz. Her şey proxy'nin röle portundan geçer ve kapsülleme başlığı bir adres etiketi görevi görür. Bu, bir aracı üzerinden bağımsız datagramları taşımak için güvenilir ve standartlaştırılmış bir yöntemdir.

FRAG Alanı Neden Çoğunlukla Ölüdür

Parçalama üzerinde ayrıca durmakta fayda var. Teorik olarak SOCKS5, büyük UDP datagramlarını parçalara ayırmaya ve proxy tarafında birleştirmeye izin verir. Pratikte bu büyük bir karmaşıklık yaratır: parçaları arabelleğe almak, birleştirme zaman aşımlarını işlemek, saldırılara karşı korunmak gerekir. Bu nedenle, uygulamaların büyük çoğunluğu sadece FRAG'ın sıfır olmasını ister ve diğerlerini atar. Uygulamalar için bu, datagramın tek bir pakete sığması gerektiği anlamına gelir. Neyse ki, UDP kullanan çoğu gerçek protokol zaten küçük datagramlarla çalışır.

HTTP ve HTTPS Proxy'leri CONNECT Üzerinden Neden UDP İletemez

Şimdi en çok yanılgıya neden olan konuya geliyoruz. İnsanlar sık sık şöyle düşünür: HTTPS proxy'si CONNECT yöntemi üzerinden şifreli trafiği tünellemeyi bildiğine göre, evrenseldir ve UDP'yi de bilmelidir. Bu bir hatadır ve şimdi neden temel olduğunu açıklayacağız.

HTTP Proxy'de CONNECT Yöntemi Nasıl Çalışır

Tarayıcınız korumalı bir siteye HTTP proxy üzerinden gittiğinde, içerik şifreli olduğu için sadece bir HTTP isteği iletemez. Bunun yerine, proxy'ye hedef ana bilgisayar ve bağlantı noktasını belirten özel bir CONNECT komutu gönderir. Proxy bu ana bilgisayara bir TCP bağlantısı kurar ve başarılı olduğunda tünelin kurulduğunu belirten bir durumla yanıt verir. Daha sonra proxy, içeriğe karışmadan baytları istemci ve sunucu arasında her iki yönde pompalar.

Buradaki anahtar kelime TCP'dir. CONNECT yöntemi, spesifikasyonu gereği tam olarak bir TCP tüneli oluşturur. Akış tabanlı bir TCP bağlantısı açar ve iki bayt akışını birbirine bağlar. CONNECT'in tanımında datagramlarla çalışmak için herhangi bir mekanizma yoktur.

Uyumsuzluğun Üç Temel Nedeni

Bunun teknik bir eksiklik değil, kavramsal bir imkansızlık olduğunu madde madde açıklayalım.

  1. CONNECT akış modeline bağlıdır. HTTP, TCP üzerinde bir protokoldür. CONNECT yöntemi bu akış doğasını devralır. İki TCP akışını birbirine bağlayabilir, ancak UDP bir akış değil, bağımsız datagramlar kümesidir. Aralarında bir uyum yoktur. HTTP CONNECT'te bulunmayan ek bir kapsülleme protokolü olmadan, farklı hedef adreslere sahip birçok dağınık datagramı tek bir TCP tüneline sıkıştıramazsınız.
  2. Datagram adresleme mekanizması yoktur. UDP'de her datagram kendi adresine ve bağlantı noktasına gidebilir. Bir ses uygulaması aynı anda birden fazla sunucuyla iletişim kurabilir. CONNECT TCP tüneli sizi kurulum anında belirtilen tek bir adrese bağlar. SOCKS5'in kapsülleme başlığındaki DST.ADDR ve DST.PORT'un aksine, her bir datagramın hedef adresini belirtmek için bir alan sağlamaz.
  3. UDP için röle portu yoktur. SOCKS5, UDP için ayrı bir röle portu tahsis eder ve bunu istemciye bildirir. HTTP proxy'nin prensipte böyle bir mekanizması yoktur. Mimarisi, sunucu tarafında iletim için UDP soketlerinin açılmasını varsaymaz. HTTP proxy'nin yazılım kodu TCP bağlantılarıyla çalışır ve oraya UDP eklemek aslında yeni bir protokol yazmak anlamına gelir.

Sonsuza Kadar Hatırlanması Gereken Sonuç

HTTP ve HTTPS proxy'leri, geliştiricilerin üşenmesi nedeniyle değil, protokolleri tamamen TCP etrafında inşa edildiği için UDP'yi desteklemez. CONNECT yöntemi bir TCP tünelidir, nokta. Proxy üzerinden UDP'ye ihtiyacınız varsa, tek standart yol UDP ASSOCIATE komutunu destekleyen SOCKS5'tir. Ne kadar gelişmiş olursa olsun hiçbir HTTP proxy'si size UDP üzerinden ses, video veya oyun trafiği iletmez.

UDP Olmadan Tam Olarak Ne Bozulur: Belirtilerin Tam Haritası

Şimdi en pratik kısım. Hangi teknolojilerin UDP'ye bağlı olduğunu ve sıradan bir kullanıcının gözünden arızanın nasıl göründüğünü inceleyelim. Bu, belirtilere göre sorunu anında teşhis etmenize yardımcı olacaktır.

WebRTC ve STUN/TURN Bağlantısı

WebRTC, tarayıcıda görüntülü aramalar, sesli sohbetler, ekran paylaşımı ve birçok konferans hizmetinin üzerine inşa edildiği gerçek zamanlı bir teknolojidir. Medya akışının iletiminin temelinde UDP vardır çünkü canlı bir konuşma için hız, her paketin teslimat garantisinden daha önemlidir. Seste küçük paket kayıpları neredeyse farkedilmezken, TCP yeniden iletiminden kaynaklanan gecikmeler kaliteyi öldürür.

Bağlantı kurmak için WebRTC, STUN ve TURN protokollerini kullanır. STUN, NAT arkasındaki dış adresinizi bulmanıza yardımcı olurken, TURN doğrudan bağlantı mümkün olmadığında bir aktarıcı olarak hizmet eder. Hem STUN hem de medya akışları varsayılan olarak UDP üzerinden gider.

Kullanıcı açısından belirti: Arama görünüşte kurulur, çevir sesi göstergesi vardır, ancak karşı taraf sizi duymaz ve görmez veya bağlantı tek yönlüdür. Bazen arama birkaç saniye sonra düşer. Web arayüzü çalışır, sohbet çalışır, ancak ses ve görüntü gelmez. Bu, UDP'nin engellendiğinin klasik bir işaretidir.

QUIC ve HTTP/3, TCP'ye Geri Dönüşle

QUIC, UDP üzerine inşa edilmiş modern bir taşıma protokolüdür. Web'in en yeni sürümü olan HTTP/3 bunun üzerinde çalışır. QUIC, klasik TCP'den daha hızlı bağlantı kurulumu sağlar ve paket kayıplarıyla daha iyi başa çıkar. 2026 itibarıyla büyük sitelerin ve hizmetlerin önemli bir kısmı HTTP/3'ü desteklemektedir.

UDP kullanılamadığında ilginç bir şey olur: uygulama veya tarayıcı genellikle TCP üzerinden HTTP/2 veya HTTP/1.1'e geri döner. Bu, tasarımda yerleşik bir hata tolerans mekanizmasıdır.

Kullanıcı açısından belirti: Çoğu zaman bariz bir arıza yoktur, siteler açılır. Ancak QUIC'in avantajlarını kaybedersiniz: bağlantılar daha yavaş kurulur, kararsız ağda donmalar olabilir. Deneyimli bir gözlemci, sunucu desteklese bile HTTP/3'ün kullanılamadığını fark eder. Çoğu kişi için bu gizli bir performans düşüşüdür, bariz bir hata değil.

53. Bağlantı Noktasında UDP Üzerinden DNS

Klasik DNS sorguları geleneksel olarak 53. bağlantı noktasında UDP üzerinden gider. Kısa ad sorgulamaları için hızlı ve etkilidir.

Burada, adları uygulamanın nasıl çözümlediğine bağlı olarak bir incelik vardır. Çözümleme proxy tarafında yapılıyorsa sorun olmayabilir. Ancak uygulama, proxy üzerinden kendisi bir UDP DNS sorgusu göndermek istiyor ve UDP desteklenmiyorsa, çözümleme bozulur.

Kullanıcı açısından belirti: Site adları çözümlenmez, uygulama ana bilgisayar bulunamadı hatası verir, ancak internet vardır. Bazen sistem UDP'yi dener, yanıt alamaz ve DNS'in TCP sürümüne geçtiğinde gecikmeler gözlemlenir.

VoIP ve Sesli İletişim

VoIP, sesin internet üzerinden iletilmesidir. Ses protokolleri neredeyse her zaman ses iletimi için UDP kullanır çünkü gecikme kritiktir. Her paketin onayını beklemek zorunda olsaydınız canlı bir konuşma mümkün olmazdı.

Kullanıcı açısından belirti: Arama gider ancak ses yoktur, kesilir veya çok gecikir. Tek yönlü duyulabilirlik, metalik yapaylıklar, konuşmanın birkaç saniye sonra kesilmesi. Bunların hepsi UDP taşımasıyla ilgili sorunların işaretleridir.

Çevrimiçi Oyunlar

Birçok ağ oyunu, özellikle dinamik nişancı oyunları ve rekabetçi projeler, oyun dünyasının durumunu iletmek için UDP kullanır. Nedeni yine aynıdır: gecikme, teslimat garantisinden daha önemlidir. Oyuncunun eski bir konum paketi işe yaramaz; yenisi daha iyidir.

Kullanıcı açısından belirti: Oyun maça bağlanmaz, bağlantı ekranında takılı kalır, zaman aşımına uğrar. Veya bağlantı vardır ancak oyun takılmalarla gider, karakterler ışınlanır, eylemler kaydedilmez. Menü ve mağaza çalışabilir çünkü bunlar genellikle TCP üzerinden HTTP ile gider.

Torrentler ve P2P

Birçok P2P protokolü, kontrol bilgileri ve veri iletimi için UDP'yi aktif olarak kullanır. UDP olmadan işlevsellik düşer: düğüm keşfi ve iletim mekanizmalarının bir kısmı çalışmaz.

Kullanıcı açısından belirti: Yavaş çalışma, kaynak bulmada sorunlar, eksik işlevsellik.

Senaryoların UDP'ye Bağımlılığının Özet Tablosu

Aşağıda kaydetmeye değer pratik bir tablo var. Hangi senaryoda ne bekleyeceğinizi anında gösterir.

  • Görüntülü arama ve görüntülü sohbet. UDP kullanır: evet, kritik. UDP desteği olmadan: arama görsel olarak kurulur ancak ses ve video yoktur, tek yönlü bağlantı veya kesinti. Temel işlevsellik çalışmaz.
  • Çevrimiçi oyun. UDP kullanır: evet, çoğu dinamik oyun için. UDP desteği olmadan: maça bağlantı yok, zaman aşımları, takılmalar, ışınlanma. Oyun deneyimi imkansız veya çok bozulur.
  • DNS sorguları. UDP kullanır: evet, klasik DNS 53. bağlantı noktasında. UDP desteği olmadan: uygulama kendisi çözümlüyorsa çözümleme sorunları veya gecikmeler olabilir; proxy tarafında çözümleme yapılıyorsa sorun olmayabilir.
  • QUIC ve HTTP/3. UDP kullanır: evet, tamamen UDP üzerine inşa edilmiştir. UDP desteği olmadan: TCP HTTP/2'ye fark edilmeyen bir geri dönüş, hız ve avantaj kaybı, ancak siteler açılır.
  • Torrent ve P2P. UDP kullanır: evet, birçok mekanizma için. UDP desteği olmadan: işlevsellik düşüşü, kaynak bulma ve iletimde sorunlar.
  • Sıradan veri kazıma ve web kazıma. UDP kullanır: hayır, genellikle HTTP üzerinden saf TCP. UDP desteği olmadan: her şey normal çalışır, UDP gerekmez.
  • VoIP araması. UDP kullanır: evet, ses akışı için. UDP desteği olmadan: ses yok, kesintiler, gecikmeler, tek yönlü duyulabilirlik.

Son satıra dikkat edin. Klasik görevler (veri kazıma veya sıradan web gezinme) için UDP hiç gerekli değildir. Bu nedenle birçok kişi yıllarca UDP'siz proxy kullanır ve bir arama veya oyunla karşılaşana kadar bu sınırlamadan haberdar olmaz.

Test Pratiği: Proxy'nin UDP'yi Destekleyip Desteklemediğini Nasıl Anlarsınız

Araçların zamanı geldi. Basitten gelişmişe birkaç test yöntemini inceleyecek ve popüler yöntemlerin neden sık sık yanıltıcı olduğunu açıklayacağız.

curl Neden Sadece TCP'yi Test Eder

Birçok kişi, bir siteye socks5-hostname üzerinden curl komutuyla proxy'yi test etmeyi dener. İstek başarılı olursa, proxy çalışıyor demektir, dolayısıyla UDP de çalışır sonucuna varırlar. Bu bir tuzaktır.

Mesele şu ki, curl üzerinden HTTP isteği TCP üzerinden gider. socks5-hostname bayrağı ile komut, SOCKS5 proxy'sinin CONNECT komutunu çalıştırabildiğini ve adı kendi tarafında çözümleyebildiğini test eder. Ancak CONNECT TCP'dir. Böyle bir testin başarısı, yalnızca TCP'nin proxy üzerinden çalıştığını söyler. UDP ASSOCIATE desteği hakkında kesinlikle hiçbir şey bildirmez.

Demir kuralı unutmayın: TCP aracıyla yapılan test UDP'yi test etmez. UDP'yi test etmek için, UDP ASSOCIATE komutunu açıkça başlatmanız ve bir datagram iletmeye çalışmanız gerekir.

Yöntem 1: Python Soketleriyle Betik

UDP ASSOCIATE'i anlamanın ve test etmenin en şeffaf yolu, doğrudan soketlerle çalışan küçük bir betik yazmaktır. Belirli bir koda bağlı kalmadan mantığı adım adım açıklayalım, böylece özü anlarsınız.

  1. Proxy'ye bir TCP bağlantısı açın. Sıradan bir TCP soketiyle SOCKS5 sunucusunun ana bilgisayarına ve bağlantı noktasına bağlanın.
  2. Tanışma aşamasından geçin. Protokol sürümünü ve desteklenen kimlik doğrulama yöntemlerinin listesini gönderin. Sunucu tarafından seçilen yöntemi alın. Gerekirse kullanıcı adı ve şifre ile kimlik doğrulaması yapın.
  3. UDP ASSOCIATE komutunu gönderin. Sürüm, komut kodu 0x03, ayrılmış bayt ve adres ile bir istek oluşturun. Adres ve bağlantı noktası olarak genellikle sıfır belirtilir; bu, istemcinin henüz datagramları hangi adresten göndereceğini bilmediği anlamına gelir.
  4. Sunucunun yanıtını okuyun. İşte kilit nokta. Sürümden sonraki ilk alan yanıt kodudur. 0x00 değeri başarı anlamına gelir. 0x07 görürseniz, bu Command not supported, yani proxy UDP ASSOCIATE'i bilmiyor demektir. Sıfır olmayan diğer kodlar da bir hata olduğunu gösterir.
  5. Röle adresini çıkarın. Başarı durumunda, yanıttan BND.ADDR ve BND.PORT'u okuyun. Bunlar, datagramlarınızı göndermeniz gereken adres ve bağlantı noktasıdır.
  6. Bir test datagramı gönderin. Bir UDP soketi oluşturun, test yükünü RSV, FRAG, ATYP, DST.ADDR, DST.PORT alanlarıyla SOCKS5 başlığına sarın ve röle portuna gönderin. Hedef olarak UDP üzerinden yanıt veren herkese açık bir hizmeti kullanmak uygundur.
  7. Yanıtı bekleyin. Doğru şekilde sarılmış bir yanıt gelirse, proxy üzerinden UDP gerçekten çalışıyordur. Başarılı yanıt koduna rağmen sessizlik olursa, ilişkilendirme resmen vardır ancak fiili datagram iletimi gerçekleşmiyor demektir.

Bu yöntem kapsamlı bir tablo verir. Sunucunun UDP ASSOCIATE komutunu kabul edip etmediğini ve datagramların gerçekten gidip gelmediğini ayrı ayrı test edersiniz.

Yöntem 2: Proxy Üzerinden STUN Sorgusu

Harika bir pratik test, yük olarak bir STUN sorgusu kullanmaktır. STUN hafif bir protokoldür, herkese açık STUN sunucuları hızlı yanıt verir ve bu test WebRTC gerçek senaryosuna en yakın olanıdır.

Mantık aynıdır: bir UDP ilişkilendirmesi kurun, bir Binding Request tipi STUN sorgusunu SOCKS5 kapsülleme başlığına sarın, herkese açık bir STUN sunucusunun adresiyle röle portuna gönderin. Dış adresinizi içeren bir STUN yanıtı gelirse, proxy üzerinden UDP yolu çift yönlü iletim dahil tamamen işlevseldir. Bu, gerçek zamanlı senaryolar için en ikna edici testtir.

Yöntem 3: UDP Üzerinden DNS için Proxy Üzerinden dig

DNS sorgusu da iyi bir testtir çünkü anlaşılır bir yanıtı olan kompakt bir UDP datagramıdır. Fikir, SOCKS5 proxy'si üzerinden UDP ile herkese açık bir DNS sunucusuna bir DNS sorgusu yönlendirmektir.

Standart dig, UDP üzerinden SOCKS5 ile kendi başına gidemez, bu nedenle genellikle UDP trafiğini proxy üzerinden yönlendiren bir yardımcı sarmalayıcı kullanılır veya yukarıda açıklanan şemaya göre kapsülleme elle yapılır. DNS yanıtı gelirse, UDP kanalı çalışıyordur. Sorgu boşluğa gidiyor ve TCP çalışıyorsa, sonuç açıktır: UDP desteklenmiyor.

Yöntem 4: socat ve Yardımcı Araçlar

socat aracı, soketlerle çalışmak için güçlü bir İsviçre çakısıdır. Onunla UDP ve SOCKS bağlantıları da dahil olmak üzere yönlendirme zincirleri oluşturabilirsiniz. Ancak, tüm sürümlerin ve socat modlarının doğrudan UDP ASSOCIATE'i desteklemediğini anlamak önemlidir. socat genellikle SOCKS5 UDP kapsüllemesini üstlenen bir katmanla birlikte kullanılırken, socat yerel UDP yönlendirmesinden sorumludur.

Pratik yaklaşım: yerel bir UDP alıcısı kurun, bir katman aracılığıyla UDP trafiğini proxy'ye yönlendirin ve yükün hedefe ulaşıp ulaşmadığını ve yanıtın dönüp dönmediğini test edin. Bu, altyapı hata ayıklamasında yararlı olan daha mühendislik odaklı bir yoldur.

0x07 Yanıt Kodu Nasıl Doğru Okunur

0x07 Command not supported kodu en dürüst ve doğrudan sinyaldir. SOCKS5 sunucusunun UDP ASSOCIATE komutunuzu aldığı, tanıdığı ancak bu komutu çalıştırmadığı anlamına gelir. Bu yanıt, yalnızca CONNECT'i uygulayan proxy'ler için tipiktir.

Ancak daha sinsi bir senaryoya dikkat edin. Bazen sunucu UDP ASSOCIATE komutuna başarı kodu 0x00 ile yanıt verir, ancak gerçek datagram iletimi çalışmaz. Nedenleri farklıdır: proxy ile hedef arasında ağ filtresi, röle adresinin yanlış işlenmesi, barındırma kısıtlamaları. Bu nedenle yalnızca yanıt kodunu kontrol etmek yeterli değildir. Gerçek test, başarılı bir uçtan uca datagram iletimi ve yanıtın alınmasıdır. Bu nedenle gerçek yanıtlı STUN veya DNS testinde ısrar ediyoruz.

Proxy'nin UDP Desteğini Kontrol Etmek İçin Kontrol Listesi

  • Test ettiğiniz şeyin HTTP proxy değil, SOCKS5 olduğundan emin olun, çünkü HTTP proxy tanım gereği UDP'yi bilmez.
  • Bir yönetim TCP bağlantısı kurun ve kimlik doğrulamasından geçin.
  • UDP ASSOCIATE komutunu gönderin ve yanıt kodunu kontrol edin. 0x00 iyidir, 0x07 destek olmadığı anlamına gelir.
  • BND.ADDR ve BND.PORT'u çıkarın ve sıfır adres durumunu dikkate alarak doğru yorumlayın.
  • Kapsülleme formatına göre sarılmış gerçek bir test datagramı gönderin.
  • Doğru şekilde sarılmış bir yanıt bekleyin. Yalnızca bu, UDP çalışmasını onaylar.
  • Rastgele paket kaybını elemek için testi birkaç kez tekrarlayın.

Mobil Ağlarda UDP: NAT Zaman Aşımları ve Keepalive

Ayrı ve çok önemli bir konu da UDP'nin mobil ağlardaki davranışıdır. Açıklanamaz görünen birçok gizemli kesintinin nedeni burada yatmaktadır.

UDP Oturumu Neden TCP'den Önce Düşer

Cihazınızla internet arasında her zaman bir NAT (Ağ Adresi Çevirisi) mekanizması vardır. NAT, dahili ve harici adresler ile bağlantı noktalarının eşleme tablosunu tutar. Her bağlantı için bu tabloda bir kayıt oluşturulur ve sınırlı bir süre yaşar.

İşte kilit fark. TCP için NAT'ta bağlantının başlangıcı ve bitişine dair net sinyaller vardır: el sıkışmayı ve kapanışı görür. Bu nedenle NAT tablosundaki TCP kayıtları genellikle uzun süre, bazen onlarca dakika veya daha fazla yaşar.

UDP için her şey farklıdır. UDP'nin bağlantı kavramı yoktur, bu nedenle NAT oturumun ne zaman başlayıp bittiğini bilmez. Sadece trafik olduğu sürece kaydı tutar ve bir sessizlik süresinden sonra siler. Bu sessizlik süresine UDP NAT zaman aşımı denir ve mobil ağlarda genellikle çok kısadır, bazen sadece onlarca saniye.

Sonuç: UDP kanalında bir süre trafik olmazsa, NAT kaydı sessizce siler. Sonraki datagramlarınızın geri dönüş yolu kalmaz ve oturum kesilir. Oysa aynı koşullarda TCP bağlantısı yaşamaya devam ederdi.

Keepalive Neden Gereklidir

Keepalive, NAT'ın oturumu aktif sayması ve kaydı silmemesi için düzenli olarak küçük paketler göndermektir. UDP için keepalive, kısa zaman aşımları nedeniyle özellikle kritiktir.

İyi tasarlanmış gerçek zamanlı protokoller, periyodik keepalive veya kontrol paketlerini kendileri gönderir. Örneğin, WebRTC'de bağlantı kontrol mekanizması yolu sürekli olarak doğrular. Ancak uygulama sessiz kalırsa ve NAT zaman aşımı kısaysa, kesinti kaçınılmazdır. Bu nedenle, mobil ağlarda proxy üzerinden UDP ile çalışırken kanalı canlı tutma gerekliliğini hesaba katmalısınız.

Mobil Ağlarla İlgili Pratik Gözlemler

  • Mobil operatörler, NAT kaynaklarından tasarruf etmek için UDP'ye TCP'den daha agresif politikalar uygulama eğilimindedir.
  • UDP NAT zaman aşımı, operatörler arasında farklılık gösterebilir ve zamanla değişebilir, bu nedenle tek bir değer yoktur.
  • Kısa zaman aşımının belirtisi: bağlantı aktif aşamada mükemmel çalışır, ancak aramadaki sessiz anlar gibi duraklamalar sırasında kesilir.
  • UDP ilişkilendirmesi için SOCKS5 yönetim TCP bağlantısının da canlı tutulması gerekir; aksi takdirde proxy tüm ilişkilendirmeyi kapatır.

Bu, yüzeysel anlayışı derin anlayıştan ayıran ince bir noktadır. Proxy UDP ASSOCIATE'i doğru şekilde desteklese bile, kararsızlık proxy'den değil, mobil NAT'tan gelebilir. Kesintileri teşhis ederken her zaman zaman aşımı faktörünü aklınızda bulundurun.

Proxy Üzerinden UDP ile Çalışırken Yaygın Hatalar

En yaygın yanılgıları tek bir yerde toplayalım. Bunlardan kaçınarak saatlerce hata ayıklamadan kurtulursunuz.

Hata 1: socks5 ve socks5h'yi Karıştırmak

Birçok aracın ayarlarında SOCKS5 için iki yazım şekli vardır. socks5 şeması genellikle alan adı çözümlemesinin istemci tarafında yerel olarak yapıldığı ve proxy'nin hazır bir IP adresi aldığı anlamına gelir. socks5h şeması ise çözümlemenin proxy sunucusu tarafında yapıldığı anlamına gelir.

Bu neden önemli? İlk olarak, yerel çözümleme normal DNS'iniz üzerinden sızıntı yapabilir ve bu da gizlilik için istenmeyen bir durumdur. İkinci olarak, yanlış şema seçimi mantığın bir kısmının beklediğiniz gibi çalışmamasına neden olabilir. socks5 ve socks5h arasındaki karışıklık, proxy'nin bazen çalışıyor gibi göründüğü zor yakalanabilir hatalara yol açar. Adın nerede çözümleneceğini her zaman bilinçli olarak seçin.

Hata 2: SOCKS5 Olduğu İçin UDP'nin Çalıştığını Sanmak

Bu belki de en yaygın ve en tehlikeli yanılgıdır. SOCKS5 standardı UDP ASSOCIATE komutunu öngörür, ancak her uygulamanın bunu desteklemesini zorunlu kılmaz. Çok sayıda SOCKS5 proxy'si yalnızca CONNECT ve BIND'i uygular ve UDP ASSOCIATE'e 0x07 koduyla yanıt verir.

Başka bir deyişle, SOCKS5 etiketi UDP garantisi değildir. Bu sadece uygulanmış olabilecek veya olmayabilecek bir olasılıktır. Kesin olarak bilmenin tek yolu yukarıda açıkladığımız gibi test etmektir. Pazarlama etiketine asla güvenmeyin, gerçek teste güvenin.

Hata 3: UDP'yi Tarayıcıyla Test Etmek

Bazı kişiler, proxy üzerinden tarayıcıda bir site açarak UDP desteğini test etmeye çalışır. Ancak tarayıcı sitelere TCP üzerinden gider. Site UDP üzerinden HTTP/3'ü desteklese bile, UDP kullanılamadığında tarayıcı sessizce TCP'ye geri döner ve siz hiçbir şey fark etmezsiniz. Sayfanın başarıyla açılması UDP çalıştığını kanıtlamaz.

Dahası, tarayıcıdaki WebRTC, ağ kısıtlamalarını aşmak için kendi karmaşık mantığına sahiptir ve bazı yapılandırmalarda TCP üzerinden TURN kullanabilir, bu da resmi daha da karmaşık hale getirir. Bu nedenle tarayıcı, saf UDP taşıma testi için kötü bir araçtır. Doğrudan soket testleri kullanın.

Hata 4: Uçtan Uca Testi İhmal Etmek

Daha önce vurguladığımız gibi, UDP ASSOCIATE'ten 0x00 yanıtı almak çalışan UDP anlamına gelmez. Sadece yanıt koduna güvenmek bir hatadır. Her zaman testi, yanıt alınan gerçek bir datagram alışverişine kadar götürün. Bu, resmi desteği fiili çalışabilirlikten ayırır.

Hata 5: Keepalive ve Zaman Aşımlarını Hesaba Katmamak

UDP'yi yapılandırdıktan sonra NAT zaman aşımlarını unutmak kolaydır. Bu durumda kanal test anında çalışır, ancak gerçek kullanımda duraklamalar sırasında kesilir. Özellikle mobil ağlarda kanalı canlı tutacak bir mekanizma eklemeyi her zaman unutmayın.

Hata 6: Röle Adresini Yanlış İşlemek

Belirtildiği gibi, sunucu BND.ADDR'de sıfır adresi döndürebilir, bu da yönetim bağlantısıyla aynı ana bilgisayarı kullan anlamına gelir. Datagramları körü körüne sıfır adrese gönderen istemciler bozulur. Doğru uygulama, proxy'nin adresini TCP bağlantısından alır. Bu incelik, birçok sessiz hatanın nedenidir.

SOCKS5 Üzerinden UDP ile Çalışmak için Araçlar ve Kaynaklar

Pratik cephaneliğinizi bir araya getirelim.

Tanı Araçları

  • Python soketleriyle kendi betiğiniz. En esnek ve şeffaf araç. UDP ASSOCIATE komutunun oluşturulması ve datagram kapsüllemesi üzerinde tam kontrol sağlar. Hassas tanı için idealdir.
  • Proxy üzerinden STUN istemcisi. Gerçek zamanlı senaryolar için en iyi test. Hızlı yanıt, anlaşılır sonuç, WebRTC'ye en yakın.
  • UDP üzerinden DNS testi. Kompakt ve anlaşılır, kısa datagramların uçtan uca iletimini test etmek için mükemmeldir.
  • socat ve UDP kapsülleme katmanları. SOCKS5 üzerinden UDP yönlendirme zincirleri oluşturmak ve hata ayıklamak için mühendislik araçları.
  • Trafik analizörü. Paketleri gözlemlemek, datagramların röle portuna gidip gitmediğini ve yanıtların gelip gelmediğini görmeye yardımcı olur. Derin hata ayıklama için vazgeçilmezdir.

Standartlar Hakkında Bilinmesi Gerekenler

SOCKS5 ile ilgili temel belge RFC 1928'dir; bu belgede komutlar, istek ve yanıt formatı ile UDP kapsüllemesi açıklanır. Bu standardı anlamak, bir uzmanı rastgele hareket eden bir kullanıcıdan ayırır. Ek olarak, STUN, QUIC ve NAT çalışma prensiplerini anlamak faydalıdır çünkü pratik UDP sorunları bu teknolojilerin kesiştiği noktada ortaya çıkar.

Mini Karar Verme Çerçevesi

  1. UDP'ye ihtiyacınız olup olmadığını belirleyin. Veri kazıma ve sıradan web için hayır, aramalar, oyunlar, gerçek zamanlı için evet.
  2. UDP gerekiyorsa, proxy'nin HTTP değil, SOCKS5 olduğundan emin olun.
  3. Gerçek UDP ASSOCIATE desteğini etikete değil, uçtan uca testle doğrulayın.
  4. Özellikle mobil ağlarda keepalive ve NAT zaman aşımlarını hesaba katın.
  5. Röle adresini ve kapsülleme formatını doğru işleyin.

Vaka Çalışmaları ve Uygulama Sonuçları

Ulaşım bilgisinin gerçek sorunları nasıl çözdüğünü gösteren birkaç tipik durumu inceleyelim.

Vaka 1: Sessiz Görüntülü Arama

Durum. Kullanıcı, proxy üzerinden tüm sitelerin açıldığını, konferanstaki sohbetin çalıştığını ancak arama sırasında ne ses ne de video geldiğini bildiriyor. Karşı taraflar bağlantı göstergesi görüyor ancak iletişim yok.

Tanı. Proxy üzerinden TCP testi başarılı, bu ilk başta kafa karıştırıcı. Ardından UDP ASSOCIATE üzerinden uçtan uca STUN testi yapılır. Sunucu komuta 0x07 Command not supported koduyla yanıt verir.

Sonuç. Proxy yalnızca CONNECT'i uyguluyor, UDP hiç desteklenmiyor. WebRTC medya akışı UDP üzerinden geçemiyor, bu nedenle sessizlik. Ulaşım düzeyinde çözüm: uçtan uca testle doğrulanmış gerçek UDP ASSOCIATE desteğine sahip bir SOCKS5 gereklidir.

Vaka 2: Mobil Ağda Duraklamalarda Bağlantı Kesintisi

Durum. Mobil ağda proxy üzerinden sesli iletişim aktif konuşma sırasında mükemmel çalışıyor, ancak karşı taraflar yarım dakika sessiz kalınca bağlantı kesiliyor.

Tanı. Uçtan uca UDP testi başarılı, datagramlar her iki yönde gidip geliyor. Yani proxy'nin kendisi UDP'yi destekliyor. Davranış gözlemi, kesintilerin tam olarak trafiğin olmadığı duraklamalarda meydana geldiğini gösteriyor.

Sonuç. Suçlu, mobil operatörün kısa UDP NAT zaman aşımı. Sessizlik sırasında NAT tablosundaki kayıt siliniyor. Ulaşım düzeyinde çözüm: kanalı ve yönetim TCP bağlantısını canlı tutacak keepalive sağlayın.

Vaka 3: 0x00 Kodundan Kaynaklanan Yanlış Güven

Durum. Bir mühendis, UDP ASSOCIATE komutunu göndererek proxy'yi test etti, başarı kodu 0x00 aldı ve UDP'nin çalıştığını duyurdu. Ancak kullanıcılar hala çalışmayan aramalardan şikayet ediyor.

Tanı. Tekrar test, yanıt kodunun ötesine geçer: röle portuna gerçek bir STUN datagramı gönderilir. Başarılı koda rağmen yanıt gelmez.

Sonuç. Resmi destek var, ancak fiili iletim yok; muhtemelen proxy ile dış ağ arasındaki filtreleme veya röle adresi işleme hatası nedeniyle. Ders: 0x00 kodu yeterli değildir, yalnızca uçtan uca datagram iletimi çalışabilirliği kanıtlar.

Vaka 4: HTTP/3'ün Gizli Performans Düşüşü

Durum. Her şey çalışıyor gibi, siteler açılıyor, şikayet yok, ancak ekip bağlantıların beklenenden yavaş kurulduğunu ve HTTP/3'ün hiç kullanılmadığını fark ediyor.

Tanı. Test, UDP'nin proxy üzerinden geçmediğini gösteriyor, bu nedenle QUIC kullanılamıyor ve istemciler sessizce TCP'ye geri dönüyor.

Sonuç. Bu bir arıza değil, gizli bir performans kaybıdır. Ulaşım bilgisi, QUIC'in görev için önemli olup olmadığına bilinçli olarak karar vermenizi ve gerekirse UDP desteği sağlamanızı sağlar.

SSS: Sıkça Sorulan Sorular

UDP'yi herhangi bir şekilde HTTP proxy üzerinden iletmek mümkün müdür?

Standart yollarla hayır. HTTP proxy'deki CONNECT yöntemi yalnızca bir TCP tüneli oluşturur ve datagramları adresleme ve iletme mekanizmasına sahip değildir. Saf bir HTTP proxy üzerinden UDP'yi zorlama girişimleri, ilgili protokolün olmaması nedeniyle başarısız olur. UDP için uygun ve standartlaştırılmış yol, UDP ASSOCIATE komutuna sahip SOCKS5'tir.

Proxy SOCKS5 olarak adlandırılıyorsa, UDP'yi kesinlikle destekler mi?

Hayır, ve bu çok önemli bir nüanstır. Standart UDP ASSOCIATE'i öngörür ancak zorunlu kılmaz. Birçok SOCKS5 proxy'si yalnızca CONNECT'i destekler. Güvenilir tek yol, isme veya pazarlamaya güvenmek yerine gerçek bir datagram iletimi ile uçtan uca test yapmaktır.

curl proxy'nin çalıştığını gösterirken neden arama gitmiyor?

Çünkü curl, CONNECT komutu üzerinden TCP'yi test ederken, arama UDP kullanır. Bunlar iki farklı taşıyıcıdır. TCP testinin başarısı UDP hakkında hiçbir şey söylemez. UDP'yi test etmek için UDP ASSOCIATE'i başlatmanız ve bir datagram (örneğin STUN sorgusu) gönderip yanıt beklemeniz gerekir.

UDP ASSOCIATE denemesinde 0x07 yanıt kodu ne anlama gelir?

Bu Command not supported demektir. Proxy komutunuzu aldı, tanıdı ancak UDP ASSOCIATE'i çalıştırmadığını bildiriyor. Pratikte bu, proxy'nin UDP iletemediği anlamına gelir. Bu komutu gerçekten destekleyen başka bir proxy'ye ihtiyacınız var.

UDP iletmek istiyorsak UDP ASSOCIATE neden bir TCP bağlantısı kullanır?

Yönetim TCP bağlantısı iki amaca hizmet eder. İlk olarak, kimlik doğrulama ve anlaşma güvenilir bir şekilde üzerinden yapılır. İkinci olarak, UDP ilişkilendirmesinin ömrünü belirler: TCP açık olduğu sürece ilişkilendirme etkindir; kapanır kapanmaz proxy kaynakları serbest bırakır. Bu, oturum yönetimi ve temizlik için zarif bir yoldur.

Mobil ağda UDP bağlantısı neden kesilir de TCP dayanır?

NAT'ın özelliklerinden dolayı. TCP için NAT'ta başlangıç ve bitişe dair net sinyaller vardır, bu nedenle kayıtlar uzun yaşar. UDP'nin bağlantı kavramı yoktur ve NAT, kısa bir sessizlik süresinden sonra kaydı siler. Mobil ağlarda UDP zaman aşımı özellikle kısadır. Çözüm: kanalı canlı tutan düzenli keepalive.

UDP desteğini doğrudan tarayıcıda test edebilir miyim?

Güvenilir bir şekilde hayır. Tarayıcı sitelere TCP üzerinden gider ve UDP kullanılamadığında QUIC için sessizce TCP'ye geri döner. Tarayıcıdaki WebRTC, karmaşık mantığa sahiptir ve geçici çözümler kullanabilir. Tüm bunlar gerçek UDP durumunu maskeler. Saf test için doğrudan soket testleri, STUN veya UDP ASSOCIATE üzerinden DNS kullanın.

Pratikte socks5 ve socks5h arasındaki fark nedir?

Fark, alan adının nerede çözümlendiğidir. socks5'te ad genellikle istemci tarafında yerel olarak çözümlenir; socks5h'de proxy tarafında. Bu, çözümlemenin gizliliğini ve bazı senaryolardaki davranışı etkiler. Şemayı bilinçli seçmek, zor yakalanabilir hatalardan kurtarır.

SOCKS5'te datagram parçalamayı uygulamak zorunlu mu?

Pratikte hayır. FRAG alanı standartta öngörülmüştür, ancak uygulamaların büyük çoğunluğu yalnızca sıfır FRAG değeriyle (parçalama olmadan) çalışır. Datagramlar tek bir pakete sığmalıdır. UDP kullanan gerçek protokoller genellikle küçük datagramlarla çalışır, bu nedenle bu nadiren sorun yaratır.

Proxy sorununu mobil NAT sorunundan nasıl ayırt edebilirim?

Uçtan uca bir UDP testi yapın. Test hiç geçmezse ve komut 0x07 döndürürse veya datagramlar ulaşmazsa, sorun proxydedir. Test başarıyla geçiyor ancak kesintiler yalnızca gerçek kullanımdaki duraklamalarda oluyorsa, büyük olasılıkla suçlu kısa UDP NAT zaman aşımıdır. Bu analiz, kaynağı tam olarak belirler.

Sonuç: Ulaşım Her Şeydir

TCP ve UDP'nin temel kavramlarından SOCKS5'teki datagram kapsüllemesinin inceliklerine ve mobil ağların sinsi NAT zaman aşımlarına kadar bir yolculuk yaptık. Şimdi ana sonuçları pekiştirelim; bunlar sizi kahve telvesine bakan bir kullanıcıdan, taşıma katmanında ne olduğunu tam olarak anlayan bir kişiye dönüştürecek.

Birincisi, UDP ve TCP iki farklı dünyadır. UDP, garantisiz, hız için bağımsız datagramlar taşır ve aramalar, oyunlar, QUIC ve klasik DNS ona dayanır. TCP'yi iletebilen bir proxy, UDP'yi de iletecek diye bir şey yoktur.

İkincisi, UDP için standart yol yalnızca SOCKS5 ve UDP ASSOCIATE komutudur. Mekanizma zariftir: bir yönetim TCP bağlantısı, ayrı bir röle portu ve her datagramın RSV, FRAG, ATYP, DST.ADDR ve DST.PORT alanlarını içeren bir başlıkla kapsüllenmesi.

Üçüncüsü, HTTP ve HTTPS proxy'leri prensipte UDP'yi geçirmez. CONNECT yöntemi yalnızca bir TCP tüneli oluşturur; mimarisinde ne datagram adreslemesi ne de röle portu vardır.

Dördüncüsü, SOCKS5 etiketi UDP garantisi değildir. Her zaman uçtan uca bir testle doğrulayın; işi gerçek bir datagram iletimi ve yanıt almaya kadar götürün. 0x00 kodu fiili alışveriş olmadan hiçbir şey kanıtlamaz; 0x07 kodu ise desteğin olmadığını dürüstçe bildirir.

Beşincisi, mobil ağlarda UDP, kısa NAT zaman aşımları nedeniyle daha hassastır. Keepalive ve yönetim bağlantısını canlı tutmak, duraklamalardaki gizemli kesintilerden kurtarır.

Sonraki adımlarınız basit. Senaryo tablomuzu kullanarak belirli göreviniz için UDP'ye ihtiyacınız olup olmadığını belirleyin. Gerekiyorsa, bir SOCKS5 ile çalıştığınızdan emin olun ve STUN, DNS veya doğrudan soket betiği ile gerçek UDP ASSOCIATE desteğini test edin. Keepalive ekleyin ve röle adresini doğru işleyin. Bunu yaptığınızda, kendinizi asla proxy çalışıyor gibi görünürken aramanın sessiz kaldığı bir durumda bulmayacaksınız. Artık nerede arayacağınızı ve taşıma katmanında nasıl düzelteceğinizi tam olarak biliyorsunuz.