OpenVPN UDP ടണലിനുള്ളിൽ TCP-യിൽ NFS: രണ്ട് സംവഹനം

UDP വഹിക്കുന്ന ടണലിനുള്ളിൽ TCP ഉപയോഗിക്കുന്ന NFS സംഭാഷണം വഹിക്കുന്നത് പൂർണ്ണമായും സ്ഥിരതയുള്ളതാണ്, അത് ഒരേസമയം രണ്ട് സംവഹനങ്ങളെ പേരെടുത്ത് പറയുന്നതിനാൽ ആളുകളെ കുഴപ്പത്തിലാക്കുന്നു. TCP ക്ലൈന്റും NFS സെർവറും തമ്മിലുള്ള ഫയൽ സേവന സംഭാഷണമാണ്. UDP VPN അറ്റങ്ങൾ തമ്മിലുള്ള എൻക്രിപ്റ്റ് ചെയ്ത വാഹകനാണ്. ഇവയൊന്നും മറ്റേതിനെക്കുറിച്ച് ഒന്നും സൂചിപ്പിക്കുന്നില്ല.

എന്തെങ്കിലും ഡീബഗ് ചെയ്യുന്നതിന് മുൻപ് രണ്ടും വെവ്വേറെ എഴുതിവയ്ക്കുക; ഈ സംഭവങ്ങളിൽ ഭൂരിഭാഗവും ആരോ തെറ്റായ പാളി മാറ്റുന്നതിൽ നിന്നാണ് ആരംഭിക്കുന്നത്.

രണ്ട് പാളി, രണ്ട് ക്രമീകരണം

മൗണ്ട് ഓപ്ഷൻ proto=tcp NFS ക്ലൈന്റ് NFS സെർവറുമായി എങ്ങനെ സംസാരിക്കുന്നു എന്ന് വിവരിക്കുന്നു. VPN പ്രൊഫൈലിലെ proto udp ക്രമീകരണം ടണലിന്റെ അറ്റങ്ങൾ എൻകാപ്സുലേറ്റ് ചെയ്ത പാക്കറ്റുകൾ എങ്ങനെ കൈമാറുന്നു എന്ന് വിവരിക്കുന്നു. മൗണ്ട് ഓപ്ഷൻ മാറ്റുന്നത് ടണലിനെ മാറ്റുന്നില്ല, ടണലിന്റെ സംവഹനം മാറ്റുന്നത് NFS ക്ലൈന്റ് ഉടമ്പടി ചെയ്ത കാര്യം മാറ്റുന്നില്ല. fstab വരിയ്ക്ക് പകരം nfsstat -m ഉപയോഗിച്ച് ഫലപ്രദമായ മൗണ്ട് ഓപ്ഷനുകൾ സ്ഥിരീകരിക്കുക, യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന പ്രൊഫൈലിൽ നിന്ന് VPN സംവഹനം സ്ഥിരീകരിക്കുക.

തുടർന്ന് അവ സംഭവക്കുറിപ്പിൽ രണ്ട് വെവ്വേറെ ഫീൽഡുകളായി രേഖപ്പെടുത്തുക. പ്രത്യക്ഷമായ മെച്ചപ്പെടുത്തൽ ഏത് പാളി മാറി എന്ന് കുറിപ്പ് പറഞ്ഞാൽ മാത്രമേ കണ്ടെത്താൻ കഴിയൂ.

ബ്രൗസിംഗ് വലിയ തോതിലുള്ള വായനയല്ല

ഒരു ഡയറക്ടറി ലിസ്റ്റ് ചില പ്രവർത്തനങ്ങൾ പൂർത്തിയായി എന്ന് തെളിയിക്കുന്നു. തുടർച്ചയായ വായന, എഴുത്ത്, ലോക്ക്, അല്ലെങ്കിൽ സംഭരണ പിൻഭാഗം അതേ സാഹചര്യത്തിൽ പൂർത്തിയാകും എന്ന് അത് തെളിയിക്കുന്നില്ല. വലിയ ഫയലിന്റെ നടുവിൽ നിൽക്കുന്നത് ഒരിക്കലും വിജയിക്കാത്ത മൗണ്ടിൽ നിന്ന് വ്യത്യസ്തമായ നിരീക്ഷണമാണ്, അവ വ്യത്യസ്ത പാളികളിലേക്ക് വിരൽ ചൂണ്ടുന്നു.

പരാജയപ്പെടുന്ന പ്രവർത്തനം കൃത്യമായി വിവരിക്കുക: പാത, ദിശ, തടസ്സത്തിന്റെ ഏകദേശ സ്ഥാനം, ക്ലൈന്റ്, സെർവർ, VPN ലോഗുകളിലെ അവസാന പ്രസക്ത സംഭവം. തുടർന്ന് ട്രാഫിക് എവിടെ തുടരുന്നു, എവിടെ നിൽക്കുന്നു എന്ന് താരതമ്യം ചെയ്യുക.

