OpenVPN ने पुश केलेले रूट स्थापित होत नाहीत: वेळ, अधिकार किंवा धोरण

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

बाहेरून ती सारखीच दिसतात आणि वेगळ्या दुरुस्त्या मागतात। रूटचा निर्णय ज्या ठिकाणी घेतला जातो तेथे क्लायंट लॉग वाचा।

रूट तुटलेला नाही तर अनुपस्थित आहे हे सिद्ध करा

रूट तुटलेला नाही तर अनुपस्थित आहे हे सिद्ध करून सुरुवात करा। Linux वर, ip route show dev tun0 क्लायंटने टनेल उपकरणावर काय स्थापित केले ते सूचीबद्ध करते। Windows वर, route print किंवा Get-NetRoute तीच गोष्ट तक्त्याच्या स्वरूपात दाखवते।

असलेला पण रहदारी पुढे न पाठवणारा रूट वेगळी समस्या आहे। त्यामुळे तपास रूट स्थापनेकडे नाही तर पुढे पाठवणे व फायरवॉल नियमांकडे जातो।

वेळ: उपकरण अस्तित्वात येण्यापूर्वीच जोडणी चालली

नियंत्रण चॅनेल वर आल्यानंतर आणि इंटरफेस संरचित केल्यानंतर क्लायंट सर्व्हरचे PUSH_REPLY विश्लेषित करतो। तेव्हाच तो प्लॅटफॉर्म जो यंत्रणा देईल त्या माध्यमातून राउटिंग तक्त्याला स्पर्श करतो। Linux netlink मधून जाते; Windows ला उन्नत टोकन लागणारे API वापरते। संरचना वाचताच रूट जोडणारी स्क्रिप्ट किंवा क्लायंट TUN/TAP उपकरण तयार होण्यापूर्वीच चालू शकतो, आणि कर्नेल जोडणी नाकारते।

तेच शर्यत स्पष्ट करते की हाताने लिहिलेला रूट का चालतो पण स्वयंचलित चालत नाही: तुम्ही तो लिहितो तेव्हा इंटरफेस आधीच वर असतो।

या प्रकरणासाठी route-delay आहे, आणि इंटरफेस व रूट संरचित झाल्यानंतर चालणाऱ्या स्क्रिप्टचे नाव route-up सांगते। टनेल पत्त्यावर अवलंबून असलेले रूट सुरुवातीच्या टप्प्यात नाही तर त्याच हुकमध्ये ठेवा।

अधिकार: तक्ता कोण बदलू शकतो

Windows राउटिंग तक्ता बदलण्यासाठी उन्नत टोकन लागते। सामान्य वापरकर्त्याने सुरू केलेला GUI सेवेमार्फत अडॅप्टरचा पत्ता ठेवू शकतो आणि तरीही रूट जोडू शकत नाही। मग लॉग गहाळ पुशऐवजी प्रवेश नाकारलेला अशा प्रकारची त्रुटी दाखवतो।

GUI प्रशासक म्हणून सुरू करणे, किंवा सेवा-आधारित क्लायंट वापरणे, तो निकाल बदलते। आवश्यक टोकनशिवाय क्लायंट सुरू करणारे नियोजित कार्य तसे करत नाही।

काहीही बदलण्यापूर्वी क्लायंट प्रत्यक्षात कोणत्या खात्यावर चालतो ते तपासा। आवृत्ती आणि सेवा मोड कोणती कारणे शक्य आहेत हे ठरवतात, म्हणून दोन्ही रूट आउटपुटजवळ नोंदवा।

धोरण: पुश केलेले रूट जाणूनबुजून वगळता येतात

route-nopull सर्व्हर पुश करतो ती रूट, त्यात पुश केलेले डीफॉल्ट रूटही, क्लायंटला दुर्लक्षित करायला लावते, तर टनेल पत्ता अजूनही स्वीकारला जातो। पुश केलेले DNS आणि DHCP पर्याय त्याच सूचनेने वगळले जातात। असा क्लायंट दोषपूर्ण नाही; तो स्वतःच्या संरचनेत स्पष्ट रूट ओळींची अपेक्षा करतो।

route-noexec वेगळे नियंत्रण आहे: ते क्लायंटला रूट बदल अजिबात राबवण्यापासून थांबवते। क्लायंट नकाशा करू शकत नाही अशी टोपोलॉजीही सारखा निकाल देऊ शकते, आणि रूट जोडलेला नाही तर नाकारलेला म्हणून नोंदवला जातो। तीनपैकी कोणते लागू आहे याचा अंदाज घेण्याऐवजी निर्णय सांगणारी लॉग ओळ वाचा। नंतर प्रभावी प्रोफाइल तपासा, कारण आयातक किंवा व्यवस्थापन साधन वापरकर्त्याने कधीही संपादित न केलेले पर्याय जोडू शकते।

मजकूर संपादकात स्वच्छ दिसणारे प्रोफाइल रनटाइममध्ये जोडलेली सूचना घेऊन असू शकते।

पुश यादीची तक्त्याशी तुलना करा

जोडल्यानंतर सर्व्हरची पुश यादी क्लायंटच्या तक्त्याजवळ ठेवा। Linux वर ती ip route show dev tun0 आहे; Windows वर route print किंवा Get-NetRoute। रूट नसल्यास आधी स्थापना दुरुस्त करा। तो असूनही रहदारी अयशस्वी झाल्यास पुढे पाठवणे व फायरवॉल धोरणाकडे जा।

क्लायंटची आवृत्ती, तो कोणत्या खात्यावर चालतो आणि सेवा-आधारित आहे का हे नोंदवा। ती तीन तथ्ये पुढील व्यक्तीला कोणती कारणे वगळली हे सांगतात।