Roundrobin у дії 🔁

Почав із найпростішого режиму — roundrobin.

Логіка очевидна: нове TCP-з’єднання віддаємо наступному доступному proxy backend. Дійшли до кінця списку — починаємо спочатку 🔄

Для перевірки підняв echo server на 10.10.10.2:8000 і відправив до нього десять запитів через gateway.

Спочатку логи здались трохи хаотичними, бо записи з різних контейнерів виводились не по порядку 😶‍🌫️

Але після сортування за timestamp усе стало на місце: контейнери проходять послідовно, а дев’ятий і десятий запити починають нове коло ✅

Є нюанс: HAProxy розподіляє саме з’єднання. Якщо програма тримає один keep-alive connection, запити всередині нього не будуть стрибати між backend.

А що робити, якщо нам навпаки потрібна стабільна IP-адреса? Тут з’являється stick-table 📌

Навіщо я додав stick-table 📌

Roundrobin добре розподіляє навантаження, але підходить не для кожного сценарію.

Уявімо, що програма робить декілька послідовних дій на одному сайті. Якщо між ними зміниться зовнішня IP-адреса, сесія може виглядати підозріло або просто зламатися 🤷‍♂️

Тому додав режим із прив’язкою клієнта до одного backend.

Важливий момент: stick-table — не алгоритм балансування. Це таблиця стану. Разом зі stick on src вона запам’ятовує, який backend HAProxy обрав для конкретної IP-адреси клієнта 🧠

Перемкнув режим через REST API і повторив десять запитів. Цього разу всі їх записав один контейнер — CT-302 ✅

Отже, прив’язка працює. Тепер треба було перевірити найважливіше: чи справді VM не може вийти напряму.

Чи може VM обійти gateway? 🧪

Те, що curl показує адресу проксі, — добре. Але мені хотілось переконатись, що іншого маршруту справді немає 🔍

Спочатку запит до ifconfig.me повернув IP проксі-сервера. Потім я видалив default route:

ip route del default

Після цього curl уже не зміг виконати DNS-запит, а ping відповів Network is unreachable. Тобто запасного виходу в інтернет машина не знайшла ✅

Повернув маршрут тільки через тестовий gateway:

ip route add default via 192.168.90.1 dev eth1

З firewall теж встиг трохи повоювати 😅 Спочатку OutputPolicy=DROP відрізав навіть керування через SSH. Для тестового стенда залишив явний DROP на небажаний вихід через management-інтерфейс.

У production я б усе ж залишав deny-by-default і окремо дозволяв потрібний службовий трафік 🛡

Вимикаю один проксі й повторюю тест 🩺

Остання перевірка — що буде, якщо один proxy backend перестане відповідати.

Вимкнув один із восьми тестових контейнерів і ще раз відправив десять запитів до echo server.

Усі десять повернули HTTP 200 ✅

Нових записів від вимкненого контейнера в логах не з’явилось. HAProxy продовжив віддавати з’єднання тільки доступним backend. Саме такої поведінки я й очікував.

Для лабораторного тесту цього достатньо. У production я б додатково читав статус DOWN через HAProxy Runtime API або сторінку статистики й підключив alerts 📊

І ще одне обмеження: ця гілка перехоплює TCP. Довільний UDP, зокрема QUIC/HTTP3 на UDP/443, через неї не проходить. DNS у моєму gateway обробляється окремо.

Повний розбір зі схемою та скріншотами залишу в наступному пості 🚀

Transparent Gateway для TCP — повний розбір 🚀

Зібрав в одну статтю весь шлях від ізольованої VM до тесту падіння proxy backend ⚙️

Всередині:

• окремий VLAN і маршрут через gateway;
• перехоплення TCP через iptables;
• redsocks як міст до проксі;
• HAProxy, roundrobin і stick-table;
• REST API для перемикання режимів;
• перевірка вихідної IP-адреси;
• тест health check на восьми LXC-контейнерах.

Додав команди, схему й реальні скріншоти з тестового стенда 📄

https://devdays.net.ua/articles/prozore-proksiiuvannia-tcp-redsocks-haproxy/

Код проєкту тут:
https://github.com/Va1b0rt/TransparentGateway

Наступний крок — збирати проксі з дозволених джерел, перевіряти їх, ранжувати й уже після цього завантажувати в робочий пул. Там теж вистачає цікавих нюансів 😬

З тестовими проксі було аж занадто добре 😅

