NFS přes TCP uvnitř tunelu OpenVPN s UDP: dva přenosy

Přenášet konverzaci NFS, která používá TCP, uvnitř tunelu, který přenáší UDP, je zcela konzistentní a mate lidi, protože pojmenovává dva přenosy najednou. TCP je konverzace souborové služby mezi klientem a serverem NFS. UDP je šifrovaná přenosová cesta mezi koncovými body VPN. Ani jedno nic neříká o druhém.

Zapište obojí odděleně, než začnete cokoli ladit; většina těchto incidentů začíná tím, že někdo změní špatnou vrstvu.

Dvě vrstvy, dvě nastavení

Volba připojení proto=tcp popisuje, jak klient NFS komunikuje se serverem NFS. Nastavení proto udp v profilu VPN popisuje, jak koncové body tunelu vyměňují zapouzdřené pakety. Změna volby připojení nemění tunel a změna přenosu tunelu nemění to, na čem se klient NFS dohodl. Ověřte skutečné volby připojení pomocí nfsstat -m, nikoli podle řádku v fstab, a ověřte přenos VPN z profilu, který se skutečně používá.

Potom je zapište do poznámek k incidentu jako dvě samostatná pole. Zdánlivé zlepšení lze vysledovat jen tehdy, když poznámka uvádí, která vrstva se změnila.

Procházení není hromadné čtení

Výpis adresáře dokazuje, že některé operace proběhly. Nedokazuje, že trvalé čtení, zápis, zámek nebo úložiště za tím skončí za stejných podmínek. Zaseknutí v polovině velkého souboru je jiné pozorování než připojení, které nikdy neuspěje, a ukazují na různé vrstvy.

Popište selhávající operaci přesně: cestu, směr, přibližné místo zaseknutí a poslední relevantní událost v protokolech klienta, serveru a VPN. Potom porovnejte, kde provoz pokračuje a kde se zastaví.

MTU je hypotéza, ne diagnóza

Ztráta závislá na velikosti paketu je reálná možnost, když tunel přenáší velké segmenty, a vytváří přesně vzorec «procházení funguje, čtení se zasekne». Ten vzorec však neprokazuje problém s MTU, protože stejný obraz nastává, když je server pomalý, když firewall ukončí dlouhé spojení kvůli vypršení a když je disk zaneprázdněný. Otestujte hypotézu řízenou sondou, místo abyste všude snížili MTU a prohlásili vítězství.

Vypršení samo o sobě nic neříká o tom, zda má být UDP vyměněno. Je to symptom s několika možnými vlastníky.

Měňte jednu proměnnou po druhé

Při porovnávání přenosů udržujte zátěž NFS a všechna ostatní nastavení stabilní. Změna přenosu připojení, protokolu tunelu a MTU v jednom servisním okně dává výsledek, který nikdo nemůže připsat konkrétní příčině. Spusťte stejnou souborovou operaci před a po a zaznamenejte výsledek v každém kroku.

Uchovejte v tiketu také předchozí hodnoty. Pokud změna věci zhorší, měl by návrat být zdokumentované číslo, a ne něčí vzpomínka na to, jak to bylo dřív.

Čtěte vrstvu, která selhala

Pokud tunel běží a požadavek NFS čeká, VPN neselhalo; selhala souborová služba. Pokud tunel spadl, selhání požadavku NFS je následek, nikoli příčina. Párování řádků protokolu z obou vrstev je nejrychlejší způsob, jak tyto dva případy rozlišit, a je lepší než hádání ze správce souborů.

Napište závěr jako dvě věty, jednu na vrstvu. To stačí, aby další člověk test zopakoval, aniž by znovu odvozoval, který přenos je který.