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 — це наслідок, а не причина. Зіставлення рядків журналу з обох рівнів — найшвидший спосіб розрізнити ці два випадки, і це краще, ніж гадати з файлового менеджера.

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