NFS przez TCP wewnątrz tunelu UDP OpenVPN: dwa transporty

Przenoszenie rozmowy NFS, która używa TCP, wewnątrz tunelu przenoszącego UDP jest całkowicie spójne, i myli ludzi, bo nazywa dwa transporty naraz. TCP to rozmowa usługi plików między klientem a serwerem NFS. UDP to szyfrowany nośnik między punktami końcowymi VPN. Żaden z nich nic nie mówi o drugim.

Zapisz oba osobno, zanim zaczniesz cokolwiek debugować; większość takich incydentów zaczyna się od tego, że ktoś zmienia niewłaściwą warstwę.

Dwie warstwy, dwa ustawienia

Opcja montowania proto=tcp opisuje, jak klient NFS rozmawia z serwerem NFS. Ustawienie proto udp w profilu VPN opisuje, jak punkty końcowe tunelu wymieniają enkapsulowane pakiety. Zmiana opcji montowania nie zmienia tunelu, a zmiana transportu tunelu nie zmienia tego, co wynegocjował klient NFS. Sprawdź rzeczywiste opcje montowania za pomocą nfsstat -m, a nie linii w fstab, i potwierdź transport VPN z profilu, który jest faktycznie używany.

Potem zapisz je w notatkach ze zdarzenia jako dwa osobne pola. Widoczną poprawę można prześledzić tylko wtedy, gdy notatka mówi, która warstwa się zmieniła.

Przeglądanie to nie masowe czytanie

Lista katalogu dowodzi, że niektóre operacje się zakończyły. Nie dowodzi, że długotrwałe czytanie, zapis, blokada albo backend pamięci masowej zakończą się w tych samych warunkach. Zatrzymanie w połowie dużego pliku to inna obserwacja niż montowanie, które nigdy się nie udaje, i wskazują na różne warstwy.

Opisz dokładnie operację, która zawodzi: ścieżkę, kierunek, przybliżony punkt zatrzymania i ostatnie istotne zdarzenie w logach klienta, serwera i VPN. Potem porównaj, gdzie ruch trwa, a gdzie się zatrzymuje.

MTU to hipoteza, nie diagnoza

Utrata zależna od rozmiaru pakietu jest realną możliwością, gdy tunel przenosi duże segmenty, i daje dokładnie wzorzec, w którym przeglądanie działa, a czytanie się zatrzymuje. Ten wzorzec nie dowodzi jednak problemu z MTU, bo ten sam kształt pojawia się, gdy serwer jest wolny, gdy zapora kończy długie połączenie przez limit czasu albo gdy dysk jest zajęty. Sprawdź hipotezę kontrolowanym testem, zamiast wszędzie obniżać MTU i ogłaszać zwycięstwo.

Sam limit czasu nie mówi nic o tym, czy UDP należy wymienić. To objaw o kilku możliwych właścicielach.

Zmieniaj jedną zmienną naraz

Porównując transporty, utrzymuj obciążenie NFS i wszystkie inne ustawienia na stałym poziomie. Zmiana transportu montowania, protokołu tunelu i MTU w tym samym oknie serwisowym daje wynik, którego nikt nie może przypisać. Wykonaj tę samą operację na pliku przed i po, i zapisuj wynik na każdym etapie.

Zachowaj poprzednie wartości także w zgłoszeniu. Jeśli zmiana pogorszy sytuację, wycofanie powinno być udokumentowaną liczbą, a nie czyimś wspomnieniem, jak było wcześniej.

Czytaj tę warstwę, która zawiodła

Jeśli tunel działa, a żądanie NFS czeka, to nie VPN zawiódł; zawiodła usługa plików. Jeśli tunel padł, niepowodzenie żądania NFS jest skutkiem, a nie przyczyną. Zestawienie linii logów z obu warstw to najszybszy sposób rozróżnienia tych dwóch przypadków, i jest lepsze niż zgadywanie z menedżera plików.

Zapisz wniosek w dwóch zdaniach, po jednym na warstwę. To wystarczy, aby następna osoba powtórzyła test, nie wyprowadzając od nowa, który transport jest który.