Настройка 3proxy на KVM VPS: собственный приватный прокси-сервер, ротация пула IPv6 /64 и авторизация

04.10.202634 мин чтения

Tropic

3proxy на vps ipv6 ротация
настройка 3proxy на сервере
собственный прокси сервер vps
ipv6 прокси 3proxy
ротация ip на vps

Краткий вывод: Для отказоустойчивого развертывания 3proxy на KVM VPS с динамической ротацией адресов из пула IPv6 /64 необходим инстанс минимум с 1 vCPU (%st = 0.0%), 1 ГБ RAM, 15 ГБ серверного NVMe и аплинком 1 Гбит/с с активным алгоритмом TCP BBR. Архитектура трансляции реализуется по протоколам SOCKS5 и HTTP(S) CONNECT через маршрутизацию всей /64 подсети на loopback-интерфейс (ip -6 route add local <prefix>::/64 dev lo) в связке с параметром ядра net.ipv6.ip_nonlocal_bind=1. Данный подход исключает деградацию сетевого стека ядра миллионом интерфейсных алиасов, удерживает network latency p99 ниже 15 мс и обеспечивает гранулярную аутентификацию по ACL с изоляцией сессий в лимитах cgroups v2.

Содержание

Аппаратные и сетевые требования к VPS под высоконагруженный прокси
Сборка 3proxy из исходного кода и тюнинг сетевого стека Linux
Конфигурация 3proxy.cfg: порты, списки доступа (ACL) и авторизация по логину
Автоматическая генерация и ротация пула адресов из подсети IPv6 /64
Настройка демона systemd, ротация логов и защита от сканеров портов
Тестирование пропускной способности, утечек DNS и аудит безопасности
Часто задаваемые вопросы (FAQ)

Аппаратные и сетевые требования к VPS под высоконагруженный прокси

Организация отказоустойчивого шлюза для 3proxy на VPS с IPv6-ротацией требует точной калибровки параметров ядра Linux, характеристик гипервизора и топологии маршрутизации префикса /64. Ошибочный сайзинг ресурсов или развертывание сервиса на виртуализации с агрессивным оверселлингом приводят к лавинообразному росту задержек (p99 latency), потере пакетов на фазе TCP-хэндшейка и исчерпанию дескрипторов сокетов уже при 3 000–5 000 параллельных сессий.

1. Архитектура виртуализации и влияние фактора CPU Steal Time (%st)

Для задач массовой проксификации допустима исключительно чистая аппаратная виртуализация KVM. Контейнерные среды (OpenVZ, Virtuozzo, базовый LXC без вложенных прав) изолируют гостевую систему от прямого управления подсистемой ядра: в них заблокирован низкоуровневый тюнинг сетевых пространств имен (network namespaces), системные вызовы setsockopt() для принудительного управления биндингом адресов (IPV6_UNICAST_HOPS, IPV6_TCLASS), а также ограничено конфигурирование локального демона Neighbor Discovery Protocol (NDP).

Критический фактор стабильности пула соединений — показатель CPU Steal Time (%st). При интенсивной обработке потоков каждый входящий клиентский запрос инициирует создание двух взаимосвязанных сокетов: 1. Ingress: клиент $\rightarrow$ порт 3proxy (IPv4 или IPv6). 2. Egress: 3proxy $\rightarrow$ целевой хост с рандомизированного IPv6 из пула /64.

Планировщик ядра CFS (Completely Fair Scheduler) при переключении контекста между тысячами легковесных потоков чувствителен к квантам процессорного времени. Если физический хост перегружен «шумными соседями» и значение %st превышает 1.5–2.0%, задержка обработки системного вызова epoll_wait() и пересылки буферов возрастает в десятки раз: метрика TCP Handshake Latency p99 деградирует с 12–15 мс до 350–500 мс. Это приводит к массовым таймаутам на стороне клиентского софта (парсеров, скреперов, автоматизированных систем).

Инфраструктурный стандарт облачной платформы tropic.host гарантирует честную KVM-виртуализацию с нулевым оверподписным коэффициентом vCPU на базе высокочастотных процессоров AMD EPYC и Ryzen 9 (%st = 0.0%). Полная изоляция процессорных циклов исключает дропы пакетов на уровне программных прерываний сетевой карты (SoftIRQ / ksoftirqd).

2. Топология подсети /64 IPv6 и локальная маршрутизация без нагрузки на NDP

Стандартный блок /64 предоставляет $2^{64} = 18\,446\,744\,073\,709\,551\,616$ уникальных адресов. При реализации ротации ключевая инженерная задача — обеспечить отправку исходящих пакетов с любого псевдослучайного IP данного диапазона без деградации сетевого интерфейса.

Ошибка физического назначения адресов

Попытка назначить тысячи IPv6-адресов на физический интерфейс (eth0 / ens3) через вызовы ip -6 addr add 2a01:... dev eth0 является архитектурной ошибкой. При превышении порога в 2 000–4 000 адресов: * Ядро Linux тратит неприемлемо много циклов CPU на обход хэш-таблицы интерфейса при каждом вызове bind(). * Входящие запросы Neighbor Solicitation (NS) от вышестоящего шлюза инициируют шторм широковещательных пакетов, приводящий к переполнению таблицы соседей (Neighbour Table Overflow).

Корректная реализация: Local AnyIP маршрутизация

Вся подсеть /64 маршрутизируется в локальный стек хоста через loopback-интерфейс (lo) с включением механизма ip_nonlocal_bind. Это позволяет демону 3proxy мгновенно привязываться к любому из $2^{64}$ адресов без их явного добавления в операционную систему:

# 1. Привязка всего диапазона /64 к loopback в качестве локального маршрута
sudo ip -6 route add local 2a01:4f8:xxxx:yyyy::/64 dev lo

# 2. Активация связывания сокетов с нелокальными IPv6-адресами на уровне ядра
sudo sysctl -w net.ipv6.ip_nonlocal_bind=1

# 3. Предотвращение исчерпания буфера таблицы соседей (NDP gc_thresh)
sudo sysctl -w net.ipv6.neigh.default.gc_thresh1=4096
sudo sysctl -w net.ipv6.neigh.default.gc_thresh2=8192
sudo sysctl -w net.ipv6.neigh.default.gc_thresh3=16384

На виртуальных серверах tropic.host публичные блоки /64 подаются через статическую routed-схему (routed subnet) непосредственно на link-local шлюз виртуальной машины. Это полностью исключает генерацию паразитного трафика Neighbor Discovery между виртуальным сервером и пограничным маршрутизатором ЦОД.

3. Профиль потребления оперативной памяти C-демоном 3proxy

3proxy написан на чистом ANSI C и оптимизирован под многопоточную модель обработки соединений (threads). В отличие от тяжеловесных решений на Python, Node.js или Go, демон не использует сборщик мусора (GC) и не создает многомегабайтный оверхед на среду исполнения.

Структура расхода памяти на одно TCP-соединение:

Пользовательский стек потока (pthread_attr_setstacksize): По умолчанию в Linux стек потока равен 8 МБ (ulimit -s 8192), что при 5 000 потоков мгновенно вызовет Out Of Memory. В 3proxy размер стека переопределяется внутренней директивой stacksize 65536 (64 КБ), чего с запасом хватает для стека сетевых функций C-библиотек.
Внутренние кольцевые буферы 3proxy: Буфер пересылки данных между сокетами конфигурируется директивой bufsize (по умолчанию 32 768 байт).
Сетевые структуры ядра Linux: На каждый установленный сокет ядро выделяет дескриптор struct sock и буферы очередей приема/передачи sk_buff. При минимальном базовом тюнинге (tcp_rmem, tcp_wmem) сокет удерживает от 8 до 32 КБ оперативной памяти ядра (Slab / dentry cache).

Формула расчета необходимой RAM под целевой объем коннектов: $$RAM_{min} = N_{conns} \times (Stack_{thread} + Buffer_{3proxy} + sk_buff_{rx} + sk_buff_{tx}) + RAM_{OS}$$

Для пула из 10 000 одновременных активных TCP-сессий: $$10\,000 \times (64\,\text{КБ} + 32\,\text{КБ} + 16\,\text{КБ} + 16\,\text{КБ}) \approx 1.22\,\text{ГБ RAM}$$ С учетом буферов операционной системы, страниц кэша и дескрипторов ввода-вывода минимальный безопасный объем физической памяти для данного профиля нагрузки составляет 4 ГБ.

4. Матрица сайзинга аппаратных ресурсов под профили нагрузки

В таблице представлены валидированные спецификации оборудования и лимитов сетевого стека для стабильной работы 3proxy с пулом IPv6-ротации под разную интенсивность параллельных запросов.

Параметр / Метрика	Starter-профиль (до 1 500 сессий)	Production-профиль (до 10 000 сессий)	Highload Enterprise (50 000+ сессий)
Вычислительная мощность (vCPU)	2 vCPU (KVM, EPYC / Xeon)	4 vCPU (KVM, High-Freq EPYC / Ryzen)	8–16 vCPU (Выделенные ядра KVM)
Порог CPU Steal Time (`%st`)	$\le 0.1\%$	Строго 0.0%	Строго 0.0%
Оперативная память (RAM)	2 ГБ ECC DDR4/DDR5	4–8 ГБ ECC DDR4/DDR5	16–32 ГБ ECC DDR5
Память ядра под сокеты (`tcp_mem`)	49152 65536 98304 (4K стр.)	98304 131072 196608 (4K стр.)	393216 524288 786432 (4K стр.)
Сетевой аплинк (Bandwidth)	1 Гбит/с Shared	1–2.5 Гбит/с Dedicated	10 Гбит/с Dedicated Full-Duplex
Пропускная способность IOPS (NVMe)	> 15 000 IOPS (4K QD1)	> 50 000 IOPS (PCIe 4.0 NVMe)	> 100 000 IOPS (Enterprise NVMe)
Дисковая задержка p99 (`fdatasync`)	$\le 3.5$ мс	$\le 0.8$ мс	$\le 0.3$ мс
Лимит дескрипторов (`file-max`)	262 144	1 048 576	4 194 304
Максимум Conntrack (`nf_conntrack`)	131 072	524 288	Отключен (`NOTRACK` в raw-таблице)
Типовой тариф на tropic.host	KVM-NVMe-Starter (Франкфурт/Амстердам)	KVM-NVMe-Pro (1–10 Gbps BBR)	KVM-Dedicated-Core (Enterprise NVMe)

5. Тюнинг сетевого стека Linux под высоконагруженный проксинг (`sysctl.conf`)

Для предотвращения зависания портов в состоянии TIME_WAIT, исключения дропов SYN-очереди и раскрытия пропускной способности канала в конфигурацию /etc/sysctl.d/99-3proxy-highload.conf вносятся следующие параметры:

# Максимальное количество открытых файловых дескрипторов в системе
fs.file-max = 2097152

# Глубина очереди входящих соединений на сокетах (backlog)
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65536

# Диапазон локальных эфемерных портов для исходящих исходящих TCP-соединений
net.ipv4.ip_local_port_range = 1024 65535

# Быстрое переиспользование TIME_WAIT сокетов для исходящих коннектов
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# Защита от SYN-флуда и емкость полуоткрытых соединений
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 65536
net.ipv4.tcp_synack_retries = 2

# Алгоритм контроля перегрузки TCP BBR и дисциплина очереди FQ (Fair Queueing)
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# Буферы приема и отправки TCP (min / default / max в байтах)
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Маршрутизация и привязка локальных подсетей IPv6
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.ip_nonlocal_bind = 1

# Лимиты таблицы Neighbor Discovery (предотвращение сброса маршрутов к шлюзу)
net.ipv6.neigh.default.gc_thresh1 = 4096
net.ipv6.neigh.default.gc_thresh2 = 8192
net.ipv6.neigh.default.gc_thresh3 = 16384
net.ipv6.neigh.default.gc_stale_time = 86400

Применение параметров без перезагрузки ноды:

sudo sysctl --system

Активация алгоритма TCP BBR совместно с аппаратным аплинком 1–10 Гбит/с на серверах tropic.host минимизирует паразитные задержки повторной передачи (TCP Retransmission Rate) на длинных трансконтинентальных маршрутах, удерживая джиттер в пределах 1.5–3.0 мс при трансфере данных через пограничные стыки AMS-IX и DE-CIX.

6. Изоляция демона и управление лимитами через systemd (cgroups v2)

Запуск 3proxy напрямую без изоляции дескрипторов приведет к падению процесса при достижении стандартного ограничения nofile = 1024. Для обеспечения стабильности создается drop-in конфигурация systemd, определяющая границы потребления памяти и дескрипторов:

Файл /etc/systemd/system/3proxy.service.d/override.conf:

[Service]
# Снятие ограничений на количество открытых файлов и сокетов
LimitNOFILE=1048576
LimitNPROC=524288
LimitMEMLOCK=infinity

# Защита от OOM Killer: приоритет сохранения процесса при нехватке памяти
OOMScoreAdjust=-900

# Ограничения контроллеров cgroups v2
MemoryAccounting=yes
MemoryHigh=3.5G
MemoryMax=3.8G
TasksAccounting=yes
TasksMax=65536

# Принудительное выделение CPU-квот
CPUAccounting=yes
CPUWeight=1000

После редактирования конфигурации выполняется перезагрузка демона systemd и службы:

sudo systemctl daemon-reload
sudo systemctl restart 3proxy

7. Требования к дисковой подсистеме NVMe для ротации и логгирования

При интенсивной ротации IP-адресов с частотой в десятки тысяч HTTP-запросов в секунду (RPS) дисковая подсистема испытывает непрерывную нагрузку на запись транзакционных логов (access.log).

Если инстанс развернут на бюджетном SATA SSD или сетевом диске (Ceph, NFS) со временем отклика 4K случайной записи > 10–15 мс, буферы вывода 3proxy мгновенно заполняются. Потоки блокируются на системном вызове write() или fdatasync(), переводя рабочие нити в состояние непрерываемого сна (Uninterruptible Sleep, D-state). В результате сетевой стек прекращает забирать пакеты из очередей sk_buff, и прокси перестает отвечать.

Использование серверных NVMe-накопителей стандарта PCIe 4.0 на площадках tropic.host с производительностью свыше 50 000 IOPS на операциях 4K QD1 и аппаратным термоконтролем гарантирует субмиллисекундный сброс дисковых страниц (p99 latency записи < 0.8 мс). Это исключает блокировку сокетов 3proxy даже при ведении расширенного аудита входящих соединений с фиксацией User-Agent, таймингов и исходящих IPv6-адресов.

Сборка 3proxy из исходного кода и тюнинг сетевого стека Linux

Стандартные бинарные пакеты 3proxy, поставляемые в upstream-репозиториях Debian и Ubuntu, скомпилированы с усредненными параметрами: внутренний буфер ввода-вывода жестко ограничен (BUFSIZE = 4096 или 8192 байт), отключены процессорные векторные инструкции, а распределение динамической памяти возложено на стандартный ptmalloc3 из состава glibc. При интенсивной обработке тысяч конкурентных сетевых потоков ptmalloc создает узкое горлышко из-за взаимных блокировок на мьютексах арен памяти (arena locks).

Для высоконагруженной архитектуры 3proxy на VPS с ротацией IPv6 требуется компиляция демона из исходного кода с флагами глубокой оптимизации компилятора GCC, переопределением размеров сетевых структур и последующим точечным тюнингом сетевой подсистемы ядра через интерфейс sysctl.

                Архитектура обработки пакетов при ротации IPv6

 ┌──────────────────────┐         ┌─────────────────────────────────────────┐
 │ Входящий TCP-запрос  │         │   Ядро Linux (Network Subsystem)        │
 │  (Клиент -> IPv4)    ├────────►│  - Ring Buffer NIC (NAPI polling)       │
 └──────────────────────┘         │  - TCP Backlog: somaxconn (65535)       │
                                  │  - SYN Queue: tcp_max_syn_backlog       │
                                  └───────────────────┬─────────────────────┘
                                                      │ epoll_wait()
                                                      ▼
 ┌──────────────────────────────────────────────────────────────────────────┐
 │  3proxy (Сборка: -O3, jemalloc, увеличенный BUFFSIZE = 65536)            │
 │  - Worker Threads (pthreads, non-blocking I/O)                           │
 │  - Выбор случайного исходящего IPv6 из пула /64 подсети                  │
 │  - setsockopt(IPV6_V6ONLY) + bind() через IP_FREEBIND / nonlocal_bind    │
 └────────────────────────────────────────────────────┬─────────────────────┘
                                                      │ connect()
                                                      ▼
 ┌──────────────────────────────────────────────────────────────────────────┐
 │  Исходящий стек ядра Linux                                               │
 │  - NDP Table (gc_thresh3 = 65536, защита от "Neighbour table overflow")  │
 │  - Congestion Control: TCP BBR + FQ qdisc                                │
 │  - Прямой роутинг без conntrack (таблица raw: NOTRACK)                  │
 └────────────────────────────────────────────────────┬─────────────────────┘
                                                      │
                                                      ▼
                                       ┌────────────────────────────┐
                                       │ Целевой ресурс (IPv6 Web)  │
                                       └────────────────────────────┘

Подготовка сборочного окружения и оптимизация исходного кода

Перед сборкой устанавливается инструментарий компиляции, заголовочные файлы ядра и OpenSSL для поддержки шифрования входящих соединений. Чтобы исключить деградацию производительности аллокатора при частых вызовах malloc()/free() внутри рабочих потоков, к сборке подключается высокопроизводительный аллокатор jemalloc:

sudo apt-get update && sudo apt-get install -y --no-install-recommends \
    build-essential \
    git \
    libssl-dev \
    libjemalloc-dev \
    libjemalloc2 \
    ca-certificates

Клонирование стабильной ветки исходного кода из официального репозитория:

cd /usr/local/src
sudo git clone https://github.com/3proxy/3proxy.git
cd 3proxy
sudo git checkout tags/0.9.4

В базовой конфигурации src/proxy.h размеры внутренних буферов не рассчитаны на передачу объемных полезных нагрузок через сокеты без дробления на мелкие системные вызовы read() и write(). Каждое лишнее переключение контекста между пространством пользователя и ядром (user/kernel space context switch) транслируется в потери циклов CPU.

Через потоковый редактор sed размер буфера BUFFSIZE увеличивается до 64 КБ (65536 байт), что кратно размеру стандартного окна TCP и снижает количество системных вызовов ввода-вывода в 4–8 раз:

# Увеличение базового буфера сокетов с 4096/8192 до 65536 байт
sudo sed -i 's/#define BUFFSIZE 8192/#define BUFFSIZE 65536/g' src/structures.h 2>/dev/null || true
sudo sed -i 's/#define BUFFSIZE 4096/#define BUFFSIZE 65536/g' src/structures.h 2>/dev/null || true
sudo sed -i 's/#define BUFSIZE 8192/#define BUFSIZE 65536/g' src/structures.h 2>/dev/null || true
sudo sed -i 's/#define BUFSIZE 4096/#define BUFSIZE 65536/g' src/structures.h 2>/dev/null || true

Далее модифицируется файл сборки Makefile.Linux. В него внедряются директивы агрессивной оптимизации GCC и линковка с библиотекой jemalloc:

# Замена стандартных CFLAGS в Makefile.Linux
sudo sed -i 's/CFLAGS = -Wall -g -O2 -c -pthread/CFLAGS = -Wall -O3 -march=native -pipe -fomit-frame-pointer -D_GNU_SOURCE -DWITH_STD_MALLOC -DWITH_PTHREADS -c -pthread/g' Makefile.Linux
sudo sed -i 's/LIBS = -lpthread/LIBS = -lpthread -ljemalloc/g' Makefile.Linux

Назначение используемых флагов оптимизации: * -O3: включает агрессивную векторизацию циклов, инлайнинг критических процедур и развертывание путей исполнения; * -march=native: инструктирует GCC задействовать полный набор инструкций доступного процессора хоста (AVX2, BMI2, FMA); * -pipe: ускоряет компиляцию за счет передачи промежуточных данных через конвейеры памяти вместо временных файлов; * -fomit-frame-pointer: освобождает регистр указателя фрейма (%ebp / %rbp), предоставляя компилятору дополнительный регистр общего назначения; * -DWITH_STD_MALLOC: отключает внутренний примитивный аллокатор 3proxy в пользу системного вызова, который перехватывается подлинкованным jemalloc.

Компиляция и установка исполняемых файлов:

sudo make -f Makefile.Linux
sudo make -f Makefile.Linux install

Проверяется корректность линковки бинарника с jemalloc:

ldd /usr/local/bin/3proxy | grep jemalloc
# Ожидаемый вывод: libjemalloc.so.2 => /lib/x86_64-linux-gnu/libjemalloc.so.2 (0x...)

Создаются системный пользователь и базовая иерархия каталогов с изоляцией прав:

sudo id -u proxy &>/dev/null || sudo useradd -r -s /usr/sbin/nologin -d /etc/3proxy -U proxy
sudo mkdir -p /etc/3proxy/conf.d /var/log/3proxy /var/run/3proxy
sudo chown -R proxy:proxy /etc/3proxy /var/log/3proxy /var/run/3proxy
sudo chmod 750 /etc/3proxy /var/log/3proxy /var/run/3proxy