Під час тестів я вручну додав вісім LXC у HAProxy. Вони стояли на своїх адресах, слухняно відповідали на health check і нікуди не зникали. Краса 😎

А потім я подумав про реальні проксі. Сьогодні адреса жива, за годину гальмує, завтра її вже немає. І спробуй вгадай, яка саме вирішить померти посеред роботи 🫣

Перевіряти це руками після кожного падіння? Не наш метод 😤. Буду автоматизувати.

Замість одного списку зібрав конвеєр:

source → fetcher → validator → ranker → active pool → gateway

Останні завершені цикли видно так:

docker compose logs --no-log-prefix --tail=20 \
  fetcher validator ranker

На моєму стенді зараз виходить:

[fetcher] sources=1 candidates=1
[validator] healthy=1/1
[ranker] validated=1 reserve=1 active=1

Це один агрегований HAProxy endpoint, тому 1 → 1 → 1 тут нормально. Головне — три незалежні worker завершили свої цикли.

Далі пішов підключати джерела. Здавалося б, JSON він і є JSON. Ага, зараз 😅

Хотів один connector для всіх JSON. Не вийшло 🧩

Першою думкою було зробити універсальний connector: даю йому URL, він читає JSON, усі задоволені 🚀

Перший реальний feed швидко пояснив, що мій оптимізм нічим не підкріплений 😅

Одне джерело повертає ip, інше host, протокол лежить то в type, то в protocol. Якщо додавати всі ці винятки у fetcher, через місяць там буде музей чужих форматів.

Тому всередині залишив одну модель:

host, port, protocol, source, credential_ref, metadata

А різницю виніс у adapters. Джерела вмикаються явно:

{
  "allowed_connector_types": [
    "jsonl_inventory", "http_json_feed"
  ],
  "active_connectors": [{
    "type": "jsonl_inventory",
    "name": "lab-lxc",
    "path": "/inventory/upstreams.jsonl"
  }]
}

Автоматично імпортувати всі Python-файли з каталогу теж не став. Випадково підкинутий файл не повинен раптом стати дозволеним мережевим джерелом 🔐

Fetcher збирає записи, прибирає дублікати й публікує proxy_pool:raw:v1. Але raw — це ще не пул. Це список адрес, яким поки що ніхто не вірить.

Наступним кроком треба було перевірити, чи вони взагалі проксі, а не просто красиві відкриті порти 🔍

Порт відкритий. Проксі живий? Не факт 🔌

Спочатку хотів перевіряти кандидатів через nc -z. Порт відкрився — значить проксі живий. Логіка залізна. Майже 😅

Socket може прийняти з’єднання, а потім відмовити на HTTP CONNECT, зламати SOCKS handshake або просто не дістатися цільового сервера.

Тому validator проходить весь маршрут:

candidate
  → HTTP CONNECT / SOCKS4 / SOCKS5 handshake
  → echo endpoint
  → HTTP status + JSON + latency

Щоб під час перевірки не покласти власний gateway, обмежив конкуренцію:

VALIDATION_CONCURRENCY=100
PROXY_VALIDATION_TIMEOUT_SECONDS=8

Semaphore тримає максимум 100 одночасних перевірок. Для сотень і тисяч адрес цього вистачає. Перед сотнями тисяч доведеться замінити asyncio.gather() на bounded queue, інакше coroutine самі з’їдять пам’ять 🤷‍♂️

З proxy auth теж без магії. У snapshot лежить лише credential_ref, а secret дістається перед handshake:

auth = credentials.get(candidate.credential_ref)

Немає посилання або пароль неправильний — кандидат вилітає. Тихого fallback без авторизації немає.

Handshake пройшов. Уже можна радіти? Ще ні. Проксі може працювати й акуратно здавати мою адресу далі 🫣

Проксі працює, але здає мою IP 🕵️

Після успішного handshake я майже записав кандидата в робочий пул. Але ж проксі може додати мою реальну адресу в X-Forwarded-For і формально все одно повернути HTTP 200 😬

Тому validator спочатку йде до echo напряму й запам’ятовує адресу клієнта. Потім повторює запит через проксі.

Якщо direct IP знову видно як peer або вона з’явилась у Forwarded, X-Forwarded-For, X-Real-IP чи Client-IP — кандидат відхиляється.

Для разової зовнішньої перевірки використовую:

ANONYMITY_CHECK_URL=https://httpbingo.org/get

