VPN

Эта статья — расширенный туториал того, как установить и настроить свой VPN на VLESS с XTLS-Reality с управлением через GUI интерфейс 3x-UI.

Почему именно этот протокол?

Особенность VLESS-Reality в том, что: берутся HTTPS-пакеты, и пускаются через наш заранее подготовленный зарубежный сервер (VPS), как через прокси. Однако, стоит учесть, что обращаться к нему мы будем как к какому-нибудь www.google.com, но в стандартной процедуре хэндшейка выполняем скрытую процедуру авторизации - благодаря чему сервер поймёт, что мы его слон.

А если кто-то (читаем как РКН) попытается обратиться к нашему «сайту» без авторизации (атака именуемая как Active Probing) то в ответ лишь получит копию www.google.com со всеми необходимыми сертификатами. РКН подумает, что наш сервер - это просто сервер Google, a никакой не VPN, и ничего блокировать не будет.

— Кроме того, поскольку HTTPS-пакеты, которые будут пропущены через прокси, уже зашифрованы, в дополнительном шифровании не нуждаются, и никакой deep package inspection т.е DPI соответственно нас ни в чём не заподозрит.

• некоторые начнут задаваться вопросом, а почему не AmneziaWG или известный из поднебесья ShadowSocks, а потому что во время масштабных блокировок под нож может пойти всё, что не HTTPS.

Я хочу настроить сервер с XTLS-Reality, как это сделать максимально правильно?

Суть Reality в маскировке под какой-либо популярный сайт, поэтому когда вы решаете это делать, вам нужно добиться того, чтобы ваш IP (IP вашего VPS) вел себя полностью идентично настоящему серверу, которым вы прикидываетесь. Если тот "настоящий" сервер слушает на 80-м порту (plain HTTP), то вам тоже нужно настроить nginx или правило фаервола, чтобы переадресовывать HTTP-запросы на оригинальный сервер. Если "настоящий" сервер не слушает SSH-подключения на стандартном 22-м порту, то ваш тоже не должен.
— Если ваш хостер предоставляет reverse-DNS записи для IP-адреса, убедитесь, что там не осталось значение по умолчанию (обычно с доменом хостера), а лучше задайте такой reverse-DNS, какой виден у IP-адреса ресурса, под который вы маскируетесь.

Правда ли что VLESS не использует шифрование, и поэтому использовать его небезопасно для конфиденциальных данных.

Нет. То, что VLESS не предусматривает шифрования на уровне протокола, не значит, что данные передаются в нешифрованном виде. VLESS всегда работает поверх TLS, трафик шифруется именно механизмами TLS, а не самого VLESS. Никакой проблемы с безопасностью тут нет, все секьюрно.

Что лучше XTLS-Reality, или просто VLESS + XTLS-Vision?

Преимуществ XTLS-Reality два. Во-первых это простота настройки, не надо никаких доменов, сертификатов, и т.д. Во-вторых, из-за возможности маскировки под любой популярный сайт, с его помощью можно пролезать через белые списки цензоров - например, в Иране долгое время блочили/резали все по малейшему подозрению, но yahoo.com у них был в белых списках, и прокси, маскирующиеся под него работали.

А теперь приступим к установке и минимальной настройке VPN своими руками.

Хостинг для VPN

Есть масса хостингов, некоторые дешевле, но в этом материале разберём установку на aeza.net, его плюсами являются: пополнение по СБП; РФ картами всех мастей; установка сервера c 3x-UI в пару кликов и небольшая настройка пресета по ключам.

Регистрация и оформление сервера

Первым делом необходимо зарегистрироваться (данные для входа продублируются на почту) и войти в панель управления, после чего, пополняем баланс удобными для вас способами, для граждан РФ все условия соблюдены, как и писал ранее пополнение по СБП; РФ картами всех мастей;

Далее в колонке под логотипом aeza выбираем «Виртуальный сервер» (речь о боковой панели) и с этого момента начинается настройка конфигурации нашего будущего сервера.

Название: не имеет значения, по желанию

Выбор локации: Амстердам

Выбор тарифа: Shared — тариф NLs-1

Выбор операционной системы и ПО: предустановленное ПО и ищем 3x-UI Ubuntu 22.04

