Вопрос или проблема
Я использую NFS-клиент для подключения к кластеру NFS. Я заметил, что стандартное поведение при недоступности сервера — это повторные попытки установить TCP-соединения с того же исходного TCP-порта, что я подтвердил с помощью tcpdump (множество пакетов SYN, разные номера последовательности, но тот же исходный порт). По умолчанию NFS использует привилегированные порты (<1024), в моем примере порт 940.
По какой-то причине это вызывает проблемы с балансировщиком нагрузки Azure (мой другой вопрос). Однако, когда я монтирую ресурс с опцией noresvport (и экспортирую с insecure), NFS-клиент использует порты >1024 и теперь при каждой попытке переподключения используемый TCP-порт будет отличаться.
NFS-клиент — это SLES12 SP4, такое же поведение наблюдается и на Oracle Linux 7.7.
NFS-сервер — это кластер HAE на базе SLES12 SP4.
Документировано ли где-то такое поведение? Почему он использует один и тот же порт каждый раз по умолчанию, но не при использовании noresvport?
Мы столкнулись с этим при наличии устройства L4 (f5, межсетевой экран, устройство безопасности) в середине, которое не разорвалось соединение, и оно все еще существует в таблице соединений, когда SYN приходит с того же исходного порта. Клиент никогда не рандомизирует исходный порт и держит запись таблицы соединений активной.
Обычно это происходит, когда сервер NFS падает и никаких RST не отправляется на хост. Наши специалисты используют жесткие ссылки для всего как rooteq и удивляются, почему они постоянно сталкиваются с проблемами.
Ответ или решение
Теория
Когда клиенты NFS (Network File System) подключаются к серверу, они обычно используют зарезервированные (привилегированные) порты, которые находятся в диапазоне от 1 до 1023. Это исторически сложившаяся практика обеспечивает определенный уровень безопасности, так как определенные сервисы ожидают подключения с доверенных диапазонов. Клиенты NFS, как правило, выбирают один и тот же исходный TCP-порт при повторных попытках подключения, если это соединение разрывается.
Такое поведение потенциально может вызывать проблемы в сценариях, где используется балансировка нагрузки или сетевые устройства, такие как Azure Load Balancer. Они могут интерпретировать повторное использование исходного порта как часть живого или подвисшего соединения, что может приводить к тому, что попытки нового подключения заблокируются.
Использование опции noresvport позволяет клиенту NFS использовать порты выше 1024, что динамически выбирается системой и отличается на каждую повторную попытку подключения. В результате, это позволяет избежать проблем, связанных с блокировкой соединения балансировщиком нагрузки.
Пример
В вашей ситуации клиент NFS, работающий на SLES12 SP4 или Oracle Linux 7.7, выполняет подключение к кластеру NFS на базе SLES12 SP4. Вы заметили, что если сервер недоступен, клиент предпринимает повторные попытки подключения, используя один и тот же исходный порт, например, порт 940. Это поведение подтверждено с помощью tcpdump, где видно отправку многих пакетов SYN с одним и тем же портом. Это вызывает проблемы при работе через балансировщик нагрузки Azure, который может не адекватно обрабатывать такие повторные попытки.
При использовании монтирования с опцией noresvport, источник TCP-портов становится непостоянным и случайным, когда каждый раз используется новый порт. Это позволяет избежать проблем блокировки соединения устройствами на уровне L4, такими как f5 или другие устройства безопасности, которые могут удерживать записи о соединении на основании статических исходных портов.
Применение
Данное поведение достаточно обосновано с точки зрения работы NFS и связано с историческими и сетевыми трендами безопасности. Важно понимать, что повторное использование одного и того же порта служит для минимизации потребления системных ресурсов и контроля потоков данных, однако имеет свои ограничения, особенно в сетях с высокой доступностью и отказоустойчивостью.
Для успешного решения проблем указанного типа следует:
-
Используйте опцию
noresvportв конфигурации клиента NFS, чтобы обеспечить выбор динамических портов выше 1024. Это убережет вас от проблем с устаревшими записями соединений на балансировщиках нагрузки. -
Через конфигурацию экспортируемых файлов на сервере NFS необходимо указать опцию
insecure, чтобы разрешить доступ с непривилегированных портов, что требуется при использовании упомянутой выше клиентской опции. -
Рассмотрите вопрос настройки сетевых устройств на предмет управления устаревшими TCP-соединениями. Особо это касается безопасности и балансировки нагрузки, которые могут некорректно обрабатывать многократные запросы SYN с одной и той же информацией о портах.
-
Проводите регулярный аудит и мониторинг сетевой деятельности с использованием инструментов вроде
tcpdump, чтобы отслеживать каналы соединений и вовремя предотвращать подобные сетевые затыки.
Такое решение позволит эффективно управлять подключениями NFS в средах с высокой отказоустойчивостью и сложной архитектурой, соответствуя требованиям современного бизнеса касаемо надежности и доступности данных. Соблюдение этих рекомендаций не только обеспечит стабильное функционирование ваших NFS-соединений, но и минимизирует риск простоя системы в случае отказов отдельных сегментов сети.