Фикс обнаружения и блокировки туннелей: разделение IP + маршрутизация sing-box

Дата: 7 апреля 2026
Источник: Dreaght — ntc.party, 2 апреля 2026
Контекст: Шпионские модули в РФ-приложениях сливают входной IP VPN-сервера → РКН блокирует сервер. Инфраструктурный фикс на уровне VPS.
Связанные заметки:

TL;DR
Модель угрозы
Почему sandbox и split-tunneling не спасают
Установка sing-box на сервере
Шаг 1: Купить второй IPv4 на VPS
Шаг 2: Разделить входной/выходной IP в sing-box
Шаг 3: WARP для неизвестного трафика
Шаг 4: Direct для доверенных CIDR
Шаг 5: Tor для геоблокированных сервисов
Шаг 6: I2P через VPS
Шаг 7: SSH через туннель
Шаг 8: DNS-разделение RU/Default
Итоговая архитектура
Рекомендация по транспорту
Fallback: если только 1 IPv4
Продвинутый уровень: множественные SNI и балансировка
Альтернатива WARP: домашний статический IP
Дополнительные улучшения
Контр-аргументы и известные риски
Чеклист

1. TL;DR

Шпионские модули в РФ-приложениях (MAX, Яндекс, ВК, и др.) обнаруживают входной IP VPN-сервера и сливают его РКН.
РКН через логи провайдеров + корреляционную атаку по времени блокирует сервер.
Минимальный фикс: купить второй IPv4, принимать VLESS на входном IP, а выходить в интернет через выходной IP.
Расширенная схема: маршрутизация на VPS через sing-box — WARP, direct, Tor, DNS-разделение.
Клиентские устройства должны быть «тупыми» — просто гнать весь трафик через VLESS на VPS.

2. Модель угрозы

Что подтверждено

MAX содержит шпионский модуль — разработчики встроили модуль слежки за VPN-пользователями с удалённым управлением, сделали его максимально трудноблокируемым.
РКН продавил закон о логах — провайдеры обязаны сливать данные (netflow и пр.), позволяющие однозначно идентифицировать абонентов по внутреннему NAT IP.
Active probing — РКН автоматически прозванивает обнаруженные входные IP VPN-серверов.

Как работает корреляционная атака

1. Шпион в приложении (MAX/VK/Яндекс) → запрос через свой exit IP → логируется на сервере
2. В то же временное окно другой шпион (другое приложение) → запрос через другой exit IP
3. У провайдера: из логов (netflow) → внутренний NAT IP пользователя
4. Два IP в одно время от одного NAT IP → один из них = VPN-туннель
5. Особенно легко при split-tunneling: два разных IP в одном временном окне

Три точки наблюдения (модель деанонимизации)

Для полной деанонимизации входного IP туннеля требуются минимум 2 из 3 точек:

#	Точка наблюдения	Статус
1	ISP (логи провайдера, netflow)	Доступ у РКН — закон принят
2	Хостер (VPS-провайдер)	Зависит от юрисдикции
3	CF / Конечные сервисы (шпионские модули)	Активно эксплуатируется

Пускание шпионов в DIRECT ослабляет схему сильнее, чем «палевные» объёмы трафика к одному IP. Шпион идёт через direct → точно спалитесь. Шпион не идёт через direct → достаточно хорошо.

Симптомы блокировки

Периодические обрывы соединений к self-hosted VPS.
ClientHello доходит, сервер не видит ACK, клиент ими долбится.
RST-пакеты от лица сервера к клиенту и от клиента к серверу (инжектируемые ТСПУ).
SSH тоже отваливается.
Блокировка входного IP со всех локаций сразу.

3. Почему sandbox и split-tunneling не спасают

Подход	Почему не работает
Sandbox / Knox / Shelter / Island	Loopback-интерфейс общий, шпион и так может обойти изоляцию
Per-app split-tunneling	Заставляет конечные устройства быть «умными» — рано или поздно ошибёшься. Архитектурно неправильно
Бан конкретных приложений	Тараканов по одному ловить — тупик. IP утекает сотней способов
Изоляция интерфейса сети (QubesOS-style)	Нереалистично на смартфонах, заведомо проигрышная борьба
IP-чекеры / блок шпионов	Невозможно отловить все каналы утечки, пролезут в правила маршрутизации
geoip:ru → WARP без разделения IP	IP-чекеры вне geoip:ru (ifconfig.me и др.) покажут реальный входной IP сервера. Правилами маршрутизации это не решить
Белые списки на роутере	CDN-сайты нельзя надёжно IP-листить. Шпион подкинет fake SNI (как Zapret) и обойдёт. Не работает для мобильных устройств без карманного OpenWRT
Отказ от TUN / ручные листы	Костыльная архитектура. Нет прозрачности, нет надёжности. Когда-нибудь ошибётесь — РКН увидит ошибку в логах

