SOCKS5 UDP ASSOCIATE DNS'imizi Nasıl Çökertti?

Yaklaşık bir yıl önce, RFC'ye birebir uygun bir özellik geliştirdik — ve prodüksiyonu çökertti. Geri aldık, derine indik, sorunun kaynağını bulduk. Spoiler: sorun DNS değildi. Portların sınırlı bir kaynak olduğunu unutmuştuk.

Mobil proxy'lere mi ihtiyacınız var?
Hemen mobil proxy oluşturun!
Ücretsiz 48 saatlik denemeyi başlatın

Özet

iProxy.online proxy sunucularımıza tam SOCKS5 UDP ASSOCIATE desteği (RFC 1928) ekledik. Birkaç gün sonra DNS çözümlemesi durdu, tüneller koptu, rastgele servisler zaman aşımına uğramaya başladı. Geri aldık ve araştırmaya koyulduk. Kök neden: Linux'ta geçici port tükenmesi — binlerce UDP association'ın her biri ayrı bir port tutuyordu ve sistem genelindeki port havuzunu tamamen boşaltıyordu. Çözüm iki konfigürasyon parametresiydi. Sorunu bulmak ise çok daha uzun sürdü.

SOCKS5 UDP ASSOCIATE Nedir?

SOCKS5, RFC 1928 ile tanımlanan üç komut destekler: CONNECT (TCP tünelleme), BIND (gelen TCP bağlantılarını kabul etme) ve UDP ASSOCIATE (UDP datagramlarını yönlendirme). Proxy sağlayıcıların büyük çoğunluğu yalnızca CONNECT komutunu uygular. UDP ASSOCIATE en zor olanıdır — ve VoIP, oyun trafiği, DNS-over-UDP ve QUIC gibi gerçek zamanlı uygulamalar için kritik olan da odur.

Çalışma mantığı şöyledir:

1. İstemci, SOCKS5 sunucusuna bir TCP kontrol bağlantısı açar.
2. İstemci, bu TCP bağlantısı üzerinden UDP ASSOCIATE isteği gönderir.
3. Sunucu, geçici bir port üzerinde ayrılmış bir UDP soketi tahsis eder ve istemciye adres ile port numarasını bildirir.
4. İstemci, UDP datagramlarını bu relay portuna gönderir. Sunucu bunları hedefe iletir ve yanıtları geri yönlendirir.
5. Association, TCP kontrol bağlantısı kapanana veya oturum zaman aşımına uğrayana kadar devam eder.

Her bir UDP association, sunucuda ayrı bir geçici port tutar. İşte kritik detay tam da bu.

Tuzak şurada: UDP bağlantısızdır (connectionless). FIN yok, RST yok. İstemcinin işinin bittiğini nasıl anlayıp portu serbest bırakacaksınız?

1. TCP kontrol bağlantısının kapanmasını bekle — RFC'nin öngördüğü sinyal. Ancak istemciler bu bağlantıyı süresiz açık tutabilir.
2. Boşta kalma zaman aşımı. Belirli bir süre datagram gelmezse association'ı sonlandır. Ama zaman aşımı çok yüksekse soketler birikmeye başlar.

Biz cömert zaman aşımları ayarladık ve tek bir istemcinin açabileceği association sayısını sınırlamadık. Soketler birikmek için bekliyormuş gibi birikti.

Altyapımız

iProxy.online olarak 100'den fazla ülkede ve 600'den fazla mobil operatörde mobil proxy altyapısı işletiyoruz; gerçek Android telefonları proxy sunucuya dönüştürüyoruz. Konsepte yeni olanlar için 4G proxy ağı kurma rehberimiz mimariyi detaylıca anlatıyor. Backend SOCKS5 proxy sunucularımız on binlerce eşzamanlı bağlantıyı yönetiyor.

Yaklaşık bir yıl önce tam UDP ASSOCIATE desteği sunmaya karar verdik — RFC uyumlu olmak ve rakiplerin çoğunun sunamadığı kullanım senaryolarının kilidini açmak istedik: VoIP proxy, oyun trafiği, QUIC tabanlı protokoller. Uygulama doğruydu. Testler geçti. Yayına aldık.

---