Низкоуровневый тюнинг ядра Linux для ротации IPv6 (sysctl)

При динамической ротации миллионов исходящих IPv6-адресов стандартная конфигурация сетевого стека Linux сталкивается с тремя фатальными проблемами: 1. Переполнение таблицы соседства NDP (Neighbor Discovery Protocol): ядро пытается сохранить MAC-адреса и состояния маршрутов для каждого сгенерированного IPv6. По умолчанию размер таблицы ограничен значением gc_thresh3 = 4096, после чего ядро отбрасывает пакеты с ошибкой Neighbour table overflow. 2. Невозможность привязки сокетов к неназначенным адресам: вызов bind() завершается ошибкой EADDRNOTAVAIL, если конкретный IPv6 не добавлен вручную на сетевой интерфейс. 3. Истощение пула дескрипторов и застревание сокетов в TIME_WAIT: блокирует открытие новых соединений к внешним серверам.

Создается конфигурационный файл /etc/sysctl.d/99-3proxy-networking.conf, полностью устраняющий узкие места ядра:

# ==============================================================================
# Файловая система и системные дескрипторы
# ==============================================================================
fs.file-max = 2097152
fs.nr_open = 2097152

# ==============================================================================
# Нелокальная привязка сокетов (Non-local Bind)
# Позволяет 3proxy выполнять bind() на любой IPv6 из назначенной /64 подсети
# без предварительного ручного добавления IP на интерфейс eth0
# ==============================================================================
net.ipv4.ip_nonlocal_bind = 1
net.ipv6.ip_nonlocal_bind = 1

# ==============================================================================
# Маршрутизация и Neighbor Discovery Protocol (NDP) для ротации IPv6
# ==============================================================================
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.all.proxy_ndp = 1
net.ipv6.conf.default.proxy_ndp = 1

# Увеличение порогов сборщика мусора (GC) таблицы соседства ARP/NDP
# gc_thresh1: минимальное количество записей, до которого GC не запускается
# gc_thresh2: порог, при котором GC начинает фоновую очистку через 5 секунд
# gc_thresh3: жесткий лимит таблицы; превышение вызывает отбрасывание пакетов
net.ipv4.neigh.default.gc_thresh1 = 4096
net.ipv4.neigh.default.gc_thresh2 = 16384
net.ipv4.neigh.default.gc_thresh3 = 65536

net.ipv6.neigh.default.gc_thresh1 = 8192
net.ipv6.neigh.default.gc_thresh2 = 32768
net.ipv6.neigh.default.gc_thresh3 = 65536

# Время удержания устаревших записей в таблице NDP (секунды)
net.ipv6.neigh.default.gc_stale_time = 60

# Максимальный размер таблицы маршрутизации IPv6
net.ipv6.route.max_size = 524288

# ==============================================================================
# Управление жизненным циклом TCP-сокетов и TIME_WAIT
# ==============================================================================
# Диапазон локальных портов для исходящих коннектов
net.ipv4.ip_local_port_range = 1024 65535

# Разрешение повторного использования сокетов в состоянии TIME_WAIT для исходящих TCP
net.ipv4.tcp_tw_reuse = 1

# Время удержания сокета в состоянии FIN-WAIT-2 перед принудительным закрытием
net.ipv4.tcp_fin_timeout = 15

# Максимальное количество сокетов, одновременно находящихся в TIME_WAIT
net.ipv4.tcp_max_tw_buckets = 2000000

# Отключение TCP Slow Start после периода простоя (предотвращает падение скорости)
net.ipv4.tcp_slow_start_after_idle = 0

# ==============================================================================
# Очереди сокетов и сетевых драйверов (Backlog & Rings)
# ==============================================================================
# Максимальная длина очереди сокетов listen() (входящие syn-запросы)
net.core.somaxconn = 65535

# Максимальное число пакетов в очереди сетевого интерфейса до передачи в TCP-стек
net.core.netdev_max_backlog = 65536

# Максимальный размер очереди полуоткрытых соединений (SYN_RECV)
net.ipv4.tcp_max_syn_backlog = 65535

# Защита от SYN Flood атак
net.ipv4.tcp_syncookies = 1

# ==============================================================================
# Буферы приема и передачи (Socket Auto-tuning)
# Значения: min (базовый) default (по умолчанию) max (верхний предел)
# ==============================================================================
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# ==============================================================================
# Алгоритм контроля перегрузки: TCP BBR v1/v2 + Fair Queueing
# ==============================================================================
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

Применение конфигурации ядра без перезагрузки операционной системы:

sudo sysctl --system

Проверка применения критических параметров в подсистеме ядра:

sysctl net.ipv6.neigh.default.gc_thresh3
# Вывод: net.ipv6.neigh.default.gc_thresh3 = 65536

sysctl net.ipv6.ip_nonlocal_bind
# Вывод: net.ipv6.ip_nonlocal_bind = 1

sysctl net.ipv4.tcp_congestion_control
# Вывод: net.ipv4.tcp_congestion_control = bbr

Разгрузка CPU: обход подсистемы Netfilter Conntrack

В процессе эксплуатации 3proxy на VPS ротация IPv6 создает сотни тысяч кратковременных сессий. Если на сервере активен межсетевой экран на базе iptables или nftables, модуль отслеживания соединений ядра (nf_conntrack) пытается зарегистрировать каждую сессию в хеш-таблице conntrack.

Это приводит к двум критическим проблемам: * Ядро исчерпывает лимит nf_conntrack_max, и стек начинает немотивированно сбрасывать входящие TCP SYN пакеты с сообщением nf_conntrack: table full, dropping packet. * Ядро тратит до 35–40% циклов CPU на вычисление хэшей в софт-интерраптах (ksoftirqd), увеличивая задержку обработки пакетов.

Для трафика прокси трансляция сетевых адресов (NAT) не требуется, так как 3proxy самостоятельно терминирует TCP-сессии на уровне сокетов прикладного уровня L7. Для входящего порта прокси (например, TCP 1080 и пула портов 10000-20000) и исходящих префиксов IPv6 модуль conntrack отключается в таблице raw:

# Обход conntrack для входящих подключений клиентов на порт прокси
sudo iptables -t raw -A PREROUTING -p tcp --dport 1080 -j NOTRACK
sudo iptables -t raw -A OUTPUT -p tcp --sport 1080 -j NOTRACK

# Обход conntrack для исходящего трафика IPv6
sudo ip6tables -t raw -A PREROUTING -j NOTRACK
sudo ip6tables -t raw -A OUTPUT -j NOTRACK

Для персистентного сохранения правил после перезагрузки:

sudo apt-get install -y iptables-persistent
sudo netfilter-persistent save

Архитектурные требования к гипервизору: стабильность KVM на tropic.host

Сетевая производительность Linux при обработке сотен тысяч пакетов в секунду (PPS) опирается на механизм NAPI (New API). Сетевой адаптер переходит из режима прерываний в режим поллинга кольцевого буфера (rx ring buffer), обрабатывая кадры пачками. При этом задействуются потоки обслуживания мягких прерываний ядра (ksoftirqd/0, ksoftirqd/1...).

Если виртуальный сервер функционирует в среде с агрессивным оверселлингом CPU (переподпиской физических ядер), гипервизор принудительно приостанавливает выполнение vCPU гостевой ОС. Это фиксируется в метрике CPU Steal Time (%st в утилите top или vmstat 1).

  Качественный хостинг (%st = 0.0%):
  Packet RX ──► [Ring Buffer] ──► ksoftirqd (NAPI) ──► 3proxy epoll (p99 latency < 5 ms)

  Оверселлинг CPU (%st > 3.0%):
  Packet RX ──► [Ring Buffer] ──► [Hypervisor Pause: vCPU Steal] ──► Buffer Overflow (Dropped)
                                                                 └──► p99 latency > 250 ms

Даже кратковременный всплеск %st свыше 2–3% фатален для ротации прокси: 1. Потоки ksoftirqd не успевают вовремя освободить кольцевой буфер сетевой карты (rx ring buffer). Накопитель буфера переполняется, и сетевой драйвер физически отбрасывает фреймы (метрика rx_dropped в выводе ip -s link show eth0). 2. Сокеты переходят в состояние тайм-аута, а задержка доставки пакетов p99 подскакивает с предсказуемых 5–10 мс до катастрофических 300–800 мс. 3. Клиентские приложения получают SocketTimeoutException при попытке ротации адреса.

Инфраструктура виртуализации KVM на платформе tropic.host гарантирует честное выделение вычислительных ресурсов физических процессоров AMD EPYC и Ryzen 9 с показателем CPU Steal Time %st = 0.0%.

В совокупности с симметричными сетевыми аплинками 1–10 Гбит/с, прямым BGP-пирингом в узловых европейских точках обмена трафиком (Франкфурт, Амстердам, Стамбул) и включенным по умолчанию на уровне сетевой фабрики протоколом TCP BBR, платформа исключает деградацию очереди sk_buff. Это позволяет скомпилированному 3proxy стабильно удерживать поток в десятки тысяч сетевых сессий при непрерывной генерации новых IPv6-сокетов.

Конфигурация 3proxy.cfg: порты, списки доступа (ACL) и авторизация по логину

Синтаксический анализатор 3proxy работает по строгому детерминированному принципу линейного интерпретатора: конфигурационный файл /etc/3proxy/3proxy.cfg считывается сверху вниз за один проход. Любая директива, определяющая списки контроля доступа (ACL), модель аутентификации или сетевые параметры, мгновенно перезаписывает текущее состояние внутреннего контекста демона и применяется исключительно к тем экземплярам проксирующих служб (proxy, socks, tcppm), которые объявлены строго ниже нее по коду.

Для исключения взаимного влияния правил между пулами прокси-портов и предотвращения уязвимостей, связанных с непреднамеренным открытием открытых релеев (open relay), боевая конфигурация строится по модульной архитектуре с обязательной изоляцией контекстов через вызов flush.

Эталонный production-конфиг `/etc/3proxy/3proxy.cfg`

Следующий конфигурационный файл ориентирован на высоконагруженную работу в среде Linux x86_64, задействует системный вызов epoll(7), принудительно кэширует DNS-запросы в оперативной памяти и изолирует клиентский трафик от служебных интерфейсов хоста:

# ==============================================================================
# СЕКЦИЯ 1: СИСТЕМНЫЕ ПАРАМЕТРЫ, ПОТОКИ И РЕЖИМ СЛУЖБЫ
# ==============================================================================
daemon
pidfile /var/run/3proxy/3proxy.pid
nserver 1.1.1.1
nserver 8.8.8.8
nserver 2606:4700:4700::1111
nserver 2001:4860:4860::8888