Правильный подход: инфраструктурный фикс на сервере. Клиенты — тупые, сервер — умный. Никакие костыли на роутере не сравнятся с простым разделением ingress/egress IPv4 + полное туннелирование.

4. Установка sing-box на сервере

sing-box и Xray — практически производные от v2ray. sing-box — следующий этап эволюции после Xray, конфиги единообразнее и понятнее.

# Arch Linux
yay -S sing-box
 
# Debian/Ubuntu
sudo apt install sing-box

Конфиг: /etc/sing-box/config.json — единственный файл конфигурации
Перезапуск: systemctl restart sing-box
Документация: sing-box.sagernet.org

Автор изначально использовал Xray на сервере + sing-box на клиенте, но ушёл полностью на sing-box — единообразнее.

5. Шаг 1: Купить второй IPv4 на VPS

В панели управления VPS → вкладка «Сеть» → купить дополнительный белый IPv4.
Проверить, что оба IP доступны:

ip a

Должны быть видны:

Входной IP (X.X.X.X) — на нём будет слушать sing-box. Нигде не светить!
Выходной IP (Y.Y.Y.Y) — на него bind outbound. Этот IP увидят шпионы, и это ОК.
IPv6 выходной (опционально, WARP предоставляет свой).

Настройка сетевого интерфейса (systemd-networkd)

Если нового IP нет в ip a после покупки — настройте вручную.

Файл /etc/systemd/network/20-eth0.network:

[Match]
Name=eth0
 
[Network]
# IPv4 — ПОРЯДОК ВАЖЕН: выходной IP первым (будет дефолтным)!
Address=Y.Y.Y.Y/24
Address=X.X.X.X/24
Gateway=Y.Y.Y.1
 
# IPv6
Address=YYYY:YYYY:Y:Y::YYYY/64
Gateway=YYYY:YYYY:Y:Y::1
 
DNS=1.1.1.1
DNS=2606:4700:4700::1111
IPv6AcceptRA=yes

Критично: X.X.X.X (входной) должен идти ПОСЛЕ Y.Y.Y.Y (выходной), чтобы выходной был дефолтным в системе!

Перезапустить:

systemctl restart systemd-networkd

6. Шаг 2: Разделить входной/выходной IP в sing-box

Конфиг /etc/sing-box/config.json:

Inbound — слушать ТОЛЬКО на входном IP

{
  "inbounds": [
    {
      "type": "vless",
      "tag": "reality-in",
      "listen": "X.X.X.X",
      "listen_port": 443,
      "...": "остальные параметры VLESS-Reality"
    }
  ]
}

Где X.X.X.X — входной IP, который нельзя нигде светить.

Outbound — выходить через выходной IP

{
  "outbounds": [
    {
      "type": "direct",
      "tag": "direct",
      "inet4_bind_address": "Y.Y.Y.Y"
    }
  ]
}

Где Y.Y.Y.Y — выходной IP. Его и увидят шпионы — но заблокировать по нему входной IP уже не смогут.

Подстраховка для других outbound

Если есть другие outbound (upstream прокси, WARP и т.д.) — добавить inet4_bind_address и туда:

{
  "type": "direct",
  "tag": "some-other-outbound",
  "inet4_bind_address": "Y.Y.Y.Y"
}

Это минимальный фикс. Его одного уже достаточно, чтобы закрыть основную уязвимость.

7. Шаг 3: WARP для неизвестного трафика

Зачем: выходной IP принадлежит ASN датацентра → сервисы типа Кинопоиск не откроются. WARP даёт «резидентный» IP.

Цепочка: Me → VLESS → WARP → Неизвестный трафик

Генерация конфига WARP

С VPS выполнить (инструкции из репозитория WARP-клиента):

wgcf register
wgcf generate

Endpoint в sing-box

{
  "endpoints": [
    {
      "type": "wireguard",
      "tag": "warp-ep",
      "system": false,
      "name": "wg0",
      "mtu": 1280,
      "address": [
        "172.16.0.2/32",
        "fd01:5ca1:ab1e:8d97:ef27:3f9b:aa5c:1234/128"
      ],
      "private_key": "ВАШ_ПРИВАТНЫЙ_КЛЮЧ=",
      "domain_resolver": "google",
      "peers": [
        {
          "address": "engage.cloudflareclient.com",
          "port": 2408,
          "public_key": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=",
          "allowed_ips": [
            "0.0.0.0/0",
            "::/0"
          ]
        }
      ]
    }
  ]
}

