NFS поверх TCP внутри UDP-туннеля OpenVPN: два транспорта

Передавать сеанс NFS, использующий TCP, внутри туннеля, несущего UDP, вполне согласованно, и это сбивает людей с толку, потому что называет два транспорта сразу. TCP — это сеанс файловой службы между клиентом и сервером NFS. UDP — это шифрованный транспорт между конечными точками VPN. Ни один из них ничего не говорит о другом.

Запишите оба отдельно, прежде чем что-либо отлаживать; большинство таких инцидентов начинается с того, что кто-то меняет не тот уровень.

Два уровня, две настройки

Параметр монтирования proto=tcp описывает, как клиент NFS общается с сервером NFS. Настройка proto udp в профиле VPN описывает, как конечные точки туннеля обмениваются инкапсулированными пакетами. Изменение параметра монтирования не меняет туннель, а изменение транспорта туннеля не меняет то, о чём договорился клиент NFS. Проверьте действующие параметры монтирования с помощью nfsstat -m, а не строки в fstab, и подтвердите транспорт VPN по профилю, который действительно используется.

Затем запишите их в заметках об инциденте как два отдельных поля. Кажущееся улучшение можно отследить только в том случае, если в заметке сказано, какой уровень изменился.

Просмотр — это не массовое чтение

Список каталога доказывает, что некоторые операции завершились. Он не доказывает, что длительное чтение, запись, блокировка или система хранения завершатся в тех же условиях. Зависание на середине большого файла — это другое наблюдение, чем монтирование, которое никогда не удаётся, и они указывают на разные уровни.

Опишите сбойную операцию точно: путь, направление, примерное место зависания и последнее значимое событие в журналах клиента, сервера и VPN. Затем сравните, где трафик продолжается, а где останавливается.

MTU — это гипотеза, а не диагноз

Потери, зависящие от размера пакета, вполне реальны, когда туннель несёт крупные сегменты, и они дают ровно ту картину, при которой просмотр работает, а чтение застревает. Однако эта картина не доказывает проблему с MTU, потому что та же форма возникает, когда сервер медленный, когда межсетевой экран закрывает долгое соединение по тайм-ауту или когда диск занят. Проверьте гипотезу контролируемой пробой, а не снижением MTU повсюду с объявлением победы.

Тайм-аут сам по себе ничего не говорит о том, нужно ли менять UDP. Это симптом с несколькими возможными владельцами.

Меняйте по одной переменной за раз

Сравнивая транспорты, держите нагрузку NFS и все остальные настройки неизменными. Изменение транспорта монтирования, протокола туннеля и MTU в одном окне обслуживания даёт результат, который никто не сможет отнести к конкретной причине. Выполните одну и ту же операцию с файлом до и после и записывайте результат на каждом шаге.

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

Читайте тот уровень, который отказал

Если туннель поднят и запрос NFS ждёт, то отказал не VPN, а файловая служба. Если туннель упал, то сбой запроса NFS — это следствие, а не причина. Сопоставление строк журнала с обоих уровней — самый быстрый способ различить эти два случая, и это лучше, чем гадать по файловому менеджеру.

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