# Кэш DNS-резолвера на 65 536 записей с TTL по умолчанию
nscache 65536
nscache6 65536

# Тонкая настройка сетевых тайм-аутов (в секундах)
# timeouts <STRING_TIMEOUT> <CONNECTION_TIMEOUT> <DATA_TIMEOUT> <AUTH_TIMEOUT> <SUBSEQUENT_DATA_TIMEOUT> <TOTAL_TIMEOUT> <DNS_TIMEOUT> <BIND_TIMEOUT>
timeouts 1 5 30 60 180 1800 15 60

# Ограничение размера стека для потока (в байтах) и максимального числа дескрипторов
stacksize 262144
maxconn 4096

# ==============================================================================
# СЕКЦИЯ 2: ЛОГИРОВАНИЕ И ФОРМАТИРОВАНИЕ МЕТРИК
# ==============================================================================
log /var/log/3proxy/3proxy.log D
logformat "L%Y-%m-%d %H:%M:%S.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T"
archiver gzip /bin/gzip -f %F

# ==============================================================================
# СЕКЦИЯ 3: БАЗОВАЯ ТАБЛИЦА АУТЕНТИФИКАЦИИ
# ==============================================================================
# Сброс глобального контекста перед объявлением учетных записей
flush

# Определение пользователей и паролей (поддерживается plaintext и crypt(3))
# Формат: users <login>:CL:<plaintext_pass> или <login>:CR:<crypt_hash>
users devops_admin:CL:K8x#m9$vL2pQ9_zT proxy_worker_01:CL:W1e!r4#tY7uI0_oP

# ==============================================================================
# СЕКЦИЯ 4: ФИЛЬТРАЦИЯ И ЗАЩИТА ОТ SSRF (ACL МАТРИЦА)
# ==============================================================================
# Включение строгой аутентификации по логину и паролю
auth strong

# 1. Запрет обращений к служебным адресам гипервизора и cloud-init metadata
deny * * 169.254.169.254,fe80::/10 *

# 2. Запрет обращений к loopback и RFC 1918 приватным сетям во избежание SSRF
deny * * 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 *
deny * * ::1/128,fc00::/7 *

# 3. Белый список клиентских IP (опционально; ограничение управляющего доступа)
# allow devops_admin 198.51.100.42 * *
# deny * * * *

# 4. Разрешение доступа аутентифицированным пользователям к внешним ресурсам
allow devops_admin,proxy_worker_01 * * 80,443,1024-65535 HTTP,HTTPS
allow devops_admin,proxy_worker_01 * * * CONNECT

# Запрет всего остального, что не подошло под правила
deny * * * *

# ==============================================================================
# СЕКЦИЯ 5: ПУЛ ПОРТОВ И МАРШРУТИЗАЦИЯ ВЫХОДНЫХ IPV6 (EGRESS BINDING)
# ==============================================================================
# Экземпляр 1: Вход на статическом IPv4, выход через выделенный IPv6-адрес №1
# Синтаксис: proxy -n -a -p<LISTEN_PORT> -i<LISTEN_IP> -e<EGRESS_IP>
proxy -n -a -p10001 -i192.0.2.15 -e2a01:4f8:1c1c:45a1::0001

# Экземпляр 2: Выход через адрес №2
flush
auth strong
allow devops_admin,proxy_worker_01
proxy -n -a -p10002 -i192.0.2.15 -e2a01:4f8:1c1c:45a1::0002

# Экземпляр 3: Выход через адрес №3
flush
auth strong
allow devops_admin,proxy_worker_01
proxy -n -a -p10003 -i192.0.2.15 -e2a01:4f8:1c1c:45a1::0003

# Экземпляр SOCKS5 для протоколов с произвольными портами
flush
auth strong
allow devops_admin,proxy_worker_01
socks -n -a -p10800 -i192.0.2.15 -e2a01:4f8:1c1c:45a1::0001

Архитектурный разбор ключевых директив и системных структур ядра

1. Диспетчеризация резолвинга: `nscache` и `nscache6`

При параллельной ротации десятков тысяч внешних IPv6-адресов наибольшим фактором задержки (p99 latency) становится ожидание ответа от апстрим DNS-серверов. Без использования директивы nscache каждый входящий HTTP CONNECT запрос инициирует блокирующий или асинхронный системный вызов getaddrinfo(3), провоцируя всплеск UDP-пакетов через порт 53.

Значение nscache 65536 размещает в адресном пространстве процесса кольцевой хэш-буфер размером 64 КБ записей. Повторные резолвы доменных имен обрабатываются внутри контекста 3proxy без сброса контекста процессора в режим ядра (context switch) и без занятия локальных сокетов UDP sk_buff. Это сокращает jitter при ротации до стабильных < 2 мс.

2. Тайм-ауты и управление жизненным циклом сокетов: `timeouts`

Значения параметров директивы timeouts напрямую определяют, как быстро демон освобождает файловые дескрипторы при зависших клиентских сессиях:

STRING_TIMEOUT = 1: время ожидания строковых данных протокола (заголовка HTTP-запроса). Отсекает медленные сканеры портов и атаки класса Slowloris.
CONNECTION_TIMEOUT = 5: предел ожидания установки TCP handshake с удаленным целевым узлом (SYN -> SYN-ACK). Если хост недоступен, сокет закрывается немедленно, не дожидаясь стандартных 127 секунд TCP retransmit ядра Linux.
DATA_TIMEOUT = 30: тайм-аут простоя в активном канале передачи данных.
AUTH_TIMEOUT = 60: окно на прохождение аутентификации.

3. Модель аутентификации: `auth strong` vs `auth iponly`

Директива auth устанавливает уровень проверки прав доступа перед вызовом функции accept() для клиентского соединения:

auth none: полная открытость. Использовать исключительно при жесткой фильтрации входящего интерфейса правилами iptables / nftables.
auth iponly: сопоставляет source-IP клиента с записями в секции allow/deny. Метод минимизирует вычислительные затраты CPU, так как исключает необходимость разбора HTTP-заголовка Proxy-Authorization.
auth strong: активирует обязательную проверку credentials по схеме HTTP Basic Authentication либо RFC 1928 (для SOCKS5). 3proxy декодирует Base64 строку и сверяет пару логин/пароль с хэш-таблицей в памяти.

Для обеспечения криптографической безопасности пароли в директиве users рекомендуется хранить не в открытом виде (CL), а в виде стандартных системных хэшей Unix crypt (CR):

# Генерация SHA-512 хэша для директивы CR
openssl passwd -6 -salt $(openssl rand -hex 8) "StrongPassword2026!"

Строка в конфигурационном файле примет вид:

users proxy_worker_01:CR:$6$b8f72a9c1e4d0f5b$ZqR4vW... (хэш)

4. Безопасность инфраструктуры: предотвращение SSRF через ACL

Прокси-сервер, имеющий прямой доступ к локальной сети ноды, представляет собой критический вектор атаки: злоумышленник может использовать открытый порт прокси для сканирования внутренних портов хоста (127.0.0.1:3306, 127.0.0.1:6379) либо облачных метаданных.

Последовательность директив deny в секции 4 блокирует любые попытки проброса соединений в loopback-диапазон (127.0.0.0/8, ::1/128), подсети link-local (169.254.0.0/16, fe80::/10) и частные пространства адресов RFC 1918 / RFC 4193. Синтаксис правила:

deny <USERS> <SOURCE_IPS> <TARGET_IPS> <TARGET_PORTS> <COMMANDS>

Символ * работает как wildcard (любое значение).

Логирование с нулевой деградацией IOPS на enterprise-хранилищах

Каждое закрытое соединение регистрируется демоном 3proxy синхронным или асинхронным вызовом write(2). Заданная нами маска:

logformat "L%Y-%m-%d %H:%M:%S.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T"

выводит подробный лог: * %Y-%m-%d %H:%M:%S.%.: абсолютное время события с точностью до миллисекунд. * %N.%p: имя сервиса и системный PID рабочего потока. * %E: код завершения сессии (0 — штатное закрытие, ошибки сокетов Linux ядра при сбое). * %U: авторизованный логин. * %C:%c и %R:%r: связка Source IP:Port и Target IP:Port. * %O и %I: количество отправленных и принятых байт. * %h: запрашиваемый хост / URL. * %T: общее время жизни TCP-сессии в секундах.

В условиях генерации 5 000–10 000 запросов в секунду интенсивность записи текстовых логов достигает сотен мегабайт в час. Дешевые виртуальные серверы с сетевыми дисками (SAN/Ceph) или consumer-накопителями с низкой производительностью на случайную запись (случайные 4K QD1 IOPS < 2 000) мгновенно сталкиваются с блокировкой дисковой подсистемы (iowait > 20%). Это замораживает процесс 3proxy в статусе ядра D (Uninterruptible Sleep) и обрушивает сетевой стек.

Инфраструктурная платформа tropic.host исключает дисковые задержки: ноды оснащены серверными NVMe-накопителями корпоративного уровня с шиной PCIe 4.0, обеспечивающими устойчивую скорость произвольной записи свыше 50 000 IOPS при глубине очереди QD1. В сочетании со статическим выделенным IPv4-адресом без скрытой фильтрации нестандартных портов (диапазон 10000–65000 полностью открыт) и отсутствием оверселлинга CPU (%st = 0.0%), платформа гарантирует безотказное выполнение системных вызовов логирования без просадки throughput сетевого трафика.

Валидация прав доступа и проверка конфигурации

Перед активацией службы проверяются права доступа на конфигурационный файл и системные каталоги. Демон 3proxy категорически запрещено запускать под учетной записью суперпользователя root:

# Создание системной изолированной группы и пользователя без командной оболочки
sudo groupadd -r proxyusers
sudo useradd -r -g proxyusers -s /usr/sbin/nologin -d /etc/3proxy proxyuser

# Назначение прав на бинарник и конфигурацию
sudo chown -R proxyuser:proxyusers /etc/3proxy
sudo chmod 700 /etc/3proxy
sudo chmod 600 /etc/3proxy/3proxy.cfg

# Создание и делегирование каталогов для логов и pid-файла
sudo mkdir -p /var/log/3proxy /var/run/3proxy
sudo chown -R proxyuser:proxyusers /var/log/3proxy /var/run/3proxy
sudo chmod 750 /var/log/3proxy /var/run/3proxy

Для проверки корректности синтаксиса перед перезапуском systemd-юнита выполняется пробный запуск демона в foreground-режиме:

# Пробный запуск под целевым пользователем для отлова синтаксических ошибок
sudo -u proxyuser 3proxy /etc/3proxy/3proxy.cfg

Проверка прослушивания портов и соответствия привязки к внешним интерфейсам выполняется через утилиту ss(8):

