NFS peste TCP într-un tunel UDP OpenVPN: două transporturi

Transportarea unei conversații NFS care folosește TCP într-un tunel care transportă UDP este perfect consecventă, și derutează oamenii pentru că numește două transporturi deodată. TCP este conversația serviciului de fișiere dintre client și serverul NFS. UDP este purtătorul criptat dintre capetele VPN. Niciunul nu implică nimic despre celălalt.

Notați ambele separat înainte de a depana orice; majoritatea acestor incidente încep când cineva schimbă stratul greșit.

Două straturi, două setări

Opțiunea de montare proto=tcp descrie cum vorbește clientul NFS cu serverul NFS. Setarea proto udp din profilul VPN descrie cum schimbă capetele tunelului pachete încapsulate. Schimbarea unei opțiuni de montare nu schimbă tunelul, iar schimbarea transportului tunelului nu schimbă ce a negociat clientul NFS. Verificați opțiunile de montare efective cu nfsstat -m în loc de linia din fstab, și verificați transportul VPN din profilul care este folosit efectiv.

Apoi notați-le în notele incidentului ca două câmpuri separate. O îmbunătățire aparentă poate fi urmărită doar dacă nota spune care strat s-a schimbat.

Răsfoirea nu este o citire masivă

O listare de director dovedește că unele operații s-au încheiat. Nu dovedește că o citire susținută, o scriere, o blocare sau backendul de stocare se vor încheia în aceleași condiții. Un blocaj la jumătatea unui fișier mare este o observație diferită de o montare care nu reușește niciodată, și indică straturi diferite.

Descrieți precis operația care eșuează: cale, direcție, punctul aproximativ al blocajului și ultimul eveniment relevant din jurnalele clientului, serverului și VPN-ului. Apoi comparați unde traficul continuă și unde se oprește.

MTU este o ipoteză, nu un diagnostic

Pierderea dependentă de dimensiunea pachetului este o posibilitate reală când un tunel transportă segmente mari, și produce exact tiparul în care răsfoirea funcționează, iar citirea se blochează. Tiparul acela nu dovedește însă o problemă de MTU, pentru că aceeași formă apare când un server este lent, când un firewall închide o conexiune de durată din cauza expirării sau când un disc este ocupat. Testați ipoteza cu o sondă controlată, în loc să reduceți MTU peste tot și să declarați victoria.

O expirare singură nu spune nimic despre dacă UDP ar trebui înlocuit. Este un simptom cu mai mulți posibili proprietari.

Schimbați o singură variabilă pe rând

Când comparați transporturi, mențineți stabilă încărcarea NFS și toate celelalte setări. Schimbarea transportului de montare, a protocolului tunelului și a MTU în aceeași fereastră de mentenanță produce un rezultat pe care nimeni nu îl poate atribui. Rulați aceeași operație pe fișier înainte și după, și notați rezultatul la fiecare pas.

Păstrați și valorile anterioare în tichet. Dacă o schimbare înrăutățește lucrurile, revenirea ar trebui să fie un număr documentat, nu amintirea cuiva despre cum era înainte.

Citiți stratul care a eșuat

Dacă tunelul este activ și cererea NFS așteaptă, VPN-ul nu a eșuat; serviciul de fișiere a eșuat. Dacă tunelul a căzut, eșecul cererii NFS este o consecință și nu o cauză. Potrivirea liniilor de jurnal din ambele straturi este cea mai rapidă cale de a distinge aceste două cazuri, și este mai bună decât ghicitul din managerul de fișiere.

Scrieți concluzia în două propoziții, una pentru fiecare strat. Este suficient pentru ca următoarea persoană să reproducă testul fără a deduce din nou care transport este care.