Add joplin web article (#9)
This commit is contained in:
deytenit authored and 
GitHub committed
1 parent
90bf68c4c8
commit
575959ffa2
38 files changed
+1043
-554
No files matched your search
@@ -0,0 +1,227 @@
|
||||
---
|
||||
title: 'Joplin Web Deployment Guide'
|
||||
description: 'Joplin Server & Web App deployment from scratch'
|
||||
createdDate: 2026-03-20
|
||||
tags: ['joplin', 'deployment', 'guide']
|
||||
---
|
||||
|
||||
This guide describes how to deploy a private note-taking infrastructure using the Joplin Server and its web client.
|
||||
|
||||
## Why I Chose Joplin?
|
||||
|
||||
I have been using Joplin for a long time, and it has become my primary note-taking tool. There are several reasons why I chose it over other alternatives:
|
||||
|
||||
- **Local-First**: Notes are stored locally on your device, ensuring fast access and full ownership (especially when the internet is inaccessible).
|
||||
- **Markdown Format**: Joplin uses Markdown for all notes, making it incredibly easy to export, import, or move your data to another platform if needed.
|
||||
- **Easy Sharing**: The ability to share notes via the web makes collaboration or public sharing straightforward.
|
||||
- **Backups**: Joplin provides robust backup options, giving me peace of mind that my data is safe.
|
||||
|
||||
One thing that was missing for me was the ability to quickly add or view notes when I don't have access to my primary devices (for example, at work). This article provides the solution: a self-hosted web client.
|
||||
|
||||
## Technical Stack Overview
|
||||
|
||||
1. **Joplin Server**: The synchronization server. It handles the Joplin sync protocol, account logic, and note synchronization across devices.
|
||||
2. **Postgres**: The database. Essential for production performance.
|
||||
3. **Joplin Web App**: A browser-based client built from the Joplin mobile app source code using React Native for Web.
|
||||
|
||||
## 1. The Deployment Stack
|
||||
|
||||
This configuration is generic, uses **Docker Volumes**, and provides a minimal setup for deploying the full stack.
|
||||
|
||||
### Main docker-compose.yml
|
||||
|
||||
This compose file is a minimal configuration to run the Joplin Server and the web app. It assumes you understand how to set up a reverse proxy, or better yet, already have your own Joplin setup.
|
||||
|
||||
```yaml
|
||||
x-environment: &shared-environment
|
||||
TZ: 'Europe/Moscow'
|
||||
POSTGRES_DB: 'joplin'
|
||||
POSTGRES_USER: ${SHARED_USERNAME?:error}
|
||||
POSTGRES_PASSWORD: ${SHARED_PASSWORD?:error}
|
||||
|
||||
services:
|
||||
postgres:
|
||||
image: postgres:16
|
||||
container_name: joplin-postgres
|
||||
volumes:
|
||||
- postgres_data:/var/lib/postgresql/data
|
||||
environment:
|
||||
<<: *shared-environment
|
||||
restart: unless-stopped
|
||||
|
||||
server:
|
||||
image: joplin/server:3.5.2
|
||||
container_name: joplin-server
|
||||
depends_on:
|
||||
- postgres
|
||||
environment:
|
||||
<<: *shared-environment
|
||||
APP_PORT: 22300
|
||||
APP_BASE_URL: 'https://example.com'
|
||||
DB_CLIENT: 'pg'
|
||||
POSTGRES_HOST: 'joplin-postgres'
|
||||
POSTGRES_PORT: 5432
|
||||
POSTGRES_DATABASE: 'joplin'
|
||||
ports:
|
||||
- '22300:22300'
|
||||
restart: unless-stopped
|
||||
|
||||
app:
|
||||
build:
|
||||
context: ./app
|
||||
args:
|
||||
- GIT_TAG=v3.5.13
|
||||
container_name: joplin-app
|
||||
environment:
|
||||
<<: *shared-environment
|
||||
ports:
|
||||
- '8080:8080'
|
||||
restart: unless-stopped
|
||||
|
||||
volumes:
|
||||
postgres_data:
|
||||
```
|
||||
|
||||
### Dockerfile
|
||||
|
||||
Create an `app` directory and place this `Dockerfile` inside it to build the web client. We build our own image since the original authors don't provide one.
|
||||
|
||||
While there are repositories with pre-built images, it's easy enough to just create our own.
|
||||
|
||||
```dockerfile
|
||||
# Stage 1: Build
|
||||
FROM node:20-bookworm-slim AS builder
|
||||
|
||||
ARG GIT_TAG=v3.5.13
|
||||
|
||||
# Install build dependencies for Joplin monorepo
|
||||
RUN apt-get update && apt-get install -y \
|
||||
git python3 build-essential rsync \
|
||||
&& rm -rf /var/lib/apt/lists/*
|
||||
|
||||
WORKDIR /app
|
||||
|
||||
# Configure regional mirror and timeout for reliability
|
||||
RUN corepack enable && \
|
||||
yarn config set registry https://registry.npmmirror.com
|
||||
|
||||
# Clone specific tag
|
||||
RUN git clone --depth 1 --branch ${GIT_TAG} https://github.com/laurent22/joplin.git .
|
||||
|
||||
# Install dependencies and build the web distribution
|
||||
RUN yarn install --network-timeout 1000000
|
||||
RUN cd packages/app-mobile/ && yarn web
|
||||
|
||||
# Stage 2: Production Server
|
||||
FROM nginx:alpine
|
||||
|
||||
# Remove default assets
|
||||
RUN rm -rf /usr/share/nginx/html/*
|
||||
|
||||
# Copy built app and custom nginx config
|
||||
COPY --from=builder /app/packages/app-mobile/web/dist /usr/share/nginx/html/app
|
||||
COPY nginx.conf /etc/nginx/conf.d/default.conf
|
||||
|
||||
EXPOSE 8080
|
||||
CMD ["nginx", "-g", "daemon off;"]
|
||||
```
|
||||
|
||||
### Nginx configuration
|
||||
|
||||
Place this `nginx.conf` alongside the `Dockerfile` in the `app` directory. Joplin is an SPA, meaning it doesn't matter where it's deployed since all navigation is handled internally without location dependency. So it's alright to just deploy it on a path that doesn't overlap with the main server, such as `/app`.
|
||||
|
||||
> This is a pretty minimal configuration; it assumes your reverse proxy is good enough to cover all questionable items, but you can expand it as you like.
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 8080;
|
||||
server_name _;
|
||||
|
||||
root /usr/share/nginx/html;
|
||||
index index.html;
|
||||
|
||||
# Gzip compression for performance
|
||||
gzip on;
|
||||
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
|
||||
gzip_min_length 1000;
|
||||
|
||||
# SPA Routing: Fall back to index.html if a file isn't found
|
||||
location /app/ {
|
||||
try_files $uri $uri/ /app/index.html;
|
||||
}
|
||||
|
||||
# Cache static assets
|
||||
location ~* \.(?:ico|css|js|gif|jpe?g|png|woff2?|eot|ttf|svg|webmanifest)$ {
|
||||
expires 6M;
|
||||
access_log off;
|
||||
add_header Cache-Control "public, max-age=15552000, immutable";
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 2. Configuration
|
||||
|
||||
Create a `.env` file in the same directory as your `docker-compose.yml`. **Do not skip the secret generation step below.**
|
||||
|
||||
```bash
|
||||
# --- Database Credentials ---
|
||||
SHARED_USERNAME=joplin
|
||||
SHARED_PASSWORD=generate_this_with_openssl
|
||||
```
|
||||
|
||||
### Generating Secrets
|
||||
|
||||
Use `openssl` to easily generate secure, random strings for your `.env` entries:
|
||||
|
||||
```bash
|
||||
# Generate SHARED_PASSWORD
|
||||
openssl rand -hex 32
|
||||
```
|
||||
|
||||
## 3. Deployment
|
||||
|
||||
Start your stack by running the following command:
|
||||
|
||||
```bash
|
||||
docker compose up -d --build
|
||||
```
|
||||
|
||||
## 4. Initial Server Setup
|
||||
|
||||
Before configuring the web app, you must initialize your Joplin Server:
|
||||
|
||||
Follow the official guide: [Joplin Server README](https://github.com/laurent22/joplin/blob/dev/packages/server/README.md)
|
||||
|
||||
Essentially, you need to ensure that basic synchronization via the app is functional.
|
||||
|
||||
## 5. Web App Showcase & Setup
|
||||
|
||||
Once the web app is running at `https://example.com/app/`, you will be greeted by it.
|
||||
|
||||
### About the Web App
|
||||
|
||||
|
||||
|
||||
It is basically the same mobile Joplin app, but in-browser. It leverages the LocalStorage API for data handling. Everything is still local-first, so after logging in, it will take some time to synchronize all remote notes.
|
||||
|
||||
But most importantly: _The Joplin web interface allows you to view and edit your notes directly from the browser._
|
||||
|
||||
> It is said that it's only guaranteed to work on Chrome due to the required API compatibility; however, I have had great success with Firefox as well. Browsers are catching up quickly.
|
||||
|
||||
### Authentication Setup
|
||||
|
||||
To connect to your self-hosted Joplin Server, go to **Settings > Synchronization** and configure the following parameters:
|
||||
|
||||
- **Sync Target**: Joplin Server
|
||||
- **Joplin Server URL**: `https://example.com`
|
||||
- **Joplin Server Email**: `your-email@example.com` (the one you just created/configured)
|
||||
- **Joplin Server Password**: `your-password`
|
||||
|
||||
|
||||
|
||||
_Enjoy!_
|
||||
|
||||
## Resources
|
||||
|
||||
- [Joplin GitHub](https://github.com/laurent22/joplin)
|
||||
- [Joplin Server README](https://github.com/laurent22/joplin/blob/dev/packages/server/README.md)
|
||||
@@ -0,0 +1,227 @@
|
||||
---
|
||||
title: 'Руководство по развертыванию Joplin Web'
|
||||
description: 'Развертывание Joplin Server и веб-приложения с нуля'
|
||||
createdDate: 2026-03-20
|
||||
tags: ['joplin', 'deployment', 'guide']
|
||||
---
|
||||
|
||||
Это руководство описывает, как развернуть приватную инфраструктуру для заметок, используя Joplin Server и его веб-клиент.
|
||||
|
||||
## Почему я выбрал Joplin?
|
||||
|
||||
Я давно пользуюсь Joplin, и он стал моим основным инструментом для ведения заметок. Есть несколько причин, по которым я выбрал его среди других альтернатив:
|
||||
|
||||
- **Local-First**: Заметки хранятся локально на вашем устройстве, что обеспечивает быстрый доступ и полное владение данными (особенно когда интернет недоступен).
|
||||
- **Формат Markdown**: Joplin использует Markdown для всех заметок, что позволяет невероятно легко экспортировать, импортировать или переносить данные на другую платформу при необходимости.
|
||||
- **Удобный обмен**: Возможность делиться заметками через веб делает совместную работу или публичный доступ простыми.
|
||||
- **Резервное копирование**: Joplin предоставляет надежные варианты резервного копирования, давая мне уверенность в сохранности моих данных.
|
||||
|
||||
Одной вещи мне не хватало — возможности быстро добавить или просмотреть заметки, когда у меня нет доступа к моим основным устройствам (например, на работе). Эта статья предлагает решение: самостоятельно размещенный (self-hosted) веб-клиент.
|
||||
|
||||
## Обзор технологического стека
|
||||
|
||||
1. **Joplin Server**: Сервер синхронизации. Он обрабатывает протокол синхронизации Joplin, логику учетных записей и синхронизацию заметок между устройствами.
|
||||
2. **Postgres**: База данных. Необходима для производительности в рабочей среде.
|
||||
3. **Joplin Web App**: Браузерный клиент, созданный из исходного кода мобильного приложения Joplin с использованием React Native for Web.
|
||||
|
||||
## 1. Стек развертывания
|
||||
|
||||
Эта конфигурация является универсальной, использует **Docker Volumes** и предоставляет минимальную настройку для развертывания полного стека.
|
||||
|
||||
### Основной docker-compose.yml
|
||||
|
||||
Этот compose-файл представляет собой минимальную конфигурацию для запуска Joplin Server и веб-приложения. Предполагается, что вы понимаете, как настроить обратный прокси-сервер, или, что еще лучше, у вас уже есть собственная установка Joplin.
|
||||
|
||||
```yaml
|
||||
x-environment: &shared-environment
|
||||
TZ: 'Europe/Moscow'
|
||||
POSTGRES_DB: 'joplin'
|
||||
POSTGRES_USER: ${SHARED_USERNAME?:error}
|
||||
POSTGRES_PASSWORD: ${SHARED_PASSWORD?:error}
|
||||
|
||||
services:
|
||||
postgres:
|
||||
image: postgres:16
|
||||
container_name: joplin-postgres
|
||||
volumes:
|
||||
- postgres_data:/var/lib/postgresql/data
|
||||
environment:
|
||||
<<: *shared-environment
|
||||
restart: unless-stopped
|
||||
|
||||
server:
|
||||
image: joplin/server:3.5.2
|
||||
container_name: joplin-server
|
||||
depends_on:
|
||||
- postgres
|
||||
environment:
|
||||
<<: *shared-environment
|
||||
APP_PORT: 22300
|
||||
APP_BASE_URL: 'https://example.com'
|
||||
DB_CLIENT: 'pg'
|
||||
POSTGRES_HOST: 'joplin-postgres'
|
||||
POSTGRES_PORT: 5432
|
||||
POSTGRES_DATABASE: 'joplin'
|
||||
ports:
|
||||
- '22300:22300'
|
||||
restart: unless-stopped
|
||||
|
||||
app:
|
||||
build:
|
||||
context: ./app
|
||||
args:
|
||||
- GIT_TAG=v3.5.13
|
||||
container_name: joplin-app
|
||||
environment:
|
||||
<<: *shared-environment
|
||||
ports:
|
||||
- '8080:8080'
|
||||
restart: unless-stopped
|
||||
|
||||
volumes:
|
||||
postgres_data:
|
||||
```
|
||||
|
||||
### Dockerfile
|
||||
|
||||
Создайте директорию `app` и поместите в нее этот `Dockerfile` для сборки веб-клиента. Мы собираем собственный образ, так как авторы оригинала его не предоставляют.
|
||||
|
||||
Хотя существуют репозитории с готовыми образами, создать свой достаточно просто.
|
||||
|
||||
```dockerfile
|
||||
# Stage 1: Build
|
||||
FROM node:20-bookworm-slim AS builder
|
||||
|
||||
ARG GIT_TAG=v3.5.13
|
||||
|
||||
# Install build dependencies for Joplin monorepo
|
||||
RUN apt-get update && apt-get install -y \
|
||||
git python3 build-essential rsync \
|
||||
&& rm -rf /var/lib/apt/lists/*
|
||||
|
||||
WORKDIR /app
|
||||
|
||||
# Configure regional mirror and timeout for reliability
|
||||
RUN corepack enable && \
|
||||
yarn config set registry https://registry.npmmirror.com
|
||||
|
||||
# Clone specific tag
|
||||
RUN git clone --depth 1 --branch ${GIT_TAG} https://github.com/laurent22/joplin.git .
|
||||
|
||||
# Install dependencies and build the web distribution
|
||||
RUN yarn install --network-timeout 1000000
|
||||
RUN cd packages/app-mobile/ && yarn web
|
||||
|
||||
# Stage 2: Production Server
|
||||
FROM nginx:alpine
|
||||
|
||||
# Remove default assets
|
||||
RUN rm -rf /usr/share/nginx/html/*
|
||||
|
||||
# Copy built app and custom nginx config
|
||||
COPY --from=builder /app/packages/app-mobile/web/dist /usr/share/nginx/html/app
|
||||
COPY nginx.conf /etc/nginx/conf.d/default.conf
|
||||
|
||||
EXPOSE 8080
|
||||
CMD ["nginx", "-g", "daemon off;"]
|
||||
```
|
||||
|
||||
### Конфигурация Nginx
|
||||
|
||||
Поместите этот `nginx.conf` рядом с `Dockerfile` в директории `app`. Joplin — это SPA (Single Page Application), а значит, не имеет значения, где оно развернуто, так как вся навигация обрабатывается внутренне без зависимости от местоположения. Поэтому вполне нормально развернуть его по пути, который не пересекается с основным сервером, например `/app`.
|
||||
|
||||
> Это довольно минималистичная конфигурация; предполагается, что ваш обратный прокси достаточно хорош, чтобы закрыть все спорные моменты, но вы можете расширить ее по своему усмотрению.
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 8080;
|
||||
server_name _;
|
||||
|
||||
root /usr/share/nginx/html;
|
||||
index index.html;
|
||||
|
||||
# Gzip-сжатие для производительности
|
||||
gzip on;
|
||||
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
|
||||
gzip_min_length 1000;
|
||||
|
||||
# SPA-роутинг: возврат к index.html, если файл не найден
|
||||
location /app/ {
|
||||
try_files $uri $uri/ /app/index.html;
|
||||
}
|
||||
|
||||
# Кэширование статических ресурсов
|
||||
location ~* \.(?:ico|css|js|gif|jpe?g|png|woff2?|eot|ttf|svg|webmanifest)$ {
|
||||
expires 6M;
|
||||
access_log off;
|
||||
add_header Cache-Control "public, max-age=15552000, immutable";
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 2. Конфигурация
|
||||
|
||||
Создайте файл `.env` в той же директории, что и `docker-compose.yml`. **Не пропускайте шаг генерации секретов ниже.**
|
||||
|
||||
```bash
|
||||
# --- Учетные данные базы данных ---
|
||||
SHARED_USERNAME=joplin
|
||||
SHARED_PASSWORD=generate_this_with_openssl
|
||||
```
|
||||
|
||||
### Генерация секретов
|
||||
|
||||
Используйте `openssl`, чтобы легко создать безопасные случайные строки для записей в вашем `.env`:
|
||||
|
||||
```bash
|
||||
# Генерация SHARED_PASSWORD
|
||||
openssl rand -hex 32
|
||||
```
|
||||
|
||||
## 3. Развертывание
|
||||
|
||||
Запустите стек, выполнив следующую команду:
|
||||
|
||||
```bash
|
||||
docker compose up -d --build
|
||||
```
|
||||
|
||||
## 4. Начальная настройка сервера
|
||||
|
||||
Перед настройкой веб-приложения необходимо инициализировать ваш Joplin Server:
|
||||
|
||||
Следуйте официальному руководству: [Joplin Server README](https://github.com/laurent22/joplin/blob/dev/packages/server/README.md)
|
||||
|
||||
По сути, вам нужно убедиться, что базовая синхронизация через приложение работает.
|
||||
|
||||
## 5. Демонстрация и настройка веб-приложения
|
||||
|
||||
Как только веб-приложение запустится по адресу `https://example.com/app/`, оно поприветствует вас.
|
||||
|
||||
### О веб-приложении
|
||||
|
||||
|
||||
|
||||
По сути, это то же самое мобильное приложение Joplin, но в браузере. Оно использует LocalStorage API для обработки данных. Все по-прежнему работает по принципу local-first, поэтому после входа в систему потребуется время для синхронизации всех удаленных заметок.
|
||||
|
||||
Но самое главное: _Веб-интерфейс Joplin позволяет просматривать и редактировать заметки прямо из браузера._
|
||||
|
||||
> Говорят, что работа гарантирована только в Chrome из-за требований к совместимости API; однако я добился отличных результатов и в Firefox. Браузеры быстро догоняют друг друга.
|
||||
|
||||
### Настройка аутентификации
|
||||
|
||||
Чтобы подключиться к вашему self-hosted серверу Joplin, перейдите в **Settings > Synchronization** и настройте следующие параметры:
|
||||
|
||||
- **Sync Target**: Joplin Server
|
||||
- **Joplin Server URL**: `https://example.com`
|
||||
- **Joplin Server Email**: `your-email@example.com` (тот, который вы только что создали/настроили)
|
||||
- **Joplin Server Password**: `your-password`
|
||||
|
||||
|
||||
|
||||
_Наслаждайтесь!_
|
||||
|
||||
## Ресурсы
|
||||
|
||||
- [Joplin GitHub](https://github.com/laurent22/joplin)
|
||||
- [Joplin Server README](https://github.com/laurent22/joplin/blob/dev/packages/server/README.md)
|
||||
@@ -1,182 +1,154 @@
|
||||
---
|
||||
title: 'Xray Subnet Mimicry'
|
||||
description: 'Building a distributed 10.0.0.0/8 private network with Xray-core'
|
||||
createdDate: 2026-03-08
|
||||
tags: ['networking', 'guide']
|
||||
title: 'Xray Subnet Mimicry (10.0.0.0/8)'
|
||||
description: 'Building a distributed private network with Xray-core and reverse tunneling'
|
||||
createdDate: 2026-03-20
|
||||
tags: ['networking', 'xray', 'guide']
|
||||
---
|
||||
|
||||
> This guide is for **educational purposes** only. It is designed as a technical demonstration of Xray-core's routing capabilities and private subnet mimicry. It is NOT intended for restriction evasion or illegal activities. Use this knowledge responsibly and in compliance with your local laws.
|
||||
> **EDUCATIONAL PURPOSES ONLY**
|
||||
> This project is designed as a technical demonstration of Xray-core's routing capabilities and private subnet mimicry. It is NOT intended for restriction evasion or illegal activities. Use this knowledge responsibly and in compliance with your local laws.
|
||||
|
||||
## Why Subnet Mimicry?
|
||||
This guide describes how to deploy a private note-taking infrastructure (or any distributed service) using a contiguous `10.0.0.0/8` private subnet mimicked across distinct servers using **Xray-core** and **reverse tunneling**.
|
||||
|
||||
By constructing a "Flat Network" (Layer 3) over the public internet, you achieve a unified private address space (`10.0.0.0/8`) distributed across distinct servers.
|
||||
## Technical Deep-Dive & Architecture
|
||||
|
||||
- **Distributed Topology**: Each node is an authoritative gateway for its own `/16` segment (e.g., Hub on `10.1.0.0/16`, Spokes on `10.2.0.0/16` and `10.3.0.0/16`).
|
||||
- **NAT Traversal**: Spokes (Bridges) actively initiate connections to the Hub (Portal), allowing nodes behind NAT to be reachable.
|
||||
- **Centralized Resolution**: Enforce network-wide DNS policies through a central Hub resolver.
|
||||
### The Virtual Subnet Concept
|
||||
|
||||
---
|
||||
We are constructing a "Flat Network" (Layer 3) over the public internet. Each node acts as an authoritative gateway for its own `/16` segment of the `10.0.0.0/8` range. This allows seamless communication between servers as if they were on the same local network.
|
||||
|
||||
## Technical Stack Overview
|
||||
### The Science of Interception (TPROXY)
|
||||
|
||||
1. **Xray-core**: The routing engine handling VLESS connections, reverse tunneling, and TPROXY interception.
|
||||
2. **TPROXY**: Transparent proxying in the Linux Mangle table that intercepts TCP/UDP traffic while preserving original destination IPs.
|
||||
3. **Policy Routing**: Using `ip rule` and routing Table 100 to force intercepted packets into the local loopback for Xray to process.
|
||||
4. **Mux.cool**: A multiplexing protocol that packs hundreds of virtual connections (TCP/UDP streams) into a single physical TLS connection.
|
||||
5. **AdGuard Home**: The centralized DNS resolver for the entire subnet.
|
||||
6. **Nginx**: Used as camouflage on the main public inbound port to hide the Xray instance.
|
||||
Unlike `REDIRECT`, which only works for TCP and modifies the destination IP, **TPROXY** (Transparent Proxy) allows Xray to intercept both TCP and UDP while preserving the original packet headers.
|
||||
|
||||
---
|
||||
- **Mechanism**: When a packet destined for `10.x.x.x` enters the `PREROUTING` or `OUTPUT` chain, the Linux Mangle table marks it with `0x1`.
|
||||
- **Preservation**: Xray's `tunnel` inbound uses the `tproxy` socket option to read the original destination IP from the socket metadata, enabling it to route the packet correctly.
|
||||
|
||||
## 1. The Deployment Stack
|
||||
### Policy Routing (Table 100)
|
||||
|
||||
This configuration represents the Central Hub (Server A) which acts as the Portal for Spoke connections. The Hub hosts the centralized DNS and the fallback Nginx camouflage.
|
||||
While firewall marks identify intercepted packets, they don't inherently change the routing path. To redirect this traffic to Xray, we use **Policy Routing**:
|
||||
|
||||
```yaml
|
||||
name: 'a'
|
||||
1. **The Rule (`ip rule`)**: `ip rule add fwmark 1 lookup 100` instructs the networking stack to use a custom routing table for marked packets.
|
||||
2. **The Table (`ip route`)**: Table 100 is configured with `local default dev lo`, treating all destination IPs as local and routing them to the loopback interface.
|
||||
3. **The Handoff**: Xray, listening on `127.0.0.1:12345` with the `tproxy` option, intercepts the packet from the loopback interface.
|
||||
4. **Loop Prevention**: We use `mark: 255` in Xray's outbounds to exempt its own traffic from interception, avoiding infinite routing loops.
|
||||
|
||||
services:
|
||||
xray:
|
||||
image: ghcr.io/xtls/xray-core:26.1.23
|
||||
container_name: a-xray
|
||||
network_mode: host
|
||||
volumes:
|
||||
- ./xray.jsonc:/etc/xray/config.jsonc:ro
|
||||
- /etc/letsencrypt/live:/etc/letsencrypt/live:ro
|
||||
command: -c '/etc/xray/config.jsonc'
|
||||
restart: unless-stopped
|
||||
cap_add:
|
||||
- NET_ADMIN
|
||||
- NET_RAW
|
||||
### The Reverse Proxy Mechanism
|
||||
|
||||
nginx:
|
||||
image: nginxinc/nginx-unprivileged:1.29-alpine
|
||||
container_name: a-nginx
|
||||
networks:
|
||||
direct:
|
||||
ipv4_address: 10.1.1.4
|
||||
restart: unless-stopped
|
||||
security_opt:
|
||||
- no-new-privileges:true
|
||||
To reach servers behind NAT (Spokes) from a central Hub, Xray employs a sophisticated Reverse Proxy architecture:
|
||||
|
||||
adguard:
|
||||
image: adguard/adguardhome:v0.107.72
|
||||
container_name: root-adguard
|
||||
volumes:
|
||||
- adguard-work:/opt/adguardhome/work
|
||||
- adguard-conf:/opt/adguardhome/conf
|
||||
networks:
|
||||
direct:
|
||||
ipv4_address: 10.1.1.3
|
||||
restart: unless-stopped
|
||||
cap_add:
|
||||
- NET_BIND_SERVICE
|
||||
- SYS_NICE
|
||||
- CAP_CHOWN
|
||||
security_opt:
|
||||
- no-new-privileges:true
|
||||
- **Bridge (Spoke)**: Initiates the connection to the Portal. It acts as a client for the tunnel but functionally behaves as a server once the connection is established.
|
||||
- **Portal (Hub)**: Listens for Bridge connections and uses "Dummy Domains" to identify them, relaying traffic through the established tunnels.
|
||||
- **Multiplexing (Mux)**: Uses [Mux.cool](https://xtls.github.io/en/development/protocols/muxcool.html) to pack hundreds of virtual streams into a single physical TLS connection, reducing overhead and bypassing NAT timeouts.
|
||||
|
||||
networks:
|
||||
direct:
|
||||
name: a-direct
|
||||
driver: bridge
|
||||
ipam:
|
||||
config:
|
||||
- subnet: 10.1.0.0/16 # Using the full /16 as defined for Server A
|
||||
gateway: 10.1.0.1
|
||||
## Setup Guide
|
||||
|
||||
volumes:
|
||||
adguard-work:
|
||||
name: a-adguard-work
|
||||
adguard-conf:
|
||||
name: a-adguard-conf
|
||||
```
|
||||
### Phase 0: Prerequisites (Server A only)
|
||||
|
||||
---
|
||||
Server A (the Hub) requires a valid SSL certificate for XTLS-Vision. Point your domain (`A-DOMAIN`) to Server A's public IP and ensure certificates are available (e.g., via Certbot) at `/etc/letsencrypt/live/A-DOMAIN/`.
|
||||
|
||||
## 2. Configuration & Routing
|
||||
### Phase 1: Security & Identity
|
||||
|
||||
### Generating Identity UUIDs
|
||||
|
||||
Each connection needs its own cryptographic "Key". You need 4 UUIDs mapped to your config files.
|
||||
|
||||
```bash
|
||||
# Generate UUIDs for the Server B and Server C mappings
|
||||
docker run --rm ghcr.io/xtls/xray-core uuid
|
||||
```
|
||||
|
||||
The mapping is as follows:
|
||||
Each connection requires a unique UUID. Generate 4 UUIDs to map the following connections:
|
||||
|
||||
- `UUID_B_REVERSE`: Tunnel control for Server B.
|
||||
- `UUID_B_DIRECT`: Data traffic for Server B.
|
||||
- `UUID_C_REVERSE`: Tunnel control for Server C.
|
||||
- `UUID_C_DIRECT`: Data traffic for Server C.
|
||||
|
||||
### Policy Routing (Table 100)
|
||||
### Phase 2: Host Networking
|
||||
|
||||
Apply the routing configuration script on **EVERY** server node to set up the kernel parameters and routing Table 100. This tricks the kernel into handing the packet to our TPROXY inbound listening on `127.0.0.1:12345`.
|
||||
On **EVERY** server node, perform the following:
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
1. **Initialize Routing**: Run the routing setup script to configure kernel parameters and Table 100.
|
||||
2. **Firewall Configuration**: Update `/etc/ufw/before.rules`. Insert the specific node rules immediately after the `*filter` header. These rules handle the `mangle` table logic required for TPROXY.
|
||||
3. **Reload**: Apply changes with `sudo ufw reload`.
|
||||
|
||||
# 1. Enable IP Forwarding
|
||||
sudo sysctl -w net.ipv4.ip_forward=1
|
||||
### Phase 3: Deployment
|
||||
|
||||
# 2. IP Rule for mark 0x1 -> table 100
|
||||
sudo ip rule add fwmark 0x1 lookup 100 priority 100
|
||||
Update your `xray.jsonc` configurations with the generated UUIDs, your domain, and public IPs. Launch the stack using `docker compose up -d`. On Server A, the compose setup will also initialize the internal bridge network for services like AdGuard and Nginx.
|
||||
|
||||
# 3. Local route in table 100
|
||||
sudo ip route add local 0.0.0.0/0 dev lo table 100
|
||||
## Configuration Examples
|
||||
|
||||
### Server A: Hub (10.1.0.0/16)
|
||||
|
||||
The Hub handles reverse tunnel entries and routes traffic to the appropriate Spoke based on the 10.x.x.x range.
|
||||
Full configuration available here: [a/xray.jsonc](https://github.com/deytenit/xray-core-subnet-mimicry/blob/main/a/xray.jsonc)
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"inbounds": [
|
||||
{
|
||||
"port": 443,
|
||||
"protocol": "vless",
|
||||
"tag": "proxy-direct",
|
||||
"settings": {
|
||||
"clients": [
|
||||
{ "id": "REPLACE_WITH_UUID_B_REVERSE", "reverse": { "tag": "reverse-b" } },
|
||||
{ "id": "REPLACE_WITH_UUID_B_DIRECT" },
|
||||
// ... repeat for other Spokes
|
||||
],
|
||||
},
|
||||
},
|
||||
{
|
||||
"tag": "proxy-enclave",
|
||||
"protocol": "tunnel",
|
||||
"streamSettings": { "sockopt": { "tproxy": "tproxy", "mark": 255 } },
|
||||
},
|
||||
],
|
||||
"routing": {
|
||||
"rules": [
|
||||
{ "ip": ["10.2.0.0/16"], "outboundTag": "reverse-b" },
|
||||
{ "ip": ["10.3.0.0/16"], "outboundTag": "reverse-c" },
|
||||
],
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
### Server B: Spoke (10.2.0.0/16)
|
||||
|
||||
## 3. Firewall Interception
|
||||
The Spoke initiates the reverse connection to the Hub and handles local subnet breakout.
|
||||
Full configuration available here: [b/xray.jsonc](https://github.com/deytenit/xray-core-subnet-mimicry/blob/main/b/xray.jsonc)
|
||||
|
||||
Open `/etc/ufw/before.rules` and insert the specific node rules immediately after the `*filter` header requirements. Below is the configuration for Server A (Hub, `10.1.0.0/16`):
|
||||
|
||||
```text
|
||||
*mangle
|
||||
:XRAY - [0:0]
|
||||
:XRAY_MASK - [0:0]
|
||||
:DIVERT - [0:0]
|
||||
|
||||
# --- PREROUTING CHAIN (Traffic from other containers/nodes) ---
|
||||
-A XRAY -d 10.1.0.0/16 -j RETURN
|
||||
-A XRAY ! -d 10.0.0.0/8 -j RETURN
|
||||
-A XRAY -m mark --mark 0xff -j RETURN
|
||||
-A XRAY -p udp -j TPROXY --on-ip 127.0.0.1 --on-port 12345 --tproxy-mark 1
|
||||
-A XRAY -p tcp -j TPROXY --on-ip 127.0.0.1 --on-port 12345 --tproxy-mark 1
|
||||
-A PREROUTING -j XRAY
|
||||
|
||||
# --- OUTPUT CHAIN (Traffic originating from the server itself) ---
|
||||
-A XRAY_MASK -d 10.1.0.0/16 -j RETURN
|
||||
-A XRAY_MASK ! -d 10.0.0.0/8 -j RETURN
|
||||
-A XRAY_MASK -m mark --mark 0xff -j RETURN
|
||||
-A XRAY_MASK -p udp -j MARK --set-mark 1
|
||||
-A XRAY_MASK -p tcp -j MARK --set-mark 1
|
||||
-A OUTPUT -j XRAY_MASK
|
||||
|
||||
# --- DIVERT Optimization ---
|
||||
-A DIVERT -j MARK --set-mark 1
|
||||
-A DIVERT -j ACCEPT
|
||||
-I PREROUTING -p tcp -m socket -j DIVERT
|
||||
|
||||
COMMIT
|
||||
```jsonc
|
||||
{
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "vless",
|
||||
"tag": "forward-a-reverse",
|
||||
"settings": {
|
||||
"address": "A-EXTERNAL-IP",
|
||||
"id": "REPLACE_WITH_UUID_B_REVERSE",
|
||||
"reverse": { "tag": "reverse-b" },
|
||||
},
|
||||
},
|
||||
{
|
||||
"protocol": "vless",
|
||||
"tag": "forward-a",
|
||||
"settings": {
|
||||
"address": "A-EXTERNAL-IP",
|
||||
"id": "REPLACE_WITH_UUID_B_DIRECT",
|
||||
},
|
||||
},
|
||||
],
|
||||
"routing": {
|
||||
"rules": [
|
||||
{ "inboundTag": ["proxy-enclave"], "outboundTag": "forward-a" },
|
||||
{ "inboundTag": ["reverse-b"], "outboundTag": "forward-direct" },
|
||||
{ "ip": ["10.2.0.0/16"], "outboundTag": "forward-direct" },
|
||||
{ "ip": ["10.0.0.0/8"], "outboundTag": "forward-a" },
|
||||
],
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
Reload UFW once applied:
|
||||
## Resources & Reference
|
||||
|
||||
```bash
|
||||
sudo ufw reload
|
||||
```
|
||||
For a complete, automated example of this architecture, check out the following repository:
|
||||
|
||||
---
|
||||
- [xray-core-subnet-mimicry on GitHub](https://github.com/deytenit/xray-core-subnet-mimicry/tree/main)
|
||||
|
||||
## Resources
|
||||
Additional technical references:
|
||||
|
||||
- [Xray-core Official Documentation](https://xtls.github.io/)
|
||||
- [Xray Reverse Proxy Documentation](https://xtls.github.io/en/config/reverse.html)
|
||||
- [Project X (Xray) GitHub](https://github.com/XTLS/Xray-core)
|
||||
- [Understanding TPROXY (Cloudflare Blog)](https://blog.cloudflare.com/how-we-built-spectrum/)
|
||||
- [Linux Kernel TPROXY Documentation](https://www.kernel.org/doc/Documentation/networking/tproxy.txt)
|
||||
- [Cloudflare Blog: TPROXY](https://blog.cloudflare.com/how-we-built-spectrum/)
|
||||
@@ -1,182 +1,154 @@
|
||||
---
|
||||
title: 'Мимикрия подсетей Xray'
|
||||
description: 'Построение распределённой приватной сети 10.0.0.0/8 с использованием Xray-core'
|
||||
createdDate: 2026-03-08
|
||||
tags: ['networking', 'guide']
|
||||
title: 'Имитация подсети Xray (10.0.0.0/8)'
|
||||
description: 'Создание распределенной частной сети с использованием Xray-core и обратного туннелирования'
|
||||
createdDate: 2026-03-20
|
||||
tags: ['networking', 'xray', 'guide']
|
||||
---
|
||||
|
||||
> Это руководство предназначено **исключительно для образовательных целей**. Оно демонстрирует маршрутизацию в Xray-core и подход к мимикрии приватной подсети. Материал НЕ предназначен для обхода ограничений или незаконной деятельности. Используйте эти знания ответственно и в соответствии с местным законодательством.
|
||||
> **ТОЛЬКО ДЛЯ ОБРАЗОВАТЕЛЬНЫХ ЦЕЛЕЙ**
|
||||
> Этот проект разработан как техническая демонстрация возможностей маршрутизации Xray-core и имитации частных подсетей. Он НЕ предназначен для обхода ограничений или незаконной деятельности. Используйте эти знания ответственно и в соответствии с местным законодательством.
|
||||
|
||||
## Зачем нужна мимикрия подсети?
|
||||
Это руководство описывает, как развернуть распределенную инфраструктуру (например, для заметок или любого другого сервиса), используя непрерывную частную подсеть `10.0.0.0/8`, имитируемую на различных серверах с помощью **Xray-core** и **обратного туннелирования**.
|
||||
|
||||
Если построить "плоскую сеть" (Layer 3) поверх публичного интернета, можно получить единое приватное адресное пространство (`10.0.0.0/8`), распределенное между несколькими отдельными серверами.
|
||||
## Технический разбор и архитектура
|
||||
|
||||
- **Распределенная топология**: каждый узел выступает в роли основного шлюза для своего сегмента `/16` (например, Hub для `10.1.0.0/16`, Spoke для `10.2.0.0/16` и `10.3.0.0/16`).
|
||||
- **Преодоление NAT**: Spoke-узлы (Bridges) сами инициируют соединения с Hub-узлом (Portal), благодаря чему даже узлы за NAT остаются доступными.
|
||||
- **Централизованное разрешение DNS**: сетевые DNS-политики единообразно применяются через центральный резолвер на Hub.
|
||||
### Концепция виртуальной подсети
|
||||
|
||||
---
|
||||
Мы создаем «плоскую сеть» (Layer 3) поверх публичного интернета. Каждый узел выступает в качестве полномочного шлюза для своего собственного сегмента `/16` из диапазона `10.0.0.0/8`. Это обеспечивает бесперебойную связь между серверами, как если бы они находились в одной локальной сети.
|
||||
|
||||
## Обзор технического стека
|
||||
### Наука перехвата (TPROXY)
|
||||
|
||||
1. **Xray-core**: движок маршрутизации для VLESS-соединений, reverse-туннелей и TPROXY-перехвата.
|
||||
2. **TPROXY**: прозрачное проксирование в таблице Linux Mangle, которое перехватывает TCP/UDP-трафик и сохраняет исходный IP назначения.
|
||||
3. **Policy Routing**: использование `ip rule` и таблицы маршрутизации 100 для принудительной отправки перехваченных пакетов в локальный loopback, где их обрабатывает Xray.
|
||||
4. **Mux.cool**: протокол мультиплексирования, который упаковывает сотни виртуальных соединений (TCP/UDP-потоков) в одно физическое TLS-соединение.
|
||||
5. **AdGuard Home**: централизованный DNS-резолвер для всей подсети.
|
||||
6. **Nginx**: используется как маскировка на основном публичном входном порту, чтобы скрыть инстанс Xray.
|
||||
В отличие от `REDIRECT`, который работает только для TCP и изменяет IP-адрес назначения, **TPROXY** (Transparent Proxy) позволяет Xray перехватывать как TCP, так и UDP, сохраняя при этом исходные заголовки пакетов.
|
||||
|
||||
---
|
||||
- **Механизм**: Когда пакет, предназначенный для `10.x.x.x`, попадает в цепочку `PREROUTING` или `OUTPUT`, таблица Linux Mangle помечает его меткой `0x1`.
|
||||
- **Сохранение**: Входящий поток `tunnel` в Xray использует опцию сокета `tproxy` для чтения исходного IP-адреса назначения из метаданных сокета, что позволяет правильно маршрутизировать пакет.
|
||||
|
||||
## 1. Стек развертывания
|
||||
### Политика маршрутизации (Таблица 100)
|
||||
|
||||
Эта конфигурация описывает центральный Hub (сервер A), который выступает как Portal для подключений Spoke-узлов. На Hub размещены централизованный DNS и fallback-маскировка через Nginx.
|
||||
Хотя метки брандмауэра идентифицируют перехваченные пакеты, они сами по себе не изменяют путь маршрутизации. Чтобы перенаправить этот трафик в Xray, мы используем **Policy Routing**:
|
||||
|
||||
```yaml
|
||||
name: 'a'
|
||||
1. **Правило (`ip rule`)**: `ip rule add fwmark 1 lookup 100` предписывает сетевому стеку использовать пользовательскую таблицу маршрутизации для помеченных пакетов.
|
||||
2. **Таблица (`ip route`)**: Таблица 100 настроена с параметром `local default dev lo`, что заставляет систему рассматривать все IP-адреса назначения как локальные и направлять их на интерфейс петли (loopback).
|
||||
3. **Передача**: Xray, прослушивающий `127.0.0.1:12345` с опцией `tproxy`, перехватывает пакет с интерфейса loopback.
|
||||
4. **Предотвращение петель**: Мы используем `mark: 255` в исходящих потоках Xray, чтобы исключить его собственный трафик из перехвата, предотвращая бесконечные циклы маршрутизации.
|
||||
|
||||
services:
|
||||
xray:
|
||||
image: ghcr.io/xtls/xray-core:26.1.23
|
||||
container_name: a-xray
|
||||
network_mode: host
|
||||
volumes:
|
||||
- ./xray.jsonc:/etc/xray/config.jsonc:ro
|
||||
- /etc/letsencrypt/live:/etc/letsencrypt/live:ro
|
||||
command: -c '/etc/xray/config.jsonc'
|
||||
restart: unless-stopped
|
||||
cap_add:
|
||||
- NET_ADMIN
|
||||
- NET_RAW
|
||||
### Механизм обратного прокси
|
||||
|
||||
nginx:
|
||||
image: nginxinc/nginx-unprivileged:1.29-alpine
|
||||
container_name: a-nginx
|
||||
networks:
|
||||
direct:
|
||||
ipv4_address: 10.1.1.4
|
||||
restart: unless-stopped
|
||||
security_opt:
|
||||
- no-new-privileges:true
|
||||
Для доступа к серверам за NAT (Spokes) из центрального хаба Xray использует сложную архитектуру обратного прокси:
|
||||
|
||||
adguard:
|
||||
image: adguard/adguardhome:v0.107.72
|
||||
container_name: root-adguard
|
||||
volumes:
|
||||
- adguard-work:/opt/adguardhome/work
|
||||
- adguard-conf:/opt/adguardhome/conf
|
||||
networks:
|
||||
direct:
|
||||
ipv4_address: 10.1.1.3
|
||||
restart: unless-stopped
|
||||
cap_add:
|
||||
- NET_BIND_SERVICE
|
||||
- SYS_NICE
|
||||
- CAP_CHOWN
|
||||
security_opt:
|
||||
- no-new-privileges:true
|
||||
- **Bridge (Spoke)**: Инициирует соединение с порталом. Он действует как клиент для туннеля, но функционально ведет себя как сервер после установления соединения.
|
||||
- **Portal (Hub)**: Прослушивает входящие соединения от Bridge и использует «фиктивные домены» (Dummy Domains) для их идентификации, ретранслируя трафик через установленные туннели.
|
||||
- **Мультиплексирование (Mux)**: Использует [Mux.cool](https://xtls.github.io/en/development/protocols/muxcool.html) для упаковки сотен виртуальных потоков в одно физическое TLS-соединение, что снижает накладные расходы и позволяет обходить тайм-ауты NAT.
|
||||
|
||||
networks:
|
||||
direct:
|
||||
name: a-direct
|
||||
driver: bridge
|
||||
ipam:
|
||||
config:
|
||||
- subnet: 10.1.0.0/16 # Using the full /16 as defined for Server A
|
||||
gateway: 10.1.0.1
|
||||
## Руководство по настройке
|
||||
|
||||
volumes:
|
||||
adguard-work:
|
||||
name: a-adguard-work
|
||||
adguard-conf:
|
||||
name: a-adguard-conf
|
||||
### Этап 0: Предварительные требования (только для сервера А)
|
||||
|
||||
Серверу А (Hub) требуется действующий SSL-сертификат для XTLS-Vision. Направьте ваш домен (`A-DOMAIN`) на публичный IP сервера А и убедитесь, что сертификаты доступны (например, через Certbot) по адресу `/etc/letsencrypt/live/A-DOMAIN/`.
|
||||
|
||||
### Этап 1: Безопасность и идентификация
|
||||
|
||||
Для каждого соединения требуется уникальный UUID. Сгенерируйте 4 UUID для сопоставления следующих соединений:
|
||||
|
||||
- `UUID_B_REVERSE`: Управление туннелем для сервера B.
|
||||
- `UUID_B_DIRECT`: Трафик данных для сервера B.
|
||||
- `UUID_C_REVERSE`: Управление туннелем для сервера C.
|
||||
- `UUID_C_DIRECT`: Трафик данных для сервера C.
|
||||
|
||||
### Этап 2: Настройка хоста
|
||||
|
||||
На **КАЖДОМ** узле сервера выполните следующее:
|
||||
|
||||
1. **Инициализация маршрутизации**: Запустите скрипт настройки маршрутизации для конфигурации параметров ядра и таблицы 100.
|
||||
2. **Настройка брандмауэра**: Обновите `/etc/ufw/before.rules`. Вставьте специфические правила узла сразу после заголовка `*filter`. Эти правила обрабатывают логику таблицы `mangle`, необходимую для TPROXY.
|
||||
3. **Перезагрузка**: Примените изменения с помощью `sudo ufw reload`.
|
||||
|
||||
### Этап 3: Развертывание
|
||||
|
||||
Обновите конфигурации `xray.jsonc`, указав сгенерированные UUID, ваш домен и публичные IP-адреса. Запустите стек с помощью `docker compose up -d`. На сервере А установка compose также инициализирует внутреннюю мостовую сеть для таких сервисов, как AdGuard и Nginx.
|
||||
|
||||
## Примеры конфигурации
|
||||
|
||||
### Сервер A: Хаб (10.1.0.0/16)
|
||||
|
||||
Хаб обрабатывает входы обратных туннелей и маршрутизирует трафик в соответствующий Spoke на основе диапазона 10.x.x.x.
|
||||
Полная конфигурация доступна здесь: [a/xray.jsonc](https://github.com/deytenit/xray-core-subnet-mimicry/blob/main/a/xray.jsonc)
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"inbounds": [
|
||||
{
|
||||
"port": 443,
|
||||
"protocol": "vless",
|
||||
"tag": "proxy-direct",
|
||||
"settings": {
|
||||
"clients": [
|
||||
{ "id": "REPLACE_WITH_UUID_B_REVERSE", "reverse": { "tag": "reverse-b" } },
|
||||
{ "id": "REPLACE_WITH_UUID_B_DIRECT" },
|
||||
// ... повторите для других Spokes
|
||||
],
|
||||
},
|
||||
},
|
||||
{
|
||||
"tag": "proxy-enclave",
|
||||
"protocol": "tunnel",
|
||||
"streamSettings": { "sockopt": { "tproxy": "tproxy", "mark": 255 } },
|
||||
},
|
||||
],
|
||||
"routing": {
|
||||
"rules": [
|
||||
{ "ip": ["10.2.0.0/16"], "outboundTag": "reverse-b" },
|
||||
{ "ip": ["10.3.0.0/16"], "outboundTag": "reverse-c" },
|
||||
],
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
### Сервер B: Узел Spoke (10.2.0.0/16)
|
||||
|
||||
## 2. Конфигурация и маршрутизация
|
||||
Spoke инициирует обратное соединение с Хабом и обрабатывает выход в локальную подсеть.
|
||||
Полная конфигурация доступна здесь: [b/xray.jsonc](https://github.com/deytenit/xray-core-subnet-mimicry/blob/main/b/xray.jsonc)
|
||||
|
||||
### Генерация UUID-идентификаторов
|
||||
|
||||
Каждому соединению нужен собственный криптографический "ключ". Для сопоставления с конфигами вам понадобятся 4 UUID.
|
||||
|
||||
```bash
|
||||
# Generate UUIDs for the Server B and Server C mappings
|
||||
docker run --rm ghcr.io/xtls/xray-core uuid
|
||||
```jsonc
|
||||
{
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "vless",
|
||||
"tag": "forward-a-reverse",
|
||||
"settings": {
|
||||
"address": "A-EXTERNAL-IP",
|
||||
"id": "REPLACE_WITH_UUID_B_REVERSE",
|
||||
"reverse": { "tag": "reverse-b" },
|
||||
},
|
||||
},
|
||||
{
|
||||
"protocol": "vless",
|
||||
"tag": "forward-a",
|
||||
"settings": {
|
||||
"address": "A-EXTERNAL-IP",
|
||||
"id": "REPLACE_WITH_UUID_B_DIRECT",
|
||||
},
|
||||
},
|
||||
],
|
||||
"routing": {
|
||||
"rules": [
|
||||
{ "inboundTag": ["proxy-enclave"], "outboundTag": "forward-a" },
|
||||
{ "inboundTag": ["reverse-b"], "outboundTag": "forward-direct" },
|
||||
{ "ip": ["10.2.0.0/16"], "outboundTag": "forward-direct" },
|
||||
{ "ip": ["10.0.0.0/8"], "outboundTag": "forward-a" },
|
||||
],
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
Соответствие такое:
|
||||
## Ресурсы и ссылки
|
||||
|
||||
- `UUID_B_REVERSE`: управляющий туннель для сервера B.
|
||||
- `UUID_B_DIRECT`: пользовательский трафик сервера B.
|
||||
- `UUID_C_REVERSE`: управляющий туннель для сервера C.
|
||||
- `UUID_C_DIRECT`: пользовательский трафик сервера C.
|
||||
Для получения полного автоматизированного примера этой архитектуры посетите следующий репозиторий:
|
||||
|
||||
### Маршрутизация по политикам (таблица 100)
|
||||
- [xray-core-subnet-mimicry на GitHub](https://github.com/deytenit/xray-core-subnet-mimicry/tree/main)
|
||||
|
||||
Примените скрипт маршрутизации на **каждом** серверном узле, чтобы настроить параметры ядра и таблицу маршрутизации 100. Это заставляет ядро передавать пакет в наш TPROXY inbound, который слушает `127.0.0.1:12345`.
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
|
||||
# 1. Enable IP Forwarding
|
||||
sudo sysctl -w net.ipv4.ip_forward=1
|
||||
|
||||
# 2. IP Rule for mark 0x1 -> table 100
|
||||
sudo ip rule add fwmark 0x1 lookup 100 priority 100
|
||||
|
||||
# 3. Local route in table 100
|
||||
sudo ip route add local 0.0.0.0/0 dev lo table 100
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Перехват в firewall
|
||||
|
||||
Откройте `/etc/ufw/before.rules` и сразу после обязательного заголовка `*filter` добавьте правила конкретного узла. Ниже пример для сервера A (Hub, `10.1.0.0/16`):
|
||||
|
||||
```text
|
||||
*mangle
|
||||
:XRAY - [0:0]
|
||||
:XRAY_MASK - [0:0]
|
||||
:DIVERT - [0:0]
|
||||
|
||||
# --- PREROUTING CHAIN (Traffic from other containers/nodes) ---
|
||||
-A XRAY -d 10.1.0.0/16 -j RETURN
|
||||
-A XRAY ! -d 10.0.0.0/8 -j RETURN
|
||||
-A XRAY -m mark --mark 0xff -j RETURN
|
||||
-A XRAY -p udp -j TPROXY --on-ip 127.0.0.1 --on-port 12345 --tproxy-mark 1
|
||||
-A XRAY -p tcp -j TPROXY --on-ip 127.0.0.1 --on-port 12345 --tproxy-mark 1
|
||||
-A PREROUTING -j XRAY
|
||||
|
||||
# --- OUTPUT CHAIN (Traffic originating from the server itself) ---
|
||||
-A XRAY_MASK -d 10.1.0.0/16 -j RETURN
|
||||
-A XRAY_MASK ! -d 10.0.0.0/8 -j RETURN
|
||||
-A XRAY_MASK -m mark --mark 0xff -j RETURN
|
||||
-A XRAY_MASK -p udp -j MARK --set-mark 1
|
||||
-A XRAY_MASK -p tcp -j MARK --set-mark 1
|
||||
-A OUTPUT -j XRAY_MASK
|
||||
|
||||
# --- DIVERT Optimization ---
|
||||
-A DIVERT -j MARK --set-mark 1
|
||||
-A DIVERT -j ACCEPT
|
||||
-I PREROUTING -p tcp -m socket -j DIVERT
|
||||
|
||||
COMMIT
|
||||
```
|
||||
|
||||
После применения перезагрузите UFW:
|
||||
|
||||
```bash
|
||||
sudo ufw reload
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Ресурсы
|
||||
Дополнительные технические материалы:
|
||||
|
||||
- [Официальная документация Xray-core](https://xtls.github.io/)
|
||||
- [Документация Xray Reverse Proxy](https://xtls.github.io/en/config/reverse.html)
|
||||
- [Project X (Xray) на GitHub](https://github.com/XTLS/Xray-core)
|
||||
- [Документация Linux Kernel по TPROXY](https://www.kernel.org/doc/Documentation/networking/tproxy.txt)
|
||||
- [Блог Cloudflare: TPROXY](https://blog.cloudflare.com/how-we-built-spectrum/)
|
||||
- [Понимание TPROXY (блог Cloudflare)](https://blog.cloudflare.com/how-we-built-spectrum/)
|
||||
- [Документация TPROXY в ядре Linux](https://www.kernel.org/doc/Documentation/networking/tproxy.txt)
|
||||
Reference in new issue
Block a user