ss -tlpn | grep 3proxy

Вывод должен отображать распределение дескрипторов по портам:

LISTEN 0   128   192.0.2.15:10001   0.0.0.0:*   users:(("3proxy",pid=14205,fd=4))
LISTEN 0   128   192.0.2.15:10002   0.0.0.0:*   users:(("3proxy",pid=14205,fd=5))
LISTEN 0   128   192.0.2.15:10003   0.0.0.0:*   users:(("3proxy",pid=14205,fd=6))
LISTEN 0   128   192.0.2.15:10800   0.0.0.0:*   users:(("3proxy",pid=14205,fd=7))

Функциональный тест каждого порта на корректность аутентификации и физический выход в сеть через соответствующий IPv6-адрес выполняется следующей командой терминала:

curl -s -S -x http://proxy_worker_01:W1e\!r4\#[email protected]:10001 \
     https://api64.ipify.org?format=json

Ответ удаленного узла подтверждает привязку сессии к заданному в директиве -e адресу:

{"ip":"2a01:4f8:1c1c:45a1::1"}

При попытке передачи невалидных учетных данных или обращения к запрещенным через ACL внутренним ресурсам (curl -x http://invalid:[email protected]:10001 http://169.254.169.254) ядро 3proxy мгновенно возвращает стандартные коды HTTP 407 Proxy Authentication Required либо 403 Forbidden, фиксируя инцидент в журнале с кодом завершения 13 (Permission Denied).

Автоматическая генерация и ротация пула адресов из подсети IPv6 /64

Ручная привязка сотен сетевых интерфейсов и портов не масштабируется в production-среде. Для решения задач автоматического скрапинга, нагрузочного тестирования распределенных API и обхода жестких rate-limit по IPv6-префиксам развертывается детерминированный конвейер ротации. При правильной маршрутизации на стороне аплинка провайдера вся подсеть /64 (содержащая $2^{64} \approx 1.84 \times 10^{19}$ уникальных адресов) направляется на сетевой интерфейс виртуального сервера. Это позволяет динамически генерировать произвольные идентификаторы хоста (Interface Identifier, IID) в пределах назначенного префикса без согласования с upstream-маршрутизатором.

Оптимизация сетевого стека ядра Linux под плотный пул адресов

Перед генерацией тысяч адресов на одном физическом или виртуальном интерфейсе необходимо скорректировать параметры стека IPv6 в ядре Linux. Поведение по умолчанию рассчитано на единичные адреса и вызовет системный сбой:

Duplicate Address Detection (DAD): По умолчанию протокол DAD отправляет ICMPv6 Neighbor Solicitation на каждый добавляемый адрес. Попытка назначить 2 000 адресов одномоментно породит лавину широковещательного трафика, переводя интерфейс в состояние задержки и блокируя сокеты на 2–5 секунд на каждый адрес. Для пула ротации DAD отключается флаwaveм ядра или директивой nodad.
Лимиты таблицы соседей (NDP Cache): Системные лимиты сборщика мусора ядра gc_thresh для IPv6 по умолчанию малы (обычно 1024–2048 записей). Превышение повлечет ошибку Neighbour table overflow, потерю пакетов и всплеск p99 latency свыше 3 000 мс.

Параметры вносятся в файл /etc/sysctl.d/99-ipv6-proxy.conf:

# Отключение Duplicate Address Detection (DAD) для мгновенного биндинга адресов
net.ipv6.conf.all.accept_dad = 0
net.ipv6.conf.default.accept_dad = 0
net.ipv6.conf.eth0.accept_dad = 0

# Увеличение емкости таблицы соседей NDP (Neighbor Discovery Protocol)
net.ipv6.neigh.default.gc_thresh1 = 4096
net.ipv6.neigh.default.gc_thresh2 = 8192
net.ipv6.neigh.default.gc_thresh3 = 16384

# Расширение лимита сетевых маршрутов IPv6 в ядре
net.ipv6.route.max_size = 131072

# Разрешение связывания с нелокальными адресами на уровне сокетов (IP_FREEBIND)
net.ipv6.ip_nonlocal_bind = 1

# Оптимизация очередей входящих соединений под высокий параллелизм
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

Применение параметров выполняется системным вызовом через интерфейс procfs:

sudo sysctl -p /etc/sysctl.d/99-ipv6-proxy.conf

На виртуализации KVM платформы tropic.host ядро гостевой ОС получает прямой доступ к кольцевым буферам виртуального адаптера virtio_net. Отсутствие оверселлинга процессора (%st = 0.0% на ядрах AMD EPYC и Ryzen 9) исключает дропы пакетов на уровне драйвера при обработке мягких прерываний (softirq) во время массовой инициализации сокетов.

Скрипт автоматизированной генерации пула и конфигурации 3proxy

Скрипт выполняет следующие атомарные шаги: * Очищает ранее назначенные динамические IPv6 с интерфейса, сохраняя статический адрес управления сервером. * Генерирует псевдослучайные 64-битные суффиксы для целевого префикса /64. * Массово инжектирует сгенерированные адреса в стек сетевого интерфейса с флагом nodad. * Создает монолитный конфигурационный файл /etc/3proxy/3proxy.cfg с индивидуальной привязкой каждого порта к уникальному исходящему IPv6-адресу (-e). * Генерирует экспортный файл списка прокси для конечных клиентов в формате IP:PORT:USER:PASS. * Проверяет валидность конфигурации и перезапускает демон 3proxy.

Создайте исполняемый файл /usr/local/bin/rotate_3proxy_ipv6.sh:

#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# СИСТЕМНЫЕ ПАРАМЕТРЫ И СЕТЕВАЯ КОНФИГУРАЦИЯ
# ==============================================================================
INTERFACE="eth0"
IPV4_BIND="192.0.2.15"                # Внешний IPv4-адрес сервера tropic.host
IPV6_PREFIX="2a01:4f8:1c1c:45a1"      # Назначенная /64 подсеть (без завершающего двоеточия)
STATIC_GATEWAY_IPV6="2a01:4f8:1c1c:45a1::1" # Системный адрес (не удалять при ротации!)

PORT_START=20000                      # Начальный порт входящих подключений
COUNT=1000                            # Количество генерируемых прокси-каналов

CONFIG_PATH="/etc/3proxy/3proxy.cfg"
BACKUP_CONFIG="/etc/3proxy/3proxy.cfg.bak"
TRACKING_FILE="/var/run/3proxy_current_ips.list"
EXPORT_FILE="/etc/3proxy/proxy_export.txt"

# Системные лимиты
PROXY_USER="proxy_rotator"
PROXY_PASS="D9#kL2!vN8@xP0$wQ"
PID_FILE="/var/run/3proxy/3proxy.pid"

# ==============================================================================
# ЭТАП 1: ОЧИСТКА ПРЕДЫДУЩЕГО ПУЛА ИЗ СТЕКА ЯДРА LINUX
# ==============================================================================
echo "[+] Инициализация очистки устаревших IPv6 адресов..."
if [[ -f "$TRACKING_FILE" ]]; then
    while IFS= read -r ip_to_remove; do
        if [[ -n "$ip_to_remove" && "$ip_to_remove" != "$STATIC_GATEWAY_IPV6" ]]; then
            ip -6 addr del "${ip_to_remove}/64" dev "$INTERFACE" 2>/dev/null || true
        fi
    done < "$TRACKING_FILE"
    rm -f "$TRACKING_FILE"
fi

# ==============================================================================
# ЭТАП 2: ФОРМИРОВАНИЕ БАЗОВОГО ШАБЛОНА 3PROXY
# ==============================================================================
echo "[+] Формирование конфигурационного файла 3proxy..."
[[ -f "$CONFIG_PATH" ]] && cp "$CONFIG_PATH" "$BACKUP_CONFIG"

cat <<EOF > "$CONFIG_PATH"
# Автоматически сгенерированная конфигурация ротации IPv6
daemon
pidfile $PID_FILE
nserver 1.1.1.1
nserver 8.8.8.8
nserver 2606:4700:4700::1111
nscache 65536
timeouts 1 5 30 60 180 1800 15 60
stacksize 262144

# Пул аутентификации
users $PROXY_USER:CL:$PROXY_PASS
auth strong
allow $PROXY_USER

EOF

# Подготовка временных файлов
rm -f "$TRACKING_FILE" "$EXPORT_FILE"
touch "$TRACKING_FILE" "$EXPORT_FILE"

# ==============================================================================
# ЭТАП 3: ГЕНЕРАЦИЯ АДРЕСОВ, ПРИВЯЗКА К СЕТИ И ПРОБРОС ПОРТОВ
# ==============================================================================
echo "[+] Генерация $COUNT адресов и биндинг на интерфейс $INTERFACE..."

for (( i=0; i<COUNT; i++ )); do
    CURRENT_PORT=$(( PORT_START + i ))

    # Генерация 4 случайных 16-битных шестнадцатеричных блоков для IID (64 бита)
    RAND_BLOCK_1=$(openssl rand -hex 2)
    RAND_BLOCK_2=$(openssl rand -hex 2)
    RAND_BLOCK_3=$(openssl rand -hex 2)
    RAND_BLOCK_4=$(openssl rand -hex 2)

    GENERATED_IPV6="${IPV6_PREFIX}:${RAND_BLOCK_1}:${RAND_BLOCK_2}:${RAND_BLOCK_3}:${RAND_BLOCK_4}"

    # Добавление адреса в стек интерфейса без задержки DAD
    ip -6 addr add "${GENERATED_IPV6}/64" dev "$INTERFACE" nodad

    # Фиксация адреса в файле отслеживания
    echo "$GENERATED_IPV6" >> "$TRACKING_FILE"

    # Формирование связки в 3proxy: SOCKS5 и HTTP(S) proxy на выделенном порту
    # Параметр -6 указывает на IPv6 downstream, -i задает входящий IPv4, -e задает исходящий IPv6
    cat <<EOF >> "$CONFIG_PATH"
proxy -6 -n -a -p$CURRENT_PORT -i$IPV4_BIND -e$GENERATED_IPV6
flush
EOF

    # Формирование экспортного списка для парсеров/ботов
    echo "${IPV4_BIND}:${CURRENT_PORT}:${PROXY_USER}:${PROXY_PASS}" >> "$EXPORT_FILE"
done

# Корректировка владельца и прав доступа к файлам
chown -R proxyuser:proxyusers /etc/3proxy /var/run/3proxy
chmod 600 "$CONFIG_PATH"
chmod 600 "$EXPORT_FILE"

# ==============================================================================
# ЭТАП 4: ВАЛИДАЦИЯ И ПЕРЕЗАПУСК СЕРВИСА
# ==============================================================================
echo "[+] Валидация синтаксиса и перезапуск процесса..."
if ! sudo -u proxyuser 3proxy -c "$CONFIG_PATH" > /dev/null 2>&1; then
    # Проверка, что бинарник корректно парсит директивы
    true
fi

# Перезапуск через systemd с контролем статуса
systemctl restart 3proxy

# Проверка факта поднятия первого и последнего портов
sleep 1
if ss -tlpn | grep -q ":${PORT_START} "; then
    echo "[SUCCESS] Пул из $COUNT IPv6 прокси успешно развернут и слушает порты с $PORT_START по $(( PORT_START + COUNT - 1 ))."
    echo "[INFO] Экспортный список сохранен в: $EXPORT_FILE"
else
    echo "[ERROR] Ошибка запуска демона. Выполняется откат конфигурации..."
    if [[ -f "$BACKUP_CONFIG" ]]; then
        mv "$BACKUP_CONFIG" "$CONFIG_PATH"
        systemctl restart 3proxy
    fi
    exit 1
fi

Назначьте скрипту права на исполнение исключительно пользователю root:

sudo chmod 700 /usr/local/bin/rotate_3proxy_ipv6.sh
sudo chown root:root /usr/local/bin/rotate_3proxy_ipv6.sh

Настройка системного таймера Systemd для циклической ротации

Использование стандартного cron для задач ротации высоконагруженных прокси-сетей неоптимально: он не предоставляет изоляции ресурсов, зависимостей запуска и мониторинга статуса сбоя. Запуск оформляется через связку systemd.service и systemd.timer.

Создайте файл описания сервиса /etc/systemd/system/3proxy-rotate.service:

[Unit]
Description=3proxy IPv6 Pool Rotation Service
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/rotate_3proxy_ipv6.sh
StandardOutput=journal
StandardError=journal
TimeoutSec=120

# Изоляция ресурсов через cgroups v2
CPUWeight=100
MemoryMax=1G
TasksMax=4096

Создайте юнит таймера /etc/systemd/system/3proxy-rotate.timer, задающий периодичность смены пула адресов (например, каждые 3 часа с рандомизацией для предотвращения прогнозирования трафика внешними системами):

[Unit]
Description=Timer for 3proxy IPv6 Pool Rotation

[Timer]
OnBootSec=5min
OnUnitActiveSec=3h
RandomizedDelaySec=300
Persistent=true

[Install]
WantedBy=timers.target

Активация и немедленный запуск таймера:

sudo systemctl daemon-reload
sudo systemctl enable --now 3proxy-rotate.timer

Проверка состояния интервалов ротации:

systemctl list-timers 3proxy-rotate.timer

Вывод команды отобразит точное время следующего срабатывания:

NEXT                         LEFT          LAST PASSED UNIT                ACTIVATES
Sun 2026-10-04 17:12:45 UTC  2h 58min left n/a  n/a    3proxy-rotate.timer 3proxy-rotate.service

Диагностика сетевого стека и верификация изоляции egress-трафика

Для подтверждения того, что при реализации схемы ротации IPv6 в 3proxy на виртуальном сервере каждый локальный порт корректно маршрутизирует трафик через индивидуальный IPv6-адрес, запускается параллельный опрос контрольного узла:

# Проверка первых трех портов пула
for PORT in 20000 20001 20002; do
    echo -n "Port $PORT -> Outbound IPv6: "
    curl -s --max-time 5 -x "http://proxy_rotator:D9#kL2!vN8@xP0\[email protected]:$PORT" \
         https://api64.ipify.org?format=json | jq -r .ip
done

Результат выполнения демонстрирует уникальные адреса из целевой /64 сети:

Port 20000 -> Outbound IPv6: 2a01:4f8:1c1c:45a1:3d8a:9f12:c0e1:14a2
Port 20001 -> Outbound IPv6: 2a01:4f8:1c1c:45a1:a71b:44e9:8802:ef51
Port 20002 -> Outbound IPv6: 2a01:4f8:1c1c:45a1:11e0:bc23:90fa:67d4

Мониторинг расхода дескрипторов сокетов и состояния таблицы соседства выполняется утилитами ip и ss:

# Контроль заполнения таблицы NDP
ip -6 neigh show nud reachable | wc -l

# Проверка распределения сокетов в ядре
ss -s

Благодаря тому, что виртуальные машины tropic.host подключены к физическим аплинкам с пропускной способностью 1–10 Гбит/с и настроенным алгоритмом TCP BBR, всплеск установления сотен TCP-соединений при очередной итерации ротации адресов не вызывает буферблоата (bufferbloat) и сохраняет задержку сетевого стека (p99 latency) в пределах 2–5 мс до магистральных европейских узлов обмена трафиком. Выделенный массив корпоративных NVMe-накопителей стандарта PCIe 4.0 полностью исключает ожидание ввода-вывода (I/O Wait), гарантируя атомарную перезапись объемных конфигурационных файлов и журналов 3proxy без просадки производительности активных воркеров.

Настройка демона systemd, ротация логов и защита от сканеров портов

Для непрерывной и устойчивой к сбоям эксплуатации 3proxy на VPS с IPv6 ротацией сервис не должен запускаться во временных сессиях screen или tmux. Обслуживание тысяч параллельных TCP-соединений требует перевода прокси-сервера в управляемый системный демон под контролем systemd, жесткой изоляции ресурсов через подсистему cgroups v2, выделения лимитов файловых дескрипторов и внедрения активной фильтрации аномального трафика.

1. Сервисный юнит systemd и изоляция через cgroups v2

Запуск процесса от непривилегированного пользователя с ограничением пространств имен ядра защищает операционную систему в случае эксплуатации уязвимостей в сетевом демоне. Перед созданием юнита создается системный пользователь и группа без права интерактивного входа:

# Создание сервисной учетной записи и каталогов
sudo groupadd -r 3proxy
sudo useradd -r -g 3proxy -d /etc/3proxy -s /usr/sbin/nologin 3proxy
sudo mkdir -p /var/log/3proxy /run/3proxy /etc/3proxy
sudo chown -R 3proxy:3proxy /var/log/3proxy /run/3proxy /etc/3proxy

Конфигурационный файл юнита /etc/systemd/system/3proxy.service настраивается с учетом максимальной утилизации сетевого стека:

[Unit]
Description=3proxy High-Performance Tiny Proxy Server
Documentation=man:3proxy(8) https://3proxy.ru/
After=network-online.target time-sync.target
Wants=network-online.target

[Service]
Type=simple
User=3proxy
Group=3proxy
WorkingDirectory=/etc/3proxy
ExecStart=/usr/local/bin/3proxy /etc/3proxy/3proxy.cfg
ExecReload=/bin/kill -HUP $MAINPID
PIDFile=/run/3proxy/3proxy.pid
Restart=always
RestartSec=3s
KillMode=control-group

# Снятие ограничений ядра на сетевые соединения и потоки
LimitNOFILE=1048576
LimitNPROC=524288
LimitMEMLOCK=infinity

# Изоляция ресурсов cgroups v2
MemoryAccounting=yes
MemoryHigh=1800M
MemoryMax=2048M
CPUAccounting=yes
CPUWeight=100
TasksMax=32768

# Песочница (Sandboxing) и ограничение привилегий ядра
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
PrivateDevices=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=true
RestrictRealtime=true
LockPersonality=true
MemoryDenyWriteExecute=true

# Разрешенные каталоги для записи логов и PID-файла
ReadWritePaths=/var/log/3proxy /run/3proxy

# Сетевые capabilities для привязки к сокетам
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_NET_ADMIN
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

Директивы MemoryHigh=1800M и MemoryMax=2048M задают мягкий и жесткий лимиты потребления оперативной памяти. При превышении порога в 1800 МБ ядро Linux активирует механизм асинхронного сброса страниц (page reclaim), не вызывая аварийного завершения процесса через OOM Killer. Директива LimitNOFILE=1048576 предотвращает появление ошибок системного вызова accept(): EMFILE: Too many open files при пиковых нагрузках в моменты ротации пула адресов.

После записи файла конфигурации служба регистрируется в системе:

sudo systemctl daemon-reload
sudo systemctl enable 3proxy.service
sudo systemctl start 3proxy.service

# Верификация применения лимитов и состояния cgroups v2
systemctl status 3proxy.service
cat /proc/$(pgrep -f 3proxy)/limits | grep "Max open files"
systemd-cgls /system.slice/3proxy.service

2. Конфигурация ротации логов (logrotate)

При интенсивной многопоточной маршрутизации через тысячи внешних IPv6-адресов журнал 3proxy генерирует сотни мегабайт событий в сутки. Задержки ввода-вывода (I/O Wait) при неблокирующей записи в журнал могут вызывать всплески latency (p99) сетевых сокетов.

Для атомарной ротации без прерывания активных клиентских сессий настраивается штатный сервис logrotate. 3proxy поддерживает переоткрытие дескриптора лог-файла по сигналу SIGUSR1 или мягкую перезагрузку по SIGHUP.

Конфигурация /etc/logrotate.d/3proxy:

/var/log/3proxy/3proxy.log {
    daily
    rotate 14
    missingok
    notifempty
    compress
    compresscmd /usr/bin/zstd
    compressext .zst
    compressoptions -19 -T0
    sharedscripts
    dateext
    dateformat -%Y%m%d-%s
    create 0640 3proxy 3proxy
    postrotate
        if [ -f /run/3proxy/3proxy.pid ]; then
            /bin/kill -USR1 $(cat /run/3proxy/3proxy.pid) 2>/dev/null || true
        fi
    endscript
}

Использование многопоточного алгоритма zstd со сжатием максимального уровня -19 минимизирует объем хранимых архивов на диске при практически нулевой нагрузке на процессор.

На виртуальных серверах tropic.host аппаратная дисковая подсистема построена на серверных NVMe-накопителях стандарта PCIe 4.0 со скоростью случайного чтения/записи 4K QD1 свыше 50 000 IOPS. Это исключает блокировку очередей ввода-вывода ядра при сжатии и архивации терабайтных массивов логов, удерживая параметр CPU Steal Time на эталонном значении %st = 0.0%.

Принудительный тест регламента ротации:

sudo logrotate -d -f /etc/logrotate.d/3proxy
sudo logrotate -f /etc/logrotate.d/3proxy
ls -lh /var/log/3proxy/

3. Защита от сканеров портов и перебора авторизации

Развертывание пула из сотен или тысяч последовательных портов (например, с 20000 по 25000) неизбежно привлекает автоматизированные сканеры сетевых диапазонов (ZMap, Masscan, Shodan). Атаки типа Brute-force и распределенное сканирование портов приводят к деградации таблицы состояний ядра conntrack и исчерпанию очереди SYN-backlog.

Защита выстраивается на двух уровнях: низкоуровневая фильтрация сканеров через сетевой фильтр nftables и пресечение подбора учетных данных через Fail2ban.

Уровень ядра: превентивная блокировка port-knocking и сканеров в nftables

Правила nftables отсекают адреса, выполняющие веерное сканирование закрытых портов или превышающие лимит новых полуоткрытых соединений в секунду:

# Создание таблицы и наборов IP-адресов
sudo nft add table inet firewall
sudo nft add set inet firewall port_scanners '{ type ipv4_addr; flags timeout; timeout 1h; }'
sudo nft add set inet firewall syn_flooders '{ type ipv4_addr; flags timeout; timeout 30m; }'

# Правила фильтрации входящего трафика
sudo nft add chain inet firewall input '{ type filter hook input priority filter; policy accept; }'

# Сброс трафика от уже заблокированных сканеров
sudo nft add rule inet firewall input ip saddr @port_scanners counter drop
sudo nft add rule inet firewall input ip saddr @syn_flooders counter drop

# Обнаружение SYN-флуда (более 50 новых соединений в секунду с одного IP)
sudo nft add rule inet firewall input pflags syn tcp dport 20000-25000 \
    meter syn_meter '{ ip saddr limit rate over 50/second }' \
    add @syn_flooders '{ ip saddr }' counter drop

# Логирование и изоляция сканирования портов, не входящих в белый список 3proxy
sudo nft add rule inet firewall input tcp dport { 22, 80, 443 } accept
sudo nft add rule inet firewall input tcp dport 20000-25000 accept
sudo nft add rule inet firewall input ct state new tcp flags syn counter add @port_scanners '{ ip saddr }' drop

Для сохранения правил при перезагрузке ОС конфигурация фиксируется в файле:

sudo nft list ruleset | sudo tee /etc/nftables.conf
sudo systemctl enable --now nftables

Прикладной уровень: автоматический бан в Fail2ban по логам 3proxy

В конфигурации 3proxy задан структурированный формат лога:

logformat "L%Y-%m-%d %H:%M:%S %z %N.%p %E %U %C:%c %R:%r %O %I %h %T"

Код ошибки %E принимает значение 00005 или 00001 при ошибке авторизации клиента (Proxy Authentication Required / Access Denied).

Создается фильтр Fail2ban /etc/fail2ban/filter.d/3proxy-auth.conf:

[Definition]
# Регулярное выражение поиска отказов аутентификации в логе 3proxy
failregex = ^\S+\s+\S+\s+\S+\s+3proxy\.\d+\s+(?:00001|00005|00407)\s+\S*\s+<HOST>:\d+
ignoreregex =

Создается конфигурация джейла /etc/fail2ban/jail.d/3proxy.local:

[3proxy-auth]
enabled = true
port = 20000:25000
filter = 3proxy-auth
logpath = /var/log/3proxy/3proxy.log
backend = polling
maxretry = 5
findtime = 600
bantime = 86400
banaction = nftables-multiport[actname=3proxy, chain=input]
action = %(banaction)s[name=%(__name__)s, bantime="%(bantime)s", port="%(port)s", protocol="tcp"]

Перезапуск и верификация работы службы Fail2ban:

sudo systemctl restart fail2ban
sudo fail2ban-client status 3proxy-auth

4. Комплексная проверка телеметрии и нагрузки

После сборки программно-аппаратного контура выполняется стресс-тестирование изоляции и мониторинг ключевых системных вызовов под нагрузкой.

Аудит состояния подсистемы cgroups v2 и выделенных файловых дескрипторов:

# Текущее потребление физической памяти и кэша процессом 3proxy
cat /sys/fs/cgroup/system.slice/3proxy.service/memory.current | awk '{print $1/1024/1024 " MB"}'

# Мониторинг системных вызовов epoll_wait и accept4 в реальном времени
sudo perf top -p $(pgrep -f 3proxy)

Проверка распределения сетевых сокетов ядра и отсутствия отброшенных пакетов:

# Диагностика переполнения очереди соединений
netstat -s | grep -i "listen drops"

# Анализ состояния сокетов в стеке TCP
ss -it 'sport >= :20000 and sport <= :25000' state established | grep -E "(rtt|retrans)"

Платформа tropic.host гарантирует аппаратную изоляцию виртуализации KVM на базе серверных процессоров AMD EPYC и Intel Xeon с тактовой частотой ядер до 3.5–5.0 ГГц.

В сочетании с магистральными сетевыми каналами пропускной способностью до 10 Гбит/с и поддержкой BGP Anycast с прямыми стыками на крупнейших европейских точках обмена трафиком (DE-CIX Frankfurt, AMS-IX Amsterdam), сетевой стек ядра сохраняет расчетные тайминги TCP Handshake в пределах 1.5–3 мс.

Аппаратная фильтрация DDoS-атак на уровнях L3/L4 поглощает объемный мусорный трафик еще до достижения сетевого интерфейса виртуальной машины, предотвращая засорение очередей драйвера virtio_net и гарантируя стабильную работу ротации IPv6 под экстремальной нагрузкой.

Тестирование пропускной способности, утечек DNS и аудит безопасности

Конфигурация сетевого стека и распределение пула адресов требуют комплексной верификации перед запуском боевых сценариев парсинга или автоматизации. Организованная через 3proxy на VPS IPv6 ротация подвержена рискам скрытых деградаций: десинхронизации исходящих сокетов, утечкам метаданных через протокол DNS, искажению TCP-фингерпринта и блокировкам по заголовкам прикладного уровня. Ниже представлен регламент аппаратного и протокольного аудита развернутого прокси-сервера.

1. Автоматизированная валидация пула и энтропии ротации через curl

Главный критерий корректности ротации — равномерное распределение исходящих TCP-сессий по выделенному диапазону /64 без повторения адресов в рамках заданного квантового окна.

Для экспресс-теста одиночного сокета и профилирования сетевых таймингов применяется curl с форматированным выводом метрик TCP/TLS Handshake:

curl -s -o /dev/null -w "\
HTTP Status:       %{http_code}\n\
DNS Lookup Time:   %{time_namelookup}s\n\
TCP Connect Time:  %{time_connect}s\n\
TLS Handshake:     %{time_appconnect}s\n\
TTFB (Start Xfer): %{time_starttransfer}s\n\
Total Duration:    %{time_total}s\n" \
  --proxy "http://proxyuser:[email protected]:20001" \
  "https://api64.ipify.org"

Для стресс-проверки всего диапазона портов (например, с 20000 по 20250) и подтверждения генерации уникальных IPv6 используется многопоточный Bash-пайплайн на базе xargs:

#!/usr/bin/env bash
set -euo pipefail

PROXY_IP="198.51.100.25"
USER_PASS="proxyuser:StrongSecretPass2026"
START_PORT=20000
END_PORT=20250
CONCURRENCY=32
OUTPUT_LOG="proxy_audit_results.log"

echo "[*] Запуск параллельного тестирования портов ${START_PORT}-${END_PORT} (потоков: ${CONCURRENCY})..."
> "${OUTPUT_LOG}"

seq "${START_PORT}" "${END_PORT}" | xargs -P "${CONCURRENCY}" -I {PORT} bash -c '
    RES=$(curl -s --max-time 5 \
        --proxy "http://'"${USER_PASS}"'@'"${PROXY_IP}"':{PORT}" \
        "https://api64.ipify.org" 2>/dev/null || echo "FAILED")

    if [[ "$RES" =~ : ]]; then
        echo "PORT {PORT} -> IPv6: $RES [OK]"
    else
        echo "PORT {PORT} -> ERROR: $RES [FAIL]"
    fi
' >> "${OUTPUT_LOG}"

# Статистика пула
TOTAL_TESTED=$(wc -l < "${OUTPUT_LOG}")
SUCCESS_COUNT=$(grep -c "\[OK\]" "${OUTPUT_LOG}" || true)
UNIQUE_IPV6=$(grep "\[OK\]" "${OUTPUT_LOG}" | awk '{print $4}' | sort -u | wc -l)

echo "--- Итоги валидации пула ---"
echo "Всего портов протестировано: ${TOTAL_TESTED}"
echo "Успешных сессий:              ${SUCCESS_COUNT}"
echo "Уникальных IPv6 адресов:      ${UNIQUE_IPV6}"

Если значение UNIQUE_IPV6 строго равно SUCCESS_COUNT, сетевой стек ядра корректно выполняет маршрутизацию ip route add local для префикса, а демон 3proxy передает корректный флаг SO_BINDTODEVICE или связывает исходящий интерфейс через bind() без коллизий.

2. Аудит утечек DNS (DNS Leaks) и изоляция резолвинга

Утечка реального IP-адреса клиента или статического IPv4-адреса ноды через резолвер нейтрализует целевую изоляцию прокси. В архитектуре SOCKS5 критично понимать разницу между типами передачи адресов:

Локальный резолвинг (SOCKS5 без флага hostname): Клиент самостоятельно отправляет запрос на системный DNS-сервер своего провайдера, а на прокси передает уже полученный IP-адрес. Это приводит к прямой утечке топологии сети клиента (DNS Leak) и блокировкам по геолокации.
Удаленный резолвинг (SOCKS5h / ATYP 0x03 Domain Name): Клиент передает доменное имя в исходном бинарном кадре SOCKS5 (поле ATYP = 0x03 по спецификации RFC 1928). Демон 3proxy обязан выполнять резолвинг исключительно на стороне сервера.

Проверка на утечку DNS выполняется перехватом сетевых пакетов на внешнем физическом интерфейсе VPS во время выполнения запроса:

# Запуск сниффера системных вызовов резолвинга на сервере
sudo tcpdump -i any -n "udp port 53 or tcp port 53 or udp port 853" -l

С клиентской машины отправляется контрольный запрос с жестким принуждением к удаленному DNS через флаг --socks5-hostname:

# ПРАВИЛЬНО: резолвинг выполняется демоном 3proxy на стороне VPS
curl -s --socks5-hostname "proxyuser:[email protected]:20001" \
  "https://one.one.one.one/cdn-cgi/trace" | grep -E "(ip|loc|dns)"

# НЕПРАВИЛЬНО (провоцирует DNS Leak на клиенте):
curl -s --socks5 "proxyuser:[email protected]:20001" \
  "https://one.one.one.one/cdn-cgi/trace"

Для полной ликвидации DNS-утечек на стороне сервера в конфигурационном файле /etc/3proxy/3proxy.cfg директива nserver переопределяется на защищенные Anycast-резолверы с валидацией DNSSEC, минуя дефолтный локальный systemd-resolved:

# Использование независимых резолверов без логирования
nserver 1.1.1.1
nserver 8.8.8.8
nserver 2606:4700:4700::1111
nserver 2001:4860:4860::8888
nscache 65536
timeout 1 5 30 60 180 1800 15 60

3. Тестирование анонимности и пассивный TCP/IP фингерпринтинг (p0f/p99)

При использовании HTTP-прокси антифрод-системы анализируют заголовки прикладного уровня L7 на наличие следов проксирования: Via, X-Forwarded-For, X-Real-IP, Proxy-Connection, а также расхождение MTU/MSS на транспортном уровне L4.

Проверка заголовков L7

Выполняется запрос к эхо-сервису с инспекцией возвращаемого JSON-дампа:

curl -s -x "http://proxyuser:[email protected]:20001" \
  "https://httpbin.org/headers" | jq .

Эталонный вывод не должен содержать следов присутствия 3proxy:

{
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.org",
    "User-Agent": "curl/8.5.0"
  }
}

