Тоже начали всё чаще и чаще душить соединения к self-hosted VPS, а потом и вовсе заблокировали доступ к входному IP? Ещё нет? Перестрахуйтесь заранее!
Контекст
В сети начали подозревать MAX в наличие шпионского модуля.
Что подтвердилось:
Примерно в то же время начали периодически душить соединения, подробнее описал здесь, а потом и вовсе заблокировали входной IP со всех локаций сразу, хотя те самые обрывы чинились банальной сменой внутреннего NAT IP.
РКН действительно продавил закон о получении логов на провайдерах:
Предположение о “Сибирской блокировке” не билось с симптомами, характерностью и последствием.
Причем есть косвенные подтверждения и от остальных пользователей.
И очень похожая на мою ситуация:
Поэтому я абсолютно уверен в том, что шпионы существуют не только в MAX, а на прочих некоторых сервисах. Подробнее даже выложил предположение о потенциальных уязвимостях, которыми они могут воспользоваться.
Спустя какое-то время кто-то выложил новость о том что “минцифры поручило сервисам обнаруживать туннели и отказывать в обслуживании”. Источники не приложу, не знаю уровень их желтизны. Пост и мой ответ к нему загадочно исчез спустя 15 минут после публикации (даже осталась ссылка к нему - https://ntc.party/t/реверс-инжиниринг-модуля-проверки-успешности-блокировок-внутри-мессенджера-max/22584/267) без каких-либо предупреждений. Походу боты РКН спровоцировали блокировку спам-жалобами. Заранее спохватились, видимо)
UPD: Появился новый! https://ntc.party/t/вопросы-по-ограничению-трафика-зарубежных-ресурсов/23526/26
Именно! Потенциально – да, данный пост как раз это и раскрывает.
Проблема (не доказанный факт, но практически подтвержденная гипотеза)
Как выясняется, РКН и подконтрольные им сервисы-шпионы теперь могут в автоматическим режиме заниматься active probing обнаруженных входных IP адресов, особенно если вы сливаете свой домашний IP для однозначной идентификации местоположения ТСПУ, который будет использоваться для корреляционной атаки.
Мы выяснили, что доступ к логам провайдеров они вполне имеют, для однозначной идентификации SRC NAT-IP:
Согласитесь, что мешает им в автоматическом режиме это делать? Мощности? Массово не будут. Будут точечно. Дорогостоящее оборудование на наши же деньги, налогоплательщиков, и поставят.
Фикс | Как вообще избежать этого?
Нет, не запускать “шпионы” в sandbox. Я дал вполне разумное техническое обоснование, почему это не сработает.
Тараканов по одному ловить – плохая идея.
Что не сливать? Кому попало домашний IP – это во-первых. Значит пускаем весь трафик (кроме Bittorrent, это только на ПК!) через VPN (путем создания интерфейса сети И прозрачной маршрутизации через userspace прокси).
Ещё – входной IP сервера – тот что шпионы донесут РКН, для его блокировки.
Как скрыть?
Уже предложили лечение:
“split tunneling” на уровне приложений я крайне не рекомендую, не столько потому, что это закрывает все уязвимости, сколько вы заставляете конечные клиенты-устройства быть умными. Как говорится, когда-нибудь да ошибетесь, да и архитектура неправильная.
“Чекеры IP” или всё что связано с MAX забанить – тоже не получится. Всех тараканов не уничтожишь, IP утечь может сотней разных способов (и пролезть в правила маршрутизации).
Нет, ну вы можете конечно изолировать не только исполняемый код, а ещё и интерфейс сети. Готовы реализовать такой же уровень изолированности, как в QubesOS, на смартфонах? Вот вот, поэтому не стоит и думать в эту сторону, это заведомо проигрышная борьба.
Схема
Минимальная схема, которая закроет банальную уязвимость - обнаружение входного IP, это поменять входной IP (принимать трафик только с него), оставив по дефолту выходным IP тем уже был.
Во-первых у своего хостера купите второй белый IPv4. Где-нибудь в панели управления VPS во вкладке “Сеть” или типа того.
У вас в ip a должны быть все нужные IP адреса. Оба входной/выходной, и IPv6 выходной, если есть. Но выходной IPv6 не обязателен, его WARP предоставляет, например для доступа к данному форуму. Если в ip a после покупки отсутствует новый IPv4, настройте чтобы был, смотря какая у Вас ОС.
Например в Arch Linux
Файл: /etc/systemd/network/20-eth0.network
[Match]
Name=eth0
[Network]
# IPv4
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 – входной IP, должен идти ПОСЛЕ выходного Y.Y.Y.Y чтобы выходной был дефолтным!
Перезапустить сервис:
systemctl restart systemd-networkd
Используем sing-box как движок маршрутизации трафика на сервере и клиенте.
/etc/sing-box/config.json – типичное местоположение его файла конфигурации.
Изменяем:
inbounds.inbound.listen
"inbounds": [
{
"type": "vless",
"tag": "reality-in",
"listen": "X.X.X.X",
...
}
]
Где вместо “X.X.X.X” - входной IP который нельзя ни в коем случае нигде светить.
То что куда-то светится - outbound.direct.inet4_bind_address
"outbounds": [
{
"type": "direct",
"tag": "direct",
"inet4_bind_address": "Y.Y.Y.Y"
},
...
]
Где “Y.Y.Y.Y” - выходной IP сервера.
Если вы не доверяете ещё каким-нибудь outbound апстримам на сервере - прикрепите
"inet4_bind_address": "Y.Y.Y.Y"
Туда тоже. Но всё равно должно идти через дефолтный (выходной), это лишь подстраховка.
Это всё? Минимально - да, но не панацея.
Кстати, я ещё долго после фикса пользовался обычным TCP транспортом без мультиплексирования и всё всё равно было супер, проблемы исчезли.
Расширенная схема
Не менее важным считаю и правильную маршрутизацию. Входной IP вы скрыли, а от корреляционных атак (как я предложил здесь) вас это всё равно не спасёт. Да, тех что автоматизированно программно осуществляют, не вручную, да хоть глубокой ночью (в моем случае так и было, тем более я трафика почти не генерировал никакого).
Хорошо, где брать сервера? Нужен только один. Объясняю:
Конечные устройства могут теми или иными способами осущеставлять те или иные манипуляции с трафиком для самих себя. Но это ужасно, и неправильно. Клиенты должны быть тупыми. А сетевой шлюз (например роутер) – умным, он для этого и создан.
При этом роутер не обязательный, вы тоже не готовы ходить с карманным OpenWRT роутером?
И мне что, на условном iOS как курица в кнопку включение/выключение клевать при этом переключая профили стран?
Нет, в том то и дело, что он, как и прочее конечное устройство на это не рассчитан (и не должен), поэтому предлагаю использовать VPS как свой личный удаленный шлюз – мозги маршрутизации.
Гоните весь трафик через VPN на смартфоне, и на ПК (с исключением для bittorrent, его напрямую в direct). Нет, ничего не будет что у вас 95% трафика идет туда (хотя для внутренних сервисов Apple можно и напрямую, внимание – доверенных сервисов, где вы точно уверены, что шпион этим каналом не воспользуется для обхода правил маршрутизации).
Получается цепочка:
Me → VLESS к серверу.
Ах да, протокол де-факто простой:
VLESS: VLESS-XTLS-uTLS-REALITY-xudp-gRPC.
Обязательно используйте как минимум gRPC для транспорта, он достаточно хорош в мультиплексировании для предотвращения триггера пресловутой “Сибирская блокировка”.
Reality к SNI в подсети хостера.
Дальше что? Весь трафик выходит через наш VPS outbound IPv4. Условный Kinopoisk вы с ним не откроете, противятся IP датацентра (принадлежащий ASN датацентра).
Заворачиваем весь неизвестный трафик в WARP тогда:
Me → VLESS → WARP → Неизвестное
Делается это добавлением интерфейса WireGuard в endpoints
"endpoints": [
{
"type": "wireguard",
"tag": "warp-ep",
"system": false,
"name": "wg0",
"mtu": 1280,
"address": [
"X.X.X.X/32",
"YYYY:YYYY:YYY:YYYY:YYYY:YYYY:YY:YYYY/128"
],
"private_key": "Private key here=",
"domain_resolver": "google",
"peers": [
{
"address": "engage.cloudflareclient.com",
"port": 2408,
"public_key": "Public key here=",
"allowed_ips": [
"0.0.0.0/0",
"::/0"
]
}
]
}
]
Чтобы сгенерировать конфиг (делать из VPS) есть инструкция (Usage) в репозитории клиента WARP.
Не забудьте изменить ключевые поля, которые отличаются.
Но Apple CIDR + Telegram (не geosite) (не geosite) и прочие хорошие доверенные сервисы (на CIDR которых нельзя расположить свои сервера) – известные, их напрямую в DIRECT на самом VPS:
Me → VLESS → Apple CIDR, Telegram CIDR и прочие хорошие, доверенные сервисы.
Но я всякий OpenAI / Habr (некоторые статьи) / TikTok – всё равно не открою! Зря купил рувпс!
Это их проблема, а не ваша. Поднимите демон Tor (для outbound) (обычно они его уважают) или апстрим прокси. Современный Tor сейчас довольно-таки шустрый.
Me → VLESS → Tor или ( ShadowSocks с/без WARP ) → Вредные сервисы (с геоблоком)
А SSH что? Какой-нибудь port-knocking или порт на небеса, или ещё какой-нибудь костыль, например firewall по SRC IP?
Всё очень просто.
Me → VLESS → SSH (к выходному IP) → мой сервер.
Всё, слушаете SSH только на выходном IP, он будет идти через VLESS автоматически (с входного IP, там пинг в той же подсети околонулевой). Также можете через IPv6 подключаться, если есть.
А ляжет туннель, как подключусь к серверу?
Через onion сервис SSH. То есть через Tor напрямую.
Me → bridges over (например, ru email-pgp GitHub Actions bot, или напрямую как-то ещё мосты) → Tor → SSH / SSH-over-onion → мой сервер (чтобы не оставлять single point of failure).
А у меня госуслуги через туннель открываться не будут! Зря весь трафик в туннель идет!
Потому что Google DNS не возвращает “правильные IP”. Для всего ру сегмента сети форсируйте Yandex DNS на самом VPS, и всё равно какой там DNS хотел клиент.
DNS over VLESS: RU → Yandex DoU; Default → Google DoT
Не заморачивайте конечные клиенты DNS правилами.
{
"rule_set": ["geosite-category-ru"],
"server": "local"
}
route.rules (чтобы заставить РФ сервисы использовать Yandex DNS)
{
"rule_set": ["geosite-category-ru"],
"action": "resolve",
"server": "local"
}
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"
}
Это всё? РФ сервисы покрыты, DNS к ним – правильный. Геоблок сервисы - тоже работают. И всё это - с тупого конечного устройства.
Что требуется от конечного устройства?
Туннелировать весь свой трафик через этот “шлюз”, теперь вы сами себе провайдер и решаете что фильтровать/блокировать, и что куда должно и по каким правилами идти, абсолютно прозрачно.
Итоговая схема:
Спойлер, роскошный максимум
Me → VLESS → WARP → Неизвестное
Me → VLESS → Tor или ( ShadowSocks с/без WARP ) → Вредные сервисы (с геоблоком)
Me → VLESS → Apple CIDR, Telegram CIDR и прочие хорошие, доверенные сервисы.
Me → VLESS → I2P, причём I2P роутер на самом сервере.
Me → VLESS → SSH (к выходному IPv4) / SSH на IPv6 → мой сервер.
Ещё есть Me → bridges over ru email-pgp GitHub Actions bot → Tor → SSH / SSH-over-onion → мой сервер (чтобы не оставлять single point of failure).
Me → DIRECT → Bittorrent
DNS over VLESS: RU → Yandex DoU; Default → Google DoT
VLESS: VLESS-XTLS-uTLS-REALITY-xudp-gRPC.
Правила маршрутизации реализованы на сервере по geosite / geoip / портам и user_auth.
Ещё и принуждение Yandex DoU для RU доменов, даже если клиент хотел другой DNS.
Выходной IPv4 – дефолтный в системе, входной IPv4 – дополнительный.
Проброс 80\TCP и 443\UDP на входном. SSH слушать только на выходном IPv4.
А не странно будет, что весь трафик идет только к одному и тому же IP?
Нет, схема обкатана, я ей пользуюсь уже неделями. Давайте решать проблемы по мере их поступления. Как минимум, будет куча ложных срабатываний если по такой эвристике что-то там судить.
Итог
Таким образом это инфраструктурный фикс проблемы утечек, а не одноразовые костыли. Теперь можно спокойно любыми шпионами пользоваться, не опасаясь что они что-то там будут пытаться задетектить.
У меня основная политика маршрутизации расположена на сервере, а не на каждом отдельном клиенте. То есть мозг маршрутизации - на сервере, и тонкие клиенты к нему.
Но минимальный фикс, и самый здесь важный, - разделить входной/выходной IP, а дальше политика маршрутизации на Ваше усмотрение, я лишь предложил архитектуру, но она не обязательна для Ваших условий, Вы можете по своему сделать.
Подразумевается, что данная схема – покрывает типовые сценарии быта среднего пользователя.