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

Решения типичных проблем r-vpn.

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

"Failed to connect" или тайм-аут¶

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

Проверка:

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

# С другой машины
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:

# Имя хоста должно соответствовать сертификату
server_address = "wss://your-server.com/api/v1/ws"  # Сертификат должен быть для your-server.com

Несовпадение SNI:

# При подключении через CDN или по IP
server_address = "wss://10.0.0.1/api/v1/ws"
sni_hostname   = "your-server.com"  # Имя хоста сертификата

iOS: Проблема проверки сертификата в песочнице (старые сборки): Убедитесь, что вы пересобрали библиотеку Rust после обновления. На iOS проверка сертификатов использует системное хранилище доверия через SecTrustEvaluateWithError.

"Connection refused" сразу¶

Симптомы: Клиент мгновенно завершается с Connection refused.

Проверка:

# Сервер запущен?
sudo systemctl status rvpn-server

# Он слушает на правильном порту?
sudo ss -tlnp | grep 443

# Можно подключиться локально?
curl -I http://127.0.0.1:8443/api/v1/ws

"X3DH handshake failed"¶

Симптомы: Подключение начинается, но завершается ошибкой при настройке шифрования.

Причины:

Несовпадение пакета предключей: Клиенты и серверы должны использовать один и тот же пакет предключей. Если сервер ротировал ключи, а у клиента старый пакет, это может завершиться ошибкой.
```
# На сервере: перегенерировать пакет предключей
rvpn-server prekey-bundle
# Распространить новый prekey-bundle.json клиентам
```
Ключ идентификации изменён: Если ключ идентификации сервера был перегенерирован, всем клиентам нужен новый пакет предключей.

"Too many connections" или превышен лимит запросов¶

Симптомы: Connection refused или Rate limited после успешного подключения в течение некоторого времени.

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

[server.rate_limit]
max_connections_per_ip    = 5
max_handshakes_per_minute = 10

Каждое клиентское подключение занимает один слот. Если у вас много устройств, увеличьте эти значения.

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

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

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

sysctl net.ipv4.ip_forward
# Должно вернуть: 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: Маршруты клиента:

# На клиенте, проверьте таблицу маршрутизации
ip route show  # Linux
route -n get 0.0.0.0  # macOS

# Маршрут по умолчанию должен указывать на туннельный интерфейс

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

Симптомы: Вы можете пинговать внешние 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

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

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

Проверка:

# На сервере
ping 10.200.0.1  # С сервера на самого себя через tun0

# На клиенте
ping 10.200.0.1  # Клиент должен достичь 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-to-HTTP или переключитесь на TUN-режим.

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

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

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

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

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

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

Проблемы мультиплексированного режима¶

Симптомы: Некоторые приложения или сайты не загружаются, выходят по тайм-ауту или ведут себя нестабильно, хотя прокси, похоже, работает.

Исправление: Мультиплексированный режим разделяет один WebSocket туннель между всеми потоками. Если сайт или приложение несовместимо с таким поведением, временно переключитесь на устаревший (немультиплексированный) режим:

[socks5]
multiplex = false

Важно: Устаревший режим открывает одно WebSocket-подключение на каждый TCP-поток. Загруженный браузер может легко исчерпать лимит max_connections_per_ip сервера. Если вы планируете регулярно использовать устаревший режим, попросите администратора сервера увеличить лимиты:

[server.rate_limit]
max_connections_per_ip    = 500
max_handshakes_per_minute = 2000

Низкая скорость подключения¶

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

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

Решения:

Уменьшите MTU в client.toml:
```
[tun]
mtu = 1280
```
Попробуйте другой сервер ближе к вашему местоположению
Проверьте нагрузку сервера: uptime, htop

Отключите IPv6, если не нужен:

[network]
ipv6_enabled = false
prefer_ipv4  = true

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

"Failed to start VPN"¶

Проверка: 1. Адрес сервера включает wss:// (не https://) 2. Ключ идентификации сгенерирован (Настройки -> Идентичность) 3. Пакет предключей импортирован 4. Сервер запущен и доступен

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

cd rvpn-ios && ./build_rust.sh

Частые разрывы соединения¶

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

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

Решения: 1. Включите "Постоянный VPN" в настройках iOS -> VPN 2. Проверьте обновления iOS 3. Пересоберите и переустановите приложение

Не назначен IP¶

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

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

[server.network]
dhcp_range = "10.200.0.0/22"  # /22 даёт 1022 IP вместо 254

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

Проблемы split tunnel¶

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

Проверка:

[split_tunnel]
enabled = true  # Должно быть true для работы обхода
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.

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

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

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

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

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

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

ping your-server.com

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

Оптимизация: 1. Используйте сервер ближе к вашему местоположению 2. Уменьшите MTU при спутниковом или высокозадержечном канале:

[tun]
mtu = 1280

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

Проверка: 1. Полоса пропускания сервера: тест iperf3 до сервера 2. Оборудование клиента: шифрование нагружает процессор на старых устройствах 3. Сетевая перегрузка

Оптимизация:

[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
sudo journalctl -u rvpn-server -f

# Журналы ядра (для проблем с TUN-интерфейсом)
dmesg | grep tun

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

# Трассировка пути к серверу
traceroute your-server.com

# Трассировка пути от сервера к цели
# (на сервере) 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`	Превышен лимит запросов