Замените address, private_key на значения из сгенерированного wgcf-profile.conf. public_key пира — стандартный CF WARP.

Риски WARP (предупреждение bolvan, автор Zapret)

С 15 апреля 2026 РФ-сервисам приказано банить IP известных VPN, и WARP будет первым. Вероятно лягут: mail.ru, VK, Yandex, Ozon, Avito и пр.

Русские сайты уже подвисают с WARP (возможно связано с AMS точкой входа).
Если РУ-сервисы перестанут открываться через WARP — пускать их в DIRECT через geosite-category-ru (см. шаг 8), а неизвестное через WARP. Или «шлите такие сервисы лесом, это их проблемы» (Dreaght).
На некоторых ASN (например Ростелеком) не проходит трафик к Cloudflare CDN — проблемы связности на промежуточных хопах.

WARP: ограничения

Не подходит для realtime (игры, VoIP) — ping jitter.
Хорош для вебсайтов благодаря CDN Cloudflare.
Для игр → пускать в DIRECT с VPS (игровые порты).

WARP = резидентский ASN

CloudFlare WARP считается резидентским IP. Даже Кинопоиск, который блокирует ASN датацентров, пускает через WARP. Госуслуги тоже открываются.

Selectel уже ограничил доступ к госуслугам со своих серверов (апрель 2026). Тренд расширится на другие хостеры. Без WARP или резидентского прокси — РФ-сервисы с VPS не откроются.

geosite для IP-чекеров

Существует отдельный geosite-список IP-чекеров. Их можно пустить в отдельный outbound (WARP/Tor), чтобы не светить реальный IP:

{
  "rule_set": ["geosite-category-ip-checker"],
  "action": "route",
  "outbound": "warp-ep"
}

8. Шаг 4: Direct для доверенных CIDR

Доверенные сервисы, на чьих CIDR нельзя разместить свой сервер — напрямую в direct без WARP.

Цепочка: Me → VLESS → Direct → Apple, Telegram, и др.

Route rules

{
  "route": {
    "rules": [
      {
        "rule_set": ["geoip-apple", "geoip-telegram"],
        "action": "route",
        "outbound": "direct"
      }
    ]
  }
}

Важно: используйте CIDR / geoip, а не geosite. Geosite работает через домены — шпион может подставить свой домен в тот же CIDR.

Что ещё пускать в DIRECT с VPS (уточнение из обсуждения)

Игровые порты + конкретные домены/списки (WARP не подходит для realtime из-за ping jitter)
YouTube — много трафика, не светит наружу IP, считается доверенным
BitTorrent — только с ПК, в DIRECT напрямую (максимизация bandwidth + юр. риски при проксировании)

WARP хорошо работает с вебсайтами (CDN), но не предназначен для realtime (игры, VoIP).

9. Шаг 5: Tor для геоблокированных сервисов

Некоторые сервисы (OpenAI, Habr, TikTok) блокируют IP датацентров и WARP. Решение — Tor или upstream прокси.

Цепочка: Me → VLESS → Tor → Геоблокированные сервисы

Установка Tor на VPS

# Debian/Ubuntu
sudo apt install tor
 
# Arch
sudo pacman -S tor

Tor запустится как SOCKS5 прокси на 127.0.0.1:9050.

Outbound в sing-box

{
  "type": "socks",
  "tag": "tor-out",
  "server": "127.0.0.1",
  "server_port": 9050
}

Route rule

{
  "rule_set": ["geosite-openai", "geosite-tiktok"],
  "action": "route",
  "outbound": "tor-out"
}

Альтернатива Tor: upstream ShadowSocks-прокси (с/без WARP). Современный Tor достаточно быстрый для большинства задач.

10. Шаг 6: I2P через VPS

Цепочка: Me → VLESS → I2P

I2P-роутер работает на самом VPS. Клиент не знает про I2P — просто гонит трафик через VLESS, а VPS маршрутизирует в I2P по правилам.

Установка I2P на VPS

# Debian/Ubuntu
sudo apt install i2pd
 
# Arch
sudo pacman -S i2pd

I2P-роутер запустится и создаст HTTP-прокси на 127.0.0.1:4444 и SOCKS на 127.0.0.1:4447.

