तपाईंले नेटवर्क इन्टरफेसको नाम परिवर्तन गर्नुभयो, वा एडाप्टर अर्को नाममा फर्किएको मेसिन पुनर्स्थापित गर्नुभयो, र अब 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 जडान गर्नुहोस्, एउटा निजी स्रोतमा पुग्नुहोस् र प्रशासनिक पृष्ठ यसको अपेक्षित मार्गबाट खोल्नुहोस्। हालका प्रयोगकर्ता अनुमति र रद्दीकरण राख्नुहोस्; ती रिसेट गर्ने रिकभरीले बाइन्डिङ सुधारेर तैनाती गुमाएको हुन्छ। काम त्यतिबेला सकिन्छ जब त्यही सेवा यसको इच्छित इन्टरफेसमा चल्छ।

सम्बन्धित लेखहरू