TUN-режим (полнотуннельный VPN)

TUN-режим обеспечивает полнотуннельный VPN, где весь трафик клиента маршрутизируется через сервер. Он отличается от SOCKS5 relay-режима, который требует настройки SOCKS5 в каждом приложении.

---

TUN-режим и SOCKS5-режим

Возможность	TUN-режим	SOCKS5-режим
Маршрутизация трафика	Полный туннель, все приложения	По приложениям, требует настройки SOCKS5
Сложность настройки	NAT на стороне сервера	Настройка приложений на клиенте
Производительность	Обработка пакетов на уровне ядра	Relay на прикладном уровне
Сценарии	Полная приватность, весь трафик	Туннелирование отдельных приложений

В TUN-режиме клиент создаёт виртуальный TUN-интерфейс и направляет весь трафик через него. Сервер получает эти пакеты и NAT-ит их в интернет, аналогично традиционному VPN.

---

Требования к настройке NAT

TUN-режим требует, чтобы сервер работал как NAT-шлюз для клиентского трафика. На сервере должен быть включён IP-форвардинг и настроены корректные правила NAT.

Linux

Включите IP-форвардинг:

# Temporary (resets on reboot)
sudo sysctl -w net.ipv4.ip_forward=1

# Permanent
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Настройте NAT через iptables:

# Assuming your public interface is eth0
# -s should match [server.network].dhcp_range in server.toml
sudo iptables -t nat -A POSTROUTING -s 10.200.0.0/24 -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Через nftables:

sudo nft add table ip nat
sudo nft add chain ip nat postrouting { type nat hook postrouting priority 100 \; }
sudo nft add rule ip nat postrouting oifname "eth0" masquerade
sudo nft add chain ip filter forward { type filter hook forward priority 0 \; }
sudo nft add rule ip filter forward iifname "tun0" oifname "eth0" accept
sudo nft add rule ip filter forward iifname "eth0" oifname "tun0" ct state related,established accept

Замените eth0 на имя вашего сетевого интерфейса (ip addr или ip link для проверки).

macOS

macOS не поддерживает TUN-режим на стороне сервера. Для серверов на macOS используйте SOCKS5-режим или запустите rvpn-server внутри FreeBSD/Linux-виртуалки с правильной настройкой NAT.

FreeBSD

Включите IP-форвардинг:

# Temporary
sudo sysctl -w net.inet.ip.forwarding=1

# Permanent in /etc/rc.conf
echo 'gateway_enable="YES"' | sudo tee -a /etc/rc.conf

Настройте NAT через ipfw:

sudo sysctl -w net.inet.ip.fw.enable=1
sudo natd -s -m -u -dynamic -i nat0

# Or using ipfw rules directly
sudo ipfw add 100 nat 1 all from any to any via tun0

Для полной настройки ipfw/natd добавьте в /etc/rc.conf:

firewall_enable="YES"
firewall_type="OPEN"
natd_enable="YES"
natd_interface="vtnet0"  # your public interface

---

Конфигурация сервера для TUN-режима

[server]
bind_address      = "0.0.0.0:443"
tls_cert_file     = "/etc/letsencrypt/live/your-domain.com/fullchain.pem"
tls_key_file      = "/etc/letsencrypt/live/your-domain.com/privkey.pem"
identity_key_file = "/etc/rvpn/server_identity.key"
websocket_path    = "/api/v1/ws"

[server.network]
nat_enabled = true
dhcp_range  = "10.200.0.0/24"

[server.tun]
enabled     = true
tun_ip      = "10.200.0.1/24"
mtu         = 1420
dns_servers = ["1.1.1.1", "8.8.8.8"]

Ключевые настройки для TUN-режима:

• websocket_path — должен быть /api/v1/ws, чтобы клиенты TUN-режима могли достичь точки TUN по адресу /api/v1/ws/tun
• [server.network].nat_enabled и dhcp_range — поля-подсказки при запуске, используемые для проверки ваших NAT-правил iptables. Сам NAT настраивается вашим оператором (iptables/pf); см. руководство Установка сервера.
• [server.tun].tun_ip — подсеть, из которой выдаются IP клиентам. Измените её, если 10.200.0.0/24 конфликтует с вашей локальной сетью.
• [server.tun].dns_servers — DNS-резолверы, передаваемые клиентам через туннель

---

Запуск сервера в TUN-режиме

Прямой запуск

sudo rvpn-server -c /etc/rvpn/server.toml

Как systemd-сервис

Сервис запускает тот же самый бинарник независимо от режима. Убедитесь, что в server.toml заданы настройки TUN-режима, как показано выше.

sudo systemctl restart rvpn-server

---

Шаги проверки

Проверьте логи сервера:

sudo journalctl -u rvpn-server -f

Ищите записи, показывающие путь WebSocket и обработчик TUN:

INFO  Starting rVPN Server on 0.0.0.0:443
INFO  Server listening on wss://0.0.0.0:443
INFO  WebSocket endpoint (mobile TUN): /api/v1/ws/tun
INFO  TUN server started on 10.200.0.1/24

Проверьте, активны ли правила NAT (Linux):

sudo iptables -t nat -L POSTROUTING -v
sudo iptables -L FORWARD -v

Проверьте связность:

Подключите клиент в TUN-режиме и проверьте:

1. Клиент получает IP из dhcp_range (например, 10.200.0.x)
2. Клиент может пинговать внешние IP (например, 8.8.8.8)
3. DNS-запросы клиента корректно разрешаются

Проверьте активные соединения на сервере:

sudo ss -tlnp | grep 443
sudo ip addr show tun0  # if interface exists

---

Устранение неполадок

Клиент не может подключиться

• Убедитесь, что порт 443 открыт в брандмауэре
• Убедитесь, что websocket_path — это /api/v1/ws (клиенты автоматически добавляют /tun)
• Просмотрите логи сервера на ошибки TLS или WebSocket-апгрейда

Трафик уходит, но ничего не возвращается

• Убедитесь, что IP-форвардинг включён: sysctl net.ipv4.ip_forward
• Проверьте правила NAT: iptables -t nat -L POSTROUTING
• Убедитесь, что группа безопасности/брандмауэр сервера разрешает исходящий трафик на всех портах

Нет доступа в интернет на клиенте

• Убедитесь, что nat_enabled = true в server.toml
• Убедитесь, что диапазон DHCP не конфликтует с существующими сетями
• Проверьте, что dns_servers доступны с сервера

TUN-интерфейс на сервере

Сервер создаёт настоящий TUN-интерфейс (например, tun0 с IP 10.200.0.1), когда TUN-режим включён. Это обеспечивает настоящий туннель TUN-to-TUN:

Компонент	Описание
TUN сервера	tun0 с IP 10.200.0.1/24
TUN клиента	Виртуальный интерфейс с IP из 10.200.0.x
Маршрутизация	Ядро направляет пакеты через TUN-интерфейс

TUN-интерфейс сервера отвечает за:

• Запись пакетов, полученных от клиентов, в ядро
• Чтение ответных пакетов из ядра
• Пересылку ответов соответствующему клиенту

---

Замечания по обратному прокси

При работе за обратным прокси (Caddy, nginx, HAProxy) убедитесь, что прокси пересылает /api/v1/ws/tun на сервер. Конфигурация прокси для TUN-режима идентична SOCKS5-режиму — оба используют один и тот же базовый WebSocket-путь.

См. Настройка обратного прокси для полных конфигураций прокси.

---

Краткая справка

Параметр	Значение
WebSocket-путь	/api/v1/ws
TUN-точка	/api/v1/ws/tun
Порт по умолчанию	443
Диапазон DHCP по умолчанию	10.200.0.0/24
Требуется NAT	Да