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 заявката е следствие, а не причина. Съпоставянето на редове от журнала от двата слоя е най-бързият начин да различите тези два случая и е по-добро от гадаене по файловия мениджър.

Запишете извода като две изречения, по едно за слой. Това е достатъчно следващият човек да възпроизведе теста, без да извежда отново кой транспорт кой е.