OpenVPN стал очень медленным, хотя конфигурация не изменялась.

Вопрос или проблема

Я использую Debian Linux (11 bullseye) для моего OpenVPN сервера (стандартный пакет Debian 2.5.1-3), а также для моего ноутбука.

Это отлично работало в течение нескольких месяцев. Оно всё ещё работает, но стало очень медленным! Открытие PDF файла размером 60kB занимает около 30 секунд по VPN.

Проблема не в интернет-соединении / канале (100 Мбит/с с обоих концов).

Я не изменял конфигурацию сервера или клиента.

Пожалуйста, смотрите мою конфигурацию сервера:

mode server
dev tun
server 10.111.9.0 255.255.255.0
topology subnet
ifconfig-pool-persist /etc/path/ipp.txt
push "route 10.94.0.0 255.255.0.0"
push "dhcp-option DNS 10.94.123.45"
push "dhcp-option WINS 10.94.123.45"
push "dhcp-option DOMAIN mydomain.internal"
push "dhcp-option NTP 10.94.123.45"
push "dhcp-option NBT 2"
daemon
log-append /var/log/openvpn/openvpn_xy.log
status /var/log/openvpn/openvpn_xy_status.log
tls-server
tls-version-min 1.2
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
tls-crypt /etc/path/tlscrypt.key
dh /etc/path/dh.pem
ca /etc/path/ca.crt
cert /etc/path/server.crt
key /etc/path/server.key
crl-verify /etc/path/crl.pem
proto udp
port 1499
user openvpn
group openvpn
allow-compression no
max-clients 50
keepalive 10 60
persist-tun
persist-key
verb 4

Но возможно что-то, касающееся MTU и т.п., изменилось на сетевом пути, что находится вне моего влияния?

Я никогда не настраивал параметры MTU, исправления MSS и т.д. Всё просто отлично работало с настройками по умолчанию (без пользовательских настроек).

Какие шаги по разрешению проблемы или диагностики я должен предпринять?

Ответ или решение

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

Теоретическая часть

OpenVPN работает поверх UDP или TCP протокола, обеспечивая безопасное соединение через инкапсуляцию данных и их маршрутизацию через защищённый туннель. Когда производительность VPN соединения резко снижается, следует рассмотреть такие аспекты, как особенности маршрутизации, изменения в сетевой инфраструктуре, загруженность процессора сервера, а также возможные проблемы с синхронизацией времени или перегрузки.

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

  1. Изменения в сети: Даже если конфигурация OpenVPN осталась прежней, изменение маршрута в сети интернет может негативно повлиять на производительность. Например, новые маршрутизаторы на пути или изменения в политике QoS (Качество Обслуживания) могут внести свои коррективы.

  2. MTU и MSS: Хотя вы не настроили MTU (Максимальная Единица Передачи), изменения вне вашего контроля могли вызвать фрагментацию пакетов. Фрагментация ведёт к увеличенной задержке и снижению пропускной способности.

  3. Нагрузка на сервере: Параллельные процессы на сервере, потребляющие ресурсы процессора/памяти, могут влиять на скорость обработки пакетов OpenVPN. Использование команд top или htop поможет выявить загрузку процессора.

  4. Сетевая загруженность и потеря пакетов: Проверьте журналы OpenVPN на предмет ошибок, связанных с потерей пакетов или повышенной задержкой. Команда ping и traceroute могут помочь выявить, где происходит задержка в сети.

  5. Обновления системы и пакетов: Автоматические обновления Debian могут внести изменения, влияющие на работу ядра или самого OpenVPN.

  6. Дисковая производительность: Если сервер хостится на диске с плохой производительностью, это может стать узким местом. Используйте iotop для проверки активности ввода/вывода.

  7. Безопасность и атаки: ДДОС-атаки или многократные попытки соединения могут перегружать ресурсы сервера OpenVPN.

Пример

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

Применение и шаги диагностики

  1. Проверка нагрузки на сервере: Используйте команды top или htop для мониторинга загрузки CPU и памяти на сервере. Если OpenVPN процесс потребляет много ресурсов, это может быть причиной задержек.

  2. Анализ журнала OpenVPN: Уровень ведения журнала, установленный как verb 4, достаточен для основных диагностик. Проверьте журнал /var/log/openvpn/openvpn_xy.log на предмет неожиданных ошибок или предупреждений.

  3. Тестирование мощности сети: Используйте iperf для тестирования пропускной способности между клиентом и сервером вне туннеля VPN. Это поможет выявить потенциальные проблемы в интернет-соединении.

  4. MTU и MSS настройки: Проверьте фрагментацию пакетов с помощью команды ping с опцией -M do -s X (где X – предполагаемый размер MTU). Убедитесь, что настройка MSS (Максимальный Размер Сегмента) соответствует ожидаемой на обоих концах соединения.

  5. Обновление системы: Проверьте версии используемого ядра и пакетов OpenVPN. Убедитесь, что все установленные обновления протестированы и совместимы.

  6. Проверка ограничения QoS: Возможна установка ограничений со стороны вашего интернет-провайдера, которые невозможно обнаружить без переговоров с ним.

  7. Трассировка маршрутов: Выполните traceroute от клиента к серверу для проверки времени прохождения пакетов через все узлы.

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

Оцените материал
Добавить комментарий

Капча загружается...