Если в теле ответа присутствуют заголовки Via или X-Forwarded-For, режим полной анонимности в 3proxy активируется добавлением параметров в секцию конфигурации:

# Скрытие системных метаданных и отключение инъекций заголовков
anonymous
force

Защита от деанонимизации через TCP MSS Clamping

Антифрод-платформы вычисляют проксирование через расхождение между размером максимального сегмента (MSS) в заголовке TCP SYN и стандартным размером MTU сетевого интерфейса. На виртуализированных KVM-нодах tropic.host аппаратные сетевые адаптеры virtio_net функционируют со стандартным размером MTU 1500 байт без скрытых оверхедов туннелирования (GRE/VXLAN), что предотвращает фрагментацию пакетов.

Для фиксации стандартного размера MSS в ядре Linux активируется правило nftables / iptables:

# Фиксация размера MSS для исходящих IPv6 соединений
sudo ip6tables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

4. Асинхронный аудит пула с расчетом Latency p50/p95/p99

Для промышленного мониторинга инфраструктуры разработан Python-скрипт на базе библиотек asyncio и httpx (с поддержкой socksio), реализующий одновременный аудит аутентификации, валидацию геопринадлежности и расчет перцентилей задержки (RTT):

#!/usr/bin/env python3
"""
Инженерный чекер пула 3proxy: проверка ротации IPv6, DNS-leak и перцентилей задержки.
Требует: pip install httpx[socks] numpy
"""

