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

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