---

Разработка распределённой сети прокси-узлов с интеллектуальной маршрутизацией трафика и системой мониторинга

О проекте

Нужно создать инфраструктуру из нескольких прокси-серверов, расположенных в разных географических регионах, которые объединены в единую сеть и умеют передавать трафик между собой. Ключевая задача системы - автоматически находить самый быстрый маршрут от пользователя до целевого сервиса, исходя из реальных измерений сети (задержка, потери пакетов, загруженность узла).

Система должна работать полностью автономно: самостоятельно мерить качество каналов, выбирать лучший маршрут и переключаться при деградации любого узла - без ручного вмешательства.

Минимальная конфигурация запуска: 3 узла в разных регионах (EU / US / Asia).  
Целевая конфигурация: 6-10 узлов с возможностью добавления новых без остановки системы.


Стек и технические требования к окружению
Компонент	Технология
ОС узлов	Ubuntu 22.04 LTS / Debian 12
Протоколы передачи	TCP, UDP, SOCKS5, HTTP CONNECT
Межузловое туннелирование	WireGuard (предпочтительно) или GRE
Язык бэкенда	Go (предпочтительно) или Python
Контейнеризация	Docker + Docker Compose
Мониторинг	Prometheus + Grafana
БД для метрик	InfluxDB или TimescaleDB
Геолокация	MaxMind GeoIP2 или аналог
VPS	Предоставляет заказчик
Состав работ

