todo/tunnel-detection-fix-split-ip.md
loop-uh baf0091fa3
Some checks failed
Published content check / validate (push) Failing after 17s
git.zapret.moe → git2.zapret.moe во всём хранилище, защита от возврата старых имён
git.zapret.moe в России заблокирован по имени, как и wiki.zapret.moe. Ссылки
на Forgejo во всех заметках, футерах, wizard.html и главной заменены на
git2.zapret.moe (включая закодированные адреса значков shields.io).

Какое имя рабочее, теперь решают реестры хоста /etc/zapret-*-domains.conf через
zapret-site-names: pre-commit хук vault отклоняет добавленные строки с
заблокированным именем, сборка Quartz сама переводит ссылки и baseUrl на
рабочие имена. Правило в AGENTS.md переписано под этот механизм.

scripts/wiki-stats.py: переходы с любых имён вики и git (wikiN, gitN) больше
не считаются внешними сайтами. content-check: проверка зеркал сторонних
проектов узнаёт любое имя git.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-24 15:51:32 -04:00

345 lines
46 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
date: 2026-04-07
fact_checked: 2026-10-14
tags:
- vpn
- sing-box
- vless
- reality
- warp
- tor
- детект-vpn
aliases:
- Разделение входного и выходного IP VPN
- Второй IPv4 на VPS для VPN
- Как скрыть IP VPN-сервера от приложений
- Почему блокируют мой VPS после MAX
- inet4_bind_address sing-box
- sendThrough Xray выходной IP
- legacy DNS server formats removed in sing-box 1.14.0
- Фикс обнаружения и блокировки туннелей
description: "Как не дать приложениям «слить» адрес вашего VPN-сервера: второй IPv4 на VPS, разделение входа и выхода в sing-box 1.14, WARP, Tor и DNS."
image: attachments/tunnel-split-ip-scheme.png
link: https://ntc.party/t/23690
---
> [!mirror] Резервное зеркало
> Актуальная версия этой страницы — на основной вики: [wiki2.zapret.moe/tunnel-detection-fix-split-ip](https://wiki2.zapret.moe/tunnel-detection-fix-split-ip)
# 🧩 Разделение входного и выходного IP на VPS: как не дать приложениям «слить» адрес VPN-сервера (sing-box, 2026)
![[tunnel-split-ip-scheme.png]]
> [!info] О чём заметка
> Российские приложения в 2026 году массово проверяют, включён ли у пользователя VPN, а некоторые узнают и публичный адрес, с которого он выходит в интернет. Если это адрес вашего собственного VPN-сервера, его можно заблокировать. Заметка разбирает защиту на стороне сервера: купить второй IPv4, принимать туннель на одном адресе, а выходить в интернет с другого. Схему в апреле 2026 года [предложил участник форума ntc.party под ником Dreaght](https://ntc.party/t/23690); здесь она перепроверена и обновлена под sing-box 1.14. В конце — вариант с промежуточным сервером в России и известные риски.
> [!warning] Что проверено, а что нет
> Конфиг в этой заметке прогнан через `sing-box check` версии 1.14.3 и проходит проверку. Модель угрозы проверена хуже: то, что приложения проверяют VPN и что Роскомнадзор собирает IP-адреса абонентского оборудования, подтверждено исследованиями и документами; а то, что блокировки серверов идут именно через утечку адреса из приложений и сопоставление логов по времени, — версия участников форума, публичных измерений нет. Исходная тема на ntc.party из России и с части хостингов открывается только по IPv6 или через Tor.
## TL;DR
- **Проблема.** Приложение на телефоне, отправив запрос через ваш VPN, узнаёт адрес, с которого запрос вышел в интернет. Если это тот же адрес, к которому подключается туннель, его можно передать дальше и заблокировать.
- **Минимальное решение.** Второй IPv4 на том же VPS. Туннель принимается на адресе X, весь исходящий трафик уходит с адреса Y. В sing-box это `listen` у входа и `inet4_bind_address` у каждого выхода, включая DNS и WARP.
- **Расширение.** Сервер сам решает, куда отправить трафик: неизвестное — через Cloudflare WARP, IP-чекеры — тоже через WARP, отдельные сервисы — через Tor. Клиентам не нужны сложные правила.
- **Ограничения.** WARP — не «резидентский» адрес, а хостинг Cloudflare. Многие российские сайты (VK, Сбер, Т-Банк, Ozon, Авито) с зарубежного адреса дата-центра не открываются вовсе.
- **Что исправлено.** Прежняя версия гайда в октябре 2026 года не запускалась на sing-box 1.14 и содержала несовместимый транспорт, несуществующие наборы правил и нерабочий аварийный SSH. Всё это заменено.
## Откуда угроза: что известно о слежке приложений за VPN
Самый обсуждаемый случай — мессенджер MAX. В марте 2026 года автор разбора на Хабре [декомпилировал клиент](https://habr.com/ru/articles/1006666/) и описал модуль, который отправляет на сервер признак включённого VPN, тип сети, оператора и публичный IP, полученный через внешние сервисы определения адреса, а также проверяет доступность Telegram и WhatsApp. Модуль включается флагом, который приходит с сервера. Автор назвал это шпионским модулем с удалённым управлением; MAX [это отрицает](https://novayagazeta.eu/articles/2026/03/05/v-max-obnaruzhili-shpionskii-modul-kotoryi-otslezhivaet-ispolzovanie-vpn-news) и говорит, что решения нужны для качества звонков и уведомлений. Корректно сказать так: проверка VPN и передача адреса подтверждены разбором кода, а цель модуля — интерпретация исследователя.
MAX не единственный. В апреле эксперты RKS Global [проверили 30 российских Android-приложений](https://meduza.io/feature/2026/04/11/rossiyskie-prilozheniya-dlya-android-sledyat-za-vami-po-suti-eto-polnotsennye-shpionskie-programmy) и нашли поиск VPN в 22 из них; по данным «Новой газеты Европа», [19 из этих 22 отправляют результат на свои серверы](https://novayagazeta.eu/articles/2026/04/15/pokhozhe-vy-ispolzuete-vpn). Отдельно ещё в марте министр цифрового развития Максут Шадаев на совещании [попросил крупнейшие сервисы](https://zona.media/news/2026/04/02/vpn-15) к 15 апреля ограничить доступ пользователям с включённым VPN. Это было устное требование, а не опубликованный приказ, и ограничения после 15 апреля оказались выборочными: с одними серверами сервис не открывался, с другими открывался. Как именно приложения добираются до адреса через локальные прокси, разобрано в заметках [[Localhost-tracking-Meta-Yandex-SOCKS5|о localhost-трекинге]] и [[VLESS-SOCKS5-vulnerability|об уязвимости SOCKS5 на localhost]].
Со стороны государства есть ещё один документ. [Приказ Роскомнадзора № 51 от 28 февраля 2025 года](https://te-st.org/2026/05/27/collectip/) обязывает операторов связи передавать сведения об IP-адресах абонентского оборудования с привязкой к местности; в 2026 году ведомство штрафовало операторов, которые этого не делали. Сам Роскомнадзор говорит, что IP-адреса конкретных людей не собирает. В исходной теме участники называли это «законом о логах с netflow»; такого закона найти не удалось, ближайший реальный акт — этот приказ.
Дальше идут версии. Участники форума предполагают, что адрес, «слитый» приложением, сопоставляют с логами провайдера по времени и так находят вход туннеля. Публичных измерений, подтверждающих такие блокировки, нет. Подтверждено другое: с августа 2026 года, по данным «Теплицы социальных технологий», Роскомнадзор [блокирует целые подсети хостеров](https://te-st.org/2026/09/30/vlessmore/), где много VPN-серверов, а ТСПУ обрывает соединения поддельными пакетами RST. Как выглядят такие обрывы и чем их проверять, — в обзоре [[DPI/tspu-inspectors-checkers-2026|чекеров блокировок]].
Проще говоря: приложения действительно узнают, что вы в VPN, и часто — с какого адреса вы вышли в интернет. Как именно этот адрес превращается в блокировку, публично не доказано. Но если у вашего сервера один адрес на вход и выход, вы отдаёте приложениям именно тот адрес, от которого зависит работа туннеля.
## Идея: развести вход и выход на два адреса
У обычного VPS один публичный IPv4. Клиент подключается к нему, и с него же сервер ходит в интернет от имени клиента. Любой сервис, который вы открыли через VPN, видит этот адрес, а значит, его видит и IP-чекер внутри приложения.
Если купить у хостера второй адрес, роли можно разделить. На адресе X сервер только принимает туннель: с него в интернет не уходит ни одного пакета. Все исходящие соединения сервер открывает с адреса Y. Приложение на телефоне, проверив свой внешний адрес, увидит Y. Заблокировать Y можно, но клиенты подключаются к X, и туннель продолжит работать. Схема не скрывает сам факт VPN — провайдер по-прежнему видит долгое шифрованное соединение с зарубежным адресом. Она защищает только адрес входа.
Почему не решать это на телефоне. Песочницы вроде Shelter или Island не изолируют сетевой интерфейс loopback, через который приложения добираются до локального прокси. Раздельное туннелирование по приложениям требует, чтобы каждое устройство было настроено без ошибок, и одна ошибка выдаёт адрес. Списки «плохих» приложений бесконечны. Поэтому автор схемы предлагает обратный подход: клиенты просто отправляют весь трафик в туннель, а вся логика живёт на сервере. Защита клиентов от localhost-атаки остаётся нужной сама по себе — она разобрана в [[VLESS-localhost-protection-guide|практическом руководстве]].
## Шаг 1. Второй IPv4 и сеть сервера
Второй адрес покупается в панели хостера. Лучше брать его из другой подсети или вообще у другого хостера: если Роскомнадзор заблокирует подсеть выходного адреса целиком, вход не должен попасть под ту же блокировку. Ниже в примерах X — `203.0.113.10` (вход), Y — `198.51.100.20` (выход); это адреса из диапазонов для документации, подставьте свои.
Важно, чтобы системные программы сервера (обновления, Tor, DNS) по умолчанию тоже выходили с Y. В прежней версии гайда это пытались сделать порядком строк `Address=` в настройках systemd-networkd, но это ненадёжно: порядок нигде не гарантирован. Правильный способ — явно указать адрес источника в маршруте по умолчанию через `PreferredSource=`, который описан в справке `systemd.network`:
```ini
# /etc/systemd/network/20-eth0.network
[Match]
Name=eth0
[Network]
Address=198.51.100.20/24
Address=203.0.113.10/24
[Route]
Gateway=198.51.100.1
PreferredSource=198.51.100.20
```
Если адреса из разных подсетей, ответы с X должны уходить через шлюз своей подсети — для этого нужна отдельная таблица маршрутизации (`[RoutingPolicyRule]` с `From=203.0.113.10/32`). Проверка: `ip route get 1.1.1.1` должен показать `src 198.51.100.20`.
## Шаг 2. sing-box на сервере
sing-box — ядро прокси от проекта SagerNet, родственное Xray; обзор форков и протоколов есть в [[sing-box/sing-box|разделе о sing-box]]. В штатных репозиториях Debian и Ubuntu его нет, поэтому команда `apt install sing-box` из прежней версии гайда не работает. Официальный способ установки — [репозиторий SagerNet](https://sing-box.sagernet.org/installation/package-manager/):
```bash
sudo mkdir -p /etc/apt/keyrings
sudo curl -fsSL https://sing-box.app/gpg.key -o /etc/apt/keyrings/sagernet.asc
sudo chmod a+r /etc/apt/keyrings/sagernet.asc
echo 'Types: deb
URIs: https://deb.sagernet.org/
Suites: *
Components: *
Enabled: yes
Signed-By: /etc/apt/keyrings/sagernet.asc' | sudo tee /etc/apt/sources.list.d/sagernet.sources
sudo apt-get update && sudo apt-get install sing-box
```
На Arch Linux пакет есть в AUR (`yay -S sing-box`). Конфиг лежит в `/etc/sing-box/config.json`, перезапуск — `systemctl restart sing-box`. Перед каждым перезапуском проверяйте конфиг командой `sing-box check -c /etc/sing-box/config.json`.
Главная правка — две строки. Вход слушает только адрес X:
```json
{ "type": "vless", "tag": "reality-in", "listen": "203.0.113.10", "listen_port": 443 }
```
Каждый выход привязан к адресу Y через поле `inet4_bind_address`. Это касается не только основного выхода `direct`, но и всего, что открывает соединения наружу: WARP-endpoint и DNS-серверов. В прежней версии гайда WARP и DNS остались без привязки, и их пакеты могли уходить с системного адреса.
```json
{ "type": "direct", "tag": "direct", "inet4_bind_address": "198.51.100.20" }
```
Проще говоря: `listen` говорит серверу, где ждать клиентов, а `inet4_bind_address` — откуда выходить в интернет. Если у какого-то выхода второго поля нет, этот выход может «засветить» вход.
## Шаг 3. Куда отправлять трафик
Сервер решает, через какой выход пустить каждое соединение. Чтобы правила по доменам работали, sing-box должен распознать домен в самом соединении: начиная с версии 1.13 это делает отдельное правило `{"action": "sniff"}`, а не настройка входа. Без него правила вида «российские домены — сюда» срабатывают, только если клиент сам передал домен.
![[tunnel-split-ip-routes.png]]
### Неизвестный трафик и IP-чекеры — через Cloudflare WARP
WARP — бесплатный VPN Cloudflare на основе WireGuard. Если поднять его на сервере как выход, сайты увидят не адрес Y, а адрес Cloudflare. Профиль генерируется утилитой [wgcf](https://github.com/ViRb3/wgcf): `wgcf register`, затем `wgcf generate`, затем `wgcf trace` для проверки. Ключ, адреса туннеля, адрес и ключ сервера Cloudflare берите из созданного файла `wgcf-profile.conf`, а не из чужих примеров: свежие версии wgcf получают их от Cloudflare при регистрации.
В прежней версии гайда WARP назывался «резидентским» адресом, которому доверяют российские сервисы. Это не так: IP-базы вроде ipinfo [относят сеть Cloudflare к хостингу](https://ipinfo.io/AS13335) и ставят ей метку VPN. В условиях использования WARP Cloudflare [прямо пишет](https://www.cloudflare.com/application/terms/), что приложение не предназначено скрывать вашу личность и что компания может ограничить или приостановить сервис по своему усмотрению. Работает ли через WARP конкретный российский сервис, зависит от того, через какую площадку Cloudflare вы выходите; на ntc.party пользователи сообщали, что через московскую площадку сайты блокировали как VPN, а через хельсинкскую открывали. Для зарубежного сервера выход обычно европейский.
IP-чекеры — сервисы, которые сообщают приложению его внешний адрес, — стоит явно отправить через WARP. Готовый набор доменов называется `geosite-category-ip-geo-detect`; набора `geosite-category-ip-checker` из прежней версии гайда не существует.
### Российские сайты — напрямую с адреса Y
Российские домены сервер резолвит через DNS «Яндекса» и отправляет напрямую с адреса Y. У этого правила есть серьёзное ограничение: многие российские сервисы не пускают зарубежные адреса дата-центров. При проверке 14 октября 2026 года с европейского сервера соединение обрывалось у VK, Сбербанка, Т-Банка, Ozon, Авито и РЖД, а Госуслуги, «Яндекс», Mail.ru и Хабр открывались. Если нужные вам сервисы в первом списке, вариантов три: смириться, отправлять российский трафик с телефона мимо VPN (и тогда приложения увидят ваш домашний адрес, но не адрес сервера) или использовать промежуточный сервер в России, о котором ниже.
### Telegram и Apple — напрямую по диапазонам адресов
Сервисы, в сети которых нельзя разместить свой сервер, можно пускать напрямую по их адресам. Правило должно опираться на диапазоны адресов, а не на домены: домен в соединении подставить легко. Для Telegram есть готовый набор `geoip-telegram`; набора `geoip-apple`, который использовала прежняя версия гайда, нет ни в одном из популярных репозиториев, поэтому диапазон Apple `17.0.0.0/8` задаётся вручную.
### Отдельные сервисы — через Tor
Tor на сервере запускается как обычный клиент и открывает SOCKS-прокси на `127.0.0.1:9050`. Чтобы сам Tor выходил в интернет с адреса Y, в `/etc/tor/torrc` нужна строка `OutboundBindAddress 198.51.100.20`, описанная в [справке Tor](https://2019.www.torproject.org/docs/tor-manual.html.en). Tor полезен для сервисов, которые режут адреса дата-центров, но сам по себе не волшебный: при проверке в октябре 2026 года ChatGPT через пять разных выходов Tor показывал проверку Cloudflare, а Хабр закрыл доступ с четырёх выходов из шести.
> [!note] I2P — по желанию
> Если нужны сайты в сети I2P, на сервере можно поднять i2pd с SOCKS-прокси на `127.0.0.1:4447`. По умолчанию i2pd [пропускает через себя чужой транзитный трафик](https://docs.i2pd.website/en/latest/user-guide/configuration/) и публикует свой адрес; на VPS стоит включить `notransit = true` и задать `address4` равным выходному адресу Y.
## Полный конфиг
Конфиг ниже проверен командой `sing-box check` на версии 1.14.3 и проходит её; конфиг из прежней версии гайда на той же версии завершался ошибкой «legacy DNS server formats… removed in sing-box 1.14.0». Замените адреса, ключи и имя маскировочного сайта на свои. Ключи REALITY генерируются командой `sing-box generate reality-keypair`, UUID — `sing-box generate uuid`.
```json
{
"log": { "level": "warn" },
"dns": {
"servers": [
{ "type": "tls", "tag": "google", "server": "8.8.8.8", "detour": "direct" },
{ "type": "udp", "tag": "yandex", "server": "77.88.8.8", "detour": "direct" }
],
"rules": [
{ "rule_set": ["geosite-category-ru"], "action": "route", "server": "yandex" }
],
"final": "google"
},
"http_clients": [{ "tag": "rs-http", "detour": "direct" }],
"inbounds": [
{
"type": "vless", "tag": "reality-in",
"listen": "203.0.113.10", "listen_port": 443,
"users": [{ "uuid": "<UUID>", "flow": "xtls-rprx-vision" }],
"tls": {
"enabled": true, "server_name": "<маскировочный-сайт>",
"reality": {
"enabled": true,
"handshake": { "server": "<маскировочный-сайт>", "server_port": 443 },
"private_key": "<приватный ключ REALITY>",
"short_id": ["<short_id>"]
}
}
}
],
"endpoints": [
{
"type": "wireguard", "tag": "warp-ep", "system": false, "mtu": 1280,
"address": ["<адрес IPv4 из wgcf-profile.conf>", "<адрес IPv6 из wgcf-profile.conf>"],
"private_key": "<PrivateKey из wgcf-profile.conf>",
"inet4_bind_address": "198.51.100.20",
"peers": [
{
"address": "<Endpoint из wgcf-profile.conf>", "port": 2408,
"public_key": "<PublicKey из wgcf-profile.conf>",
"allowed_ips": ["0.0.0.0/0", "::/0"]
}
]
}
],
"outbounds": [
{ "type": "direct", "tag": "direct", "inet4_bind_address": "198.51.100.20" },
{ "type": "socks", "tag": "tor-out", "server": "127.0.0.1", "server_port": 9050 },
{ "type": "socks", "tag": "i2p-out", "server": "127.0.0.1", "server_port": 4447 }
],
"route": {
"default_http_client": "rs-http",
"default_domain_resolver": "google",
"final": "warp-ep",
"rule_set": [
{ "tag": "geosite-category-ru", "type": "remote", "format": "binary", "update_interval": "7d",
"url": "https://raw.githubusercontent.com/runetfreedom/russia-v2ray-rules-dat/release/sing-box/rule-set-geosite/geosite-category-ru.srs" },
{ "tag": "geoip-telegram", "type": "remote", "format": "binary",
"url": "https://raw.githubusercontent.com/runetfreedom/russia-v2ray-rules-dat/release/sing-box/rule-set-geoip/geoip-telegram.srs" },
{ "tag": "geosite-openai", "type": "remote", "format": "binary",
"url": "https://raw.githubusercontent.com/SagerNet/sing-geosite/rule-set/geosite-openai.srs" },
{ "tag": "geosite-tiktok", "type": "remote", "format": "binary",
"url": "https://raw.githubusercontent.com/SagerNet/sing-geosite/rule-set/geosite-tiktok.srs" },
{ "tag": "geosite-category-ip-geo-detect", "type": "remote", "format": "binary",
"url": "https://raw.githubusercontent.com/SagerNet/sing-geosite/rule-set/geosite-category-ip-geo-detect.srs" },
{ "tag": "apple-cidr", "type": "inline", "rules": [{ "ip_cidr": ["17.0.0.0/8"] }] }
],
"rules": [
{ "action": "sniff" },
{ "protocol": "dns", "action": "hijack-dns" },
{ "rule_set": ["geosite-category-ru"], "action": "resolve", "server": "yandex" },
{ "rule_set": ["geosite-category-ru", "geoip-telegram", "apple-cidr"], "action": "route", "outbound": "direct" },
{ "rule_set": ["geosite-category-ip-geo-detect"], "action": "route", "outbound": "warp-ep" },
{ "rule_set": ["geosite-openai", "geosite-tiktok"], "action": "route", "outbound": "tor-out" },
{ "domain_suffix": [".i2p"], "action": "route", "outbound": "i2p-out" }
]
}
}
```
Что изменилось по сравнению с прежней версией гайда:
- DNS-серверы описаны в новом формате (`"type": "tls", "server": "8.8.8.8"`): старый формат `"address": "tls://8.8.8.8"` [устарел в 1.12 и удалён в 1.14](https://sing-box.sagernet.org/deprecated/). У обоих DNS-серверов `detour: "direct"`, иначе запросы уходили бы не с адреса Y.
- Добавлены `route.default_domain_resolver` (без него конфиг с доменными адресами не проходит проверку) и `http_clients` для загрузки наборов правил: старое поле `download_detour` устарело в 1.14.
- У WARP-endpoint есть `inet4_bind_address`, а поле `name` убрано: оно нужно только для системного интерфейса.
- Неизвестный трафик (`final`) уходит через WARP; если вы хотите выходить с адреса Y, замените на `direct`.
![[tunnel-split-ip-fixes.png]]
## Транспорт: Vision поверх TCP, без gRPC
В прежней версии гайда рекомендовался транспорт «VLESS-XTLS-uTLS-REALITY-xudp-gRPC». Такое сочетание не работает: по [документации Xray](https://xtls.github.io/en/config/outbounds/vless.html) режим XTLS Vision доступен только поверх TCP с TLS или REALITY, а с gRPC его не используют. В sing-box `xudp` и так включён по умолчанию. Сам gRPC в Xray помечен как устаревший: разработчики [рекомендуют переходить на XHTTP](https://xtls.github.io/en/config/transports/grpc.html), но XHTTP есть только в Xray, в sing-box его нет. Практический выбор для схемы из этой заметки — VLESS + Vision + REALITY поверх TCP; подробнее о слоях стека — в [[xray/vless-stack-map|карте VLESS-стека]], о REALITY — в [[xray/reality|отдельной заметке]].
Автор исходной схемы советовал gRPC ради мультиплексирования против так называемой «сибирской блокировки». Её [описали на Хабре](https://habr.com/ru/articles/1044396/): соединения замораживаются на 120 секунд, если к одному SNI за минуту было больше трёх быстрых параллельных попыток TLS-подключения при подозрительной подсети и подозрительном отпечатке клиента. Отсюда разумный вывод — открывать меньше параллельных соединений, но это не делает gRPC обязательным. Разбор механизма есть в [[VLESS/dpi-tls-june-2026|заметке о «заморозке» VLESS+REALITY]].
На входном адресе X должны быть открыты только порты, которые слушает вход: для VLESS+REALITY это 443/TCP. Пункт прежней версии «проброс 80/TCP и 443/UDP» к этой схеме не относится: 443/UDP нужен только для протоколов на QUIC вроде Hysteria 2, а 80/TCP — для получения сертификата или сайта-заглушки.
### То же самое в Xray
В Xray аналог `inet4_bind_address` — поле [`sendThrough` у выхода](https://xtls.github.io/en/config/outbound.html): `"sendThrough": "198.51.100.20"`. Вход ограничивается полем `listen`. WARP в Xray подключается выходом `wireguard`; пример есть в [[VLESS-localhost-protection-guide|руководстве по защите от localhost-атаки]].
## Доступ к серверу по SSH
SSH стоит слушать только на выходном адресе Y: `ListenAddress 198.51.100.20` в `/etc/ssh/sshd_config`. Тогда подключение к серверу из дома идёт через тот же туннель, а входной адрес не связан с вашим домашним. На Ubuntu с сокет-активацией SSH адрес задаётся в `ssh.socket`, а не в `sshd_config`.
Для аварийного доступа, если туннель лёг, можно поднять SSH как скрытый сервис Tor. В прежней версии гайда здесь была ошибка: сервис указывал на `127.0.0.1:22`, где sshd при такой настройке не слушает. Правильно:
```
# /etc/tor/torrc
HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 198.51.100.20:22
```
Onion-адрес появится в `/var/lib/tor/ssh/hostname`. Подключаться к нему из России придётся через мосты Tor.
## Если адрес только один
На дешёвых тарифах хостер даёт один IPv4. Тогда развести вход и выход нельзя, и остаётся одно правило: ничего не выпускать напрямую с сервера. Весь трафик, включая российский, — через WARP или Tor (`final` и все правила маршрутизации без `direct`). Приложения увидят адрес Cloudflare, а не ваш. Это слабее схемы с двумя адресами: если WARP перестанет работать, сервер начнёт выходить со своего единственного адреса.
## Вариант с промежуточным сервером в России
Многие строят цепочку из двух серверов: телефон подключается к VPS в России, а тот передаёт трафик на зарубежный сервер. Зачем это делают: соединение с российским адресом реже режут фильтры, при отключениях мобильного интернета российские облака иногда попадают в «белый список», а если введут плату за зарубежный мобильный трафик, соединение с российским сервером оператор посчитает внутренним. Подробно этот довод разобран в [[DPI/paid-international-traffic-5g-50gb-october-2026|заметке о плате за зарубежный трафик в 5G]]. В исходной теме участник предлагал усилить такую цепочку: на российском сервере балансировать нагрузку между двумя зарубежными серверами с разными SNI.
Схема разделения адресов к этой цепочке применима так же: у зарубежного сервера вход принимает только соединения от российского, а выход идёт с другого адреса. Но у самой цепочки свои риски, и с 2026 года они растут. Российский хостер обязан выполнять требования ведомств, и сервер обхода на нём [[DPI/mincifry-whitelist-vpn-hosting-august-2026|под ударом первым]]: Минцифры обсуждает с хостерами проверку адресов из белого списка, а 1 октября 2026 года [опубликовало проект](https://zona.media/news/2026/10/01/vpn), по которому владельцев VPN для обхода блокировок предлагают на год лишать доступа к российским хостингам. Ещё в декабре 2025 года Роскомнадзор, [по данным «Теплицы»](https://te-st.org/2026/05/12/hostingrules/), прислал хостеру Aeza список адресов из его сети с требованием убрать VPN-серверы за сутки. А в октябре 2026 года удары по дата-центрам «Яндекса» показали ещё один риск: входной узел в одном российском облаке может пропасть вместе с ним, об этом — [[DPI/datacenter-strikes-october-2026|статья об ударах по ЦОД]].
## Риски и спорные места
**Один долгий туннель сам по себе заметен.** Участник обсуждения под ником aki возражал, что многомесячное соединение с одним зарубежным адресом с сотнями гигабайт трафика провайдер и так распознает как VPN. Автор отвечал, что так же выглядят игры, стриминг и синхронизация облачных дисков, и ложных срабатываний было бы слишком много. Публичных случаев блокировки только за объём трафика к одному адресу не найдено, но схема разделения адресов эту проблему и не решает.
**Блокировка подсетей.** Подтверждённый риск: с августа 2026 года подсети хостеров блокируют целиком. Если вход и выход в одной подсети, блокировка выходного адреса может задеть и вход. Отсюда совет брать второй адрес из другой подсети или у другого хостера.
**CGNAT не спасает.** Автор схемы считал, что общий адрес у многих абонентов провайдера размывает сопоставление. Приказ Роскомнадзора № 51 как раз требует от операторов передавать сведения об адресах оборудования, поэтому полагаться на это не стоит.
**Торренты.** В исходной схеме торренты с компьютера пускались мимо VPN, чтобы не нагружать сервер и не получать жалобы хостеру. Но тогда ваш домашний адрес виден в раздачах, а это тот же адрес, с которого вы подключаетесь к туннелю. Хостеры вроде Hetzner в своих условиях запрещают нарушение авторских прав и могут заблокировать сервер, так что торренты через VPS — тоже не выход.
**Домашний статический адрес как выход для российских сайтов.** Участник обсуждения предлагал отправлять российский трафик с сервера через свой домашний статический адрес, который российские сайты считают обычным. Это работает, но появляется ещё одна точка, которую нужно обслуживать, а связь «домашний адрес — зарубежный сервер» становится видна провайдеру.
## Чек-лист
- [ ] Куплен второй IPv4, лучше из другой подсети
- [ ] `ip route get 1.1.1.1` показывает `src` выходного адреса Y
- [ ] sing-box установлен из репозитория SagerNet, `sing-box version` — 1.14 или новее
- [ ] Вход слушает только адрес X (`listen`)
- [ ] У `direct`, WARP-endpoint и обоих DNS-серверов выход идёт с адреса Y
- [ ] Первым правилом маршрутизации стоит `{"action": "sniff"}`
- [ ] Профиль WARP создан через wgcf, `wgcf trace` показывает `warp=on`
- [ ] Tor выходит с адреса Y (`OutboundBindAddress`), i2pd — без транзита
- [ ] На адресе X открыт только порт входа, SSH слушает только Y
- [ ] `sing-box check` проходит без ошибок
- [ ] С телефона через туннель сервис определения адреса показывает Y или адрес Cloudflare, но не X
## Источники
- [ntc.party, апрель 2026 — тема Dreaght «Фикс обнаружения и блокировки туннелей: sing-box маршрутизация»](https://ntc.party/t/23690)
- [Хабр, 5 марта 2026 — разбор модуля проверки VPN в MAX](https://habr.com/ru/articles/1006666/)
- [«Новая газета Европа», 5 марта 2026 — ответ MAX на обвинения в слежке](https://novayagazeta.eu/articles/2026/03/05/v-max-obnaruzhili-shpionskii-modul-kotoryi-otslezhivaet-ispolzovanie-vpn-news)
- [Meduza, 11 апреля 2026 — исследование RKS Global: 22 из 30 приложений ищут VPN](https://meduza.io/feature/2026/04/11/rossiyskie-prilozheniya-dlya-android-sledyat-za-vami-po-suti-eto-polnotsennye-shpionskie-programmy)
- [«Новая газета Европа», 15 апреля 2026 — как сервисы ограничили доступ с VPN](https://novayagazeta.eu/articles/2026/04/15/pokhozhe-vy-ispolzuete-vpn)
- [«Медиазона», 2 апреля 2026 — Шадаев попросил сервисы ограничить доступ с VPN к 15 апреля](https://zona.media/news/2026/04/02/vpn-15)
- [«Теплица социальных технологий», 27 мая 2026 — приказ РКН № 51 и сбор IP-адресов](https://te-st.org/2026/05/27/collectip/)
- [«Теплица социальных технологий», 30 сентября 2026 — блокировки подсетей хостеров](https://te-st.org/2026/09/30/vlessmore/)
- [«Теплица социальных технологий», 12 мая 2026 — требования к хостерам и случай Aeza](https://te-st.org/2026/05/12/hostingrules/)
- [«Медиазона», 1 октября 2026 — проект: год без российских хостингов для VPN](https://zona.media/news/2026/10/01/vpn)
- [sing-box — установка через менеджер пакетов](https://sing-box.sagernet.org/installation/package-manager/)
- [sing-box — устаревшие и удалённые возможности](https://sing-box.sagernet.org/deprecated/)
- [wgcf — неофициальный клиент Cloudflare WARP](https://github.com/ViRb3/wgcf)
- [ipinfo — AS13335 Cloudflare](https://ipinfo.io/AS13335)
- [Cloudflare — условия использования приложения WARP](https://www.cloudflare.com/application/terms/)
- [Tor — справочное руководство, OutboundBindAddress](https://2019.www.torproject.org/docs/tor-manual.html.en)
- [i2pd — параметры конфигурации](https://docs.i2pd.website/en/latest/user-guide/configuration/)
- [Xray — VLESS и ограничения XTLS Vision](https://xtls.github.io/en/config/outbounds/vless.html)
- [Xray — транспорт gRPC и рекомендация перейти на XHTTP](https://xtls.github.io/en/config/transports/grpc.html)
- [Xray — параметр sendThrough](https://xtls.github.io/en/config/outbound.html)
- [Хабр — «сибирская блокировка» TLS-соединений](https://habr.com/ru/articles/1044396/)
## 📚 См. также
- [[VLESS-localhost-protection-guide|Защита VPN от localhost-атаки]] — что настроить на клиенте и сервере, включая WARP в Xray.
- [[VLESS-SOCKS5-vulnerability|Уязвимость SOCKS5 на localhost]] — как приложения узнают адрес сервера через локальный прокси.
- [[Localhost-tracking-Meta-Yandex-SOCKS5|Localhost-трекинг Meta и «Яндекса»]] — подтверждённые случаи слежки через loopback.
- [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY]] — подсеть, отпечаток TLS и частота соединений.
- [[DPI/mincifry-whitelist-vpn-hosting-august-2026|«Замаскированные» VPN и белый список]] — почему сервер обхода на российском хостинге под ударом.
- [[DPI/paid-international-traffic-5g-50gb-october-2026|Плата за зарубежный трафик в 5G]] — зачем строят цепочку через российский сервер.
- [[DPI/datacenter-strikes-october-2026|Удары по дата-центрам «Яндекса» и «Сбера»]] — что бывает с узлом в одном российском облаке.
- [[sing-box/sing-box|Раздел о sing-box]] и [[xray/xray|раздел о Xray]] — ядра, протоколы и маршрутизация.
- [[Белые списки]] — три значения «белого списка» в теме блокировок.
---
> [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ
> При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git2.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/tunnel-detection-fix-split-ip.md) · [скачать весь репозиторий одним zip-архивом](https://git2.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip).