Evgeny 

Представьте ситуацию. Вы купили VPS, настроили сайт, ваша простая стартовая страничка нормально грузится, но вам нужно что-то большее. Например POST-запросы или GRPC. И всё это не работает. Вы ищете причину в настройках сервера, файрвол, nginx, selinux, кажется, что всё верно. Чтобы не бродить по этому замкнутому кругу, вот два простых признака, что ваш сервер блокируется оборудованием DPI или ТСПУ.

Первый. Положите в файлы вашего сайта что-нибудь весом килобайт тридцать, вот этот файл прекрасно подойдёт. Затем попробуйте скачать его с вашего сайта. Если закачка останавливается примерно на середине, "поздравляю" - вы под блокировкой tcp 16-20. Этот вид блокировок, когда проходят только первые 16-20 кБ трафика, распространился и на сервера в России.

Второй способ. Запросите с помощью curl или браузера что-нибудь с вашего сайта и посмотрите на ответ в Wireshark. Tcp пакеты пронумерованы по порядку, и если часть пакетов не дошла до вас, то это будет заметно по отсутствующим номерам. Остальные пакеты из этого соединения программа Wireshark "подсветит" чёрным.

ip link # чтобы узнать название интерфейса

sudo tcpdump -i <your-interface> host your-server-ip -w captured.pcap # захват пакетов

wireshark captured.pcap

Совместно с логами nginx видно, что блокировка действует не на уходящие от пользователя пакеты, а на ответ, приходящий к нему. И метод, по которому они блокируются, похоже, вероятностный, и его скорее всего можно обойти. Однако даже если удастстя обмануть DPI, вы упрётесь в tcp 16-20. Выход один - переезд.

Чтобы понять, как работает dnstt, сделаем такой опыт.

В линуксе в одном терминале запустим команду netcat

ncat -l -k -v 127.0.0.1 8000

а в другом терминале netcat с другими опциями:

ncat -v 127.0.0.1 8000

Теперь всё, что вы будете писать в одном терминале, будет появляться в другом, и наоборот. Такой же канал, только зашифрованный, dnstt создаёт между клиентом и сервером с помощью dns запросов-ответов. Для соединения клиента и сервера клиенту понадобится ключ, сгенерированный при установке dnstt.

Логичный вопрос: если что-то происходит в "терминале" сервера, как это будет передано клиенту, ведь dns запросов в этот момент не происходит? Похоже, серверу приходится держать буфер под это, a клиенту довольно часто посылать dns запросы.

Ещё одно замечание. На клиенте для dns запросов используйте doh (dns-over-https), чтобы ваше соединение покрылось ещё одним слоем шифрования. Иначе "наблюдатьль" увидит довольно странные и нетипичные dns запросы.

Итак, для установки проще всего использовать скрипт dnstt-deploy.

Понадобится доменное имя (на сайте Селектела можно купить за 130 рублей в год), и скорость будет не больше 0.5-1.5 Мб/с. Весь процесс описан по ссылке, я лишь отмечу детали, которые инструкция освещает не очень понятно.

Меня интересует ssh-доступ к серверу, на который ставится dnstt, и dnstt-deploy для этого очень подходит. В режиме ssh mode (option 2) создаётся netcat туннель прямо на порт, который слушает sshd на сервере. (А в режиме socks пользователь попадает прямо на вход socks5-прокси, который просто даёт выход в интернет с сервера.)

На клиенте для подключения к ssh-демону сервера (нестандартный порт определится автоматически) достаточно запустить всего две команды (в файл dnstt-key.pub просто скопируйте ключ, полученный при установке):

У сочетания vless+tcp+reality обнаружилась фундаментальная проблема, благодаря которой его можно "задетектировать". На каждое tls соединение он создает отдельное tcp соединение. Ничего крамольного в этом нет, только вот _обычно_ браузеры так не делают. Обычно сначала происходит tcp соединение - браузер посылает специальный syn-syn tcp пакет, принимает syn-ack от сервера и возвращает ack-ack, благодаря чему клиент и сервер договариваются о базовых вещах, вроде занесения айпи и портов друг друга в специальную таблицу открытых соединений. Дальше между этими портами и айпи могут пересылаться пакеты TLS hello, да и собственно зашифрованные пакеты tls. И обычно в рамках одного tcp соединения может произойти несколько tls соединений.

Такое поведение можно сымитировать с помощью мультиплексирования, используя одно tcp соединение для нескольких tls. Беда в том, что мультиплексирование (mux) несовместимо с flow.

Flow в reality влияет на макроскопические временнЫе характеристики трафика. ВременнЫе характеристики трафика могут быть обусловлены протоколом или поведением, например, сколько файлов загружается при посещении главной страницы Google, в каком порядке и какого размера. Добавление еще одного уровня шифрования не может эффективно скрыть эту информацию.