import asyncio
import time
import numpy as np
import httpx

GATEWAY_IPV4 = "198.51.100.25"
AUTH_CREDS = "proxyuser:StrongSecretPass2026"
PORT_RANGE = range(20000, 20100)
CHECK_TARGET = "https://api64.ipify.org"
CONCURRENCY_LIMIT = 25

async def test_proxy_node(semaphore: asyncio.Semaphore, port: int, client: httpx.AsyncClient):
    proxy_url = f"http://{AUTH_CREDS}@{GATEWAY_IPV4}:{port}"
    async with semaphore:
        start_time = time.perf_counter()
        try:
            response = await client.get(
                CHECK_TARGET,
                proxy=proxy_url,
                timeout=7.0
            )
            elapsed_ms = (time.perf_counter() - start_time) * 1000

            if response.status_code == 200:
                ip_addr = response.text.strip()
                # Валидация наличия IPv6 (содержит двоеточия)
                is_ipv6 = ":" in ip_addr
                return {
                    "port": port,
                    "status": "SUCCESS" if is_ipv6 else "IPV4_LEAK",
                    "ip": ip_addr,
                    "latency": elapsed_ms
                }
            return {"port": port, "status": f"HTTP_{response.status_code}", "ip": None, "latency": elapsed_ms}
        except httpx.RequestError as exc:
            elapsed_ms = (time.perf_counter() - start_time) * 1000
            return {"port": port, "status": f"ERR_{type(exc).__name__}", "ip": None, "latency": elapsed_ms}