Outbound в sing-box

{
  "type": "socks",
  "tag": "i2p-out",
  "server": "127.0.0.1",
  "server_port": 4447
}

Route rule (для .i2p доменов)

{
  "domain_suffix": [".i2p"],
  "action": "route",
  "outbound": "i2p-out"
}

11. Шаг 7: SSH через туннель

SSH слушает ТОЛЬКО на выходном IP → подключение автоматически идёт через VLESS.

Цепочка: Me → VLESS → SSH (к выходному IP Y.Y.Y.Y) → мой сервер

Настройка sshd

В /etc/ssh/sshd_config:

ListenAddress Y.Y.Y.Y

Пинг от входного IP к выходному IP в подсети хостера — околонулевой. Также можно подключаться через IPv6 если есть.

Аварийный доступ — через Tor (onion SSH)

Если туннель лёг:

Me → Tor bridges → Tor → SSH-over-onion → мой сервер

В /etc/tor/torrc:

HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 127.0.0.1:22

После перезапуска Tor — onion-адрес в /var/lib/tor/ssh/hostname.

Это single-point-of-failure бэкап. Мосты Tor можно получить через email, PGP, GitHub Actions бот.

12. Шаг 8: DNS-разделение RU/Default

Проблема: Google DNS не возвращает «правильные» IP для РФ-сервисов (госуслуги и т.д.). Решение — форсировать Yandex DNS для RU-сегмента на самом VPS.

DNS over VLESS:
  RU → Yandex DoU (unencrypted, на VPS)
  Default → Google DoT (encrypted)

Не заморачивайте конечные клиенты DNS-правилами — всё на сервере.

dns.rules — перенаправить RU-домены на Yandex

{
  "dns": {
    "servers": [
      {
        "tag": "google",
        "address": "tls://8.8.8.8",
        "detour": "direct"
      },
      {
        "tag": "local",
        "address": "77.88.8.8",
        "detour": "direct"
      }
    ],
    "rules": [
      {
        "rule_set": ["geosite-category-ru"],
        "server": "local"
      }
    ]
  }
}

route.rules — заставить RU-сервисы использовать Yandex DNS

{
  "route": {
    "rules": [
      {
        "rule_set": ["geosite-category-ru"],
        "action": "resolve",
        "server": "local"
      }
    ]
  }
}

rule_set — источник списка RU-доменов

{
  "route": {
    "rule_set": [
      {
        "tag": "geosite-category-ru",
        "type": "remote",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/runetfreedom/russia-v2ray-rules-dat/release/sing-box/rule-set-geosite/geosite-category-ru.srs"
      }
    ]
  }
}

13. Итоговая архитектура

Клиент (смартфон / ПК)
  │
  │  Весь трафик (кроме BitTorrent на ПК)
  │
  ▼
VLESS-XTLS-uTLS-REALITY-xudp-gRPC
  │  → входной IP X.X.X.X (скрытый)
  │
  ▼
VPS sing-box (маршрутизатор)
  │
  ├─► RU-сервисы (geosite-category-ru)
  │     DNS: Yandex 77.88.8.8
  │     → Direct (выходной IP Y.Y.Y.Y)
  │
  ├─► Доверенные CIDR (Apple, Telegram)
  │     → Direct (выходной IP Y.Y.Y.Y)
  │
  ├─► Неизвестный трафик (default)
  │     DNS: Google 8.8.8.8 DoT
  │     → WARP (CF WireGuard)
  │
  ├─► Геоблокированные (OpenAI, TikTok, Habr)
  │     → Tor SOCKS5 (localhost:9050)
  │       или ShadowSocks (с/без WARP)
  │
  ├─► I2P
  │     → I2P-роутер на самом VPS
  │
  ├─► SSH
  │     → к выходному IP Y.Y.Y.Y (через VLESS автоматически)
  │     → или по IPv6
  │     → аварийный: bridges → Tor → SSH-over-onion
  │
  └─► BitTorrent (только ПК)
        → DIRECT (напрямую, минуя VPN)

Клиент → DIRECT → BitTorrent

Проброс портов на входном IP

80/TCP  — на входном IP (X.X.X.X)
443/UDP — на входном IP (X.X.X.X)

SSH слушать только на выходном IPv4 (Y.Y.Y.Y).

Правила маршрутизации

Реализованы на сервере по:

geosite / geoip — rule_set
Портам — port matching
user_auth — дифференциация по пользователям

Принцип

