Selective Telegram Routing

Выборочная маршрутизация IPv4-сетей Telegram через отдельный WireGuard-туннель на европейский VPS. Остальной трафик основного Debian-сервера продолжает использовать обычный маршрут. Поддерживается трафик самого сервера, контейнеров с network_mode: host и клиентов существующего wg0.

Это набор примеров и пошаговая инструкция для интеграции в существующую сеть. Автоматической замены firewall нет.

Основной сервер / host-контейнер
    Telegram IPv4 → OUTPUT mark 0x200 ───────────────┐
                                                   ↓
Клиент → wg0 → PREROUTING mark 0x200 → table 200 → wg-eu
                                                   ↓ SNAT 10.7.0.11
                                              EU VPS wg0
                                                   ↓ FORWARD + masquerade
                                               Интернет → Telegram

Остальной IPv4 → main table → обычный интернет-интерфейс

Быстрый вход

1. У вас уже есть WireGuard-профиль? Начните с инструкции для начинающего: 10 шагов. Она подключает Debian к VPN и направляет Telegram в туннель; существующий wg0 не нужен.
2. Нужны пояснения? Откройте FAQ: ключи, адреса, AllowedIPs, IPv6, Docker, обновление и отключение.
3. VPN-сервера ещё нет или есть сложный firewall? Используйте настройку EU и интеграцию.
4. Подробности: архитектура, проверки и reboot, диагностика и MTU.

Источники адресов Telegram

В конфигурации объединены IPv4-подсети из официального списка Telegram, раздела Telegram в gist iamwildtuna и списка itdoginfo.

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

Состав

configs/
  wireguard/main-wg-eu.conf.example  # основной сервер
  wireguard/eu-wg0.conf.example      # новый EU WireGuard-сервер
  nftables/main.nft                 # маркировка и SNAT
  nftables/main-forward.nft         # вставка в существующую цепочку
  nftables/eu-nat.nft               # NAT на EU
  nftables/eu-forward.nft           # вставка в существующую цепочку
  sysctl/90-telegram-routing.conf   # IPv4 forwarding и loose rp_filter
docs/                              # установка, объяснение, проверки, откат
scripts/check-routing.sh            # чтение состояния основного сервера
scripts/test-telegram.py            # повторные TCP-подключения по IPv4

Границы решения

• Отбор идёт по IP назначения, а не имени приложения или домену. Любой трафик к указанным IPv4-подсетям пойдёт через EU; внешние сервисы, CDN и другие адреса автоматически не охватываются.
• IPv6 здесь не маршрутизируется через EU. Приложение должно использовать IPv4 для Telegram; удаление IPv6-адреса с wg-eu этого не обеспечивает.
• Docker bridge, Kubernetes и другие входные интерфейсы требуют дополнительных правил. Для host-контейнеров работает серверный OUTPUT.
• Это не kill switch: остановка wg-eu удаляет policy rule, и Telegram может пойти напрямую. Если интерфейс поднят, но peer недоступен, трафик обычно остаётся в неработающем туннеле.
• Таблица 200, приоритет 100 и mark 0x200 должны быть свободны. Пример использует всю метку целиком; при наличии других mark-based правил потребуется согласование.

Статус проверки

По исходному описанию работали серверный Telegram и клиенты wg0, были свежий handshake, успешный restart wg-eu и серия 20/20 TCP-подключений при MTU 1280. Это наблюдения исходной системы, а не результат тестирования этих шаблонов.

Полный reboot финальной исходной конфигурации не подтверждён. Шаблоны необходимо проверить на целевых Linux-серверах. MTU 1280 — исходная рабочая настройка, не универсальное требование. Причинная связь нестабильности с zapret/nfqws не установлена.

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