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

Решения типичных проблем с rVPN.

Проблемы с подключением

«Failed to connect» или таймаут

Симптомы: клиент зависает на Connecting to wss://... и в итоге падает по таймауту.

Проверьте:

Порт сервера доступен:

# From a different machine
nc -zv your-server.com 443
curl -I https://your-server.com/api/v1/ws

Брандмауэр разрешает порт 443:

sudo ufw status  # UFW
sudo iptables -L -n | grep 443  # iptables

TLS-сертификат действителен:

openssl s_client -connect your-server.com:443 -servername your-server.com </dev/null 2>/dev/null | openssl x509 -noout -dates

WebSocket-путь правильный. Клиенты подключаются к {websocket_path} (например, /api/v1/ws). Если ваш сервер использует другой путь, обновите client.toml.

«TLS handshake failed»

Симптомы: клиент показывает TLS handshake failed или certificate verify failed.

Причины и решения:

Сертификат Let’s Encrypt не обновлён:

sudo certbot certificates
sudo systemctl reload rvpn-server

Неверное имя хоста в server_address:

# The hostname must match the certificate
server_address = "wss://your-server.com/api/v1/ws"  # Certificate must be for your-server.com

Несоответствие SNI:

# If connecting through a CDN or by IP
server_address = "wss://10.0.0.1/api/v1/ws"
sni_hostname   = "your-server.com"  # Certificate hostname

iOS: проблема проверки сертификата (старые сборки): Убедитесь, что вы пересобрали Rust-библиотеку после обновления. TLS-стек rVPN использует BoringSSL со встроенным корневым хранилищем Mozilla и не обращается к keychain iOS, поэтому ротация сертификатов или изменения доверия на уровне ОС не применяются до пересборки приложения.

«Connection refused» сразу

Симптомы: клиент моментально падает с Connection refused.

Проверьте:

# Is the server running?
sudo systemctl status rvpn-server

# Is it listening on the right port?
sudo ss -tlnp | grep 443

# Can you connect locally? (uses whatever bind_address is set to)
curl -I https://127.0.0.1:443/api/v1/ws --insecure

«X3DH handshake failed»

Симптомы: соединение начинается, но падает при установке шифрования.

Причины:

Несоответствие набора prekey: Клиент и сервер должны использовать один и тот же набор prekey. Если сервер провёл ротацию ключей, а у клиента старый набор, это может дать сбой.

# On server: regenerate prekey bundle
rvpn-server prekey-bundle
# Distribute new prekey-bundle.json to clients

Ключ идентификации изменился: Если ключ идентификации сервера был пересоздан, всем клиентам нужен новый набор prekey.

«Too many connections» или превышен лимит

Симптомы: Connection refused или Rate limited после успешной работы некоторое время.

Проверьте серверные лимиты:

[server.rate_limit]
max_connections_per_ip    = 500      # default
max_handshakes_per_minute = 2000     # default

Каждое клиентское соединение занимает один слот. Значения по умолчанию щедрые — если у вас очень большой парк на одном egress-IP, поднимите их; если вас зондируют и вы хотите лимиты жёстче, опустите.

Проблемы TUN-режима

Клиент подключается, но нет доступа в интернет

Проверка 1: IP-форвардинг на сервере:

sysctl net.ipv4.ip_forward
# Must return: net.ipv4.ip_forward = 1

Если не включено:

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

Проверка 2: правила NAT на сервере:

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

Вы должны видеть правила MASQUERADE и FORWARD ACCEPT.

Если их нет:

sudo iptables -t nat -A POSTROUTING -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

Проверка 3: группа безопасности/брандмауэр сервера разрешает исходящий трафик: Сервер должен иметь возможность инициировать исходящие соединения на любой IP на любом порту, чтобы NAT работал.

Проверка 4: NAT включён в server.toml:

[server.network]
nat_enabled = true

Проверка 5: маршруты клиента:

# On client, check routing table
ip route show  # Linux
route -n get 0.0.0.0  # macOS

# Default route should point to tunnel interface

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

Симптомы: вы можете пинговать внешние IP, но ответа нет. Логи сервера показывают ретрансляцию фреймов, но нет «Relay completed».

Первопричина: SOCKS5-ответ был отправлен до готовности туннеля.

Исправление: это был баг в старых версиях. Пересоберите и разверните заново:

cd rvpn-ios && ./build_rust.sh

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

INFO  rvpn_server: Listening on 0.0.0.0:443
INFO  rvpn_server: WebSocket path: /api/v1/ws
INFO  rvpn_server: TUN mode enabled

Если TUN-режим не включён, клиенты в TUN-режиме не смогут корректно подключиться.

TUN-интерфейс не создаётся на сервере

Проверьте:

sudo ip addr show tun0
sudo ip link show tun0

Если интерфейса нет:

Убедитесь, что enabled = true в [server.tun]
Проверьте логи сервера на ошибки при создании интерфейса
Попробуйте другое имя интерфейса на случай конфликта имён

Клиент не может пинговать TUN IP сервера

Проверьте:

# On server
ping 10.200.0.1  # From server to itself via tun0

# On client
ping 10.200.0.1  # Client should be able to reach server's TUN IP

Если клиент не может достучаться до 10.200.0.1, туннель установлен некорректно.

Проблемы SOCKS5-режима

Приложения не идут через прокси

Проверка 1: прокси запущен:

curl --socks5 127.0.0.1:1080 https://api.ipify.org

Если это возвращает IP VPN-сервера, прокси работает.

Проверка 2: системные настройки прокси: Убедитесь, что ваша система или приложение настроены на использование 127.0.0.1:1080 как SOCKS5-прокси.

Проверка 3: настройки прокси в браузере: Chrome и Edge используют системные настройки прокси. У Firefox свои собственные настройки прокси.

Проверка 4: специфика приложения: Некоторые приложения не поддерживают SOCKS5 (только HTTP-прокси). Используйте адаптер SOCKS5-в-HTTP или переключитесь на TUN-режим.

DNS-утечки в SOCKS5-режиме

Симптомы: тест DNS-утечек показывает DNS вашего провайдера, а не VPN.

Исправление: включите DNS-прокси:

[dns_proxy]
enabled        = true
listen_address = "127.0.0.1:53"

Настройте системный DNS на 127.0.0.1. См. Защиту от DNS-утечек для подробной настройки.

Специфика Chrome: Chrome использует собственный безопасный DNS-резолвер по умолчанию, который обходит системный DNS и VPN-туннель.

На Desktop/Android: перейдите в Настройки → Конфиденциальность и безопасность → Безопасность → Использовать безопасный DNS и отключите.
Очистите DNS-кеш Chrome: посетите chrome://net-internals/#dns и нажмите Clear host cache.
На iOS: принудительно закройте Chrome или очистите данные браузера, чтобы сбросить кеш.

Ограничения соединения на поток (компромисс мультиплексирования)

multiplex по умолчанию false — стандартный, рекомендуемый режим, — потому что «один WebSocket на поток» сливается с шаблоном трафика обычного браузинга и обходит DPI-классификаторы, ловящие форму мультиплексирования. Компромисс в том, что активный браузер может открыть десятки одновременных WebSocket’ов и на общих egress-IP упереться в серверный лимит max_connections_per_ip.

Два способа справиться:

Попросите администратора сервера повысить лимиты:
```
[server.rate_limit]
max_connections_per_ip    = 1000
max_handshakes_per_minute = 5000
```
Включите мультиплексирование на клиенте, чтобы один туннель обслуживал все потоки (меньше задержка, но более отличительный шаблон трафика):
```
[socks5]
multiplex = true
```

Медленная скорость соединения

Возможные причины:

Высокая задержка: VPN-сервер географически далеко
Перегрузка сервера: слишком много соединений к одному серверу
Ограничение полосы: upstream сервера насыщен
Проблемы с MTU: фрагментация пакетов на высоколатентных каналах

Решения:

Снизьте MTU в client.toml:

[tun]
mtu = 1280

Попробуйте другой сервер, ближе к вам
Проверьте нагрузку сервера: uptime, htop
Отключите IPv6, если он не нужен:

[network]
ipv6_enabled = false
prefer_ipv4  = true

Проблемы приложения iOS

«Failed to start VPN»

Проверьте:

Адрес сервера начинается с wss:// (не https://)
Ключ идентификации сгенерирован (Settings -> Identity)
Набор prekey импортирован
Сервер работает и доступен

Пересоберите Rust-библиотеку:

cd rvpn-ios && ./build_rust.sh

Соединение часто обрывается

Возможные причины:

Нестабильная сеть (переключение Wi-Fi на сотовую)
iOS переводит приложение в фоновой режим
VPN-профиль отзывается

Решения:

Включите «Always-on VPN» в iOS Настройки -> VPN
Проверьте наличие обновлений iOS
Пересоберите и переустановите приложение

IP не назначен

Причина: пул DHCP на сервере исчерпан.

Исправление: увеличьте диапазон DHCP на сервере:

[server.network]
dhcp_range = "10.200.0.0/22"  # /22 gives 1022 IPs instead of 254

Или отключите неиспользуемых клиентов.

Проблемы приложения macOS

VPN перестал работать после обновления приложения

Симптомы: приложение показывает «Connected», но трафик не проходит, или соединение сразу падает после обновления из App Store или пересборки из Xcode.