async def main():
    semaphore = asyncio.Semaphore(CONCURRENCY_LIMIT)
    async with httpx.AsyncClient(verify=True) as client:
        tasks = [test_proxy_node(semaphore, port, client) for port in PORT_RANGE]
        print(f"[*] Старт аудита {len(PORT_RANGE)} прокси-портов (Concurrency: {CONCURRENCY_LIMIT})...")
        results = await asyncio.gather(*tasks)

    success_nodes = [r for r in results if r["status"] == "SUCCESS"]
    latencies = [r["latency"] for r in success_nodes]
    unique_ips = set(r["ip"] for r in success_nodes)

    print("\n================== ИТОГОВЫЙ ОТЧЕТ АУДИТА ==================")
    print(f"Всего сокетов в пуле:     {len(results)}")
    print(f"Рабочих IPv6 эндпоинтов: {len(success_nodes)}")
    print(f"Уникальных адресов IPv6: {len(unique_ips)}")
    print(f"Коэффициент энтропии:    {(len(unique_ips) / len(success_nodes) * 100) if success_nodes else 0:.2f}%")

    if latencies:
        p50 = np.percentile(latencies, 50)
        p95 = np.percentile(latencies, 95)
        p99 = np.percentile(latencies, 99)
        print(f"RTT Latency p50:         {p50:.2f} ms")
        print(f"RTT Latency p95:         {p95:.2f} ms")
        print(f"RTT Latency p99:         {p99:.2f} ms")

    # Диагностика ошибок
    failures = [r for r in results if r["status"] != "SUCCESS"]
    if failures:
        print("\nОбнаружены сбойные порты:")
        for fail in failures[:10]:
            print(f"  Порт {fail['port']}: {fail['status']} ({fail['latency']:.1f} ms)")
        if len(failures) > 10:
            print(f"  ... и еще {len(failures) - 10} портов с ошибками.")

if __name__ == "__main__":
    asyncio.run(main())

При эксплуатации сетевых пулов на базе инфраструктуры tropic.host за счет выделенной KVM-виртуализации с нулевым оверселлингом процессора (%st = 0.0%) и аппаратных NVMe-накопителей со скоростью случайного чтения 4K QD1 свыше 50 000 IOPS, значения p99 latency для пула из сотен параллельных соединений удерживаются в пределах 15–35 мс. Прямой BGP-аплинк в ключевых узлах обмена трафиком (Франкфурт, Амстердам) исключает джиттер маршрутизации, обеспечивая стабильную пропускную способность каждого исходящего IPv6-канала без потери пакетов на перегруженных транзитных узлах.

Часто задаваемые вопросы (FAQ)

Сколько ресурсов потребляет 3proxy на 1 000 параллельных соединений?

3proxy написан на C и чрезвычайно легковесен: на 1 000 одновременных потоков ему требуется менее 30–50 МБ оперативной памяти и минимальная нагрузка на 1 vCPU.

Зачем нужна KVM виртуализация для генерации тысяч IPv6 адресов?

На чистом KVM ядро позволяет свободно биндить тысячи адресов из маршрутизируемой подсети /64 через ip -6 addr add. На OpenVZ/LXC добавление внешних IP часто заблокировано гипервизором.

Назад к блогу

Настройка 3proxy на KVM VPS: собственный приватный прокси-сервер, ротация пула IPv6 /64 и авторизация

Содержание

Аппаратные и сетевые требования к VPS под высоконагруженный прокси

1. Архитектура виртуализации и влияние фактора CPU Steal Time (%st)

2. Топология подсети /64 IPv6 и локальная маршрутизация без нагрузки на NDP

Ошибка физического назначения адресов

Корректная реализация: Local AnyIP маршрутизация

3. Профиль потребления оперативной памяти C-демоном 3proxy

Структура расхода памяти на одно TCP-соединение:

4. Матрица сайзинга аппаратных ресурсов под профили нагрузки

5. Тюнинг сетевого стека Linux под высоконагруженный проксинг (sysctl.conf)

6. Изоляция демона и управление лимитами через systemd (cgroups v2)

7. Требования к дисковой подсистеме NVMe для ротации и логгирования

Сборка 3proxy из исходного кода и тюнинг сетевого стека Linux

Подготовка сборочного окружения и оптимизация исходного кода

Низкоуровневый тюнинг ядра Linux для ротации IPv6 (sysctl)

Разгрузка CPU: обход подсистемы Netfilter Conntrack

Архитектурные требования к гипервизору: стабильность KVM на tropic.host

Конфигурация 3proxy.cfg: порты, списки доступа (ACL) и авторизация по логину

Эталонный production-конфиг /etc/3proxy/3proxy.cfg

Архитектурный разбор ключевых директив и системных структур ядра

1. Диспетчеризация резолвинга: nscache и nscache6

2. Тайм-ауты и управление жизненным циклом сокетов: timeouts

3. Модель аутентификации: auth strong vs auth iponly

4. Безопасность инфраструктуры: предотвращение SSRF через ACL

Логирование с нулевой деградацией IOPS на enterprise-хранилищах

Валидация прав доступа и проверка конфигурации

Автоматическая генерация и ротация пула адресов из подсети IPv6 /64

Оптимизация сетевого стека ядра Linux под плотный пул адресов

Скрипт автоматизированной генерации пула и конфигурации 3proxy

Настройка системного таймера Systemd для циклической ротации

Диагностика сетевого стека и верификация изоляции egress-трафика

Настройка демона systemd, ротация логов и защита от сканеров портов

1. Сервисный юнит systemd и изоляция через cgroups v2

2. Конфигурация ротации логов (logrotate)

3. Защита от сканеров портов и перебора авторизации

Уровень ядра: превентивная блокировка port-knocking и сканеров в nftables

Прикладной уровень: автоматический бан в Fail2ban по логам 3proxy

4. Комплексная проверка телеметрии и нагрузки

Тестирование пропускной способности, утечек DNS и аудит безопасности

1. Автоматизированная валидация пула и энтропии ротации через curl

2. Аудит утечек DNS (DNS Leaks) и изоляция резолвинга

3. Тестирование анонимности и пассивный TCP/IP фингерпринтинг (p0f/p99)

Проверка заголовков L7

Защита от деанонимизации через TCP MSS Clamping

4. Асинхронный аудит пула с расчетом Latency p50/p95/p99

Часто задаваемые вопросы (FAQ)

Сколько ресурсов потребляет 3proxy на 1 000 параллельных соединений?

Зачем нужна KVM виртуализация для генерации тысяч IPv6 адресов?

5. Тюнинг сетевого стека Linux под высоконагруженный проксинг (`sysctl.conf`)

Эталонный production-конфиг `/etc/3proxy/3proxy.cfg`

1. Диспетчеризация резолвинга: `nscache` и `nscache6`

2. Тайм-ауты и управление жизненным циклом сокетов: `timeouts`

3. Модель аутентификации: `auth strong` vs `auth iponly`