Саме /get, а не /ip. Поточному parser потрібні і origin, і об’єкт headers. Тому ipify та ifconfig.me сюди без доробки не підходять.

У лабораторії в мене інший endpoint:

ANONYMITY_CHECK_URL=http://10.10.10.2:8000/

Він перевіряє HAProxy та контейнери 301–308, але нічого не доводить про публічний Internet. Для production потрібен ще власний HTTPS echo. Чужий безкоштовний сервіс сьогодні працює, а завтра вводить rate limit — і знову весело 🙃

Адресу отримали. Тепер можна ранжувати. І тут найшвидші кандидати підготували ще один сюрприз.

Десять IP в одному плащі 🧥

Відсортував кандидатів за latency, подивився на красиву верхівку списку й уже хотів радіти 🚀

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

Для цього зробив окремий demo:

./scripts/run-diversity-ranking-demo.sh

Результат скорочено:

INPUT
proxy-1: ASN=AS1, latency=10ms
proxy-2: ASN=AS1, latency=11ms
proxy-3: ASN=AS2, latency=20ms

OUTPUT
1. proxy-1: ASN=AS1, score=92.909091
2. proxy-3: ASN=AS2, score=49.619048
3. proxy-2: ASN=AS1, score=28.444444

Повільніший AS2 піднявся між двома AS1 через ASN/subnet penalty. Це синтетичний тест: production snapshot він не чіпає, зате добре показує логіку ranker 🔍

Ще додав MIN_SCORE_THRESHOLD. Якщо нормальних кандидатів лише 40, POOL_SIZE=150 не змушує добирати 110 трупів для красивої цифри. Порожнє місце в пулі краще за проксі, який не пройшов поріг.

З ранжуванням розібрався. Залишилось безпечно передати результат між worker. Один ключ у Redis? Ну звісно, ні 😬

Один ключ у Redis? Ага, зараз 😅

Спочатку хотів тримати весь стан в одному Redis key. Fetcher записав список, validator його оновив, ranker відсортував. Просто ж 🤔

А потім два worker одночасно торкнуться цього ключа — і спробуй зрозумій, чий там зараз результат.

Тому розділив конвеєр на повні snapshots:

proxy_pool:raw:v1
proxy_pool:validated:v1
proxy_pool:reserve:v1
proxy_pool:active:v1

Перевірити поточний стан можна так:

./scripts/run-redis-rows.sh

На лабораторному стенді зараз:

proxy_pool:raw:v1: 1
proxy_pool:validated:v1: 1
proxy_pool:reserve:v1: 1
proxy_pool:active:v1: 1
transparent-gateway:validated:v1: 1

Ці числа показують, що ключі містять повні списки. Чи належать вони одному циклу — окремо звіряю через generated_at, source_generated_at і logs.

Запис теж зробив без проміжного стану: спочатку тимчасовий key, потім атомарний Redis RENAME. Читач бачить старий або новий повний JSON, а не половину нового пулу 🛡

Active готовий. Тепер просто віддам його HAProxy й піду пити каву. Принаймні такий був план ☕️

Віддав mixed pool у HAProxy. Майже 🚧

План здавався нормальним: ranker формує active pool, HAProxy підхоплює backend через config або Runtime API, я задоволений і йду далі 😎

Але пул змішаний: HTTP, HTTPS, SOCKS4, SOCKS5, ще й credentials подекуди є. HAProxy як TCP backend не виконає SOCKS handshake і не дістане пароль за credential_ref.

От і приїхали 😬

Між redsocks та upstream довелось додати protocol-aware relay:

VM → iptables → redsocks :12345
   → egress_relay :12000
   → HTTP / HTTPS / SOCKS4 / SOCKS5 upstream
   → destination

Перед новим з’єднанням relay перевіряє active snapshot, але не частіше ніж раз на три секунди. Потім вибирає кандидата, виконує правильний handshake і тільки тоді підставляє credentials. Restart або reload не потрібен ⚙️

Є чесне обмеження: у живому active pool поки один агрегований HAProxy endpoint. Тому показати реальний cooldown між двома direct candidates на цьому стенді я не можу. Логіка покрита unit-тестами, а HAProxy failover окремо перевірений на восьми LXC.

Отака вийшла проста задача «автоматично оновлювати список проксі» 😅

У наступному пості зберу код, тести й повний матеріал.