Сейчас блокировки поотпустили, и в целом без flow и без mux всё прекрасно работает. Но детектирование трафика без-mux на dpi уже продемонстрировано, детектирование трафика с пустым flow: "" - вопрос времени, и те, кто не перейдёт на xhttp или другую альтернативу, рискуют остаться не у дел.

ssh на мобильном интернете у меня перестал работать практически полностью в любом направлении, а на домашнем - на некоторые сервера. Что делать?

Вариант 1 - если есть промежуточный доступный jump-сервер, можно использовать ssh -J, но вам придётся два раза вводить пароль, сначала от первого сервера, потом от второго. С ключами (-i key) эта команда работать пока не научилась. Проще сначала просто зайти на jump-сервер, потом дальше.

Вариант 2. Если у вас есть локальный socks5 прокси - как раз такой поднимается при использовании клиентских конфигов easy-xray. В примере сокс на порту 10808.

Пишем в ~/.ssh/config сдедующее:

Host my_host

    HostName my_host

    User my_user

    Port my_port

    IdentityFile ~/.ssh/my_ed25519_key

    ProxyCommand nc --proxy-type socks5 --proxy 127.0.0.1:10808 %h %p

И всё! Просто подключаемся к серверу командой

ssh my_host

Последнее время мобильный интернет сильно "штормит", и то один, то другой айпи адрес оказывается заблокированным. Ещё есть не лишенное здравого зерна мнение, что не стоит весь трафик пропускать через один айпи адрес. А ещё есть белые списки, которые местами обходятся не перебором айпи адресов, а перебором SNI.

Xray позволяет "перебор" делать автоматически, с использованием балансировки (balancing). В xray есть разные типы балансировки, но хочется остановиться на leastLoad. В этом случае из нескольких серверов выбирается тот, через который "пинги" проходят стабильнее всего. За мониторинг соединений (пинги) в фоновом режиме отвечает "обсерватория". Обсерватории есть двух типов, но выбирать стоит burstObservatory - она проводит пинги нерегулярно, что уменьшает вероятность выявления использования xray.

В примере каждые три минуты (180s) через каждый сервер клиент нерегулярно шесть раз (5+1=6) обращается к адресу www.google.com/generate_204 для получения в ответ кода HTTP 204. Xray ждёт ответа максимум пять секунд (timeout). Результаты мониторинга используются в маршрутизации, через balancerObject (в примере - my_balancer). Выбираются наиболее надёжные сервера, не с меньшим пингом, а с наибольшим (за 180 s) числом прошедших пингов. Между двумя (expected: 2) лучшими серверами нагрузка распределяется случайным образом.

Работает этот конфиг в клиентах, честно использующих ядро xray: v2rayNG, v2rayN, Happ и SimpleXray. Последний использует кастомные geo*.dat файлы, поэтому для его работы в конфиге может понадобиться удалить блоки с geo*.

P.S. Обратите внимание на модуль dns. В конфигах с балансировкой не любой dns-модуль будет работать.

1. Easy-xray не гибкий. Совсем. Если что-то нужно поменять в конфигах, то жди беды. Easy-xray предполагает, что определённые поля конфигов находятся в определённых местах, например, что api inbound стоит первым в списке входящих соединений. Если изменить его положение, то easy-xray может начать генерировать невалидные конфиги. И это трудно заметить - тестов-то нет.

Правильный подход - не использовать jq, а использовать интерполяцию строк, когда значение переменной просто подставляется в строку. Это даже в bash можно было бы сделать. "address": "${address}"

2. Bash. Трудный для чтения, неудобный, error-prone. Я не могу без ChatGPT написать код, который с помощью for или sed в правилах добавит "domain:" к каждому домену. Высокоуровневый язык был бы лучше.

3. Не декларативные конфиги. То есть конфиги всегда декларативные, но с easy-xray пользователь не пишет конфиги, он запускает команды. Команда может полностью переписать конфиг или испортить его, и бэкапы не всегда спасают.

Писать конфиги вручную совершенно неудобно, например, для добавления пользователя нужно как минимум сгенерировать два id. Выход? Сочетать два подхода. Если конфиг - это история команд, простая и понятная, которую можно править как текстовый файл, то бекап не нужен в принципе.

4. Можно п.3 рассмотреть на примере. Здесь ещё одна идея - использовать в качестве языка конфигураций не JSON, TOML или DHALL, а использовать полноценный язык программирования. Здесь Scala3. Python, Clojure (babashka), JS (deno) - все имеют плюсы и минусы. Любой из них скорее всего тоже бы подошёл.

Как это должно работать: владелец сервера заполняет часть конфига, а дальше использует команды для добавления или удаления пользователей. Эти команды только дописывают строчки в конфиг, и ничего не удаляют из него. Вся история сохраняется