MTU ഒരു സിദ്ധാന്തമാണ്, രോഗനിർണ്ണയമല്ല

പാക്കറ്റ് വലിപ്പത്തെ ആശ്രയിക്കുന്ന നഷ്ടം ടണൽ വലിയ സെഗ്മെന്റുകൾ വഹിക്കുമ്പോൾ യഥാർത്ഥ സാധ്യതയാണ്, അത് ബ്രൗസിംഗ് പ്രവർത്തിക്കുന്നു, വായന നിൽക്കുന്നു എന്ന മാതൃക കൃത്യമായി ഉണ്ടാക്കുന്നു. എന്നാൽ ആ മാതൃക MTU പ്രശ്നം തെളിയിക്കുന്നില്ല, കാരണം സെർവർ മന്ദഗതിയിലാകുമ്പോൾ, ഫയർവാൾ ദീർഘകാല കണക്ഷൻ സമയപരിധിയിൽ അവസാനിപ്പിക്കുമ്പോൾ, അല്ലെങ്കിൽ ഡിസ്ക് തിരക്കിലാകുമ്പോൾ അതേ രൂപം പ്രത്യക്ഷപ്പെടുന്നു. എല്ലായിടത്തും MTU കുറച്ച് വിജയം പ്രഖ്യാപിക്കുന്നതിന് പകരം നിയന്ത്രിത പരിശോധനയിലൂടെ സിദ്ധാന്തം പരീക്ഷിക്കുക.

സമയപരിധി ഒറ്റയ്ക്ക് UDP മാറ്റണോ വേണ്ടയോ എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ഇത് നിരവധി സാധ്യതയുള്ള ഉടമകളുള്ള ഒരു ലക്ഷണമാണ്.

ഒരു സമയത്ത് ഒരു ചരം മാറ്റുക

സംവഹനങ്ങൾ താരതമ്യം ചെയ്യുമ്പോൾ NFS ജോലിഭാരവും മറ്റെല്ലാ ക്രമീകരണങ്ങളും സ്ഥിരമായി നിർത്തുക. ഒരേ അറ്റകുറ്റപ്പണി ജാലകത്തിൽ മൗണ്ട് സംവഹനം, ടണൽ പ്രോട്ടോക്കോൾ, MTU എന്നിവ മാറ്റുന്നത് ആർക്കും കണ്ടെത്താനാകാത്ത ഫലം നൽകുന്നു. അതേ ഫയൽ പ്രവർത്തനം മുൻപും ശേഷവും നടത്തി ഓരോ ഘട്ടത്തിലും ഫലം രേഖപ്പെടുത്തുക.

മുൻ മൂല്യങ്ങളും ടിക്കറ്റിൽ സൂക്ഷിക്കുക. ഒരു മാറ്റം കാര്യങ്ങൾ വഷളാക്കിയാൽ, പിൻവാങ്ങൽ രേഖപ്പെടുത്തിയ ഒരു സംഖ്യയായിരിക്കണം, മുൻപ് എങ്ങനെയായിരുന്നു എന്ന ആരുടെയോ ഓർമ്മയല്ല.

പരാജയപ്പെട്ട പാളി വായിക്കുക

ടണൽ ഉയർന്നിരിക്കുകയും NFS അഭ്യർത്ഥന കാത്തിരിക്കുകയും ചെയ്യുന്നുവെങ്കിൽ VPN പരാജയപ്പെട്ടിട്ടില്ല; ഫയൽ സേവനമാണ് പരാജയപ്പെട്ടത്. ടണൽ വീണുപോയെങ്കിൽ, NFS അഭ്യർത്ഥനയുടെ പരാജയം ഫലമാണ്, കാരണമല്ല. രണ്ട് പാളികളുടെയും ലോഗ് വരികൾ ഒത്തുനോക്കുന്നത് ഈ രണ്ട് സാഹചര്യങ്ങൾ വേർതിരിക്കാനുള്ള വേഗതയേറിയ മാർഗമാണ്, അത് ഫയൽ മാനേജരിൽ നിന്ന് ഊഹിക്കുന്നതിനേക്കാൾ മികച്ചതാണ്.

നിഗമനം രണ്ട് വാക്യങ്ങളിൽ എഴുതുക, ഓരോ പാളിക്കും ഒന്ന്. ഏത് സംവഹനം ഏതാണെന്ന് വീണ്ടും കണ്ടെത്താതെ അടുത്തയാൾ പരീക്ഷണം ആവർത്തിക്കാൻ അത് മതി.