# Фикс обнаружения и блокировки туннелей: разделение IP + маршрутизация sing-box **Дата:** 7 апреля 2026 **Источник:** [Dreaght — ntc.party](https://ntc.party/t/фикс-обнаружения-и-блокировки-туннелей-sing-box-маршрутизация/), 2 апреля 2026 **Контекст:** Шпионские модули в РФ-приложениях сливают входной IP VPN-сервера → РКН блокирует сервер. Инфраструктурный фикс на уровне VPS. **Связанные заметки:** - [Уязвимость VLESS-клиентов — SOCKS5 на localhost](VLESS-SOCKS5-vulnerability.md) - [Защита VPN от localhost-атаки](VLESS-localhost-protection-guide.md) - [Localhost-трекинг Meta/Яндекс](Localhost-tracking-Meta-Yandex-SOCKS5.md) --- ## Оглавление 1. [TL;DR](#1-tldr) 2. [Модель угрозы](#2-модель-угрозы) 3. [Почему sandbox и split-tunneling не спасают](#3-почему-sandbox-и-split-tunneling-не-спасают) 4. [Установка sing-box на сервере](#4-установка-sing-box-на-сервере) 5. [Шаг 1: Купить второй IPv4 на VPS](#5-шаг-1-купить-второй-ipv4-на-vps) 6. [Шаг 2: Разделить входной/выходной IP в sing-box](#6-шаг-2-разделить-входнойвыходной-ip-в-sing-box) 7. [Шаг 3: WARP для неизвестного трафика](#7-шаг-3-warp-для-неизвестного-трафика) 8. [Шаг 4: Direct для доверенных CIDR](#8-шаг-4-direct-для-доверенных-cidr) 9. [Шаг 5: Tor для геоблокированных сервисов](#9-шаг-5-tor-для-геоблокированных-сервисов) 10. [Шаг 6: I2P через VPS](#10-шаг-6-i2p-через-vps) 11. [Шаг 7: SSH через туннель](#11-шаг-7-ssh-через-туннель) 12. [Шаг 8: DNS-разделение RU/Default](#12-шаг-8-dns-разделение-rudefault) 13. [Итоговая архитектура](#13-итоговая-архитектура) 14. [Рекомендация по транспорту](#14-рекомендация-по-транспорту) 15. [Fallback: если только 1 IPv4](#15-fallback-если-только-1-ipv4) 16. [Продвинутый уровень: множественные SNI и балансировка](#16-продвинутый-уровень-множественные-sni-и-балансировка) 17. [Альтернатива WARP: домашний статический IP](#17-альтернатива-warp-домашний-статический-ip-как-входная-точка) 18. [Дополнительные улучшения](#18-дополнительные-улучшения) 19. [Контр-аргументы и известные риски](#19-контр-аргументы-и-известные-риски) 20. [Чеклист](#20-чеклист) --- ## 1. TL;DR - Шпионские модули в РФ-приложениях (MAX, Яндекс, ВК, и др.) обнаруживают входной IP VPN-сервера и сливают его РКН. - РКН через логи провайдеров + корреляционную атаку по времени блокирует сервер. - **Минимальный фикс:** купить второй IPv4, принимать VLESS на входном IP, а выходить в интернет через выходной IP. - **Расширенная схема:** маршрутизация на VPS через sing-box — WARP, direct, Tor, DNS-разделение. - Клиентские устройства должны быть «тупыми» — просто гнать весь трафик через VLESS на VPS. --- ## 2. Модель угрозы ### Что подтверждено 1. **MAX содержит шпионский модуль** — разработчики встроили модуль слежки за VPN-пользователями с удалённым управлением, сделали его максимально трудноблокируемым. 2. **РКН продавил закон о логах** — провайдеры обязаны сливать данные (netflow и пр.), позволяющие однозначно идентифицировать абонентов по внутреннему NAT IP. 3. **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, конфиги единообразнее и понятнее. ```bash # 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](https://sing-box.sagernet.org/) > Автор изначально использовал Xray на сервере + sing-box на клиенте, но ушёл полностью на sing-box — единообразнее. --- ## 5. Шаг 1: Купить второй IPv4 на VPS 1. В панели управления VPS → вкладка **«Сеть»** → купить дополнительный белый IPv4. 2. Проверить, что оба IP доступны: ```bash 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`: ```ini [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` (выходной), чтобы выходной был дефолтным в системе! Перезапустить: ```bash systemctl restart systemd-networkd ``` --- ## 6. Шаг 2: Разделить входной/выходной IP в sing-box Конфиг `/etc/sing-box/config.json`: ### Inbound — слушать ТОЛЬКО на входном IP ```json { "inbounds": [ { "type": "vless", "tag": "reality-in", "listen": "X.X.X.X", "listen_port": 443, "...": "остальные параметры VLESS-Reality" } ] } ``` > Где `X.X.X.X` — **входной IP**, который нельзя нигде светить. ### Outbound — выходить через выходной IP ```json { "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` и туда: ```json { "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-клиента](https://github.com/ViRb3/wgcf)): ```bash wgcf register wgcf generate ``` ### Endpoint в sing-box ```json { "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: ```json { "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 ```json { "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 ```bash # Debian/Ubuntu sudo apt install tor # Arch sudo pacman -S tor ``` Tor запустится как SOCKS5 прокси на `127.0.0.1:9050`. ### Outbound в sing-box ```json { "type": "socks", "tag": "tor-out", "server": "127.0.0.1", "server_port": 9050 } ``` ### Route rule ```json { "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 ```bash # 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 ```json { "type": "socks", "tag": "i2p-out", "server": "127.0.0.1", "server_port": 4447 } ``` ### Route rule (для .i2p доменов) ```json { "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 ```json { "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 ```json { "route": { "rules": [ { "rule_set": ["geosite-category-ru"], "action": "resolve", "server": "local" } ] } } ``` ### rule_set — источник списка RU-доменов ```json { "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: ```json { "outbounds": [ { "tag": "direct", "protocol": "freedom", "sendThrough": "Y.Y.Y.Y", "settings": {} } ] } ``` > Документация: [xtls.github.io — OutboundObject](https://xtls.github.io/config/outbound.html) --- ## 15. Fallback: если только 1 IPv4 На нищих промо-тарифах хостеры дают только 1 адрес. В этом случае: > **Ничего в direct напрямую с VPS не пускать.** Весь трафик — только через WARP/Tor. Входной и выходной IP совпадают, но шпионы увидят IP CloudFlare (WARP), а не реальный IP сервера. Менее надёжно, чем 2 IP, но лучше чем ничего. --- ## 16. Продвинутый уровень: множественные SNI и балансировка > Рекомендация NikeProPickMe из обсуждения. Критическая ошибка большинства — **1 outbound с 1 SNI**. Рекомендуется: 1. **5 outbound с разными SNI** — диверсификация TLS fingerprint 2. **Промежуточная MSK-машина** (VPS в РФ) — не подключается к единственному VLESS-серверу напрямую 3. **Второй зарубежный сервер** с `dnsmasq`, блокирующим `.ru`, `.рф` и `yandex.net` 4. **Балансировка** на 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-блок: ```json { "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, коворкинги) ещё сильнее усложняют идентификацию. Не везде можно привязать конкретную сессию к конкретному человеку. --- ## 20. Чеклист - [ ] Куплен второй IPv4 на VPS - [ ] Оба IP видны в `ip a` - [ ] В systemd-networkd: выходной IP **первым**, входной — вторым - [ ] `inbounds.listen` = входной IP (X.X.X.X) - [ ] `outbounds.direct.inet4_bind_address` = выходной IP (Y.Y.Y.Y) - [ ] Все прочие outbound тоже с `inet4_bind_address` = Y.Y.Y.Y - [ ] Входной IP не фигурирует ни в каких outbound - [ ] Проброс портов: 80/TCP и 443/UDP на входном IP - [ ] SSH слушает **только** на выходном IPv4 - [ ] WARP endpoint настроен (ключи сгенерированы с VPS) - [ ] I2P-роутер (i2pd) запущен на VPS - [ ] Tor демон запущен на VPS - [ ] Tor onion для аварийного SSH доступа - [ ] DNS: RU → Yandex, Default → Google DoT - [ ] Route rules: geosite-category-ru → resolve через local DNS - [ ] Маршрутизация по geosite/geoip/портам/user_auth — на сервере - [ ] Клиенты настроены гнать ВЕСЬ трафик через VLESS (кроме BitTorrent на ПК) - [ ] Проверить: `curl ifconfig.me` с клиента → показывает WARP/выходной IP, **НЕ** входной - [ ] Проверить: госуслуги и РФ-сервисы открываются через туннель