नेटवर्क इंटरफेसचे नाव बदलल्यानंतर Access Server ने त्याचे बंधन गमावले: किल्ल्या दुरुस्त करा

तुम्ही नेटवर्क इंटरफेसचे नाव बदलले आहे, किंवा अडॅप्टर दुसऱ्या नावाने परत आलेले यंत्र पुनर्संचयित केले आहे, आणि आता OpenVPN Access Server चा डेमन सुरू होत नाही. वेब इंटरफेस कदाचित अजूनही प्रतिसाद देईल किंवा देणार नाही, जुन्या नावाशी कोणता घटक जोडलेला होता यावर अवलंबून. सेवा खराब झाली नाही आणि कॉन्फिगरेशन गेले नाही; एक सेटिंग अजूनही होस्टकडे नसलेल्या इंटरफेसकडे दाखवते.

नेहमीची प्रतिक्रिया म्हणजे त्रुटी जाईपर्यंत पुन्हा इंस्टॉल करणे, पुन्हा सुरू करणे किंवा डेटाबेस संपादित करणे. प्रत्येकजण दोषापेक्षा मोठा बदल आहे, आणि शेवटचा तो वापरकर्ते, परवानग्या आणि अवलंबित्व पुसू शकतो ज्यामुळे सर्व्हर वाचवण्यासारखा होता. ही बंधनाची समस्या आहे आणि तिला नामनिर्देशित उपाय आहे.

लक्षण खरे काय सांगते

बांधता न येणारा डेमन सहसा स्वतःच्या लॉगमध्ये सांगतो: पत्ता उपलब्ध नाही किंवा इंटरफेस अस्तित्वात नाही. संदेश ठोस आहे: डेमनने प्रयत्न केलेला पत्ता तो सांगतो; होस्टवरील ip -br addr शी तुलना केल्यास इंटरफेसचे नाव बदलले, काढले किंवा जुन्या पत्त्याशिवाय उभारले हे कळते.

संपूर्ण वेळ अधिकृत रिकव्हरी कन्सोल उघडे ठेवा. बदलावायचे बंधन तुमचे एकमेव प्रशासकीय सत्र वाहत असेल तर तुम्ही परतीचा रस्ता कापला आहे. स्थानिक कन्सोल, दुसरा व्यवस्थापन पत्ता किंवा दस्तऐवजी बाह्य मार्ग बदल परत करण्यायोग्य करतात.

संपादित करण्यापूर्वी कॉन्फिगरेशन विचारा

Access Server त्याचे कॉन्फिगरेशन त्याच्या स्वतःच्या CLI द्वारे दाखवते. दस्तऐवजी दृश्य असे आहे:

sacli ConfigQuery

ते तुमच्या आवृत्तीसाठी दस्तऐवजी प्रशासकीय वातावरणात चालवा, दुसऱ्या होस्टवरील असंबंधित शेलमधून नाही. काहीही बदलण्यापूर्वी सध्याची मूल्ये सुरक्षित जागी साठवा आणि संपूर्ण आउटपुट सार्वजनिक सहाय्य धाग्यात चिकटवू नका.

ते आउटपुट सर्व्हर कॉन्फिगरेशनचे दृश्य आहे, पूर्ण बॅकअप नाही. वापरकर्ता आणि गट गुणधर्म वेगळे विचारले जातात, त्यामुळे स्वच्छ बंधन ओळख पुनर्संचयित करत नाही, आणि पुनर्संचयित ओळख श्रोत्याला दुरुस्त करत नाही. दोन्ही दोन वेगळ्या दस्तऐवजांत नोंदवा.

कोणता श्रोता तुटलेला आहे ते ठरवा

Access Server एकापेक्षा जास्त श्रोते चालवतो. OpenVPN डेमन टनेल रहदारी वाहतात, वेब सेवा प्रशासकीय आणि ग्राहक पोर्टल वाहते, आणि इतर घटकांचे स्वतःचे पोर्ट असू शकतात. अयशस्वी ब्राउझर विनंती कोणते अयशस्वी झाले सांगत नाही, त्रुटी संदेशातील पोर्ट क्रमांकही सांगत नाही.

डेमनच्या बंधन किल्ल्या प्रति डेमन दस्तऐवजी आहेत, आणि अधिकृत ट्युटोरियलमध्ये मूल्य इंटरफेस ओळखकर्ता आहे, जरी किल्लीची नावे ip_address ने संपत असली तरी. ते वाक्य दोन वेळा वाचा. ट्युटोरियल UDP आणि TCP डेमन एक इंटरफेस सामायिक करतील अशी अपेक्षा करते, त्यामुळे फक्त एक किल्ली दुरुस्त करणे अर्धवट दुरुस्ती आहे.

नामनिर्देशित सेटिंग बदला, जुळणाऱ्या ओळी नाही

ट्युटोरियल ConfigPut विशिष्ट किल्ल्यांवर दस्तऐवजी करते, जसे vpn.daemon.0.server.ip_address आणि vpn.daemon.0.listen.ip_address. उत्पादनाची स्वतःची पद्धत किल्लीचे नाव आणि नवे मूल्य यासह, तुमच्या आवृत्तीसाठी दस्तऐवजी वाक्यरचनेत वापरा, आणि तुम्ही निदान केलेल्या श्रोत्याच्या किल्ल्या केवळ बदला.

जे करू नये ते म्हणजे डेटाबेसमध्ये ज्याचे मूल्य जुन्या इंटरफेस नावासारखे आहे अशा प्रत्येक ओळी शोधून सर्व बदलणे. ते जुने नाव केवळ श्रोता सेटिंगमध्ये होते असे गृहीत धरते, ज्याची स्कीमा हमी देत नाही. ते बदल पुनरावलोकनास अशक्यही करते.

आणखी दोन प्रलोभने नाकारण्यासारखी आहेत. सर्व इंटरफेसवर ऐकणारे डीफॉल्ट पुनर्संचयित करणे हे उघड होण्याचा निर्णय आहे, स्पेलिंग दुरुस्ती नाही; इच्छित स्थानिक बंधन, प्रकाशित मार्ग आणि त्यापुढील फिल्टरिंग त्या निवडीशी जुळले पाहिजेत. कॉन्फिगरेशन पुन्हा सुरू करणे समस्या सोडवण्याऐवजी तिचे नाव बदलते, कारण नवीन इंस्टॉल नाव बदलण्यापूर्वी काम करणारे वापरकर्ते आणि परवानग्या टाकून देतो.

ते लागू करा, नंतर मार्ग काम करतो हे सिद्ध करा

मूल्य दुरुस्त केल्यानंतर उत्पादनाच्या दस्तऐवजी जीवनचक्रातून ते लागू करा ( जीवनचक्र ). ट्युटोरियल किल्ल्या सेट केल्यानंतर sacli start वापरते; ते पूर्ण होस्ट रीबूट किंवा डेटाबेस रीसेट नाही.

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

श्रोता तपासा, नंतर एक अधिकृत VPN कनेक्शन करा, एक खाजगी संसाधन गाठा आणि प्रशासकीय पृष्ठ त्याच्या अपेक्षित मार्गाने उघडा. सध्याच्या वापरकर्ता परवानग्या आणि रद्दीकरणे ठेवा; ती रीसेट करणाऱ्या रिकव्हरीने बंधन दुरुस्त केले आणि तैनाती गमावली. काम तेव्हा पूर्ण होते जेव्हा तीच सेवा तिच्या इच्छित इंटरफेसवर काम करते.