Клиенты — тупые. Только гонят весь трафик через VLESS.
VPS — умный. Вся логика маршрутизации на сервере.
Входной IP скрыт. Шпионы видят только выходной IP (или WARP/Tor IP).
Выходной IPv4 — дефолтный в системе, входной IPv4 — дополнительный.
Принуждение DNS: Yandex DoU для RU-доменов, даже если клиент хотел другой DNS.

14. Рекомендация по транспорту

Протокол: VLESS-XTLS-uTLS-REALITY-xudp-gRPC

REALITY — SNI к домену в подсети хостера (не к публичному сайту).
gRPC транспорт — обязателен как минимум. Мультиплексирование gRPC предотвращает триггер «Сибирской блокировки» (корреляция по временным паттернам TCP-соединений).
После фикса (разделение IP) автор пользовался обычным TCP без мультиплексирования — проблемы исчезли. Но gRPC рекомендуется для подстраховки.

Аналог для Xray-core

В Xray-core аналог inet4_bind_address — параметр sendThrough в Outbounds:

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "sendThrough": "Y.Y.Y.Y",
      "settings": {}
    }
  ]
}

Документация: xtls.github.io — OutboundObject

15. Fallback: если только 1 IPv4

На нищих промо-тарифах хостеры дают только 1 адрес. В этом случае:

Ничего в direct напрямую с VPS не пускать. Весь трафик — только через WARP/Tor.

Входной и выходной IP совпадают, но шпионы увидят IP CloudFlare (WARP), а не реальный IP сервера. Менее надёжно, чем 2 IP, но лучше чем ничего.

16. Продвинутый уровень: множественные SNI и балансировка

Рекомендация NikeProPickMe из обсуждения.

Критическая ошибка большинства — 1 outbound с 1 SNI. Рекомендуется:

5 outbound с разными SNI — диверсификация TLS fingerprint
Промежуточная MSK-машина (VPS в РФ) — не подключается к единственному VLESS-серверу напрямую
Второй зарубежный сервер с dnsmasq, блокирующим .ru, .рф и yandex.net
Балансировка на MSK-машине: least_ping или round_robin между зарубежными серверами

Схема:

Клиент → MSK VPS (балансировщик)
                ├─► Зарубежный сервер 1 (SNI-A, SNI-B)
                └─► Зарубежный сервер 2 (SNI-C, SNI-D, SNI-E)
                       └─ dnsmasq: блок .ru/.рф/yandex.net

Это уровень параноидальной безопасности. Базовая схема с 2 IP уже закрывает основную уязвимость.

17. Альтернатива WARP: домашний статический IP как входная точка

Предложение knitabsorbed из обсуждения.

Если у вас белый (статический) домашний IP, его можно использовать как входную точку для RU-трафика вместо WARP:

Me → VLESS → VPS → (RU-трафик) → домашний IP → РФ-сервисы

Плюсы:

Не нужен WARP для РФ-сервисов — домашний IP = легитимный резидентский
Нет рисков бана WARP на госуслугах/сервисах

Минусы:

Не все ISP дают статические IP — схема не универсальна
Появляется новая точка обслуживания (домашний сервер/роутер)
Если триггеры корреляции по временным окнам в ТСПУ существуют — слив домашнего IP через direct (допущение)

Dreaght: «Резидентский прокси — да, это будет работать. Неудобно, появляется новая точка обслуживания.»

18. Дополнительные улучшения

XHTTP + разделение up/downstream

Возможно реализовать XHTTP с разделением upload/download потоков для дополнительной обфускации. Упоминается в обсуждении как перспективное направление.

DNS-бойкот вредоносных сервисов

Если сервис блокирует WARP или требует резидентский IP — вместо ослабления схемы (direct) добавить его в DNS-блок:

{
  "dns": {
    "rules": [
      {
        "domain_suffix": ["selectel-blocked-service.ru"],
        "action": "reject"
      }
    ]
  }
}

Принцип Dreaght: идти дальше, а не сдавать назад. Ослабление схемы ради удобства одного сервиса — компромисс не в вашу пользу.

19. Контр-аргументы и известные риски

Честный обзор критики из обсуждения — чтобы принимать решения с открытыми глазами.

«Один туннель = табличка “я использую VPN”» (aki)

Аргумент: Пользователь месяцами держит единственный постоянный коннект к одному IP, гонит сотни ГБ → для провайдера это VPN с вероятностью 99%. Не нужен ML, достаточно простого анализа метаданных. Пакет Яровой = все метаданные сессий хранятся 3 года.