Bu ölçekte proxy altyapısı kurmak, her protokol kararının gerçek sonuçları olması demek. iProxy.online'da her Android cihaz bağımsız bir mobil proxy sunucu olarak çalışır — SOCKS5, HTTP ve artık tam UDP desteğiyle — tek bir kontrol paneli veya Telegram bot üzerinden yönetilir. Sistemi nasıl çökerttik okumadan önce nasıl çalıştığını görmek istiyorsanız, 48 saatlik ücretsiz denemeyi başlatın — kredi kartı gerekmez.

---

Ne Ters Gitti?

Birkaç gün sonra prodüksiyon sunucuları tuhaf, birbiriyle ilgisiz görünen belirtiler sergilemeye başladı:

• DNS çözümlemesi durdu. Dahili servisler birbirlerine hostname ile ulaşamıyordu.
• Tüneller koptu. Sunuculara yönetim bağlantısı kesildi.
• NTP senkronizasyonu başarısız oldu. Sunucu saatleri kaymaya başladı.
• Rastgele UDP tabanlı servisler belirli bir kalıp olmadan zaman aşımına uğruyordu.

Arıza kademeli değildi — uçurum gibiydi. Saatlerce sorunsuz çalışır, ardından aynı sunucuda birden fazla servis eşzamanlı olarak çökerdi. UDP ASSOCIATE'i geri aldık ve araştırmaya başladık.

Kök Nedenin Bulunması

İlk içgüdümüz yanlıştı. DDoS saldırısı, bellek sızıntısı, disk I/O doygunluğu ve CPU yükü kontrol ettik — hepsi normaldi. Uygulama düzeyindeki sağlık kontrolleri, her şey çökene kadar yeşil görünüyordu.

Çığır açan bulgu, çoğu ekibin hiç bakmadığı düşük seviye sistem metriklerinden geldi:

node_sockstat_UDP_inuse on binlere tırmanıyordu. Sağlıklı bir sunucuda bu sayı birkaç yüz civarındadır. Bizimki 20 bini aştı.

ICMP Type 3 Code 3 (port unreachable) sayaçları fırladı. Çekirdeğin söylediği şuydu: "Bu giden UDP paketi için kaynak port tahsis edemiyorum."

Manuel kontrolle doğruladık:

ss -u state all | wc -l
# 28,431

cat /proc/net/sockstat
# UDP: inuse 28419

Linux'ta geçici port aralığı varsayılan olarak 32768–60999'dur — yaklaşık 28.000 port. Neredeyse tamamını tüketmiştik.

Domino Etkisi

Hesap basit. Linux'un sınırlı bir geçici port havuzu var — varsayılan olarak yaklaşık 28 bin. Her UDP ASSOCIATE bir port yer. Yüzlerce eşzamanlı association artı yavaş temizleme, havuzun tükenmesi demek.

Geçici portlar bittiğinde, sunucuda yeni bir UDP soketi açması gereken her şey başarısız olur. DNS dahil — her giden DNS sorgusu, port 53'e istek göndermek için geçici bir kaynak porta ihtiyaç duyar. Ad çözümleme ölür ve DNS ile hiçbir ilgisi olmayan nedenlerle sunucudaki her şey çalışmaz hale gelir.

Domino etkisi şöyle işledi:

Port tahsisi → her UDP ASSOCIATE, bind() çağrısını port 0 ile yapar ve çekirdekten bir sonraki boş geçici portu ister.

Port birikimi → port, TCP kapanana veya boşta kalma zaman aşımı dolana kadar açık kalır. Cömert zaman aşımları, portların serbest bırakılmasından daha hızlı birikmesi anlamına gelir.

Havuz tükenmesi → binlerce association'ın her biri bir port tuttuğunda, havuzun tamamı boşalır. bind() her yeni soket için EADDRINUSE döndürmeye başlar.

Sistem genelinde çökme → DNS sorguları başarısız olur (systemd-resolved da geçici port ister). WireGuard el sıkışmaları başarısız olur. NTP başarısız olur. Syslog-over-UDP sessizce ölür. Ardından DNS çökmesi ikincil bir domino etkisi yaratır — hostname çözen her şey durur; sağlık kontrolleri, veritabanı bağlantıları ve izleme ajanları dahil. CPU, bellek ve disk sorunsuz olmasına rağmen sunucu "çökmüş" görünür.

