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

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