NFS per TCP OpenVPN UDP tunelyje: du transportai

NFS pokalbio, kuris naudoja TCP, perdavimas tuneliu, kuris perduoda UDP, yra visiškai nuoseklus, ir tai klaidina žmones, nes įvardija du transportus vienu metu. TCP yra failų tarnybos pokalbis tarp kliento ir NFS serverio. UDP yra šifruotas nešiklis tarp VPN galinių taškų. Nė vienas iš jų nieko nereiškia apie kitą.

Užsirašykite abu atskirai, prieš pradėdami ką nors derinti; dauguma šių incidentų prasideda nuo to, kad kas nors pakeičia netinkamą sluoksnį.

Du sluoksniai, du nustatymai

Prijungimo parinktis proto=tcp aprašo, kaip NFS klientas kalba su NFS serveriu. VPN profilio nustatymas proto udp aprašo, kaip tunelio galiniai taškai apsikeičia inkapsuliuotais paketais. Prijungimo parinkties pakeitimas nekeičia tunelio, o tunelio transporto pakeitimas nekeičia to, dėl ko susitarė NFS klientas. Patikrinkite faktines prijungimo parinktis naudodami nfsstat -m, o ne fstab eilutę, ir patikrinkite VPN transportą iš profilio, kuris iš tikrųjų naudojamas.

Tada užrašykite juos incidento pastabose kaip du atskirus laukus. Akivaizdus pagerėjimas gali būti atsekamas tik tada, kai pastaba nurodo, kuris sluoksnis pasikeitė.

Naršymas nėra masinis skaitymas

Katalogo sąrašas įrodo, kad kai kurios operacijos baigtos. Jis neįrodo, kad ilgalaikis skaitymas, rašymas, užraktas ar saugyklos posistemis baigsis tomis pačiomis sąlygomis. Sustojimas didelio failo viduryje yra kitas stebėjimas nei prijungimas, kuris niekada nepavyksta, ir jie rodo skirtingus sluoksnius.

Tiksliai aprašykite nepavykusią operaciją: kelią, kryptį, apytikslę sustojimo vietą ir paskutinį svarbų įvykį kliento, serverio ir VPN žurnaluose. Tada palyginkite, kur srautas tęsiasi, o kur sustoja.

MTU yra hipotezė, o ne diagnozė

Nuo paketo dydžio priklausantis nuostolis yra reali galimybė, kai tunelis perduoda didelius segmentus, ir jis sukuria būtent modelį, kai naršymas veikia, o skaitymas sustoja. Tačiau šis modelis neįrodo MTU problemos, nes tokia pat forma atsiranda, kai serveris lėtas, kai ugniasienė nutraukia ilgalaikį ryšį dėl laiko limito arba kai diskas užimtas. Patikrinkite hipotezę kontroliuojamu bandymu, o ne visur sumažindami MTU ir paskelbdami pergalę.

Laiko limitas pats savaime nieko nesako apie tai, ar UDP reikia pakeisti. Tai simptomas su keliais galimais savininkais.

Keiskite po vieną kintamąjį

Lygindami transportus, palaikykite NFS darbo krūvį ir visus kitus nustatymus pastovius. Prijungimo transporto, tunelio protokolo ir MTU keitimas tame pačiame techninės priežiūros lange duoda rezultatą, kurio niekas negali priskirti. Paleiskite tą pačią failo operaciją prieš ir po, ir kiekviename žingsnyje užrašykite rezultatą.

Išsaugokite ankstesnes reikšmes ir biliete. Jei pakeitimas pablogina padėtį, grįžimas atgal turėtų būti dokumentuotas skaičius, o ne kažkieno atmintis, kaip buvo anksčiau.

Skaitykite tą sluoksnį, kuris nepavyko

Jei tunelis veikia, o NFS užklausa laukia, VPN nepavyko; nepavyko failų tarnyba. Jei tunelis nukrito, NFS užklausos nesėkmė yra pasekmė, o ne priežastis. Abiejų sluoksnių žurnalo eilučių sugretinimas yra greičiausias būdas atskirti šiuos du atvejus, ir tai geriau nei spėlioti iš failų tvarkyklės.

Parašykite išvadą dviem sakiniais, po vieną kiekvienam sluoksniui. To pakanka, kad kitas žmogus pakartotų testą nereikalaudamas iš naujo nustatyti, kuris transportas yra kuris.