VPN पते पर Samba: श्रोता क्यों गायब हो जाता है

शेयर पूरी सुबह काम करता है, दोपहर में टनल फिर से जुड़ता है, और वही UNC पथ अब समय समाप्त हो जाता है, जबकि सर्वर को ping अभी भी जवाब देता है। शेयर की परिभाषा में कुछ नहीं बदला और VPN चालू है। जो बदला वह स्थानीय पता है जिससे Samba बँधा था, और इंटरफ़ेस फिर से बनने के बाद वह मौजूद नहीं है। यह विफलता का ढंग श्रोता के जीवनचक्र की समस्या है, अनुमति की समस्या नहीं।

टनल फिर से शुरू होने तक शेयर काम करता है

किसी सेवा को पते से बाँधना उसके सॉकेट को उस पते के जीवनकाल से जोड़ता है। जब टनल इंटरफ़ेस नष्ट करके फिर बनाया जाता है, पुराना पता गायब हो जाता है और उससे बँधा सॉकेट भी उसके साथ चला जाता है। सेवा चलती रहती है, पर जहाँ ग्राहक भेजे जाते हैं वहाँ कुछ सुनता नहीं।

यदि नया पता ICMP का जवाब दे तो ping अभी भी सफल हो सकता है, इसीलिए शेयर मृत होने पर भी पहुँच ठीक दिखती है। वही एक भ्रामक सफलता लोगों को फ़ायरवॉल की ओर भेजती है।

पहुँच बंधन पता नहीं है

यहाँ तीन निर्णय मिल जाते हैं। मार्ग तय करता है कि ग्राहक का पैकेट पहुँचता है या नहीं। सुनता सॉकेट तय करता है कि स्थानीय पते पर कोई उसे स्वीकार करता है या नहीं। शेयर कॉन्फ़िगरेशन और फ़ाइलसिस्टम अनुमतियाँ तय करती हैं कि उसके बाद क्या होगा। इंटरफ़ेस फिर बनने पर केवल दूसरा टूटता है।

VPN पूल का पता भी अपने आप स्थानीय बंधन पता नहीं होता। वह ग्राहक का है, फ़ाइल सर्वर का नहीं। फ़ाइल सेवा के लिए ping कमज़ोर परीक्षण है।

दस्तावेज़ीकरण में भी इन मालिकों को अलग रखें। VPN पूल में भविष्य का बदलाव Samba संपादित करने की माँग नहीं करना चाहिए, और शेयर अनुमति का बदलाव टनल फिर शुरू करने की माँग नहीं करना चाहिए।

इसके बजाय स्थिर पते से बाँधें

अधिक स्थिर डिज़ाइन Samba को स्थायी पते पर रखता है और VPN को ग्राहकों को वहाँ ले जाने देता है। टनल के हिचकोले खाने पर सर्वर का पता नहीं बदलता, इसलिए श्रोता को कभी इंटरफ़ेस का पीछा नहीं करना पड़ता। तब प्रवेश VPN मार्ग और होस्ट फ़ायरवॉल लागू करते हैं, जो इसी काम के लिए बने हैं।

यदि आपको टनल से बाँधना ही है, तो संस्थापित संस्करण का अनुबंध समझें। interfaces और bind interfaces only पैरामीटर एक ही बात नहीं हैं, और बंधन दस्तावेज़ रुक-रुक कर आने वाले इंटरफ़ेस की चेतावनी देता है। कुछ प्लेटफ़ॉर्म पर गतिशील श्रोता प्रबंधन मौजूद है, पर वह मानने की नहीं, जाँचने की क्षमता है। हिचकोले से पहले और बाद में तालिका पढ़ें और दोनों आउटपुट की तुलना करें।

ss -ltnp | grep ':445'

फिर से जुड़ना जाँचें, हरी बत्ती नहीं

सेवा शुरू होने के बाद ही नहीं, फिर से जुड़ने के बाद श्रोता जाँचें। टनल फिर बनाएँ, फिर सुनने की तालिका पढ़ें और पुष्टि करें कि जिस पते पर ग्राहक भेजे जाते हैं वहाँ सॉकेट मौजूद है। हरा टनल संकेतक और सफल कॉन्फ़िगरेशन जाँच इनमें से कोई भी साबित नहीं करते।

smbclient -L //files.corp.example -U alice

फिर ग्राहक से एक अनुमत क्रिया और एक अस्वीकृत पथ चलाएँ, और दूसरे फिर से जुड़ने के बाद दोहराएँ। यदि शेयर केवल पहले हिचकोले तक काम करता है, तो बंधन अभी भी इंटरफ़ेस के जीवनकाल से जुड़ा है और डिज़ाइन ठीक नहीं हुआ। बंधन या सेवा का पता बदलें, और लक्षण फिर आना बंद हो जाएगा।