Проверить можно прямо с клиента, без компьютера и ssh. VLESS Mixer для этого идеально подходит. Нужна работающая vless:// ссылка, совместимая с vless-mixer, с ней вы сможете направить ваш трафик сначала на сервер заграницей, а потом на тот сервер, который хотите проверить.
1. Идём на https://lucynspace.cc/ , жмякаем получить vpn, получаем vless-ссылку, проверяем в приложении, что она работает.
2. Идём на https://lucynspace.cc/ , жмякаем vless-mixer, в качестве первого ключа вставляем полученную vless ссылку, в качестве второго - vless ссылку от того сервера, который хотим проверить.
3. Создаём json конфигурацию, копируем и вставляем в v2rayNG на Андроид или happ на Айос.
4. Если конфигурация работает, приложение подключается и трафик идёт, поздравляю - из Европы ваш сервер доступен. Если конфигурация не работает, это ещё не значит, что ваш сервер упал, но это возможно.

Наше сообщество помогло протестировать эту штуку на разных платформах (спасибо!), поэтому расскажу про неё подробнее.

Обычно все собирают логи. Провайдеры VPN (впн-сервисы), провайдеры VPS (хостеры). В vless обычный https-трафик шифрован, но на стороне vless-сервера видно домены, к которым обращается пользователь. И видно айпи-адрес пользователя. Если эта информация попадёт в чьи-то руки, она может быть использована против пользователя - чаще всего для таргетированной рекламы.

Как этого избежать? Что делать, если вы хотите безопасно использовать бесплатные ключи (vless ссылки, vless urls) с гитхаба или из телеграма?

VLESS Mixer предоставляет простой и эффективный способ повышения конфиденциальности и безопасности, маршрутизируя трафик через два сервера. Изменения в клиентах или серверах не требуются; просто настройте клиентские приложения.

VLESS Mixer генерирует конфигурацию для приложений с ядром Xray из двух VLESS-ссылок (vless://). Основная идея заключается в том, что Xray может отправлять впн-трафик, предназначенный для server2, сначала на server1 - как будто это обычный HTTPS трафик. Это магия vless-reality.

В результате первый сервер знает IP-адрес пользователя, но не целевые сайты, в то время как второй сервер знает целевые сайты, но не IP-адрес пользователя.

Будем делать из "малинки" "роутер", который всё (не совсем всё, об этом ниже), что подключено к ней по LAN, перенапраявляет на сервер (VPS) в Европе. Тогда любой телевизор, подключенный к этой Raspberry проводом локальной сети, получит "европейский" интернет — без российских блокировок. Моя личная мотивация была очень простой — смотреть YouTube на большом экране Smart TV.

Нам понадобятся:

- Raspberry Pi 3 или любой другой компьютер с 1 ГБ оперативной памяти

- арендованный где-нибудь в Финляндии виртуальный частный сервер (VPS)

- Smart TV с приложением ютуба

На VPS устанавливаем и настраиваем Xray (например с помощью easy-xray) и делаем клиентский конфиг для малинки. На ней тоже устанавливаем Xray: настраивать уже ничего не нужно, поэтому можно воспользоваться однострочником (см. https://github.com/XTLS/Xray-install)

Если использовать easy-xray, помимо клиентского конфига, сгенерированного на серверe, на малинку нужно скопировать customgeo.dat (в /usr/local/share/xray/). Копируем клиентский конфиг в директорию, где xray его будет искать, и перезапускаем xray:

easy-xray делает клиентский конфиг для xray, с которым он создаёт http-прокси на 127.0.0.1:801. Проверить, что он работает, можно с помощью

curl (должно вернуться 200 OK):

- Новая инструкция для grpc+tls+Cloudflare CDN https://github.com/EvgenyNerush/easy-xray/blob/main/CDN.ru.md

- Скрипты init0.sh и init1.sh для быстрой настройки "голых" серверов https://github.com/EvgenyNerush/easy-xray/tree/main/misc

------------------------

Easy-xray давно (но негласно) поддерживает конфигурацию с двумя ip-адресами на сервере, когда по одному адресу доступ происходит напрямую (по протоколу vless-REALITY), а по другому адресу - по протоколу gRPC (с TLS шифрованием). Второй ip адрес стоит обычно 1-2 евро, но он того стоит. Сеть доставки контента (CDN) от Cloudflare может доставлять gRPC трафик, и, купив доменное имя (~1 €), можно "присоединить" CDN к серверу с easy-xray.

Плюсы:

- ещё один канал связи, если сервер будет заблокирован по ip, у вас останется доступ по доменному имени,

- труднее выявить - ваш трафик идёт к серверам Cloudflare, которые управляют трафиком огромного количества сайтов в сети. Такой трафик не должен вызывать подозрений,

- труднее заблокировать, сопутствующий ущерб больше, чем от блокировки одного ip-адреса.

- другой путь трафика - скорость может быть даже выше

------------------------

init0.sh и init1.sh написаны для redhat-based дистрибутивов (Rocky, Alma Linux, CentOS) и позволяют быстро