Автоматичний пул проксі — код, тести й граблі 🚀

Зібрав увесь шлях в одну статтю: від першого JSON до active pool, який gateway підхоплює без рестарту. Інформації вийшло нормально так 😅

Перед запуском стенда перевірив протокольну логіку окремо:

python3 -m venv .venv
. .venv/bin/activate
python -m pip install -r requirements-dev.txt
python -m pytest -q

Результат:

............................ [100%]
28 passed

Усередині статті:

• connector adapters;
• HTTP, HTTPS, SOCKS4 і SOCKS5 validation;
• authenticated proxy без secrets у Redis;
• перевірка витоку IP;
• ASN diversity та quality threshold;
• атомарні snapshots;
• глухий кут із HAProxy;
• protocol-aware egress relay;
• шість практичних перевірок.

Обмеження теж не ховав: стенд поки має один агрегований HAProxy endpoint, для реальної різноманітності потрібні direct candidates, а для постійної зовнішньої перевірки — власний HTTPS echo.

Стаття, до якої вела ця серія:
https://devdays.net.ua/articles/avtomatychnyi-pul-proksi-zbir-validatsiia-ranzhuvannia/

Код:
https://github.com/Va1b0rt/TransparentGateway

Далі буду відучувати gateway від ручного налаштування однієї VM: Proxmox, cloud-init і deployment. Там теж без граблів не обійдеться ⚙️😬

Gateway працює. А повторити його я зможу? 🤔

Transparent Gateway уже маршрутизує DNS і TCP, оновлює active pool та переживає перезапуск контейнерів. На схемі — майже production. На диску — кілька днів моїх ручних пригод 😅

Поки VM жива, різниці не видно. Але якщо диск завтра вирішить піти у відпустку, чи вдасться відтворити той самий gateway на чистій машині без історії shell і магічного "десь я це вже правив"?

Почав із простого аудиту на gateway: перевірив середовище, стан cloud-init, версію Debian і запущені сервіси.

systemd-detect-virt
cloud-init status
. /etc/os-release; echo "$PRETTY_NAME"
docker compose ps

Ключові рядки виглядали так:

kvm
status: done
Debian GNU/Linux 13 (trixie)

Docker також показав усі шість сервісів запущеними. Здавалося б, де проблема?

Проблема в одному слові: done стосується cloud-init, а не всього gateway. VM створена автоматично, застосунок — ще ні. Далі пішов шукати, де саме закінчується автоматизація 🔍

Щоб зрозуміти, яку частину gateway справді можна відтворити, порівняв вміст робочої VM з тим, що зберігає Git. Перевірку запускав на gateway з кореня проєкту:

cd /opt/transparent-gateway
git ls-files | grep -E \
  '(^|/)(deploy|cloud-init|systemd|.*\.service$|docker-compose\.yml$|\.env\.example$)'

Результат короткий:

.env.example
docker-compose.yml

Скрипту розгортання немає. Конфігурації cloud-init немає. Окремого systemd-сервісу для gateway теж немає. Робочі .env, списки проксі та паролі живуть лише на конкретній VM.

До того ж відтворити треба не лише контейнери. У хоста три мережеві ролі: керування, клієнтський gateway і лабораторна мережа з проксі та echo-сервісом. Переплутати два інтерфейси — і Docker буде зелений, а клієнтський трафік піде гуляти не туди 🚶‍♂️

Отже, копії каталогу недостатньо. Потрібна процедура, яка відтворює весь стан — від мережі до повної перевірки готовності.

Запхнути все розгортання в runcmd. YAML починає мститися 📜

План номер два: cloud-init встановить Docker, забере код із Git, створить конфігурацію, передасть секрети й виконає docker compose up. Один YAML — одна VM — усі задоволені. Перші хвилин п’ять 😅

Далі runcmd росте, повторний запуск стає окремою пригодою, а перевірити розгортання можна лише створенням нової VM. Якщо команда впала посередині, треба вгадати, що вже виконалося, а що тільки збиралося.

Із секретами ще веселіше. Cloud-init зберігає отриманий user-data всередині /var/lib/cloud/instances/ і може згадати його в журналах. Передати там пароль проксі або токен API — це залишити секрет на диску під табличкою "я тут" 🔐

На gateway сам факт збереження можна перевірити без відкриття вмісту:

find /var/lib/cloud/instances -maxdepth 2 \
  -type f -name 'user-data*' -printf '%m %p\n'