1. Настройка и развёртывание прокси-узлов
Что нужно сделать:
•	Установить и настроить прокси-сервер на каждом VPS с поддержкой SOCKS5 и HTTP CONNECT протоколов
•	Настроить межузловое туннелирование (WireGuard) для безопасной передачи трафика между серверами
•	Сконфигурировать firewall (iptables / nftables): закрыть лишние порты, разрешить только необходимые соединения, включить защиту от брутфорса
•	Настроить автозапуск всех сервисов через systemd с watchdog-мониторингом (автоматический перезапуск при падении)
•	Поддержка как TCP, так и UDP трафика на каждом узле
•	Подготовить Ansible-плейбук или bash-скрипт для автоматизированного развёртывания нового узла с нуля (идемпотентный, воспроизводимы
Ожидаемый результат:
Каждый узел работает стабильно, принимает входящие соединения, корректно проксирует трафик, защищён от несанкционированного доступа. Новый сервер разворачивается за 1 команду.

2. Построение сети между узлами
Что нужно сделать:
•	Организовать сетевую топологию между всеми узлами - full-mesh (каждый с каждым) или hub-and-spoke (через центральный узел). Исполнитель предлагает архитектуру с обоснованием плюсов и минусов для данной задачи
•	Реализовать multi-hop маршрутизацию: трафик может передаваться через несколько промежуточных узлов перед выходом к целевому сервису
•	Настроить внутренний DNS-резолвинг для адресации узлов по hostname внутри сети
•	Реализовать горизонтальное масштабирование: новый узел добавляется в сеть через onboarding-скрипт без остановки системы и без изменения конфигурации существующих узлов
•	Обеспечить изоляцию внутреннего трафика: трафик между узлами не должен быть виден снаружи
Ожидаемый результат:
Сеть из 3+ узлов, связанных между собой зашифрованными туннелями. Трафик может передаваться между любыми узлами. Добавление нового узла занимает не более 10 минут.

3. Система мониторинга узлов
Что нужно сделать:
•	На каждом узле установить Prometheus exporters для сбора следующих метрик:
￮	RTT / latency до набора целевых хостов (список конфигурируется, например: игровые серверы, CDN)
￮	Packet loss (%) - постоянные ICMP/TCP ping-измерения
￮	Throughput (Mbps) - входящий и исходящий трафик
￮	Системные метрики: CPU, RAM, Disk I/O, сетевые интерфейсы
￮	Количество активных соединений через данный узел
￮	Статус туннелей между узлами (up/down)
•	Настроить централизованный Prometheus для сбора метрик со всех узлов
•	Создать дашборд в Grafana с:
￮	Картой узлов и их текущим статусом (зелёный / жёлтый / красный)
￮	Графиками latency и packet loss по каждому узлу в динамике
￮	Топ-5 самых нагруженных маршрутов
￮	Сравнительной таблицей всех узлов
•	Настроить алертинг (email или Telegram-webhook):
￮	Узел недоступен более 30 секунд
￮	Latency превышает пороговое значение (конфигурируется)
￮	Packet loss > 5%
￮	CPU/RAM узла > 85%
•	Хранение исторических данных метрик - минимум 30 дней
Ожидаемый результат:
Полностью рабочий мониторинг в Grafana, доступный по URL. Алерты настроены и протестированы. Можно в любой момент увидеть состояние всей сети одним взглядом.

4. Система определения оптимальной точки входа для пользователя
Что нужно сделать:
•	Реализовать модуль GeoIP-определения по IP пользователя (страна, регион, ASN)
•	Разработать алгоритм выбора оптимального узла на основе комбинации факторов:
￮	Географическая близость пользователя к узлу
￮	Текущий RTT от пользователя до узла (если доступно)
￮	Текущий packet loss на узле
￮	Текущая нагрузка узла (количество соединений, CPU)
•	Разработать HTTP API-эндпоинт:
￮	GET /best-node?ip=<user_ip> → возвращает JSON с рекомендованным узлом (hostname, IP, регион, текущий latency)
￮	GET /nodes → возвращает список всех активных узлов с их метриками
•	Реализовать кэширование результатов (TTL конфигурируется, по умолчанию 30 секунд)
•	Предусмотреть fallback-логику: если лучший узел недоступен - возвращается следующий по рейтингу

Ожидаемый результат:
API работает, отвечает корректно и быстро (< 50ms). При имитации запроса с разных IP-адресов возвращает разные узлы в зависимости от геолокации и текущего состояния сети.

5. Система динамической маршрутизации трафика
Что нужно сделать:
•	Реализовать алгоритм построения оптимального маршрута между узлами на основе текущих метрик (аналог алгоритма Дейкстры с весами по latency и packet loss)
•	Веса метрик должны быть конфигурируемыми (например: 70% latency + 30% packet loss - задаётся в конфиге)
•	Обеспечить динамическое обновление маршрутов без перезапуска сервисов: при изменении метрик маршруты пересчитываются автоматически (интервал пересчёта конфигурируется, рекомендуется 5-15 секунд)
•	Реализовать автоматический failover: при деградации или падении узла трафик переключается на резервный маршрут в течение не более 10 секунд
•	Вести подробный лог маршрутных решений:
￮	Timestamp решения
￮	Выбранный маршрут и причина выбора
￮	Отброшенные маршруты и их метрики
•	Предусмотреть режим принудительного маршрута (override): возможность вручную задать конкретный маршрут через конфиг для отладки
Ожидаемый результат:
Система самостоятельно адаптирует маршруты при изменении качества каналов. Лог показывает, почему был выбран тот или иной маршрут. При искусственном ухудшении канала между двумя узлами система переключается на обходной маршрут автоматически.

Требования к документации
Документ	Содержание
README / Architecture Doc	Описание архитектуры, схема сети (диаграмма обязательна), описание всех компонентов
Deployment Guide	Пошаговое руководство по развёртыванию узла с нуля, воспроизводимое без знания проекта
API Reference	Описание всех эндпоинтов: параметры, примеры запросов/ответов
Operations Runbook	Как добавить узел, как откатить, как посмотреть логи, как обновить конфиги
Конфигурационные файлы	Все настройки вынесены в .env / YAML, никакого hardcode
Весь код размещается в Git-репозитории с чистой историей коммитов и осмысленными commit messages.
По завершении - видеодемонстрация или live-сессия: показать работу мониторинга, смену маршрута при деградации узла, API-ответ с выбором оптимального узла.

Требования к исполнителю
Обязательно:
•	Опыт администрирования Linux-серверов (Ubuntu/Debian): сеть, firewall, systemd
•	Уверенное знание сетевых протоколов: TCP/UDP, SOCKS5, туннелирование
•	Практический опыт настройки WireGuard или аналогичных VPN-туннелей
•	Опыт развёртывания и настройки Prometheus + Grafana
•	Умение писать автоматизированные скрипты развёртывания (Ansible или bash)
Желательно:
•	Опыт написания сетевых сервисов на Go
•	Понимание алгоритмов маршрутизации (Dijkstra, Bellman-Ford)
•	Опыт работы с GeoIP-базами (MaxMind)
•	Опыт с InfluxDB / TimescaleDB
Приветствуется:
•	Портфолио с похожими проектами (сетевая инфраструктура, распределённые системы, VPS-кластеры)
•	GitHub с примерами кода

Что НЕ входит в задачу
•	Разработка клиентского приложения (мобильное, desktop, браузерное)
•	Биллинг, авторизация и управление пользователями
•	Закупка и аренда серверов (предоставляет мы)
Разработка прокси-узлов с маршрут. трафика,мониторингом
Нужно создать инфраструктуру из нескольких прокси-серверов, расположенных в разных географических регионах, которые объединены в единую сеть и умеют передавать трафик между собой. Ключевая задача системы - автоматически находить самый быстрый маршрут от пользователя до целевого сервиса, исходя из реальных измерений сети (задержка, потери пакетов, загруженность узла).
Система должна работать полностью автономно: самостоятельно мерить качество каналов, выбирать лучший маршрут и переключаться при деградации любого узла - без ручного вмешательства.
Минимальная конфигурация запуска: 2 узла в регионах (EU / РФ).
Целевая конфигурация: 5 - 10 узлов с возможностью добавления новых без остановки системы.
Состав работ
1. Настройка и развёртывание прокси-узлов
- Настройка прокси-узлов (SOCKS5, firewall, systemd)
2. Построение сети между узлами
- Сеть между узлами (mesh-топология, multi-hop, масштабирование)
3. Система мониторинга узлов
- Мониторинг (метрики, дашборды, алертинг)
4. Система определения оптимальной точки входа для пользователя
- Выбор оптимального узла для пользователя (GeoIP + метрики → API)
5. Система динамической маршрутизации трафика
- Динамическая маршрутизация (алгоритм, fallback, веса метрик)
Подробнее с ТЗ можно ознакомиться в документе. Он может обсуждаться корректироваться исходя из возможностей и понимания исполнителя о проекте т.к. требования могут не соответствовать на начальном этапе желаемого результата.
Разработка DNS сервиса.docx
Желаемый бюджет: до 20 000 ₽
Допустимый: до 60 000 ₽

Покупатель: KalinaAleks 
Размещено проектов на бирже: 5
Нанято: 0%
Осталось: 19 ч. 49 мин.
Предложений: 16

 Добрый день. Тема: проект "Разработка прокси-узлов с маршрут. трафика,мониторингом"
Хочу немного рассказать подробнее что планируем. Это сервис оптимизации сетевых маршрутов похожая на ExitLag примерно, но свое решение. Это не VPN и не смена IP-адреса пользователя. Нас не интересует анонимность или обход блокировок. Задача одна - снизить задержку (ping) и уменьшить потери пакетов до конкретного сервера при этом не меняя пользователю его ip и не попадая под ограничения как сервис VPN.

Суть, стандартный интернет-маршрут от пользователя до игрового сервера идёт через множество промежуточных узлов, и часто это не самый короткий путь по задержке. Мы хтим выстроить свою сеть прокси-узлов в разных точках мира и прокладываем трафик через неё - так, чтобы пакет шёл по более прямому и быстрому пути, а а сарте в рамках MVP сделать для рф в EU.

Вопросы
1) Каким инструментом или способом ты бы реализовал перехват трафика конкретного приложения или IP на клиентской стороне - и почему именно так, а не иначе?
2) Как бы ты измерял качество канала между узлами - ICMP ping достаточно или нет? Что ещё нужно мерить и почему по твоему мнению?
3) Представь что два сервера Amsterdam и Frankfurt - оба близко к пользователю. Как система должна выбрать через какой из них пускать трафик?
4) Какие сервера нужны для такого сервиса и пропуской способсти для сервиса с 1000 пользователями?