Контр-аргумент (Dreaght): Помимо VPN, на один IP постоянно ходят:

Игры (постоянный коннект, большой трафик)
Стриминг (один IP, огромный трафик)
Торренты (один IP)
Синхронизация облачных дисков (один IP, огромный трафик)
Корпоративные туннели / домашние серверы — туннелирование не запрещено

Ложных срабатываний будет слишком много. Точечные ручные проверки не масштабируются.

Вывод: риск существует, но на данный момент никого за объёмы трафика к одному IP ещё не банили. Проблема шпионов реальнее.

CF WARP ≠ резидентский IP (aki)

Аргумент: WARP использует IP, принадлежащие ASN13335 (Cloudflare). Определяется как cdn/hosting. Сегодня банки и Кинопоиск пускают, завтра — могут перестать.

Контр-аргумент (Dreaght): Пока лично не сталкивался с ограничениями через WARP. Госуслуги, Яндекс, ВК — работают. Если перестанут — шлите такие сервисы лесом, или пускайте RU-сегмент через Yandex DNS + direct на VPS.

Вывод: WARP — не настоящий резидентский, но функционально пока работает как резидентский для РФ-сервисов. Заменить на домашний статический IP (§17) если начнут банить.

Риск бана всей подсети (SweetPotato)

Аргумент: Хостеры выделяют IP из одной подсети. РКН банит подсети целиком. Входной IP может попасть под бан, предназначенный для чужого выходного IP.

Вывод: реальный риск. Входной IP лучше брать из другой подсети, если хостер позволяет. Или у другого хостера.

CGNAT размывает корреляцию (Dreaght)

Внутренний NAT IP (CGNAT провайдера) может меняться, размывая связку SRC → DST. Общедоступные сети (Wi-Fi, коворкинги) ещё сильнее усложняют идентификацию. Не везде можно привязать конкретную сессию к конкретному человеку.

Zapret Wiki

Проводник

Недавно обновлено

Zapret 2 (Запрет GUI) — обход блокировок Discord и YouTube

download

zapret_not_working

Дорожная карта

Фикс обнаружения и блокировки туннелей: разделение IP + маршрутизация sing-box

Оглавление

1. TL;DR

2. Модель угрозы

Что подтверждено

Как работает корреляционная атака

Три точки наблюдения (модель деанонимизации)

Симптомы блокировки

3. Почему sandbox и split-tunneling не спасают

4. Установка sing-box на сервере

5. Шаг 1: Купить второй IPv4 на VPS

Настройка сетевого интерфейса (systemd-networkd)

6. Шаг 2: Разделить входной/выходной IP в sing-box

Inbound — слушать ТОЛЬКО на входном IP

Outbound — выходить через выходной IP

Подстраховка для других outbound

7. Шаг 3: WARP для неизвестного трафика

Генерация конфига WARP

Endpoint в sing-box

Риски WARP (предупреждение bolvan, автор Zapret)

WARP: ограничения

WARP = резидентский ASN

geosite для IP-чекеров

8. Шаг 4: Direct для доверенных CIDR

Route rules

Что ещё пускать в DIRECT с VPS (уточнение из обсуждения)

9. Шаг 5: Tor для геоблокированных сервисов

Установка Tor на VPS

Outbound в sing-box

Route rule

10. Шаг 6: I2P через VPS

Установка I2P на VPS

Outbound в sing-box

Route rule (для .i2p доменов)

11. Шаг 7: SSH через туннель

Настройка sshd

Аварийный доступ — через Tor (onion SSH)

12. Шаг 8: DNS-разделение RU/Default

dns.rules — перенаправить RU-домены на Yandex

route.rules — заставить RU-сервисы использовать Yandex DNS

rule_set — источник списка RU-доменов

13. Итоговая архитектура

Проброс портов на входном IP

Правила маршрутизации

Принцип

14. Рекомендация по транспорту

Аналог для Xray-core

15. Fallback: если только 1 IPv4

16. Продвинутый уровень: множественные SNI и балансировка

17. Альтернатива WARP: домашний статический IP как входная точка

18. Дополнительные улучшения

XHTTP + разделение up/downstream

DNS-бойкот вредоносных сервисов

19. Контр-аргументы и известные риски

«Один туннель = табличка “я использую VPN”» (aki)

CF WARP ≠ резидентский IP (aki)

Риск бана всей подсети (SweetPotato)

CGNAT размывает корреляцию (Dreaght)

20. Чеклист

Вид графа

Оглавление