NFS TCP-n OpenVPN UDP-alagútban: két szállítási mód

Egy TCP-t használó NFS-beszélgetést UDP-t szállító alagúton belül vinni teljesen következetes, és összezavarja az embereket, mert egyszerre két szállítási módot nevez meg. A TCP a fájlszolgáltatás beszélgetése az ügyfél és az NFS-kiszolgáló között. Az UDP a titkosított hordozó a VPN végpontjai között. Egyik sem mond semmit a másikról.

Írja le mindkettőt külön, mielőtt bármit hibakeresne; ezeknek az eseteknek a többsége azzal kezdődik, hogy valaki a rossz réteget változtatja meg.

Két réteg, két beállítás

A proto=tcp csatolási opció azt írja le, hogyan beszél az NFS-ügyfél az NFS-kiszolgálóval. A VPN-profil proto udp beállítása azt írja le, hogyan cserélnek az alagút végpontjai beágyazott csomagokat. A csatolási opció módosítása nem változtatja meg az alagutat, és az alagút szállítási módjának módosítása nem változtatja meg azt, amiről az NFS-ügyfél megállapodott. A tényleges csatolási opciókat nfsstat -m segítségével igazolja, nem az fstab sor alapján, a VPN szállítási módját pedig abból a profilból igazolja, amelyet valóban használ.

Ezután rögzítse őket az esetjegyzetben két külön mezőként. Egy látszólagos javulás csak akkor követhető nyomon, ha a jegyzet megmondja, melyik réteg változott.

A böngészés nem tömeges olvasás

Egy könyvtárlista bizonyítja, hogy bizonyos műveletek befejeződtek. Azt nem bizonyítja, hogy egy tartós olvasás, egy írás, egy zár vagy a tárolási háttér ugyanilyen feltételek mellett be fog fejeződni. Egy nagy fájl közepén bekövetkező akadás más megfigyelés, mint egy soha nem sikerülő csatolás, és különböző rétegekre mutatnak.

Írja le pontosan a meghiúsuló műveletet: útvonal, irány, az akadás hozzávetőleges pontja és az utolsó releváns esemény az ügyfél, a kiszolgáló és a VPN naplójában. Ezután hasonlítsa össze, hol folytatódik a forgalom és hol áll meg.

Az MTU hipotézis, nem diagnózis

A csomagmérettől függő veszteség valós lehetőség, amikor az alagút nagy szegmenseket szállít, és pontosan azt a mintát hozza létre, hogy a böngészés működik, az olvasás pedig megakad. Ez a minta azonban nem bizonyít MTU-problémát, mert ugyanez az alak akkor is megjelenik, ha a kiszolgáló lassú, ha a tűzfal időtúllépéssel bont egy hosszú életű kapcsolatot, vagy ha a lemez foglalt. Tesztelje a hipotézist ellenőrzött próbával ahelyett, hogy mindenhol csökkentené az MTU-t és győzelmet hirdetne.

Egy időtúllépés önmagában semmit sem mond arról, hogy az UDP-t ki kellene cserélni. Ez egy tünet, amelynek több lehetséges felelőse lehet.

Egyszerre egy változót módosítson

A szállítási módok összehasonlításakor tartsa stabilan az NFS-terhelést és minden más beállítást. Ha a csatolási szállítást, az alagútprotokollt és az MTU-t ugyanabban a karbantartási ablakban módosítja, olyan eredményt kap, amelyet senki sem tud visszavezetni egy okra. Futtassa ugyanazt a fájlműveletet előtte és utána, és minden lépésnél rögzítse az eredményt.

Őrizze meg a korábbi értékeket is a jegyben. Ha egy változtatás ront a helyzeten, a visszaállásnak dokumentált számnak kell lennie, nem annak az emlékének, hogy korábban hogyan volt.

Azt a réteget olvassa, amelyik meghibásodott

Ha az alagút él és az NFS-kérés várakozik, nem a VPN hibázott; a fájlszolgáltatás hibázott. Ha az alagút leesett, az NFS-kérés meghiúsulása következmény, nem ok. A két réteg naplósorainak összevetése a leggyorsabb módja annak, hogy megkülönböztesse ezt a két esetet, és jobb, mint a fájlkezelőből találgatni.

Írja le a következtetést két mondatban, rétegenként egyben. Ez elég ahhoz, hogy a következő ember újra elvégezhesse a tesztet anélkül, hogy újra levezesse, melyik szállítási mód melyik.