NFS oor TCP in ’n OpenVPN-UDP-tonnel: twee vervoerprotokolle

Om ’n NFS-gesprek wat TCP gebruik binne ’n tonnel wat UDP dra, is heeltemal konsekwent, en dit verwar mense omdat dit twee vervoerlyne gelyk noem. TCP is die lêerdiensgesprek tussen die kliënt en die NFS-bediener. UDP is die versleutelde draer tussen die VPN-eindpunte. Nie een sê iets oor die ander nie.

Skryf albei afsonderlik neer voordat jy iets ontfout; die meeste van hierdie voorvalle begin wanneer iemand die verkeerde laag verander.

Twee lae, twee instellings

Die monteeropsie proto=tcp beskryf hoe die NFS-kliënt met die NFS-bediener praat. Die VPN-profiel se proto udp-instelling beskryf hoe die tonneleindpunte ingekapselde pakkette uitruil. Om ’n monteeropsie te verander, verander nie die tonnel nie, en om die tonnel se vervoer te verander, verander nie wat die NFS-kliënt onderhandel het nie. Bevestig die werklike monteeropsies met nfsstat -m eerder as die fstab-reël, en bevestig die VPN-vervoer uit die profiel wat werklik in gebruik is.

Teken dit dan in die voorvalnotas aan as twee aparte velde. ’n Oënskynlike verbetering is net naspeurbaar as die nota sê watter laag verander het.

Blaai is nie ’n grootmaat-lees nie

’n Gidslys bewys dat sommige bewerkings voltooi is. Dit bewys nie dat ’n volgehoue lees, ’n skryf, ’n slot of die bergingsagterkant onder dieselfde toestande sal voltooi nie. ’n Hang halfpad deur ’n groot lêer is ’n ander waarneming as ’n montering wat nooit slaag nie, en hulle wys na verskillende lae.

Beskryf die mislukkende bewerking presies: pad, rigting, die benaderde punt van die hang, en die laaste relevante gebeurtenis in die kliënt-, bediener- en VPN-logs. Vergelyk dan waar verkeer voortduur en waar dit stop.

MTU is ’n hipotese, nie ’n diagnose nie

Pakketgrootte-afhanklike verlies is ’n werklike moontlikheid wanneer ’n tonnel groot segmente dra, en dit lewer presies die patroon blaai-werk-lees-hang. Daardie patroon bewys egter nie ’n MTU-probleem nie, want dieselfde vorm verskyn wanneer ’n bediener stadig is, ’n firewall ’n langdurige verbinding laat verstryk, of ’n skyf besig is. Toets die hipotese met ’n beheerde probe eerder as om MTU oral te verlaag en die oorwinning aan te kondig.

’n Tydverstryking op sigself sê niks oor of UDP vervang moet word nie. Dit is ’n simptoom met verskeie moontlike eienaars.

Verander een veranderlike op ’n slag

Wanneer jy vervoerlyne vergelyk, hou die NFS-werklading en elke ander instelling stabiel. Om die monteervervoer, die tonnelprotokol en die MTU in dieselfde onderhoudsvenster te verander, lewer ’n resultaat wat niemand kan toeskryf nie. Voer dieselfde lêerbewerking voor en ná uit, en teken die uitkoms by elke stap aan.

Hou ook die vorige waardes in die kaartjie. As ’n verandering dinge vererger, moet die terugval ’n gedokumenteerde nommer wees eerder as iemand se herinnering aan hoe dit was.

Lees die laag wat misluk het

As die tonnel op is en die NFS-versoek wag, het die VPN nie misluk nie; die lêerdiens het. As die tonnel geval het, is die mislukking van die NFS-versoek ’n gevolg eerder as ’n oorsaak. Om logreëls uit albei lae te pas, is die vinnigste manier om daardie twee gevalle te onderskei, en dit is beter as om uit die lêerbestuurder te raai.

Skryf die gevolgtrekking as twee sinne, een per laag. Dit is genoeg vir die volgende persoon om die toets te herhaal sonder om weer af te lei watter vervoer wat is.