Выбор периода оплаты и оформление заказа: я выставил помесячную оплату, мало ли, что с хостинг-провайдером станет.

Бэкапы: отключаем (в них нет необходимости под наши нужды)

Установка

После успешного оформления и оплаты сервера переходим в раздел «Мои услуги» (речь о боковой панели), далее кликаем по нашему названию сервера с флагом попадая на страницу с краткой сводкой о сервере:

На данном этапе нас интересует лишь IP-адрес; имя пользователя и пароль.

Подключение по SSH к серверу

Постараюсь разобрать на трёх разных ОС параллельно, указывая для каждой какую команду и на каком этапе необходимо вводить.

Linux:

$ ssh username@ip-address -p 22

Где username — это логин администратора на сервере, а IP-address, соответственно, — ее IP-адрес.

Windows:

С некоторых пор подключаться через SSH из операционной системы Windows также стало можно через командную строку. Раньше для этого применялись сторонние приложения (вроде PuTTY или Cygwin и пр.), но в десятой версии ОС был добавлен встроенный OpenSSH клиент, который работает так же, как в Линукс.

Единственное отличие в том, что по умолчанию эта утилита отключена, и чтобы приступить к выполнению команд, необходимо установить ее в настройках.

Для этого совершите несколько шагов:

1. Откройте «Параметры» — «Приложения».

2. Выберите подпункт «Дополнительные компоненты».

3. Найдите в списке «Клиент OpenSSH» и нажмите «Установить». Если этой кнопки нет, значит, служба уже включена.

4. После установки перезагрузите компьютер.

Теперь нужно открыть командную строку. Можно найти ее через поиск или нажать Win+R, ввести в поле «cmd» и Enter. В этом случае процесс подключения по SSH в Windows и Linux будет идентичен.

Mac OS:

ssh username@ip-address -p 22

Итак, если в командной строке увидели «Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-113-generic x86_64)» то вы на верном пути и всё хорошо складывается, далее вводим команду:

nano 3x-ui.txt

Перед нами появится три важных для нас строки: URL; Login; Password.

Лезем в браузер и вставляем в адресную строку свой ссылку, в моём случае это:

http://77.221.154.202:16068

Вводим логин и пароль, который мы получили благодаря команде nano 3x-ui.txt и попадаем в панель управления, следующий шаг это создание ключа и настройка конфигурации.

Переходим в раздел «Подключения» — «Добавить подключение»

Настройка VLESS с XTLS-Reality

Примечание: наименование для более удобной идентификации ключей в панели управления (того стоит, в случае, если собираетесь раздать разные ключи)

Протокол: vless

Порт IP: оставляем пустым, как и на скриншоте выше

Порт: по умолчанию у вас будет выставлено определённое значение, его стираем и выставляем - 443

Ко вкладке «Клиент» вернёмся чуть позже, пока перейдём ниже:

Протокол передачи: TCP (всё, что ниже оставляем по умолчанию)

Безопасность: REALITY

• xVer — оставьте значение 0;

• uTLS— выбираем под какой браузер будет маскироваться VPN соединение. Рекомендую выбирать Chrome, ибо он наиболее популярен;

• Dest — назначение, указываем домен и порт. Я оставил yahoo.com:443;

• SNI — это домен, под который будем маскироваться. Ставим идентично пункту Dest yahoo.com, www.yahoo.com;

• Short ID — приватный ключ сгенерированный автоматически;

• Приватный ключ и Публичный ключ — не трогаем, стоит лишь нажать кнопку Get New Keys и ключи автоматически сгенерируются;

• Sniffing, HTTP, TLS, QUIC, FAKEDNS — оставляем по умолчанию.

Настройка клиента:

Email: аналогично как и с примечанием, наименование для удобства;

Flow: выбираем из списка xtls-rprx-vision.

Остальное не трогаем, оставляем по умолчанию и кликаем на «Создать» (ключ готов)

Для удобства подключения с мобильных устройств жмём на «+» у клиента и перед нами появится иконка QR-кода, кликаем и сохраняем:

Для получения текстового ключа кликаем по значку «i»

Ключ готов, теперь необходимо определиться с клиентом для подключения, моя основная ОС — Mac OS, порекомендовать могу FoXray (для тех, у кого macOS 13.1 и новее) в случае если у вас более старые ОС, то рекомендую использовать V2Box; из клиентов на iOS советую поставить также FoXray, но есть и масса других клиентов.

