Вопрос или проблема
У меня точно такая же проблема, как описано здесь, но я не могу запросить разъяснения у автора, так как я новый пользователь и не могу оставить комментарий, поэтому я публикую новый вопрос (я попробовал разместить это как ответ в той же теме, но он был удален, так как не содержал ответа…).
Как предотвратить замерзание TCP-соединений через сеть OpenVPN?
Вопрос: есть ли у кого-либо рекомендации по устранению проблемы и/или определению коренной причины проблемы с TCP, описанной в той теме? Такое ощущение, что удаленный конечный узел не принимает ACK-сообщения, отправленные VPN-клиентом.
Моя настройка точно такая же, как в исходном вопросе: сервер на CentOS (с топологией подсети), и два клиента — один на CentOS и один на Ubuntu14.03. Когда я делаю ‘ssh cat abc.txt’ с клиента на Ubuntu на клиента на CentOS, VPN соединение CentOS зависает. Единственный способ восстановить его — перезапустить и сервер openvpn (на машине с centos), и openvpn-клиент на centos – просто перезапуск соединения centos-клиента не делает его рабочим (он поднимет tun0 через ~1-2 минуты, но я не могу пингануть или ssh на машину через vpn). Я также попробовал все предложения по настройке MTU из других тем (tun-mtu 1300 / fragment 1100 / mssfix и т.д.), но ни одно из них не помогло.
Что делает это еще более странным, так это то, что если я делаю то же самое ssh-cat с Ubuntu, используя vpn на сервере CentOS для выхода в интернет на публичный IP-адрес клиента на CentOS (обходя таким образом часть vpn centos-клиент<->centos-сервер), все работает нормально (без зависаний).
ОБНОВЛЕНИЕ 1: Я нашел обходное решение, но оно очень некрасивое. Публикую его здесь, на случай если кто-то предложит другие идеи/подсказки. Когда я устанавливаю уровень детализации на 9 на openvpn сервере (не на клиенте, только на сервере), проблема больше никогда не возникает. Verb 9 заставляет сервер openvpn регистрировать много данных и загружать на 100% процессор, на котором он работает. Это затем ограничивает скорость передачи и позволяет scp завершиться успешно без зависаний; теперь scp копирует со скоростью 40-50Кб/сек, в то время как раньше зависал при достижении скорости выше 100Кб/сек.
ОБНОВЛЕНИЕ 2: Я считаю, что это проблема с буферизацией. Размер передаваемого файла (через scp или ssh cat) имеет большое значение. Если я делаю scp файла размером 700КБ (или меньше), передача всегда будет успешной, сколько бы раз я это ни пытался. Если я попробую файл размером 800КБ, он всегда будет зависать после 7xxКБ+.
Я встречал похожую проблему и смог обойти ее, отключив масштабирование окна TCP.
sysctl -w net.ipv4.tcp_window_scaling=0
Возможно, это укажет вам в правильном направлении, где может быть проблема.
Мы исключили openvpn, создав туннели ssh. Наши удаленные хосты устанавливают ssh-туннель к нам, и если он падает, они инициализируют его заново. Нам пришлось использовать несколько shell-скриптов, чтобы это заработало, но как только оно заработало, оно работает безупречно уже много лет. Это позволяет нам делать ssh через туннель обратно к серверам.
Ответ или решение
Проблема зависания SSH-соединений через клиентско-клиентское подключение OpenVPN действительно может представлять собой серьезную трудность, особенно когда задача заключается в обеспечении стабильности и надежности соединений удаленного доступа. Прежде чем приступить к решению проблемы, важно теоретически понять основные концепции, которые могут влиять на данную ситуацию.
Теория
Природа проблемы: Наиболее вероятной причиной зависания TCP-соединений через OpenVPN является проблемы, связанные с настройкой MTU (Maximum Transmission Unit) и взаимодействием TCP-соединений. Когда MTU несоответствует, это может привести к фрагментации пакетов и потере их на сетевом уровне, что, в свою очередь, вызывает зависания и перебои в соединении.
Концепция TCP: TCP (Transmission Control Protocol) обеспечивает надежную передачу данных между двумя узлами, используя механизмы, такие как управление потоком, квитанции сообщений (ACK), контроль перегрузки и другое. Если TCP-сегменты не получают квитанции в установленные таймауты, это может вызвать восстановление сессии или зависание, особенно при передаче больших пакетов данных.
OpenVPN: Это программное обеспечение для создания безопасных виртуальных частных сетей, которое сильно зависит от правильной конфигурации сети. Параметры вроде tun-mtu, fragment, mssfix и другие влияют на то, как OpenVPN управляет сетевыми пакетами, и могут играть важную роль в уменьшении фрагментации пакетов.
Примеры
Установленный кейс: Рассматриваемый случай предоставляет массу информации для анализа. На вашей стороне используются сервер на базе CentOS с топологией подсети и два клиента (один на CentOS и другой на Ubuntu 14.03). Проблема заключается в зависании VPN соединения на клиенте CentOS, когда передаются данные через SSH от клиента Ubuntu на клиента CentOS. Изначальные шаги, такие как настройка MTU, не привели к решению проблемы.
Интересный вывод: Попытка решить проблему с помощью повышения уровня логирования OpenVPN сервера до 9, которая уменьшает скорость передачи и предотвращает зависание, может указывать на проблему с пропускной способностью или на сбои, связанные с обработкой пакетов при высоких скоростях передачи.
Обходное решение через SSH туннели: Этот подход обхода OpenVPN, при котором используются SSH туннели для установления сессий, также указывает на возможность проблем с управлением TCP окнами или неполучением необходимых ACK сигналов.
Применение
-
Налаживание параметров MTU и фрагментация: Начните с тщательной настройки параметров MTU на всех узлах. Оптимальное значение MTU для VPN соединений часто может составлять около 1400 байт, однако точное значение варьируется в зависимости от конкретной сети. Важен также параметр MSS (Maximum Segment Size), который может быть концептуально связан с TCP и должен быть настроен с учетом снижения фрагментации.
-
Отключение TCP Scaling: Попробуйте отключение TCP window scaling на всех задействованных узлах. Это может стабилизировать соединение за счет уменьшения потенциально чрезмерного роста окна, который некоторыми сетевыми устройствами может обрабатываться некорректно.
sysctl -w net.ipv4.tcp_window_scaling=0 -
Оптимизация нагрузки на CPU: Проверьте загрузку процессора. Если при уменьшении нагрузки на CPU проблема исчезает, можно попробовать распределить ресурсы либо добавить оборудований, чтобы избежать перегрузок.
-
Расширенный мониторинг и логирование: Используя логирование на сервере уровня выше 3, можно получить более детальную информацию о том, как пакеты обрабатываются, и какие ошибки возникают. Анализ этих данных может указать на слабые места в сети.
-
Альтернативные маршрутизации: Обеспечьте возможность смены маршрута данных через другие доступные узлы или транспортные средства, подобно SSH туннелям. Это создаст резервный канал на время решения проблем с основным путем.
-
Обновление программного обеспечения и поддержка: Проследите за тем, чтобы все использованные дистрибутивы и пакеты OpenVPN были последних версий, а доработки инфраструктуры сетевого стек протоколов были актуальны.
Таким образом, данная ситуация требует комплексного подхода, включающего не только поиск причин и возможность их устранения, но и применение дополнительных альтернативных решений для поддержания устойчивости и надежности сети.