add Russian lang (#529)
* add Russian lang support --------- Co-authored-by: 风扇滑翔翼 <Fangliding.fshxy@outlook.com>
@@ -0,0 +1,52 @@
|
||||
---
|
||||
sidebar: auto
|
||||
---
|
||||
# Быстрый старт
|
||||
|
||||
> **В этой главе вы узнаете, как максимально просто получить Xray и начать его использовать.**
|
||||
|
||||
## Загрузка и установка
|
||||
|
||||
Xray поддерживает разнообразные платформы, и вы можете получить разные версии Xray из множества источников и различными способами.
|
||||
|
||||
Перейдите в раздел [Загрузка и установка](./install.md), чтобы загрузить Xray.
|
||||
|
||||
## Настройка и запуск
|
||||
|
||||
После загрузки и установки Xray вам нужно всего лишь настроить его, чтобы начать использование.
|
||||
|
||||
Перейдите в раздел [Настройка и запуск](./config.md), чтобы изучить самый простой способ настройки.
|
||||
|
||||
## Команды и аргументы
|
||||
|
||||
Xray обладает множеством команд и аргументов, что делает его гибким и мощным.
|
||||
|
||||
Перейдите в раздел [Команды и аргументы](./command.md), чтобы узнать больше о командах и аргументах Xray.
|
||||
|
||||
## Улучшение документации
|
||||
|
||||
Если вы заинтересованы, перейдите в раздел [Использование документации](./document.md), чтобы помочь нам улучшить документацию, или нажмите кнопку `Помогите нам улучшить эту страницу!` внизу страницы.
|
||||
|
||||
Мы очень благодарны каждому участнику за вклад! Вы делаете Project X сильнее!
|
||||
|
||||
## Простыми словами
|
||||
|
||||
Практические советы для новичков.
|
||||
|
||||
Перейдите в раздел [Простыми словами](./level-0/) для просмотра.
|
||||
|
||||
## Базовые навыки
|
||||
|
||||
Освоив основы, вы можете перейти к разделу [Базовые навыки](./level-1/), чтобы узнать о других способах использования.
|
||||
|
||||
## Продвинутая документация
|
||||
|
||||
Практические советы для опытных пользователей.
|
||||
|
||||
Перейдите в раздел [Продвинутая документация](./level-2/) для просмотра.
|
||||
|
||||
::: tip Благодарность
|
||||
Огромное спасибо всем за то, что делитесь своими навыками и опытом, которые делают Xray с каждым днем лучше.
|
||||
:::
|
||||
|
||||
|
||||
@@ -0,0 +1,159 @@
|
||||
# Командные аргументы
|
||||
|
||||
::: tip
|
||||
Xray использует команды и аргументы в стиле Go.
|
||||
:::
|
||||
|
||||
## Базовые команды
|
||||
|
||||
Вы можете запустить `xray help`, чтобы получить список всех базовых команд Xray, а также их описание и примеры использования.
|
||||
|
||||
```
|
||||
Xray is a platform for building proxies.
|
||||
|
||||
Usage:
|
||||
|
||||
xray <command> [arguments]
|
||||
|
||||
The commands are:
|
||||
|
||||
run Run Xray with config, the default command
|
||||
version Show current version of Xray
|
||||
api Call an API in an Xray process
|
||||
tls TLS tools
|
||||
uuid Generate UUIDv4 or UUIDv5
|
||||
x25519 Generate key pair for x25519 key exchange
|
||||
wg Generate key pair for wireguard key exchange
|
||||
|
||||
Use "xray help <command>" for more information about a command.
|
||||
|
||||
```
|
||||
|
||||
### xray run
|
||||
|
||||
Запуск Xray с указанием одного или нескольких файлов конфигурации.
|
||||
|
||||
Использование:
|
||||
|
||||
```
|
||||
xray run [-c config.json] [-confdir dir]
|
||||
```
|
||||
|
||||
```
|
||||
Run Xray with config, the default command.
|
||||
|
||||
The -config=file, -c=file flags set the config files for
|
||||
Xray. Multiple assign is accepted.
|
||||
|
||||
The -confdir=dir flag sets a dir with multiple json config
|
||||
|
||||
The -format=json flag sets the format of config files.
|
||||
Default "auto".
|
||||
|
||||
The -test flag tells Xray to test config files only,
|
||||
without launching the server.
|
||||
|
||||
The -dump flag tells Xray to print the merged config.
|
||||
```
|
||||
|
||||
`-config=` / `-c=`: Указывает путь к файлу конфигурации, поддерживается использование нескольких файлов.
|
||||
`-confdir=`: Указывает путь к папке, содержащей несколько файлов конфигурации.
|
||||
`-format=`: Задает формат файлов конфигурации.
|
||||
`-test`: Проверяет корректность файлов конфигурации.
|
||||
`-dump`: Выводит объединенный результат слияния нескольких файлов конфигурации.
|
||||
|
||||
::: tip
|
||||
Помимо формата JSON по умолчанию, файлы конфигурации также могут быть в формате TOML или YAML. Если формат не указан явно, он определяется по расширению файла.
|
||||
:::
|
||||
|
||||
```
|
||||
xray run -dump
|
||||
```
|
||||
|
||||
Выводит результат слияния нескольких файлов конфигурации.
|
||||
|
||||
### xray version
|
||||
|
||||
Выводит информацию о версии Xray, версии Golang и т. д.
|
||||
|
||||
Использование:
|
||||
|
||||
```
|
||||
xray version
|
||||
```
|
||||
|
||||
### xray api
|
||||
|
||||
Вызов gRPC API Xray, который должен быть включен в файле конфигурации.
|
||||
|
||||
Использование:
|
||||
|
||||
```
|
||||
xray api <command> [arguments]
|
||||
```
|
||||
|
||||
```
|
||||
restartlogger Restart the logger
|
||||
stats Get statistics
|
||||
statsquery Query statistics
|
||||
statssys Get system statistics
|
||||
adi Add inbounds
|
||||
ado Add outbounds
|
||||
rmi Remove inbounds
|
||||
rmo Remove outbounds
|
||||
```
|
||||
|
||||
### xray tls
|
||||
|
||||
Инструменты для работы с TLS.
|
||||
|
||||
Использование:
|
||||
|
||||
```
|
||||
xray tls <command> [arguments]
|
||||
```
|
||||
|
||||
```
|
||||
cert Generate TLS certificates
|
||||
ping Ping the domain with TLS handshake
|
||||
certChainHash Calculate TLS certificates hash.
|
||||
```
|
||||
|
||||
### xray uuid
|
||||
|
||||
Генерация UUID.
|
||||
|
||||
Использование:
|
||||
|
||||
```
|
||||
xray uuid [-i "example"]
|
||||
```
|
||||
|
||||
### xray x25519
|
||||
|
||||
Генерация пары ключей x25519.
|
||||
|
||||
Использование:
|
||||
|
||||
```
|
||||
xray x25519 [-i "(base64.RawURLEncoding)" --std-encoding ]
|
||||
```
|
||||
|
||||
### xray wg
|
||||
|
||||
Генерация пары ключей curve25519 для WireGuard.
|
||||
|
||||
Использование:
|
||||
|
||||
```
|
||||
xray wg [-i "(base64.StdEncoding)"]
|
||||
```
|
||||
|
||||
::: tip
|
||||
Если `-config` не указан, Xray попытается загрузить `config.json` из следующих мест:
|
||||
|
||||
- Рабочий каталог (Working Directory);
|
||||
- Путь, указанный в переменной окружения `Xray.location.asset` (см. [Переменные окружения](../config/features/env.md#ресурсные-файлы)).
|
||||
:::
|
||||
|
||||
|
||||
@@ -0,0 +1,108 @@
|
||||
# Настройка и запуск
|
||||
|
||||
После того, как вы [скачали и установили](./install) Xray, вам потребуется его настроить.
|
||||
|
||||
В данном руководстве мы рассмотрим только простой способ настройки. Дополнительные шаблоны: [Xray-examples](https://github.com/XTLS/Xray-examples)
|
||||
|
||||
Для настройки более сложных функций обратитесь к подробным инструкциям в разделе [Файл конфигурации](../config/).
|
||||
|
||||
::: danger
|
||||
Во избежание расшифровки вашего трафика <br>
|
||||
следует сгенерировать уникальный UUID с помощью команды `xray uuid` или `uuidgen`, <br>
|
||||
который затем нужно вставить на стороне сервера в поле `inbounds[0].settings.clients[0].id`, <br>
|
||||
а на стороне клиента - в поле `outbounds[0].settings.vnext[0].users[0].id`. <br>
|
||||
:::
|
||||
|
||||
## Настройка сервера
|
||||
|
||||
Вам понадобится сервер с публичным IP-адресом (не за NAT), на котором будет запущен Xray. Конфигурация сервера:
|
||||
|
||||
```json
|
||||
{
|
||||
"inbounds": [
|
||||
{
|
||||
"port": 10086, // Порт, который слушает сервер
|
||||
"protocol": "vmess",
|
||||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "b831381d-6324-4d53-ad4f-8cda48b30811" // Не забудьте заменить это поле, сгенерировав UUID с помощью `xray uuid` или `uuidgen`
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
],
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Убедитесь, что `id` и порт в конфигурации сервера совпадают с настройками клиента, чтобы подключение работало correctamente.
|
||||
|
||||
## Настройка клиента
|
||||
|
||||
На вашем компьютере (или телефоне) необходимо запустить Xray со следующей конфигурацией:
|
||||
|
||||
```json
|
||||
{
|
||||
"inbounds": [
|
||||
{
|
||||
"port": 1080, // Порт SOCKS-прокси, на него нужно будет направлять трафик в браузере
|
||||
"listen": "127.0.0.1",
|
||||
"protocol": "socks",
|
||||
"settings": {
|
||||
"udp": true
|
||||
}
|
||||
}
|
||||
],
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "vmess",
|
||||
"settings": {
|
||||
"vnext": [
|
||||
{
|
||||
"address": "server", // Адрес сервера, замените его на IP-адрес или доменное имя вашего сервера
|
||||
"port": 10086, // Порт сервера
|
||||
"users": [
|
||||
{
|
||||
"id": "b831381d-6324-4d53-ad4f-8cda48b30811" // Не забудьте заменить это поле, сгенерировав UUID с помощью `xray uuid` или `uuidgen`
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"protocol": "freedom",
|
||||
"tag": "direct"
|
||||
}
|
||||
],
|
||||
"routing": {
|
||||
"domainStrategy": "IPOnDemand",
|
||||
"rules": [
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["geoip:private","geoip:cn"], // Исключить локальную сеть и диапазоны IP-адресов Китая
|
||||
"outboundTag": "direct"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
Единственное, что вам нужно изменить в приведенной выше конфигурации, - это IP-адрес вашего сервера и UUID пользователя, как указано в комментариях. Эта конфигурация будет перенаправлять весь трафик на ваш сервер, за исключением локальной сети (например, доступ к маршрутизатору) и диапазонов IP-адресов Китая (например, доступ к bilibili, acfun).
|
||||
|
||||
## Запуск
|
||||
|
||||
- В Windows и macOS файл конфигурации обычно находится в том же каталоге, что и Xray, и называется `config.json`.
|
||||
- Просто запустите `Xray` или `Xray.exe`.
|
||||
- В Linux файл конфигурации обычно находится в каталоге `/etc/xray/` или `/usr/local/etc/xray/`.
|
||||
- Запустите команду `xray run -c /etc/xray/config.json`.
|
||||
- Или используйте systemd или другой инструмент для запуска Xray как службы в фоновом режиме.
|
||||
|
||||
Более подробную информацию можно найти в [документации по конфигурации](../config/) и в разделе [Простыми словами](./level-0/).
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
# Вклад в документацию Project X
|
||||
|
||||
Мы приветствуем ваш вклад в документацию Project X и благодарим каждого контрибьютора за помощь! Вы делаете Xray лучше!
|
||||
|
||||
## Улучшение документации
|
||||
|
||||
Документация Project X размещена на [GitHub](https://github.com/XTLS/Xray-docs-next).
|
||||
|
||||
Вы можете внести изменения в документацию, выполнив следующие действия:
|
||||
|
||||
1. Откройте [репозиторий документации Project X](https://github.com/XTLS/Xray-docs-next), нажмите кнопку "Fork" в правом верхнем углу, чтобы создать копию репозитория документации в вашей учетной записи GitHub.
|
||||
|
||||
2. Используйте любой удобный инструмент для клонирования документации из вашего репозитория, например:
|
||||
|
||||
```
|
||||
git clone https://github.com/XTLS/Xray-docs-next.git
|
||||
```
|
||||
|
||||
3. Создайте новую ветку на основе ветки `main`, например:
|
||||
|
||||
```
|
||||
git checkout -b your-branch
|
||||
```
|
||||
|
||||
4. Внесите изменения в новую ветку.
|
||||
|
||||
Примечание: рекомендуем придерживаться [Руководства по оформлению текстов на китайском языке](https://github.com/sparanoid/chinese-copywriting-guidelines) (на китайском).
|
||||
|
||||
5. После внесения изменений отформатируйте их с помощью [Prettier](https://prettier.io/docs/en/install.html).
|
||||
|
||||
Примечание: запросы на включение (PR) с ошибками форматирования могут быть отклонены.
|
||||
|
||||
6. Зафиксируйте изменения и отправьте их в ваш репозиторий:
|
||||
|
||||
```
|
||||
git push -u origin your-branch
|
||||
```
|
||||
|
||||
7. Откройте GitHub, перейдите в раздел "Pull requests" и создайте новый запрос на включение (PR) в [репозиторий документации Project X](https://github.com/XTLS/Xray-docs-next).
|
||||
|
||||
8. В заголовке и описании PR кратко опишите внесенные изменения.
|
||||
|
||||
9. Дождитесь ответа. Если ваш PR будет принят, изменения появятся на [сайте документации Project X](https://xtls.github.io).
|
||||
|
||||
## Нашли ошибку?
|
||||
|
||||
Если вы обнаружили ошибку в документации, вы можете внести исправления или создать задачу (Issue).
|
||||
|
||||
|
||||
@@ -0,0 +1,119 @@
|
||||
# Загрузка и установка
|
||||
|
||||
## Поддерживаемые платформы
|
||||
|
||||
Xray доступен на следующих платформах:
|
||||
|
||||
- Windows 7 и выше (x86 / amd64 / arm32 / arm64);
|
||||
- macOS 10.10 Yosemite и выше (amd64 / arm64);
|
||||
- Linux 2.6.23 и выше (x86 / amd64 / arm / arm64 / mips64 / mips / ppc64 / s390x / riscv64);
|
||||
- Включая, но не ограничиваясь: Debian 7 / 8, Ubuntu 12.04 / 14.04 и выше, CentOS 7 / 8, Arch Linux и др.;
|
||||
- FreeBSD (x86 / amd64);
|
||||
- OpenBSD (x86 / amd64);
|
||||
- Dragonfly BSD (amd64);
|
||||
|
||||
## Загрузка Xray
|
||||
|
||||
Предварительно скомпилированные ZIP-архивы с двоичными файлами можно найти в [Github Releases](https://github.com/xtls/Xray-core/releases).
|
||||
|
||||
Скачайте архив для своей платформы, распакуйте его и можете использовать.
|
||||
|
||||
## Проверка установочного пакета
|
||||
|
||||
Xray предлагает два способа проверки:
|
||||
|
||||
- SHA1 / SHA256 хэш-сумма ZIP-архива;
|
||||
- Воспроизводимая сборка: см. [Сборка Xray](../development/intro/compile.md).
|
||||
|
||||
## Установка на Windows
|
||||
|
||||
- Скачайте ZIP-архив для Windows на [Github Releases](https://github.com/xtls/Xray-core/releases), распакуйте его, чтобы получить исполняемый файл `xray.exe`, а затем [запустите его из командной строки с параметрами](./command).
|
||||
- Установите с помощью менеджера пакетов [Scoop](https://scoop.sh): Xray был добавлен в [Mochi](https://github.com/Qv2ray/mochi).
|
||||
|
||||
## Установка на macOS
|
||||
|
||||
- Скачайте ZIP-архив для macOS на [Github Releases](https://github.com/xtls/Xray-core/releases), распакуйте его, чтобы получить исполняемый файл `xray`, а затем [запустите его из командной строки с параметрами](./command.md).
|
||||
- Установите с помощью менеджера пакетов [Homebrew](https://brew.sh): `brew install xray`.
|
||||
- [homebrew-xray](https://github.com/N4FA/homebrew-xray) Спасибо, [@N4FA](https://github.com/N4FA)!
|
||||
|
||||
## Установка на Linux
|
||||
|
||||
### Установочные скрипты
|
||||
|
||||
- Linux Script
|
||||
|
||||
- [Xray-install](https://github.com/XTLS/Xray-install)
|
||||
|
||||
* One Click
|
||||
|
||||
- [Xray-script](https://github.com/kirin10000/Xray-script)
|
||||
- [ProxySU](https://github.com/proxysu/ProxySU)
|
||||
- [v2ray-agent](https://github.com/reeceyng/v2ray-agent) Спасибо, [@mack-a](https://github.com/mack-a) [@Reece](https://github.com/reeceyng)!
|
||||
- [Xray-yes](https://github.com/jiuqi9997/Xray-yes)
|
||||
- [Xray-onekey](https://github.com/wulabing/Xray_onekey)
|
||||
|
||||
* Magisk
|
||||
- [Xray4Magisk](https://github.com/CerteKim/Xray4Magisk)
|
||||
- [Xray_For_Magisk](https://github.com/E7KMbb/Xray_For_Magisk)
|
||||
|
||||
### Arch Linux
|
||||
|
||||
#### Arch User Repository
|
||||
|
||||
Требуется [помощник AUR](https://wiki.archlinux.org/index.php/AUR_helpers), например, [yay](https://github.com/Jguer/yay), установка с помощью команды `yay -S xray`.
|
||||
|
||||
#### Arch Linux CN
|
||||
|
||||
Сначала добавьте [репозиторий Arch Linux CN](https://www.archlinuxcn.org/archlinux-cn-repo-and-mirror/), затем установите от имени пользователя root с помощью команды `pacman -S xray`.
|
||||
|
||||
### Linuxbrew
|
||||
|
||||
Использование менеджера пакетов Linuxbrew аналогично Homebrew: `brew install xray`.
|
||||
|
||||
### Debian <Badge text="WIP" type="warning"/>
|
||||
|
||||
### Gentoo
|
||||
|
||||
В настоящее время существует три оверлея сторонних разработчиков, которые предоставляют сценарии установки Portage:
|
||||
|
||||
- [CHN-beta/touchfish-os](https://github.com/gentoo-mirror/touchfish-os/tree/master/net-proxy/Xray): Поддерживается отдельным пользователем, подходит для систем с systemD.
|
||||
- [Gentoo-zh](https://github.com/microcai/gentoo-zh): Поддерживается сообществом, подходит для систем с systemD.
|
||||
- [JuanCldCmt/Xray-Overlay](https://github.com/JuanCldCmt/Xray-Overlay): Поддерживается отдельным пользователем, подходит для систем с openRC, использует группу пользователей xray для повышения безопасности.
|
||||
|
||||
Добавьте оверлей в локальную систему с помощью layman или eselect-repository, а затем выполните установку.
|
||||
|
||||
## Установка с помощью Docker
|
||||
|
||||
- [teddysun/xray](https://hub.docker.com/r/teddysun/xray)
|
||||
|
||||
### Файловая структура образа Docker
|
||||
|
||||
- `/etc/xray/config.json`: файл конфигурации;
|
||||
- `/usr/bin/xray`: основная программа Xray;
|
||||
- `/usr/share/xray/geoip.dat`: файл данных IP;
|
||||
- `/usr/share/xray/geosite.dat`: файл данных доменных имен.
|
||||
|
||||
# Графические клиенты
|
||||
|
||||
- OpenWrt
|
||||
- [PassWall](https://github.com/xiaorouji/openwrt-passwall)
|
||||
- [Hello World](https://github.com/jerrykuku/luci-app-vssr)
|
||||
- [ShadowSocksR Plus+](https://github.com/fw876/helloworld)
|
||||
- [luci-app-xray](https://github.com/yichya/luci-app-xray) ([openwrt-xray](https://github.com/yichya/openwrt-xray))
|
||||
- Windows
|
||||
- [v2rayN](https://github.com/2dust/v2rayN)
|
||||
- [Qv2ray](https://github.com/Qv2ray/Qv2ray) (проект заморожен и архивирован)
|
||||
- [Netch (NetFilter & TUN/TAP)](https://github.com/NetchX/Netch) (проект заморожен и архивирован)
|
||||
- Android
|
||||
- [v2rayNG](https://github.com/2dust/v2rayNG)
|
||||
- [Kitsunebi](https://github.com/rurirei/Kitsunebi/tree/release_xtls)
|
||||
- iOS / macOS (с чипом ARM)
|
||||
- [Shadowrocket](https://apps.apple.com/app/shadowrocket/id932747118)
|
||||
- [Stash](https://apps.apple.com/app/stash/id1596063349)
|
||||
- macOS (чип X86 / ARM)
|
||||
- [Qv2ray](https://github.com/Qv2ray/Qv2ray) (проект заморожен и архивирован)
|
||||
- [V2RayXS](https://github.com/tzmax/V2RayXS)
|
||||
|
||||
# Генератор UUID
|
||||
|
||||
Генератор UUID от сторонних разработчиков: [uuidgenerator.net](https://www.uuidgenerator.net)
|
||||
@@ -0,0 +1,25 @@
|
||||
# Простые разговоры о сложном
|
||||
|
||||
**Эта глава - базовый курс «С нуля», новичкам читать и учить обязательно**
|
||||
|
||||
::: tip
|
||||
Сделано с ❤️ [@ricuhkaen](https://github.com/ricuhkaen)
|
||||
:::
|
||||
|
||||
[【Глава 1】 Введение](./ch01-preface.md) - Чужой или свой сервер? Вот в чём вопрос
|
||||
|
||||
[【Глава 2】 Подготовка](./ch02-preparation.md) - Прежде чем браться за дело, заготовь средства
|
||||
|
||||
[【Глава 3】 Удалённое подключение](./ch03-ssh.md) - Мост между севером и югом, пропасть превращается в путь
|
||||
|
||||
[【Глава 4】 Безопасность](./ch04-security.md) - Небрежность в безопасности, и родные будут лить слёзы
|
||||
|
||||
[【Глава 5】 Создание сайта](./ch05-webpage.md) - Покажи свою красоту
|
||||
|
||||
[【Глава 6】 Управление сертификатами](./ch06-certificates.md) - Законно то, что с лицензией
|
||||
|
||||
[【Глава 7】 Xray сервер](./ch07-xray-server.md) - Наконец-то дождались
|
||||
|
||||
[【Глава 8】 Xray клиенты](./ch08-xray-clients.md) - Новое начало
|
||||
|
||||
[【Глава 9】 Приложение](./ch09-appendix.md) - Все контрольные точки здесь
|
||||
|
After Width: | Height: | Size: 161 KiB |
@@ -0,0 +1,99 @@
|
||||
# 【Глава 1】 Простыми словами
|
||||
|
||||
## 1.1 Для кого эта документация?
|
||||
|
||||
В двух словах: для **① новичков без опыта** **② желающих научиться настраивать свой собственный VPS**.
|
||||
|
||||
## 1.2 Для кого эта документация не предназначена?
|
||||
|
||||
В том числе, но не ограничиваясь: для всевозможных гуру и экспертов, для тех, кто слишком ленив, чтобы во всём разбираться самостоятельно, для тех, кто уже умеет настраивать VPS, для тех, кто точно решил пользоваться платными VPN-сервисами, для тех, кто предпочитает использовать готовые скрипты... Короче говоря, если у вас есть технические знания или вы не хотите настраивать всё сами, можете смело закрывать эту статью. Скорее всего, она покажется вам бесполезной и даже может вызвать раздражение, а оно вам надо?
|
||||
|
||||
## 1.3 Важное замечание и другие примечания
|
||||
|
||||
**Важное замечание:**
|
||||
|
||||
Я не являюсь техническим экспертом, поэтому в этой статье неизбежны пробелы и неточности. Если вы обнаружите какие-либо ошибки, пожалуйста, дайте мне знать об этом деликатно, без лишних эмоций.
|
||||
|
||||
**Отказ от ответственности:**
|
||||
|
||||
Пожалуйста, относитесь к информации, представленной в этой статье, критически и проверяйте её самостоятельно. Я не несу никакой ответственности за любые проблемы или негативные последствия, возникшие в результате использования информации из этой статьи.
|
||||
|
||||
**Предупреждение о многословности:**
|
||||
|
||||
Поскольку эта статья предназначена для **новичков без опыта**, многие вещи будут объяснены максимально подробно. Поэтому будьте готовы к тому, что текст будет довольно многословным.
|
||||
|
||||
## 1.4 Почему самостоятельная настройка — это сложно?
|
||||
|
||||
Чтобы ответить на этот вопрос, нужно немного углубиться в историю вопроса.
|
||||
|
||||
Во-первых, обход блокировок существует уже почти двадцать лет (Шок! Ужас!). Сначала для этого достаточно было пары манипуляций (поправить файл hosts, подключиться по SSH), потом понадобились веб-прокси, затем — собственные протоколы (например, Shadowsocks) и так далее.
|
||||
|
||||
По мере того, как технологии блокировок совершенствовались на протяжении последних десятилетий, для самостоятельного обхода блокировок теперь нужно уметь:
|
||||
|
||||
- Разбираться в основных командах Linux.
|
||||
- Понимать принципы работы сетевых протоколов.
|
||||
- Иметь технические навыки и средства для покупки и управления VPS.
|
||||
- Иметь технические навыки и средства для покупки и управления доменными именами.
|
||||
- Уметь получать TLS-сертификаты.
|
||||
- И многое другое.
|
||||
|
||||
Всё это превратило некогда простую задачу в пугающее испытание для новичков.
|
||||
|
||||
Во-вторых, о проблемах новичков.
|
||||
|
||||
Начинающим пользователям без технического бэкграунда, чтобы разобраться во всех этих премудростях, приходится изучать огромные массивы информации, разбросанной по всему интернету: блогам, форумам, группам в мессенджерах, репозиториям на GitHub, видео на YouTube и так далее.
|
||||
|
||||
Вся эта информация часто оказывается противоречивой, неполной или попросту неверной. Новичкам остаётся только гадать, кому верить и как всё это работает на самом деле.
|
||||
|
||||
В итоге вместо нехватки информации новички сталкиваются с её избытком. После нескольких (скорее всего, неудачных) попыток разобраться во всём этом, их энтузиазм угасает. А если по пути им ещё и «посчастливится» обратиться за помощью не в то место, их могут ещё и высмеять: «Ну ты и нуб, проще уж платным VPN пользоваться, зачем изобретать велосипед?» или «Сначала Linux изучи, потом приходи».
|
||||
|
||||
В такие моменты остаётся только горько усмехнуться.
|
||||
|
||||
## 1.5 «Почему бы просто не пользоваться платным VPN?»
|
||||
|
||||
Во-первых, я хотел бы спросить у любителей подобных советов: разве платные VPN — это панацея?
|
||||
|
||||
Во-вторых, я считаю, что «не знать» и «не хотеть знать» — это две большие разницы. Конечно, инфантилы, которые хотят всё и сразу, не прилагая никаких усилий, вызывают только раздражение. Но люди, которые искренне хотят разобраться во всём сами, не заслуживают презрения и издёвок. Именно эта нетерпимость к новичкам и побудила меня написать эту статью.
|
||||
|
||||
Давайте разберёмся, в чём плюсы и минусы платных VPN-сервисов.
|
||||
|
||||
**Плюсы:**
|
||||
|
||||
1. **Простота использования:** сканирование QR-кода, добавление правил в один клик и т.д.
|
||||
2. **Большой выбор серверов:** доступ к ресурсам разных стран и регионов; например, выделенные серверы с низкой задержкой (iplc), серверы для онлайн-игр и т.д.
|
||||
3. **Множество точек подключения:** выше устойчивость к блокировкам, если один сервер заблокируют, можно подключиться к другому.
|
||||
|
||||
**Риски:**
|
||||
|
||||
За удобство приходится платить, и в случае с платными VPN-сервисами риски следующие:
|
||||
|
||||
1. **VPN-провайдер имеет полный доступ к вашим данным:** всё, что вы делаете в интернете, **обязательно** проходит и **с большой вероятностью** хранится на серверах провайдера. Эти данные никак не защищены пользовательским соглашением или законом о защите персональных данных **(вас могут отслеживать и записывать всё, что вы делаете)**.
|
||||
2. **Отсутствие регулирования рынка:** высока вероятность нарваться на мошенников **(провайдер может в любой момент исчезнуть с вашими деньгами)**.
|
||||
3. **Давление со стороны регулирующих органов:** крупные VPN-провайдеры, с одной стороны, кажутся более надёжными, но, с другой стороны, чаще привлекают к себе внимание властей. В 2020 году было несколько случаев закрытия и прекращения работы крупных VPN-провайдеров, что привело к серьёзным неудобствам для пользователей **(провайдер может быть вынужден прекратить работу)**.
|
||||
4. **Непрозрачность технических решений:** качество предоставляемых услуг может сильно варьироваться, не редки случаи обмана **(низкая скорость, частые обрывы связи, невозможность подключения)**.
|
||||
|
||||
## 1.6 Так стоит ли настраивать VPN самостоятельно?
|
||||
|
||||
Теперь, когда вы знаете о плюсах и минусах платных VPN, решать вам. В конце концов, лучший вариант — тот, который подходит именно вам.
|
||||
|
||||

|
||||
|
||||
1. Если вы решили воспользоваться платным VPN, можете закрыть эту статью.
|
||||
|
||||
2. Если же вы решили настроить всё самостоятельно, продолжайте чтение!
|
||||
|
||||
Цель этой статьи — стать отправной точкой для новичков, предоставить подробное пошаговое руководство по настройке VPN-сервера на VPS, начиная **с ввода первой команды** и заканчивая **успешным подключением к заблокированным ресурсам**.
|
||||
|
||||
В процессе настройки вы познакомитесь с основными командами Linux, что станет хорошей базой для дальнейшего изучения этой операционной системы.
|
||||
|
||||
## 1.7 Немного лирики
|
||||
|
||||
1. В интернете много дезинформации, поэтому важно научиться критически мыслить, не поддаваться на провокации и не верить всему, что пишут.
|
||||
2. Искренне надеюсь, что, получив доступ к свободному интернету, вы сможете узнавать больше нового, наслаждаться разнообразным контентом, знакомиться с интересными людьми и находить единомышленников.
|
||||
3. Ваша личность в интернете — это всё ещё вы. Добиться полной анонимности крайне сложно, поэтому не забывайте о законах вашей страны и стран, IP-адреса которых вы используете. Всегда помните о собственной безопасности.
|
||||
|
||||
## 1.8 Ваш прогресс
|
||||
|
||||
> ⬛⬜⬜⬜⬜⬜⬜⬜ 12.5%
|
||||
|
||||
|
||||
|
After Width: | Height: | Size: 55 KiB |
@@ -0,0 +1,57 @@
|
||||
# 【Глава 2】 Подготовка
|
||||
|
||||
Эта глава особенная, поскольку затрагивает финансовые операции. В соответствии с нейтральной позицией проекта, здесь не будет конкретных рекомендаций. Всё, что я могу сделать, — это рассказать, что вам понадобится.
|
||||
|
||||
## 2.1 Приобретение VPS
|
||||
|
||||
Вам нужно получить работающий VPS с не заблокированным IP-адресом и выполнить следующие базовые действия в панели управления:
|
||||
|
||||
1. Установить на VPS операционную систему Debian 10 64-bit.
|
||||
2. Записать IP-адрес VPS (в этой статье он будет обозначаться как `"100.200.300.400"`).
|
||||
::: tip
|
||||
Это **неверный** IP-адрес, используемый только в качестве примера. Не забудьте заменить его на свой реальный IP-адрес.
|
||||
:::
|
||||
3. Записать порт (Port) SSH для удалённого подключения к VPS.
|
||||
4. Записать имя пользователя и пароль для удалённого подключения по SSH.
|
||||
|
||||
Выбор и покупка VPS — дело непростое. Рекомендуем сначала изучить этот вопрос и выбрать тариф, который соответствует вашим финансовым возможностям и требованиям к скорости и качеству связи. Также можно воспользоваться бесплатными (постоянными или временными) предложениями от крупных облачных провайдеров, таких как Oracle Cloud и Google Cloud. Главное — не влезайте в долги.
|
||||
|
||||
::: tip Пояснение
|
||||
Несколько слов о выборе Debian 10 в качестве операционной системы. Что бы вы ни слышали в интернете, какой бы дистрибутив Linux ни советовали вам гуру, все эти споры о том, какой Linux лучше, **не имеют к вам никакого отношения**! Debian 10 — это надёжная и стабильная операционная система, которая отлично подходит для работы VPN-сервера и достаточно оптимизирована (например, имеет специальное ядро для облачных сред и своевременную поддержку BBR). Когда вы освоитесь с Linux, можете попробовать и другие дистрибутивы.
|
||||
:::
|
||||
|
||||
## 2.2 Выбор доменного имени
|
||||
|
||||
Вам нужно получить доменное имя и добавить A-запись, указывающую на IP-адрес вашего VPS, в настройках DNS.
|
||||
|
||||
1. Выберите надёжного международного регистратора доменных имён. Доменная зона (расширение домена) может быть любой, главное — не используйте `.cn`.
|
||||
2. В настройках DNS добавьте A-запись, указывающую на IP-адрес вашего VPS (имя A-записи может быть любым, в этой статье оно будет обозначаться как `"a-name"`. Полное доменное имя будет выглядеть как `"a-name.yourdomain.com"`). Должно получиться примерно так:
|
||||
|
||||

|
||||
|
||||
::: tip
|
||||
Это **не** настоящий URL-адрес. Не забудьте заменить его на свой реальный адрес.
|
||||
:::
|
||||
|
||||
## 2.3 Необходимое программное обеспечение
|
||||
|
||||
1. SSH-клиент для удалённого подключения:
|
||||
|
||||
- Windows: [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html)
|
||||
- macOS/Linux: Terminal
|
||||
|
||||
2. Программа для передачи файлов:
|
||||
|
||||
- Windows: [WinSCP](https://winscp.net/eng/index.php)
|
||||
- macOS/Linux: Terminal
|
||||
|
||||
3. Хороший текстовый редактор:
|
||||
- Windows/macOS/Linux: [VSCode](https://code.visualstudio.com)
|
||||
|
||||
## 2.4 Ваш прогресс
|
||||
|
||||
Если вы выполнили все пункты из этого раздела, у вас уже есть всё необходимое, чтобы открыть для себя новый мир. Так чего же мы ждём? Давайте перейдём к следующей главе и сделаем это!
|
||||
|
||||
> ⬛⬛⬜⬜⬜⬜⬜⬜ 25%
|
||||
|
||||
|
||||
|
After Width: | Height: | Size: 91 KiB |
|
After Width: | Height: | Size: 50 KiB |
|
After Width: | Height: | Size: 58 KiB |
|
After Width: | Height: | Size: 19 KiB |
|
After Width: | Height: | Size: 25 KiB |
|
After Width: | Height: | Size: 3.1 MiB |
@@ -0,0 +1,87 @@
|
||||
# 【Глава 3】 Удалённое подключение
|
||||
|
||||
## 3.1 Удалённое подключение к VPS (PuTTY)
|
||||
|
||||
Во-первых, поскольку Windows является самой распространённой операционной системой среди новичков, в этой статье мы будем использовать её в качестве примера.
|
||||
|
||||
Во-вторых, хотя PowerShell и WSL в Windows 10 и выше также предоставляют удобные инструменты для работы по SSH, не все версии Windows имеют эти компоненты. Поэтому в этой статье мы рассмотрим подключение по SSH с помощью старого доброго PuTTY. (После подключения по SSH действия во всех программах будут одинаковыми.)
|
||||
|
||||
Итак, давайте начнём.
|
||||
|
||||
1. Перейдите на [официальный сайт](https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html) PuTTY и скачайте версию, подходящую для вашей операционной системы (в этой статье мы будем использовать 64-битную версию).
|
||||
|
||||

|
||||
|
||||
2. Запустите PuTTY. Откроется главное окно программы. Теперь возьмите [блокнот](./ch02-preparation.md#21-получение-vps), в который вы записывали информацию в предыдущей главе, и введите **IP-адрес** и **порт** вашего VPS в соответствующие поля (на скриншоте ниже). Чтобы не вводить эти данные каждый раз, можно сохранить сеанс (Saved Sessions). В дальнейшем вы сможете загрузить сохранённые настройки одним кликом.
|
||||
|
||||

|
||||
|
||||
3. Рекомендуем установить значение `keepalive` в разделе `Connection` равным `60` секундам, чтобы предотвратить разрыв SSH-соединения, если вы долгое время не будете выполнять никаких действий. Не забудьте снова сохранить настройки.
|
||||
|
||||

|
||||
|
||||
::: warning Внимание
|
||||
После любых изменений настроек PuTTY необходимо сохранить сеанс, иначе они будут потеряны при закрытии программы.
|
||||
:::
|
||||
|
||||
4. Нажмите кнопку "Open", чтобы открыть окно SSH-подключения. Введите имя пользователя и пароль для подключения к вашему VPS (в этой статье предполагается, что имя пользователя по умолчанию — `root`. Обратите внимание, что при вводе пароля в Linux не отображаются символы `******`. Это сделано для того, чтобы скрыть длину пароля. Не пугайтесь, ваша клавиатура в порядке!).
|
||||
|
||||

|
||||
|
||||
## 3.2 Успешное подключение по SSH! Знакомство с командной строкой!
|
||||
|
||||
1. Если вы всё сделали правильно, вы увидите примерно такой экран, как на рисунке ниже. Это означает, что вы успешно подключились к серверу:
|
||||
|
||||

|
||||
|
||||
Этот экран — аналог «рабочего стола» на удалённом сервере, но здесь нет привычных значков, курсора мыши и ярких цветов. Только текст. Это и есть **командная строка** — *Command Line Interface* или сокращённо *CLI*.
|
||||
|
||||
Все дальнейшие действия вам придётся выполнять в командной строке, как хакер в кино. Возможно, поначалу это покажется вам непривычным, но поверьте, в использовании командной строки нет ничего страшного или сложного. По сути, это всего лишь способ взаимодействия с компьютером с помощью текстовых команд вместо графического интерфейса. **Вы пишете команду, а компьютер её выполняет.**
|
||||
|
||||
2. Теперь можете немного осмотреться и познакомиться с командной строкой. На этом экране уже есть полезная информация, например, версия ядра системы (в данном случае `4.19.37-5`), время последнего входа в систему, IP-адрес и т.д. Конечно, в зависимости от VPS, ваш экран может выглядеть немного иначе.
|
||||
|
||||
3. Обратите внимание на последнюю строку командной строки. Слева от мигающего курсора находится набор символов. В данном случае это `root@vps-server:~#`. Что это значит? Всё просто:
|
||||
|
||||
- Текущий пользователь: `root`.
|
||||
- Имя сервера, на котором работает пользователь `root`: `vps-server`.
|
||||
- Текущий каталог, в котором находится пользователь `root`: `~`.
|
||||
- Символ `#` указывает на то, что после него можно вводить команды.
|
||||
|
||||
Первые два пункта интуитивно понятны и не требуют пояснений. Третий пункт относится к файловой системе Linux. Сейчас вам не нужно вдаваться в подробности, достаточно знать, что `~` — это «домашний каталог» текущего пользователя. Четвёртый пункт, символ `#`, также не требует особого внимания. Просто знайте, что в дальнейшем все команды, которые вам нужно будет вводить, будут начинаться с `#` или `$`. Это будет означать, что **после** этого символа нужно ввести команду (поэтому при копировании команд **копируйте только текст после**, без символа `#` или `$`).
|
||||
|
||||
## 3.3 Первое обновление программного обеспечения Linux!
|
||||
|
||||
1. Так же, как и ваш телефон, будь то Android или iPhone, Linux нуждается в регулярном обновлении программного обеспечения для получения исправлений безопасности и новых функций. В Linux каждое приложение называется «пакетом» (package). А программа, которая управляет пакетами, называется «менеджером пакетов» (Package Manager). С помощью менеджера пакетов можно устанавливать, обновлять и удалять программы, а также обновлять саму систему Linux. Менеджеры пакетов Linux очень мощные, но сейчас вам достаточно знать, что в Debian используется менеджер пакетов `apt`. Давайте обновим систему с помощью `apt`, чтобы вы познакомились с его основными функциями.
|
||||
|
||||
2. Базовые команды Linux:
|
||||
|
||||
| Номер | Команда | Описание |
|
||||
| :----: | :----------: | :----------------- |
|
||||
| `cmd-01` | `apt update` | Проверить обновления |
|
||||
| `cmd-02` | `apt upgrade` | Установить обновления|
|
||||
|
||||
3. Введите первую команду, чтобы получить информацию об обновлениях:
|
||||
|
||||
```shell
|
||||
apt update
|
||||
```
|
||||
|
||||
4. Затем введите вторую команду. При появлении запроса на подтверждение установки `(Y/n)` введите `y` и нажмите Enter, чтобы начать установку.
|
||||
|
||||
```shell
|
||||
apt upgrade
|
||||
```
|
||||
|
||||
5. Весь процесс показан на гифке ниже:
|
||||
|
||||

|
||||
|
||||
## 3.4 Ваш прогресс
|
||||
|
||||
**Поздравляем, вы сделали ещё один важный шаг!** Теперь вы умеете подключаться к своему серверу по SSH! Но что делать после подключения, кроме обновления системы? Узнаем в следующей главе!
|
||||
|
||||
> ⬛⬛⬛⬜⬜⬜⬜⬜ 37.5%
|
||||
|
||||
|
||||
|
||||
|
||||
|
After Width: | Height: | Size: 44 KiB |
|
After Width: | Height: | Size: 95 KiB |
|
After Width: | Height: | Size: 36 KiB |
|
After Width: | Height: | Size: 46 KiB |
|
After Width: | Height: | Size: 120 KiB |
|
After Width: | Height: | Size: 77 KiB |
|
After Width: | Height: | Size: 52 KiB |
|
After Width: | Height: | Size: 61 KiB |
|
After Width: | Height: | Size: 104 KiB |
|
After Width: | Height: | Size: 50 KiB |
|
After Width: | Height: | Size: 104 KiB |
|
After Width: | Height: | Size: 114 KiB |
|
After Width: | Height: | Size: 143 KiB |
|
After Width: | Height: | Size: 134 KiB |
|
After Width: | Height: | Size: 141 KiB |
|
After Width: | Height: | Size: 961 KiB |
|
After Width: | Height: | Size: 112 KiB |
|
After Width: | Height: | Size: 62 KiB |
|
After Width: | Height: | Size: 30 KiB |
|
After Width: | Height: | Size: 193 KiB |
@@ -0,0 +1,332 @@
|
||||
# 【Глава 4】 Обеспечение безопасности
|
||||
|
||||
## 4.1 Зачем нужна безопасность?
|
||||
|
||||
Безопасность Linux-серверов — это обширная и сложная тема. Бесчисленные веб-сайты, приложения, сервисы и даже критически важная инфраструктура построены на базе Linux. За всем этим стоят огромные деньги и коммерческие интересы, что, естественно, привлекает злоумышленников. В то же время надёжная работа этих сервисов крайне важна, поэтому любые серьёзные уязвимости недопустимы. Именно поэтому множество специалистов по безопасности изо дня в день ведут борьбу на передовой, обеспечивая стабильную работу цифрового мира, к которому мы все привыкли.
|
||||
|
||||
Теперь, когда у вас есть собственный VPS-сервер, и вы собираетесь открыть на нём порты для перенаправления трафика, вы фактически оказываетесь на передовой этой борьбы и подвергаетесь тем же рискам. В то же время, новички, не обладающие достаточными знаниями и информацией, склонны впадать в крайности: либо они считают, что им ничего не угрожает, либо же, наоборот, впадают в паранойю.
|
||||
|
||||
- Первым я бы посоветовал не относиться к безопасности легкомысленно и изучить этот вопрос более подробно, чтобы потом не пришлось кусать локти.
|
||||
|
||||
- Вторым я бы посоветовал не паниковать. Ваш сервер вряд ли представляет собой лакомую цель для серьёзных злоумышленников, поэтому вам достаточно базовых мер защиты от автоматических сканеров и ботов, о которых мы и поговорим в этой главе.
|
||||
|
||||
## 4.2 Какие именно риски существуют?
|
||||
|
||||
Как мы уже говорили в главе про удалённое подключение, для доступа к вашему VPS достаточно знать четыре вещи: **IP-адрес**, **порт**, **имя пользователя** и **пароль**. Очевидно, что эти четыре элемента нужно защищать в первую очередь. Давайте разберём каждый из них:
|
||||
|
||||
1. **IP-адрес**: злоумышленники могут сканировать целые диапазоны IP-адресов в поисках уязвимых серверов. Ваш IP-адрес — это публичная информация, которую невозможно скрыть.
|
||||
|
||||
2. **Порт**: если вы используете настройки по умолчанию, то порт SSH равен `22`.
|
||||
|
||||
3. **Имя пользователя**: если вы используете настройки по умолчанию, то имя пользователя — `root`.
|
||||
|
||||
4. **Пароль**: пароль не имеет значения по умолчанию. Он либо генерируется автоматически при создании VPS, либо задаётся вами. Таким образом, если вы не меняли настройки сервера, то три из четырёх элементов уже известны злоумышленникам, и вся безопасность вашего сервера держится на одном только пароле. Возможны следующие варианты:
|
||||
|
||||
- Вы используете автоматически сгенерированный пароль из панели управления VPS. Такие пароли обычно состоят из случайного набора символов (букв в разных регистрах, цифр и спецсимволов) и достаточно надёжны.
|
||||
|
||||
- Вы установили простой пароль, например, `123456`. Взломать такой сервер не составит труда.
|
||||
|
||||
- Вы установили сложный пароль, который используете где-то ещё. Это тоже небезопасно. Злоумышленники используют специальные программы, которые перебирают миллионы ранее скомпрометированных паролей из утечек данных.
|
||||
|
||||
5. Важно понимать, что никакой хакер не будет лично подбирать ваш пароль. Все атаки выполняются автоматически с помощью специальных скриптов, которые работают круглосуточно. Пока вы спите, ваш сервер может подвергаться атакам.
|
||||
|
||||
Если пароль будет подобран, злоумышленники получат полный доступ к вашему серверу (права пользователя `root`), смогут установить на него вредоносное ПО и использовать его в своих целях (например, для майнинга криптовалюты, рассылки спама, фишинговых атак, организации торрент-трекера, размещения публичных узлов для доступа к даркнету и т.д.). При этом злоумышленники могут действовать очень скрытно, и вы даже не заметите, что ваш сервер взломан, пока не получите уведомление от хостинг-провайдера о блокировке вашего аккаунта или, что ещё хуже, повестку в суд.
|
||||
|
||||
6. Не забывайте, что при покупке VPS вы, скорее всего, указывали свои реальные платёжные данные. А при посещении сайтов и использовании социальных сетей ваш IP-адрес также сохраняется. Всё это может быть использовано против вас. **Поэтому, если на вашем сервере произойдёт что-то противозаконное, отвечать за это придётся вам.**
|
||||
|
||||
## 4.3 Какие меры безопасности нужно предпринять?
|
||||
|
||||
Исходя из всего вышесказанного, нам нужно защитить **порт**, **имя пользователя** и **пароль**, чтобы снизить риск взлома. Для этого необходимо:
|
||||
|
||||
1. Изменить порт SSH на **нестандартный** (отличный от 22) (см. раздел 4.4).
|
||||
2. Создать **нового пользователя** (не `root`) и **запретить удалённое подключение по SSH** для пользователя `root` (см. разделы 4.5 и 4.6).
|
||||
3. Настроить **аутентификацию по SSH-ключам** и **запретить аутентификацию по паролю** (см. раздел 4.7).
|
||||
|
||||
Выполняйте эти действия по порядку, чтобы не оказаться случайно заблокированным на своём же сервере.
|
||||
|
||||
## 4.4 Изменение порта SSH
|
||||
|
||||
Давайте решим проблему с портом SSH, который по умолчанию равен `22` (обратите внимание: у некоторых хостинг-провайдеров порт SSH по умолчанию уже отличается от 22. В этом случае вы можете пропустить этот шаг, но можете и изменить порт ещё раз, следуя инструкциям ниже).
|
||||
|
||||
1. Базовые команды Linux:
|
||||
|
||||
| Номер | Команда | Описание |
|
||||
| :----: | :---------------- | :------------------------ |
|
||||
| `cmd-03` | `nano` | Текстовый редактор |
|
||||
| `cmd-04` | `systemctl restart` | Перезапуск службы |
|
||||
|
||||
2. Важные файлы конфигурации Linux:
|
||||
|
||||
| Номер | Путь к файлу | Описание |
|
||||
| :------ | :----------------------- | :------------------------- |
|
||||
| `conf-01` | `/etc/ssh/sshd_config` | Настройки SSH-сервера |
|
||||
|
||||
3. Первое, что нужно сделать, — это открыть файл настроек SSH-сервера (`/etc/ssh/sshd_config`) в текстовом редакторе `nano`. В Windows вы бы просто нашли этот файл и дважды кликнули по нему. А как это сделать в Linux? Если вы внимательно читали предыдущие разделы, то наверняка уже догадались! Правильно, нужно выполнить команду:
|
||||
|
||||
```shell
|
||||
nano /etc/ssh/sshd_config
|
||||
```
|
||||
|
||||
4. После открытия файла вы увидите интерфейс редактора `nano`. Обратите внимание на нижнюю часть экрана, где перечислены основные горячие клавиши (на скриншоте ниже выделены красной рамкой). Не нужно ничего заучивать, всё необходимое всегда перед глазами!
|
||||
|
||||

|
||||
|
||||
5) Второе, что нужно сделать, — это найти строку, начинающуюся с `Port`, и изменить номер порта. Число после `Port` — это номер порта SSH. Рекомендуется использовать число в диапазоне от `1024` до `65535` (в этой статье мы будем использовать порт `9753`). Как это сделать, используя горячие клавиши `nano`? Вы уже наверняка догадались!
|
||||
|
||||
- Нажмите `Ctrl+W`, чтобы открыть поиск, введите `Port 22` и нажмите Enter.
|
||||
- Замените `22` на `9753`.
|
||||
- Примечание: если в начале строки стоит символ `#`, значит, эта строка закомментирована и не будет применяться. Вы можете либо раскомментировать её (удалив `#`), либо добавить новую строку без `#` в конце файла, как показано на скриншоте.
|
||||
|
||||
::: warning
|
||||
Использование порта `9753` в этой статье делает его менее безопасным, поскольку злоумышленники могут начать сканировать этот порт в первую очередь. Кроме того, этот порт может быть заблокирован некоторыми провайдерами. Поэтому настоятельно рекомендуем использовать другой порт. У вас в распоряжении более 60 тысяч портов, так что выбрать есть из чего.
|
||||
:::
|
||||
|
||||
6. Третье, что нужно сделать, — это сохранить изменения и выйти из редактора.
|
||||
|
||||
- Как вы уже могли заметить, для сохранения файла используется не `Ctrl+S`, как в большинстве программ.
|
||||
- Горячие клавиши: `Ctrl+O` — сохранить, `Ctrl+X` — выйти.
|
||||
|
||||
7. И последнее, что нужно сделать, — это перезапустить SSH-сервер, чтобы изменения вступили в силу.
|
||||
|
||||
```shell
|
||||
systemctl restart ssh
|
||||
```
|
||||
|
||||
8. Весь процесс показан на гифке ниже:
|
||||
|
||||

|
||||
|
||||
9. Изменение настроек PuTTY
|
||||
|
||||
Теперь, когда вы изменили порт SSH, вам нужно указать новый порт (`9753`) в настройках PuTTY. Вы ведь помните, где это делается? (Если нет, вернитесь и перечитайте предыдущие разделы!)
|
||||
|
||||
## 4.5 Создание нового пользователя
|
||||
|
||||
Перейдём ко второму шагу — избавлению от пользователя `root`.
|
||||
|
||||
Прежде всего, нужно понимать, что пользователь `root` в Linux — это не просто администратор. Это корень системы, её основа, верховный правитель. Если безопасность учётной записи `root` будет нарушена, под угрозой окажется вся система.
|
||||
|
||||
1. Базовые команды Linux:
|
||||
|
||||
| Номер | Команда | Описание |
|
||||
| :----: | :------------ | :---------------------------------- |
|
||||
| `cmd-05` | `adduser` | Добавление нового пользователя |
|
||||
| `cmd-06` | `apt install` | Установка программного обеспечения |
|
||||
| `cmd-07` | `visudo` | Редактор файла sudoers |
|
||||
|
||||
2. Первое, что нужно сделать, — это создать нового пользователя и установить для него пароль. Имя пользователя может быть любым, в этой статье мы будем использовать имя `vpsadmin`.
|
||||
|
||||
```shell
|
||||
adduser vpsadmin
|
||||
```
|
||||
|
||||
Следуйте инструкциям на экране. Обязательно укажите пароль для нового пользователя (и не удивляйтесь, что при вводе пароля символы не отображаются). Далее система может запросить дополнительную информацию о пользователе. Можете пропустить эти пункты, нажав Enter.
|
||||
|
||||

|
||||
|
||||
::: warning
|
||||
Использование имени пользователя `vpsadmin` в этой статье делает его менее безопасным, поскольку злоумышленники могут начать перебирать пароли для этого имени в первую очередь. Поэтому, как и в случае с портом, настоятельно рекомендуем использовать другое имя пользователя.
|
||||
:::
|
||||
|
||||
3. Весь процесс показан на гифке ниже:
|
||||
|
||||

|
||||
|
||||
4. Второе, что нужно сделать, — это установить пакет `sudo` (`sudo` позволяет обычным пользователям временно получать права суперпользователя `root`, чтобы выполнять задачи, требующие повышенных привилегий).
|
||||
|
||||
```shell
|
||||
apt update && apt install sudo
|
||||
```
|
||||
|
||||
Вы, наверное, заметили, что эта строка содержит две команды. Первая команда, `apt update`, уже знакома вам — она обновляет информацию о доступных пакетах. Вторая команда, `apt install`, используется для установки программного обеспечения. В данном случае мы обновляем информацию о пакетах и устанавливаем последнюю версию `sudo`. Символы `&&` используются для объединения нескольких команд в одну строку.
|
||||
|
||||
5. Третье, что нужно сделать, — это добавить пользователя `vpsadmin` в группу `sudo`, чтобы он мог использовать команду `sudo`.
|
||||
|
||||
```shell
|
||||
visudo
|
||||
```
|
||||
|
||||
Добавьте следующую строку в раздел `User Privilege Specification`: `vpsadmin ALL=(ALL) NOPASSWD: ALL`.
|
||||
|
||||
::: warning
|
||||
Обратите внимание на опцию `NOPASSWD`. Она означает, что пользователю `vpsadmin` не нужно будет вводить пароль при использовании команды `sudo`. **Это противоречит общепринятым рекомендациям по безопасности.** Однако я рекомендую сделать именно так, потому что многие новички используют учётную запись `root` именно потому, что им не нужно каждый раз вводить пароль. Я считаю, что **риски от использования учётной записи `root` гораздо выше**, чем риски от использования `sudo` без пароля.
|
||||
|
||||
Если вы всё же хотите, чтобы при каждом использовании `sudo` запрашивался пароль, используйте следующую строку: `vpsadmin ALL=(ALL:ALL) ALL`.
|
||||
:::
|
||||
|
||||
6. Весь процесс показан на гифке ниже:
|
||||
|
||||

|
||||
|
||||
## 4.6 Запрет удалённого подключения по SSH для пользователя root
|
||||
|
||||
1. Вы уже немного освоились в Linux, поэтому попробуйте сами догадаться, что нужно сделать в первую очередь. Правильно, нужно снова открыть файл настроек SSH-сервера (`/etc/ssh/sshd_config`) в редакторе `nano`. Не помните, как это сделать? Вернитесь и перечитайте предыдущие разделы! ... Правильный ответ:
|
||||
|
||||
```shell
|
||||
nano /etc/ssh/sshd_config
|
||||
```
|
||||
|
||||
2. Найдите строку `PermitRootLogin Yes` и замените `yes` на `no`. Помните, как это сделать? ... Правильный ответ:
|
||||
|
||||
- Нажмите `Ctrl+W`, чтобы открыть поиск, введите `PermitRootLogin` и нажмите Enter.
|
||||
- Замените `yes` на `no`.
|
||||
|
||||
3. Сохраните изменения и выйдите из редактора. Помните, как это сделать? ... Правильный ответ:
|
||||
|
||||
- `Ctrl+O` — сохранить, `Enter` — подтвердить сохранение.
|
||||
- `Ctrl+X` — выйти.
|
||||
|
||||
4. Перезапустите SSH-сервер, чтобы изменения вступили в силу. Помните... Ладно, вот правильный ответ:
|
||||
|
||||
```shell
|
||||
systemctl restart ssh
|
||||
```
|
||||
|
||||
5. Весь процесс показан на гифке ниже:
|
||||
|
||||

|
||||
|
||||
6. Теперь при попытке подключения по SSH с помощью PuTTY под пользователем `root` вы получите ошибку. Используйте имя пользователя `vpsadmin` для подключения. Для удобства вы можете указать `vpsadmin` в качестве имени пользователя по умолчанию в настройках PuTTY (не забудьте сохранить сеанс!).
|
||||
|
||||

|
||||
|
||||
## 4.7 Настройка аутентификации по SSH-ключам и запрет аутентификации по паролю
|
||||
|
||||
Перейдём к третьему шагу — защите от подбора пароля.
|
||||
|
||||
Как мы уже говорили, хакеры не будут подбирать ваш пароль вручную. Они используют специальные программы и базы данных с миллионами скомпрометированных паролей. Если вы не используете случайно сгенерированный пароль достаточной длины (например, с помощью менеджера паролей, такого как 1Password или Keychain в macOS), ваш пароль могут подобрать.
|
||||
|
||||
Конечно, можно использовать длинный и сложный пароль, но такой пароль сложно запомнить и легко ввести неправильно. Чтобы решить эту проблему, можно вообще отказаться от аутентификации по паролю и использовать более безопасный способ — аутентификацию по SSH-ключам.
|
||||
|
||||
**Аутентификация по SSH-ключам** основана на использовании пары связанных ключей — **публичного** и **приватного**. Публичный ключ помещается на сервер, а приватный ключ хранится у вас на компьютере. При подключении по SSH клиент предъявляет серверу публичный ключ, а сервер, в свою очередь, шифрует с помощью него случайное сообщение и отправляет клиенту. Клиент расшифровывает сообщение с помощью приватного ключа и отправляет результат обратно на сервер. Если результат совпадает с ожидаемым, аутентификация считается успешной (таким образом, вам не нужно запоминать и вводить сложный пароль, достаточно лишь защитить свой приватный ключ от кражи).
|
||||
|
||||
::: warning
|
||||
В этой статье мы рассмотрим использование **RSA-ключей**, поскольку они поддерживаются практически всеми SSH-клиентами и до сих пор считаются достаточно надёжными. Однако это не единственный вариант.
|
||||
|
||||
Существуют и другие алгоритмы:
|
||||
|
||||
- **DSA**: этот алгоритм считается небезопасным, поэтому использовать его не рекомендуется.
|
||||
- **ECDSA**: этот алгоритм обеспечивает высокий уровень безопасности при меньшем размере ключа, однако существуют подозрения, что в нём есть уязвимости, которые могут быть использованы АНБ. Поэтому, если вы храните на своём сервере что-то действительно важное, лучше не использовать этот алгоритм.
|
||||
- **Ed25519**: этот алгоритм похож на ECDSA, но считается более безопасным, поскольку его код открыт и доступен для изучения.
|
||||
|
||||
Поэтому, если ваше оборудование и программное обеспечение поддерживают этот алгоритм, рекомендуется использовать именно его.
|
||||
:::
|
||||
|
||||
Итак, давайте настроим аутентификацию по SSH-ключам.
|
||||
|
||||
1. Запустите программу **PuTTYgen** (генератор ключей PuTTY). Она находится в меню «Пуск» --> «Все программы» --> «PuTTY (64-bit)» --> «PuTTYgen».
|
||||
|
||||
1. Нажмите кнопку **Generate**, чтобы сгенерировать ключи (поводите курсором мыши по пустому пространству окна, чтобы добавить энтропии).
|
||||
|
||||

|
||||
|
||||
::: warning
|
||||
На скриншоте показан пример генерации 2048-битного RSA-ключа. Однако для достижения уровня безопасности, со comparableного с 256-битным ключом ECDSA/Ed25519, вам нужно сгенерировать 3072-битный RSA-ключ (т.е. ввести значение `3072` в поле «Number of bits in a generated key»).
|
||||
:::
|
||||
|
||||
2. Вы можете установить пароль для защиты приватного ключа.
|
||||
3. Нажмите кнопку **Save public key**, чтобы сохранить публичный ключ в файл `id_rsa.pub`.
|
||||
4. Нажмите кнопку **Save private key**, чтобы сохранить приватный ключ в файл `id_rsa` (приватные ключи PuTTY имеют расширение `.ppk`).
|
||||
5. **Важно!** Скопируйте содержимое поля, выделенного красной рамкой (не забудьте прокрутить текст до конца!), и сохраните его в файл `authorized_keys`. (Если вы будете использовать для этого VSCode, файл будет сохранён с расширением `.txt` — `authorized_keys.txt`. Это нормально, позже мы переименуем файл).
|
||||
|
||||

|
||||
|
||||
2. Скопируйте публичный ключ на VPS в домашний каталог пользователя `vpsadmin`.
|
||||
|
||||
1. Для этого используйте программу **WinSCP**, которую мы установили ранее.
|
||||
2. Скачайте и установите WinSCP с [официального сайта](https://winscp.net/eng/index.php). При первом запуске программа предложит импортировать настройки из PuTTY. Согласитесь на импорт.
|
||||
|
||||

|
||||
|
||||
3. Если вам не предложили импортировать настройки или вы уже настроили WinSCP ранее, настройте подключение к VPS, как показано на скриншоте ниже.
|
||||
|
||||

|
||||
|
||||
4. В левой части окна WinSCP отображаются файлы и папки на вашем компьютере, а в правой — на VPS. Перейдите в папку с сохранёнными ключами на вашем компьютере.
|
||||
|
||||
5. В правой части окна (VPS) по умолчанию открыт каталог `/home/vpsadmin/`. Нажмите кнопку «Show hidden files» (скрытые файлы), чтобы отобразить скрытые файлы и папки.
|
||||
|
||||

|
||||
|
||||
6. щёлкните правой кнопкой мыши в правой части окна (VPS) и создайте новую папку с именем `.ssh` (обратите внимание на точку в начале имени).
|
||||
|
||||

|
||||
|
||||
7. Скопируйте файл `authorized_keys` в папку `.ssh`.
|
||||
|
||||

|
||||
|
||||
8. При копировании файла `authorized_keys.txt` переименуйте его в `authorized_keys` (удалите расширение `.txt`).
|
||||
|
||||

|
||||
|
||||
9. Весь процесс показан на гифке ниже:
|
||||
|
||||

|
||||
|
||||
3. Настройте SSH-сервер на использование ключей и отключите аутентификацию по паролю.
|
||||
|
||||
1. Базовые команды Linux:
|
||||
| Номер | Команда | Описание |
|
||||
| :----: | :------ | :--------------------------------------- |
|
||||
| `cmd-08` | `sudo` | Выполнение команды от имени root |
|
||||
| `cmd-09` | `chmod` | Изменение прав доступа к файлам и папкам |
|
||||
|
||||
2. Подключитесь к VPS по SSH (PuTTY).
|
||||
|
||||
3. Измените права доступа к файлу `authorized_keys` на `600` (только владелец может читать и записывать файл).
|
||||
|
||||
```shell
|
||||
chmod 600 ~/.ssh/authorized_keys
|
||||
```
|
||||
|
||||
4. Откройте файл настроек SSH. Мы уже делали это раньше, но теперь мы работаем не под пользователем `root`, а под пользователем `vpsadmin`. У этого пользователя нет прав на редактирование системных файлов, поэтому нужно использовать команду `sudo`:
|
||||
|
||||
```shell
|
||||
sudo nano /etc/ssh/sshd_config
|
||||
```
|
||||
|
||||
5. Найдите (`Ctrl+W`) строку `PasswordAuthentication` и измените значение на `no`.
|
||||
|
||||
6. Найдите (`Ctrl+W`) строку `PubkeyAuthentication` и измените значение на `yes`. Сохраните изменения (`Ctrl+O`) и выйдите из редактора (`Ctrl+X`).
|
||||
|
||||
7. Перезапустите SSH-сервер (не забудьте, что теперь вам нужно использовать команду `sudo`):
|
||||
|
||||
```shell
|
||||
sudo systemctl restart ssh
|
||||
```
|
||||
|
||||
8. Весь процесс показан на гифке ниже:
|
||||
|
||||

|
||||
|
||||
4. Теперь, когда на сервере настроен публичный ключ, нужно указать PuTTY путь к приватному ключу (не забудьте сохранить сеанс!).
|
||||
|
||||

|
||||
|
||||
5. Готово! Теперь у вас настроена аутентификация по SSH-ключам, а аутентификация по паролю отключена. Кроме того, вы сохранили имя пользователя и путь к приватному ключу в сеансе PuTTY. Теперь для подключения к VPS достаточно будет выбрать сохранённый сеанс `VPS-SERVER` и нажать кнопку «Open».
|
||||
|
||||
Если вы установили пароль для защиты приватного ключа, вам нужно будет ввести его при подключении, как показано на скриншоте ниже:
|
||||
|
||||

|
||||
|
||||
6. Не забудьте настроить аутентификацию по ключам и в WinSCP. В противном случае вы не сможете подключаться к серверу для передачи файлов:
|
||||
|
||||

|
||||
|
||||
::: warning
|
||||
Теперь для подключения к вашему серверу по SSH требуется авторизация по ключам. Мы рассмотрели настройку PuTTY и WinSCP, но существует множество других программ, которые также используют SSH. Настройте их самостоятельно при необходимости.
|
||||
:::
|
||||
|
||||
## 4.8 Ваш прогресс
|
||||
|
||||
На этом этапе ваш VPS защищён базовыми мерами безопасности. Конечно, это не панацея, но большинство автоматизированных атак вам уже не страшны!
|
||||
|
||||
Теперь у нас есть надёжный фундамент, и в следующей главе мы можем приступить к установке и настройке необходимых компонентов Xray (а именно, веб-сервера и SSL-сертификата).
|
||||
|
||||
> ⬛⬛⬛⬛⬜⬜⬜⬜ 50%
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
After Width: | Height: | Size: 39 KiB |
|
After Width: | Height: | Size: 92 KiB |
|
After Width: | Height: | Size: 308 KiB |
@@ -0,0 +1,195 @@
|
||||
# 【Глава 5】 Создание веб-сайта
|
||||
|
||||
## 5.1 Зачем нужен веб-сайт?
|
||||
|
||||
Начинающие пользователи могут задаться вопросом: зачем создавать веб-сайт для обхода блокировок? Я не программист, это же сложно?
|
||||
|
||||
Начнём с первого вопроса. Веб-сайт нужен для того, чтобы:
|
||||
|
||||
1. Получить действующий SSL-сертификат (это очень важно).
|
||||
2. Обеспечить маскировку трафика (fallback) и защититься от атак, направленных на выявление VPN-серверов.
|
||||
3. Создать сайт-прикрытие (например, блог, облачное хранилище, медиа-портал, игровой сайт), который будет отображаться при прямом доступе к серверу, делая использование VPN менее заметным.
|
||||
|
||||
Теперь ответим на второй вопрос:
|
||||
|
||||
1. В этой статье мы создадим максимально простой веб-сайт, состоящий из **одного HTML-файла** и работающий на веб-сервере **Nginx**, чтобы решить поставленные выше задачи. Это очень просто.
|
||||
2. Этот веб-сайт не обязательно должен быть просто прикрытием. Вы можете развивать его и превратить в полноценный проект. Всё зависит от ваших желаний и возможностей.
|
||||
3. Создание сайта-прикрытия и его продвижение — это отдельная большая тема, которая выходит за рамки этой статьи. Если вам интересно, вы можете найти информацию об этом в интернете.
|
||||
|
||||
## 5.2 Подключение к VPS и установка Nginx
|
||||
|
||||
1. В этом разделе мы будем использовать команды, которые уже были подробно рассмотрены ранее. Если вы что-то не понимаете, вернитесь и перечитайте предыдущие главы.
|
||||
|
||||
```shell
|
||||
sudo apt update && sudo apt install nginx
|
||||
```
|
||||
|
||||
2. После завершения установки Nginx запустится автоматически. Откройте браузер на своём компьютере и введите адрес `http://100.200.300.400:80`. Если вы увидите страницу, как на скриншоте ниже, значит, Nginx работает.
|
||||
|
||||

|
||||
|
||||
3. Если вы не видите страницу Nginx, возможно, вам нужно настроить Uncomplicated Firewall (UFW), стандартный брандмауэр в Debian, чтобы разрешить трафик на портах HTTP (80) и HTTPS (443).
|
||||
|
||||
a. Чтобы проверить, введите:
|
||||
```shell
|
||||
sudo ufw status
|
||||
```
|
||||
b. Если вывод команды такой, как показано ниже, это означает, что порты 80 и 443 закрыты. Выполните действия, описанные в пункте c.
|
||||
```shell
|
||||
Status: active
|
||||
To Action From
|
||||
-- ------ ----
|
||||
22/tcp ALLOW Anywhere
|
||||
22/tcp (v6) ALLOW Anywhere (v6)
|
||||
```
|
||||
c. Чтобы открыть порты 80 и 443 для Nginx в UFW, выполните команду:
|
||||
```shell
|
||||
sudo ufw allow 'Nginx Full'
|
||||
```
|
||||
d. Снова проверьте статус UFW, выполнив команду из пункта a. Если вы видите вывод, как показано ниже, значит, трафик для Nginx разрешён, и вы должны увидеть стандартную страницу Nginx.
|
||||
```shell
|
||||
Status: active
|
||||
To Action From
|
||||
-- ------ ----
|
||||
22/tcp ALLOW Anywhere
|
||||
Nginx Full ALLOW Anywhere
|
||||
22/tcp (v6) ALLOW Anywhere (v6)
|
||||
Nginx Full (v6) ALLOW Anywhere (v6)
|
||||
```
|
||||
|
||||
## 5.3 Создание простой веб-страницы
|
||||
|
||||
1. Базовые команды Linux:
|
||||
| Номер | Команда | Описание |
|
||||
| :----: | :-------- | :------------------------ |
|
||||
| `cmd-10` | `mkdir` | Создание папки |
|
||||
| `cmd-11` | `systemctl reload` | Перезагрузка службы |
|
||||
|
||||
2. Важные файлы конфигурации Linux:
|
||||
| Номер | Путь к файлу | Описание |
|
||||
| :------ | :-------------------- | :------------------------- |
|
||||
| `conf-02` | `/etc/nginx/nginx.conf` | Настройки Nginx |
|
||||
|
||||
3. Создайте папку `/home/vpsadmin/www/webpage/` для вашего сайта и файл `index.html` внутри неё:
|
||||
```shell
|
||||
mkdir -p ~/www/webpage/ && nano ~/www/webpage/index.html
|
||||
```
|
||||
|
||||
::: warning
|
||||
Если вы используете имя пользователя, отличное от `vpsadmin`, обратите внимание на символ `~` в этой команде (это важно для 5-го шага):
|
||||
|
||||
- Для пользователей, **отличных от `root`**: `~` эквивалентно `/home/имя_пользователя`.
|
||||
- Для пользователя **`root`**: `~` эквивалентно `/root`.
|
||||
:::
|
||||
|
||||
4. Скопируйте следующий код в файл `index.html` и сохраните его (`Ctrl+O`, `Enter`), затем выйдите из редактора (`Ctrl+X`):
|
||||
|
||||
```html
|
||||
<html lang="">
|
||||
<!-- Text between angle brackets is an HTML tag and is not displayed.
|
||||
Most tags, such as the HTML and /HTML tags that surround the contents of
|
||||
a page, come in pairs; some tags, like HR, for a horizontal rule, stand
|
||||
alone. Comments, such as the text you're reading, are not displayed when
|
||||
the Web page is shown. The information between the HEAD and /HEAD tags is
|
||||
not displayed. The information between the BODY and /BODY tags is displayed.-->
|
||||
<head>
|
||||
<title>Enter a title, displayed at the top of the window.</title>
|
||||
</head>
|
||||
<!-- The information between the BODY and /BODY tags is displayed.-->
|
||||
<body>
|
||||
<h1>Enter the main heading, usually the same as the title.</h1>
|
||||
<p>Be <b>bold</b> in stating your key points. Put them in a list:</p>
|
||||
<ul>
|
||||
<li>The first item in your list</li>
|
||||
<li>The second item; <i>italicize</i> key words</li>
|
||||
</ul>
|
||||
<p>Improve your image by including an image.</p>
|
||||
<p>
|
||||
<img src="https://i.imgur.com/SEBww.jpg" alt="A Great HTML Resource" />
|
||||
</p>
|
||||
<p>
|
||||
Add a link to your favorite
|
||||
<a href="https://www.dummies.com/">Web site</a>. Break up your page
|
||||
with a horizontal rule or two.
|
||||
</p>
|
||||
<hr />
|
||||
<p>
|
||||
Finally, link to <a href="page2.html">another page</a> in your own Web
|
||||
site.
|
||||
</p>
|
||||
<!-- And add a copyright notice.-->
|
||||
<p>© Wiley Publishing, 2011</p>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
5. Дайте другим пользователям право на чтение этого файла:
|
||||
|
||||
```shell
|
||||
chmod -R a+r .
|
||||
```
|
||||
|
||||
6. Отредактируйте файл `nginx.conf` и перезапустите Nginx, чтобы он открывал созданную нами страницу `index.html` при обращении к порту `80`.
|
||||
|
||||
1. Отредактируйте файл `nginx.conf`.
|
||||
|
||||
```shell
|
||||
sudo nano /etc/nginx/nginx.conf
|
||||
```
|
||||
|
||||
2. Добавьте следующий блок кода внутрь блока `http{}` и сохраните изменения (`Ctrl+O`, `Enter`), затем выйдите из редактора (`Ctrl+X`). (Не забудьте заменить доменное имя на ваше реальное доменное имя, включая поддомен).
|
||||
|
||||
```
|
||||
server {
|
||||
listen 80;
|
||||
server_name поддомен.ваш_домен.com;
|
||||
root /home/vpsadmin/www/webpage;
|
||||
index index.html;
|
||||
}
|
||||
```
|
||||
|
||||
::: warning Важно!
|
||||
Как уже говорилось в 3-м шаге, убедитесь, что путь `/home/vpsadmin/www/webpage` соответствует реальному пути к вашему файлу.
|
||||
:::
|
||||
|
||||
3. Перезагрузите Nginx, чтобы применить изменения.
|
||||
|
||||
```shell
|
||||
sudo systemctl reload nginx
|
||||
```
|
||||
|
||||
4. Весь процесс настройки показан на гифке ниже:
|
||||
|
||||

|
||||
|
||||
5. Теперь, если вы откроете в браузере адрес `http://поддомен.ваш_домен.com`, вы должны увидеть созданную нами страницу:
|
||||
|
||||

|
||||
|
||||
## 5.4 Распространённые ошибки
|
||||
|
||||
Вообще, если вы внимательно следовали инструкциям, ошибок быть не должно. Однако на этом этапе многие пользователи сталкиваются с проблемами. В чём же дело? Ответ прост: **невнимательность**. Здесь возможны только две ошибки, и обе они связаны с невнимательностью.
|
||||
|
||||
**Ошибки:**
|
||||
|
||||
- Путь `/home/vpsadmin/www/webpage` в файле `nginx.conf` не соответствует реальному пути к файлу `index.html`. Nginx не может найти файл.
|
||||
- Путь указан верно, но у Nginx нет прав на чтение файла.
|
||||
|
||||
**Причины:**
|
||||
|
||||
- Вы работаете не под пользователем `root`, но скопировали команды из статьи без изменений (как будто списали домашнее задание вместе с именем одноклассника).
|
||||
- Вы работаете под пользователем `root`.
|
||||
|
||||
Если у вас возникли проблемы, вернитесь к разделу 5.3 и внимательно перечитайте пункты 3 и 6.2.
|
||||
|
||||
::: warning
|
||||
В предыдущих главах мы много говорили о важности использования пользователя, отличного от `root`, и вся статья написана с учётом этого. Поэтому проблемы, связанные с использованием `root`, не рассматриваются в рамках этой статьи.
|
||||
|
||||
Однако я уверен, что те, кто всё-таки работает под `root`, достаточно опытны и смогут решить эти проблемы самостоятельно.
|
||||
:::
|
||||
|
||||
## 5.5 Ваш прогресс
|
||||
|
||||
Первый компонент Xray — веб-сайт — готов. Давайте перейдём ко второму компоненту — SSL-сертификату!
|
||||
|
||||
> ⬛⬛⬛⬛⬛⬜⬜⬜ 62.5%
|
||||
@@ -0,0 +1,216 @@
|
||||
# 【Глава 6】 Управление сертификатами
|
||||
|
||||
## 6.1 Получение SSL-сертификата
|
||||
|
||||
Теперь нам нужно получить действующий SSL-сертификат для нашего доменного имени, чтобы веб-сайт работал по протоколу HTTPS. Это важнейший инструмент для обеспечения безопасности трафика при использовании современных VPN-сервисов, таких как Xray.
|
||||
|
||||
::: warning
|
||||
Не используйте самоподписанные сертификаты. Это ненамного упростит задачу, но создаст дополнительные риски (например, возможность атак типа «человек посередине»).
|
||||
:::
|
||||
|
||||
Мы будем использовать инструмент для управления сертификатами [`acme.sh`](https://github.com/acmesh-official/acme.sh). Он простой, лёгкий, эффективный и умеет автоматически обновлять сертификаты.
|
||||
|
||||
Я уверен, что вы уже освоились с базовыми командами Linux, поэтому скриншоты с выводом команд, которые мы уже использовали ранее, будут опущены. Если вы забыли, как выполнять ту или иную команду, вернитесь и перечитайте предыдущие главы.
|
||||
|
||||
## 6.2 Установка `acme.sh`
|
||||
|
||||
1. Базовые команды Linux:
|
||||
| Номер | Команда | Описание |
|
||||
| :----: | :---------- | :---------------------------- |
|
||||
| `cmd-12` | `wget` | Загрузка файла из интернета |
|
||||
| `cmd-13` | `acme.sh` | Управление сертификатами |
|
||||
|
||||
2. Запустите скрипт установки:
|
||||
|
||||
```shell
|
||||
wget -O - https://get.acme.sh | sh
|
||||
```
|
||||
|
||||
3. Сделайте команду `acme.sh` доступной:
|
||||
|
||||
```shell
|
||||
. .bashrc
|
||||
```
|
||||
|
||||
4. Включите автоматическое обновление `acme.sh`:
|
||||
|
||||
```shell
|
||||
acme.sh --upgrade --auto-upgrade
|
||||
```
|
||||
|
||||
5. Весь процесс установки показан на гифке ниже:
|
||||
|
||||

|
||||
|
||||
## 6.3 Тестовый запрос сертификата
|
||||
|
||||
Перед тем, как запросить настоящий сертификат, давайте сделаем тестовый запрос (`--issue --test`), чтобы убедиться, что всё настроено правильно. Это позволит избежать превышения лимита на количество запросов Let's Encrypt (например, не более 5 неудачных запросов в час для одного домена и одного аккаунта).
|
||||
|
||||
1. Команда для тестового запроса сертификата (в этой статье мы будем использовать сертификаты **ECC**, поскольку на сегодняшний день нет причин не использовать их):
|
||||
|
||||
```shell
|
||||
acme.sh --issue --server letsencrypt --test -d поддомен.ваш_домен.com -w /home/vpsadmin/www/webpage --keylength ec-256
|
||||
```
|
||||
|
||||
::: warning Пояснение
|
||||
Главное преимущество **ECC-сертификатов** — это меньший размер ключа, что означает более высокий уровень безопасности при том же размере ключа, а также более высокую скорость шифрования и расшифровки. Например, ECC-256 обеспечивает уровень безопасности, примерно соответствующий RSA-3072, так зачем же отказываться от ECC? Некоторые утверждают, что рукопожатие TLS с ECC-сертификатами происходит заметно быстрее. Я считаю, что это преувеличение. RSA-рукопожатие и так достаточно быстрое, а разница в скорости, если она и есть, составляет всего несколько миллисекунд и практически незаметна.
|
||||
|
||||
Конечно, если вам нужно обеспечить совместимость с очень старыми устройствами, то можно использовать и RSA-сертификат.
|
||||
:::
|
||||
|
||||
2. В случае успеха вы увидите примерно такой вывод:
|
||||
|
||||
```log
|
||||
[Wed 30 Dec 2022 04:25:12 AM EST] Using ACME_DIRECTORY: https://acme-staging-v02.api.letsencrypt.org/directory
|
||||
[Wed 30 Dec 2022 04:25:13 AM EST] Using CA: https://acme-staging-v02.api.letsencrypt.org/directory
|
||||
[Wed 30 Dec 2022 04:25:13 AM EST] Create account key ok.
|
||||
[Wed 30 Dec 2022 04:25:13 AM EST] Registering account: https://acme-staging-v02.api.letsencrypt.org/directory
|
||||
[Wed 30 Dec 2022 04:25:13 AM EST] Registered
|
||||
[Wed 30 Dec 2022 04:25:13 AM EST] ACCOUNT_THUMBPRINT='CU6qmPKuRqhyTAIrF4swosR375194z_1ddUlWef8xDc'
|
||||
[Wed 30 Dec 2022 04:25:13 AM EST] Creating domain key
|
||||
[Wed 30 Dec 2022 04:25:13 AM EST] The domain key is here: /home/vpsadmin/.acme.sh/поддомен.ваш_домен.com_ecc/поддомен.ваш_домен.com.key
|
||||
[Wed 30 Dec 2022 04:25:13 AM EST] Single domain='поддомен.ваш_домен.com'
|
||||
[Wed 30 Dec 2022 04:25:13 AM EST] Getting domain auth token for each domain
|
||||
[Wed 30 Dec 2022 04:25:14 AM EST] Getting webroot for domain='поддомен.ваш_домен.com'
|
||||
[Wed 30 Dec 2022 04:25:14 AM EST] Verifying: поддомен.ваш_домен.com
|
||||
[Wed 30 Dec 2022 04:25:23 AM EST] Pending
|
||||
[Wed 30 Dec 2022 04:25:25 AM EST] Success
|
||||
[Wed 30 Dec 2022 04:25:25 AM EST] Verify finished, start to sign.
|
||||
[Wed 30 Dec 2022 04:25:25 AM EST] Lets finalize the order.
|
||||
[Wed 30 Dec 2022 04:25:25 AM EST] Le_OrderFinalize='https://acme-staging-v02.api.letsencrypt.org/acme/finalize/490205995/7730242871'
|
||||
[Wed 30 Dec 2022 04:25:25 AM EST] Downloading cert.
|
||||
[Wed 30 Dec 2022 04:25:25 AM EST] Le_LinkCert='https://acme-staging-v02.api.letsencrypt.org/acme/cert/xujss5xt8i38waubafz2xujss5xt8i38waubz2'
|
||||
[Wed 30 Dec 2022 15:21:52 AM EST] Cert success.
|
||||
--BEGIN CERTIFICAT--
|
||||
sxlYqPvWreKgD5b8JyOQX0Yg2MLoRUoDyqVkd31PthIiwzdckoh5eD3JU7ysYBtN
|
||||
cTFK4LGOfjqi8Ks87EVJdK9IaSAu7ZC6h5to0eqpJ5PLhaM3e6yJBbHmYA8w1Smp
|
||||
wAb3tdoHZ9ttUIm9CrSzvDBt6BBT6GqYdDamMyCYBLooMyDEM4CUFsOzCRrEqqvC
|
||||
2mTTEmhvpojo5rhdTSJxibozyNWTGwoTj0v9pTUeQcGqLIzqi4DowjBHD5guwRid
|
||||
SjAFnm6JT2xUQgWFm58A1gv1OhbH1TRPUUmtE1nFEN7YiSjI4xgxqAXT3CLD2EUb
|
||||
wXlUrO6c75zSsQP4bRMzgOjJUqHtSb6IEqELzt4M7KzL5iCOruCChCo2DZxUwvVX
|
||||
tOoaAyQJzCbTqE6aUqwiKi3gVyoxvDP9mI5JdRYzsDL6GVud7EHPnYeMl9ubLZAK
|
||||
0vg84mbMP3f6mYM4KRa1cqiyOIcQPT4AzGFYVv4sm049bZQg7sd0Bz9CaFvE7yDA
|
||||
1y17XlgCDnsjxl66bqI1vkENN9XT5xeFHONqc18b5fZEKSIvdX7iWPFWp1PyMPpG
|
||||
0pMCP1EymZNFxIMJLgbWqExwLWfPc5Ib3PjBaIqhXPnw6sT2MQSxXwDupq1UJVhV
|
||||
7E3hQRVlwI4CXi6WLHJMNvNRyyK87gCrLH1bKYsPeRVaz77poWBq49zwBCts6hPY
|
||||
IeF4ltGXyANNIOPEi8vy138fRU4LYh81d8FjOtFfJZogMjwhfNvapqxPMsioPlmX
|
||||
TnZu0n7setrVNUEfTMHWqPpDgk5MPrWLA4LapqaDfEX4pwnQJLMwMi6s94z165c0
|
||||
iMRSKA1yU5zqv8aNsDfPoY4OkSPWs4MaXgRRSLBsUfZ15DwQXPk76kegHIyxWvwF
|
||||
tYw9HKR5QCMK66fa0z4aJoFVFLK0IIOGEZOanRFUCnkLUDd3QZ3YU8lEcrj7Uxos
|
||||
haiRNICyC6UfsCJ94a8vcNyMosPv3xBLMp19WXgiFYqEFQkntkv1FLRI35fjeJmg
|
||||
0fmD9VG9bkzGPHihJgQLRlCHasGf6XrdfkSsODAyCUHUHJ0RzqF4YEZMcxDxzuQ2
|
||||
YO7bFwj7S3mUdVPZ6MPasjxdyBjJgEBMch2uy4AhmudXfEBQBye8W6ZI4ztZjLVV
|
||||
FmP4SIuaNUmMe20TjR8b9NVC96AhxOanWT3mRROsdokpKQGTJvl27EHH8KuAbUOc
|
||||
G6KtPy4wslNZNXWcBy9n63RcWak12r7kAIFn38tZxmlw2WUKoRSMAH64GcDTjRQd
|
||||
Am65hBHzvGrj93wEuVNIebvNIsJOlng3HFjpIxVqKGMCIfWIKGDE3YzK3p4LbGZ6
|
||||
NZFQWYJLNVf2M9CCJfbEImPYgvctrxl39H6KVYPCw1SAdaj9NneUqmREOQkKoEB0
|
||||
x6PmNirbMscHhQPSC0JQaqUgaQFgba1ALmzRYAnYhNb0twkTxWbY7DBkAarxqMIp
|
||||
yiLKcBFc5H7dgJCImo7us7aJeftC44uWkPIjw9AKH=
|
||||
--END CERTIFICAT--
|
||||
[Wed 30 Dec 2022 15:21:52 AM EST] Your cert is in /home/vpsadmin/.acme.sh/поддомен.ваш_домен.com_ecc/поддомен.ваш_домен.com.cer
|
||||
[Wed 30 Dec 2022 15:21:52 AM EST] Your cert key is in /home/vpsadmin/.acme.sh/поддомен.ваш_домен.com_ecc/поддомен.ваш_домен.com.key
|
||||
[Wed 30 Dec 2022 15:21:52 AM EST] The intermediate CA cert is in /home/vpsadmin/.acme.sh/поддомен.ваш_домен.com_ecc/ca.cer
|
||||
[Wed 30 Dec 2022 15:21:52 AM EST] And the full chain certs is there: /home/vpsadmin/.acme.sh/поддомен.ваш_домен.com_ecc/fullchain.cer
|
||||
```
|
||||
|
||||
3. Обратите внимание, что мы запросили тестовый сертификат, который нельзя использовать в реальной среде. Он нужен только для проверки корректности настроек. Если вы посмотрите на вывод команды, то увидите, что сертификат был выпущен сервером `https://acme-staging-v02.api.letsencrypt.org`. Слово `staging` означает, что это тестовый сервер Let's Encrypt.
|
||||
|
||||
4. Если на этом этапе возникли ошибки, выполните следующую команду, чтобы увидеть подробную информацию о процессе запроса сертификата:
|
||||
|
||||
```shell
|
||||
acme.sh --issue --server letsencrypt --test -d поддомен.ваш_домен.com -w /home/vpsadmin/www/webpage --keylength ec-256 --debug
|
||||
```
|
||||
|
||||
Мы просто добавили параметр `--debug` в конец команды.
|
||||
|
||||
5. Если тестовый запрос выполнен успешно, можно переходить к запросу настоящего сертификата (тестовый сертификат удалять не нужно, он будет автоматически перезаписан настоящим сертификатом).
|
||||
|
||||
## 6.4 Запрос настоящего сертификата
|
||||
|
||||
1. Команда для запроса настоящего сертификата (мы просто убираем параметр `--test` и добавляем параметр `--force`):
|
||||
|
||||
```shell
|
||||
acme.sh --set-default-ca --server letsencrypt
|
||||
```
|
||||
|
||||
```shell
|
||||
acme.sh --issue -d поддомен.ваш_домен.com -w /home/vpsadmin/www/webpage --keylength ec-256 --force
|
||||
```
|
||||
|
||||
::: warning Пояснение
|
||||
Параметр `--force` используется для принудительного обновления сертификата до истечения срока действия старого. В предыдущем шаге мы получили тестовый сертификат, который всё ещё действителен. Поэтому нам нужно использовать этот параметр.
|
||||
:::
|
||||
|
||||
2. В случае успеха вы увидите примерно такой же вывод, как и в предыдущем шаге:
|
||||
|
||||
```log
|
||||
vpsadmin@vps-server:~$ acme.sh --issue -d поддомен.ваш_домен.com -w /home/vpsadmin/www/webpage --keylength ec-256
|
||||
[Wed 30 Dec 2022 15:22:51 AM EST] Using CA: https://acme-v02.api.letsencrypt.org/directory
|
||||
[Wed 30 Dec 2022 15:22:51 AM EST] Creating domain key
|
||||
[Wed 30 Dec 2022 15:22:51 AM EST] The domain key is here: /home/vpsadmin/.acme.sh/поддомен.ваш_домен.com_ecc/поддомен.ваш_домен.com.key
|
||||
[Wed 30 Dec 2022 15:22:51 AM EST] Single domain='поддомен.ваш_домен.com'
|
||||
[Wed 30 Dec 2022 15:22:51 AM EST] Getting domain auth token for each domain
|
||||
[Wed 30 Dec 2022 15:22:51 AM EST] Getting webroot for domain='поддомен.ваш_домен.com'
|
||||
[Wed 30 Dec 2022 15:22:51 AM EST] Verifying: поддомен.ваш_домен.com
|
||||
[Wed 30 Dec 2022 15:22:51 AM EST] Pending
|
||||
[Wed 30 Dec 2022 15:22:51 AM EST] Success
|
||||
[Wed 30 Dec 2022 15:22:51 AM EST] Verify finished, start to sign.
|
||||
[Wed 30 Dec 2022 15:22:51 AM EST] Lets finalize the order.
|
||||
[Wed 30 Dec 2022 15:22:51 AM EST] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/490205996/7730242872'
|
||||
[Wed 30 Dec 2022 15:22:51 AM EST] Downloading cert.
|
||||
[Wed 30 Dec 2022 15:22:51 AM EST] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/vsxvk0oldnuobe51ayxz4dms62sk2dwmw9zhuw'
|
||||
[Wed 30 Dec 2022 15:22:52 AM EST] Cert success.
|
||||
--BEGIN CERTIFICAT--
|
||||
sxlYqPvWreKgD5b8JyOQX0Yg2MLoRUoDyqVkd31PthIiwzdckoh5eD3JU7ysYBtN
|
||||
cTFK4LGOfjqi8Ks87EVJdK9IaSAu7ZC6h5to0eqpJ5PLhaM3e6yJBbHmYA8w1Smp
|
||||
wAb3tdoHZ9ttUIm9CrSzvDBt6BBT6GqYdDamMyCYBLooMyDEM4CUFsOzCRrEqqvC
|
||||
2mTTEmhvpojo5rhdTSJxibozyNWTGwoTj0v9pTUeQcGqLIzqi4DowjBHD5guwRid
|
||||
SjAFnm6JT2xUQgWFm58A1gv1OhbH1TRPUUmtE1nFEN7YiSjI4xgxqAXT3CLD2EUb
|
||||
wXlUrO6c75zSsQP4bRMzgOjJUqHtSb6IEqELzt4M7KzL5iCOruCChCo2DZxUwvVX
|
||||
tOoaAyQJzCbTqE6aUqwiKi3gVyoxvDP9mI5JdRYzsDL6GVud7EHPnYeMl9ubLZAK
|
||||
0vg84mbMP3f6mYM4KRa1cqiyOIcQPT4AzGFYVv4sm049bZQg7sd0Bz9CaFvE7yDA
|
||||
1y17XlgCDnsjxl66bqI1vkENN9XT5xeFHONqc18b5fZEKSIvdX7iWPFWp1PyMPpG
|
||||
0pMCP1EymZNFxIMJLgbWqExwLWfPc5Ib3PjBaIqhXPnw6sT2MQSxXwDupq1UJVhV
|
||||
7E3hQRVlwI4CXi6WLHJMNvNRyyK87gCrLH1bKYsPeRVaz77poWBq49zwBCts6hPY
|
||||
IeF4ltGXyANNIOPEi8vy138fRU4LYh81d8FjOtFfJZogMjwhfNvapqxPMsioPlmX
|
||||
TnZu0n7setrVNUEfTMHWqPpDgk5MPrWLA4LapqaDfEX4pwnQJLMwMi6s94z165c0
|
||||
iMRSKA1yU5zqv8aNsDfPoY4OkSPWs4MaXgRRSLBsUfZ15DwQXPk76kegHIyxWvwF
|
||||
tYw9HKR5QCMK66fa0z4aJoFVFLK0IIOGEZOanRFUCnkLUDd3QZ3YU8lEcrj7Uxos
|
||||
haiRNICyC6UfsCJ94a8vcNyMosPv3xBLMp19WXgiFYqEFQkntkv1FLRI35fjeJmg
|
||||
0fmD9VG9bkzGPHihJgQLRlCHasGf6XrdfkSsODAyCUHUHJ0RzqF4YEZMcxDxzuQ2
|
||||
YO7bFwj7S3mUdVPZ6MPasjxdyBjJgEBMch2uy4AhmudXfEBQBye8W6ZI4ztZjLVV
|
||||
FmP4SIuaNUmMe20TjR8b9NVC96AhxOanWT3mRROsdokpKQGTJvl27EHH8KuAbUOc
|
||||
G6KtPy4wslNZNXWcBy9n63RcWak12r7kAIFn38tZxmlw2WUKoRSMAH64GcDTjRQd
|
||||
Am65hBHzvGrj93wEuVNIebvNIsJOlng3HFjpIxVqKGMCIfWIKGDE3YzK3p4LbGZ6
|
||||
NZFQWYJLNVf2M9CCJfbEImPYgvctrxl39H6KVYPCw1SAdaj9NneUqmREOQkKoEB0
|
||||
x6PmNirbMscHhQPSC0JQaqUgaQFgba1ALmzRYAnYhNb0twkTxWbY7DBkAarxqMIp
|
||||
yiLKcBFc5H7dgJCImo7us7aJeftC44uWkPM=
|
||||
--END CERTIFICAT--
|
||||
[Wed 30 Dec 2022 15:22:52 AM EST] Your cert is in /home/vpsadmin/.acme.sh/поддомен.ваш_домен.com_ecc/поддомен.ваш_домен.com.cer
|
||||
[Wed 30 Dec 2022 15:22:52 AM EST] Your cert key is in /home/vpsadmin/.acme.sh/поддомен.ваш_домен.com_ecc/поддомен.ваш_домен.com.key
|
||||
[Wed 30 Dec 2022 15:22:52 AM EST] The intermediate CA cert is in /home/vpsadmin/.acme.sh/поддомен.ваш_домен.com_ecc/ca.cer
|
||||
[Wed 30 Dec 2022 15:22:52 AM EST] And the full chain certs is there: /home/vpsadmin/.acme.sh/поддомен.ваш_домен.com_ecc/fullchain.cer
|
||||
```
|
||||
|
||||
3. Обратите внимание, что теперь сертификат выдан сервером `https://acme-v02.api.letsencrypt.org` (без слова `staging`), т.е. это настоящий, действующий сертификат.
|
||||
|
||||
## 6.5 Установка сертификата
|
||||
|
||||
1. После того, как сертификат получен, его нужно установить в определённое место и указать путь к нему в файле конфигурации:
|
||||
|
||||
```shell
|
||||
vpsadmin@vps-server:~$ acme.sh --installcert -d поддомен.ваш_домен.com --cert-file /путь/к/папке/cert.crt --key-file /путь/к/папке/cert.key --fullchain-file /путь/к/папке/fullchain.crt --ecc
|
||||
[Mon 14 Feb 2022 03:00:25 PM CST] Installing cert to: /etc/xray/cert/cert.crt
|
||||
[Mon 14 Feb 2022 03:00:25 PM CST] Installing key to: /etc/xray/cert/cert.key
|
||||
[Mon 14 Feb 2022 03:00:25 PM CST] Installing full chain to: /etc/xray/cert/fullchain.crt
|
||||
```
|
||||
|
||||
## 6.6 Ваш прогресс
|
||||
|
||||
Наконец-то все необходимые компоненты Xray готовы! Мы подошли к самому интересному — установке и настройке самого Xray!
|
||||
|
||||
> ⬛⬛⬛⬛⬛⬛⬜⬜ 75%
|
||||
|
||||
|
||||
|
||||
|
||||
|
After Width: | Height: | Size: 170 KiB |
|
After Width: | Height: | Size: 128 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
After Width: | Height: | Size: 101 KiB |
|
After Width: | Height: | Size: 110 KiB |
|
After Width: | Height: | Size: 48 KiB |
|
After Width: | Height: | Size: 404 KiB |
|
After Width: | Height: | Size: 211 KiB |
|
After Width: | Height: | Size: 27 KiB |
@@ -0,0 +1,574 @@
|
||||
# 【Глава 7】Настройка Xray на сервере
|
||||
|
||||
## 7.1 Познать многое, усвоить нужное; копить постепенно, тратить осмотрительно
|
||||
|
||||
Во время написания этого руководства один знакомый в шутку заметил: "Твое руководство уже 6 глав публикуется, а до Xray всё никак не дойдёт. Кто не знает, подумает, что это руководство "Создание сайта с нуля". (И ведь не поспоришь! 😂)
|
||||
|
||||
На самом деле такая структура — результат моего осознанного решения. Ведь только заложив прочный фундамент, можно в дальнейшем двигаться вперёд семимильными шагами. Я видел в чатах много новичков, которые не могут правильно использовать даже `nano`, не говоря уже о `WinSCP`. Из-за этого их `config.json`, написанные вручную на удалённом сервере, пестрят ошибками, а поиск и исправление этих ошибок превращается в мучение.
|
||||
|
||||
::: warning
|
||||
Пройдя первые 6 глав, мы вместе с вами преодолели несколько важных этапов: освоили базовые операции Linux, научились удалённо управлять VPS, разобрались с установкой веб-сервера, управлением доменными именами, получением SSL-сертификатов. Оглядываясь назад, разве всё это кажется таким уж сложным? Теперь, имея такой солидный багаж знаний, мы подойдём к установке и настройке Xray с чувством лёгкости и уверенности, ведь всё уже готово!
|
||||
:::
|
||||
|
||||
Дальнейшие шаги предельно просты:
|
||||
|
||||
1. Установка
|
||||
2. Настройка (например, установка TLS-сертификата, настройка `config.json`)
|
||||
3. Запуск
|
||||
4. Оптимизация (например, обновление ядра, включение `bbr`, автоматическое перенаправление `http`-запросов на `https` и т. д.)
|
||||
|
||||
## 7.2 Установка Xray
|
||||
|
||||
Xray основан на проекте с открытым исходным кодом [xray-core](https://github.com/XTLS/Xray-core) (лицензия `MPL 2.0`). Запущенный на сервере, скомпилированный бинарный файл этого проекта, работает как серверная часть Xray; запущенный на локальном компьютере, он становится клиентской частью. Основное различие заключается в **конфигурации**.
|
||||
|
||||
Для установки воспользуемся официальным скриптом. Он предлагает несколько вариантов установки. Вы можете ознакомиться с ними в [репозитории скриптов](https://github.com/XTLS/Xray-install). **В данном руководстве мы будем использовать установку от имени непривилегированного пользователя**.
|
||||
|
||||
На момент написания руководства в скрипте есть небольшая ошибка при установке от имени непривилегированного пользователя, поэтому мы выполним эти шаги вручную. Заодно рассмотрим команду удаления файлов в Linux.
|
||||
|
||||
1. Базовые команды Linux:
|
||||
|
||||
| Номер | Команда | Описание |
|
||||
| :----: | :--------: | :-------------- |
|
||||
| `cmd-14` | `rm` | Удаление файлов |
|
||||
|
||||
2. Скачиваем установочный скрипт:
|
||||
|
||||
```shell
|
||||
wget https://github.com/XTLS/Xray-install/raw/main/install-release.sh
|
||||
```
|
||||
|
||||
3. Запускаем установку:
|
||||
|
||||
```shell
|
||||
sudo bash install-release.sh
|
||||
```
|
||||
|
||||
4. После завершения установки удаляем скрипт:
|
||||
|
||||
```shell
|
||||
rm ~/install-release.sh
|
||||
```
|
||||
|
||||
::: warning
|
||||
При использовании команды `rm` для удаления файлов по умолчанию подразумевается удаление файлов в текущей директории. Однако **я всё же указал полный путь**: `~/install-release.sh`. Это моя привычка, которая повышает безопасность при использовании `rm`. Думаю, вы слышали истории про "программиста, который удалил базу данных и сбежал". 😉
|
||||
:::
|
||||
|
||||
5. Весь процесс показан на гифке:
|
||||
|
||||

|
||||
|
||||
## 7.3 Установка TLS-сертификата для Xray
|
||||
|
||||
Хотя мы уже получили TLS-сертификат, согласно [официальной документации `acme.sh`](https://github.com/acmesh-official/acme.sh/wiki/%E8%AF%B4%E6%98%8E#3-copy%E5%AE%89%E8%A3%85-%E8%AF%81%E4%B9%A6), не рекомендуется использовать полученные файлы сертификата напрямую. Правильный способ — использовать команду `--install-cert` для установки сертификата для нужного приложения. Давайте установим сертификат для `xray-core`.
|
||||
|
||||
1. Чтобы избежать проблем с правами доступа при работе от имени непривилегированного пользователя, создадим папку для сертификатов в домашней директории пользователя `vpsadmin`:
|
||||
|
||||
```shell
|
||||
mkdir ~/xray_cert
|
||||
```
|
||||
|
||||
2. Используем команду `--install-cert` из `acme.sh` для установки (копирования) файлов сертификата:
|
||||
|
||||
```shell
|
||||
acme.sh --install-cert -d sub.yourdomain.com --ecc \
|
||||
--fullchain-file ~/xray_cert/xray.crt \
|
||||
--key-file ~/xray_cert/xray.key
|
||||
```
|
||||
|
||||
3. По умолчанию файл `xray.key` недоступен для чтения другим пользователям, поэтому нужно выдать права на чтение:
|
||||
|
||||
```shell
|
||||
chmod +r ~/xray_cert/xray.key
|
||||
```
|
||||
|
||||
4. Процесс довольно простой, поэтому обойдёмся без гифки:
|
||||
|
||||

|
||||
|
||||
5. `acme.sh` проверяет срок действия сертификата каждые 60 дней и автоматически обновляет его при необходимости. Однако, насколько мне известно, он не устанавливает новый сертификат для `xray-core` автоматически. Поэтому нам нужно добавить автоматическое задание cron, которое будет делать это за нас.
|
||||
|
||||
1. Базовые команды Linux:
|
||||
|
||||
| Номер | Команда | Описание |
|
||||
| :----: | :----------: | :------------------------------------ |
|
||||
| `cmd-15` | `crontab -e` | Редактирование crontab текущего пользователя |
|
||||
|
||||
2. Создаём файл скрипта (`xray-cert-renew.sh`):
|
||||
|
||||
```shell
|
||||
nano ~/xray_cert/xray-cert-renew.sh
|
||||
```
|
||||
|
||||
3. Копируем в него следующий код, заменив `sub.yourdomain.com` на своё доменное имя, и сохраняем файл:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
/home/vpsadmin/.acme.sh/acme.sh --install-cert -d sub.yourdomain.com --ecc --fullchain-file /home/vpsadmin/xray_cert/xray.crt --key-file /home/vpsadmin/xray_cert/xray.key
|
||||
echo "Xray Certificates Renewed"
|
||||
|
||||
chmod +r /home/vpsadmin/xray_cert/xray.key
|
||||
echo "Read Permission Granted for Private Key"
|
||||
|
||||
sudo systemctl restart xray
|
||||
echo "Xray Restarted"
|
||||
```
|
||||
|
||||
::: warning
|
||||
Как заметили пользователи, `acme.sh` имеет команду `reloadcmd`, которая позволяет выполнить произвольную команду после обновления сертификата. Таким образом, можно настроить автоматическую установку сертификата для `Xray`. Однако, поскольку `crontab` — очень полезный и часто используемый инструмент в Linux, в данном руководстве мы будем использовать его для обновления сертификата `Xray`. (Подробнее о команде `reloadcmd` можно прочитать в [документации `acme.sh`](https://github.com/acmesh-official/acme.sh)).
|
||||
|
||||
Кроме того, в момент записи гифки в скрипт не была добавлена команда перезапуска `Xray`, поскольку в планах разработчиков `Xray` — поддержка **горячего обновления сертификатов**. Это означает, что `Xray` сможет автоматически обнаруживать обновление сертификата и перезагружать его без необходимости перезапуска. После добавления этой функции я обновлю конфигурацию `config.json`, включив эту настройку, и удалю команду перезапуска из скрипта.
|
||||
:::
|
||||
|
||||
4. Делаем скрипт исполняемым:
|
||||
|
||||
```shell
|
||||
chmod +x ~/xray_cert/xray-cert-renew.sh
|
||||
```
|
||||
|
||||
5. Запускаем `crontab -e`, чтобы добавить задание на автоматическое выполнение `xray-cert-renew.sh` каждый месяц (не используйте `sudo`, так как мы добавляем задание для пользователя `vpsadmin`. При первом запуске `crontab` вам будет предложено выбрать редактор. Выбираем знакомый нам `nano`!):
|
||||
|
||||
```shell
|
||||
crontab -e
|
||||
```
|
||||
|
||||
6. Добавляем следующую строку в конец файла и сохраняем его:
|
||||
|
||||
```
|
||||
# 1:00am, 1st day each month, run `xray-cert-renew.sh`
|
||||
0 1 1 * * bash /home/vpsadmin/xray_cert/xray-cert-renew.sh
|
||||
```
|
||||
|
||||
7. Весь процесс показан на гифке:
|
||||
|
||||

|
||||
|
||||
## 7.4 Настройка Xray
|
||||
|
||||
Для начала можете ознакомиться с [примерами конфигурации VLESS](https://github.com/XTLS/Xray-examples). В этом руководстве мы будем использовать официальный пример для настройки максимально простого варианта: **один входящий прокси-сервер VLESS + перенаправление с порта 80**. Такая конфигурация обеспечит максимальную скорость и необходимый уровень безопасности в большинстве случаев.
|
||||
|
||||
1. Генерируем валидный `UUID` и сохраняем его (грубо говоря, `UUID` — это уникальный идентификатор, который можно сравнить с отпечатком пальца):
|
||||
|
||||
```shell
|
||||
xray uuid
|
||||
```
|
||||
|
||||
2. Создаём файлы и папки для логов:
|
||||
|
||||
1. Базовые команды Linux:
|
||||
|
||||
| Номер | Команда | Описание |
|
||||
| :----: | :-----: | :---------------------- |
|
||||
| `cmd-16` | `touch` | Создание пустого файла |
|
||||
|
||||
2. Создаём папку для логов в домашней директории пользователя `vpsadmin`:
|
||||
|
||||
```shell
|
||||
mkdir ~/xray_log
|
||||
```
|
||||
|
||||
3. Создаём два файла для логов (логи доступа и логи ошибок):
|
||||
|
||||
```shell
|
||||
touch ~/xray_log/access.log && touch ~/xray_log/error.log
|
||||
```
|
||||
|
||||
::: warning
|
||||
Это не стандартное расположение файлов логов `Xray`. Мы используем его, чтобы избежать проблем с правами доступа, которые могут возникнуть у новичков. Когда разберётесь, рекомендуется использовать стандартные пути: `/var/log/xray/access.log` и `/var/log/xray/error.log`.
|
||||
:::
|
||||
|
||||
4. По умолчанию Xray запускается от имени пользователя `nobody`, поэтому нужно дать другим пользователям права на запись в файлы логов (`*.log` — это все файлы с расширением `log`. Здесь проявляются преимущества использования командной строки):
|
||||
|
||||
```shell
|
||||
chmod a+w ~/xray_log/*.log
|
||||
```
|
||||
|
||||
3. Создаём файл конфигурации `Xray` с помощью `nano`:
|
||||
|
||||
```shell
|
||||
sudo nano /usr/local/etc/xray/config.json
|
||||
```
|
||||
|
||||
4. Копируем в него следующий код и вставляем сгенерированный ранее `UUID` в строку 61: `"id": "",` (должно получиться что-то вроде `"id": "uuiduuid-uuid-uuid-uuid-uuiduuiduuid"`). В этом файле конфигурации я добавил свои комментарии, чтобы вам было проще понять, за что отвечает каждый модуль.
|
||||
|
||||
```json
|
||||
// ССЫЛКИ:
|
||||
// https://github.com/XTLS/Xray-examples
|
||||
// https://xtls.github.io/config/
|
||||
// Типичный конфигурационный файл, как для сервера, так и для клиента, состоит из 5 основных частей. Разберём их по полочкам:
|
||||
// ┌─ 1_log Настройки логирования - что и куда писать в лог (чтобы было проще искать ошибки)
|
||||
// ├─ 2_dns Настройки DNS - как выполнять DNS-запросы (защита от DNS-спуфинга, защита от слежки, предотвращение маршрутизации трафика на китайские серверы и т. д.)
|
||||
// ├─ 3_routing Настройки маршрутизации - как обрабатывать трафик (фильтрация рекламы, разделение трафика для разных стран)
|
||||
// ├─ 4_inbounds Настройки входящих подключений - какой трафик может поступать на Xray
|
||||
// └─ 5_outbounds Настройки исходящих подключений - куда направлять трафик, исходящий от Xray
|
||||
{
|
||||
// 1_Настройки логирования
|
||||
"log": {
|
||||
"loglevel": "warning", // Уровень детализации логов: "none", "error", "warning", "info", "debug" (от меньшего к большему)
|
||||
"access": "/home/vpsadmin/xray_log/access.log", // Файл для записи логов доступа
|
||||
"error": "/home/vpsadmin/xray_log/error.log" // Файл для записи логов ошибок
|
||||
},
|
||||
// 2_Настройки DNS
|
||||
"dns": {
|
||||
"servers": [
|
||||
"https+local://1.1.1.1/dns-query", // Используем DoH-сервер 1.1.1.1 в первую очередь. Это снижает скорость, но защищает от слежки со стороны интернет-провайдера
|
||||
"localhost"
|
||||
]
|
||||
},
|
||||
// 3_Настройки маршрутизации
|
||||
"routing": {
|
||||
"domainStrategy": "IPIfNonMatch",
|
||||
"rules": [
|
||||
// 3.1 Предотвращение проблем с локальной маршрутизацией: атаки на внутреннюю сеть, неправильная обработка локальных адресов и т. д.
|
||||
{
|
||||
"type": "field",
|
||||
"ip": [
|
||||
"geoip:private" // Условие: адреса из списка "private" в файле geoip (локальные адреса)
|
||||
],
|
||||
"outboundTag": "block" // Действие: отправить трафик на исходящее подключение "block" (блокировка)
|
||||
},
|
||||
{
|
||||
// 3.2 Предотвращение прямого подключения к китайским серверам
|
||||
"type": "field",
|
||||
"ip": ["geoip:cn"],
|
||||
"outboundTag": "block"
|
||||
},
|
||||
// 3.3 Блокировка рекламы
|
||||
{
|
||||
"type": "field",
|
||||
"domain": [
|
||||
"geosite:category-ads-all" // Условие: домены из списка "category-ads-all" в файле geosite (рекламные домены)
|
||||
],
|
||||
"outboundTag": "block" // Действие: отправить трафик на исходящее подключение "block" (блокировка)
|
||||
}
|
||||
]
|
||||
},
|
||||
// 4_Настройки входящих подключений
|
||||
// 4.1 Здесь указан только один простейший входящий прокси-сервер vless+xtls, так как это самый производительный режим Xray. При необходимости вы можете добавить другие прокси-серверы, используя этот шаблон.
|
||||
"inbounds": [
|
||||
{
|
||||
"port": 443,
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "", // Укажите свой UUID
|
||||
"flow": "xtls-rprx-vision",
|
||||
"level": 0,
|
||||
"email": "vpsadmin@yourdomain.com"
|
||||
}
|
||||
],
|
||||
"decryption": "none",
|
||||
"fallbacks": [
|
||||
{
|
||||
"dest": 80 // Перенаправлять на порт 80 по умолчанию
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
"network": "tcp",
|
||||
"security": "tls",
|
||||
"tlsSettings": {
|
||||
"alpn": "http/1.1",
|
||||
"certificates": [
|
||||
{
|
||||
"certificateFile": "/home/vpsadmin/xray_cert/xray.crt",
|
||||
"keyFile": "/home/vpsadmin/xray_cert/xray.key"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
// 5_Настройки исходящих подключений
|
||||
"outbounds": [
|
||||
// 5.1 Первое исходящее подключение - это правило по умолчанию. freedom - это прямое подключение (VPS и так находится во внешней сети)
|
||||
{
|
||||
"tag": "direct",
|
||||
"protocol": "freedom"
|
||||
},
|
||||
// 5.2 Правило блокировки. Протокол blackhole отправляет трафик в никуда (блокирует его)
|
||||
{
|
||||
"tag": "block",
|
||||
"protocol": "blackhole"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
5. Весь процесс показан на гифке:
|
||||
|
||||

|
||||
|
||||
## 7.5 Запуск Xray! (и проверка состояния сервиса)
|
||||
|
||||
Если вы всё делали по инструкции, то должны были избежать двух самых распространённых ошибок: **недостаточно прав для записи в файлы логов** и **недостаточно прав для чтения файлов сертификата**. Так что запуск `Xray` должен пройти без сучка и задоринки.
|
||||
|
||||
1. Вводим команду и наслаждаемся историческим моментом запуска `Xray`!!!
|
||||
|
||||
```shell
|
||||
sudo systemctl start xray
|
||||
```
|
||||
|
||||
2. Однако просто выполнить команду `start` недостаточно, чтобы убедиться, что сервис `Xray` запущен и работает корректно. Для проверки состояния сервиса используем следующую команду:
|
||||
|
||||
```shell
|
||||
sudo systemctl status xray
|
||||
```
|
||||
|
||||
Видите надпись зелёного цвета `active (running)`? Это означает, что `Xray` запущен и работает.
|
||||
|
||||
3. Весь процесс показан на гифке:
|
||||
|
||||

|
||||
|
||||
## 7.6 Базовое управление сервисами с помощью `systemd`
|
||||
|
||||
Мы уже использовали несколько команд `systemctl`: `start`, `status`, `reload`. Все эти команды используются для управления сервисами в Linux с помощью системы инициализации `systemd`. Давайте рассмотрим ещё несколько полезных команд.
|
||||
|
||||
1. Чтобы временно остановить сервис `Xray`, используем команду `stop`:
|
||||
|
||||
```shell
|
||||
sudo systemctl stop xray
|
||||
```
|
||||
|
||||
2. Чтобы перезапустить сервис `Xray`, используем команду `restart`:
|
||||
|
||||
```shell
|
||||
sudo systemctl restart xray
|
||||
```
|
||||
|
||||
3. Чтобы запретить автозапуск сервиса `Xray` после перезагрузки, используем команду `disable`:
|
||||
|
||||
```shell
|
||||
sudo systemctl disable xray
|
||||
```
|
||||
|
||||
4. Чтобы разрешить автозапуск сервиса `Xray` после перезагрузки, используем команду `enable`:
|
||||
|
||||
```shell
|
||||
sudo systemctl enable xray
|
||||
```
|
||||
|
||||
## 7.7 Оптимизация сервера: включение BBR
|
||||
|
||||
1. Что говорят о `BBR`
|
||||
|
||||
Уверен, что, изучая различные способы обхода блокировок, вы не раз сталкивались с аббревиатурой `bbr`. В многочисленных блогах её расхваливают на все лады, наделяя чуть ли не магическими свойствами. Существуют также различные модификации, такие как `bbrplus`, `bbr2`, `магически модифицированный bbr` и т. д. Создаётся ощущение, что это какая-то волшебная палочка, которая превращает тыкву в карету, а медленный интернет — в сверхскоростной.
|
||||
|
||||
Так что же такое `BBR` на самом деле? Действительно ли он так хорош? И какую версию использовать?
|
||||
|
||||
2. `BBR` на самом деле
|
||||
|
||||
**BBR** = **B**ottleneck **B**andwidth and **R**ound-trip propagation time — это алгоритм управления перегрузками для протокола TCP. Проще говоря, это **регулировщик дорожного движения для интернет-трафика**: когда на дороге нет пробок, каждая машина может двигаться с максимальной скоростью.
|
||||
|
||||
Так работает ли он? Как правило, разница между включенным и выключенным `BBR` заметна (улучшается скорость, стабильность и снижается пинг), поэтому **настоятельно рекомендуется включить `BBR`**.
|
||||
|
||||
Однако разница между версиями `BBR` для ядер 4.x и 5.x зачастую не столь существенна и зависит от конкретной ситуации. Решающим фактором, влияющим на качество связи, по-прежнему остаётся качество самого интернет-канала. Поэтому **не стоит гнаться за новейшими версиями `BBR`. Достаточно использовать версию, которая поставляется с вашей версией дистрибутива Linux**.
|
||||
|
||||
3. Действительно ли `bbrplus`, `bbr2`, `магически модифицированный bbr` и другие версии с крутыми названиями лучше?
|
||||
|
||||
Одним словом: **нет! Не используйте их! Все эти названия придуманы только для привлечения внимания!**
|
||||
|
||||
Обновления `BBR` выпускаются вместе с обновлениями ядра Linux (`Kernel`). Другими словами, если вы используете относительно новое ядро, то у вас уже будет установлена последняя версия `BBR`.
|
||||
|
||||
А все эти скрипты с крутыми названиями просто скачивают и устанавливают предварительные версии ядра (или даже модифицированные сторонними разработчиками версии) с более новыми версиями `BBR`.
|
||||
|
||||
Стабильность ядра — это основа стабильной работы сервера. **Незначительное повышение производительности, которое могут дать тестовые версии `BBR`, не стоит того, чтобы рисковать стабильностью сервера.** Используйте последнюю версию ядра, которая поддерживается вашим дистрибутивом Linux. Это обеспечит максимальную стабильность и совместимость вашего сервера.
|
||||
|
||||
::: warning
|
||||
Так называемое "преимущество" модифицированных версий `bbr` **очень недолговечно**. Например, многие скрипты `bbrplus` до сих пор устанавливают ядро версии 4.19, поскольку не обновлялись уже несколько лет. А ведь на дворе уже эпоха Debian 11 с ядром 5.10! То есть, если в январе 2018 года этот скрипт, возможно, и давал какое-то преимущество, то уже к октябрю 2018 года, когда вышла стабильная версия ядра 4.19, он потерял всякий смысл. А сейчас его использование и вовсе можно назвать **даунгрейдом**.
|
||||
:::
|
||||
|
||||
4. Какой алгоритм управления очередями использовать: `fq`, `fq_codel`, `fq_pie`, `cake` или какой-то другой?
|
||||
|
||||
Одним словом: **если не знаете, что выбрать, оставьте `fq`. Этого достаточно, и это не ухудшит качество связи**.
|
||||
|
||||
5. Стоит ли использовать "ускорители" типа **锐速**, **Finalspeed**, **LotServer**?
|
||||
|
||||
Одним словом: **нет! Забудьте о них, как о страшном сне!**
|
||||
|
||||
Единственная проблема, которую они решают, — это проблема потери пакетов. Если проводить аналогию, то представьте, что вам нужно отправить груз, но машина, которая его везёт, иногда ломается по дороге (теряются пакеты). Эти "ускорители" просто отправляют три одинаковых груза на трёх машинах одновременно. Даже если две машины сломаются, третья всё равно доставит груз. Конечно, если на дороге будет много ваших машин, то вы будете создавать помехи другим участникам движения. Но и они будут создавать помехи вам. А поскольку пропускная способность канала ограничена, то в итоге все будут стоять в пробке.
|
||||
|
||||
::: warning
|
||||
Эти "ускорители" не оптимизируют алгоритмы и не увеличивают скорость соединения. В большинстве своём это просто **увеличители количества отправляемых пакетов**. Для каналов с **очень высокими потерями пакетов** они могут дать незначительный эффект, но **для хороших каналов с низкими потерями пакетов они бесполезны и даже вредны, поскольку увеличивают расход трафика**. Это создаёт ненужную нагрузку на сервер и на каналы других пользователей.
|
||||
|
||||
Если у вас действительно плохой канал с высокими потерями пакетов, то единственное правильное решение — **сменить провайдера**.
|
||||
:::
|
||||
|
||||
6. Я так подробно остановился на `BBR`, потому что вокруг него слишком много мифов и откровенной дезинформации, нацеленной на новичков. Надеюсь, теперь у вас есть чёткое представление о том, что такое `BBR` и как он работает. А теперь давайте установим последнюю версию ядра Debian и включим `BBR`! (Это действительно просто)
|
||||
|
||||
1. Добавляем репозиторий `backports` в Debian 10, чтобы получить доступ к более новым версиям пакетов:
|
||||
|
||||
```shell
|
||||
sudo nano /etc/apt/sources.list
|
||||
```
|
||||
|
||||
::: warning
|
||||
В Debian 10 можно без проблем использовать файл `/etc/apt/sources.list`. Однако, если вы используете другой дистрибутив Linux или не устанавливали систему с нуля по этой инструкции, то рекомендуется создать папку `/etc/apt/sources.list.d/` и добавлять свои файлы конфигурации в неё, например, `/etc/apt/sources.list.d/vpsadmin.list`. Это обеспечит совместимость с другими дистрибутивами и предотвратит потерю настроек при случайном перезаписывании файла `/etc/apt/sources.list`.
|
||||
:::
|
||||
|
||||
2. Добавляем следующую строку в конец файла и сохраняем его:
|
||||
|
||||
```
|
||||
deb http://archive.debian.org/debian buster-backports main
|
||||
```
|
||||
|
||||
3. Обновляем список доступных пакетов, ищем последнюю версию ядра Debian и устанавливаем её. Устанавливайте версию ядра, которая подходит для вашей архитектуры (в данном руководстве мы используем `amd64`):
|
||||
|
||||
```shell
|
||||
sudo apt update && sudo apt -t buster-backports install linux-image-amd64
|
||||
```
|
||||
|
||||
::: warning
|
||||
Если ваш VPS поддерживает это, вы можете попробовать установить **специальное ядро для облачных серверов** `linux-image-cloud-amd64`. Его преимущества — это меньший размер и меньшее потребление ресурсов. Однако некоторые пользователи сталкивались с проблемами при установке этого ядра на неподдерживаемые системы, вплоть до невозможности загрузки (ядро не определялось).
|
||||
|
||||
Чтобы не попасть в такую ситуацию, перед установкой этого ядра:
|
||||
|
||||
- создайте снапшот системы или
|
||||
- убедитесь, что у вас есть доступ к `vnc`-консоли (и вы знаете, как ей пользоваться)
|
||||
|
||||
:::
|
||||
|
||||
4. Редактируем файл конфигурации `sysctl.conf` и включаем `BBR`:
|
||||
|
||||
```shell
|
||||
sudo nano /etc/sysctl.conf
|
||||
```
|
||||
|
||||
::: warning
|
||||
В Debian 10 можно без проблем использовать файл `/etc/sysctl.conf`. Однако, если вы используете другой дистрибутив Linux или не устанавливали систему с нуля по этой инструкции, то рекомендуется создать папку `/etc/sysctl.d/` и добавлять свои файлы конфигурации в неё, например, `/etc/sysctl.d/vpsadmin.conf`. Это обеспечит совместимость с другими дистрибутивами, поскольку в некоторых из них, начиная с версии `systemd` 207, параметры из файла `/etc/sysctl.conf` не читаются. Использование отдельного файла конфигурации также предотвратит потерю настроек при случайном перезаписывании файла `/etc/sysctl.conf`.
|
||||
:::
|
||||
|
||||
5. Добавляем следующие строки в конец файла:
|
||||
|
||||
```
|
||||
net.core.default_qdisc=fq
|
||||
net.ipv4.tcp_congestion_control=bbr
|
||||
```
|
||||
|
||||
6. Перезагружаем VPS, чтобы изменения вступили в силу:
|
||||
|
||||
```shell
|
||||
sudo reboot
|
||||
```
|
||||
|
||||
7. Весь процесс показан на гифке:
|
||||
|
||||
::: tip
|
||||
На моём VPS поддерживается специальное ядро для облачных серверов, поэтому на гифке я устанавливаю `linux-image-cloud-amd64`. Если вы не уверены, поддерживается ли оно на вашем VPS, то установите обычное ядро `linux-image-amd64`, как показано в пункте 3.
|
||||
:::
|
||||
|
||||

|
||||
|
||||
8. Проверяем, что `BBR` включен
|
||||
|
||||
Чтобы убедиться, что модуль `BBR` загружен, выполните команду:
|
||||
|
||||
```shell
|
||||
lsmod | grep bbr
|
||||
```
|
||||
|
||||
В результате вы должны увидеть что-то вроде этого:
|
||||
|
||||
```
|
||||
tcp_bbr
|
||||
```
|
||||
|
||||
Чтобы убедиться, что алгоритм `fq` используется, выполните команду:
|
||||
|
||||
```shell
|
||||
lsmod | grep fq
|
||||
```
|
||||
|
||||
В результате вы должны увидеть что-то вроде этого:
|
||||
|
||||
```
|
||||
sch_fq
|
||||
```
|
||||
|
||||
## 7.8 Оптимизация сервера: автоматическое перенаправление HTTP на HTTPS
|
||||
|
||||
1. Ранее мы настроили веб-сервер на порту 80 и получили TLS-сертификат.
|
||||
|
||||
Однако, если вы попытаетесь открыть наш сайт по протоколу HTTP, то заметите, что он не перенаправляется автоматически на HTTPS, как это делают большинство сайтов. Другими словами, в нашей текущей конфигурации HTTP (порт 80) и HTTPS (порт 443) — это два совершенно независимых сайта. Чтобы это исправить, нужно внести некоторые изменения.
|
||||
|
||||
2. Открываем файл конфигурации Nginx:
|
||||
|
||||
```shell
|
||||
sudo nano /etc/nginx/nginx.conf
|
||||
```
|
||||
|
||||
3. В настройках сервера, который слушает порт 80, добавляем следующую строку и сохраняем файл (строки `root` и `index` можно удалить):
|
||||
|
||||
```
|
||||
return 301 https://$http_host$request_uri;
|
||||
```
|
||||
|
||||
4. Добавляем новый сервер, который будет прослушивать локальный порт и отдавать файлы сайта. В данном примере мы будем использовать порт 8080 (вы можете использовать любой другой порт):
|
||||
|
||||
```
|
||||
server {
|
||||
listen 127.0.0.1:8080;
|
||||
root /home/vpsadmin/www/webpage;
|
||||
index index.html;
|
||||
add_header Strict-Transport-Security "max-age=63072000" always;
|
||||
}
|
||||
```
|
||||
|
||||
5. Перезапускаем Nginx:
|
||||
|
||||
```shell
|
||||
sudo systemctl restart nginx
|
||||
```
|
||||
|
||||
6. Изменяем настройки перенаправления в файле конфигурации Xray, заменив порт 80 на 8080 (находим `"dest": 80` и меняем на `"dest": 8080`):
|
||||
|
||||
```shell
|
||||
sudo nano /usr/local/etc/xray/config.json
|
||||
```
|
||||
|
||||
7. Перезапускаем Xray:
|
||||
|
||||
```shell
|
||||
sudo systemctl restart xray
|
||||
```
|
||||
|
||||
8. Весь процесс показан на гифке:
|
||||
|
||||

|
||||
|
||||
9. Теперь, если вы попытаетесь открыть сайт по адресу `http://sub.yourdomain.com`, он должен автоматически перенаправиться на HTTPS:
|
||||
|
||||

|
||||
|
||||
## 7.9 Оптимизация сервера: более гибкая настройка перенаправления
|
||||
|
||||
Если вам нужны более гибкие настройки перенаправления, обратитесь к статье [«Разбор функции Fallback»](../level-1/fallbacks-lv1/).
|
||||
|
||||
## 7.10 Ваши успехи
|
||||
|
||||
Поздравляю! На этом этапе у вас есть работающий сервер с обходом блокировок и сайт-приманка, который защитит вас от сканирования. Теперь достаточно установить клиентское приложение на ваше устройство — и можно наслаждаться свободным интернетом!
|
||||
|
||||
> ⬛⬛⬛⬛⬛⬛⬛⬜ 87.5%
|
||||
|
||||
## 7.11 Важные исправления
|
||||
|
||||
1. В первоначальной версии руководства был указан неверный путь к файлу конфигурации `Xray` (`config.json`). Если вы настроили `Xray` по старой инструкции, то он не запустится. Приносим извинения за неудобства!
|
||||
|
||||
- Верный путь: `/usr/local/etc/xray/config.json`
|
||||
- Неверный путь: `/usr/local/etc/config.json`
|
||||
|
||||
Затронутые разделы:
|
||||
|
||||
- 7.4 Настройка Xray - 3. Создание файла конфигурации `Xray` с помощью `nano`
|
||||
- 7.8 Оптимизация сервера: автоматическое перенаправление HTTP на HTTPS - 6. Изменяем настройки перенаправления в файле конфигурации Xray
|
||||
|
||||
2. В первоначальной версии руководства была ошибка в настройках Nginx (неверный путь к папке с файлами сайта). Если вы настроили Nginx по старой инструкции, то сайт не будет работать. Приносим извинения за неудобства!
|
||||
|
||||
- Верный путь: `root /home/vpsadmin/www/webpage;`
|
||||
- Неверный путь: `root /var/www/website/html`
|
||||
|
||||
Затронутые разделы:
|
||||
|
||||
- 7.8 Оптимизация сервера: автоматическое перенаправление HTTP на HTTPS - 4. Добавляем новый сервер, который будет прослушивать локальный порт и отдавать файлы сайта.
|
||||
|
After Width: | Height: | Size: 335 KiB |
|
After Width: | Height: | Size: 686 KiB |
@@ -0,0 +1,336 @@
|
||||
# 【Глава 8】Настройка Xray на клиенте
|
||||
|
||||
## 8.1 Как работает Xray: краткое описание
|
||||
|
||||
Чтобы правильно настраивать и использовать `Xray`, важно понимать принципы его работы. Новичкам поможет упрощённая схема, на которой не показаны некоторые сложные моменты:
|
||||
|
||||

|
||||
|
||||
Ключевые моменты:
|
||||
|
||||
1. Приложение должно самостоятельно или с помощью стороннего инструмента перенаправить трафик на **входящее подключение** (`inbounds`) клиента `Xray`.
|
||||
|
||||
2. Поступивший на клиент трафик обрабатывается **модулем маршрутизации** (`routing`) в соответствии с заданными правилами и перенаправляется на разные **исходящие подключения** (`outbounds`) клиента `Xray`, например:
|
||||
|
||||
- Трафик на китайские ресурсы — напрямую (`direct`)
|
||||
- Трафик на зарубежные ресурсы — через VPS (`proxy`)
|
||||
- Рекламный трафик — блокируется (`block`)
|
||||
|
||||
3. Трафик на зарубежные ресурсы, перенаправленный на VPS, проходит через Великий Китайский Файрвол и попадает на **входящее подключение** (`inbounds`) сервера `Xray`.
|
||||
|
||||
4. Как и на клиенте, трафик, поступивший на сервер, обрабатывается **модулем маршрутизации** (`routing`) в соответствии с заданными правилами и перенаправляется на разные **исходящие подключения** (`outbounds`):
|
||||
|
||||
- Поскольку сервер находится за пределами Китая, трафик по умолчанию идёт напрямую, что позволяет получить доступ к заблокированным ресурсам (`direct`).
|
||||
- При необходимости можно настроить перенаправление трафика на другие VPS (`proxy`).
|
||||
- На сервере также можно блокировать нежелательный трафик, например, рекламу или торренты (`block`).
|
||||
|
||||
:::warning Внимание!
|
||||
|
||||
Важно помнить, что маршрутизация в `Xray` очень гибкая, и описанный выше сценарий — лишь один из множества возможных.
|
||||
|
||||
Используя файлы `geosite.dat` и `geoip.dat`, можно очень гибко управлять маршрутизацией трафика по доменным именам и IP-адресам. Это гораздо удобнее, чем устаревший `GFWList`, поскольку позволяет очень точно настроить правила: например, можно разрешить прямое подключение к доменам Apple, перенаправить трафик на домены Amazon через прокси-сервер, блокировать доступ к доменам Baidu и т. д.
|
||||
|
||||
Более подробно о маршрутизации в Xray читайте в статье [«Разбор функции маршрутизации (routing)»](../level-1/routing-lv1-part1.md). Советую сначала дочитать эту главу и настроить базовый клиент, а потом уже углубляться в тонкости маршрутизации.
|
||||
:::
|
||||
|
||||
## 8.2 Подключение клиента к серверу
|
||||
|
||||
Теперь, когда вы понимаете принципы работы `Xray`, настройка клиента сводится к тому, чтобы **сообщить ему, как подключиться к вашему VPS**. Это как настроить `PuTTY` для подключения к серверу, только в случае с Xray параметров подключения больше, чем IP-адрес, порт, имя пользователя и пароль.
|
||||
|
||||
Набор параметров подключения в `Xray` зависит от используемого [протокола](../../config/inbounds/). В главе 7 мы настроили сервер на использование протокола `VLESS` с шифрованием `XTLS`. Посмотрим на файл конфигурации сервера, чтобы узнать, какие параметры нужны для подключения:
|
||||
|
||||
- **Адрес сервера**: `sub.yourdomain.com`
|
||||
- **Порт сервера**: `443`
|
||||
- **Протокол**: `vless`
|
||||
- **Поток**: `xtls-rprx-vision` (режим `vision` подходит для всех платформ)
|
||||
- **Идентификатор**: `uuiduuid-uuid-uuid-uuid-uuiduuiduuid`
|
||||
- **Безопасность**: `"allowInsecure": false`
|
||||
|
||||
Ниже приведен список популярных клиентов Xray для мобильных и настольных устройств. Каждый клиент имеет свой собственный интерфейс, поэтому я не буду делать скриншоты для каждого из них. Внимательно изучите документацию к выбранному клиенту и укажите нужные параметры подключения.
|
||||
|
||||
:::warning Внимание!
|
||||
|
||||
Многие клиенты поддерживают как `xray-core`, так и `v2fly-core`. Но по умолчанию может использоваться не тот, который вам нужен. Убедитесь, что вы выбрали нужный инструмент!
|
||||
:::
|
||||
|
||||
- **v2rayN - для Windows**
|
||||
|
||||
- Скачайте последнюю версию из [репозитория на GitHub](https://github.com/2dust/v2rayN/releases)
|
||||
- Настройте клиент в соответствии с документацией
|
||||
|
||||
- **v2rayNG - для Android**
|
||||
|
||||
- Скачайте последнюю версию из [репозитория на GitHub](https://github.com/2dust/v2rayNG/releases)
|
||||
- Настройте клиент в соответствии с документацией
|
||||
|
||||
- **Shadowrocket - для iOS, macOS на базе Apple M1**
|
||||
|
||||
- Создайте учётную запись iCloud **не** в китайском регионе
|
||||
- Купите приложение в App Store
|
||||
- Настройте клиент в соответствии с документацией
|
||||
|
||||
- **Qv2ray - кроссплатформенный графический интерфейс для Linux, Windows, macOS**
|
||||
|
||||
- Скачайте последнюю версию из [репозитория на GitHub](https://github.com/Qv2ray/Qv2ray/releases) (или более новую версию из раздела [сборок на GitHub](https://github.com/Qv2ray/Qv2ray/actions))
|
||||
- Изучите документацию на [сайте проекта](https://qv2ray.net/)
|
||||
- Настройте клиент в соответствии с документацией
|
||||
|
||||
- **V2RayXS - клиент для macOS, основанный на V2RayX и использующий xray-core**
|
||||
|
||||
- Скачайте последнюю версию из [репозитория на GitHub](https://github.com/tzmax/v2rayXS/releases)
|
||||
- Поддерживает импорт ссылок на конфигурации VLESS / VMessAEAD по стандарту, предложенному в [этой задаче](https://github.com/XTLS/Xray-core/issues/91)
|
||||
- Настройте клиент в соответствии с документацией
|
||||
|
||||
На этом этапе ваша система готова к работе!
|
||||
|
||||
## 8.3 Дополнительное задание 1: настройка `xray-core` на ПК вручную
|
||||
|
||||
Хотя на предыдущем шаге мы уже всё настроили, любознательным и обладающим хорошей памятью читателям наверняка вспомнятся мои слова из предыдущей главы о том, что `xray-core` можно запускать как на сервере, так и на клиенте. Так как же использовать `xray-core` в качестве клиента?
|
||||
|
||||
Чтобы ответить на этот вопрос, я добавил этот раздел с дополнительным заданием. Оно немного выходит за рамки основного материала и может показаться сложным, но у него есть свои преимущества:
|
||||
|
||||
- Вы всегда будете использовать самую последнюю версию `xray-core`, не дожидаясь, пока разработчики клиентов выпустят обновления.
|
||||
- Вы получите максимальную гибкость в настройке маршрутизации (хотя стоит отметить, что Qv2ray имеет мощный редактор маршрутизации, который позволяет настраивать все функции `xray-core`).
|
||||
- Вы сэкономите системные ресурсы (графические клиенты всегда потребляют больше ресурсов, чем консольные).
|
||||
|
||||
Недостаток этого способа заключается в том, что вам придётся **настраивать клиент вручную, редактируя файл конфигурации**. Но ведь на сервере вы уже делали это, так что ничего сложного здесь нет. Давайте разберёмся по шагам:
|
||||
|
||||
1. Скачайте последнюю версию `xray-core` для вашей платформы из [репозитория на GitHub](https://github.com/XTLS/Xray-core/releases) и распакуйте архив в удобное место.
|
||||
2. Создайте пустой файл конфигурации `config.json` в той же папке (думаю, с этим проблем не возникнет).
|
||||
3. Что значит "удобное место"? Это зависит от платформы.
|
||||
4. Заполните файл конфигурации.
|
||||
|
||||
- Я написал пример конфигурации, основанный на схеме из раздела 8.1 (прямое подключение к китайским ресурсам, проксирование трафика на зарубежные ресурсы через VPS, блокировка рекламы) и параметрах подключения из раздела 8.2.
|
||||
- Замените `uuid` на идентификатор из вашей конфигурации сервера.
|
||||
- Замените `address` на доменное имя вашего сервера.
|
||||
- Замените `serverName` на доменное имя вашего сервера.
|
||||
- Я добавил подробные комментарии к каждому разделу конфигурации.
|
||||
|
||||
```json
|
||||
// ССЫЛКИ:
|
||||
// https://github.com/XTLS/Xray-examples
|
||||
// https://xtls.github.io/config/
|
||||
|
||||
// Типичный конфигурационный файл, как для сервера, так и для клиента, состоит из 5 основных частей. Разберём их по полочкам:
|
||||
// ┌─ 1_log Настройки логирования - что и куда писать в лог (чтобы было проще искать ошибки)
|
||||
// ├─ 2_dns Настройки DNS - как выполнять DNS-запросы (защита от DNS-спуфинга, защита от слежки, предотвращение маршрутизации трафика на китайские серверы и т. д.)
|
||||
// ├─ 3_routing Настройки маршрутизации - как обрабатывать трафик (фильтрация рекламы, разделение трафика для разных стран)
|
||||
// ├─ 4_inbounds Настройки входящих подключений - какой трафик может поступать на Xray
|
||||
// └─ 5_outbounds Настройки исходящих подключений - куда направлять трафик, исходящий от Xray
|
||||
|
||||
{
|
||||
// 1_Настройки логирования
|
||||
// В этом примере я закомментировал настройки файлов логов, потому что в Windows, macOS и Linux используются разные пути. Укажите свои пути.
|
||||
"log": {
|
||||
// "access": "/home/local/xray_log/access.log", // Файл для записи логов доступа
|
||||
// "error": "/home/local/xray_log/error.log", // Файл для записи логов ошибок
|
||||
"loglevel": "warning" // Уровень детализации логов: "none", "error", "warning", "info", "debug" (от меньшего к большему)
|
||||
},
|
||||
|
||||
// 2_Настройки DNS
|
||||
"dns": {
|
||||
"servers": [
|
||||
// 2.1 Запросы к зарубежным доменам отправляем на зарубежный DNS-сервер
|
||||
{
|
||||
"address": "1.1.1.1",
|
||||
"domains": ["geosite:geolocation-!cn"]
|
||||
},
|
||||
// 2.2 Запросы к китайским доменам отправляем на китайский DNS-сервер и ожидаем получить китайский IP-адрес. Если адрес не китайский, используем следующий DNS-сервер
|
||||
{
|
||||
"address": "223.5.5.5",
|
||||
"domains": ["geosite:cn"],
|
||||
"expectIPs": ["geoip:cn"]
|
||||
},
|
||||
// 2.3 Резервный китайский DNS-сервер
|
||||
{
|
||||
"address": "114.114.114.114",
|
||||
"domains": ["geosite:cn"]
|
||||
},
|
||||
// 2.4 Если все предыдущие DNS-серверы не ответили, используем локальный DNS-сервер
|
||||
"localhost"
|
||||
]
|
||||
},
|
||||
|
||||
// 3_Настройки маршрутизации
|
||||
// Маршрутизация позволяет перенаправлять трафик, соответствующий определённым условиям, на определённое исходящее подключение (см. раздел 5).
|
||||
"routing": {
|
||||
"domainStrategy": "IPIfNonMatch",
|
||||
"rules": [
|
||||
// 3.1 Блокировка рекламных доменов
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["geosite:category-ads-all"],
|
||||
"outboundTag": "block"
|
||||
},
|
||||
// 3.2 Прямое подключение к китайским доменам
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["geosite:cn"],
|
||||
"outboundTag": "direct"
|
||||
},
|
||||
// 3.3 Прямое подключение к китайским IP-адресам
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["geoip:cn", "geoip:private"],
|
||||
"outboundTag": "direct"
|
||||
},
|
||||
// 3.4 Проксирование трафика на зарубежные домены
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["geosite:geolocation-!cn"],
|
||||
"outboundTag": "proxy"
|
||||
},
|
||||
// 3.5 Правило по умолчанию
|
||||
// В Xray любой трафик, который не соответствует ни одному из правил маршрутизации, отправляется на первое исходящее подключение (см. раздел 5.1). Поэтому важно разместить настройки прокси-сервера на первом месте.
|
||||
// 3.6 Трафик, который идёт на DNS-сервер 223.5.5.5, отправляем напрямую
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["223.5.5.5"],
|
||||
"outboundTag": "direct"
|
||||
}
|
||||
]
|
||||
},
|
||||
|
||||
// 4_Настройки входящих подключений
|
||||
"inbounds": [
|
||||
// 4.1 Обычно используется протокол SOCKS5 для локального перенаправления трафика
|
||||
{
|
||||
"tag": "socks-in",
|
||||
"protocol": "socks",
|
||||
"listen": "127.0.0.1", // Адрес, на котором будет слушать SOCKS5-сервер
|
||||
"port": 10800, // Порт, на котором будет слушать SOCKS5-сервер
|
||||
"settings": {
|
||||
"udp": true
|
||||
}
|
||||
},
|
||||
// 4.2 Некоторые приложения не поддерживают SOCKS. Для них можно использовать HTTP-прокси
|
||||
{
|
||||
"tag": "http-in",
|
||||
"protocol": "http",
|
||||
"listen": "127.0.0.1", // Адрес, на котором будет слушать HTTP-сервер
|
||||
"port": 10801 // Порт, на котором будет слушать HTTP-сервер
|
||||
}
|
||||
],
|
||||
|
||||
// 5_Настройки исходящих подключений
|
||||
"outbounds": [
|
||||
// 5.1 Настройки прокси-сервера
|
||||
// Этот раздел должен быть первым, как уже было сказано в разделе 3.5. Все правила по умолчанию будут использовать эти настройки.
|
||||
{
|
||||
"tag": "proxy",
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"vnext": [
|
||||
{
|
||||
"address": "sub.yourdomain.com", // Замените на доменное имя вашего сервера
|
||||
"port": 443,
|
||||
"users": [
|
||||
{
|
||||
"id": "uuiduuid-uuid-uuid-uuid-uuiduuiduuid", // Должен совпадать с идентификатором на сервере
|
||||
"flow": "xtls-rprx-vision",
|
||||
"encryption": "none",
|
||||
"level": 0
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
"network": "tcp",
|
||||
"security": "tls",
|
||||
"tlsSettings": {
|
||||
"serverName": "sub.yourdomain.com", // Замените на доменное имя вашего сервера
|
||||
"allowInsecure": false, // Запретить использование недоверенных сертификатов
|
||||
"fingerprint": "chrome" // Использовать uTLS для подмены отпечатка браузера Chrome / Firefox / Safari или случайный отпечаток
|
||||
}
|
||||
}
|
||||
},
|
||||
// 5.2 Прямое подключение
|
||||
// Используется, если в настройках маршрутизации указан тег "direct"
|
||||
{
|
||||
"tag": "direct",
|
||||
"protocol": "freedom"
|
||||
},
|
||||
// 5.3 Блокировка трафика
|
||||
// Используется, если в настройках маршрутизации указан тег "block"
|
||||
{
|
||||
"tag": "block",
|
||||
"protocol": "blackhole"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## 8.4 Дополнительное задание 2: запуск `xray-core` на ПК
|
||||
|
||||
Итак, мы создали файл конфигурации. Как теперь запустить `xray-core`? Двойной клик по файлу не работает!
|
||||
|
||||
Во-первых, вам нужно открыть **командную строку**.
|
||||
|
||||
1. Пользователи Linux и macOS наверняка знают, как это сделать. Просто найдите приложение **«Терминал»**.
|
||||
2. В Windows используйте **«Командную строку»** или **PowerShell** (пользователи WSL, можете использовать привычный вам **«Терминал»**).
|
||||
|
||||
Во-вторых, нам нужно **указать `xray` путь к файлу конфигурации `config.json` и запустить его**.
|
||||
|
||||
1. В Windows, если файл `xray.exe` находится в папке `C:\Xray-windows-64\`, а файл `config.json` — в той же папке, то команда запуска будет выглядеть так:
|
||||
|
||||
```shell
|
||||
C:\Xray-windows-64\xray.exe -c C:\Xray-windows-64\config.json
|
||||
```
|
||||
|
||||
:::tip
|
||||
Параметр `-c` указывает путь к файлу конфигурации.
|
||||
:::
|
||||
|
||||
2. Аналогично, в Linux и macOS, если файл `xray` находится в папке `/usr/local/bin/`, а файл `config.json` — в папке `/usr/local/etc/xray/`, то команда запуска будет выглядеть так:
|
||||
|
||||
```shell
|
||||
/usr/local/bin/xray -c /usr/local/etc/xray/config.json
|
||||
```
|
||||
|
||||
:::tip
|
||||
В каждом системе есть переменные окружения, которые хранят пути к часто используемым папкам. Поэтому указывать полный путь к файлу `xray` не обязательно. Но я всё же указал его для надёжности.
|
||||
:::
|
||||
|
||||
## 8.5 Дополнительное задание 3: автозапуск `xray-core` на ПК
|
||||
|
||||
Если вы попробовали запускать `xray-core` вручную, то наверняка заметили следующие недостатки:
|
||||
|
||||
1. При каждом запуске `Xray` открывается чёрное окно консоли, что не очень красиво.
|
||||
2. `Xray` не запускается автоматически при загрузке системы, поэтому его приходится запускать вручную каждый раз.
|
||||
|
||||
Спешу вас обрадовать: **эти проблемы решаемы!** Но как именно их решить, я оставлю вам в качестве домашнего задания (подсказка: загляните в раздел FAQ на сайте документации).
|
||||
|
||||
## 8.6 Финишная прямая!
|
||||
|
||||
Уверен, что те, кто дочитал до этого места, — это любознательные и целеустремлённые люди, которые готовы учиться новому! Я от всей души поздравляю вас, ведь вы **самостоятельно, начиная с самых азов, настроили сервер VPS и клиент Xray!** Это огромная победа!
|
||||
|
||||
Надеюсь, теперь вы больше не боитесь `Linux` и разобрались с тем, как работает `Xray`.
|
||||
|
||||
**На этом наше повествование завершается!**
|
||||
|
||||
> ⬛⬛⬛⬛⬛⬛⬛⬛ 100%
|
||||
|
||||
## 8.7 В бесконечность и далее!
|
||||
|
||||
**Но это ещё не всё, что может Xray.**
|
||||
|
||||
`Xray` — это мощный и многофункциональный инструмент, который можно использовать для решения самых разных задач. В этом руководстве мы лишь поверхностно рассмотрели **самые простые** и **наглядные** варианты его настройки.
|
||||
|
||||
Если вам достаточно и этого, то наслаждайтесь свободой в интернете! Но если ваш пытливый ум жаждет новых знаний, то продолжайте изучать безграничные возможности `Xray`!
|
||||
|
||||
Дополнительную информацию можно найти здесь:
|
||||
|
||||
1. [xtls.github.io](https://xtls.github.io/) — официальная документация
|
||||
2. [Официальная группа в Telegram](https://t.me/projectXray) — активное и дружелюбное сообщество
|
||||
|
||||

|
||||
|
||||
:::tip Вместо послесловия
|
||||
|
||||
Надеюсь, это небольшое путешествие, в которое я вас отправил, поможет вам сделать интернет лучше.
|
||||
|
||||
Конечно, со временем информация из этого руководства устареет. Но вы будете расти и развиваться, и, возможно, когда-нибудь, вспоминая это руководство и те цели, которые я ставил перед собой, создавая его, вы передадите свои знания другим, чтобы эта эстафета помощи новичкам не прекращалась.
|
||||
|
||||
Мы живём в мире, где царят тьма и цензура. Люди бродят в одиночестве в поисках лучика света. И если мы не будем помогать друг другу и поддерживать друг друга на этом пути, то в конце концов нас ждёт лишь печальная картина запустения.
|
||||
:::
|
||||
@@ -0,0 +1,46 @@
|
||||
# [Глава 9] Приложение
|
||||
|
||||
## 1. Индекс основных команд Linux для начинающих
|
||||
|
||||
| Номер | Название команды | Описание команды | Глава |
|
||||
| :------: | :------------------ | :--------------------------- | :----------------------------------------: |
|
||||
| `cmd-01` | `apt update` | Обновление списка пакетов | [Глава о удаленном подключении](./ch03-ssh.md) |
|
||||
| `cmd-02` | `apt upgrade` | Обновление пакетов системы | [Глава о удаленном подключении](./ch03-ssh.md) |
|
||||
| `cmd-03` | `nano` | Текстовый редактор | [Глава о безопасности](./ch04-security.md) |
|
||||
| `cmd-04` | `systemctl restart` | Перезапуск сервиса | [Глава о безопасности](./ch04-security.md) |
|
||||
| `cmd-05` | `adduser` | Добавление пользователя | [Глава о безопасности](./ch04-security.md) |
|
||||
| `cmd-06` | `apt install` | Установка пакета | [Глава о безопасности](./ch04-security.md) |
|
||||
| `cmd-07` | `visudo` | Редактор для настройки sudo | [Глава о безопасности](./ch04-security.md) |
|
||||
| `cmd-08` | `sudo` | Выполнение команды от имени root | [Глава о безопасности](./ch04-security.md) |
|
||||
| `cmd-09` | `chmod` | Изменение прав доступа к файлу/папке | [Глава о безопасности](./ch04-security.md) |
|
||||
| `cmd-10` | `mkdir` | Создание папки | [Глава о создании сайта](./ch05-webpage.md) |
|
||||
| `cmd-11` | `systemctl reload` | Перезагрузка конфигурации сервиса | [Глава о создании сайта](./ch05-webpage.md) |
|
||||
| `cmd-12` | `wget` | Загрузка файла/страницы из сети | [Глава об управлении сертификатами](./ch06-certificates.md) |
|
||||
| `cmd-13` | `acme.sh` | Управление сертификатами с помощью acme.sh | [Глава об управлении сертификатами](./ch06-certificates.md) |
|
||||
| `cmd-14` | `rm` | Удаление файлов/папок | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
| `cmd-15` | `crontab -e` | Редактирование crontab текущего пользователя | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
| `cmd-16` | `touch` | Создание пустого файла | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
| `cmd-17` | `systemctl` | Базовые команды управления сервисами systemd | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
| `cmd-18` | `reboot` | Перезагрузка Linux | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
|
||||
## 2. Индекс важных конфигурационных файлов Linux
|
||||
|
||||
| Номер | Расположение файла | Описание файла | Глава |
|
||||
| :-------: | :-------------------------------------- | :----------------------------- | :----------------------------------------: |
|
||||
| `conf-01` | `/etc/ssh/sshd_config` | Конфигурация SSH сервера | [Глава о удаленном подключении](./ch03-ssh.md) |
|
||||
| `conf-02` | `/etc/nginx/nginx.conf` | Конфигурация Nginx | [Глава о создании сайта](./ch05-webpage.md) |
|
||||
| `conf-03` | `/etc/apt/sources.list` | Список репозиториев APT | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
| `conf-04` | `/etc/apt/sources.list.d/vpsadmin.list` | Список пользовательских репозиториев APT | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
| `conf-05` | `crontab -e` | Crontab текущего пользователя | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
| `conf-06` | `/etc/sysctl.conf` | Настройки ядра Linux | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
| `conf-07` | `/etc/sysctl.d/vpsadmin.conf` | Пользовательские настройки ядра Linux | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
|
||||
## 3. Индекс важных файлов Xray
|
||||
|
||||
| Номер | Расположение файла | Описание файла | Глава |
|
||||
| :-------: | :----------------------------------- | :------------ | :----------------------------------------: |
|
||||
| `xray-01` | `/usr/local/etc/xray/config.json` | Конфигурация Xray | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
| `xray-02` | `/home/vpsadmin/xray_cert/xray.cert` | TLS сертификат | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
| `xray-03` | `/home/vpsadmin/xray_cert/xray.key` | TLS ключ | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
| `xray-04` | `/home/vpsadmin/xray_log/access.log` | Лог доступа Xray | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
| `xray-05` | `/home/vpsadmin/xray_log/error.log` | Лог ошибок Xray | [Глава о Xray сервере](./ch07-xray-server.md) |
|
||||
@@ -0,0 +1,13 @@
|
||||
# Советы для начинающих
|
||||
|
||||
**В этой главе вы найдете советы по использованию Xray для начинающих, в основном с описанием принципов работы часто используемых модулей Xray.**
|
||||
|
||||
[Обзор функции Fallback](./fallbacks-lv1.md)
|
||||
|
||||
[Обзор функции маршрутизации (routing) (часть 1)](./routing-lv1-part1.md)
|
||||
|
||||
[Обзор функции маршрутизации (routing) (часть 2)](./routing-lv1-part2.md)
|
||||
|
||||
[Обзор режимов работы Xray](./work.md)
|
||||
|
||||
[Маскировка и разделение трафика по доменам с помощью функции SNI Fallback](./fallbacks-with-sni.md)
|
||||
@@ -0,0 +1,395 @@
|
||||
# Обзор функции Fallback
|
||||
|
||||
При использовании Xray вы наверняка много раз слышали о функции **"fallback"**. В этой статье мы кратко рассмотрим логику этой функции и способы ее применения.
|
||||
|
||||
## 1. Что такое Fallback в простых словах
|
||||
|
||||
Если вы использовали [конфигурацию Xray](../level-0/ch07-xray-server.md#_7-4-配置xray) из нашего руководства и настроили [автоматическое перенаправление HTTP на HTTPS](../level-0/ch07-xray-server.md#_7-8-服务器优化之二-开启http自动跳转https), то у вас уже есть простой fallback на основе протокола `VLESS`:
|
||||
|
||||
```json
|
||||
{
|
||||
"inbounds": [
|
||||
{
|
||||
"port": 443,
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"clients": [
|
||||
// ... ...
|
||||
],
|
||||
"decryption": "none",
|
||||
"fallbacks": [
|
||||
{
|
||||
"dest": 8080 // По умолчанию перенаправлять на прокси-сервер, защищенный от сканирования
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
// ... ...
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Как объяснить этот фрагмент конфигурации простыми словами?
|
||||
|
||||
1. **`Xray` прослушивает порт `[inbound port]` `443`**
|
||||
|
||||
Это означает, что `Xray` отвечает за прослушивание трафика `HTTPS` на порту `443`.
|
||||
|
||||
2. **`Xray` использует протокол `[inbound protocol]` `vless`**
|
||||
|
||||
Только трафик протокола `vless` будет обрабатываться `Xray` и перенаправляться на исходящие модули.
|
||||
|
||||
::: warning
|
||||
**Примечание:** Легковесный протокол `VLESS` был разработан с целью добавления функции fallback в `xray`, `v2fly` и другие ядра, а также для уменьшения избыточных проверок/шифрования. (Конечно, на данный момент протокол `trojan` в `xray` также полностью поддерживает функцию fallback.)
|
||||
:::
|
||||
|
||||
3. **Целевой порт fallback `[fallback dest]` - `8080`**
|
||||
|
||||
После того, как `Xray` получает входящий трафик на порт `443`, трафик протокола `vless` обрабатывается внутренне и перенаправляется на исходящий модуль. Другой трафик, не относящийся к протоколу `vless`, перенаправляется на порт `8080`.
|
||||
|
||||
::: warning
|
||||
**Вопрос:** Использовать единственное или множественное число?
|
||||
|
||||
Ответ: Внимательные читатели, должно быть, заметили, что в файле конфигурации используются множественные числа `inbounds`, `fallbacks`, но почему я использую единственное число: `inbound`, `fallback`?
|
||||
|
||||
Потому что множественное число в файле конфигурации означает, что `xray` поддерживает N элементов одного уровня (т.е. N входящих, M резервных и т.д.), а в приведенном выше примере анализа используется только один, поэтому я использовал единственное число.
|
||||
:::
|
||||
|
||||
4. **Трафик, перенаправляемый на порт `8080`, обрабатывается последующей программой**
|
||||
|
||||
В нашем примере порт `8080` обрабатывается `Nginx`, который находит и отображает страницу с маленькой пандой в соответствии с конфигурацией.
|
||||
|
||||
5. **В итоге, полный маршрут данных в нашем примере выглядит следующим образом:**
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
W(Внешний HTTP:80 запрос) --> N80(HTTP:80)
|
||||
|
||||
subgraph Nginx Внешнее прослушивание
|
||||
N80 -.- N301(301 перенаправление) -.- N443(HTTPS:443)
|
||||
end
|
||||
|
||||
N443 --> X(Xray прослушивает 443) .- X1{Проверка входящего трафика}
|
||||
X1 --> |Трафик VLESS| X2(Внутренние правила Xray)
|
||||
X2 --> O(Xray Outbounds Исходящий)
|
||||
X1 ==> |Fallback не VLESS трафика| N8080(Nginx:8080)
|
||||
N8080:::nginxclass ==> H(index.html)
|
||||
|
||||
H:::nginxclass
|
||||
classDef nginxclass fill:#FFFFDE
|
||||
|
||||
```
|
||||
|
||||
## 2. Что такое Fallback (ЧТО, КАК `v1`)
|
||||
|
||||
Основываясь на приведенном выше примере, вы должны понять, что такое fallback (Что) и как он работает (Как), проще говоря, вот эти несколько элементов:
|
||||
|
||||
1. Fallback происходит после того, как трафик поступает на **порт прослушивания `Xray`**.
|
||||
2. Fallback основывается на таких характеристиках трафика, как **тип протокола**.
|
||||
3. Целью fallback является определенный **порт**.
|
||||
4. Трафик, для которого выполнен fallback, обрабатывается программой, прослушивающей **порт fallback**.
|
||||
|
||||
## 3. Зачем нужен Fallback (ЗАЧЕМ `v1`)
|
||||
|
||||
Изначально он был предназначен для защиты от **активного зондирования** (Active Probing).
|
||||
|
||||
**Активное зондирование:** Проще говоря, это означает, что внешние злоумышленники отправляют определенные сетевые запросы и интерпретируют ответы сервера, чтобы определить, запущены ли на сервере такие прокси-инструменты, как `xray`, `v2fly`, `shadowsocks` и т.д. Если это удается точно определить, сервер может подвергнуться атаке или блокировке.
|
||||
|
||||
Интерпретировать ответы сервера можно потому, что полный запрос данных на самом деле состоит из множества этапов обмена данными, и на каждом этапе генерируются определенные характеристики программного обеспечения. Проще говоря:
|
||||
|
||||
- Ответ обычного сайта **обязательно будет** содержать характеристики таких инструментов веб-сервиса и базы данных, как `Nginx`, `Apache`, `MySQL` и т.д.
|
||||
- Ответ обычного сайта **не будет** содержать характеристики таких прокси-инструментов, как `xray`, `v2fly`, `shadowsocks` и т.д.
|
||||
|
||||
Таким образом, когда мы предоставляем `Xray` функцию **"fallback"** (как в приведенном выше примере, fallback на `Nginx`), любой запрос, используемый для зондирования, приводит к следующему:
|
||||
|
||||
- Зондирующий трафик не может получить доступ к вашим параметрам `VLESS` и поэтому будет перенаправлен на `Nginx`.
|
||||
- Весь зондирующий трафик перенаправляется на `Nginx`, поэтому ответ VPS-сервера **обязательно будет** содержать характеристики `Nginx`.
|
||||
- Поскольку сам `Xray` не отвечает на зондирующий трафик, ответ VPS **не будет** содержать характеристики `Xray`.
|
||||
|
||||
Таким образом, функция **"fallback"** решает проблему безопасности **активного зондирования** сервера с точки зрения логики взаимодействия данных.
|
||||
|
||||
## 4. Полное понимание Fallback (ЧТО, ЗАЧЕМ, КАК `v2`)
|
||||
|
||||
Почему нужно снова говорить о fallback? Потому что выше мы рассмотрели только первую версию fallback, основанную на "протоколе" и защите от **активного зондирования**.
|
||||
|
||||
В процессе постоянного развития и обновления протокола `VLESS` и функции `fallback` командой [RPRX](https://github.com/rprx) постепенно выяснилось, что fallback может быть более гибким и мощным. При условии обеспечения защиты от **активного зондирования** можно в полной мере использовать информацию, содержащуюся в первом пакете данных, для реализации многоэлементного и многоуровневого fallback (например, `path`, `alpn` и т.д.).
|
||||
|
||||
Основываясь на этой концепции разработки, функция **"fallback"** постепенно превратилась в то, чем она является сейчас, - в механизм, реализующий **полную маскировку --> ws-разделение --> многопротокольное и многопараметрическое разделение**. Финальная версия даже полностью заменила функцию разделения, которую раньше выполняли веб-серверы и другие инструменты. А поскольку описанная выше обработка **"fallback/разделения"** выполняется на этапе определения первого пакета за миллисекунды и не связана с какими-либо операциями с данными, она практически не приводит к потерям производительности.
|
||||
|
||||
**Таким образом, сейчас **полноценная функция "fallback" в `Xray`** обладает следующими свойствами:**
|
||||
|
||||
- **Безопасность:** полная защита от атак активного зондирования.
|
||||
- **Эффективность:** практически полное отсутствие потерь производительности.
|
||||
- **Гибкость:** гибкое разделение данных, повторное использование часто используемых портов (например, 443).
|
||||
|
||||
::: tip
|
||||
Хотя такой подробный подход может показаться несколько утомительным, только он позволяет в полной мере раскрыть уникальные преимущества **полноценного "fallback"**.
|
||||
:::
|
||||
|
||||
## 5. Пример и описание многоуровневого fallback
|
||||
|
||||
Теперь, когда мы понимаем, что такое **"полноценный fallback"**, мы можем приступить к настройке многоуровневого fallback.
|
||||
|
||||
### 5.1 Сначала скопируем фрагмент конфигурации прослушивания порта 443 на стороне сервера:
|
||||
|
||||
```json
|
||||
{
|
||||
"port": 443,
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "", // Укажите свой UUID
|
||||
"flow": "xtls-rprx-vision",
|
||||
"level": 0,
|
||||
"email": "love@example.com"
|
||||
}
|
||||
],
|
||||
"decryption": "none",
|
||||
"fallbacks": [
|
||||
{
|
||||
"dest": 1310, // По умолчанию перенаправлять на протокол Trojan Xray
|
||||
"xver": 1
|
||||
},
|
||||
{
|
||||
"path": "/websocket", // Обязательно укажите свой путь
|
||||
"dest": 1234,
|
||||
"xver": 1
|
||||
},
|
||||
{
|
||||
"path": "/vmesstcp", // Обязательно укажите свой путь
|
||||
"dest": 2345,
|
||||
"xver": 1
|
||||
},
|
||||
{
|
||||
"path": "/vmessws", // Обязательно укажите свой путь
|
||||
"dest": 3456,
|
||||
"xver": 1
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
"network": "tcp",
|
||||
"security": "tls",
|
||||
"tlsSettings": {
|
||||
"alpn": ["http/1.1"],
|
||||
"certificates": [
|
||||
{
|
||||
"certificateFile": "/path/to/fullchain.crt", // Укажите путь к вашему сертификату, абсолютный путь
|
||||
"keyFile": "/path/to/private.key" // Укажите путь к вашему закрытому ключу, абсолютный путь
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Как объяснить этот фрагмент конфигурации простыми словами?
|
||||
|
||||
1. **`Xray` прослушивает порт (`inbound port`) `443`**
|
||||
|
||||
Это означает, что `Xray` отвечает за прослушивание трафика `HTTPS` на порту `443` и использует сертификат `TLS`, указанный в `certificates`, для аутентификации.
|
||||
|
||||
2. **`Xray` использует протокол (`inbound protocol`) `vless`**
|
||||
|
||||
Трафик протокола `vless` напрямую передается в `Xray` для дальнейшей обработки.
|
||||
|
||||
3. **Трафик, не относящийся к протоколу `VLESS`, перенаправляется на 4 различных порта fallback:**
|
||||
|
||||
1. Трафик с `path`, равным `websocket`, перенаправляется на порт `1234` для дальнейшей обработки.
|
||||
2. Трафик с `path`, равным `vmesstcp`, перенаправляется на порт `2345` для дальнейшей обработки.
|
||||
3. Трафик с `path`, равным `vmessws`, перенаправляется на порт `3456` для дальнейшей обработки.
|
||||
4. Весь остальной трафик перенаправляется на порт `1310` для дальнейшей обработки.
|
||||
|
||||
4. **`xver`, равный `1`, означает, что функция `proxy protocol` включена, и реальный IP-адрес источника будет передан дальше.**
|
||||
|
||||
5. **Структура fallback показана на рисунке ниже:**
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
W443(Внешний HTTP:443 запрос) --> X443(Xray-inbound: 443) .- X1{Проверка входящего трафика}
|
||||
X1 --> |Протокол = VLESS| X2(Внутренние правила Xray)
|
||||
X2 --> O(Xray Outbounds Исходящий)
|
||||
|
||||
X1 --> |path = /websocket| X1234(Xray-inbound:1234)
|
||||
X1 --> |path = /vmesstcp| X2345(Xray-inbound:2345)
|
||||
X1 --> |path = /vmessws| X3456(Xray-inbound:3456)
|
||||
X1 --> |Весь остальной трафик| X1310(Xray-inbound:1310)
|
||||
|
||||
```
|
||||
|
||||
6. **Куда делся fallback на веб-страницу?**
|
||||
|
||||
Верно, внимательные читатели должны были заметить, что `fallback на nginx`, защищающий от **активного зондирования**, исчез!!! Почему? Не опасно ли это? Не волнуйтесь, давайте разбираться дальше:
|
||||
|
||||
### 5.2 Фрагмент конфигурации, отвечающий за обработку fallback:
|
||||
|
||||
1. Трафик, перенаправляемый на порт `1310`, обрабатывается в соответствии со следующей конфигурацией:
|
||||
|
||||
```json
|
||||
{
|
||||
"port": 1310,
|
||||
"listen": "127.0.0.1",
|
||||
"protocol": "trojan",
|
||||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"password": "", // Укажите свой пароль
|
||||
"level": 0,
|
||||
"email": "love@example.com"
|
||||
}
|
||||
],
|
||||
"fallbacks": [
|
||||
{
|
||||
"dest": 80 // Или перенаправлять на другой прокси-сервер, защищенный от сканирования
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
"network": "tcp",
|
||||
"security": "none",
|
||||
"tcpSettings": {
|
||||
"acceptProxyProtocol": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Смотрите, произошло чудо, в протоколе `trojan` появился новый `fallbacks`. Как уже говорилось ранее, протокол `trojan` в `xray` также обладает полной функциональностью fallback, поэтому на этом этапе протокол `trojan` может снова выполнять проверку и fallback (это и есть легендарный "fallback в fallback"):
|
||||
|
||||
- Весь трафик протокола `trojan` передается в `Xray` для дальнейшей обработки.
|
||||
- Весь остальной трафик перенаправляется на порт `80`. **Защита от активного зондирования** реализована!
|
||||
|
||||
2. Трафик, перенаправляемый на порт `1234`, на самом деле является `vless+ws`:
|
||||
|
||||
```json
|
||||
{
|
||||
"port": 1234,
|
||||
"listen": "127.0.0.1",
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "", // Укажите свой UUID
|
||||
"level": 0,
|
||||
"email": "love@example.com"
|
||||
}
|
||||
],
|
||||
"decryption": "none"
|
||||
},
|
||||
"streamSettings": {
|
||||
"network": "ws",
|
||||
"security": "none",
|
||||
"wsSettings": {
|
||||
"acceptProxyProtocol": true, // Напоминание: если вы используете Nginx/Caddy и т.д. для обратного проксирования WS, удалите эту строку
|
||||
"path": "/websocket" // Обязательно укажите свой путь, он должен совпадать с путем разделения
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
3. Трафик, перенаправляемый на порт `2345`, на самом деле является прямым подключением `vmess`:
|
||||
|
||||
```json
|
||||
{
|
||||
"port": 2345,
|
||||
"listen": "127.0.0.1",
|
||||
"protocol": "vmess",
|
||||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "", // Укажите свой UUID
|
||||
"level": 0,
|
||||
"email": "love@example.com"
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
"network": "tcp",
|
||||
"security": "none",
|
||||
"tcpSettings": {
|
||||
"acceptProxyProtocol": true,
|
||||
"header": {
|
||||
"type": "http",
|
||||
"request": {
|
||||
"path": [
|
||||
"/vmesstcp" // Обязательно укажите свой путь, он должен совпадать с путем разделения
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
4. Трафик, перенаправляемый на порт `3456`, на самом деле является `vmess+ws(+cdn)`.
|
||||
|
||||
::: warning
|
||||
Да, вы не ослышались, это одна из комбинаций, рекомендованных v2fly, и она полностью поддерживает `CDN`. Теперь она добавлена в наш идеальный набор fallback!
|
||||
:::
|
||||
|
||||
```json
|
||||
{
|
||||
"port": 3456,
|
||||
"listen": "127.0.0.1",
|
||||
"protocol": "vmess",
|
||||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "", // Укажите свой UUID
|
||||
"level": 0,
|
||||
"email": "love@example.com"
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
"network": "ws",
|
||||
"security": "none",
|
||||
"wsSettings": {
|
||||
"acceptProxyProtocol": true, // Напоминание: если вы используете Nginx/Caddy и т.д. для обратного проксирования WS, удалите эту строку
|
||||
"path": "/vmessws" // Обязательно укажите свой путь, он должен совпадать с путем разделения
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
5. Теперь мы можем нарисовать полную схему fallback:
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
W443(Внешний HTTP:443 запрос) --> X443(Xray-inbound: 443) .- X1{Проверка входящего трафика}
|
||||
X1 --> |Протокол = VLESS| X2(Внутренние правила Xray)
|
||||
X2 --> XO(Xray Outbounds Исходящий)
|
||||
|
||||
X1 --> |path = /websocket| X1234(Xray-inbound:1234)
|
||||
X1 --> |path = /vmesstcp| X2345(Xray-inbound:2345)
|
||||
X1 --> |path = /vmessws| X3456(Xray-inbound:3456)
|
||||
X1 --> |Весь остальной трафик| X1310(Xray-inbound:1310)
|
||||
|
||||
X1234 --> X2
|
||||
X2345 --> X2
|
||||
X3456 --> X2
|
||||
|
||||
X1310 --> |Протокол = trojan| X2
|
||||
X1310 --> |Весь остальной трафик| N80(Nginx:80)
|
||||
|
||||
N80:::nginxclass --> H(index.html)
|
||||
|
||||
H:::nginxclass
|
||||
classDef nginxclass fill:#FFFFDE
|
||||
```
|
||||
|
||||
## 6. Заключение
|
||||
|
||||
На этом обзор функции **"fallback"** в `Xray` завершен. Надеемся, что эта статья поможет вам лучше понять возможности `Xray`.
|
||||
|
||||
## 7. Дополнительное задание
|
||||
|
||||
Позвольте мне нагло оставить вам дополнительное задание: есть ли что-то, что можно оптимизировать в шаблоне [VLESS-TCP-XTLS-WHATEVER](https://github.com/XTLS/Xray-examples/blob/main/VLESS-TCP-XTLS-WHATEVER/), описанном в этой статье?
|
||||
|
||||
Подсказка: автоматическое перенаправление HTTP на HTTPS.
|
||||
|
After Width: | Height: | Size: 7.2 KiB |
|
After Width: | Height: | Size: 14 KiB |
|
After Width: | Height: | Size: 21 KiB |
@@ -0,0 +1,333 @@
|
||||
---
|
||||
title: SNI Fallback
|
||||
---
|
||||
|
||||
# Маскировка и разделение трафика по доменам с помощью функции SNI Fallback
|
||||
|
||||
VLESS - это очень легкий протокол, который, как и Trojan, не использует сложного шифрования и обфускации трафика. Вместо этого он, подобно тому, как искусный мастер кунг-фу скрывает свою силу, шифрует трафик с помощью протокола TLS, маскируя его под обычный HTTPS-трафик и позволяя ему беспрепятственно проходить через Великий китайский файрвол. Для лучшей маскировки от активного зондирования вместе с VLESS была представлена функция Fallbacks (резервирование). В этой статье мы рассмотрим, как использовать функцию Fallbacks входящего протокола VLESS в Xray совместно с Nginx или Caddy для реализации разделения трафика по доменам при обеспечении полной маскировки.
|
||||
|
||||
## Сценарии использования
|
||||
|
||||
Из-за XTLS Xray необходимо прослушивать порт 443, что создает проблему, если на сервере уже запущен веб-сайт - сайт либо не сможет работать, либо его придется запускать на другом порту, что нежелательно. Есть три способа решить эту проблему:
|
||||
|
||||
- Xray прослушивает другие часто используемые порты (например, 22, 3389, 8443).
|
||||
|
||||
Это самое простое решение, но оно не идеально.
|
||||
|
||||
- Nginx или HAProxy прослушивает порт 443 и выполняет обратное проксирование на уровне L4 с разделением трафика по SNI, что позволяет использовать один порт для нескольких сервисов.
|
||||
|
||||
Этот вариант более сложный и требует определенных знаний Nginx или HAProxy, поэтому мы не будем его здесь подробно рассматривать.
|
||||
|
||||
- Xray прослушивает порт 443 и использует функцию Fallbacks для перенаправления трафика веб-сайта на Nginx или Caddy на основе SNI.
|
||||
|
||||
Этот вариант имеет среднюю сложность и является тем, который мы рассмотрим в этом руководстве.
|
||||
|
||||
## Что такое SNI
|
||||
|
||||
**SNI** (Server Name Indication) - это расширение протокола TLS. Те, кто знаком с обратным проксированием, знают, что для правильной маршрутизации трафика по доменному имени необходимо следующее правило:
|
||||
|
||||
```nginx
|
||||
proxy_set_header Host имя_хоста;
|
||||
```
|
||||
|
||||
Эта строка устанавливает HTTP-заголовок "Host" на определенное имя хоста. Зачем это нужно? Обычно у одного сервера один IP-адрес, но на нем может быть запущено несколько сайтов. Пользователи получают IP-адрес по доменному имени и обращаются к серверу, но как сервер определяет, какой именно сайт запрашивает пользователь? Для этого используются виртуальные хосты, основанные на имени.
|
||||
|
||||
Когда веб-сервер получает запрос, он проверяет заголовок "Host" и направляет пользователя на нужный сайт. Однако, когда HTTP-трафик шифруется с помощью TLS, этот простой метод перестает работать. TLS-рукопожатие происходит до того, как сервер увидит какие-либо HTTP-заголовки, поэтому сервер не может использовать информацию из заголовка "Host", чтобы решить, какой сертификат предоставить, и тем более не может определить, к какому сайту обращается пользователь.
|
||||
|
||||
SNI решает эту проблему, позволяя клиенту отправлять имя хоста как часть TLS-рукопожатия. Поэтому при использовании Nginx для обратного проксирования HTTPS-трафика необходимо добавить в конфигурацию `proxy_ssl_server_name on;`. В этом случае Nginx будет отправлять информацию SNI на проксируемый сервер, решая проблему неработающих виртуальных хостов по HTTPS. Кроме того, при использовании SNI можно получить доступ к нужному сайту, даже не указывая заголовок "Host".
|
||||
|
||||
## Идея
|
||||
|
||||

|
||||
|
||||
После получения трафика на порт 443 Xray расшифровывает TLS и перенаправляет трафик с длиной первого пакета менее 18 байт, неверной версией протокола или ошибкой аутентификации на адрес, указанный в `dest`, на основе совпадения `name`, `path` или `alpn`.
|
||||
|
||||
## Добавление DNS-записей
|
||||
|
||||

|
||||
|
||||
Измените домен и IP-адрес в соответствии с вашей ситуацией.
|
||||
|
||||
## Запрос TLS-сертификата
|
||||
|
||||
Поскольку нам нужно разделять трафик по доменам с разными поддоменами, а wildcard-сертификат покрывает только домены между двумя точками (например, сертификат для `*.example.com` не будет действовать для `example.com` и `*.*.example.com`), нам нужно запросить wildcard-сертификат с [SAN](https://ru.wikipedia.org/wiki/Subject_Alternative_Name). Согласно информации на сайте Let's Encrypt[^1], для запроса wildcard-сертификата требуется проверка DNS-01. В этом руководстве мы рассмотрим, как запросить бесплатный TLS-сертификат Let's Encrypt с помощью [acme.sh](https://acme.sh) для домена, управляемого Cloudflare. Инструкции для других провайдеров DNS можно найти в [dnsapi · acmesh-official/acme.sh Wiki](https://github.com/acmesh-official/acme.sh/wiki/dnsapi).
|
||||
|
||||
Сначала нужно создать API-токен на [панели управления Cloudflare](https://dash.cloudflare.com/profile/api-tokens). Параметры следующие:
|
||||
|
||||

|
||||
|
||||
Настройка прав доступа очень важна, остальные параметры можно оставить по умолчанию.
|
||||
|
||||
После создания вы получите строку символов - это и есть ваш API-токен (`CF_Token`). Сохраните его в надежном месте, так как он больше не будет отображаться.
|
||||
|
||||
::: tip Внимание
|
||||
Следующие действия необходимо выполнять от имени пользователя root. Использование sudo может привести к ошибкам.
|
||||
:::
|
||||
|
||||
```bash
|
||||
curl https://get.acme.sh | sh # Установка acme.sh
|
||||
export CF_Token="sdfsdfsdfljlbjkljlkjsdfoiwje" # Установка переменной окружения с API-токеном
|
||||
acme.sh --issue -d example.com -d *.example.com --dns dns_cf # Запрос сертификата с проверкой DNS-01
|
||||
mkdir /etc/ssl/xray # Создание каталога для хранения сертификата
|
||||
acme.sh --install-cert -d example.com --fullchain-file /etc/ssl/xray/cert.pem --key-file /etc/ssl/xray/privkey.key --reloadcmd "chown nobody:nogroup -R /etc/ssl/xray && systemctl restart xray" # Установка сертификата в указанный каталог и настройка команды для автоматического перезапуска Xray после обновления сертификата
|
||||
```
|
||||
|
||||
## Конфигурация Xray
|
||||
|
||||
```json
|
||||
{
|
||||
"log": {
|
||||
"loglevel": "warning"
|
||||
},
|
||||
"inbounds": [
|
||||
{
|
||||
"port": 443,
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "UUID",
|
||||
"flow": "xtls-rprx-vision"
|
||||
}
|
||||
],
|
||||
"decryption": "none",
|
||||
"fallbacks": [
|
||||
{
|
||||
"name": "example.com",
|
||||
"path": "/vmessws",
|
||||
"dest": 5000,
|
||||
"xver": 1
|
||||
},
|
||||
{
|
||||
"dest": 5001,
|
||||
"xver": 1
|
||||
},
|
||||
{
|
||||
"alpn": "h2",
|
||||
"dest": 5002,
|
||||
"xver": 1
|
||||
},
|
||||
{
|
||||
"name": "blog.example.com",
|
||||
"dest": 5003,
|
||||
"xver": 1
|
||||
},
|
||||
{
|
||||
"name": "blog.example.com",
|
||||
"alpn": "h2",
|
||||
"dest": 5004,
|
||||
"xver": 1
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
"network": "tcp",
|
||||
"security": "tls",
|
||||
"tlsSettings": {
|
||||
"alpn": ["h2", "http/1.1"],
|
||||
"certificates": [
|
||||
{
|
||||
"certificateFile": "/etc/ssl/xray/cert.pem",
|
||||
"keyFile": "/etc/ssl/xray/privkey.key"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"listen": "127.0.0.1",
|
||||
"port": 5000,
|
||||
"protocol": "vmess",
|
||||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "UUID"
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
"network": "ws",
|
||||
"wsSettings": {
|
||||
"acceptProxyProtocol": true,
|
||||
"path": "/vmessws"
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Эта конфигурация предназначена для Nginx. Обратите внимание на следующие детали:
|
||||
|
||||
- О Proxy Protocol
|
||||
|
||||
Proxy Protocol - это протокол, разработанный HaProxy для решения проблемы потери информации о клиенте при проксировании, часто используемый в цепочках прокси-серверов и обратных прокси. Традиционные методы решения этой проблемы, как правило, сложны и имеют много ограничений, в то время как Proxy Protocol очень прост - он просто добавляет пакет данных с информацией об исходном соединении (четверка "источник-назначение:порт") при передаче данных.
|
||||
|
||||
У всего есть свои плюсы и минусы, и Proxy Protocol не исключение.
|
||||
|
||||
- Если есть отправка, должен быть и прием, и наоборот.
|
||||
- Один и тот же порт не может одновременно поддерживать соединения с данными Proxy Protocol и без них (например, разные виртуальные хосты (server) Nginx на одном порту, что по сути является следствием предыдущего пункта)[^2][^3].
|
||||
|
||||
Если вы столкнулись с ошибками, убедитесь, что ваша конфигурация соответствует этим условиям.
|
||||
|
||||
Здесь мы используем Proxy Protocol, чтобы целевой сервер, на который перенаправляется трафик, получал реальный IP-адрес клиента.
|
||||
|
||||
Кроме того, если в конфигурации входящего трафика Xray есть `"acceptProxyProtocol": true`, ReadV будет отключен.
|
||||
|
||||
- О HTTP/2
|
||||
|
||||
Во-первых, порядок элементов в `inbounds.streamSettings.tlsSettings.alpn` важен: `h2` должен быть перед `http/1.1`, чтобы обеспечить совместимость при использовании HTTP/2. Обратный порядок приведет к тому, что HTTP/2 будет понижен до HTTP/1.1 во время согласования, делая конфигурацию недействительной.
|
||||
|
||||
В приведенной выше конфигурации каждая запись fallback для Nginx разделена на две. Это связано с тем, что h2 - это обязательное зашифрованное соединение HTTP/2, что хорошо для безопасности передачи данных в Интернете, но не нужно внутри сервера. h2c же - это незашифрованное соединение HTTP/2, подходящее для этой среды. Однако Nginx не может одновременно прослушивать HTTP/1.1 и h2c на одном порту. Чтобы решить эту проблему, необходимо указать `alpn` (в разделе `fallbacks`, а не `tlsSettings`), чтобы сопоставить результаты согласования TLS ALPN.
|
||||
|
||||
Рекомендуется указывать `alpn` только в двух случаях[^4]:
|
||||
|
||||
- опустить
|
||||
- `"h2"`
|
||||
|
||||
Если вы используете Caddy, то вам не нужно так усложнять, поскольку он **может** одновременно прослушивать HTTP/1.1 и h2c на одном порту. Изменения в конфигурации следующие:
|
||||
|
||||
```json
|
||||
{
|
||||
"fallbacks": [
|
||||
{
|
||||
"name": "example.com",
|
||||
"path": "/vmessws",
|
||||
"dest": 5000,
|
||||
"xver": 1
|
||||
},
|
||||
{
|
||||
"dest": 5001,
|
||||
"xver": 1
|
||||
},
|
||||
{
|
||||
"name": "blog.example.com",
|
||||
"dest": 5002,
|
||||
"xver": 1
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Конфигурация Nginx
|
||||
|
||||
Nginx будет установлен из официального репозитория.
|
||||
|
||||
```bash
|
||||
sudo apt install curl gnupg2 ca-certificates lsb-release
|
||||
echo "deb [arch=amd64] http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" \
|
||||
| sudo tee /etc/apt/sources.list.d/nginx.list
|
||||
curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add -
|
||||
sudo apt update
|
||||
sudo apt install nginx
|
||||
```
|
||||
|
||||
Удалите `/etc/nginx/conf.d/default.conf` и создайте `/etc/nginx/conf.d/fallbacks.conf` со следующим содержимым:
|
||||
|
||||
```nginx
|
||||
set_real_ip_from 127.0.0.1;
|
||||
real_ip_header proxy_protocol;
|
||||
|
||||
server {
|
||||
listen 127.0.0.1:5001 proxy_protocol default_server;
|
||||
listen 127.0.0.1:5002 proxy_protocol default_server http2;
|
||||
|
||||
location / {
|
||||
root /srv/http/default;
|
||||
}
|
||||
}
|
||||
|
||||
server {
|
||||
listen 127.0.0.1:5003 proxy_protocol;
|
||||
listen 127.0.0.1:5004 proxy_protocol http2;
|
||||
|
||||
server_name blog.example.com;
|
||||
|
||||
location / {
|
||||
root /srv/http/blog.example.com;
|
||||
}
|
||||
}
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
return 301 https://$host$request_uri;
|
||||
}
|
||||
```
|
||||
|
||||
## Конфигурация Caddy
|
||||
|
||||
Инструкции по установке Caddy можно найти в [Install — Caddy Documentation](https://caddyserver.com/docs/install).
|
||||
|
||||
Чтобы Caddy мог получать реальный IP-адрес посетителя, необходимо скомпилировать Caddy с модулем Proxy Protocol. Рекомендуется скомпилировать его прямо на сайте Caddy.
|
||||
|
||||
```bash
|
||||
sudo curl -o /usr/bin/caddy "https://caddyserver.com/api/download?os=linux&arch=amd64&p=github.com%2Fmastercactapus%2Fcaddy2-proxyprotocol&idempotency=79074247675458"
|
||||
sudo chmod +x /usr/bin/caddy
|
||||
```
|
||||
|
||||
Просто замените существующий бинарный файл.
|
||||
|
||||
::: tip
|
||||
Рекомендуется сначала установить Caddy, следуя инструкциям на официальном сайте, а затем заменить бинарный файл. Это избавит от необходимости настраивать запуск сервиса вручную.
|
||||
:::
|
||||
|
||||
Отредактируйте `/etc/caddy/Caddyfile`:
|
||||
|
||||
```Caddyfile
|
||||
{
|
||||
servers 127.0.0.1:5001 {
|
||||
listener_wrappers {
|
||||
proxy_protocol
|
||||
}
|
||||
protocol {
|
||||
allow_h2c
|
||||
}
|
||||
}
|
||||
servers 127.0.0.1:5002 {
|
||||
listener_wrappers {
|
||||
proxy_protocol
|
||||
}
|
||||
protocol {
|
||||
allow_h2c
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
:5001 {
|
||||
root * /srv/http/default
|
||||
file_server
|
||||
log
|
||||
bind 127.0.0.1
|
||||
}
|
||||
|
||||
http://blog.example.com:5002 {
|
||||
root * /srv/http/blog.example.com
|
||||
file_server
|
||||
log
|
||||
bind 127.0.0.1
|
||||
}
|
||||
|
||||
:80 {
|
||||
redir https://{host}{uri} permanent
|
||||
}
|
||||
```
|
||||
|
||||
## Ссылки
|
||||
|
||||
1. [Указание имени сервера - Википедия](https://ru.wikipedia.org/wiki/Указание_имени_сервера)
|
||||
2. [Home · acmesh-official/acme.sh Wiki](https://github.com/acmesh-official/acme.sh/wiki)
|
||||
3. [HTTP/2 - Википедия](https://ru.wikipedia.org/wiki/HTTP/2)
|
||||
|
||||
## Примечания
|
||||
|
||||
[^1]: [Часто задаваемые вопросы - Let's Encrypt - бесплатные SSL/TLS сертификаты](https://letsencrypt.org/ru/docs/faq/)
|
||||
[^2]: [Proxy Protocol - HAProxy Technologies](https://www.haproxy.com/blog/haproxy/proxy-protocol/)
|
||||
[^3]: [proxy protocol 介绍及 nginx 配置 - 简书](https://www.jianshu.com/p/cc8d592582c9)
|
||||
[^4]: [v2fly-github-io/vless.md at master · rprx/v2fly-github-io](https://github.com/rprx/v2fly-github-io/blob/master/docs/config/protocols/vless.md)
|
||||
|
||||
|
||||
|
After Width: | Height: | Size: 1.3 MiB |
@@ -0,0 +1,422 @@
|
||||
# Краткий обзор функции маршрутизации (routing) (часть 1)
|
||||
|
||||
Если "мощность" Xray в основном заключается в его высокой скорости и широкой совместимости, то его "гибкость" в первую очередь связана с продуманной функцией **"routing" (маршрутизация)**. В этой статье мы кратко рассмотрим логику этой функции и способы ее применения.
|
||||
|
||||
## 1. Знакомство с тремя братьями-маршрутизаторами
|
||||
|
||||
Чтобы понять маршрутизацию, нужно понимать, что для ее полноценной работы нужны три компонента: 1. **входящий трафик** (inbound); 2. **маршрутизация** (routing); 3. **исходящий трафик** (outbound).
|
||||
|
||||

|
||||
|
||||
Три брата, поклявшиеся в верности, не обязательно родились в один день, но должны быть готовы умереть в один день.
|
||||
|
||||
Поэтому запомните: если один из элементов работает неправильно, функция маршрутизации может не работать.
|
||||
|
||||
Поскольку маршрутизация очень гибкая, чтение только технической документации может вас запутать, поэтому в этой статье мы будем использовать конкретные примеры, чтобы объяснить все пошагово.
|
||||
|
||||
::: warning
|
||||
Функция маршрутизации настолько гибкая, что примеры в этой статье приведены только для объяснения соответствующих концепций. На практике, пожалуйста, корректируйте их в соответствии с вашими потребностями.
|
||||
:::
|
||||
|
||||
## 2. Основы: "Братья едины"
|
||||
|
||||
На рисунке ниже показан пример, когда входящий трафик от приложения поступает на `Xray` на клиенте, маршрутизируется на исходящий трафик и отправляется на VPS.
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
S(Данные приложения) .-> I[Входящий трафик]
|
||||
|
||||
subgraph Xray
|
||||
I --> R[Маршрутизация] --> O[Исходящий трафик]
|
||||
end
|
||||
|
||||
O .-> V(VPS)
|
||||
|
||||
V:::greyclass
|
||||
S:::greyclass
|
||||
R:::routingclass
|
||||
classDef greyclass fill:#C0C0C0
|
||||
classDef routingclass fill:#FFFFDE
|
||||
|
||||
```
|
||||
|
||||
Давайте проанализируем каждый шаг:
|
||||
|
||||
### 2.1 Входящий трафик
|
||||
|
||||
::: tip
|
||||
**Входящий трафик (inbound):** это то, как трафик попадает в `Xray`.
|
||||
:::
|
||||
|
||||
Пример конфигурации входящего трафика ниже означает, что данные поступают в `Xray` по протоколу `socks` через порт `10808` с локального адреса `127.0.0.1`. `Xray` присваивает этому входящему трафику имя `inbound-10808` с помощью `[tag]`.
|
||||
|
||||
```json
|
||||
{
|
||||
"inbounds": [
|
||||
{
|
||||
"tag": "inbound-10808",
|
||||
"protocol": "socks",
|
||||
"listen": "127.0.0.1",
|
||||
"port": 10808,
|
||||
"settings": {
|
||||
"udp": true
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 2.2 Исходящий трафик
|
||||
|
||||
::: tip
|
||||
**Исходящий трафик (outbound):** это то, как трафик выходит из `Xray`.
|
||||
:::
|
||||
|
||||
Пример конфигурации исходящего трафика ниже означает, что данные отправляются на соответствующий VPS по протоколу `VLESS` с использованием `tcp + xtls` и других параметров. `Xray` присваивает этому исходящему трафику имя `proxy-out-vless` с помощью `[tag]`.
|
||||
|
||||
```json
|
||||
{
|
||||
"outbounds": [
|
||||
{
|
||||
"tag": "proxy-out-vless",
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"vnext": [
|
||||
{
|
||||
"address": "a-name.yourdomain.com",
|
||||
"port": 443,
|
||||
"users": [
|
||||
{
|
||||
"id": "uuiduuid-uuid-uuid-uuid-uuiduuiduuid",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"encryption": "none",
|
||||
"level": 0
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
"network": "tcp",
|
||||
"security": "tls",
|
||||
"tlsSettings": {
|
||||
"serverName": "a-name.yourdomain.com",
|
||||
"allowInsecure": false,
|
||||
"fingerprint": "chrome"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 2.3 Маршрутизация
|
||||
|
||||
::: tip
|
||||
**Маршрутизация (routing):** это соединение канала между **входящим** и **исходящим** трафиком с помощью определенного **условия**.
|
||||
:::
|
||||
|
||||
Пример конфигурации маршрутизации ниже означает, что весь трафик, поступающий в `Xray` через входящий трафик с `[tag]="inbound-10808"`, **на 100%** перенаправляется на исходящий трафик с `[tag]="proxy-out-vless"` без разделения или каких-либо других действий.
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
{
|
||||
"type": "field",
|
||||
"inboundTag": ["inbound-10808"],
|
||||
"outboundTag": "proxy-out-vless"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Таким образом, мы реализовали очень простое правило, описанное в начале: **входящий трафик от приложения поступает на `Xray` на клиенте, маршрутизируется на исходящий трафик и отправляется на VPS**.
|
||||
|
||||
### 2.4 Анализ параметров конфигурации маршрутизации: критерии фильтрации трафика
|
||||
|
||||
Обратите внимание на конфигурацию маршрутизации. Мы видим несколько новых терминов:
|
||||
|
||||
1. `"domainStrategy": "AsIs"`
|
||||
2. `“rules”`
|
||||
3. `"type": "field"`
|
||||
4. `"inboundTag": ["inbound-10808"]`
|
||||
5. `"outboundTag": "proxy-out-vless"`
|
||||
|
||||
Пока оставим `domainStrategy` в стороне и кратко объясним остальные:
|
||||
|
||||
| Название параметра | Значение параметра | Описание параметра |
|
||||
| :---------------- | :----------------- | :------------------ |
|
||||
| `“rules”` | | Внутри этого параметра находятся подробные настройки **правил маршрутизации**. |
|
||||
| `"type"` | `"field"` | На данный момент этот параметр не имеет особого значения, но его нельзя опускать, поэтому просто укажите его. |
|
||||
| `"inboundTag"` | `["inbound-10808"]` | **Критерий** фильтрации трафика - это **тег входящего трафика**, а **условие** сейчас только одно: **источник входящего трафика - `inbound-10808`**. |
|
||||
| `"outboundTag"` | `"proxy-out-vless"` | Если указанное выше условие фильтрации выполняется (т.е. входящий трафик имеет `[tag]="inbound-10808"`), `Xray` направит трафик на исходящий трафик с `[tag]="proxy-out-vless"`. |
|
||||
|
||||
В этом примере у нас есть только один входящий трафик с `"inboundTag" = "inbound-10808"` и один исходящий трафик с `[tag]="proxy-out-vless"`. Поэтому, согласно приведенному выше правилу маршрутизации, весь трафик, поступающий в `Xray` через порт `10808`, **на 100%** соответствует условиям фильтрации, выбирается модулем маршрутизации и перенаправляется на единственный исходящий трафик.
|
||||
|
||||
Таким образом, **входящий трафик**, **маршрутизация** и **исходящий трафик** уже могут работать вместе. Конечно, в данном случае 100% перенаправление не имеет особого смысла. Давайте посмотрим, какие преимущества может дать такой механизм разделения труда.
|
||||
|
||||
## 3. Первые шаги: "Разделение мира на три части" - "Разделение по домену"
|
||||
|
||||
> `[geosite.dat]`
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
S(Данные приложения) .-> I[Входящий трафик]
|
||||
|
||||
subgraph Xray
|
||||
I --> R[Маршрутизация] -- "geosite:category-ads-all" --> O1[block]
|
||||
R[Маршрутизация] -- "geosite:cn" --> O2[direct]
|
||||
R[Маршрутизация] -- "geosite:geolocation-!cn" --> O3[proxy]
|
||||
|
||||
end
|
||||
|
||||
O2 .-> D(Внутренний сервер)
|
||||
O3 .-> V(VPS)
|
||||
|
||||
O1:::redclass
|
||||
V:::greyclass
|
||||
S:::greyclass
|
||||
R:::routingclass
|
||||
|
||||
classDef redclass fill:#FF0000
|
||||
classDef greyclass fill:#C0C0C0
|
||||
classDef routingclass fill:#FFFFDE,stroke:#000000
|
||||
|
||||
```
|
||||
|
||||
Эта конфигурация реализует самый простой и распространенный (используемый в нашем руководстве) набор правил маршрутизации:
|
||||
|
||||
1. Блокировка рекламы (`[block]`)
|
||||
2. Прямое подключение к внутренним ресурсам (`[direct]`)
|
||||
3. Перенаправление трафика на VPS (`[proxy]`)
|
||||
|
||||
::: warning Внимание
|
||||
В нашем руководстве прямое подключение настроено для **внутренних доменов**, **внутренних IP-адресов** и **локальных IP-адресов**. Здесь мы рассмотрим только **внутренние домены**.
|
||||
:::
|
||||
|
||||
### 3.1 Входящий трафик
|
||||
|
||||
Оставляем `inbound-10808` из предыдущего примера без изменений.
|
||||
|
||||
### 3.2 Исходящий трафик
|
||||
|
||||
В предыдущем примере у нас уже есть исходящий трафик `[proxy]` - `"proxy-out-vless"`, поэтому он остается без изменений. Очевидно, что нам нужно добавить два новых типа исходящего трафика: `[block]` и `[direct]`, как показано ниже:
|
||||
|
||||
```json
|
||||
{
|
||||
"outbounds": [
|
||||
{
|
||||
"tag": "proxy-out-vless"
|
||||
// ... ...
|
||||
},
|
||||
{
|
||||
"tag": "block",
|
||||
"protocol": "blackhole"
|
||||
},
|
||||
{
|
||||
"tag": "direct-out",
|
||||
"protocol": "freedom"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Приведенная выше конфигурация означает:
|
||||
|
||||
1. Конфигурация исходящего трафика `[proxy-out-vless]` из предыдущего примера остается без изменений.
|
||||
2. Добавлен протокол **`blackhole` (черная дыра)**. Трафик, отправляемый через этот протокол, попадает в "черную дыру" внутри `Xray` и не может выйти наружу, что фактически блокирует его (`[block]`).
|
||||
3. Добавлен протокол **`freedom` (свобода)**. Трафик, отправляемый через этот протокол, свободно покидает `Xray` и следует к своему первоначальному адресу, как будто его и не было, что фактически означает прямое подключение (`[direct]`). (Здесь я назвал его `[direct-out]`, чтобы подчеркнуть, что это исходящий трафик).
|
||||
|
||||
### 3.3 Маршрутизация
|
||||
|
||||
Настало время для чуда! Мы можем связать все это вместе с помощью конфигурации **маршрутизации**!
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["geosite:category-ads-all"],
|
||||
"outboundTag": "block"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["geosite:cn"],
|
||||
"outboundTag": "direct-out"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["geosite:geolocation-!cn"],
|
||||
"outboundTag": "proxy-out-vless"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Чтобы понять этот файл конфигурации, нам нужно кратко объяснить несколько новых параметров:
|
||||
|
||||
- `"domain": ["geosite:category-ads-all"]`
|
||||
- `"domain": ["geosite:cn"]`
|
||||
- `"domain": ["geosite:geolocation-!cn"]`
|
||||
|
||||
### 3.4 Краткий обзор файла доменов: `geosite.dat`
|
||||
|
||||
На самом деле, вы, вероятно, уже догадались по названиям этих параметров:
|
||||
|
||||
- `"domain"`: **критерий** фильтрации трафика в этот раз - это **доменное имя** (а не тег входящего трафика).
|
||||
- `"geosite"`: `Xray` будет искать **соответствующие доменные имена** в файле `geosite.dat`.
|
||||
- `"category-ads-all"`: **все рекламные домены**, указанные в этом файле.
|
||||
- `"cn"`: **китайские домены**, указанные в этом файле.
|
||||
- `"geolocation-!cn"`: **не китайские домены**, указанные в этом файле.
|
||||
|
||||
С учетом этих пояснений конфигурацию из пункта 3.3 можно перевести так:
|
||||
|
||||
1. Трафик от приложений, пытающихся получить доступ к иностранным доменам (`"domain": "geolocation-!cn"`), перенаправляется на VPS через исходящий трафик `[proxy-out-vless]`.
|
||||
2. Трафик от приложений, пытающихся получить доступ к иностранным рекламным доменам (`"domain": "geosite:category-ads-all"`), блокируется (`[block]`) путем перенаправления в "черную дыру".
|
||||
3. Трафик от приложений, пытающихся получить доступ к китайским доменам (`"domain": "geosite:cn"`), отправляется напрямую (`[direct-out]`).
|
||||
|
||||
Вот так проявляются преимущества **функции маршрутизации**.
|
||||
|
||||
### 3.5 Так что же такое `geosite.dat`? Разве у нас нет `GFWList`?
|
||||
|
||||
Представьте, что в мире миллионы доменов. Если бы нам приходилось вручную собирать и вводить каждый домен для каждого правила маршрутизации, основанного на доменном имени, это было бы крайне неэффективно!
|
||||
|
||||
А если бы все домены относились только к одному типу и могли быть обработаны только одним из трех способов: `[direct], [proxy], [block]`, это было бы очень неудобно!
|
||||
|
||||
Как Гуань Юю нужен его Цинлун Яньюэдао, так и **функции маршрутизации** нужен свой волшебный меч - файл `geosite.dat`, который представляет собой готовый к использованию **список категорий доменов**. Он позволяет пользователям легко вызывать любую подкатегорию с помощью формата `geosite:xxx` и настраивать правила маршрутизации в соответствии со своими потребностями.
|
||||
|
||||
Такая модульная структура обеспечивает гораздо большую гибкость, чем традиционный список заблокированных доменов [`GFWList`](https://github.com/gfwlist/gfwlist). Например, вы можете указать, что домены Apple (`geosite:apple`) и домены, связанные с iCloud (`geosite:icloud`), должны проксироваться (`[proxy]`), а домены обновлений Apple (`geosite:apple-update`) должны подключаться напрямую (`[direct]`) для максимальной скорости загрузки.
|
||||
|
||||
::: warning
|
||||
**Внимание:** на данный момент существует несколько вариантов файла `geosite.dat`:
|
||||
|
||||
- Изначально, когда `Victoria Raymond` активно занималась проектом `Project V`, она предоставляла соответствующий проект [`domain-list-community`](https://github.com/v2ray/domain-list-community), который использовался для сбора, хранения и классификации часто используемых типов доменов.
|
||||
- После того, как Виктория внезапно исчезла, и разработка `Project V` приостановилась, сообщество `v2fly` продолжило поддерживать и обновлять свою версию [`domain-list-community`](https://github.com/v2fly/domain-list-community).
|
||||
- В то же время [@Loyalsoldier](Loyalsoldier) ведет свой собственный, модифицированный и расширенный файл правил маршрутизации [v2ray-rules-dat](https://github.com/Loyalsoldier/v2ray-rules-dat), который предлагает множество различных вариантов и логики классификации.
|
||||
- Кроме того, команда `Project X` планирует в будущем создать и поддерживать файл правил маршрутизации [Xray-rules-dat](https://github.com/XTLS/Xray-rules-dat), который будет лучше подходить для использования с `Xray`. ~~(Как видите, папка уже создана, так что это дело времени)~~
|
||||
|
||||
Вы даже можете создать свой собственный файл `geosite` и подключить его к `Xray`, но это выходит за рамки данной статьи, поэтому мы не будем на этом останавливаться.
|
||||
|
||||
Если вы обнаружите, что некоторые домены не классифицированы должным образом, пожалуйста, создайте issue или отправьте pull request в один из перечисленных выше проектов! Поддерживайте сообщество - каждый за всех, и все за одного!
|
||||
|
||||
:::
|
||||
|
||||
### 3.6 Секретное оружие: скрытое правило маршрутизации
|
||||
|
||||
На самом деле, если вы внимательно посмотрите на приведенные выше правила, то заметите одну проблему: все наши правила определяют только то, **куда** следует перенаправлять входящий трафик, **если он соответствует определенному условию**. Но что произойдет, если файл `geosite.dat` неполный, и наш входящий трафик **не соответствует ни одному условию**? Как поступит `Xray`?
|
||||
|
||||
::: warning Внимание
|
||||
Если вы думаете, что **если условие не выполняется, то соединение не будет установлено**, то вам нужно подумать еще раз. Соединение будет разорвано только в том случае, если указано правило `[block]`, которое перенаправляет трафик в "черную дыру" (`blackhole`).
|
||||
:::
|
||||
|
||||
На самом деле, чтобы избежать путаницы из-за неполных правил маршрутизации, `Xray` предоставляет скрытое правило: **если входящий трафик не соответствует ни одному условию, он перенаправляется на первый исходящий трафик**.
|
||||
|
||||
Таким образом, ни один трафик не будет потерян. Поэтому важно поместить ваш самый надежный исходящий трафик на **первое место**, чтобы он служил вам верным стражем.
|
||||
|
||||
### 3.7 Снова смотрим на карту "трех царств"
|
||||
|
||||
Поскольку в предыдущем примере мы поместили `[proxy-out-vless]` на первое место в списке исходящего трафика, при срабатывании скрытого правила трафик будет перенаправляться на удаленный VPS по протоколу `VLESS`. Таким образом, полная логика работы `Xray` выглядит следующим образом:
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
S(Данные приложения) .-> I[Входящий трафик]
|
||||
|
||||
subgraph Xray
|
||||
I --> R[Маршрутизация] -- "geosite:category-ads-all" --> O1[block]
|
||||
R[Маршрутизация] -- "geosite:cn" --> O2[direct]
|
||||
R[Маршрутизация] -- "geosite:geolocation-!cn" --> O3[proxy]
|
||||
R[Маршрутизация] -. "Трафик, не соответствующий ни одному правилу" .-> O4[Первый исходящий трафик]
|
||||
|
||||
end
|
||||
|
||||
O2 .-> D(Внутренний сервер)
|
||||
O3 .-> V(VPS)
|
||||
O4 .-> V(VPS)
|
||||
|
||||
O1:::redclass
|
||||
V:::greyclass
|
||||
S:::greyclass
|
||||
R:::routingclass
|
||||
|
||||
classDef redclass fill:#FF0000
|
||||
classDef greyclass fill:#C0C0C0
|
||||
classDef routingclass fill:#FFFFDE,stroke:#000000
|
||||
|
||||
```
|
||||
|
||||
Фактически, это и есть то, что традиционно называется **"проксирование по умолчанию, прямой доступ к внутренним сайтам по белому списку"**.
|
||||
|
||||
## 4. "Разделение мира на три части" - "Битва Вэй и Шу"
|
||||
|
||||
Теперь, когда вы знаете о скрытом правиле маршрутизации по умолчанию (**"если входящий трафик не соответствует ни одному условию, он перенаправляется на первый исходящий трафик"**), вы должны понимать, что то, будет ли **проксирование** или **прямое подключение** основным режимом работы, зависит от того, какой исходящий трафик стоит на первом месте!
|
||||
|
||||
На предыдущем шаге мы настроили правило **"проксирование по умолчанию, прямой доступ к внутренним сайтам по белому списку"**. Теперь, чтобы получить правило **"прямое подключение по умолчанию, проксирование иностранных сайтов по белому списку"**, нам просто нужно **поместить правило прямого подключения на первое место**.
|
||||
|
||||
Это очень просто, не правда ли?
|
||||
|
||||
```json
|
||||
{
|
||||
"outbounds": [
|
||||
{
|
||||
"tag": "direct-out",
|
||||
"protocol": "freedom"
|
||||
},
|
||||
{
|
||||
"tag": "proxy-out-vless"
|
||||
// ... ...
|
||||
},
|
||||
{
|
||||
"tag": "block",
|
||||
"protocol": "blackhole"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Теперь правила маршрутизации выглядят так:
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
S(Данные приложения) .-> I[Входящий трафик]
|
||||
|
||||
subgraph Xray
|
||||
I --> R[Маршрутизация] -- "geosite:category-ads-all" --> O1[block]
|
||||
R[Маршрутизация] -- "geosite:geolocation-!cn" --> O3[proxy]
|
||||
R[Маршрутизация] -- "geosite:cn" --> O2[direct]
|
||||
R[Маршрутизация] -. "Трафик, не соответствующий ни одному правилу" .-> O4[Первый исходящий трафик]
|
||||
|
||||
end
|
||||
|
||||
O2 .-> D(Внутренний сервер)
|
||||
O3 .-> V(VPS)
|
||||
O4 .-> D
|
||||
|
||||
O1:::redclass
|
||||
V:::greyclass
|
||||
S:::greyclass
|
||||
R:::routingclass
|
||||
classDef redclass fill:#FF0000
|
||||
classDef greyclass fill:#C0C0C0
|
||||
classDef routingclass fill:#FFFFDE,stroke:#000000
|
||||
|
||||
```
|
||||
|
||||
В этом и заключается гибкость функции маршрутизации - вы можете свободно менять порядок правил для достижения различных результатов.
|
||||
|
||||
На этом мы закончили объяснение того, **как использовать файл `geosite.dat` для разделения сетевого трафика по доменному имени с помощью правил маршрутизации**.
|
||||
|
||||
## 5. Покорение новых высот - Различные условия сопоставления маршрутов
|
||||
|
||||
Пожалуйста, убедитесь, что вы хорошо усвоили материал, изложенный выше, поскольку это основа для понимания принципов работы **функции маршрутизации**. Имея эту базу, мы можем двигаться дальше и рассмотреть более подробные параметры конфигурации и условия сопоставления.
|
||||
|
||||
После того, как вы прочитаете следующий раздел, вы сможете свободно настраивать свои собственные правила маршрутизации! Так чего же мы ждем? Давайте перейдем к [части 2](./routing-lv1-part2.md)!
|
||||
@@ -0,0 +1,434 @@
|
||||
# Краткий обзор функции маршрутизации (routing) (часть 2)
|
||||
|
||||
Добро пожаловать на продолжение изучения **функции маршрутизации** в `Xray`!
|
||||
|
||||
В [части 1](./routing-lv1-part1.md) мы разобрались с логикой работы **функции маршрутизации** и настроили простое разделение трафика по домену на основе файла `geosite.dat`.
|
||||
|
||||
Как уже было сказано, разделение по домену — это лишь верхушка айсберга возможностей **функции маршрутизации**. Давайте посмотрим, что еще, кроме домена, можно использовать в качестве критерия для разделения трафика!
|
||||
|
||||
## 5. Покорение новых высот - Различные условия сопоставления маршрутов
|
||||
|
||||
> `[домен], [IP], [протокол], etc.`
|
||||
|
||||
Разделение по домену уже позволяет нам в общих чертах разделить сетевой трафик. Почему **в общих чертах**?
|
||||
|
||||
Потому что, хотя **"разделение мира на три части"** — это правильная стратегия, ее реализация только с помощью **доменов** имеет множество недостатков, например:
|
||||
|
||||
1. После прочтения нашего руководства я зарегистрировал новый домен `proxy.yourdomain.com` для своего VPS и хочу, чтобы трафик на него всегда проксировался. Есть ли он в `geosite.dat`?
|
||||
2. У меня есть еще один домен `direct.yourdomain.com`, и я хочу, чтобы трафик на него всегда шел напрямую. Есть ли он в `geosite.dat`?
|
||||
3. Правильно ли настроен прямой доступ для локального трафика на `127.0.0.1` (например, `docker`)?
|
||||
4. Правильно ли настроен прямой доступ для трафика в моей локальной сети `192.168.*.*` (например, роутер, NAS)?
|
||||
5. Правильно ли настроен прямой доступ для моих DNS-запросов к внутренним DNS-серверам (например, `223.5.5.5`)?
|
||||
6. Правильно ли настроен прокси для моих DNS-запросов к внешним DNS-серверам (например, `1.1.1.1`)?
|
||||
7. Правильно ли настроен прямой доступ для других внутренних сайтов, у которых нет доменного имени, а только IP-адрес, как у внутренних DNS-серверов?
|
||||
8. Правильно ли настроен прокси для других внешних сайтов, у которых нет доменного имени, а только IP-адрес, как у внешних DNS-серверов?
|
||||
9. Как настроить принудительное прямое подключение для торрент-трафика, который, хотя и поступает извне, может привести к блокировке VPS при проксировании?
|
||||
10. ......
|
||||
|
||||
Я говорю, что разделение по домену имеет много недостатков, потому что файл `geosite.dat` содержит только ограниченный набор часто используемых доменов. Другими словами, полагаясь только на него, мы:
|
||||
|
||||
- не сможем сопоставить новые домены, которых нет в файле;
|
||||
- не сможем сопоставить правила на основе IP-адресов;
|
||||
- не сможем сопоставить правила на основе сетевых протоколов.
|
||||
|
||||
::: warning
|
||||
Давайте вспомним, что происходит, когда эти условия не выполняются? Верно, срабатывает скрытое правило маршрутизации: **трафик перенаправляется на первый исходящий трафик**. Это означает, что:
|
||||
|
||||
- если вашим первым исходящим трафиком является `[direct-out]`: **все, что должно идти напрямую, будет работать правильно, а все, что должно проксироваться, будет работать неправильно**;
|
||||
- если вашим первым исходящим трафиком является `[proxy-out-vless]`: **все, что должно проксироваться, будет работать правильно, а все, что должно идти напрямую, будет работать неправильно**.
|
||||
:::
|
||||
|
||||
Поэтому нам нужен способ, который позволит нам получить и то, и другое. Существует ли такой способ? **Конечно, существует!** Нам просто нужны дополнительные **критерии сопоставления** помимо **домена**.
|
||||
|
||||
### 5.1 Разделение по определенному домену: `[domain], [full]` и т. д.
|
||||
|
||||
1. Для сопоставления поддомена, например `a-name.yourdomain.com`, мы используем `full: "a-name.yourdomain.com"`.
|
||||
2. **Проблемы 1** и **2**, описанные выше, можно решить, указав исходящий трафик `[proxy-out-vless]` для `proxy.yourdomain.com` и исходящий трафик `[direct-out]` для `direct.yourdomain.com`.
|
||||
3. Для сопоставления всех поддоменов `yourdomain.com` мы используем `domain: "yourdomain.com"`.
|
||||
4. Эти два правила могут быть независимыми, чтобы настроить прямое подключение для одних поддоменов и проксирование для других.
|
||||
5. Кроме того, `[domain]` поддерживает сопоставление с помощью регулярных выражений. Подробнее см. [документацию по модулю маршрутизации](../../../config/base/routing/).
|
||||
|
||||
Конфигурация выглядит следующим образом:
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
// Прямое подключение для определенного поддомена
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["full:direct.yourdomain.com"],
|
||||
"outboundTag": "direct-out"
|
||||
},
|
||||
// Проксирование для определенного поддомена
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["full:proxy.yourdomain.com"],
|
||||
"outboundTag": "proxy-out-vless"
|
||||
},
|
||||
// Проксирование для всех поддоменов
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["yourdomain.com"],
|
||||
"outboundTag": "proxy-out-vless"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 5.2 Разделение по IP-адресам из файла: `geoip.dat`
|
||||
|
||||
Подобно файлу правил `geosite.dat`, у нас есть файл правил `geoip.dat`, который предоставляет **готовый к использованию список категорий IP-адресов**. Он позволяет пользователям легко вызывать любую подкатегорию с помощью формата `geoip:xxx` и настраивать правила маршрутизации в соответствии со своими потребностями.
|
||||
|
||||
1. Чтобы решить **проблемы 3** и **4**, описанные выше, мы используем категорию `geoip:private` и указываем исходящий трафик `[direct-out]`.
|
||||
2. Чтобы решить **проблему 7**, мы используем категорию `geoip:cn` и указываем исходящий трафик `[direct-out]`.
|
||||
3. Чтобы решить **проблему 8**, мы используем скрытое правило маршрутизации, поскольку в `geoip` нет категории "не китайские IP-адреса" (потому что это равносильно сбору всех IP-адресов в мире). Другими словами, мы размещаем `[proxy-out-vless]` на первом месте в списке исходящего трафика.
|
||||
|
||||
Конфигурация выглядит следующим образом:
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
// Прямое подключение для локальных и внутренних IP-адресов
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["geoip:private"],
|
||||
"outboundTag": "direct-out"
|
||||
},
|
||||
// Прямое подключение для китайских IP-адресов
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["geoip:cn"],
|
||||
"outboundTag": "direct-out"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 5.3 Разделение по определенному IP-адресу
|
||||
|
||||
1. Чтобы решить **проблему 5**, мы используем `ip: "223.5.5.5"` и указываем исходящий трафик `[direct-out]`.
|
||||
2. Чтобы решить **проблему 6**, мы используем `ip: "1.1.1.1"` и указываем исходящий трафик `[proxy-out-vless]`.
|
||||
|
||||
Конфигурация выглядит следующим образом:
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
// Прямое подключение для определенного IP-адреса
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["223.5.5.5"],
|
||||
"outboundTag": "direct-out"
|
||||
},
|
||||
// Проксирование для определенного IP-адреса
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["1.1.1.1"],
|
||||
"outboundTag": "proxy-out-vless"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 5.4 Разделение по типу протокола: `[protocol]` и т. д.
|
||||
|
||||
1. Чтобы решить **проблему 9**, мы используем `"protocol": ["bittorrent"]` и указываем исходящий трафик `[direct-out]`.
|
||||
|
||||
::: tip
|
||||
Вам нужно включить `sniffing` во входящем прокси, чтобы использовать этот метод разделения.
|
||||
:::
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
// Прямое подключение для торрент-трафика
|
||||
{
|
||||
"type": "field",
|
||||
"protocol": ["bittorrent"],
|
||||
"outboundTag": "direct-out"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 5.5 Разделение по другим критериям
|
||||
|
||||
На данный момент мы рассмотрели лишь малую часть возможностей разделения трафика **функции маршрутизации**! Она поддерживает множество других критериев сопоставления! Я перечислю их здесь:
|
||||
|
||||
Критерии, которые мы уже рассмотрели:
|
||||
|
||||
- `inboundTag`
|
||||
- `domain`
|
||||
- `ip`
|
||||
- `protocol`
|
||||
|
||||
Критерии, которые мы еще не рассмотрели:
|
||||
|
||||
- `port`
|
||||
- `sourcePort`
|
||||
- `network`
|
||||
- `source`
|
||||
- `user`
|
||||
- `attrs`
|
||||
|
||||
Однако, это слишком много информации для уровня 1, поэтому, если вам нужны эти сложные критерии, пожалуйста, внимательно изучите [документацию по модулю маршрутизации](../../config/base/routing/) самостоятельно! Если у вас возникнут вопросы, задавайте их в Telegram-группе!
|
||||
|
||||
## 6. "Начало новой эры": обзор правил маршрутизации
|
||||
|
||||
К настоящему моменту у нас накопился внушительный набор правил маршрутизации. Чтобы избежать путаницы, давайте проведем полный обзор.
|
||||
|
||||
::: warning Внимание
|
||||
Правила маршрутизации обрабатываются **последовательно сверху вниз**. Поэтому я рекомендую следующий порядок:
|
||||
|
||||
`[1-block] --> [2-direct] --> [3-proxy] --> [4-first-outbound]`
|
||||
:::
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
// [1-block Блокировка рекламы]
|
||||
// 1.1 Блокировка рекламных доменов
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["geosite:category-ads-all"],
|
||||
"outboundTag": "block"
|
||||
},
|
||||
// [2-direct Прямое подключение к внутренним ресурсам]
|
||||
// 2.1 Прямое подключение для китайских доменов и определенного поддомена
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["geosite:cn", "full:direct.yourdomain.com"],
|
||||
"outboundTag": "direct-out"
|
||||
},
|
||||
// 2.2 Прямое подключение для локальных, внутренних, китайских и определенных IP-адресов
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["geoip:private", "geoip:cn", "223.5.5.5"],
|
||||
"outboundTag": "direct-out"
|
||||
},
|
||||
// 2.3 Прямое подключение для торрент-трафика
|
||||
{
|
||||
"type": "field",
|
||||
"protocol": ["bittorrent"],
|
||||
"outboundTag": "direct-out"
|
||||
},
|
||||
// [3-proxy Проксирование для внешних ресурсов]
|
||||
// 3.1 Проксирование для иностранных доменов, определенного поддомена и всех поддоменов
|
||||
{
|
||||
"type": "field",
|
||||
"domain": [
|
||||
"geosite:geolocation-!cn",
|
||||
"full:proxy.yourdomain.com",
|
||||
"yourdomain.com"
|
||||
],
|
||||
"outboundTag": "proxy-out-vless"
|
||||
},
|
||||
// 3.2 Проксирование для определенного IP-адреса
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["1.1.1.1"],
|
||||
"outboundTag": "proxy-out-vless"
|
||||
}
|
||||
// [4-default-routing Первый исходящий трафик]
|
||||
// Трафик, не соответствующий ни одному правилу, обрабатывается первым исходящим трафиком
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Теперь правила маршрутизации выглядят так:
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
S(Данные приложения) .-> I[Входящий трафик]
|
||||
|
||||
subgraph Xray
|
||||
I --> R[Маршрутизация] -- "geosite:category-ads-all" --> O1[block]
|
||||
|
||||
R[Маршрутизация] -- "geosite:cn" --> O2[direct]
|
||||
R[Маршрутизация] -- "direct.yourdomain.com" --> O2[direct]
|
||||
R[Маршрутизация] -- "geoip:private" --> O2[direct]
|
||||
R[Маршрутизация] -- "geoip:cn" --> O2[direct]
|
||||
R[Маршрутизация] -- "ip:223.5.5.5" --> O2[direct]
|
||||
R[Маршрутизация] -- "protocol:bittorrent" --> O2[direct]
|
||||
|
||||
R[Маршрутизация] -- "geosite:geolocation-!cn" --> O3[proxy]
|
||||
R[Маршрутизация] -- "proxy.yourdomain.com" --> O3[proxy]
|
||||
R[Маршрутизация] -- "*.yourdomain.com" --> O3[proxy]
|
||||
R[Маршрутизация] -- "ip:1.1.1.1" --> O3[proxy]
|
||||
|
||||
R[Маршрутизация] -. "Трафик, не соответствующий ни одному правилу" .-> O4[Первый исходящий трафик]
|
||||
|
||||
end
|
||||
|
||||
O2 .-> D(Внутренний сервер)
|
||||
O3 .-> V(VPS)
|
||||
|
||||
O1:::redclass
|
||||
V:::greyclass
|
||||
S:::greyclass
|
||||
R:::routingclass
|
||||
classDef redclass fill:#FF0000
|
||||
classDef greyclass fill:#C0C0C0
|
||||
classDef routingclass fill:#FFFFDE,stroke:#000000
|
||||
|
||||
```
|
||||
|
||||
Будет ли первым исходящим трафиком `[direct-out]` или `[proxy-out-vless]`, зависит от ваших потребностей.
|
||||
|
||||
## 7. Распространенные ошибки в конфигурации маршрутизации
|
||||
|
||||
Обратите внимание, что каждое правило маршрутизации, которое я привел выше, имеет **только один критерий сопоставления**. Это необходимо для того, чтобы правило работало корректно. Частая ошибка новичков при настройке маршрутизации заключается в том, что они **указывют несколько критериев сопоставления в одном правиле, что делает его недействительным**.
|
||||
|
||||
Например, предположим, что нужно настроить следующее:
|
||||
|
||||
1. Прямое подключение для собственного домена `direct.yourdomain.com`.
|
||||
2. Прямое подключение для DNS-запросов к внутренним DNS-серверам (например, `223.5.5.5`).
|
||||
|
||||
### 7.1 Неправильный пример
|
||||
|
||||
Чтобы достичь этой цели, новичок может написать следующее правило маршрутизации:
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["223.5.5.5"],
|
||||
"domain": ["full:direct.yourdomain.com"],
|
||||
"outboundTag": "direct-out"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Видите ли вы здесь ошибку? На первый взгляд, кажется, все правильно?
|
||||
|
||||
::: warning Внимание
|
||||
**В одном правиле все критерии должны выполняться одновременно**, чтобы правило сработало. Логическое отношение — "**И**", а не "**ИЛИ**".
|
||||
:::
|
||||
|
||||
Другими словами, это правило означает: **`Xray` направит трафик на исходящий трафик `[direct-out]` только в том случае, если целевой адрес равен `direct.yourdomain.com` **и** `223.5.5.5` одновременно**.
|
||||
|
||||
Очевидно, что один адрес не может быть равен двум разным значениям одновременно, поэтому это не только невыполнимое правило, но и не имеет ничего общего с нашей первоначальной целью.
|
||||
|
||||
### 7.2 Правильный пример
|
||||
|
||||
Правильное решение — разделить разные критерии сопоставления на разные правила:
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["223.5.5.5"],
|
||||
"outboundTag": "direct-out"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["full:direct.yourdomain.com"],
|
||||
"outboundTag": "direct-out"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
На самом деле, в пункте 6 я уже привел упорядоченные правила, принцип которых заключается в том, что **одинаковые критерии сопоставления можно объединять, а разные критерии сопоставления должны быть разделены**.
|
||||
|
||||
## 8. Скрытые пути
|
||||
|
||||
> Секретный проход для преобразования `[domain]` в `[ip]`: `domainStrategy`
|
||||
|
||||
В пункте 5.4 мы рассмотрели различные **критерии** для сопоставления трафика, среди которых были **домен** `[domain]` и **IP-адрес** `[IP]`.
|
||||
|
||||
Если вы знакомы с принципами работы DNS, то знаете, что при обращении к домену `[domain]` сначала нужно отправить запрос на DNS-сервер, чтобы получить IP-адрес `[IP]`, соответствующий домену, а затем отправить фактический запрос на этот IP-адрес.
|
||||
|
||||
Поэтому у `Xray` есть два шанса определить тип входящего запроса к домену. Использовать ли эти два шанса, решает параметр `domainStrategy`. Он имеет три значения:
|
||||
|
||||
- `AsIs`
|
||||
- `IPIfNonMatch`
|
||||
- `IPOnDemand`
|
||||
|
||||
Давайте рассмотрим каждое из них:
|
||||
|
||||
### 8.1 Стратегия домена: `"AsIs"`
|
||||
|
||||
"As Domain Is" означает **"как есть, без лишних действий"**.
|
||||
|
||||
Проще говоря, **"сопоставлять только по домену"**.
|
||||
|
||||
::: tip
|
||||
`AsIs` на самом деле означает **"как есть, без изменений"**. Описание 🍉-sensei не совсем точное.
|
||||
:::
|
||||
|
||||
В этом режиме вся обработка выполняется внутри `Xray` без обмена данными с внешним миром, поэтому скорость максимальна. Стратегия обработки несопоставимых доменов также ясна: как уже говорилось ранее, они автоматически перенаправляются на первый исходящий трафик. Поэтому это **наиболее рекомендуемая стратегия** для обычного использования функции маршрутизации.
|
||||
|
||||
### 8.2 Стратегия домена: `"IPIfNonMatch"`
|
||||
|
||||
"lookup IP if (there's) no matching rule" означает **"искать IP-адрес, если не найдено совпадений по другим правилам"**.
|
||||
|
||||
Проще говоря, **"сначала сопоставить целевой адрес со всеми правилами, а если совпадений не найдено, то получить IP-адрес через DNS и снова сопоставить его со всеми правилами"**.
|
||||
|
||||
В этом режиме домены, не сопоставленные ни с одним правилом, будут проходить через DNS-запрос и второй этап сопоставления правил, что займет больше времени, чем в режиме `AsIs`. Поэтому это **не самая рекомендуемая стратегия**.
|
||||
|
||||
### 8.3 Стратегия домена: `"IPOnDemand"`
|
||||
|
||||
"Demand IP" означает **"запрашивать IP-адрес"**.
|
||||
|
||||
Проще говоря, **"если в правилах маршрутизации есть правила на основе IP-адреса, то все запросы на основе домена `[domain]` будут преобразованы в IP-адреса `[IP]` и сопоставлены с правилами на основе IP-адреса"**.
|
||||
|
||||
В этом режиме все запросы к доменам будут проходить через DNS-запрос, поэтому первый запрос будет медленным. Хотя благодаря механизму кэширования DNS в `Xray` последующие запросы к тому же домену будут быстрыми, в целом это **не самая рекомендуемая стратегия**.
|
||||
|
||||
::: warning
|
||||
`domainStrategy` действует **только для доменов**, не путайте!
|
||||
:::
|
||||
|
||||
## 9. Задание для размышления
|
||||
|
||||
До сих пор мы рассматривали логику конфигурации **маршрутизации** на основе **одного входящего** и **одного исходящего** трафика.
|
||||
|
||||
Но, как вы знаете, `Xray` поддерживает несколько портов и протоколов. Что, если я спрошу вас:
|
||||
|
||||
1. Я хочу, чтобы протокол `VLESS` перенаправлял мой обычный веб-трафик и трафик приложений на высокоскоростной сервер в США.
|
||||
2. Я хочу, чтобы протокол `trojan` перенаправлял весь мой трафик Netflix на сервер в Японии, чтобы разблокировать все аниме.
|
||||
3. Я хочу, чтобы протокол `shadowsocks` перенаправлял весь мой игровой трафик на сервер в Гонконге для минимальной задержки.
|
||||
4. Я хочу, чтобы был отдельный порт, который перенаправлял бы весь трафик `telegram` на VPS.
|
||||
5. Я хочу, чтобы был отдельный порт, который перенаправлял бы весь торрент-трафик на мощный сервер в Европе.
|
||||
6. Я хочу......
|
||||
|
||||
Можно ли реализовать эти сценарии с помощью **функции маршрутизации**?
|
||||
|
||||
Ответ, конечно же, **да**! Однако, это выходит за рамки уровня 1, поэтому я оставлю это вам для самостоятельного изучения!
|
||||
|
||||
## 10. Заключение
|
||||
|
||||
На этом обзор **функции маршрутизации** в `Xray` завершен. Надеюсь, эта статья помогла вам лучше понять гибкость `Xray`.
|
||||
|
||||
## 11. Примечания
|
||||
|
||||
- Теперь вы можете перечитать раздел [Маршрутизация](../../config/routing.md) и посмотреть, стало ли вам что-то понятнее.
|
||||
- 🍉🍉🍉🍉🍉 :D
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,56 @@
|
||||
# Режимы работы Xray
|
||||
|
||||
## Режим одного сервера
|
||||
|
||||
Как и в случае с другими прокси-инструментами, вам понадобится сервер с настроенным Xray, а затем установить и настроить клиент Xray на вашем устройстве, после чего вы сможете свободно пользоваться Интернетом.
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
A(ПК) -.- B(Брандмауэр);
|
||||
B -.-> C(Внешний сайт);
|
||||
A --> D(Xray/VPS);
|
||||
D --> C;
|
||||
A --> E(Внутренний сайт);
|
||||
```
|
||||
|
||||
Один сервер Xray может одновременно обслуживать несколько устройств, использующих разные протоколы проксирования. При правильной настройке Xray может распознавать и различать трафик, который нужно проксировать, и трафик, который можно отправлять напрямую, без проксирования.
|
||||
|
||||
## Режим моста
|
||||
|
||||
Если вы не хотите настраивать маршрутизацию на каждом устройстве, вы можете настроить промежуточный сервер, который будет принимать весь трафик от клиентов и перенаправлять его в зависимости от настроек.
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
A(ПК) -.-> B(Брандмауэр);
|
||||
B -.-> C(Внешний сайт);
|
||||
A --> D(Внутренний VPS);
|
||||
D --> E(Внешний VPS);
|
||||
E --> C;
|
||||
D --> F(Внутренний сайт);
|
||||
```
|
||||
|
||||
## Принцип работы
|
||||
|
||||
Перед настройкой Xray давайте рассмотрим, как он работает. Ниже представлена схема внутреннего устройства одного процесса Xray. Несколько процессов Xray работают независимо друг от друга.
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
A1(inbound) --> D(Dispatcher / Router / DNS);
|
||||
A2(inbound) --> D;
|
||||
A3(inbound) --> D;
|
||||
A4(inbound) --> D;
|
||||
D --> B1(outbound);
|
||||
D --> B2(outbound);
|
||||
D --> B3(outbound);
|
||||
D --> B4(outbound);
|
||||
```
|
||||
|
||||
- Для нормальной работы необходимо настроить как минимум одно входящее соединение (Inbound) и одно исходящее соединение (Outbound).
|
||||
- Входящее соединение отвечает за связь с клиентом (например, браузером):
|
||||
- Входящее соединение обычно можно настроить с аутентификацией пользователя, например, с использованием ID и пароля;
|
||||
- После получения данных входящее соединение передает их диспетчеру (Dispatcher) для распределения.
|
||||
- Исходящее соединение отвечает за отправку данных на сервер, например, на другой Xray, работающий на другом хосте.
|
||||
- При наличии нескольких исходящих соединений можно настроить маршрутизацию (Routing) для указания, какое исходящее соединение должно использоваться для определенного типа трафика.
|
||||
- При необходимости маршрутизатор обращается к DNS для получения дополнительной информации для принятия решения.
|
||||
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
# Продвинутая документация
|
||||
|
||||
**В этом разделе представлены советы и рекомендации по использованию Xray для продвинутых пользователей. Если вы уже знакомы с Xray, то информация, представленная здесь, поможет вам использовать Xray по максимуму.**
|
||||
|
||||
[Введение в прозрачное проксирование](./transparent_proxy/transparent_proxy.md) от <img src="https://avatars2.githubusercontent.com/u/57820613?s=32" width="32" height="32" alt="a"/> [@kirin](https://github.com/kirin10000)
|
||||
|
||||
Вводная статья о прозрачном проксировании.
|
||||
|
||||
[Руководство по настройке прозрачного проксирования (TProxy) ](./tproxy.md) от <img src="https://avatars2.githubusercontent.com/u/41363844?s=32" width="32" height="32" alt="a"/> [@BioniCosmos](https://github.com/BioniCosmos)
|
||||
|
||||
Полное руководство по настройке прозрачного проксирования (TProxy) на основе Xray.
|
||||
|
||||
[Руководство по настройке прозрачного проксирования TProxy (ipv4 и ipv6)](./tproxy_ipv4_and_ipv6.md) от <img src="https://avatars.githubusercontent.com/u/110686480?s=32" width="32" height="32" alt="a"/> [@SQLimit](https://github.com/SQLimit)
|
||||
|
||||
Руководство по настройке прозрачного проксирования TProxy (ipv4 и ipv6) на основе Xray.
|
||||
|
||||
[Создание TLS-туннеля с помощью Nginx или Haproxy для скрытия отпечатков](./nginx_or_haproxy_tls_tunnel.md) от <img src="https://avatars.githubusercontent.com/u/110686480?s=32" width="32" height="32" alt="a"/> [@SQLimit](https://github.com/SQLimit)
|
||||
|
||||
Создание TLS-туннеля с помощью Nginx или Haproxy на стороне клиента и сервера для скрытия отпечатков.
|
||||
|
||||
[[Прозрачное проксирование] Исключение трафика Xray с помощью GID](./iptables_gid.md) от <img src="https://avatars2.githubusercontent.com/u/57820613?s=32" width="32" height="32" alt="a"/> [@kirin](https://github.com/kirin10000)
|
||||
|
||||
Новый способ исключения трафика Xray при реализации прозрачного проксирования с помощью iptables/nftables.
|
||||
|
||||
[Направление определенного трафика через определенный выходной узел с помощью Xray для реализации "разделения" глобальной маршрутизации](./redirect.md) от <img src="https://avatars.githubusercontent.com/u/28607089?s=32" width="32" height="32" alt="a"/> [@Zzz3m](https://github.com/Zzz3m)
|
||||
|
||||
Использование Xray по максимуму: реализация "разделения" трафика на основе fwmark, sendThrough или sockopt.interface.
|
||||
|
||||
[Повышение безопасности проксирования с помощью Cloudflare Warp](./warp.md) от <img src="https://avatars.githubusercontent.com/u/1588741?s=32" width="32" height="32" alt="a"/> [@yuhan6665](https://github.com/yuhan6665)
|
||||
|
||||
Введение в использование исходящего подключения WireGuard, добавленного в Xray v1.6.5.
|
||||
|
||||
[Статистика трафика Xray](./traffic_stats.md) от <img src="https://avatars.githubusercontent.com/u/1588741?s=32" width="32" height="32" alt="a"/> [@yuhan6665](https://github.com/yuhan6665)
|
||||
|
||||
Статистика трафика и скрипты для Xray.
|
||||
|
||||
|
||||
@@ -0,0 +1,240 @@
|
||||
---
|
||||
title: GID Прозрачное проксирование
|
||||
---
|
||||
|
||||
# Прозрачное проксирование: Исключение трафика Xray с помощью GID
|
||||
|
||||
В существующих русскоязычных руководствах по прозрачному проксированию с использованием iptables (**[Новое руководство по V2Ray на русском языке - Прозрачное проксирование](https://guide.v2fly.org/app/transparent_proxy.html)**, **[Новое руководство по V2Ray на русском языке - Прозрачное проксирование (TPROXY)](https://guide.v2fly.org/app/tproxy.html)**, **[Руководство по настройке прозрачного проксирования (TProxy)](./tproxy)**) исключение трафика Xray осуществляется с помощью меток. Исходящий трафик Xray помечается, а затем с помощью правил iptables трафик с соответствующей меткой направляется напрямую, минуя Xray и предотвращая зацикливание.
|
||||
|
||||
У такого подхода есть несколько недостатков:
|
||||
|
||||
1. **[Необъяснимый трафик попадает в цепочку PREROUTING](https://github.com/v2ray/v2ray-core/issues/2621)**
|
||||
|
||||
2. Android использует собственный механизм меток, поэтому данный метод не применим к Android
|
||||
|
||||
Предлагаемый в данном руководстве подход не требует использования меток, теоретически обеспечивая более высокую производительность и избегая описанных выше проблем.
|
||||
|
||||
## Идея
|
||||
|
||||
Tproxy трафик может приниматься только пользователями с правами root (uid==0) или CAP_NET_ADMIN.
|
||||
|
||||
Правила iptables позволяют разделять трафик на основе UID (идентификатор пользователя) и GID (идентификатор группы).
|
||||
|
||||
Запустим Xray от имени пользователя с uid==0 и gid!=0 и настроим правила iptables, чтобы исключить трафик с этим GID, избегая проксирования трафика Xray.
|
||||
|
||||
## Настройка
|
||||
|
||||
### 1. Предварительная подготовка
|
||||
|
||||
**Android**
|
||||
|
||||
1. На устройстве должны быть получены root-права.
|
||||
2. Установите **[busybox](https://play.google.com/store/apps/details?id=stericson.busybox)**.
|
||||
3. Наличие терминала для выполнения команд, например, adb shell, Termux и т.д.
|
||||
|
||||
**Другие Linux системы**
|
||||
|
||||
Необходимо наличие sudo, модуля tproxy для iptables и модуля extra.
|
||||
|
||||
Обычно все это уже установлено в системе, для OpenWRT выполните:
|
||||
|
||||
```bash
|
||||
opkg install sudo iptables-mod-tproxy iptables-mod-extra
|
||||
```
|
||||
|
||||
Также могут понадобиться следующие зависимости для OpenWRT, их отсутствие может помешать запуску Xray:
|
||||
|
||||
```bash
|
||||
opkg install libopenssl ca-certificates
|
||||
```
|
||||
|
||||
### 2. Добавление пользователя (пропустите для Android)
|
||||
|
||||
Android не поддерживает файл /etc/passwd для управления пользователями, пропустите этот шаг и перейдите к следующему.
|
||||
|
||||
```bash
|
||||
grep -qw xray_tproxy /etc/passwd || echo "xray_tproxy:x:0:23333:::" >> /etc/passwd
|
||||
```
|
||||
|
||||
Где xray_tproxy - имя пользователя, 0 - UID, 23333 - GID. Имя пользователя и GID можно задать произвольно, UID должен быть равен 0.
|
||||
Проверьте, успешно ли добавлен пользователь, выполнив:
|
||||
|
||||
```bash
|
||||
sudo -u xray_tproxy id
|
||||
```
|
||||
|
||||
В результате должен отобразиться UID 0 и GID 23333.
|
||||
|
||||
### 3. Настройка запуска Xray и правил iptables
|
||||
|
||||
Внесите изменения в существующие русскоязычные руководства по прозрачному проксированию с использованием iptables (**[Новое руководство по V2Ray на русском языке - Прозрачное проксирование](https://guide.v2fly.org/app/transparent_proxy.html)**, **[Новое руководство по V2Ray на русском языке - Прозрачное проксирование (TPROXY)](https://guide.v2fly.org/app/tproxy.html)**, **[Руководство по настройке прозрачного проксирования (TProxy)](./tproxy)**):
|
||||
|
||||
1. Измените конфигурационный файл JSON, удалив все, что связано с метками.
|
||||
|
||||
2. Измените правила iptables, удалив все, что связано с метками, и добавьте опцию "-m owner ! --gid-owner 23333" в цепочку OUTPUT перед применением правила XRAY_SELF.
|
||||
|
||||
Например:
|
||||
|
||||
```bash
|
||||
iptables -t mangle -A OUTPUT -j XRAY_SELF
|
||||
```
|
||||
|
||||
Замените на:
|
||||
|
||||
```bash
|
||||
iptables -t mangle -A OUTPUT -m owner ! --gid-owner 23333 -j XRAY_SELF
|
||||
```
|
||||
|
||||
3. Измените способ запуска Xray, чтобы он запускался от имени пользователя с UID 0 и GID 23333, см. [здесь](#3-настройка-максимального-количества-открытых-файлов-и-запуск-клиента-xray).
|
||||
|
||||
## Ниже приведен пример полной настройки глобального проксирования с использованием TPROXY
|
||||
|
||||
### 1. Выполните [предварительную подготовку](#1-предварительная-подготовка) и [добавление пользователя](#2-добавление-пользователя-пропустите-для-android).
|
||||
|
||||
### 2. Подготовьте конфигурационный файл Xray.
|
||||
|
||||
Настройте произвольную дверь Xray для прослушивания порта 12345, включите followRedirect и tproxy, sniffing не требуется:
|
||||
|
||||
```json
|
||||
{
|
||||
"inbounds": [
|
||||
{
|
||||
"port": 12345,
|
||||
"protocol": "dokodemo-door",
|
||||
"settings": {
|
||||
"network": "tcp,udp",
|
||||
"followRedirect": true
|
||||
},
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"tproxy": "tproxy"
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"outbounds": [
|
||||
{
|
||||
// Конфигурация вашего сервера
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 3. Настройка максимального количества открытых файлов и запуск клиента Xray
|
||||
|
||||
О проблеме "too many open files" см.: **[Проблема too many open files](https://guide.v2fly.org/app/tproxy.html#решение-проблемы-too-many-open-files)**
|
||||
|
||||
В настоящее время при установке сервера Xray с помощью официального скрипта максимальное количество открытых файлов настраивается автоматически, никаких дополнительных действий не требуется.
|
||||
|
||||
**Android**
|
||||
|
||||
```bash
|
||||
ulimit -SHn 1000000
|
||||
setuidgid 0:23333 "команда запуска Xray"&
|
||||
```
|
||||
|
||||
**Другие Linux системы**
|
||||
|
||||
```bash
|
||||
ulimit -SHn 1000000
|
||||
sudo -u xray_tproxy "команда запуска Xray"&
|
||||
```
|
||||
|
||||
Например:
|
||||
|
||||
```bash
|
||||
ulimit -SHn 1000000
|
||||
sudo -u xray_tproxy xray -c /etc/xray/config.json &
|
||||
```
|
||||
|
||||
_Первая команда:_
|
||||
|
||||
Изменяет максимальное количество открытых файлов, действует только в текущем терминале, необходимо выполнять перед каждым запуском Xray. Эта команда устанавливает максимальное количество открытых файлов для клиента.
|
||||
|
||||
_Вторая команда:_
|
||||
|
||||
Запускает клиент Xray от имени пользователя с UID 0 и GID, отличным от 0. Символ & в конце команды означает запуск в фоновом режиме.
|
||||
|
||||
**Проверка настройки максимального количества открытых файлов**
|
||||
|
||||
```bash
|
||||
cat /proc/PID Xray/limits
|
||||
```
|
||||
|
||||
Найдите строку "Max open files", значение должно соответствовать установленному вами. PID процесса Xray можно узнать, выполнив команду `ps`, `ps -aux`, `ps -a` или `pidof xray`.
|
||||
|
||||
Проверьте как сервер, так и клиент.
|
||||
|
||||
### 4. Настройка правил iptables
|
||||
|
||||
**Проксирование IPv4**
|
||||
|
||||
```bash
|
||||
ip rule add fwmark 1 table 100
|
||||
ip route add local 0.0.0.0/0 dev lo table 100
|
||||
|
||||
# Проксирование устройств локальной сети
|
||||
iptables -t mangle -N XRAY
|
||||
# "Сегмент IPv4-сети шлюза" можно получить, выполнив команду "ip address | grep -w inet | awk '{print $2}'", как правило, их несколько
|
||||
iptables -t mangle -A XRAY -d Сегмент IPv4-сети шлюза 1 -j RETURN
|
||||
iptables -t mangle -A XRAY -d Сегмент IPv4-сети шлюза 2 -j RETURN
|
||||
...
|
||||
|
||||
# Прямое подключение для многоадресных адресов/адресов класса E/широковещательных адресов
|
||||
iptables -t mangle -A XRAY -d 224.0.0.0/3 -j RETURN
|
||||
|
||||
# Если шлюз является основным маршрутизатором, добавьте эту строку, см.: https://xtls.github.io/documents/level-2/transparent_proxy/transparent_proxy.md#iptables-прозрачное-проксирование-другие-замечания
|
||||
# "Диапазон LAN-адресов IPv4 шлюза" можно получить, выполнив команду "ip address | grep -w "inet" | awk '{print $2}'", это будет один из адресов
|
||||
iptables -t mangle -A XRAY ! -s Диапазон LAN-адресов IPv4 шлюза -j RETURN
|
||||
|
||||
# Пометить TCP-трафик меткой 1 и перенаправить на порт 12345
|
||||
# Трафик будет приниматься произвольной дверью Xray только при наличии метки 1
|
||||
iptables -t mangle -A XRAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
|
||||
iptables -t mangle -A XRAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 1
|
||||
# Применить правило
|
||||
iptables -t mangle -A PREROUTING -j XRAY
|
||||
|
||||
# Проксирование хоста шлюза
|
||||
iptables -t mangle -N XRAY_MASK
|
||||
iptables -t mangle -A XRAY_MASK -m owner --gid-owner 23333 -j RETURN
|
||||
iptables -t mangle -A XRAY_MASK -d Сегмент IPv4-сети шлюза 1 -j RETURN
|
||||
iptables -t mangle -A XRAY_MASK -d Сегмент IPv4-сети шлюза 2 -j RETURN
|
||||
...
|
||||
iptables -t mangle -A XRAY_MASK -d 224.0.0.0/3 -j RETURN
|
||||
iptables -t mangle -A XRAY_MASK -j MARK --set-mark 1
|
||||
iptables -t mangle -A OUTPUT -p tcp -j XRAY_MASK
|
||||
iptables -t mangle -A OUTPUT -p udp -j XRAY_MASK
|
||||
```
|
||||
|
||||
**Проксирование IPv6 (необязательно)**
|
||||
|
||||
```bash
|
||||
ip -6 rule add fwmark 1 table 106
|
||||
ip -6 route add local ::/0 dev lo table 106
|
||||
|
||||
# Проксирование устройств локальной сети
|
||||
ip6tables -t mangle -N XRAY6
|
||||
# "Сегмент IPv6-сети шлюза" можно получить, выполнив команду "ip address | grep -w inet6 | awk '{print $2}'".
|
||||
ip6tables -t mangle -A XRAY6 -d Сегмент IPv6-сети шлюза 1 -j RETURN
|
||||
ip6tables -t mangle -A XRAY6 -d Сегмент IPv6-сети шлюза 2 -j RETURN
|
||||
...
|
||||
|
||||
# Если шлюз является основным маршрутизатором, добавьте эту строку, см.: https://xtls.github.io/documents/level-2/transparent_proxy/transparent_proxy.md#iptables-прозрачное-проксирование-другие-замечания
|
||||
# "Диапазон LAN-адресов IPv6 шлюза" можно получить, выполнив команду "ip address | grep -w "inet6" | awk '{print $2}'", это будет один из адресов
|
||||
ip6tables -t mangle -A XRAY6 ! -s Диапазон LAN-адресов IPv6 шлюза -j RETURN
|
||||
|
||||
ip6tables -t mangle -A XRAY6 -p udp -j TPROXY --on-port 12345 --tproxy-mark 1
|
||||
ip6tables -t mangle -A XRAY6 -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
|
||||
ip6tables -t mangle -A PREROUTING -j XRAY6
|
||||
|
||||
# Проксирование хоста шлюза
|
||||
ip6tables -t mangle -N XRAY6_MASK
|
||||
ip6tables -t mangle -A XRAY6_MASK -m owner --gid-owner 23333 -j RETURN
|
||||
ip6tables -t mangle -A XRAY6_MASK -d Сегмент IPv6-сети шлюза 1 -j RETURN
|
||||
ip6tables -t mangle -A XRAY6_MASK -d Сегмент IPv6-сети шлюза 2 -j RETURN
|
||||
...
|
||||
ip6tables -t mangle -A XRAY6_MASK -j MARK --set-mark 1
|
||||
ip6tables -t mangle -A OUTPUT -p tcp -j XRAY6_MASK
|
||||
ip6tables -t mangle -A OUTPUT -p udp -j XRAY6_MASK
|
||||
```
|
||||
|
||||
@@ -0,0 +1,729 @@
|
||||
---
|
||||
title: Создание TLS-туннеля с помощью Nginx или Haproxy для скрытия отпечатков
|
||||
---
|
||||
|
||||
Nginx или Haproxy реализуют HTTPS-туннели, туннели HTTP/2 over HTTPS, туннели WebSocket over HTTP/2 over HTTPS, туннели gRPC over HTTP/2 over HTTPS, а также туннели gRPC over HTTP/2 over HTTPS с двусторонней аутентификацией по самозаверяющему сертификату.
|
||||
|
||||
# Создание HTTPS-туннеля с помощью Nginx на стороне клиента и сервера для скрытия отпечатков
|
||||
|
||||
Сетевая структура:
|
||||
|
||||
xray_client ---tcp--- nginx_client ---HTTPS--- nginx_sever ---tcp--- xray_server
|
||||
|
||||
## Компиляция nginx с поддержкой --with-stream
|
||||
|
||||
Выполните компиляцию как на клиенте, так и на сервере.
|
||||
|
||||
`curl -O -L http://nginx.org/download/nginx-1.22.1.tar.gz`
|
||||
|
||||
`tar -zxvf nginx-1.22.1.tar.gz`
|
||||
|
||||
`cd nginx-1.22.1`
|
||||
|
||||
`apt install gcc make` // Для компиляции требуются gcc и make
|
||||
|
||||
`./configure --prefix=/usr/local/nginx --with-http_ssl_module --with-http_v2_module --with-stream --with-stream_ssl_module` // На этом шаге могут потребоваться дополнительные библиотеки, установите их в соответствии с сообщениями об ошибках.
|
||||
|
||||
`make && make install`
|
||||
|
||||
После компиляции папка nginx будет находиться в `/usr/local/nginx`.
|
||||
|
||||
## Настройка nginx
|
||||
|
||||
Отредактируйте конфигурационный файл nginx.conf.
|
||||
|
||||
`vim /usr/local/nginx/conf/nginx.conf`
|
||||
|
||||
Добавьте следующую конфигурацию на стороне сервера.
|
||||
|
||||
Получение сертификата для сервера не рассматривается в данном руководстве. Обратитесь к [документации](https://xtls.github.io/document/level-0/ch06-certificates.html).
|
||||
|
||||
```
|
||||
stream {
|
||||
server {
|
||||
listen 443 ssl;
|
||||
listen [::]:443 ssl;
|
||||
ssl_protocols TLSv1.3;
|
||||
ssl_certificate /path/to/cert/domain.crt; # Путь к файлу crt
|
||||
ssl_certificate_key /path/to/cert/domain.key; # Путь к файлу key
|
||||
proxy_pass unix:/dev/shm/vless.sock; # Использование доменного сокета
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
::: warning Внимание
|
||||
|
||||
Раздел stream находится на одном уровне с модулем http. Клиент может удалить раздел http, а сервер может удалить его или настроить веб-сайт для маскировки.
|
||||
:::
|
||||
|
||||
Добавьте следующую конфигурацию на стороне клиента.
|
||||
|
||||
```
|
||||
stream {
|
||||
server {
|
||||
listen 6666;
|
||||
listen [::]:6666;
|
||||
proxy_ssl on;
|
||||
proxy_ssl_protocols TLSv1.3;
|
||||
proxy_ssl_server_name on;
|
||||
proxy_ssl_name yourdomain.domain; # Доменное имя сервера
|
||||
proxy_pass ip:443; # IP-адрес сервера, например, proxy_pass 6.6.6.6:443; или proxy_pass [2401:0:0::1]:443;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Создайте файл `nginx.service` в папке `/etc/systemd/system`.
|
||||
|
||||
`vim /etc/systemd/system/nginx.service`
|
||||
|
||||
Добавьте следующий текст:
|
||||
|
||||
```
|
||||
[Unit]
|
||||
Description=The NGINX HTTP and reverse proxy server
|
||||
After=syslog.target network-online.target remote-fs.target nss-lookup.target
|
||||
After=xray.service
|
||||
|
||||
[Service]
|
||||
Type=forking
|
||||
ExecStartPre=/usr/local/nginx/sbin/nginx -t
|
||||
ExecStart=/usr/local/nginx/sbin/nginx
|
||||
ExecReload=/usr/local/nginx/sbin/nginx -s reload
|
||||
ExecStop=/bin/kill -s QUIT $MAINPID
|
||||
PrivateTmp=true
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
Добавьте автоматический запуск при загрузке системы.
|
||||
|
||||
`systemctl enable nginx`
|
||||
|
||||
## Настройка Xray
|
||||
|
||||
Конфигурация Xray на стороне сервера:
|
||||
|
||||
```json
|
||||
{
|
||||
"log": {
|
||||
"loglevel": "none"
|
||||
},
|
||||
"inbounds": [
|
||||
{
|
||||
"listen": "/dev/shm/vless.sock,0666",
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "uuid"
|
||||
}
|
||||
],
|
||||
"decryption": "none"
|
||||
},
|
||||
"streamSettings": {
|
||||
"network": "tcp"
|
||||
},
|
||||
"sniffing": {
|
||||
"enabled": true,
|
||||
"destOverride": [
|
||||
"http",
|
||||
"tls"
|
||||
]
|
||||
}
|
||||
}
|
||||
],
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Конфигурация Xray на стороне клиента (в данном примере используется прозрачное проксирование пограничного маршрутизатора):
|
||||
|
||||
```json
|
||||
{
|
||||
"log": {
|
||||
"loglevel": "none"
|
||||
},
|
||||
"dns": {
|
||||
"servers": [
|
||||
"1.1.1.1",
|
||||
{
|
||||
"address": "119.29.29.29",
|
||||
"domains": [
|
||||
"geosite:cn"
|
||||
],
|
||||
"expectIP": [
|
||||
"geoip:cn"
|
||||
]
|
||||
}
|
||||
],
|
||||
"disableFallback": true,
|
||||
"disableFallbackIfMatch": true
|
||||
},
|
||||
"inbounds": [
|
||||
{
|
||||
"tag": "tproxy-in",
|
||||
"port": 12345,
|
||||
"protocol": "dokodemo-door",
|
||||
"settings": {
|
||||
"network": "tcp,udp",
|
||||
"followRedirect": true
|
||||
},
|
||||
"sniffing": {
|
||||
"enabled": true,
|
||||
"destOverride": [
|
||||
"http",
|
||||
"tls"
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"tproxy": "tproxy",
|
||||
"mark": 255
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"tag": "http",
|
||||
"port": 10808,
|
||||
"listen": "127.0.0.1",
|
||||
"protocol": "http",
|
||||
"sniffing": {
|
||||
"enabled": true,
|
||||
"destOverride": [
|
||||
"http",
|
||||
"tls"
|
||||
]
|
||||
}
|
||||
}
|
||||
],
|
||||
"outbounds": [
|
||||
{
|
||||
"tag": "nginxtls",
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"vnext": [
|
||||
{
|
||||
"address": "127.0.0.1",
|
||||
"port": 6666,
|
||||
"users": [
|
||||
{
|
||||
"id": "uuid",
|
||||
"encryption": "none"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"mark": 255
|
||||
},
|
||||
"network": "tcp"
|
||||
}
|
||||
},
|
||||
{
|
||||
"tag": "direct",
|
||||
"protocol": "freedom",
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"mark": 255
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"tag": "block",
|
||||
"protocol": "blackhole",
|
||||
"settings": {
|
||||
"response": {
|
||||
"type": "http"
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"routing": {
|
||||
"domainMatcher": "mph",
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
{
|
||||
"type": "field",
|
||||
"domain": [
|
||||
"geosite:category-ads-all"
|
||||
],
|
||||
"outboundTag": "block"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"port": 123,
|
||||
"network": "udp",
|
||||
"outboundTag": "direct"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"ip": [
|
||||
"1.1.1.1"
|
||||
],
|
||||
"outboundTag": "proxy"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"domain": [
|
||||
"geosite:cn"
|
||||
],
|
||||
"outboundTag": "direct"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"protocol": [
|
||||
"bittorrent"
|
||||
],
|
||||
"outboundTag": "direct"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"ip": [
|
||||
"geoip:private"
|
||||
],
|
||||
"outboundTag": "direct"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"inboundTag": [
|
||||
"tproxy-in"
|
||||
],
|
||||
"outboundTag": "nginxtls"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
При использовании прозрачного проксирования необходимо добавить следующие правила в конфигурацию iptables или ip6tables:
|
||||
|
||||
```
|
||||
# Настройка маршрутизации по политике для IPv4
|
||||
ip rule add fwmark 1 table 100
|
||||
ip route add local 0.0.0.0/0 dev lo table 100
|
||||
|
||||
# Настройка маршрутизации по политике для IPv6
|
||||
ip -6 rule add fwmark 1 table 106
|
||||
ip -6 route add local ::/0 dev lo table 106
|
||||
|
||||
# Прямое подключение для IP-адреса VPS
|
||||
iptables -t mangle -A XRAY_MASK -d VSP_IPv4/32 -j RETURN
|
||||
ip6tables -t mangle -A XRAY6_MASK -d VPS_IPv6/128 -j RETURN
|
||||
```
|
||||
|
||||
## Запуск сервисов на клиенте и сервере
|
||||
|
||||
`systemctl restart xray`
|
||||
|
||||
`systemctl restart nginx`
|
||||
|
||||
## Завершение
|
||||
|
||||
# Создание HTTPS-туннеля с помощью Haproxy на стороне клиента и сервера для скрытия отпечатков
|
||||
|
||||
Установка Haproxy:
|
||||
|
||||
`pacman -Su haproxy` или `apt install haproxy`
|
||||
|
||||
Haproxy требует OpenSSL для обработки SSL. Проверьте версию OpenSSL и при необходимости установите или обновите ее.
|
||||
|
||||
## HTTPS-туннель
|
||||
|
||||
Haproxy может легко реализовать HTTPS-туннель, как и описанный выше Nginx.
|
||||
|
||||
Сетевая структура:
|
||||
|
||||
xray_client ---tcp--- haproxy_client ---HTTPS--- haproxy_sever ---tcp--- xray_server
|
||||
|
||||
### Конфигурация haproxy_client (удалите комментарии перед запуском):
|
||||
|
||||
```
|
||||
global
|
||||
log /dev/log local0 alert
|
||||
log /dev/log local1 alert
|
||||
stats socket /dev/shm/admin.sock mode 660 level admin expose-fd listeners
|
||||
stats timeout 30s
|
||||
user root
|
||||
group root
|
||||
daemon
|
||||
|
||||
# Принудительное использование TLS 1.3 для туннеля
|
||||
ssl-default-server-options ssl-min-ver TLSv1.3
|
||||
|
||||
defaults
|
||||
log global
|
||||
mode tcp
|
||||
timeout connect 5s
|
||||
timeout client 300s
|
||||
timeout server 300s
|
||||
|
||||
frontend xray
|
||||
bind 127.0.0.1:6666 # Прослушивание порта 6666 на локальном хосте
|
||||
default_backend tunnel
|
||||
|
||||
backend tunnel
|
||||
server tunnel www.example.com:443 ssl verify none sni req.hdr(host) alpn h2,http/1.1
|
||||
# Можно использовать доменное имя или IP-адрес. При использовании доменного имени рекомендуется указать IP-адрес в файле hosts, чтобы сократить время разрешения имени.
|
||||
# alpn используется для согласования с сервером. Если на стороне сервера установлено alpn h2,http1.1, то клиент может указать h2 для подключения по HTTP/2 или http1.1 для подключения по HTTP.
|
||||
# Рекомендуется указывать h2 в обоих случаях.
|
||||
```
|
||||
|
||||
### Конфигурация haproxy_server (удалите комментарии перед запуском):
|
||||
|
||||
```
|
||||
global
|
||||
log /dev/log local0 alert
|
||||
log /dev/log local1 alert
|
||||
stats socket /dev/shm/admin.sock mode 660 level admin expose-fd listeners
|
||||
stats timeout 30s
|
||||
user root
|
||||
group root
|
||||
daemon
|
||||
|
||||
# Указание наборов шифров и минимальной версии SSL 1.2 для повышения безопасности
|
||||
ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256
|
||||
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
|
||||
ssl-default-bind-options ssl-min-ver TLSv1.2
|
||||
|
||||
defaults
|
||||
log global
|
||||
mode tcp
|
||||
timeout connect 5s
|
||||
timeout client 300s
|
||||
timeout server 300s
|
||||
|
||||
frontend tls-in
|
||||
bind :::443 ssl crt /path/to/pem alpn h2,http/1.1 # Haproxy использует pem для расшифровки SSL. Файл pem можно получить с помощью команды cat www.example.com.crt www.example.com.key > www.example.com.pem
|
||||
default_backend xray
|
||||
tcp-request inspect-delay 5s
|
||||
tcp-request content accept if HTTP
|
||||
use_backend web if HTTP
|
||||
|
||||
backend xray
|
||||
server xray /dev/shm/vless.sock # Поддерживаются абстрактные сокеты: "abns@vless.sock" и loopback: 127.0.0.1:6666
|
||||
|
||||
backend web
|
||||
server web /dev/shm/h1h2c.sock # Перенаправление на веб-сайт
|
||||
```
|
||||
|
||||
### Настройка Xray
|
||||
|
||||
Аналогично разделу Nginx: простейшая конфигурация TCP, совместимая с любым протоколом. Рекомендуется использовать VLESS+TCP без дополнительного шифрования. Обратитесь к документации или другим примерам.
|
||||
|
||||
## WebSocket over HTTP/2
|
||||
|
||||
Haproxy поддерживает h2c как для входящих, так и для исходящих подключений HTTP/2.
|
||||
|
||||
Однако в документации Xray по HTTP/2 говорится:
|
||||
|
||||
“В соответствии с рекомендациями по HTTP/2, клиент и сервер должны одновременно включать TLS для корректной работы этого метода передачи... В текущей версии HTTP/2 для входящих подключений (сервер) не требуется настройка TLS.”
|
||||
|
||||
То есть для входящих подключений можно использовать h2c, но для исходящих подключений h2c не поддерживается. Поэтому невозможно использовать схему xray_client ---h2c--- haproxy_client ---HTTP/2+TLS--- haproxy_sever ---h2c--- xray_server.
|
||||
|
||||
Однако можно обойти это ограничение, используя WebSocket. Haproxy поддерживает ws over HTTP/2.
|
||||
|
||||
Тогда сетевая структура будет выглядеть следующим образом: xray_client ---ws--- haproxy_client ---ws over HTTP/2 over HTTPS--- haproxy_sever ---ws--- xray_server.
|
||||
|
||||
### Конфигурация haproxy_client:
|
||||
|
||||
```
|
||||
global
|
||||
log /dev/log local0 alert
|
||||
log /dev/log local1 alert
|
||||
stats socket /dev/shm/admin.sock mode 660 level admin expose-fd listeners
|
||||
stats timeout 30s
|
||||
user root
|
||||
group root
|
||||
daemon
|
||||
|
||||
# Настройка производительности HTTP/2. Эти параметры можно изменять при возникновении проблем с производительностью HTTP/2.
|
||||
# Дополнительные настройки см. в разделе tune.h2 документации Haproxy: https://docs.haproxy.org/2.7/configuration.html
|
||||
tune.h2.initial-window-size 536870912 # Начальный размер окна, рекомендуется настроить, значение по умолчанию - 65536 байт.
|
||||
# При резком увеличении трафика может потребоваться время на загрузку, рекомендуется настраивать в зависимости от скорости интернета.
|
||||
tune.h2.max-concurrent-streams 512 # Количество одновременных потоков, можно настроить при необходимости, значение по умолчанию - 100.
|
||||
# Обычно не требуется изменять (не рекомендуется официальной документацией).
|
||||
|
||||
ssl-default-server-options ssl-min-ver TLSv1.3
|
||||
|
||||
defaults
|
||||
log global
|
||||
mode http
|
||||
timeout connect 5s
|
||||
timeout client 300s
|
||||
timeout server 300s
|
||||
|
||||
frontend xray
|
||||
bind 127.0.0.1:6666
|
||||
default_backend tunnel
|
||||
|
||||
backend tunnel
|
||||
server tunnel www.example.com:443 ssl verify none sni req.hdr(host) ws h2 alpn h2
|
||||
# ws over HTTP/2
|
||||
```
|
||||
|
||||
### Конфигурация haproxy_server:
|
||||
|
||||
```
|
||||
global
|
||||
log /dev/log local0 alert
|
||||
log /dev/log local1 alert
|
||||
stats socket /dev/shm/admin.sock mode 660 level admin expose-fd listeners
|
||||
stats timeout 30s
|
||||
user root
|
||||
group root
|
||||
daemon
|
||||
|
||||
# Настройка производительности HTTP/2 (необязательно, но рекомендуется).
|
||||
tune.h2.initial-window-size 536870912
|
||||
tune.h2.max-concurrent-streams 512
|
||||
|
||||
ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256
|
||||
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
|
||||
ssl-default-bind-options ssl-min-ver TLSv1.2
|
||||
|
||||
defaults
|
||||
log global
|
||||
mode http
|
||||
timeout connect 5s
|
||||
timeout client 300s
|
||||
timeout server 300s
|
||||
|
||||
frontend tls-in
|
||||
bind :::443 ssl crt /path/to/pem alpn h2,http/1.1
|
||||
use_backend xray if { ssl_fc_alpn -i h2 } { path_beg /tunnel }
|
||||
use_backend server1 if { ssl_fc_alpn -i h2 } { path_beg /path1 }
|
||||
use_backend server2 if { ssl_fc_alpn -i h2 } { path_beg /path2 }
|
||||
use_backend server3 if { ssl_fc_alpn -i h2 } { path_beg /path3 }
|
||||
default_backend web
|
||||
# Haproxy в режиме http может разделять трафик на основе пути.
|
||||
|
||||
backend xray
|
||||
server xray abns@vless.sock ws h1
|
||||
|
||||
backend server1
|
||||
server server1 abns@server1.sock ws h1
|
||||
|
||||
backend server2
|
||||
server server2 abns@server2.sock ws h1
|
||||
|
||||
backend server3
|
||||
server server3 abns@server3.sock ws h1
|
||||
|
||||
backend web
|
||||
server web /dev/shm/h1h2c.sock
|
||||
```
|
||||
|
||||
### Настройка Xray
|
||||
|
||||
Простая конфигурация WebSocket, TLS не требуется. Пример конфигурации см. в документации Xray.
|
||||
Параметр "path" можно использовать для разделения трафика на стороне сервера Haproxy (клиент также может разделять трафик с помощью Haproxy, принцип аналогичен, см. конфигурацию разделения трафика на стороне сервера).
|
||||
|
||||
## gRPC over HTTP/2
|
||||
|
||||
Хотя двусторонний h2c невозможен, gRPC не требует обязательного использования TLS.
|
||||
|
||||
Сетевая структура: xray_client ---gRPC h2c--- haproxy_client ---gRPC over HTTP/2 over HTTPS--- haproxy_sever ---gRPC h2c--- xray_server
|
||||
|
||||
### Конфигурация haproxy_client:
|
||||
|
||||
```
|
||||
global
|
||||
log /dev/log local0 alert
|
||||
log /dev/log local1 alert
|
||||
stats socket /dev/shm/admin.sock mode 660 level admin expose-fd listeners
|
||||
stats timeout 30s
|
||||
user root
|
||||
group root
|
||||
daemon
|
||||
|
||||
tune.h2.initial-window-size 536870912
|
||||
tune.h2.max-concurrent-streams 512
|
||||
|
||||
ssl-default-server-options ssl-min-ver TLSv1.3
|
||||
|
||||
defaults
|
||||
log global
|
||||
mode http
|
||||
timeout connect 5s
|
||||
timeout client 300s
|
||||
timeout server 300s
|
||||
|
||||
frontend xray
|
||||
bind 127.0.0.1:6666 proto h2 # Укажите proto h2 для использования h2c
|
||||
default_backend tunnel
|
||||
|
||||
backend tunnel
|
||||
server tunnel www.example.com:443 ssl verify none sni req.hdr(host) alpn h2
|
||||
```
|
||||
|
||||
### Конфигурация haproxy_server:
|
||||
|
||||
```
|
||||
global
|
||||
log /dev/log local0 alert
|
||||
log /dev/log local1 alert
|
||||
stats socket /dev/shm/admin.sock mode 660 level admin expose-fd listeners
|
||||
stats timeout 30s
|
||||
user root
|
||||
group root
|
||||
daemon
|
||||
|
||||
tune.h2.initial-window-size 536870912
|
||||
tune.h2.max-concurrent-streams 512
|
||||
|
||||
ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256
|
||||
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
|
||||
ssl-default-bind-options ssl-min-ver TLSv1.2
|
||||
|
||||
defaults
|
||||
log global
|
||||
mode http
|
||||
timeout connect 5s
|
||||
timeout client 300s
|
||||
timeout server 300s
|
||||
|
||||
frontend tls-in
|
||||
bind :::443 ssl crt /path/to/pem alpn h2,http/1.1
|
||||
use_backend xray if { ssl_fc_alpn -i h2 } { path_beg /tunnel } # "serviceName", настроенное в gRPC Xray, можно использовать для разделения трафика в Haproxy с помощью пути.
|
||||
# Для удобства использования "multiMode" используйте параметр path_beg для сопоставления пути.
|
||||
use_backend server1 if { ssl_fc_alpn -i h2 } { path_beg /path1 }
|
||||
use_backend server2 if { ssl_fc_alpn -i h2 } { path_beg /path2 }
|
||||
use_backend server3 if { ssl_fc_alpn -i h2 } { path_beg /path3 }
|
||||
default_backend web
|
||||
|
||||
backend xray
|
||||
server xray abns@vless.sock proto h2
|
||||
|
||||
backend server1
|
||||
server server1 abns@server1.sock proto h2
|
||||
|
||||
backend server2
|
||||
server server2 abns@server2.sock proto h2
|
||||
|
||||
backend server3
|
||||
server server3 abns@server3.sock proto h2
|
||||
|
||||
backend web
|
||||
server web /dev/shm/h1h2c.sock
|
||||
```
|
||||
|
||||
### Настройка Xray
|
||||
|
||||
Простая конфигурация gRPC, TLS не требуется. Конфигурация см. в документации.
|
||||
Параметр serviceName можно использовать для разделения трафика.
|
||||
|
||||
# Двусторонняя аутентификация Haproxy с использованием самозаверяющего сертификата (пример gRPC)
|
||||
|
||||
Здесь используется двусторонняя аутентификация по самозаверяющему сертификату для повышения безопасности туннеля (это немного увеличивает задержку, но с gRPC это не так заметно). Сервер обрабатывает как доверенные, так и самозаверяющие сертификаты и разделяет трафик на поддельный веб-сайт и туннель.
|
||||
|
||||
www.example.com - доменное имя поддельного веб-сайта с доверенным сертификатом (например, сертификат, полученный в соответствии с документацией).
|
||||
|
||||
tunnel.example.com - доменное имя с самозаверяющим сертификатом.
|
||||
Самозаверяющий сертификат можно создать, например, с помощью инструкции https://learn.microsoft.com/ru-ru/azure/application-gateway/self-signed-certificates.
|
||||
|
||||
Корневой сертификат: ca.crt, сертификат сервера: server.crt, ключ сервера: server.key.
|
||||
|
||||
Необходимо создать как минимум файл server.pem, который клиент может использовать для двусторонней аутентификации.
|
||||
Также можно создать два сертификата - client и server - для двусторонней аутентификации.
|
||||
|
||||
Необходимо подготовить файл fullchain.crt для аутентификации (cat server.crt ca.crt > fullchain.crt) и server.pem (cat server.crt server.key ca.crt > server.pem) для расшифровки.
|
||||
|
||||
### Конфигурация haproxy_client:
|
||||
|
||||
```
|
||||
global
|
||||
log /dev/log local0 alert
|
||||
log /dev/log local1 alert
|
||||
stats socket /dev/shm/admin.sock mode 660 level admin expose-fd listeners
|
||||
stats timeout 30s
|
||||
user root
|
||||
group root
|
||||
daemon
|
||||
|
||||
tune.h2.initial-window-size 536870912
|
||||
tune.h2.max-concurrent-streams 512
|
||||
|
||||
ssl-default-server-options ssl-min-ver TLSv1.3
|
||||
|
||||
defaults
|
||||
log global
|
||||
mode http
|
||||
timeout connect 5s
|
||||
timeout client 300s
|
||||
timeout server 300s
|
||||
|
||||
frontend xray
|
||||
bind 127.0.0.1:6666 proto h2
|
||||
default_backend tunnel
|
||||
|
||||
backend tunnel
|
||||
server tunnel tunnel.example.com:443 tfo allow-0rtt ssl crt /path/to/client.pem verify required ca-file /path/to/fullchain.crt sni str(tunnel.example.com) alpn h2
|
||||
# Доменное имя можно настроить произвольно, оно должно совпадать с самозаверяющим сертификатом.
|
||||
# Укажите IP-адрес в файле hosts.
|
||||
# Параметр str в sni устанавливает SNI, который используется сервером для идентификации.
|
||||
```
|
||||
|
||||
### Конфигурация haproxy_server:
|
||||
|
||||
```
|
||||
global
|
||||
log /dev/log local0 alert
|
||||
log /dev/log local1 alert
|
||||
stats socket /dev/shm/admin.sock mode 660 level admin expose-fd listeners
|
||||
stats timeout 30s
|
||||
user root
|
||||
group root
|
||||
daemon
|
||||
|
||||
tune.h2.initial-window-size 536870912
|
||||
tune.h2.max-concurrent-streams 512
|
||||
|
||||
ssl-default-bind-ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256
|
||||
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
|
||||
ssl-default-bind-options ssl-min-ver TLSv1.2
|
||||
|
||||
defaults
|
||||
log global
|
||||
mode http
|
||||
timeout connect 5s
|
||||
timeout client 300s
|
||||
timeout server 300s
|
||||
|
||||
frontend tls-in
|
||||
bind :::443 tfo allow-0rtt ssl crt /path/to/server.pem verify optional ca-file /path/to/fullchain.crt crt /path/to/www.example.com.pem alpn h2,http/1.1
|
||||
use_backend xray if { ssl_fc_sni tunnel.example.com } { ssl_c_used } { ssl_fc_alpn -i h2 } { path_beg /tunnel }
|
||||
use_backend server1 if { ssl_fc_sni atunnel.example.com } { ssl_c_used } { ssl_fc_alpn -i h2 } { path_beg /path2 }
|
||||
use_backend server2 if { ssl_fc_sni btunnel.example.com } { ssl_c_used } { ssl_fc_alpn -i h2 } { path_beg /path3 }
|
||||
use_backend server3 if { ssl_fc_sni ctunnel.example.com } { ssl_c_used } { ssl_fc_alpn -i h2 } { path_beg /path4 }
|
||||
default_backend web
|
||||
# Haproxy поддерживает несколько файлов pem для расшифровки.
|
||||
# Разделение трафика можно выполнять на основе SNI или пути, доступны различные способы.
|
||||
# Дополнительные сведения об ACL см. в документации Haproxy.
|
||||
|
||||
backend xray
|
||||
server xray abns@vless.sock proto h2
|
||||
|
||||
backend server1
|
||||
server server1 abns@server1.sock proto h2
|
||||
|
||||
backend server2
|
||||
server server2 abns@server2.sock proto h2
|
||||
|
||||
backend server3
|
||||
server server3 abns@server3.sock proto h2
|
||||
|
||||
backend web
|
||||
server web /dev/shm/h1h2c.sock
|
||||
```
|
||||
|
||||
### Настройка Xray
|
||||
|
||||
Простая конфигурация gRPC, TLS не требуется. Конфигурация см. в документации.
|
||||
Параметр serviceName можно использовать для разделения трафика.
|
||||
@@ -0,0 +1,246 @@
|
||||
---
|
||||
title: Перенаправление исходящего трафика
|
||||
---
|
||||
|
||||
# Перенаправление трафика на основе fwmark или sendThrough
|
||||
|
||||
Направление определенного трафика через определенный выходной узел с помощью Xray для реализации "разделения" глобальной маршрутизации
|
||||
|
||||
## Введение
|
||||
|
||||
Я видел много прокси-серверов или VPN, которые перехватывают весь трафик, что приводит к неработоспособности Xray, если он установлен одновременно с ними. Многие руководства, которые я находил, предлагали решать эту проблему путем разделения трафика на основе таблиц маршрутизации CIDR. Это не очень элегантно, и если я хочу иметь возможность гибко переключаться между маршрутами и реализовывать разделение трафика по требованию, то есть ли лучший способ? Да, есть!
|
||||
|
||||
С помощью fwmark или sendThrough/sockopt.interface в Xray и простой настройки таблицы маршрутизации можно добиться следующего:
|
||||
|
||||
1. Xray может направлять трафик с определенным тегом, доменным именем и т.д. через определенный интерфейс. Если ваш интерфейс поддерживает dual-stack, вы можете указать IPv4 или IPv6.
|
||||
2. Остальной трафик будет идти через исходный интерфейс IPv4 или IPv6.
|
||||
|
||||
Вот как это настроить (на примере Debian 10):
|
||||
|
||||
## 1. Установите прокси-сервер или VPN-клиент (например, Wireguard, IPsec и т.д.)
|
||||
|
||||
Обратитесь к официальной документации для получения инструкций по установке для вашей системы и программного обеспечения.
|
||||
|
||||
## 2. Отредактируйте конфигурационный файл VPN (на примере WireGuard)
|
||||
|
||||
Исходный файл:
|
||||
|
||||
```ini
|
||||
[Interface]
|
||||
PrivateKey = <PriKey>
|
||||
Address = <IPv4>
|
||||
Address = <IPv6>
|
||||
DNS = 8.8.8.8
|
||||
MTU = 1280
|
||||
[Peer]
|
||||
PublicKey = <Pubkey>
|
||||
AllowedIPs = ::/0
|
||||
AllowedIPs = 0.0.0.0/0
|
||||
Endpoint = <EndpointIP>:<Port>
|
||||
```
|
||||
|
||||
Добавьте следующие строки в раздел `[Interface]`:
|
||||
```ini
|
||||
Table = <table>
|
||||
### fwmark
|
||||
PostUP = ip rule add fwmark <mark> lookup <table>
|
||||
PostDown = ip rule del fwmark <mark> lookup <table>
|
||||
PostUP = ip -6 rule add fwmark <mark> lookup <table>
|
||||
PostDown = ip -6 rule del fwmark <mark> lookup <table>
|
||||
## sendThrough
|
||||
PreUp = ip rule add from <IPv4> lookup <table>
|
||||
PostDown = ip rule del from <IPv4> lookup <table>
|
||||
PreUp = ip -6 rule add from <IPv6> lookup <table>
|
||||
PostDown = ip -6 rule del from <IPv6> lookup <table>
|
||||
## sockopt.interface
|
||||
PreUp = ip rule add oif %i lookup <table>
|
||||
PostDown = ip rule del oif %i lookup <table>
|
||||
PreUp = ip -6 rule add oif %i lookup <table>
|
||||
PostDown = ip -6 rule del oif %i lookup <table>
|
||||
```
|
||||
::: tip
|
||||
- В этом конфигурационном файле объединены `fwmark`, `sendThrough` и `sockopt.interface`.
|
||||
- Подключения, поступающие на этот интерфейс `%i`, с этого IP-адреса `<IPv4/6>` или помеченные `fwmark` как `<mark>`,
|
||||
- будут перенаправлены через WireGuard.
|
||||
- `%i` - это заполнитель в конфигурационном файле WireGuard, который будет заменен на имя интерфейса во время запуска.
|
||||
:::
|
||||
|
||||
|
||||
Сохраните файл.
|
||||
|
||||
Рекомендуется установить:
|
||||
|
||||
::: warning
|
||||
Если вы используете поле `DNS` в разделе `[Interface]`, то эта программа будет обязательной.
|
||||
:::
|
||||
|
||||
```bash
|
||||
apt install openresolv
|
||||
```
|
||||
|
||||
## 3. Активируйте сетевой интерфейс WireGuard.
|
||||
|
||||
Загрузите модуль ядра:
|
||||
|
||||
```bash
|
||||
modprobe wireguard
|
||||
```
|
||||
|
||||
Проверьте, правильно ли загружен модуль WG:
|
||||
|
||||
```bash
|
||||
lsmod | grep wireguard
|
||||
```
|
||||
|
||||
## 4. Измените конфигурационный файл Xray-core.
|
||||
|
||||
```json
|
||||
{
|
||||
"api": {
|
||||
"services": [
|
||||
"HandlerService",
|
||||
"LoggerService",
|
||||
"StatsService"
|
||||
],
|
||||
"tag": "api"
|
||||
},
|
||||
"inbounds": [
|
||||
{
|
||||
"listen": "127.0.0.1",
|
||||
"port": <port>,
|
||||
"protocol": "dokodemo-door",
|
||||
"settings": {
|
||||
"address": "127.0.0.1"
|
||||
},
|
||||
"tag": "api"
|
||||
}
|
||||
],
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom",
|
||||
"settings": {
|
||||
"domainStrategy": "UseIPv4"
|
||||
}
|
||||
// Измените на UseIPv4 или UseIPv6 по вашему выбору
|
||||
},
|
||||
// <--Выберите один из вариантов--> Вариант 1: fwmark
|
||||
{
|
||||
"protocol": "freedom",
|
||||
"tag": "wg0",
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"mark": <mark>
|
||||
}
|
||||
},
|
||||
"settings": {
|
||||
"domainStrategy": "UseIPv6"
|
||||
}
|
||||
} // Трафик с меткой fwmark, равной <mark>, будет направлен через UseIPv6/UseIPv4.
|
||||
// <--Выберите один из вариантов--> Вариант 2: sendThrough
|
||||
{
|
||||
"tag": "wg0",
|
||||
"protocol": "freedom",
|
||||
"sendThrough": "your wg0 v4 address",
|
||||
// Измените на UseIPv4 или UseIPv6 по вашему выбору
|
||||
"settings": {
|
||||
"domainStrategy": "UseIPv4"
|
||||
}
|
||||
// Измените на UseIPv4 или UseIPv6 по вашему выбору
|
||||
},
|
||||
// <--Выберите один из вариантов--> Вариант 3: sockopt.interface
|
||||
{
|
||||
"tag": "wg0",
|
||||
"protocol": "freedom",
|
||||
"settings": {
|
||||
"domainStrategy": "UseIPv4"
|
||||
},
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"interface": "wg0"
|
||||
}
|
||||
}
|
||||
},
|
||||
// <--Выберите один из вариантов--> Конец
|
||||
{
|
||||
"protocol": "blackhole",
|
||||
"settings": {},
|
||||
"tag": "blocked"
|
||||
}
|
||||
],
|
||||
"policy": {
|
||||
"system": {
|
||||
"statsInboundDownlink": true,
|
||||
"statsInboundUplink": true
|
||||
}
|
||||
},
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"inboundTag": [
|
||||
"api"
|
||||
],
|
||||
"outboundTag": "api",
|
||||
"type": "field"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"outboundTag": "wg0",
|
||||
"inboundTag": [
|
||||
"<inboundTag>"
|
||||
// Укажите тег входящего подключения, определенный ранее в разделе inbound.
|
||||
// Здесь используется тег api, сгенерированный автоматически. Вы также можете добавить доменные имена и т.д.
|
||||
]
|
||||
},
|
||||
{
|
||||
"outboundTag": "blocked",
|
||||
"protocol": [
|
||||
"bittorrent"
|
||||
],
|
||||
"type": "field"
|
||||
}
|
||||
]
|
||||
},
|
||||
"stats": {}
|
||||
}
|
||||
```
|
||||
|
||||
::: tip
|
||||
Вы можете изменить "domainStrategy": "UseIPv6", чтобы управлять способом доступа для определенных пользователей.
|
||||
По моим тестам, этот параметр имеет более высокий приоритет, чем gai.config в системе.
|
||||
:::
|
||||
|
||||
## 5. Настройка системы
|
||||
|
||||
::: tip
|
||||
Необходимо включить ip_forward в системе:
|
||||
`sysctl -w net.ipv4.ip_forward=1`
|
||||
`sysctl -w net.ipv6.conf.all.forwarding=1`
|
||||
:::
|
||||
|
||||
## 6. Завершение настройки WireGuard
|
||||
|
||||
Запустите туннель:
|
||||
|
||||
```bash
|
||||
wg-quick up wg0
|
||||
```
|
||||
|
||||
Настройте автоматический запуск:
|
||||
|
||||
```bash
|
||||
systemctl enable wg-quick@wg0
|
||||
systemctl start wg-quick@wg0
|
||||
```
|
||||
|
||||
Проверьте IPv4/IPv6:
|
||||
|
||||
> На прокси-сервере выполните команду `curl ip-api.com -4/-6` / откройте в браузере сайт ip-api.com
|
||||
|
||||
## Послесловие
|
||||
|
||||
Цель этой статьи - показать, как избежать ненужных затрат трафика, переложив функции маршрутизации и разделения трафика на Xray. Это позволяет избежать утомительной работы по обслуживанию таблиц маршрутизации и повышает технический уровень.
|
||||
|
||||
## Благодарности
|
||||
|
||||
[XTLS/Xray-core](https://github.com/XTLS/Xray-core); [v2fly/v2ray-core](https://github.com/v2fly/v2ray-core); [WireGuard](https://www.wireguard.com/); [@p3terx](https://p3terx.com/); @w; @Hiram; @Luminous; @Ln; @JackChou;
|
||||
|
||||
@@ -0,0 +1,357 @@
|
||||
---
|
||||
title: Прозрачное проксирование TProxy
|
||||
---
|
||||
|
||||
# Руководство по настройке прозрачного проксирования (TProxy)
|
||||
|
||||
Эта конфигурация основана на [Новом руководстве по V2Ray на русском языке - Прозрачное проксирование (TPROXY)](https://guide.v2fly.org/app/tproxy.html) с добавлением новых функций Xray, использованием схемы VLESS + XTLS Vision и изменением режима разделения трафика с проксирования по умолчанию на прямое подключение по умолчанию. Пользователи должны настроить конфигурацию в соответствии со своими потребностями.
|
||||
|
||||
Все конфигурации, представленные в этой статье, были успешно протестированы в средах Raspberry Pi 2B и Ubuntu 20.04. При использовании в других средах вам может потребоваться изменить конфигурацию.
|
||||
|
||||
## Перед началом работы
|
||||
|
||||
Убедитесь, что на вашем устройстве есть доступное сетевое подключение, сервер настроен, а клиент установлен.
|
||||
|
||||
Обратите внимание, что многие руководства по настройке прозрачного проксирования предлагают включить переадресацию IP в системе Linux, но это может привести к снижению производительности Splice. Дополнительную информацию см. в статье [Расследование снижения производительности Splice до уровня ниже, чем Direct](https://github.com/XTLS/Xray-core/discussions/59).
|
||||
|
||||
Хочу добавить, что многие руководства по настройке прозрачного проксирования используют Netfilter для разделения трафика, отправляя прямой трафик напрямую, минуя Xray. В этом случае необходимо включить переадресацию IP.
|
||||
Другие руководства, например это, направляют весь трафик через Xray, где он разделяется модулем маршрутизации Xray. В этом случае переадресацию IP включать не нужно.
|
||||
|
||||
## Настройка Xray
|
||||
|
||||
Для лучшего разделения трафика замените файл правил маршрутизации по умолчанию на [Loyalsoldier/v2ray-rules-dat](https://github.com/Loyalsoldier/v2ray-rules-dat), иначе Xray-core не сможет загрузить эту конфигурацию.
|
||||
|
||||
```bash
|
||||
sudo curl -oL /usr/local/share/xray/geoip.dat https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geoip.dat
|
||||
sudo curl -oL /usr/local/share/xray/geosite.dat https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geosite.dat
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"log": {
|
||||
"loglevel": "warning",
|
||||
"error": "/var/log/xray/error.log",
|
||||
"access": "/var/log/xray/access.log"
|
||||
},
|
||||
"inbounds": [
|
||||
{
|
||||
"tag": "all-in",
|
||||
"port": 12345,
|
||||
"protocol": "dokodemo-door",
|
||||
"settings": {
|
||||
"network": "tcp,udp",
|
||||
"followRedirect": true
|
||||
},
|
||||
"sniffing": {
|
||||
"enabled": true,
|
||||
"destOverride": ["http", "tls"]
|
||||
},
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"tproxy": "tproxy"
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"outbounds": [
|
||||
{
|
||||
"tag": "direct",
|
||||
"protocol": "freedom",
|
||||
"settings": {
|
||||
"domainStrategy": "UseIPv4"
|
||||
},
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"mark": 2
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"tag": "proxy",
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"vnext": [
|
||||
{
|
||||
"address": "домен сервера",
|
||||
"port": 443,
|
||||
"users": [
|
||||
{
|
||||
"id": "UUID",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"encryption": "none"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
"network": "tcp",
|
||||
"security": "xtls",
|
||||
"sockopt": {
|
||||
"mark": 2
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"tag": "block",
|
||||
"protocol": "blackhole",
|
||||
"settings": {
|
||||
"response": {
|
||||
"type": "http"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"tag": "dns-out",
|
||||
"protocol": "dns",
|
||||
"settings": {
|
||||
"address": "8.8.8.8"
|
||||
},
|
||||
"proxySettings": {
|
||||
"tag": "proxy"
|
||||
},
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"mark": 2
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"dns": {
|
||||
"hosts": {
|
||||
"домен сервера": "IP-адрес сервера"
|
||||
},
|
||||
"servers": [
|
||||
{
|
||||
"address": "119.29.29.29",
|
||||
"port": 53,
|
||||
"domains": ["geosite:cn"],
|
||||
"expectIPs": ["geoip:cn"]
|
||||
},
|
||||
{
|
||||
"address": "223.5.5.5",
|
||||
"port": 53,
|
||||
"domains": ["geosite:cn"],
|
||||
"expectIPs": ["geoip:cn"]
|
||||
},
|
||||
"8.8.8.8",
|
||||
"1.1.1.1",
|
||||
"https+local://doh.dns.sb/dns-query"
|
||||
]
|
||||
},
|
||||
"routing": {
|
||||
"domainStrategy": "IPIfNonMatch",
|
||||
"rules": [
|
||||
{
|
||||
"type": "field",
|
||||
"inboundTag": ["all-in"],
|
||||
"port": 53,
|
||||
"outboundTag": "dns-out"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["8.8.8.8", "1.1.1.1"],
|
||||
"outboundTag": "proxy"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["geosite:category-ads-all"],
|
||||
"outboundTag": "block"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["geosite:geolocation-!cn"],
|
||||
"outboundTag": "proxy"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["geoip:telegram"],
|
||||
"outboundTag": "proxy"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
::: tip Совет
|
||||
Эта конфигурация перехватывает весь трафик, направляемый на порт 53, для решения проблемы загрязнения DNS, поэтому адрес DNS-сервера на клиенте и на самом устройстве можно настроить произвольно.
|
||||
:::
|
||||
|
||||
## Настройка маршрутизации по политике
|
||||
|
||||
```
|
||||
sudo ip route add local default dev lo table 100 # Добавить таблицу маршрутизации 100
|
||||
sudo ip rule add fwmark 1 table 100 # Добавить правило для таблицы маршрутизации 100
|
||||
```
|
||||
|
||||
## Настройка Netfilter
|
||||
|
||||
::: warning Внимание
|
||||
Выберите одну из следующих конфигураций: nftables или iptables. Не используйте обе одновременно.
|
||||
:::
|
||||
|
||||
<Tabs title="netfilter">
|
||||
|
||||
<Tab title="nftables1">
|
||||
|
||||
```nftables
|
||||
#!/usr/sbin/nft -f
|
||||
|
||||
flush ruleset
|
||||
|
||||
define RESERVED_IP = {
|
||||
10.0.0.0/8,
|
||||
100.64.0.0/10,
|
||||
127.0.0.0/8,
|
||||
169.254.0.0/16,
|
||||
172.16.0.0/12,
|
||||
192.0.0.0/24,
|
||||
224.0.0.0/4,
|
||||
240.0.0.0/4,
|
||||
255.255.255.255/32
|
||||
}
|
||||
|
||||
table ip xray {
|
||||
chain prerouting {
|
||||
type filter hook prerouting priority mangle; policy accept;
|
||||
ip daddr $RESERVED_IP return
|
||||
ip daddr 192.168.0.0/16 tcp dport != 53 return
|
||||
ip daddr 192.168.0.0/16 udp dport != 53 return
|
||||
ip protocol tcp tproxy to 127.0.0.1:12345 meta mark set 1
|
||||
ip protocol udp tproxy to 127.0.0.1:12345 meta mark set 1
|
||||
}
|
||||
chain output {
|
||||
type route hook output priority mangle; policy accept;
|
||||
ip daddr $RESERVED_IP return
|
||||
ip daddr 192.168.0.0/16 tcp dport != 53 return
|
||||
ip daddr 192.168.0.0/16 udp dport != 53 return
|
||||
meta mark 2 return
|
||||
ip protocol tcp meta mark set 1
|
||||
ip protocol udp meta mark set 1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
::: tip Использование
|
||||
|
||||
Запишите приведенную выше конфигурацию в файл (например, `nft.conf`), затем предоставьте файлу права на выполнение и выполните его от имени пользователя root ( `# ./nft.conf` ).
|
||||
:::
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab title="iptables1">
|
||||
|
||||
```bash
|
||||
iptables -t mangle -N XRAY
|
||||
iptables -t mangle -A XRAY -d 10.0.0.0/8 -j RETURN
|
||||
iptables -t mangle -A XRAY -d 100.64.0.0/10 -j RETURN
|
||||
iptables -t mangle -A XRAY -d 127.0.0.0/8 -j RETURN
|
||||
iptables -t mangle -A XRAY -d 169.254.0.0/16 -j RETURN
|
||||
iptables -t mangle -A XRAY -d 172.16.0.0/12 -j RETURN
|
||||
iptables -t mangle -A XRAY -d 192.0.0.0/24 -j RETURN
|
||||
iptables -t mangle -A XRAY -d 224.0.0.0/4 -j RETURN
|
||||
iptables -t mangle -A XRAY -d 240.0.0.0/4 -j RETURN
|
||||
iptables -t mangle -A XRAY -d 255.255.255.255/32 -j RETURN
|
||||
iptables -t mangle -A XRAY -d 192.168.0.0/16 -p tcp ! --dport 53 -j RETURN
|
||||
iptables -t mangle -A XRAY -d 192.168.0.0/16 -p udp ! --dport 53 -j RETURN
|
||||
iptables -t mangle -A XRAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
|
||||
iptables -t mangle -A XRAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 1
|
||||
iptables -t mangle -A PREROUTING -j XRAY
|
||||
|
||||
iptables -t mangle -N XRAY_SELF
|
||||
iptables -t mangle -A XRAY_SELF -d 10.0.0.0/8 -j RETURN
|
||||
iptables -t mangle -A XRAY_SELF -d 100.64.0.0/10 -j RETURN
|
||||
iptables -t mangle -A XRAY_SELF -d 127.0.0.0/8 -j RETURN
|
||||
iptables -t mangle -A XRAY_SELF -d 169.254.0.0/16 -j RETURN
|
||||
iptables -t mangle -A XRAY_SELF -d 172.16.0.0/12 -j RETURN
|
||||
iptables -t mangle -A XRAY_SELF -d 192.0.0.0/24 -j RETURN
|
||||
iptables -t mangle -A XRAY_SELF -d 224.0.0.0/4 -j RETURN
|
||||
iptables -t mangle -A XRAY_SELF -d 240.0.0.0/4 -j RETURN
|
||||
iptables -t mangle -A XRAY_SELF -d 255.255.255.255/32 -j RETURN
|
||||
iptables -t mangle -A XRAY_SELF -d 192.168.0.0/16 -p tcp ! --dport 53 -j RETURN
|
||||
iptables -t mangle -A XRAY_SELF -d 192.168.0.0/16 -p udp ! --dport 53 -j RETURN
|
||||
iptables -t mangle -A XRAY_SELF -m mark --mark 2 -j RETURN
|
||||
iptables -t mangle -A XRAY_SELF -p tcp -j MARK --set-mark 1
|
||||
iptables -t mangle -A XRAY_SELF -p udp -j MARK --set-mark 1
|
||||
iptables -t mangle -A OUTPUT -j XRAY_SELF
|
||||
```
|
||||
|
||||
</Tab>
|
||||
|
||||
</Tabs>
|
||||
|
||||
После завершения настройки измените шлюз по умолчанию на других устройствах в локальной сети на IP-адрес этого устройства, и они смогут использовать VPN. После того, как вы проверите, что все работает правильно на других хостах и на самом устройстве, перейдите к следующему шагу.
|
||||
|
||||
## Настройка автозагрузки и сохранения конфигурации
|
||||
|
||||
<br/>
|
||||
|
||||
<Tabs title="netfilter2">
|
||||
|
||||
<Tab title="nftables2">
|
||||
|
||||
Сначала переместите отредактированный файл конфигурации nftables в каталог `/etc` и переименуйте его в `nftables.conf`.
|
||||
Затем отредактируйте файл `/lib/systemd/system/nftables.service`.
|
||||
|
||||
```ini
|
||||
[Unit]
|
||||
Description=nftables
|
||||
Documentation=man:nft(8) http://wiki.nftables.org
|
||||
Wants=network-pre.target
|
||||
Before=network-pre.target shutdown.target
|
||||
Conflicts=shutdown.target
|
||||
DefaultDependencies=no
|
||||
|
||||
[Service]
|
||||
Type=oneshot
|
||||
RemainAfterExit=yes
|
||||
StandardInput=null
|
||||
ProtectSystem=full
|
||||
ProtectHome=true
|
||||
ExecStart=/usr/sbin/nft -f /etc/nftables.conf ; /usr/sbin/ip route add local default dev lo table 100 ; /usr/sbin/ip rule add fwmark 1 table 100
|
||||
ExecReload=/usr/sbin/nft -f /etc/nftables.conf
|
||||
ExecStop=/usr/sbin/nft flush ruleset ; /usr/sbin/ip route del local default dev lo table 100 ; /usr/sbin/ip rule del table 100
|
||||
|
||||
[Install]
|
||||
WantedBy=sysinit.target
|
||||
```
|
||||
|
||||
Наконец, выполните команду `systemctl enable nftables`.
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab title="iptables2">
|
||||
|
||||
Для сохранения конфигурации iptables рекомендуется установить пакет `iptables-persistent`.
|
||||
|
||||
Во время установки вам будет предложено сохранить конфигурацию.
|
||||
Если вы уже записали конфигурацию iptables в систему, выберите "Да".
|
||||
Если вы еще не записали конфигурацию, это не проблема. После установки запишите конфигурацию и выполните команду `netfilter-persistent save` (требуются права root).
|
||||
|
||||
Затем отредактируйте файл `/lib/systemd/system/netfilter-persistent.service`.
|
||||
|
||||
```ini
|
||||
[Unit]
|
||||
Description=netfilter persistent configuration
|
||||
DefaultDependencies=no
|
||||
Wants=network-pre.target systemd-modules-load.service local-fs.target
|
||||
Before=network-pre.target shutdown.target
|
||||
After=systemd-modules-load.service local-fs.target
|
||||
Conflicts=shutdown.target
|
||||
Documentation=man:netfilter-persistent(8)
|
||||
|
||||
[Service]
|
||||
Type=oneshot
|
||||
RemainAfterExit=yes
|
||||
ExecStart=/usr/sbin/netfilter-persistent start ; /usr/sbin/ip route add local default dev lo table 100 ; /usr/sbin/ip rule add fwmark 1 table 100
|
||||
ExecStop=/usr/sbin/netfilter-persistent stop ; /usr/sbin/ip route flush dev lo table 100 ; /usr/sbin/ip rule del table 100
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
</Tab>
|
||||
|
||||
</Tabs>
|
||||
|
||||
|
||||
@@ -0,0 +1,597 @@
|
||||
---
|
||||
title: Прозрачное проксирование TProxy (ipv4 и ipv6)
|
||||
---
|
||||
|
||||
# Руководство по настройке прозрачного проксирования TProxy (ipv4 и ipv6)
|
||||
|
||||
Эта конфигурация основана на [Новом руководстве по V2Ray на русском языке - Прозрачное проксирование (TPROXY)](https://guide.v2fly.org/app/tproxy.html), [Руководстве по настройке прозрачного проксирования (TProxy)](https://xtls.github.io/document/level-2/tproxy.html#%E5%BC%80%E5%A7%8B%E4%B9%8B%E5%89%8D) и [Прозрачное проксирование: Исключение трафика Xray с помощью GID](https://xtls.github.io/document/level-2/iptables_gid.html). Она включает поддержку IPv6 для прозрачного проксирования и использует схему VLESS-TCP-XTLS-RPRX-Vision для обхода блокировок (рекомендуется использовать версии 1.7.2 и выше).
|
||||
|
||||
Настройка Xray не является основной темой данной статьи. Пользователи могут изменять ее в соответствии со своими потребностями. Подробную информацию можно найти в [примерах официальной документации](https://github.com/XTLS/Xray-examples) или в других отличных примерах, таких как [@chika0801](https://github.com/chika0801/Xray-examples) и [@lxhao61](https://github.com/lxhao61/integrated-examples).
|
||||
|
||||
::: warning Внимание
|
||||
|
||||
При использовании других конфигураций обратите особое внимание на часть `outbound` с тегом `proxy` в конфигурации клиента. Остальные части остаются неизменными.
|
||||
|
||||
Конфигурация сервера также должна быть изменена соответственно.
|
||||
:::
|
||||
|
||||
Эта конфигурация предназначена для решения проблемы, когда такие сайты, как Netflix, которые по умолчанию используют IPv6, не могут быть проксированы через пограничный маршрутизатор, или когда требуется проксирование IPv6.
|
||||
|
||||
В данной статье используется сетевая структура с пограничным маршрутизатором с одним интерфейсом.
|
||||
|
||||
Все конфигурации, представленные в этой статье, были успешно протестированы в среде Arch Linux (Kernel: 6.0.10). В других средах настройка аналогична.
|
||||
|
||||
Убедитесь, что установлены необходимые программы: `# sudo apt install iptables ip6tables` или `# sudo apt install nftables`.
|
||||
|
||||
Если на пограничном маршрутизаторе не установлена программа Xray, можно вручную скачать соответствующую версию Xray, например [Xray-linux-64.zip](https://github.com/XTLS/Xray-core/releases/download/v1.7.0/Xray-linux-64.zip), а затем скопировать файл [install-release.sh](https://github.com/XTLS/Xray-install/blob/main/install-release.sh) на пограничный маршрутизатор. Предоставьте файлу права на выполнение `# chmod 700 install-release.sh` и запустите его с помощью команды `# ./install-release.sh --local Xray-linux-64.zip`. Следуйте инструкциям для локальной установки.
|
||||
|
||||
## Настройка Xray
|
||||
|
||||
### Конфигурация клиента
|
||||
|
||||
```json
|
||||
{
|
||||
"log": {
|
||||
"loglevel": "warning"
|
||||
},
|
||||
"inbounds": [
|
||||
{
|
||||
"tag": "all-in",
|
||||
"port": 12345,
|
||||
"protocol": "dokodemo-door",
|
||||
"settings": {
|
||||
"network": "tcp,udp",
|
||||
"followRedirect": true
|
||||
},
|
||||
"sniffing": {
|
||||
"enabled": true,
|
||||
"destOverride": ["http", "tls", "quic"]
|
||||
},
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"tproxy": "tproxy"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"port": 10808,
|
||||
"protocol": "socks",
|
||||
"sniffing": {
|
||||
"enabled": true,
|
||||
"destOverride": ["http", "tls", "quic"]
|
||||
},
|
||||
"settings": {
|
||||
"auth": "noauth",
|
||||
"udp": true
|
||||
}
|
||||
}
|
||||
],
|
||||
"outbounds": [
|
||||
{
|
||||
// Это исходящее подключение по умолчанию. Если модуль маршрутизации (routing) не найдет подходящего правила, трафик будет направлен через этот выходной узел proxy.
|
||||
// Если вы хотите, чтобы трафик в Китай направлялся напрямую, переместите исходящее подключение direct на первое место в списке outbound.
|
||||
// Если вы не понимаете, что это значит, просто пропустите этот комментарий.
|
||||
"tag": "proxy",
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"vnext": [
|
||||
{
|
||||
"address": "yourdomain.domain", // Замените на ваше доменное имя, также можно использовать IPv4- или IPv6-адрес.
|
||||
"port": 443,
|
||||
"users": [
|
||||
{
|
||||
"id": "uuid", // Введите UUID, который можно сгенерировать, выполнив команду xray uuid в терминале.
|
||||
// Также поддерживаются произвольные строки (https://xtls.github.io/config/inbounds/vless.html#clientobject).
|
||||
"encryption": "none",
|
||||
"flow": "xtls-rprx-vision"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"mark": 255
|
||||
},
|
||||
"network": "tcp",
|
||||
"security": "tls", // При использовании управления потоком xtls-rprx-vision здесь должно быть указано tls.
|
||||
"tlsSettings": {
|
||||
// При использовании управления потоком xtls-rprx-vision здесь должно быть указано tlsSettings.
|
||||
"allowInsecure": false,
|
||||
"serverName": "yourdomain.domain", // Замените на ваше доменное имя.
|
||||
"fingerprint": "chrome" // Рекомендуется сначала ознакомиться с разделом Release: https://github.com/XTLS/Xray-core/releases/tag/v1.7.3
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"tag": "direct",
|
||||
"protocol": "freedom",
|
||||
"settings": {
|
||||
"domainStrategy": "UseIP"
|
||||
},
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"mark": 255
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"tag": "block",
|
||||
"protocol": "blackhole",
|
||||
"settings": {
|
||||
"response": {
|
||||
"type": "http"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"tag": "dns-out",
|
||||
"protocol": "dns",
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"mark": 255
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"dns": {
|
||||
"hosts": {
|
||||
"domain:googleapis.cn": "googleapis.com",
|
||||
"dns.google": "8.8.8.8",
|
||||
"yourdomain.domain": "your VPS IP" // Если в разделе address исходящего подключения proxy указано доменное имя:
|
||||
// для проксирования через IPv4 укажите IPv4-адрес VPS, для проксирования через IPv6 укажите IPv6-адрес VPS.
|
||||
// Если в разделе address исходящего подключения proxy указан IP-адрес, эту строку можно удалить.
|
||||
},
|
||||
"servers": [
|
||||
"https://1.1.1.1/dns-query",
|
||||
{
|
||||
"address": "119.29.29.29",
|
||||
"domains": ["geosite:cn"],
|
||||
"expectIPs": ["geoip:cn"]
|
||||
},
|
||||
"https://dns.google/dns-query",
|
||||
"223.5.5.5",
|
||||
"localhost"
|
||||
]
|
||||
},
|
||||
"routing": {
|
||||
"domainMatcher": "mph",
|
||||
"domainStrategy": "IPIfNonMatch",
|
||||
"rules": [
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["geosite:category-ads-all"],
|
||||
"outboundTag": "block"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"inboundTag": ["all-in"],
|
||||
"port": 123,
|
||||
"network": "udp",
|
||||
"outboundTag": "direct"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"inboundTag": ["all-in"],
|
||||
"port": 53,
|
||||
"network": "udp",
|
||||
"outboundTag": "dns-out"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["119.29.29.29", "223.5.5.5"],
|
||||
"outboundTag": "direct"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"protocol": ["bittorrent"],
|
||||
"outboundTag": "direct"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["geoip:private", "geoip:cn"], // Здесь можно добавить IP-адрес VPS, чтобы избежать проксирования трафика SSH.
|
||||
"outboundTag": "direct"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["geosite:cn"],
|
||||
"outboundTag": "direct"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["1.1.1.1", "8.8.8.8"],
|
||||
"outboundTag": "proxy"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"domain": [
|
||||
"geosite:geolocation-!cn",
|
||||
"domain:googleapis.cn",
|
||||
"dns.google"
|
||||
],
|
||||
"outboundTag": "proxy"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Конфигурация сервера
|
||||
|
||||
```json
|
||||
{
|
||||
"log": {
|
||||
"loglevel": "warning"
|
||||
},
|
||||
"routing": {
|
||||
"domainStrategy": "IPIfNonMatch",
|
||||
"rules": [
|
||||
{
|
||||
// Блокировка китайских IP-адресов для повышения безопасности.
|
||||
// Также можно направить китайский трафик через Warp, см. https://xtls.github.io/document/level-2/warp.html
|
||||
"type": "field",
|
||||
"ip": ["geoip:cn"],
|
||||
"outboundTag": "block"
|
||||
}
|
||||
]
|
||||
},
|
||||
"inbounds": [
|
||||
{
|
||||
"port": 443,
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "uuid", // Должен совпадать с UUID клиента.
|
||||
"flow": "xtls-rprx-vision"
|
||||
}
|
||||
],
|
||||
"decryption": "none",
|
||||
"fallbacks": [
|
||||
{
|
||||
"dest": 8080 // Резервный порт. Требуется настройка веб-сервера, см. документацию. Можно не указывать.
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings": {
|
||||
"network": "tcp",
|
||||
"security": "tls",
|
||||
"tlsSettings": {
|
||||
"certificates": [
|
||||
{
|
||||
"certificateFile": "/etc/ssl/private/fullchain.crt",
|
||||
"keyFile": "/etc/ssl/private/crt.key" // Укажите пути к файлам fullchain.crt и cert.key, сгенерированным в соответствии с руководством (https://xtls.github.io/document/level-0/ch06-certificates.html#_6-4-%E6%AD%A3%E5%BC%8F%E8%AF%81%E4%B9%A6%E7%94%B3%E8%AF%B7).
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
"sniffing": {
|
||||
"enabled": true,
|
||||
"destOverride": ["http", "tls"]
|
||||
}
|
||||
}
|
||||
],
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom",
|
||||
"tag": "direct"
|
||||
},
|
||||
{
|
||||
"protocol": "blackhole",
|
||||
"tag": "block"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Настройка Netfilter
|
||||
|
||||
### Настройка маршрутизации по политике
|
||||
|
||||
```bash
|
||||
# Настройка маршрутизации по политике для IPv4
|
||||
ip rule add fwmark 1 table 100
|
||||
ip route add local 0.0.0.0/0 dev lo table 100
|
||||
|
||||
# Настройка маршрутизации по политике для IPv6
|
||||
ip -6 rule add fwmark 1 table 106
|
||||
ip -6 route add local ::/0 dev lo table 106
|
||||
|
||||
# Прямое подключение через основной маршрутизатор
|
||||
ip route add default via 192.168.31.1 # Укажите IPv4-адрес основного маршрутизатора.
|
||||
# Если используется метод 1 для настройки доступа к интернету на устройствах локальной сети, эту команду можно не выполнять.
|
||||
ip -6 route add default via fd00:6868:6868::1 # Укажите IPv6-адрес основного маршрутизатора.
|
||||
# Если используется метод 1 для настройки доступа к интернету на устройствах локальной сети, эту команду можно не выполнять.
|
||||
|
||||
```
|
||||
|
||||
::: tip Использование
|
||||
|
||||
Скопируйте команды в терминал пограничного маршрутизатора и выполните их.
|
||||
:::
|
||||
|
||||
::: tip О прямом подключении через основной маршрутизатор
|
||||
|
||||
Выполните команду `ip route show` на пограничном маршрутизаторе. Если используется метод 1, то после `default via` должен быть указан IP-адрес основного маршрутизатора, ничего менять не нужно.
|
||||
Если используется метод 2, то после `default via` должен быть указан IP-адрес пограничного маршрутизатора. В этом случае DNS-запросы для сайтов, к которым должно быть установлено прямое подключение, будут зацикливаться, что приведет к невозможности доступа к этим сайтам. Поэтому необходимо указать IP-адрес основного маршрутизатора.
|
||||
:::
|
||||
|
||||
Если в настройках маршрутизатора указан пограничный маршрутизатор в качестве шлюза по умолчанию (то есть используется метод 2 для настройки доступа к интернету на устройствах локальной сети), то необходимо выполнить команду `# Прямое подключение через основной маршрутизатор`.
|
||||
Кроме настройки через командную строку iproute2, можно использовать dhcpcd или systemctl-network для настройки статического IP-адреса.
|
||||
В качестве примера рассмотрим dhcpcd. Отредактируйте файл `/etc/dhcpcd.conf` и добавьте следующие строки в конец файла. Измените IP-адреса в соответствии с вашей конфигурацией.
|
||||
`interface` - это имя сетевого интерфейса или беспроводного устройства, которое можно узнать с помощью команды `# ip link show`.
|
||||
|
||||
```
|
||||
interface enp0s25
|
||||
static ip_address=192.168.31.100/24
|
||||
static ip6_address=fd00:6868:6868::8888/64
|
||||
static routers=192.168.31.1
|
||||
static domain_name_servers=192.168.31.1 fd00:6868:6868::1
|
||||
```
|
||||
|
||||
После настройки статического IP-адреса и шлюза вам не нужно будет выполнять команду `# Прямое подключение через основной маршрутизатор` при каждой загрузке.
|
||||
|
||||
::: warning Внимание
|
||||
|
||||
Выберите одну из следующих конфигураций: nftables или iptables. Не используйте обе одновременно.
|
||||
:::
|
||||
|
||||
### Использование iptables
|
||||
|
||||
В этой конфигурации IPv4 и IPv6 объединены в одном файле.
|
||||
|
||||
```bash
|
||||
# Проксирование устройств локальной сети (IPv4)
|
||||
iptables -t mangle -N XRAY
|
||||
iptables -t mangle -A XRAY -d 127.0.0.1/32 -j RETURN
|
||||
iptables -t mangle -A XRAY -d 224.0.0.0/4 -j RETURN
|
||||
iptables -t mangle -A XRAY -d 255.255.255.255/32 -j RETURN
|
||||
iptables -t mangle -A XRAY -d 192.168.0.0/16 -p tcp -j RETURN
|
||||
iptables -t mangle -A XRAY -d 192.168.0.0/16 -p udp ! --dport 53 -j RETURN
|
||||
iptables -t mangle -A XRAY -j RETURN -m mark --mark 0xff
|
||||
iptables -t mangle -A XRAY -p udp -j TPROXY --on-ip 127.0.0.1 --on-port 12345 --tproxy-mark 1
|
||||
iptables -t mangle -A XRAY -p tcp -j TPROXY --on-ip 127.0.0.1 --on-port 12345 --tproxy-mark 1
|
||||
iptables -t mangle -A PREROUTING -j XRAY
|
||||
|
||||
# Проксирование устройств локальной сети (IPv6)
|
||||
ip6tables -t mangle -N XRAY6
|
||||
ip6tables -t mangle -A XRAY6 -d ::1/128 -j RETURN
|
||||
ip6tables -t mangle -A XRAY6 -d fe80::/10 -j RETURN
|
||||
ip6tables -t mangle -A XRAY6 -d fd00::/8 -p tcp -j RETURN
|
||||
ip6tables -t mangle -A XRAY6 -d fd00::/8 -p udp ! --dport 53 -j RETURN
|
||||
ip6tables -t mangle -A XRAY6 -j RETURN -m mark --mark 0xff
|
||||
ip6tables -t mangle -A XRAY6 -p udp -j TPROXY --on-ip ::1 --on-port 12345 --tproxy-mark 1
|
||||
ip6tables -t mangle -A XRAY6 -p tcp -j TPROXY --on-ip ::1 --on-port 12345 --tproxy-mark 1
|
||||
ip6tables -t mangle -A PREROUTING -j XRAY6
|
||||
|
||||
# Проксирование хоста шлюза (IPv4)
|
||||
iptables -t mangle -N XRAY_MASK
|
||||
iptables -t mangle -A XRAY_MASK -d 224.0.0.0/4 -j RETURN
|
||||
iptables -t mangle -A XRAY_MASK -d 255.255.255.255/32 -j RETURN
|
||||
iptables -t mangle -A XRAY_MASK -d 192.168.0.0/16 -p tcp -j RETURN
|
||||
iptables -t mangle -A XRAY_MASK -d 192.168.0.0/16 -p udp ! --dport 53 -j RETURN
|
||||
iptables -t mangle -A XRAY_MASK -j RETURN -m mark --mark 0xff
|
||||
iptables -t mangle -A XRAY_MASK -p udp -j MARK --set-mark 1
|
||||
iptables -t mangle -A XRAY_MASK -p tcp -j MARK --set-mark 1
|
||||
iptables -t mangle -A OUTPUT -j XRAY_MASK
|
||||
|
||||
# Проксирование хоста шлюза (IPv6)
|
||||
ip6tables -t mangle -N XRAY6_MASK
|
||||
ip6tables -t mangle -A XRAY6_MASK -d fe80::/10 -j RETURN
|
||||
ip6tables -t mangle -A XRAY6_MASK -d fd00::/8 -p tcp -j RETURN
|
||||
ip6tables -t mangle -A XRAY6_MASK -d fd00::/8 -p udp ! --dport 53 -j RETURN
|
||||
ip6tables -t mangle -A XRAY6_MASK -j RETURN -m mark --mark 0xff
|
||||
ip6tables -t mangle -A XRAY6_MASK -p udp -j MARK --set-mark 1
|
||||
ip6tables -t mangle -A XRAY6_MASK -p tcp -j MARK --set-mark 1
|
||||
ip6tables -t mangle -A OUTPUT -j XRAY6_MASK
|
||||
|
||||
# Создание правила DIVERT, чтобы избежать повторного прохождения пакетов с существующими подключениями через TPROXY, что теоретически повышает производительность (IPv4)
|
||||
iptables -t mangle -N DIVERT
|
||||
iptables -t mangle -A DIVERT -j MARK --set-mark 1
|
||||
iptables -t mangle -A DIVERT -j ACCEPT
|
||||
iptables -t mangle -I PREROUTING -p tcp -m socket -j DIVERT
|
||||
|
||||
# Создание правила DIVERT, чтобы избежать повторного прохождения пакетов с существующими подключениями через TPROXY, что теоретически повышает производительность (IPv6)
|
||||
ip6tables -t mangle -N DIVERT
|
||||
ip6tables -t mangle -A DIVERT -j MARK --set-mark 1
|
||||
ip6tables -t mangle -A DIVERT -j ACCEPT
|
||||
ip6tables -t mangle -I PREROUTING -p tcp -m socket -j DIVERT
|
||||
|
||||
```
|
||||
|
||||
::: tip Использование
|
||||
|
||||
Запишите приведенную выше конфигурацию в файл (например, `iptables.rules`), затем предоставьте файлу права на выполнение `# chmod 700 ./iptables.rules`.
|
||||
|
||||
Наконец, выполните файл от имени пользователя root: `# ./iptables.rules` или `# source iptables.rules`.
|
||||
:::
|
||||
|
||||
### Использование nftables
|
||||
|
||||
В этой конфигурации IPv4 и IPv6 объединены.
|
||||
|
||||
```
|
||||
#!/usr/sbin/nft -f
|
||||
|
||||
flush ruleset
|
||||
|
||||
table inet xray {
|
||||
chain prerouting {
|
||||
type filter hook prerouting priority filter; policy accept;
|
||||
ip daddr { 127.0.0.0/8, 224.0.0.0/4, 255.255.255.255 } return
|
||||
meta l4proto tcp ip daddr 192.168.0.0/16 return
|
||||
ip daddr 192.168.0.0/16 udp dport != 53 return
|
||||
ip6 daddr { ::1, fe80::/10 } return
|
||||
meta l4proto tcp ip6 daddr fd00::/8 return
|
||||
ip6 daddr fd00::/8 udp dport != 53 return
|
||||
meta mark 0x000000ff return
|
||||
meta l4proto { tcp, udp } meta mark set 0x00000001 tproxy ip to 127.0.0.1:12345 accept
|
||||
meta l4proto { tcp, udp } meta mark set 0x00000001 tproxy ip6 to [::1]:12345 accept
|
||||
}
|
||||
|
||||
chain output {
|
||||
type route hook output priority filter; policy accept;
|
||||
ip daddr { 127.0.0.0/8, 224.0.0.0/4, 255.255.255.255 } return
|
||||
meta l4proto tcp ip daddr 192.168.0.0/16 return
|
||||
ip daddr 192.168.0.0/16 udp dport != 53 return
|
||||
ip6 daddr { ::1, fe80::/10 } return
|
||||
meta l4proto tcp ip6 daddr fd00::/8 return
|
||||
ip6 daddr fd00::/8 udp dport != 53 return
|
||||
meta mark 0x000000ff return
|
||||
meta l4proto { tcp, udp } meta mark set 0x00000001 accept
|
||||
}
|
||||
|
||||
chain divert {
|
||||
type filter hook prerouting priority mangle; policy accept;
|
||||
meta l4proto tcp socket transparent 1 meta mark set 0x00000001 accept
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
::: tip Использование
|
||||
|
||||
Запишите приведенную выше конфигурацию в файл (например, `nftables.rules`), затем предоставьте файлу права на выполнение `# chmod 700 ./nftables.rules`.
|
||||
|
||||
Наконец, выполните файл от имени пользователя root: `# ./nftables.rules` или `# source nftables.rules`.
|
||||
:::
|
||||
|
||||
Адреса шлюза `192.168.0.0/16`, `fd00::/8` и т.д. можно получить с помощью команд `ip address | grep -w inet | awk '{print $2}'` и `ip address | grep -w inet6 | awk '{print $2}'` [ссылка](https://xtls.github.io/document/level-2/iptables_gid.html#_4-%E8%AE%BE%E7%BD%AE-iptables-%E8%A7%84%E5%88%99).
|
||||
|
||||
Или посмотреть в настройках сети Windows.
|
||||
|
||||
Или посмотреть в настройках интернета на маршрутизаторе.
|
||||
|
||||
Если префиксы `192.168`, `fd00:` совпадают, их можно не менять.
|
||||
Если они отличаются, например, `fc00:`, `fe00:` и т.д., замените их на соответствующие значения.
|
||||
Синтаксис можно найти в Google, например, `fc00::/7`, `fe00::/9`.
|
||||
|
||||
### Автоматический запуск конфигурации Netfilter при загрузке
|
||||
|
||||
Сначала убедитесь, что вы выполнили соответствующие команды Netfilter, описанные выше, и успешно протестировали настройку прозрачного проксирования, чтобы убедиться, что в дальнейшем будет сгенерирован правильный файл.
|
||||
|
||||
#### При использовании конфигурации iptables
|
||||
|
||||
1. Сохраните конфигурацию iptables в файлы `iptables.rulesv4` и `iptables.rulesv6` с помощью команд `# iptables-save > /root/iptables.rulesv4` и `# ip6tables-save > /root/iptables.rulesv6`.
|
||||
|
||||
2. Создайте файл с именем `tproxyrules.service` в каталоге `/etc/systemd/system/` и добавьте следующее содержимое:
|
||||
|
||||
```
|
||||
[Unit]
|
||||
Description=Tproxy rules
|
||||
|
||||
[Service]
|
||||
Type=oneshot
|
||||
RemainAfterExit=yes
|
||||
ExecStartPre=/bin/sh -c 'until ping -c1 192.168.31.1; do sleep 1; done;'
|
||||
ExecStart=/sbin/ip rule add fwmark 1 table 100 ; \
|
||||
/sbin/ip -6 rule add fwmark 1 table 106 ; \
|
||||
/sbin/ip route add local 0.0.0.0/0 dev lo table 100 ; \
|
||||
/sbin/ip -6 route add local ::/0 dev lo table 106 ; \
|
||||
/sbin/ip route add default via 192.168.31.1 ; \
|
||||
/sbin/ip -6 route add default via fd00:6868:6868::1 ; \
|
||||
/sbin/iptables-restore /root/iptables.rulesv4 ; \
|
||||
/sbin/ip6tables-restore /root/iptables.rulesv6
|
||||
ExecStop=/sbin/ip rule del fwmark 1 table 100 ; \
|
||||
/sbin/ip -6 rule del fwmark 1 table 106 ; \
|
||||
/sbin/ip route del local 0.0.0.0/0 dev lo table 100 ; \
|
||||
/sbin/ip -6 route del local ::/0 dev lo table 106 ; \
|
||||
/sbin/ip route del default via 192.168.31.1 ; \
|
||||
/sbin/ip -6 route del default via fd00:6868:6868::1 ; \
|
||||
/sbin/iptables -t mangle -F ; \
|
||||
/sbin/ip6tables -t mangle -F
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
3. Выполните команду `systemctl enable tproxyrules`.
|
||||
|
||||
#### При использовании конфигурации nftables
|
||||
|
||||
1. Сохраните конфигурацию nftables в файл `nftables.rulesv46` с помощью команды `# nft list ruleset > /root/nftables.rulesv46`.
|
||||
|
||||
2. Создайте файл с именем `tproxyrules.service` в каталоге `/etc/systemd/system/` и добавьте следующее содержимое:
|
||||
|
||||
```
|
||||
[Unit]
|
||||
Description=Tproxy rules
|
||||
|
||||
[Service]
|
||||
Type=oneshot
|
||||
RemainAfterExit=yes
|
||||
ExecStartPre=/bin/sh -c 'until ping -c1 192.168.31.1; do sleep 1; done;'
|
||||
ExecStart=/sbin/ip rule add fwmark 1 table 100 ; \
|
||||
/sbin/ip -6 rule add fwmark 1 table 106 ; \
|
||||
/sbin/ip route add local 0.0.0.0/0 dev lo table 100 ; \
|
||||
/sbin/ip -6 route add local ::/0 dev lo table 106 ; \
|
||||
/sbin/ip route add default via 192.168.31.1 ; \
|
||||
/sbin/ip -6 route add default via fd00:6868:6868::1 ; \
|
||||
/sbin/nft -f /root/nftables.rulesv46 ;
|
||||
ExecStop=/sbin/ip rule del fwmark 1 table 100 ; \
|
||||
/sbin/ip -6 rule del fwmark 1 table 106 ; \
|
||||
/sbin/ip route del local 0.0.0.0/0 dev lo table 100 ; \
|
||||
/sbin/ip -6 route del local ::/0 dev lo table 106 ; \
|
||||
/sbin/ip route del default via 192.168.31.1 ; \
|
||||
/sbin/ip -6 route del default via fd00:6868:6868::1 ; \
|
||||
/sbin/nft flush ruleset
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
3. Выполните команду `systemctl enable tproxyrules`.
|
||||
|
||||
::: tip tproxyrules.service
|
||||
|
||||
Обратите внимание на IP-адрес основного маршрутизатора и измените его в соответствии с вашей конфигурацией.
|
||||
|
||||
Команда `ExecStartPre=/bin/sh -c 'until ping -c1 192.168.31.1; do sleep 1; done;'` гарантирует, что команды будут выполнены только после получения IP-адреса, иначе могут возникнуть странные ошибки. IP-адрес - это адрес основного маршрутизатора, измените его в соответствии с вашей конфигурацией.
|
||||
:::
|
||||
|
||||
::: warning Внимание
|
||||
|
||||
Если вы настроили статический IP-адрес и шлюз с помощью dhcpcd и т.д., удалите соответствующие строки `ip route add/del` из приведенных выше конфигураций.
|
||||
:::
|
||||
|
||||
## Настройка доступа к интернету на устройствах локальной сети
|
||||
|
||||
Предположим, что IPv4- и IPv6-адреса пограничного маршрутизатора - `192.168.31.100` и `fd00:6868:6868::8866` соответственно.
|
||||
IP-адреса пограничного маршрутизатора можно узнать с помощью команды `ip add`.
|
||||
|
||||
### Метод 1
|
||||
|
||||
Есть два способа настроить доступ к интернету на устройствах локальной сети.
|
||||
Первый способ - настроить статический IP-адрес на каждом устройстве и указать IP-адрес пограничного маршрутизатора в качестве шлюза.
|
||||
Обратите внимание, что большинство мобильных устройств поддерживают только ручную настройку IPv4-шлюза и не поддерживают ручную настройку IPv6-шлюза, если не получены root-права и не выполнены соответствующие настройки.
|
||||
|
||||
В качестве примера рассмотрим устройство Windows.
|
||||
Можно сначала включить DHCP и записать автоматически назначенный IP-адрес для справки, а затем вручную настроить статический IP-адрес.
|
||||
|
||||
::: tip Настройка DNS
|
||||
|
||||
В этой конфигурации перехватывается DNS-трафик, поэтому DNS можно указать произвольно.
|
||||
|
||||
Рекомендуется указать IP-адрес пограничного маршрутизатора, чтобы избежать утечки DNS.
|
||||
:::
|
||||
|
||||
<img width="231" alt="image" src="https://user-images.githubusercontent.com/110686480/208310266-632e36b9-a23b-4b90-aa28-583b50e87c66.png"> <img width="238" alt="image" src="https://user-images.githubusercontent.com/110686480/208309659-e3172218-ef27-4a94-a017-225f8e05b611.png">
|
||||
|
||||
### Метод 2
|
||||
|
||||
Второй способ настроить доступ к интернету на устройствах локальной сети - указать пограничный маршрутизатор в качестве шлюза в настройках маршрутизатора.
|
||||
Этот метод не требует настройки на каждом устройстве, подключенном к маршрутизатору, но обратите внимание, что некоторые маршрутизаторы не поддерживают настройку IPv6-шлюза, поэтому устройствам, которым требуется IPv6, необходимо вручную настроить IPv6 в соответствии с методом 1.
|
||||
|
||||
<img width="700" alt="image" src="https://user-images.githubusercontent.com/110686480/208310174-2245a890-eb6b-4341-899f-81c6ac8255ff.png">
|
||||
|
||||
## Результаты
|
||||
|
||||
После настройки в соответствии с вышеуказанными инструкциями устройства смогут получать доступ к интернету по IPv4 и IPv6.
|
||||
На тестовом сайте, например https://ipv6-test.com/, вы увидите следующие результаты (сайт должен быть проксирован, чтобы увидеть эти результаты):
|
||||
|
||||
<img width="700" alt="image" src="https://user-images.githubusercontent.com/110686480/208743723-f8a2751b-43d0-4353-9383-5ae0e00e9449.png">
|
||||
|
||||
## Заключение
|
||||
|
||||
В настоящее время IPv6 еще не получил широкого распространения, и 99% трафика, к которому мы обращаемся, по-прежнему приходится на IPv4.
|
||||
Многие провайдеры VPS
|
||||
@@ -0,0 +1,122 @@
|
||||
---
|
||||
title: Статистика трафика
|
||||
---
|
||||
|
||||
# Руководство по настройке статистики трафика
|
||||
|
||||
Ознакомьтесь с [руководством по статистике трафика](https://guide.v2fly.org/advanced/traffic.html).
|
||||
Эта статья адаптирует его для Xray (1.5.9+).
|
||||
|
||||
## Просмотр статистики трафика
|
||||
|
||||
Способ настройки такой же, как и для v2fly.
|
||||
Просмотр статистики трафика - одна из функций командной строки Xray. Порт api dokodemo-door, указанный в конфигурации, - это порт, используемый в параметре `--server`.
|
||||
|
||||
```bash
|
||||
xray api statsquery --server=127.0.0.1:10085 # Просмотр всей статистики трафика
|
||||
xray help api statsquery # statsquery - запрос соответствующих записей
|
||||
xray help api stats # stats - запрос одной записи
|
||||
```
|
||||
|
||||
Пример вывода:
|
||||
|
||||
```json
|
||||
{
|
||||
"stat": [
|
||||
{
|
||||
"name": "inbound>>>vmess-quic>>>traffic>>>downlink",
|
||||
"value": "1176"
|
||||
},
|
||||
{
|
||||
"name": "user>>>love@example.com>>>traffic>>>downlink",
|
||||
"value": "2040"
|
||||
},
|
||||
{
|
||||
"name": "inbound>>>api>>>traffic>>>uplink",
|
||||
"value": "14247"
|
||||
},
|
||||
{
|
||||
"name": "user>>>love@example.com>>>traffic>>>uplink",
|
||||
"value": "2520"
|
||||
},
|
||||
{
|
||||
"name": "inbound>>>api>>>traffic>>>downlink",
|
||||
"value": "87618"
|
||||
},
|
||||
{
|
||||
"name": "outbound>>>direct>>>traffic>>>downlink",
|
||||
"value": "0"
|
||||
},
|
||||
{
|
||||
"name": "inbound>>>vmess-quic>>>traffic>>>uplink",
|
||||
"value": "1691"
|
||||
},
|
||||
{
|
||||
"name": "outbound>>>direct>>>traffic>>>uplink",
|
||||
"value": "0"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Обработка статистики трафика
|
||||
|
||||
Сохраните следующий скрипт в файл `traffic.sh` и предоставьте ему права на выполнение с помощью команды `chmod 755 traffic.sh`.
|
||||
Не забудьте изменить строку `_APISERVER`, указав правильный порт.
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
_APISERVER=127.0.0.1:10085
|
||||
_XRAY=/usr/local/bin/xray
|
||||
|
||||
apidata () {
|
||||
local ARGS=
|
||||
if [[ $1 == "reset" ]]; then
|
||||
ARGS="-reset=true"
|
||||
fi
|
||||
$_XRAY api statsquery --server=$_APISERVER "${ARGS}" \
|
||||
| awk '{
|
||||
if (match($1, /"name":/)) {
|
||||
f=1; gsub(/^"|link"|,$/, "", $2);
|
||||
split($2, p, ">>>");
|
||||
printf "%s:%s->%s\t", p[1],p[2],p[4];
|
||||
}
|
||||
else if (match($1, /"value":/) && f){
|
||||
f = 0;
|
||||
gsub(/"/, "", $2);
|
||||
printf "%.0f\n", $2;
|
||||
}
|
||||
else if (match($0, /}/) && f) { f = 0; print 0; }
|
||||
}'
|
||||
}
|
||||
|
||||
print_sum() {
|
||||
local DATA="$1"
|
||||
local PREFIX="$2"
|
||||
local SORTED=$(echo "$DATA" | grep "^${PREFIX}" | sort -r)
|
||||
local SUM=$(echo "$SORTED" | awk '
|
||||
/->up/{us+=$2}
|
||||
/->down/{ds+=$2}
|
||||
END{
|
||||
printf "SUM->up:\t%.0f\nSUM->down:\t%.0f\nSUM->TOTAL:\t%.0f\n", us, ds, us+ds;
|
||||
}')
|
||||
echo -e "${SORTED}\n${SUM}" \
|
||||
| numfmt --field=2 --suffix=B --to=iec \
|
||||
| column -t
|
||||
}
|
||||
|
||||
DATA=$(apidata $1)
|
||||
echo "------------Inbound----------"
|
||||
print_sum "$DATA" "inbound"
|
||||
echo "-----------------------------"
|
||||
echo "------------Outbound----------"
|
||||
print_sum "$DATA" "outbound"
|
||||
echo "-----------------------------"
|
||||
echo
|
||||
echo "-------------User------------"
|
||||
print_sum "$DATA" "user"
|
||||
echo "-----------------------------"
|
||||
```
|
||||
|
||||
|
||||
|
After Width: | Height: | Size: 32 KiB |
@@ -0,0 +1,281 @@
|
||||
## Погружение в прозрачное проксирование
|
||||
|
||||
### Что такое прозрачное проксирование?
|
||||
|
||||
Проще говоря, прозрачное проксирование не позволяет проксируемому устройству понять, что оно проксируется. Это означает, что на проксируемом устройстве не нужно запускать какое-либо программное обеспечение для проксирования (например, Xray, V2RayNG и т. д.). Когда вы подключаетесь к сети, ваше устройство уже проксируется.
|
||||
|
||||
Это также означает, что программное обеспечение прокси работает в другом месте, например, на маршрутизаторе, и устройства, подключенные к Интернету через маршрутизатор, автоматически проксируются.
|
||||
|
||||
### Реализация прозрачного проксирования
|
||||
|
||||
В настоящее время существует два основных способа реализации прозрачного проксирования:
|
||||
|
||||
### tun2socks
|
||||
|
||||
Доступно для Windows/Linux (включая Android). Поскольку процесс реализации относительно прост, существует не так много руководств, поэтому я кратко опишу его здесь.
|
||||
|
||||
**Windows**
|
||||
|
||||
1. Установите **[Netch](https://github.com/NetchX/Netch/releases)**, используя режим `[3] [TUN/TAP] Обход локальной сети` для запуска.
|
||||
|
||||
2. Включите точку доступа.
|
||||
|
||||
3. Откройте `Панель управления` -> `Сеть и Интернет` -> `Центр управления сетями и общим доступом` -> `Изменение параметров адаптера`, найдите `TAP-Windows Adapter` и `Microsoft Wi-Fi Direct Virtual Adapter`.
|
||||
|
||||
4. Щелкните правой кнопкой мыши `TAP-Windows Adapter`, `Свойства` -> `Доступ`, установите флажок `Разрешить другим пользователям сети подключаться к Интернету через это подключение к Интернету`, в `Домашнее сетевое подключение` выберите сетевое подключение `Microsoft Wi-Fi Direct Virtual Adapter`, нажмите `ОК`.
|
||||
|
||||
**Android**
|
||||
|
||||
1. Настройте подключение V2RayNG.
|
||||
|
||||
2. Включите точку доступа.
|
||||
|
||||
3. Настройки точки доступа -> Разрешить использование VPN для точки доступа (эта опция может отсутствовать в некоторых системах Android).
|
||||
|
||||
### iptables/nftables
|
||||
|
||||
iptables и nftables реализуют прозрачное проксирование по одному и тому же принципу, в дальнейшем мы будем использовать iptables.
|
||||
|
||||
Реализация прозрачного проксирования на основе iptables применима только к системам Linux (включая openwrt/Android). Благодаря своей эффективности по сравнению с tun2socks и возможности настройки на маршрутизаторах, она получила широкое распространение.
|
||||
|
||||
Существующие три русскоязычных руководства по прозрачному проксированию на самом деле описывают реализацию прозрачного проксирования на основе этого решения: **[Новое руководство по V2Ray на русском языке - Прозрачное проксирование](https://guide.v2fly.org/app/transparent_proxy.html)**, **[Новое руководство по V2Ray на русском языке - Прозрачное проксирование (TPROXY)](https://guide.v2fly.org/app/tproxy.html)**, **[Руководство по настройке прозрачного проксирования (TProxy)](../tproxy.md)**. Первое основано на устаревшем режиме iptables-redirect, который не рекомендуется использовать и приводится только для справки. Второе и третье описывают реализацию прозрачного проксирования на основе режима iptables-tproxy.
|
||||
|
||||
## Принцип реализации прозрачного проксирования с помощью iptables
|
||||
|
||||
Linux использует `Netfilter` для управления сетью, модель `Netfilter` выглядит следующим образом:
|
||||
|
||||

|
||||
|
||||
**Предположим, что в качестве шлюза используется маршрутизатор (т. е. наш обычный способ подключения к Интернету), тогда:**
|
||||
|
||||
Направление трафика от устройств локальной сети к Интернету через маршрутизатор:
|
||||
|
||||
`Цепочка PREROUTING -> Цепочка FORWARD -> Цепочка POSTINGROUTING`
|
||||
|
||||
Направление трафика от устройств локальной сети к маршрутизатору (например, вход в веб-интерфейс маршрутизатора/подключение к маршрутизатору по ssh/доступ к DNS-серверу маршрутизатора и т. д.):
|
||||
|
||||
`Цепочка PREROUTING -> Цепочка INPUT -> Хост шлюза`
|
||||
|
||||
Направление трафика от маршрутизатора к Интернету:
|
||||
|
||||
`Хост шлюза -> Цепочка OUTPUT -> Цепочка POSTINGROUTING`
|
||||
|
||||
**Управляя направлением трафика цепочек `PREROUTING` и `OUTPUT` с помощью iptables и перенаправляя его на Xray, мы можем проксировать устройства локальной сети и хост шлюза.**
|
||||
|
||||
## В чем сложность прозрачного проксирования?
|
||||
|
||||
Сложность прозрачного проксирования заключается в маршрутизации, то есть в различении того, какой трафик должен быть прямым, а какой должен проксироваться, поэтому я лично считаю, что термин **разделение трафика** более уместен.
|
||||
|
||||
Мы можем разделить маршрутизацию на следующие этапы по возрастанию сложности:
|
||||
|
||||
1. Проксирование всех запросов.
|
||||
2. Прямое подключение для локальных IP-адресов/многоадресных IP-адресов, проксирование для остальных запросов.
|
||||
3. На основе пункта 2, прямое подключение для исходящих запросов, инициированных Xray.
|
||||
4. На основе пункта 3, прямое подключение для запросов, адресованных китайским IP-адресам, и выбор внутренних и внешних DNS-серверов для разрешения внутренних и внешних доменных имен.
|
||||
|
||||
Три вышеупомянутых руководства описывают четвертый этап. Поэтому новичкам может быть сложно понять их, читая напрямую.
|
||||
|
||||
## Пошаговая реализация прозрачного проксирования на основе iptables-tproxy с нуля
|
||||
|
||||
### Прежде чем начать, вам необходимо иметь базовые знания:
|
||||
|
||||
1. Примерное представление о протоколах TCP/IP, доменных именах и DNS-серверах.
|
||||
2. Знание того, что такое WAN-порт, LAN-порт, LAN_IP, WAN_IP и DHCP-сервер. Для пограничных маршрутизаторов есть только один сетевой порт, который мы будем называть LAN-портом.
|
||||
3. Базовое понимание системы Linux (знание того, как запускать команды).
|
||||
4. Умение писать конфигурационные файлы клиента в формате json или, по крайней мере, понимать их.
|
||||
|
||||
### Предварительная подготовка
|
||||
::: warning
|
||||
Перед началом работы не забудьте включить пересылку пакетов ipv4 в Linux с помощью команды `sysctl -w net.ipv4.ip_forward=1`
|
||||
:::
|
||||
**1. Подготовьте шлюз под управлением Linux**
|
||||
|
||||
Например, маршрутизатор с прошивкой OpenWRT.
|
||||
|
||||
**2. Подготовьте исполняемый файл Xray и конфигурационный файл на шлюзе (маршрутизаторе)**
|
||||
|
||||
Конфигурационный файл прослушивает порт 12345 и включает tproxy:
|
||||
|
||||
```json
|
||||
{
|
||||
"log": {
|
||||
"loglevel": "warning"
|
||||
},
|
||||
"inbounds": [
|
||||
{
|
||||
"port": 12345,
|
||||
"protocol": "dokodemo-door",
|
||||
"settings": {
|
||||
"network": "tcp,udp",
|
||||
"followRedirect": true
|
||||
},
|
||||
"streamSettings": {
|
||||
"sockopt": {
|
||||
"tproxy": "tproxy"
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"outbounds": [
|
||||
{
|
||||
// Конфигурация вашего сервера
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Мы пойдем от простого к сложному, не будем писать routing, а напишем только один inbound и один outbound.
|
||||
|
||||
### Сначала давайте попробуем достичь первого этапа
|
||||
|
||||
::: warning
|
||||
Если вы не хотите перезагружать свою машину, лучше сначала попрактиковаться на виртуальной машине
|
||||
:::
|
||||
|
||||
Перенаправьте весь трафик цепочки `PREROUTING` в Xray.
|
||||
|
||||
Запустите Xray и выполните следующие команды:
|
||||
|
||||
```bash
|
||||
ip rule add fwmark 1 table 100
|
||||
ip route add local 0.0.0.0/0 dev lo table 100
|
||||
iptables -t mangle -N XRAY
|
||||
iptables -t mangle -A XRAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
|
||||
iptables -t mangle -A XRAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 1
|
||||
iptables -t mangle -A PREROUTING -j XRAY
|
||||
```
|
||||
|
||||
После ввода команд, если вы подключены к шлюзу по ssh, вы обнаружите, что соединение ssh разорвано (не беспокойтесь, перезагрузка восстановит его), и прозрачное проксирование не работает; если ваш шлюз - это виртуальная машина, вы обнаружите, что сам шлюз не может получить доступ к Интернету, и в журнале доступа Xray появится множество запросов с исходным адресом, равным целевому адресу, и целевым адресом, равным WAN_IP.
|
||||
|
||||
Теоретически доступ хоста шлюза к общедоступной сети должен проходить только через цепочки `OUTPUT` и `POSTINGROUTING`, так почему же управление цепочкой `PREROUTING` приводит к тому, что шлюз не может получить доступ к Интернету? Это связано с тем, что сетевое взаимодействие, как правило, двунаправленное, и хотя доступ шлюза к общедоступному IP-адресу не требует прохождения через цепочку `PREROUTING`, информация, возвращаемая сервером на шлюз, должна проходить через цепочку `PREROUTING`, и эта часть перенаправляется на Xray, что приводит к обратным запросам в журнале.
|
||||
|
||||
Давайте изменим правило, чтобы возвращать трафик, источник которого не находится в локальной сети. Перезагрузите шлюз, запустите Xray и выполните следующие команды:
|
||||
|
||||
```bash
|
||||
ip rule add fwmark 1 table 100
|
||||
ip route add local 0.0.0.0/0 dev lo table 100
|
||||
iptables -t mangle -N XRAY
|
||||
# "Диапазон LAN-адресов шлюза" можно получить, выполнив команду "ip address | grep -w "inet" | awk '{print $2}'", это будет один из адресов
|
||||
iptables -t mangle -A XRAY ! -s Диапазон LAN-адресов шлюза -j RETURN
|
||||
iptables -t mangle -A XRAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
|
||||
iptables -t mangle -A XRAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 1
|
||||
iptables -t mangle -A PREROUTING -j XRAY
|
||||
```
|
||||
|
||||
Теперь вы обнаружите, что, хотя соединение ssh разорвано, прозрачное проксирование уже работает. Если мы изменим системный DNS на общедоступный DNS, мы сможем нормально просматривать веб-страницы (поскольку в настоящее время шлюз недоступен, мы не можем установить DNS на шлюз).
|
||||
|
||||
На этом первый этап завершен. Причина, по которой мы не можем получить доступ к шлюзу, заключается в том, что правило проксирования проксирует весь трафик, включая трафик, адресованный шлюзу. Представьте, что вы пытаетесь получить доступ к своему локальному шлюзу с VPS, вы не сможете этого сделать, поэтому нам нужно сделать этот трафик прямым, смотрите второй этап:
|
||||
|
||||
### Второй этап
|
||||
|
||||
Перезагрузите шлюз, запустите Xray и выполните следующие команды:
|
||||
|
||||
```bash
|
||||
ip rule add fwmark 1 table 100
|
||||
ip route add local 0.0.0.0/0 dev lo table 100
|
||||
iptables -t mangle -N XRAY
|
||||
|
||||
# Прямое подключение для всех запросов, адресованных сегменту сети шлюза
|
||||
# Получите сегменты сети, выполнив команду "ip address | grep -w "inet" | awk '{print $2}'", как правило, их несколько
|
||||
iptables -t mangle -A XRAY -d Сегмент сети шлюза 1 -j RETURN
|
||||
iptables -t mangle -A XRAY -d Сегмент сети шлюза 2 -j RETURN
|
||||
...
|
||||
|
||||
# Прямое подключение для запросов, адресованных многоадресным IP-адресам/адресам класса E/широковещательным IP-адресам
|
||||
iptables -t mangle -A XRAY -d 224.0.0.0/3 -j RETURN
|
||||
|
||||
iptables -t mangle -A XRAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
|
||||
iptables -t mangle -A XRAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 1
|
||||
iptables -t mangle -A PREROUTING -j XRAY
|
||||
```
|
||||
|
||||
После использования этого правила предыдущее правило `iptables -t mangle -A XRAY ! -s Диапазон LAN-адресов шлюза -j RETURN` становится лишним и его можно удалить.
|
||||
|
||||
На этом второй этап завершен. Шлюз доступен, ssh не разрывается.
|
||||
|
||||
### Третий этап
|
||||
|
||||
Обычно мы используем DNS, предоставляемый маршрутизатором, но это правило iptables проксирует только устройства в локальной сети, а не сам хост шлюза, поэтому возвращаемые результаты DNS-запросов могут быть неверными или загрязненными.
|
||||
|
||||
iptables-tproxy не поддерживает работу с цепочкой `OUTPUT`, но мы можем настроить `маршрутизацию по политике`, чтобы перенаправлять соответствующие пакеты из цепочки `OUTPUT` обратно в цепочку `PREROUTING`.
|
||||
|
||||
```bash
|
||||
# Добавить маршрут по политике: пакеты с меткой 1 направляются в таблицу маршрутизации 100
|
||||
ip rule add fwmark 1 table 100
|
||||
# Добавить запись маршрута в таблицу маршрутизации 100: все пакеты направляются локально
|
||||
ip route add local 0.0.0.0/0 dev lo table 100
|
||||
```
|
||||
|
||||
Настроив `маршрутизацию по политике` выше, нам нужно только пометить пакеты, которые необходимо проксировать от хоста шлюза, меткой `1` в цепочке `OUTPUT`, и соответствующие пакеты будут направлены на сам хост шлюза, то есть в цепочку `PREROUTING`.
|
||||
|
||||
Если мы хотим проксировать все запросы, отправленные хостом шлюза, это вызовет проблему: Xray работает на шлюзе, Xray отправляет запросы на сервер прокси, и эти запросы снова проксируются, образуя петлю.
|
||||
|
||||
Поэтому, чтобы проксировать хост шлюза, необходимо избежать зацикливания, то есть исключить трафик запросов Xray из правил проксирования.
|
||||
|
||||
**Существуют три распространенных метода:**
|
||||
|
||||
1. Прямое подключение трафика, адресованного VPS
|
||||
|
||||
Перезагрузите шлюз, запустите Xray и выполните следующие команды:
|
||||
|
||||
```bash
|
||||
# Проксирование устройств локальной сети
|
||||
# Наследуем достижения предыдущего этапа
|
||||
ip rule add fwmark 1 table 100
|
||||
ip route add local 0.0.0.0/0 dev lo table 100
|
||||
iptables -t mangle -N XRAY
|
||||
iptables -t mangle -A XRAY -d Сегмент сети шлюза 1 -j RETURN
|
||||
iptables -t mangle -A XRAY -d Сегмент сети шлюза 2 -j RETURN
|
||||
...
|
||||
iptables -t mangle -A XRAY -d 224.0.0.0/3 -j RETURN
|
||||
iptables -t mangle -A XRAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
|
||||
iptables -t mangle -A XRAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 1
|
||||
iptables -t mangle -A PREROUTING -j XRAY
|
||||
|
||||
# Проксирование хоста шлюза
|
||||
iptables -t mangle -N XRAY_MASK
|
||||
iptables -t mangle -A XRAY_MASK -d Сегмент сети шлюза 1 -j RETURN
|
||||
iptables -t mangle -A XRAY_MASK -d Сегмент сети шлюза 2 -j RETURN
|
||||
...
|
||||
iptables -t mangle -A XRAY_MASK -d 224.0.0.0/3 -j RETURN
|
||||
iptables -t mangle -A XRAY_MASK -d Общедоступный IP-адрес VPS/32 -j RETURN
|
||||
iptables -t mangle -A XRAY_MASK -j MARK --set-mark 1
|
||||
iptables -t mangle -A OUTPUT -p tcp -j XRAY_MASK
|
||||
iptables -t mangle -A OUTPUT -p udp -j XRAY_MASK
|
||||
```
|
||||
|
||||
Однако у этого метода есть недостаток: если используется CDN или много VPS, то написание правил становится неудобным.
|
||||
|
||||
2. Исключение с помощью меток
|
||||
|
||||
Три вышеупомянутых русскоязычных руководства используют этот метод исключения, обратитесь к ним, мы не будем повторяться здесь.
|
||||
|
||||
3. Исключение с помощью gid (рекомендуется)
|
||||
|
||||
См. **[[Прозрачное проксирование] Исключение трафика Xray с помощью gid](../iptables_gid.md)**
|
||||
|
||||
На этом третий этап проксирования, также известный как глобальное проксирование, завершен. Но не забудьте установить DNS-сервер шлюза на зарубежный DNS-сервер, иначе вы все равно можете получить загрязненные результаты.
|
||||
|
||||
### Четвертый этап
|
||||
|
||||
На самом деле, не всем нужно реализовывать четвертый этап. Глобальное проксирование подходит для большинства случаев.
|
||||
|
||||
Особенно для пограничных маршрутизаторов. При необходимости проксирования установите шлюз на IP-адрес пограничного маршрутизатора, при отсутствии необходимости проксирования - на IP-адрес основного маршрутизатора.
|
||||
|
||||
Что касается конкретной реализации четвертого этапа, то об этом подробно рассказывается в трех вышеупомянутых русскоязычных руководствах. После того, как вы поймете вышеизложенное, вам будет легче понять эти руководства.
|
||||
|
||||
### Проксирование IPv6
|
||||
|
||||
Вышеуказанные правила действительны только для IPv4, если вы хотите проксировать запросы IPv6, используйте команду ip6tables, ее использование в основном такое же, как и у iptables. См. **[[Прозрачное проксирование] Исключение трафика Xray с помощью gid # 4-Настройка правил iptables](../iptables_gid # 4-Настройка правил iptables.md)**
|
||||
|
||||
# Другие замечания по прозрачному проксированию с помощью iptables
|
||||
|
||||
1. Если шлюз, выступающий в качестве прокси, также является основным маршрутизатором, необходимо добавить правило `iptables -t mangle -A XRAY ! -s Диапазон LAN-адресов шлюза -j RETURN` в цепочку `PREROUTING`, то есть команду, использованную на первом этапе и удаленную на втором этапе. Если этого не сделать, другие люди в той же подсети, что и WAN-порт, смогут использовать ваш WAN_IP в качестве шлюза, чтобы злоупотреблять вашим прозрачным прокси, что может быть небезопасно.
|
||||
|
||||
2. В **[Новое руководство по V2Ray на русском языке - Прозрачное проксирование (TPROXY) # Настройка шлюза](https://guide.v2fly.org/app/tproxy.html # Настройка шлюза)** третий пункт гласит: `Настройте сеть ПК вручную, указав в качестве шлюза по умолчанию адрес Raspberry Pi, то есть 192.168.1.22. Теперь ПК должен иметь доступ к Интернету (поскольку проксирование еще не настроено, “доступ” означает возможность доступа к внутренним веб-сайтам)`. На самом деле, даже если включена переадресация IP, ПК под управлением Ubuntu, CentOS, Debian и других систем не смогут получить доступ к Интернету, это нормально. Фактически, только OpenWRT может сделать то, что описано в статье, как указал **[@BioniCosmos](https://github.com/BioniCosmos)**, это связано с тем, что в обычных системах Linux нет правил Masquerade.
|
||||
|
||||
3. **[Проблема too many open files](https://guide.v2fly.org/app/tproxy.html#решение-проблемы-too-many-open-files)**, см. решение в **[[Прозрачное проксирование] Исключение трафика Xray с помощью gid - Настройка максимального количества открытых файлов и запуск клиента Xray](../iptables_gid#3-настройка-максимального-количества-открытых-файлов-запуск-клиента-xray)**
|
||||
|
||||
4. Избегайте повторного прохождения пакетов с существующими подключениями через TPROXY, будет дополнено...
|
||||
|
||||
5. Основной маршрутизатор, однорукий маршрутизатор и пограничный маршрутизатор, будет дополнено...
|
||||
@@ -0,0 +1,233 @@
|
||||
---
|
||||
title: Повышение безопасности проксирования с помощью Cloudflare Warp
|
||||
---
|
||||
|
||||
# Повышение безопасности проксирования с помощью Cloudflare Warp
|
||||
|
||||
В Xray (1.6.5+) добавлен исходящий WireGuard. Хотя это увеличивает размер ядра из-за дополнительных кода и зависимостей, мы считаем, что это важная новая функция по трем причинам:
|
||||
|
||||
1. Из недавних обсуждений и [экспериментов](https://github.com/net4people/bbs/issues/129#issuecomment-1308102504) мы знаем, что проксирование трафика в Китай небезопасно.
|
||||
Одним из способов решения этой проблемы является перенаправление трафика в Китай в черный дыры.
|
||||
Недостаток этого метода заключается в том, что geosite и geoip обновляются нерегулярно, и новички могут не знать, как правильно настроить разделение трафика на клиенте, в результате чего трафик попадает в черный дыры, что снижает удобство использования.
|
||||
В этом случае мы можем просто перенаправить трафик в Китай через Cloudflare Warp, что обеспечит такую же безопасность без ущерба для удобства использования.
|
||||
2. Как известно, большинство VPN-провайдеров ведут журналы посещенных пользователями доменов, а некоторые даже проверяют и блокируют определенный трафик.
|
||||
Один из способов защиты конфиденциальности пользователей - использовать цепочку прокси-серверов на клиенте.
|
||||
Warp использует легкий VPN-протокол WireGuard, который добавляет дополнительный уровень шифрования.
|
||||
Для VPN-провайдера весь трафик пользователя будет направляться на Warp, что обеспечивает максимальную защиту конфиденциальности.
|
||||
3. Простота использования.
|
||||
Для настройки разделения трафика, WireGuard-туннеля и цепочки прокси-серверов достаточно одного ядра.
|
||||
|
||||
## Создание аккаунта Warp
|
||||
|
||||
### Спасибо Cloudflare за содействие свободному интернету! Теперь вы можете бесплатно пользоваться услугами Warp. При подключении автоматически выбирается ближайший сервер.
|
||||
#### Метод 1:
|
||||
1. Используйте VPS и загрузите [wgcf](https://github.com/ViRb3/wgcf/releases).
|
||||
2. Запустите `wgcf register`, чтобы создать файл `wgcf-account.toml`.
|
||||
3. Запустите `wgcf generate`, чтобы создать файл `wgcf-profile.conf`. Скопируйте его содержимое:
|
||||
|
||||
```ini
|
||||
[Interface]
|
||||
PrivateKey = Мой закрытый ключ
|
||||
Address = 172.16.0.2/32
|
||||
Address = 2606:4700:110:8949:fed8:2642:a640:c8e1/128
|
||||
DNS = 1.1.1.1
|
||||
MTU = 1280
|
||||
[Peer]
|
||||
PublicKey = Открытый ключ Warp
|
||||
AllowedIPs = 0.0.0.0/0
|
||||
AllowedIPs = ::/0
|
||||
Endpoint = engage.cloudflareclient.com:2408
|
||||
```
|
||||
#### Метод 2:
|
||||
1. Используйте [warp-reg.sh](https://github.com/chise0713/warp-reg.sh). Запустите:
|
||||
```
|
||||
bash -c "$(curl -L warp-reg.vercel.app)"
|
||||
```
|
||||
- Вывод:
|
||||
```json
|
||||
{
|
||||
"endpoint":{
|
||||
"v4": "162.159.192.7",
|
||||
"v6": "[2606:4700:d0::a29f:c007]",
|
||||
},
|
||||
"reserved_dec": [35, 74, 190],
|
||||
"reserved_hex": "0x234abe",
|
||||
"reserved_str": "I0q+",
|
||||
"private_key": "yL0kApRiZW4VFfNkKAQ/nYxnMFT3AH0dfVkj1GAlr1k=",
|
||||
"public_key": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=",
|
||||
"v4": "172.16.0.2",
|
||||
"v6": "2606:4700:110:81f3:2a5b:3cad:9d4:9ea6"
|
||||
}
|
||||
```
|
||||
2. Скопируйте вывод.
|
||||
#### Метод 3:
|
||||
1. Используйте [wgcf-cli](https://github.com/ArchiveNetwork/wgcf-cli). Запустите следующие команды для установки:
|
||||
```
|
||||
bash -c "$(curl -L wgcf-cli.vercel.app)"
|
||||
```
|
||||
2. Запустите `wgcf-cli -r` для регистрации. Вывод:
|
||||
```json
|
||||
❯ wgcf-cli -r
|
||||
{
|
||||
"endpoint": {
|
||||
"v4": "162.159.192.7:0",
|
||||
"v6": "[2606:4700:d0::a29f:c007]:0"
|
||||
},
|
||||
"reserved_str": "6nT5",
|
||||
"reserved_hex": "0xea74f9",
|
||||
"reserved_dec": [
|
||||
234,
|
||||
116,
|
||||
249
|
||||
],
|
||||
"private_key": "WIAKvgUlq5fBazhttCvjhEGpu8MmGHcb1H0iHSGlU0Q=",
|
||||
"public_key": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=",
|
||||
"addresses": {
|
||||
"v4": "172.16.0.2",
|
||||
"v6": "2606:4700:110:8d9c:3c4e:2190:59d1:2d3c"
|
||||
}
|
||||
}
|
||||
```
|
||||
- Полный файл будет сохранен в файле `wgcf.json` в рабочем каталоге.
|
||||
3. Если у вас есть ключ Warp+, вы можете привязать его, запустив `wgcf-cli -l [ключ]`.
|
||||
- (Ключ можно получить, отправив `/keyget@getwarpplusbot` в [нашем чате](https://t.me/projectXray/)).
|
||||
Вывод:
|
||||
```json
|
||||
❯ wgcf-cli -l 9zs5I61a-l9j8m7T5-4pC6k20X
|
||||
{
|
||||
"id": "cd7f4695-e9ef-4bb0-b412-5f4d84919db7",
|
||||
"created": "0001-01-01T00:00:00Z",
|
||||
"updated": "2023-12-14T12:32:18.689777921Z",
|
||||
"premium_data": 0,
|
||||
"quota": 0,
|
||||
"warp_plus": true,
|
||||
"referral_count": 0,
|
||||
"referral_renewal_countdown": 0,
|
||||
"role": "child"
|
||||
}
|
||||
```
|
||||
4. Запустите `wgcf-cli -g xray`, чтобы создать исходящий WireGuard.
|
||||
Содержимое будет сохранено в файле `wgcf.json.xray.json`.
|
||||
- Пример файла:
|
||||
```json
|
||||
{
|
||||
"protocol": "wireguard",
|
||||
"settings": {
|
||||
"secretKey": "6CRVRLgFwGajnikoVOPTDNZnDhx3EydhPsMgpxHfBCY=",
|
||||
"address": [
|
||||
"172.16.0.2/32",
|
||||
"2606:4700:110:857a:6a95:fe27:1870:2a9d/128"
|
||||
],
|
||||
"peers": [
|
||||
{
|
||||
"publicKey": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=",
|
||||
"allowedIPs": [
|
||||
"0.0.0.0/0",
|
||||
"::/0"
|
||||
],
|
||||
"endpoint": "162.159.192.1:2408"
|
||||
}
|
||||
],
|
||||
"reserved": [
|
||||
240,
|
||||
25,
|
||||
146
|
||||
],
|
||||
"mtu": 1280
|
||||
},
|
||||
"tag": "wireguard"
|
||||
}
|
||||
```
|
||||
## Перенаправление трафика в Китай через Warp на сервере
|
||||
|
||||
Добавьте исходящий WireGuard к существующим исходящим подключениям:
|
||||
|
||||
```json
|
||||
{
|
||||
"protocol": "wireguard",
|
||||
"settings": {
|
||||
"secretKey": "Мой закрытый ключ",
|
||||
"address": ["172.16.0.2/32", "2606:4700:110:8949:fed8:2642:a640:c8e1/128"],
|
||||
"peers": [
|
||||
{
|
||||
"publicKey": "Открытый ключ Warp",
|
||||
"endpoint": "engage.cloudflareclient.com:2408"
|
||||
}
|
||||
],
|
||||
"reserved":[0, 0, 0] // Вставьте reserved, если у вас есть.
|
||||
},
|
||||
"tag": "wireguard-1"
|
||||
}
|
||||
```
|
||||
|
||||
Рекомендуется использовать стратегию маршрутизации `IPIfNonMatch`.
|
||||
|
||||
Добавьте следующие правила к существующим правилам маршрутизации:
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "field",
|
||||
"domain": [
|
||||
"geosite:cn"
|
||||
],
|
||||
"outboundTag": "wireguard-1"
|
||||
},
|
||||
{
|
||||
"type": "field",
|
||||
"ip": [
|
||||
"geoip:cn"
|
||||
],
|
||||
"outboundTag": "wireguard-1"
|
||||
},
|
||||
```
|
||||
|
||||
## Использование Warp в качестве прокси-сервера в цепочке на клиенте
|
||||
|
||||
```json
|
||||
{
|
||||
"outbounds":[
|
||||
{
|
||||
"protocol":"wireguard",
|
||||
"settings":{
|
||||
"secretKey":"Мой закрытый ключ",
|
||||
"peers":[
|
||||
{
|
||||
"publicKey":"Открытый ключ Warp",
|
||||
"endpoint":"engage.cloudflareclient.com:2408"
|
||||
}
|
||||
],
|
||||
"reserved":[0, 0, 0] // Вставьте reserved, если у вас есть.
|
||||
},
|
||||
"streamSettings":{
|
||||
"sockopt":{
|
||||
"dialerProxy":"proxy"
|
||||
}
|
||||
},
|
||||
"tag":"wireguard-1"
|
||||
},
|
||||
{
|
||||
"tag":"proxy",
|
||||
"protocol":"vmess",
|
||||
"settings":{
|
||||
"vnext":[
|
||||
{
|
||||
"address":"Мой IP-адрес",
|
||||
"port":Мой порт,
|
||||
"users":[
|
||||
{
|
||||
"id":"Мой UUID",
|
||||
"security":"auto"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
"streamSettings":{
|
||||
"network":"tcp"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||