Коротко — под DPI я понимаю Deep Packet Inspection (сетевой инспектор/фильтрация трафика), а не «dots per inch».
Дальше — по вашим вопросам.
1) Как однозначно установить, что блокировка идёт со стороны РКН / провайдера в России
Ни одного «волшебного» теста нет, но комбинация тестов даёт практически однозначное подтверждение. Что следует сделать и как интерпретировать результаты:
A. Общая диагностика доступности
- ping, traceroute (tracert/tracepath/tcptraceroute) от клиентов в России и с внешних хостов:
- если из России трасса обрывается на каком‑то узле внутри РФ/на первом «хопе» провайдера — повод подозревать фильтрацию.
- Проверка открытого порта:
- nc -vz <IP> <PORT> или curl --connect-timeout 10 https://<IP>:<PORT>/ (для TLS) — если с внешних мест порт открыт, а из РФ — нет, это индикатор блокировки со стороны российских сетей.
B. Проверка логов и сетевых пакетов на сервере
- На сервере запустите tcpdump и смотрите, приходят ли SYN от российских клиентов:
- sudo tcpdump -nn -i any host <ip_клиента> and tcp
- Или для порта: sudo tcpdump -nn -i any 'tcp port 443'
- Сценарии:
- Клиент слал SYN, на сервер приходят SYN → сервер отвечает SYN-ACK, но клиент не получает — это может быть инъекция/блокировка на пути к клиенту.
- На сервер не приходит никаких SYN от российских IP → вероятно, блокировка/черныйхол в российской сети или BGP‑фильтр.
- На клиенте и сервере одновременно: hping3 и tcpdump
- Пример: с клиента hping3 -S -p 443 -c 3 <сервер_ip>
- На сервере смотреть, приходят ли пакеты. Это помогает понять, где именно теряется трафик.
C. Поиск признаков инъекции (RST/FIN)
- Инъекция часто проявляется как «лягушачьи» RST-пакеты от «постороннего» адреса или с необычно малым TTL.
- В pcap ищите RST от IP, который не соответствует ни клиенту ни серверу, или RST с TTL, отличающимся от обычных — это классический признак активного вмешательства.
D. Проверка BGP/маршрутизации и видимости IP
- Посмотрите объявляется ли ваш IP через RIPEstat / bgp.he.net / viewroute. Если IP внезапно перестал анонсироваться — это может быть провайдерская блокировка или blackhole.
- Проверьте, не занесён ли IP в общедоступные черные списки/реестры.
E. Сопоставление с другими точками доступа
- Попросите тесты с разных российских операторов/сетей (домашний провайдер, мобильный интернет разных операторов). Если блокировка наблюдается у большинства российских провайдеров — высокая вероятность централизованной фильтрации.
- Используйте публичные RIPE/активные точки (RIPE Atlas, OONI, сторонние сервисы) для проверки.
F. Проверка Xray/сервера
- Просмотрите логи Xray: journalctl -u xray -f и лог файлов access/error. Возможно не сам бинд/демон, а проблема в сертификате/конфиге.
- netstat -tunlp | grep xray — убедиться, что порт слушается.
Если после всех вышеуказанных тестов:
- на сервере НЕ видно входящих SYN от российских клиентов → блокировка/фильтрация на уровне операторов/RKN;
- на сервере видны SYN, но клиентам приходят RST‑ы или нет ответа → возможно инъекция/RST‑интерференция DPI;
— тогда с высокой степенью уверенности можно говорить о вмешательстве со стороны фильтрующих систем.
2) Поможет ли организация «моста» через российский VPS, и нюансы/риски
Короткий ответ: да, в большинстве случаев организация проксирования через VPS в России восстановит доступ клиентам внутри РФ (потому что трафик до российской VPS остаётся в пределах российских сетей и не блокируется как «внешний»). Но есть важные оговорки.
Как это обычно делается
- Вариант A — VPS в РФ принимает соединения от клиентов (порт 443, TLS, WebSocket/h2 и т.п.) и ретранслирует трафик далее на ваш зарубежный сервер по зашифрованному туннелю (SSH, WireGuard, TLS).
- Вариант B — VPS действует как «reverse proxy» и выполняет роль единственной точки входа для российских клиентов, а уже он коннектится к бэкенду.
Плюсы
- Российские клиенты снова подключаются к VPS без внешних блокировок.
- Можно замаскировать внешний трафик между клиентом и VPS под «нормальный» HTTPS (port 443, легитимный сертификат, корректный SNI), уменьшая шанс DPI‑детекции.
Минусы и риски
- Законность и ответственность:
- VPS в России работает под юрисдикцией РФ. Провайдер и госорганы могут требовать логи (SORM) и быстро реагировать на жалобы/предписания. Это юридический риск для владельца VPS и для вас как организатора моста.
- Провайдер может отключить аккаунт при жалобах/обнаружении проксирования.
- DPI и обнаружение:
- Если клиенты соединяются с VPS по «обычному» TLS/HTTP/WS, DPI с меньшей вероятностью выявит проблему. Но если между VPS и зарубежным сервером идёт специфический трафик (Trojan/VLESS в явном виде), он может быть выявлен или заблокирован на исходящей стороне российского хоста.
- Даже внутри РФ провайдеры могут применять DPI и блокировать или ограничивать подозрительный трафик.
- Логи и приватность:
- Вся метаданные и, возможно, незашифрованный трафик будут видны провайдеру VPS (и государству через СОРМ).
- Надёжность и масштаб:
- Это единая точка отказа/целевая — один российский VPS будет интенсивно нагружен и легче обнаружим.
- Экономика и поддержка:
- Нужны средства на VPS, мониторинг, быстрая смена конфигураций/серверов при детекции.
Практические рекомендации, если решите поставить мост
- На VPS:
- Принимать трафик по 443/TLS с валидным сертификатом (Let's Encrypt) и маскировкой SNI под обычный домен.
- Использовать WebSocket over TLS (ws/wss) или HTTP/2 для маскирования.
- Скрывать сигнатуру прокся (соблюдать «правильные» заголовки Host/User‑Agent, не выдавать типичный прокси‑поведение).
- Между VPS и зарубежным сервером:
- Делайте защищённый туннель (WireGuard/SSH/мутуальный TLS). Лучше — протокол с постоянной «похожестью» на обычный HTTPS.
- Шифруйте и по возможности разбивайте трафик/используйте мультиплексирование.
- Обфускация:
- Xray/V2Ray/XTLS/XTLS+Websocket/HTTP2 — используйте опции, которые уменьшают характерную подпись протокола.
- Периодически меняйте порты/SNI/сертификаты и имитируйте обычный веб‑трафик.
- Аудит и мониторинг:
- Ведите логирование и собирайте pcap при неполадках, чтобы быстро диагностировать повторную фильтрацию.
- Юридические предостережения:
- Обсудите с юристом последствия либо используйте VPS только для личного использования. Я не даю юридических советов, но предупреждаю об увеличенном риске в юрисдикции РФ.
Альтернативы мосту внутри РФ
- Использование CDN/Spectrum (Cloudflare Spectrum) — платное и более устойчивое, но тоже не гарантирует защиту от детальной DPI.
- Несколько зеркал/серверов в разных юрисдикциях + ротация.
- Обфусцирующие плагины/транспорты (obfs4, meek-подобные техники) — может снижать вероятность детекции DPI.
Что можно сделать прямо сейчас (пошагово)
1. На сервере: запустите tcpdump и/или сохраните pcap при попытках подключения российских клиентов.
- sudo tcpdump -nn -i any port <ваш_порт> -w /tmp/cap.pcap
2. С клиента в РФ: выполните hping3 и curl/openssl s_client, соберите вывод.
- hping3 -S -p <порт> -c 5 <IP_сервера>
- openssl s_client -connect <IP>:<порт> -servername <hostname> -tlsextdebug
3. Сравните: приходят ли SYN на сервер; приходят ли ответы;
4. Проверьте трассу и BGP объявление IP.
5. Пришлите сюда выводы tcpdump/hping/trace — помогу проанализировать.
Если хотите — пришлите результаты tcpdump/пара команд (или короткие логи Xray + вывод traceroute/hping с российского клиента), и я помогу интерпретировать и подскажу краткосрочную конфигурацию «моста», учитывая риски.