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 વિનંતીની નિષ્ફળતા પરિણામ છે, કારણ નહીં. બંને સ્તરોની લોગ લાઇનોનું મેળવણી કરવી એ આ બે કિસ્સાઓને અલગ પાડવાનો સૌથી ઝડપી રસ્તો છે, અને તે ફાઇલ મેનેજરમાંથી અનુમાન કરવા કરતાં સારું છે.

તારણને બે વાક્યોમાં લખો, દરેક સ્તર માટે એક. આગલી વ્યક્તિ માટે કયું પરિવહન કયું છે તે ફરીથી તારવ્યા વિના પરીક્ષણનું પુનરાવર્તન કરવા માટે એ પૂરતું છે.