Високонавантажені корпоративні шлюзи VPN, проксі-сервери вихідного трафіку та концентратори трансляції мережевих адрес джерела (SNAT) щомиті обслуговують десятки тисяч паралельних тунельних сесій. Коли запити користувачів прямують через захищений шлюз до зовнішніх хмарних API, мікросервісів та публічних веб-серверів, система повинна створювати вихідні з'єднання TCP від імені підключених клієнтських пристроїв.

В умовах щільного трафіку мережеві інженери нерідко зіштовхуються з раптовим збоєм: системні виклики connect() для вихідних з'єднань раптово завершуються помилкою EADDRNOTAVAIL (код помилки 99: «Cannot assign requested address»). Водночас на вузлі залишаються вільними десятки гігабайтів оперативної пам'яті, а навантаження на процесорні ядра далеке від критичного.

Причина цієї проблеми криється в класичній моделі сокетів Берклі: передчасному виділенні динамічного (ефемерного) порту джерела ще до моменту з'ясування адреси призначення. Для усунення цього вузького місця до ядра Linux було додано опцію сокета IP_BIND_ADDRESS_NO_PORT. Відкладаючи вибір локального порту до моменту безпосереднього встановлення зв'язку, сучасні шлюзи VPN повністю ліквідують дефіцит портів та масштабують кількість вихідних сесій у сотні разів на одній IP-адресі.

Порівняння традиційного bind() та механізму IP_BIND_ADDRESS_NO_PORT:

Традиційні сокети (Передчасне виділення порту):
Створення сокета ──> bind(Source_IP, port = 0)
                           │
                           ▼ (Ядро миттєво резервує вільний порт, наприклад 42100)
                     Фіксується груповий шаблон: [Source_IP : 42100 : * : *]
                           │
                           ▼
                     connect(Dest_IP_A : 443)
                     Результат: Порт 42100 ЗАБЛОКОВАНО глобально для Source_IP.
                     (Повне вичерпання пулу настає вже після ~28 232 з'єднань!)

Оптимізовані сокети з IP_BIND_ADDRESS_NO_PORT:
Створення сокета ──> setsockopt(IP_BIND_ADDRESS_NO_PORT) ──> bind(Source_IP, port = 0)
                                                                  │
                                                                  ▼
                                                     Зберігається лише Source_IP.
                                                     ВИДІЛЕННЯ ПОРТУ ВІДКЛАДЕНО!
                                                                  │
                                                                  ▼
                                                     connect(Dest_IP_A : 443)
                                                     Ядро зіставляє повний 4-кортеж:
                                                     [Source_IP : 42100 -> Dest_IP_A : 443]
                                                     Порт 42100 залишається ДОСТУПНИМ для Dest_IP_B!

Природа вичерпання ефемерних портів

Відповідно до базової специфікації протоколу TCP (RFC 793), встановлене мережеве з'єднання однозначно ідентифікується в ядрі через 4-кортеж (4-tuple):

$$\text{Сесія} = (\text{IP джерела}, \text{Порт джерела}, \text{IP призначення}, \text{Порт призначення})$$

Доки хоча б один із цих чотирьох компонентів відрізняється, мережевий стек ядра Linux може надійно розрізняти пакети та підтримувати мільйони паралельних потоків без виникнення колізій.

Проте коли шлюз або вихідний проксі має прив'язати сокет до конкретної локальної адреси інтерфейсу (наприклад, для передачі даних через призначений пул публічних адрес або віртуальну IP-адресу VPN), розробники традиційно застосовували таку конструкцію:

// Класична прив'язка до вихідного інтерфейсу
struct sockaddr_in src_addr;
src_addr.sin_family = AF_INET;
src_addr.sin_addr.s_addr = inet_addr("198.51.100.10");
src_addr.sin_port = 0; // Запит динамічного порту від ядра ОС

bind(sockfd, (struct sockaddr *)&src_addr, sizeof(src_addr));
connect(sockfd, (struct sockaddr *)&dst_addr, sizeof(dst_addr));

Структурний недолік традиційного виклику bind()

Коли функція bind() виконується з параметром port = 0, ядро Linux негайно звертається до таблиці локальних динамічних портів (net.ipv4.ip_local_port_range, яка за замовчуванням містить діапазон 32768 60999 і надає лише 28 232 порти).

Оскільки системний виклик connect() ще не відбувся, ядро не має жодної інформації про IP-адресу та порт призначення. Щоб запобігти внутрішньому конфлікту адрес, ядро змушене зарезервувати виділений порт для абсолютно всіх можливих адресатів з цієї IP-адреси джерела:

$$(\text{IP джерела}, \text{Виділений порт}, *, *)$$

Як наслідок, щойно шлюз відкриває 28 232 одночасних з'єднання з цієї адреси, діапазон портів повністю вичерпується. Будь-який наступний виклик bind() негайно завершується помилкою EADDRNOTAVAIL, навіть якщо новий запит прямує до абсолютно іншого зовнішнього сервера.

Механізм IP_BIND_ADDRESS_NO_PORT в ядрі Linux

Для усунення цієї неефективності в ядрі Linux версії 4.2 з'явилася опція сокета IP_BIND_ADDRESS_NO_PORT (автор реалізації — Ерік Дюмазе), разом із відповідною опцією IPV6_BIND_ADDRESS_NO_PORT для протоколу IPv6:

#include <netinet/in.h>

int val = 1;
setsockopt(sockfd, IPPROTO_IP, IP_BIND_ADDRESS_NO_PORT, &val, sizeof(val));

Логіка відкладеного розподілу в net/ipv4/af_inet.c

Коли ця опція встановлюється до виклику bind(), процес ініціалізації сокета всередині ядра змінюється:

  1. Прив'язка адреси без зайняття порту: У функції inet_bind() ядро перевіряє коректність IP-адреси джерела та заповнює службові поля inet->inet_rcv_saddr і inet->inet_saddr. Далі встановлюється внутрішній прапорець:
    inet_sk(sk)->bind_address_no_port = 1;
    Функція inet_bind() завершується без виконання пошуку порту в inet_csk_get_port(). Порт сокета залишається рівним 0.
  2. Оцінка повного кортежу під час connect: Коли програма ініціює виклик connect(), керування переходить до tcp_v4_connect(). На цьому кроці ядро володіє всією необхідною інформацією: IP джерела, IP призначення та порт призначення.
  3. Оптимізований пошук у таблиці ehash: Ядро викликає inet_hash_connect(), яка перевіряє таблицю активних з'єднань (tcp_hashinfo.ehash). Алгоритм не вимагає унікальності порту для всієї системи, а лише перевіряє відсутність дубліката повного 4-кортежу.
Порівняння ємності на одну вихідну IP-адресу:

Звичайні сокети (Порт резервується під час bind):
Максимальна кількість з'єднань = Розмір пулу портів (~28 232 - 64 000 загалом)

Сокети з опцією IP_BIND_ADDRESS_NO_PORT:
Максимальна кількість з'єднань = (Розмір пулу портів) × (Кількість унікальних серверів)
Приклад: 64 000 портів × 500 цільових серверів = 32 000 000 одночасних з'єднань!

Практична реалізація в коді

Сучасні високопродуктивні проксі та шлюзи VPN застосовують відкладене виділення портів у різних середовищах розробки.

1. Низькорівнева реалізація мовою C

#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <stdio.h>

int create_optimized_egress_socket(const char *src_ip, const char *dst_ip, int dst_port) {
    int fd = socket(AF_INET, SOCK_STREAM, 0);
    if (fd < 0) return -1;

    // Увімкнення відкладеного виділення портів
    int optval = 1;
    if (setsockopt(fd, IPPROTO_IP, IP_BIND_ADDRESS_NO_PORT, &optval, sizeof(optval)) < 0) {
        perror("Помилка setsockopt IP_BIND_ADDRESS_NO_PORT");
        close(fd);
        return -1;
    }

    // Прив'язка до вибраної вихідної IP-адреси
    struct sockaddr_in local_addr = {0};
    local_addr.sin_family = AF_INET;
    local_addr.sin_addr.s_addr = inet_addr(src_ip);
    local_addr.sin_port = 0; // Відкласти вибір порту

    if (bind(fd, (struct sockaddr *)&local_addr, sizeof(local_addr)) < 0) {
        perror("Помилка bind");
        close(fd);
        return -1;
    }

    // З'єднання з віддаленим сервером (порт виділяється тут)
    struct sockaddr_in remote_addr = {0};
    remote_addr.sin_family = AF_INET;
    remote_addr.sin_addr.s_addr = inet_addr(dst_ip);
    remote_addr.sin_port = htons(dst_port);

    if (connect(fd, (struct sockaddr *)&remote_addr, sizeof(remote_addr)) < 0) {
        perror("Помилка connect");
        close(fd);
        return -1;
    }

    return fd;
}

2. Реалізація в Go через хук Control у net.Dialer

У середовищі Go інженери налаштовують параметри дескриптора за допомогою хука Control:

package main

import (
	"context"
	"net"
	"syscall"
	"golang.org/x/sys/unix"
)

func createOptimizedDialer(egressIP string) *net.Dialer {
	return &net.Dialer{
		LocalAddr: &net.TCPAddr{
			IP:   net.ParseIP(egressIP),
			Port: 0,
		},
		Control: func(network, address string, c syscall.RawConn) error {
			var controlErr error
			err := c.Control(func(fd uintptr) {
				// Встановлення IP_BIND_ADDRESS_NO_PORT під Linux
				controlErr = unix.SetsockoptInt(int(fd), unix.IPPROTO_IP, unix.IP_BIND_ADDRESS_NO_PORT, 1)
			})
			if err != nil {
				return err
			}
			return controlErr
		},
	}
}

3. Оптимізація параметрів ядра для динамічних портів

Разом із застосуванням опції сокета необхідно розширити пул портів у файлі /etc/sysctl.d/99-networking.conf:

# Розширення пулу локальних портів до максимального ліміту
net.ipv4.ip_local_port_range = 1024 65535

# Безпечне повторне використання сокетів у стані TIME_WAIT (RFC 6191)
net.ipv4.tcp_tw_reuse = 2

Застосування змін у діючій системі:

sysctl -w net.ipv4.ip_local_port_range = 1024 65535
sysctl -w net.ipv4.tcp_tw_reuse = 2

Діагностика та моніторинг насичення портів

Інженери з експлуатації можуть у режимі реального часу відстежувати стан сокетів та виявляти перевантаження за допомогою штатних утиліт Linux:

# Перевірка глобальної статистики сокетів у ядрі
cat /proc/net/sockstat

# Підрахунок вихідних з'єднань із розподілом за портами
ss -tan 'sport >= :1024 and sport <= :65535' | awk '{print $4}' | cut -d: -f2 | sort | uniq -c | sort -nr | head -n 10

# Моніторинг системних помилок виділення з'єднань
netstat -s | grep -i "failed"

Якщо фіксуються помилки під час виклику connect(), а оперативна пам'ять залишається вільною, причиною майже напевно є застарілий підхід до прив'язки без відкладеного вибору порту.

Реалізація у протоколі RiceGuard від VPNRice

Архітектура платформи VPNRice та базовий механізм RiceGuard побудовані з урахуванням високих вимог до надійності мільйонів одночасних сесій на глобальних Anycast-вузлах:

  1. Штатне відкладене виділення портів: Усі процеси маршрутизації та вихідні проксі в Anycast-кластерах RiceGuard примусово використовують IP_BIND_ADDRESS_NO_PORT та IPV6_BIND_ADDRESS_NO_PORT. Один серверний вузол успішно обслуговує понад 500 000 одночасних сесій без ризику вичерпання портів.
  2. Рандомізація за стандартом RFC 6056: Відкладене зв'язування поєднується з криптографічною рандомізацією номерів портів джерела, що унеможливлює атаки з підробки пакетів або отруєння кешу DNS.
  3. Ліквідація блокувань у ядрі (Lock Contention): Перенесення вибору порту на фазу connect() виключає блокування глобальної хеш-таблиці сокетів, забезпечуючи лінійне зростання продуктивності багатоядерних процесорів.

Впровадження IP_BIND_ADDRESS_NO_PORT є ключовим інженерним стандартом для масштабованих шлюзів, який забезпечує стабільну роботу мережі та максимальну віддачу від апаратного забезпечення.