Висновок вийшов простий: cloud-init потрібен, але він не повинен знати всю біографію застосунку. Його робота — зробити VM керованим хостом і передати естафету окремому коду розгортання.

Де закінчується cloud-init і починається gateway ⚙️

Після двох крайнощів межа нарешті стала нормальною:

шаблон Proxmox
  → cloud-init: ім’я, SSH, мережа
  → код розгортання: версія, конфігурація, systemd
  → Docker Compose
  → перевірка: знімки стану, проксі, весь маршрут

Секрети надходять окремим захищеним каналом. Шаблон їх не бачить, у Git їх немає, а user-data не перетворюється на музей паролів.

Ще одна важлива різниця: запущений контейнер — не обов’язково готовий сервіс. Зелений статус не доводить, що активний список проксі свіжий, relay приймає з’єднання, а клієнт справді виходить через gateway.

Тому остаточний критерій буде жорстким: нова VM з чистого шаблону, повторюване розгортання, перезавантаження і жодної додаткової SSH-команди. Якщо треба "тільки один маршрут руками поправити" — автоматизація ще не завершена 😅

У статті зібрав аудит поточної VM, дві відкинуті крайнощі й архітектуру наступного етапу:
https://devdays.net.ua/articles/chomu-transparent-gateway-ne-hotovyi-do-production/

Наступний матеріал буде практичним: створю чистий шаблон, підготую cloud-init і systemd, а потім перевірю перезавантаження та повне відтворення gateway.

Видалити VM і не пошкодувати 😅

Transparent Gateway працює. DNS і TCP-трафік проходять через проксі, пул оновлюється, контейнери переживають перезапуск.

Зараз gateway прив’язаний до конкретної VM. Якщо з нею щось станеться, швидко розгорнути таку саму не вийде. Тому хочу перетворити налаштовану вручну машину на відтворюване розгортання: створив нову VM, запустив автоматизацію — отримав готовий gateway.

Мій домашній стенд працює на Proxmox, тому почну з чистого шаблону Debian. Це базова VM без коду gateway, паролів, даних Redis і слідів попередніх експериментів. Proxmox використовуватиме її як основу для створення нових машин.

Початкове налаштування виконає cloud-init. Це стандартний механізм, який готує VM під час першого запуску: задає ім’я машини, створює користувача, додає SSH-ключі, налаштовує мережу та встановлює Docker.

На цьому робота cloud-init закінчується. Він готує операційну систему, але не розгортає сам Transparent Gateway. Код застосунку, його конфігурацію, секрети, запуск контейнерів і перевірку готовності передам окремому сценарію. Так початкове налаштування VM не залежить від конкретної версії gateway, а застосунок можна оновити без створення нової машини.

Після розгортання systemd керуватиме запуском gateway і підніматиме його після перезавантаження.

Хто тут за що відповідає 🧩

Щоб автоматизація не перетворилася на один великий скрипт із правами root, розділив розгортання на кілька частин:

шаблон Debian
  ↓
Proxmox створює VM
  ↓
cloud-init готує систему
  ↓
сценарій розгортає gateway
  ↓
systemd керує запуском
  ↓
перевірка проходить увесь маршрут

Шаблон містить лише чистий Debian і підтримку cloud-init. У ньому немає коду Transparent Gateway, секретів, Docker-образів або даних Redis. Це основа, яку можна використовувати для різних машин.

Proxmox створює з шаблону нову VM, підключає мережеві інтерфейси й передає початкові налаштування через cloud-init.

Cloud-init готує операційну систему: створює користувача, додає SSH-ключі, налаштовує мережу та встановлює Docker. Після цього машина готова прийняти застосунок, але самого gateway на ній ще немає.

Далі окремий сценарій доставляє потрібну версію коду, перевіряє конфігурацію та запускає контейнери. Секрети передаються окремо: вони не потрапляють ані в шаблон, ані в Git, ані в дані cloud-init.

Після розгортання керування переходить до systemd. Він запускає Transparent Gateway після Docker і мережі, а також піднімає його знову після перезавантаження VM.

Останній етап — перевірка готовності. Вона дивиться не лише на запущені контейнери, а й на свіжість пулу проксі та проходження клієнтського запиту через gateway.

Тепер кожна частина має одну роботу. А якщо щось зламається, принаймні не доведеться шукати одну потрібну команду посеред YAML на три екрани 😅