Причина: macOS хранит VPN-профили в системных настройках независимо от приложения. После обновления ссылка сохранённого профиля на туннельное расширение устаревает, поскольку подпись кода расширения изменилась. Приложение пытается запустить старое расширение, которого больше нет.

Исправление:

Откройте Системные настройки > VPN (или Системные настройки > Основные > VPN и фильтры на более новых версиях macOS).
Удалите запись rVPN.
Заново откройте приложение rVPN и подключитесь. Приложение автоматически создаст свежий профиль.

Это исправлено в версии 1.2.4 и новее, которая автоматически обнаруживает и заменяет устаревшие профили при запуске.

«Failed to start VPN» или соединение молча не удаётся

Проверьте:

Откройте приложение rVPN и перейдите в Settings (Cmd+,). Убедитесь, что профиль показывает зелёные галочки и для Identity Key, и для Prekey Bundle.
Адрес сервера должен начинаться с wss:// и не содержать лишних пробелов.
Сервер должен работать и быть доступным на порту 443.

Если в профиле нет ключей:

Сгенерируйте новый ключ идентификации в редакторе профиля.
Импортируйте набор prekey от администратора сервера.

Если ключи есть, но всё равно не работает:

Удалите VPN-профиль из Системных настроек > VPN.
Удалите приложение rVPN.
Переустановите из App Store.
Заново настройте профиль и подключитесь.

Туннель подключается, но DNS не разрешается

Приложение macOS запускает локальный DNS-прокси для разрешения DNS в split-tunnel. Если DNS не работает:

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

Как собрать диагностические логи

Логи уровня Rust (обходят редактирование логов macOS):

cat ~/Library/Group\ Containers/group.org.rvpn.client/rvpn_tunnel_rust.log

Системные логи (могут быть отредактированы на macOS 12+):

log show --predicate 'subsystem == "org.rvpn.tunnel"' --last 5m --level debug

Также можно использовать Console.app: фильтр по подсистеме org.rvpn.tunnel.

Проблемы раздельного туннелирования

Обходной трафик всё равно идёт через VPN

Проверьте:

[split_tunnel]
enabled = true  # Must be true for any bypass to work
builtin_bypass_countries = ["CN"]

Убедитесь, что правила загружены: Логи клиента должны показывать правила обхода при запуске:

INFO  rvpn_client: Split tunnel enabled, X networks bypassed

Проверьте таблицу маршрутизации:

ip route show  # Linux
route -n get 0.0.0.0  # macOS

Убедитесь, что обходные сети не в таблице маршрутизации VPN.

Стриминговый сервис всё ещё блокирует

Причины:

Стриминговые сервисы могут использовать GPS/локаль, а не только IP
Валюта оплаты и история аккаунта влияют на контент
IP CDN могут не совпадать с данными обхода по стране

Решения:

Очистите куки и кеш браузера/приложения
Используйте расширение браузера для подмены таймзоны и локали
Может потребоваться режим полного туннеля (без обхода)

Проблемы производительности

Высокая задержка через VPN

Проверьте задержку до сервера:

ping your-server.com

Если задержка высока даже до сервера, проблема в географическом расстоянии, а не в VPN.

Оптимизируйте:

Используйте сервер ближе к вам
Снизьте MTU при спутниковом или высоколатентном канале:

[tun]
mtu = 1280

Низкая пропускная способность

Проверьте:

Полосу сервера: тест iperf3 к серверу
Клиентское железо: шифрование ресурсоёмко на старых устройствах
Перегрузку сети

Оптимизируйте:

[performance]
worker_threads        = 4
crypto_worker_count   = 4
recv_buffer_size      = 262144
send_buffer_size      = 262144

Получение дополнительной информации

Включите отладочное логирование

Для подробных логов клиента:

RUST_LOG=debug rvpn -c ~/.config/rvpn/client.toml

Для логов сервера:

RUST_LOG=debug sudo rvpn-server -c /etc/rvpn/server.toml

Проверьте системные логи

# systemd journal
sudo journalctl -u rvpn-server -f

# kernel logs (for TUN interface issues)
dmesg | grep tun

Проверьте сетевые пути

# Trace path to server
traceroute your-server.com

# Trace path from server to target
# (on server) sudo tcpdump -i tun0 -n

Типичные сообщения в логах

Сообщение	Значение
`Listening on 0.0.0.0:443`	Сервер успешно запущен
`WebSocket path: /api/v1/ws`	WebSocket-точка настроена
`TUN mode enabled`	TUN-интерфейс сервера активен
`X3DH handshake complete`	Шифрование установлено
`NAT enabled`	Сервер будет маскарадировать клиентский трафик
`Relay completed`	Одна сессия ретрансляции данных завершена
`Too many connections`	Превышен лимит скорости