Як SOCKS5 UDP ASSOCIATE поклав наш DNS

Майже рік тому ми реалізували RFC-фічу «за підручником» — і вона поклала продакшн. Відкотили, розібралися, знайшли причину. Спойлер: справа була не в DNS. Ми просто забули, що порти — ресурс скінченний.

украинский

Потрібні мобільні проксі?
Створіть проксі просто зараз!
Почніт​​ь 48-годинний пробний період

TL;DR

Ми додали повну підтримку SOCKS5 UDP ASSOCIATE (RFC 1928) на проксі-серверах iProxy.online. За кілька днів DNS перестав резолвити, тунелі почали відвалюватись, а різні сервіси — випадково таймаутити. Відкотили, почали копати. Корінна причина — вичерпання ефемерних портів на Linux: тисячі UDP-асоціацій тримали по окремому порту, висмоктуючи весь системний пул. Фікс — два конфіг-параметри. Знайти проблему було значно довше.

Що таке SOCKS5 UDP ASSOCIATE?

SOCKS5, описаний у RFC 1928, підтримує три команди: CONNECT (TCP-тунелювання), BIND (прийом вхідних TCP-з'єднань) і UDP ASSOCIATE (ретрансляція UDP-датаграм). Більшість проксі-провайдерів реалізують тільки CONNECT. UDP ASSOCIATE — найскладніша команда, і водночас та, що потрібна для реальних застосувань: VoIP, ігровий трафік, DNS-over-UDP, QUIC.

Як це працює:

1. Клієнт відкриває TCP-з'єднання керування з SOCKS5-сервером.

2. Через це TCP-з'єднання клієнт надсилає запит UDP ASSOCIATE.

3. Сервер виділяє окремий UDP-сокет на ефемерному порту та повертає адресу й номер порту.

4. Клієнт відправляє UDP-датаграми на цей relay-порт. Сервер пересилає їх до адресата та повертає відповіді.

5. Асоціація живе, поки TCP-з'єднання керування не закриється або не спрацює таймаут сесії.

Кожна UDP-асоціація займає окремий ефемерний порт на сервері. Ось ключова деталь.

А ось пастка. UDP — протокол без з'єднання. Ніякого FIN, ніякого RST. Як зрозуміти, що клієнт закінчив, і звільнити порт?

1. Чекати закриття TCP-з'єднання керування — сигнал за RFC. Але клієнти можуть тримати його відкритим нескінченно.

2. Idle timeout. Якщо датаграми не приходять X секунд — вбиваємо асоціацію. Але якщо таймаут завеликий, сокети накопичуються.

Ми виставили щедрі таймаути й не обмежили кількість асоціацій на одного клієнта. Сокети накопичились.

Наша інфраструктура

У iProxy.online ми керуємо інфраструктурою мобільних проксі у 100+ країнах і 600+ мобільних операторах, перетворюючи реальні Android-пристрої на проксі-сервери. Якщо ви новачок у цій темі, наш гайд про побудову мережі 4G-проксі детально описує архітектуру. Наші бекенд-сервери SOCKS5 обробляють десятки тисяч одночасних з'єднань.

Приблизно рік тому ми вирішили впровадити повну підтримку UDP ASSOCIATE — стати по-справжньому RFC-сумісними та відкрити юзкейси, які більшість конкурентів не тягне: проксіювання VoIP, ігрового трафіку, QUIC-протоколів. Реалізація була коректною. Тести пройшли. Викатили.

---

Проксі-інфраструктура такого масштабу — це коли кожне рішення щодо протоколу має реальні наслідки. У iProxy.online кожен Android-пристрій працює як окремий мобільний проксі сервер — SOCKS5, HTTP і тепер повний UDP — з керуванням через єдиний дашборд або Telegram-бот. Хочете побачити, як система працює, перш ніж читати, як ми її зламали? Створити мобільний проксі — безкоштовний 48-годинний тріал, без прив'язки картки.

---

Що пішло не так

За кілька днів після деплою на продакшн-серверах почалися дивні, на перший погляд не пов'язані між собою симптоми:

• DNS перестав резолвити. Внутрішні сервіси не могли знайти один одного за hostname.
• Тунелі відвалювались. Управлінське з'єднання з серверами втрачалось.
• Синхронізація NTP зламалась. Годинники серверів почали «плисти».
• Випадкові UDP-сервіси таймаутили без зрозумілої закономірності.

Збій був не поступовим — а обривним. Все працювало нормально годинами, а потім кілька сервісів падали одночасно на одному хості. Ми відкотили UDP ASSOCIATE і почали розбиратися.

Пошук кореневої причини

Перший інстинкт виявився хибним. Перевірили DDoS-атаки, витоки пам'яті, навантаження на диск, CPU — все в нормі. Аплікаційні хелсчеки горіли зеленим аж до моменту, коли все вмирало.

Прорив прийшов від низькорівневих системних метрик, на які більшість команд навіть не дивиться:

node_sockstat_UDP_inuse повзла вгору до десятків тисяч. На здоровому сервері ця цифра тримається в межах кількох сотень. У нас пробила 20K.

Лічильники ICMP Type 3 Code 3 (port unreachable) злетіли вгору. Це ядро каже: «Не можу виділити вихідний порт для цього UDP-пакета».

Швидка ручна перевірка підтвердила:

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

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

Діапазон ефемерних портів у Linux за замовчуванням — 32768–60999, тобто приблизно 28 000 портів. Ми спожили майже всі.

Каскад

Ось арифметика. Linux має скінченний пул ефемерних портів — близько 28K за замовчуванням. Кожна UDP-асоціація з'їдає один. Сотні одночасних асоціацій плюс повільне очищення — і пул вичерпано.

Коли ефемерні порти закінчуються, будь-що на сервері, що намагається відкрити новий UDP-сокет, — ламається. Включно з DNS: кожен вихідний DNS-запит потребує ефемерного порту, щоб відправити запит на порт 53. Резолвінг імен помирає, і раптом все на сервері зламано з причин, які не мають жодного стосунку до DNS.

Каскад:

Виділення портів → кожна UDP-асоціація викликає bind() з портом 0, просячи ядро віддати наступний вільний ефемерний порт.

Накопичення портів → порт залишається відкритим, поки TCP не закриється або не спрацює idle timeout. Щедрі таймаути означають, що порти накопичуються швидше, ніж звільняються.

Вичерпання пулу → тисячі асоціацій тримають по порту, весь пул висихає. bind() починає повертати EADDRINUSE для кожного нового сокета.

Системний збій → DNS-запити не проходять (systemd-resolved теж потребує ефемерних портів). WireGuard-хендшейки ламаються. NTP ламається. Syslog-over-UDP мовчки помирає. Потім збій DNS спричиняє вторинний каскад — все, що резолвить hostname, перестає працювати, включно з хелсчеками, підключеннями до БД і моніторинговими агентами. Сервер виглядає «мертвим», хоча CPU, пам'ять і диск — в нормі.

Чому стандартний моніторинг не помітив

HTTP-хелсчеки проходили — ендпоінт слухав. CPU, пам'ять, диск, пропускна здатність — норма. Метрики на рівні процесів не показували нічого незвичайного. SOCKS5-процес був здоровий. Вичерпався пул портів ядра, а це жоден стандартний дашборд Grafana не трекає.

Єдині метрики, які це зловили — ті, що ми додали майже «для галочки»: лічильники сокетів на рівні ядра та частота ICMP-помилок.

Як полагодили

Два конфіг-параметри. Дебаг зайняв більше часу, ніж фікс.

1. Різко скоротили idle timeout. Зменшили таймаут бездіяльності UDP-асоціацій з хвилин до секунд. Якщо через relay-порт не проходять датаграми протягом короткого інтервалу — асоціація закривається, порт звільняється. Більшість легітимних UDP-сесій (DNS-запити, NTP) завершуються значно менш ніж за секунду. Довготривалі сесії (VoIP, ігри) підтримують асоціацію активним трафіком, тому їх це не зачіпає.

2. Ліміти одночасних асоціацій на клієнта. Обмежили кількість одночасних UDP-асоціацій для одного клієнта. Це не дає жодному користувачу — чи клієнту з багами — монополізувати пул портів. Ліміт достатньо щедрий для легітимного використання, але зупиняє неконтрольоване накопичення.

Разом ці два параметри повернули UDP_inuse з 28K до кількох сотень. Ми перезапустили UDP ASSOCIATE з новими лімітами, і відтоді все працює стабільно.

---

Сам фікс був простим — складніше було побудувати підтримку SOCKS5 UDP ASSOCIATE, яка витримує десятки тисяч одночасних сесій без виснаження системних ресурсів. Якщо вам потрібен мобільний проксі з повним UDP relay і правильним управлінням життєвим циклом з'єднань, iProxy.online працює на реальних Android-пристроях у 600+ операторів, з ротацією IP, контролем кожного пристрою та тарифами від $6/міс. Безкоштовний 48-годинний тріал — перевірте на реальному навантаженні.

---

Що варто моніторити

Якщо ви запускаєте щось, що відкриває UDP-сокети у великих кількостях — SOCKS5 проксі, ігрові сервери, VoIP-інфраструктуру, QUIC-релеї — додайте до свого стеку:

1. node_sockstat_UDP_inuse (node_exporter). Кількість відкритих UDP-сокетів у реальному часі. Здоровий сервер тримається на кількох сотнях. Якщо у вас Prometheus — метрика вже є, потрібні лише панель і алерт. Рекомендуємо алертити від 5 000.

2. node_netstat_Icmp_OutDestUnreachs (ICMP Type 3 Code 3, port unreachable). Сплески означають, що ядро відповідає на UDP-пакети, які прилітають на порти, де ніхто не слухає. Кілька на хвилину — шум. Тисячі на секунду — пожежа.

3. ss -u state all | wc -l — швидка перевірка під час інциденту.

4. cat /proc/net/sockstat — класичний однорядковий чек без залежностей.

Ці метрики відсутні в більшості дефолтних дашбордів. А мали б бути. Детальніше про підтримку проксі-інфраструктури в здоровому стані — у нашому гайді про оптимізацію швидкості й стабільності проксі.

Уроки, які ми винесли

Порти — скінченний ресурс, плануйте їх бюджет. Ми плануємо CPU, RAM, диск, смугу пропускання. Ніхто не планує ефемерні порти. На сервері з десятками тисяч з'єднань ~28K портів — це небагато. Можна розширити діапазон через sysctl -w net.ipv4.ip_local_port_range="1024 65535", але навіть 64K — скінченне число, коли кожна асоціація тримає порт нескінченно.

RFC каже ЩО, а не ЯК. RFC 1928 писали у 1996 році, коли «навантажений» сервер обробляв сотні з'єднань. Він ідеально описує механіку протоколу. Але нічого не каже про управління життєвим циклом портів, ліміти ресурсів чи graceful degradation. Якщо реалізуєте будь-який протокол на масштабі — читайте RFC для коректності, а управління ресурсами проектуйте самі.

Метрики ядра бачать те, що аплікаційні — ні. Хелсчеки, Prometheus-скрейпери, HTTP-пінги — все казало, що сервери здорові. Ядро знало краще. Якщо ваш моніторинг не включає статистику сокетів і лічильники ICMP, у вас є сліпа зона для цілого класу збоїв через вичерпання ресурсів. Ми зіткнулися з аналогічним розривом у спостережуваності при виявленні прихованих збоїв TLS 1.3 на нашому парку Android-пристроїв — інша корінна причина, але урок той самий.

UDP потребує явного управління життєвим циклом. У TCP є вбудований lifecycle — з'єднання відкриваються, передають дані й закриваються визначеним хендшейком. Порти перевикористовуються після TIME_WAIT. У UDP цього немає. Сокет висить відкритим, поки щось явно його не закриє. У relay-архітектурах ви мусите будувати свій lifecycle, інакше — необмежене споживання ресурсів.

Кому ще варто хвилюватися

Це не тільки проксі-проблема. Будь-яка інфраструктура, що виділяє UDP-сокети за запитами користувачів, може впертися в той самий обрив:

• TURN/STUN-сервери для WebRTC — кожен медіа-релей виділяє пару портів.
• Ігрові сервери — сесія кожного гравця може тримати UDP-порт.
• QUIC-балансувальники — міграція з'єднань може призводити до накопичення портів.
• Рекурсивні DNS-резолвери — кожен вихідний запит використовує ефемерний порт.
• VPN-концентратори — WireGuard та IPsec IKE обидва працюють через UDP.

Якщо ви запускаєте щось із цього на масштабі — або керуєте фермою мобільних проксі — перевірте свій sockstat сьогодні. Можливо, ви ближче до обриву, ніж думаєте.

Підсумок

Ми реалізували SOCKS5 UDP ASSOCIATE коректно — відповідно до RFC, протестували, задеплоїли. І він спричинив системний збій, якого наш стандартний моніторинг не побачив.

Висновок, який ми тепер вважаємо жорстким правилом: будь-яка фіча, що виділяє ресурси на рівні ядра — порти, файлові дескриптори, conntrack-записи — потребує явного управління життєвим циклом і бюджетування ресурсів з першого дня. Не як фікс після першого падіння.

Порти — як кисень. Не помічаєш, поки не закінчаться.

---

Це реальний продакшн-інцидент від iProxy.online. Ми будуємо інфраструктуру мобільних проксі, що перетворює Android-телефони на SOCKS5 та HTTP проксі-сервери, працюючи у 100+ країнах і 600+ операторів. Повна підтримка UDP ASSOCIATE включена — тепер із правильним управлінням ресурсами. Спробувати iProxy →