Standart İzleme Neden Yakalayamadı?

HTTP sağlık kontrolleri geçiyordu — uç nokta dinleme yapıyordu. CPU, bellek, disk, bant genişliği normal. Süreç düzeyindeki metrikler olağandışı bir şey göstermiyordu. SOCKS5 süreci sağlıklıydı. Tükenen, çekirdeğin port havuzuydu ve standart bir Grafana panosunda bunu izleyen hiçbir şey yoktu.

Durumu yakalayan tek metrikler, neredeyse arka düşünce olarak eklediğimiz çekirdek düzeyindeki soket sayaçları ve ICMP hata oranlarıydı.

Çözüm

İki parametre ile çözdük. Hata ayıklama, düzeltmeden çok daha uzun sürdü.

1. Boşta kalma zaman aşımlarını radikal şekilde düşürdük. UDP association'lar için boşta kalma zaman aşımını dakikalardan saniyelere indirdik. Relay portundan belirli bir süre datagram geçmezse, association sonlandırılır ve port serbest bırakılır. Meşru UDP oturumlarının çoğu (DNS sorguları, NTP) bir saniyenin çok altında tamamlanır. Uzun süreli oturumlar (VoIP, oyun trafiği) süregelen trafik sayesinde association'ı canlı tutar, dolayısıyla etkilenmezler.

2. İstemci başına eşzamanlı association sınırı. Tek bir istemcinin aynı anda tutabileceği UDP association sayısını sınırladık. Bu, herhangi bir kullanıcının — veya hatalı davranan istemcinin — port havuzunu tekelleştirmesini engeller. Sınır, meşru kullanım için yeterince geniş ama kontrolsüz birikmeyi engelleyecek düzeyde.

Bu iki değişiklik, UDP_inuse değerini 28 binden birkaç yüze düşürdü. UDP ASSOCIATE'i yeni sınırlarla tekrar yayına aldık ve o zamandan beri kararlı çalışıyor.

---

Sams fixin kendisi basitti — asıl zor olan, on binlerce eşzamanlı oturumu sistem kaynaklarını tüketmeden yönetebilen bir SOCKS5 UDP ASSOCIATE altyapısı inşa etmekti. Tam UDP relay desteği ve düzgün yaşam döngüsü yönetimi sunan bir mobil proxy arıyorsanız, iProxy.online gerçek Android cihazlarda 600+ operatörle çalışır; IP rotasyonu, cihaz bazında kontrol ve aylık 6 dolardan başlayan planlar sunar.

---

Neleri İzlemelisiniz?

UDP soketlerini ölçekte açan herhangi bir altyapı işletiyorsanız — SOCKS5 proxy sunucu, oyun sunucuları, VoIP altyapısı, QUIC relay — şunları izleme yığınınıza ekleyin:

1. node_sockstat_UDP_inuse (node_exporter). Gerçek zamanlı açık UDP soket sayısı. Normal bir sunucu birkaç yüzde seyreder. Prometheus kullanıyorsanız bu metrik zaten mevcuttur — sadece bir panel ve alarm kuralı gerekir. 5.000 üzeri için alarm öneririz.
2. node_netstat_Icmp_OutDestUnreachs (ICMP Type 3 Code 3, port unreachable). Sıçramalar, çekirdeğin kimsenin dinlemediği portlara gelen UDP paketlerine yanıt verdiği anlamına gelir. Dakikada birkaç tane normaldir. Saniyede binlerce tane yangın demektir.
3. ss -u state all | wc -l — olay anında hızlı bir kontrol.
4. cat /proc/net/sockstat — bağımlılığı sıfır olan klasik tek satırlık komut.

Bunlar varsayılan panoların çoğunda yer almaz. Alması gerekir. Proxy altyapınızı sağlıklı tutma hakkında daha fazla bilgi için proxy hızı ve kararlılığını optimize etme rehberimize göz atın.

Çıkarılan Dersler

