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 अनुरोध की विफलता परिणाम है, कारण नहीं। दोनों परतों की लॉग पंक्तियों का मिलान करना इन दो स्थितियों को अलग पहचानने का सबसे तेज़ तरीका है, और यह फ़ाइल मैनेजर से अनुमान लगाने से बेहतर है।

निष्कर्ष दो वाक्यों में लिखें, हर परत के लिए एक। अगले व्यक्ति के लिए यह काफ़ी है कि वह बिना दोबारा तय किए कि कौन-सा परिवहन कौन-सा है, परीक्षण दोहरा सके।