• Windows – InvisibleMan-XRay разворачиваем Assets и выбираем нужный zip х64 для 64 битных систем, x86 для 32 битных систем. Есть и другие клиенты постабильнее.

• Android – NakeBox разворачиваем Assets и там будут apk. Выбираем arm64. На момент написания статьи последний назывался релиз: NB4A-1.3.1-arm64-v8a.apk

Ещё больше познавательного контента в Telegram-канале — @secur_researcher

Нужно только сделать наши сети L и R приватными, на роутере C командой

Имена интерфейсов, а также их свойства смотрим командой show interface. Да, чтобы добраться до CLI - просто в адресной строке браузера допишите /a к ip адресу роутера.

Затем, руководствуясь этим "доступ закрыт, но может быть разрешен", делаем

Казалось бы всё, должно работать! Но нееет))) Роем дальше, командой show ip nat в таблице маршрутизации видим, что кинетик C делает с пакета на входящем интерфейсе с сетей L и R SNAT, т.е. подменяет исходный адрес адресом интерфейса wireguard

Роемся в документации, делаем на роутере C

Казалось бы теперь точно всё! Но снова нет. show ip nat говорит нам, что nat на интерфейсах сетей L и R по-прежнему включен! Соответственно, передачи пакетов между сетями L и R нет

Копаем дальше, находим пару интересных обсуждений про работу ip nat и ip static, в которых уже лет как 10 поднимается этот вопрос к инженерам кинетика... Суть следующая: если на роутер приходит пакет, адрес назначения находится вне известных кинетику приватных сетей, то он делает SNAT независимо от того, установлен или ip nat для исходного интерфейса или нет. И удалить эту конфигурационную запись вроде нельзя. Или можно? Точного ответа пока не нашел(

В общем - несмотря на то, что подсеть L и подсеть R прописаны в таблице статической маршрутизации роутера C, прописаны в настройках wireguard - для целей nat роутер считает эти сети неизвестными публичными (ну правильно, адрес интерфейса wireguard 10.220.100.1, а сеть за ним - 10.220.19.0/24) В итоге ip форвардинг не пашет.

Внимание, вопрос: кто-то сумел настроить сеть в такой конфигурации на кинетиках? Смену оборудования просьба не предлагать)

Разберусь сам - естественно напишу решение. Но как всегда хочется немного упростить задачу)))

Решение: всего час, и от пользователя stranneek получен совет, решивший проблему: на роутерах L и R нужно прописать в маршруты не только удаленные сети, но и подсети туннелей wireguard, ведущие к удаленным подсетям. Т.е. Не только 10.220.14.0/24, но и 10.220.100.0/24, в которой находятся два интерфейса wireguard 10.220.100.1 (на роутере C) и 10.220.100.2 (на роутере удаленной подсети). Спасибо огромное! Думаю, эта инфа кому-нибудь да сэкономит несколько часов)

З.Ы. Проверил - эти подсети должны быть и в настройках тоннеля wireguard, и в маршрутах. Всё со стороны удаленных сетей, в центре ничего прописывать не нужно

З.З.Ы. Да, все эти security-level и no isolate-private тоже не нужны. Достаточно в межсетевом экране на всех роутерах открыть нужные протоколы/порты на всех wireguard интерфейсах)

З.З.З.Ы. Еще полчаса экспериментов показали, что связь начинает работать, когда на роутере в подсети-получателе (т.е. не в той, из которой пингуем, а в той, которую пингуем) прописан маршрут до подсети wireguard отправителя. Ну и тогда вся логика сразу встала на свои места. nat никуда не делся, ip адрес отправителя путем SNAT поменялся на ip интерфейса wireguard, ну а роутер сети-получателя вообще не в курсе, что это за сеть и куда посылать к ней пакеты. И пока не пропишешь эту подсеть в настройках тоннеля и в маршрутизации - ничего не работает. Проверил show ip nat - и НЕТ! Нету этого коннекта в таблице nat на центральном роутере. В общем - полон загадок этот кинетик, но способ сделать полноценную распределенную сетку всё-таки есть)