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 अनुरोधको असफलता परिणाम हो, कारण होइन। दुवै तहका लग लाइनहरू मिलाएर हेर्नु यी दुई अवस्था छुट्याउने सबैभन्दा छिटो उपाय हो, र यो फाइल म्यानेजरबाट अनुमान गर्नुभन्दा राम्रो छ।

निष्कर्ष दुई वाक्यमा लेख्नुहोस्, प्रत्येक तहका लागि एउटा। कुन ढुवानी कुन हो भनेर फेरि निकाल्नु नपर्ने गरी अर्को व्यक्तिले परीक्षण दोहोर्याउन यति नै पर्याप्त छ।