Portlar sınırlı bir kaynaktır — bütçeleyin. CPU, RAM, disk ve bant genişliği için bütçe yaparız. Kimse geçici portlar için bütçe yapmaz. On binlerce bağlantı yöneten bir sunucuda ~28 bin port hiç de fazla değildir. Aralığı sysctl -w net.ipv4.ip_local_port_range="1024 65535" ile genişletebilirsiniz, ancak her association bir portu süresiz tuttuğunda 64 bin bile sınırlıdır.

RFC'ler NE'yi söyler, NASIL'ı değil. RFC 1928, "yoğun" bir sunucunun yüzlerce bağlantı yönettiği 1996'da yazıldı. Protokol mekaniğini kusursuz tanımlar. Port yaşam döngüsü yönetimi, kaynak sınırları veya zarif degredasyon hakkında hiçbir şey söylemez. Herhangi bir protokolü ölçekte uyguluyorsanız, doğruluk için RFC'yi okuyun ve kendi kaynak yönetiminizi üzerine inşa edin.

Çekirdek metrikleri, uygulama metriklerinin kaçırdıklarını yakalar. Sağlık kontrolleri, Prometheus toplayıcıları ve HTTP ping'leri sunucuların sağlıklı olduğunu söylüyordu. Çekirdek gerçeği biliyordu. İzlemeniz soket istatistikleri ve ICMP sayaçlarını içermiyorsa, kaynak tükenme arızalarının bütün bir sınıfı için kör noktanız var demektir. Android cihaz filomuzda sessiz TLS 1.3 hatalarıyla karşılaştığımızda da benzer bir gözlemlenebilirlik boşluğuyla yüzleştik — farklı kök neden, aynı ders.

UDP'nin açık yaşam döngüsü yönetimine ihtiyacı var. TCP'de yerleşik yaşam döngüsü vardır — bağlantılar açılır, veri aktarır ve tanımlı bir el sıkışmayla kapanır. Portlar TIME_WAIT sonrasında yeniden kullanılır. UDP'de bunların hiçbiri yoktur. Bir soket, açıkça kapatılana kadar açık kalır. Relay mimarilerinde kendi yaşam döngünüzü inşa etmelisiniz, aksi halde sınırsız kaynak tüketimini kabul edersiniz.

Kimler Bu Durumdan Endişelenmeli?

Bu sadece bir proxy sorunu değil. Kullanıcı isteklerine göre UDP soketi tahsis eden herhangi bir altyapı aynı uçuruma düşebilir:

• TURN/STUN sunucuları (WebRTC için) — her medya relay'i bir port çifti tahsis eder.
• Oyun sunucuları — oyuncu oturumlarının her biri bir UDP portu tutabilir.
• QUIC yük dengeleyiciler — bağlantı göçü (connection migration) port birikmesine yol açabilir.
• DNS özyinelemeli çözücüler — her giden sorgu geçici port kullanır.
• VPN yoğunlaştırıcılar — WireGuard ve IPsec IKE, ikisi de UDP'ye dayanır.

Bunlardan herhangi birini ölçekte işletiyorsanız — veya bir mobil proxy çiftliği kuruyorsanız — bugün sockstat değerlerinizi kontrol edin. Uçuruma düşünden daha yakın olabilirsiniz.

Son Söz

SOCKS5 UDP ASSOCIATE'i doğru şekilde uyguladık — RFC uyumlu, test edilmiş, dağıtılmış. Ve standart izlemenin göremediği sistem genelinde bir çökmeye neden oldu.

Artık kesin kural olarak uyguladığımız çıkarım: çekirdek düzeyinde kaynak tahsis eden her özellik — portlar, dosya tanımlayıcılar, conntrack girişleri — birinci günden itibaren açık yaşam döngüsü yönetimi ve kaynak bütçelemesi gerektirir. İlk kesintiden sonraki yamama olarak değil.

Portlar oksijen gibidir. Bitene kadar farkına varmazsınız.

---

Bu, iProxy.online'dan gerçek bir prodüksiyon olayıdır. 100'den fazla ülkede ve 600'den fazla operatörde Android telefonları SOCKS5 ve HTTP proxy sunuculara dönüştüren mobil proxy altyapısı kuruyoruz. Tam UDP ASSOCIATE desteği dahil — artık düzgün kaynak yönetimiyle birlikte. iProxy'yi deneyin →