OPNsense मागे OpenVPN क्लायंटचे स्थिर पत्ते

नावांना हलत नसलेले पत्ते लागतात, आणि OpenVPN ची pool फाइल पत्त्याला फक्त चिकट बनवते। ती फाइल गमावली, किंवा दुसऱ्या सामान्य नावाखाली प्रमाणपत्र पुन्हा जारी केले, तर परत येणारा क्लायंट pool मध्ये दुसरीकडे उतरतो, तर त्याची DNS नोंद अजूनही जुन्या पत्त्याकडेच निर्देश करते। टिकाऊ उत्तर म्हणजे पत्ता पिन करणारे क्लायंट-विशिष्ट ओव्हरराइड, सोबत रुंद टनल नेटवर्क जेणेकरून पिन केलेले पत्ते गतिशील श्रेणीबाहेर राहतील। त्या रुंदीकरणामागील गणित हेच बहुतेक गोंधळ राहतो ते ठिकाण।

OPNsense हे ओव्हरराइड सर्व्हरच्या क्लायंट-विशिष्ट सेटिंग्जमध्ये ठेवते, प्रमाणपत्राच्या सामान्य नावाने किल्ली दिलेली, ज्यामुळे सामान्य नाव पत्ता योजनेचा भाग होते।

चिकट लीज स्थिर पत्ता नाही

pool फाइल पत्ता-ते-क्लायंट मॅपिंग लिहिते आणि ओळखीचा क्लायंट पुन्हा जोडला गेल्यावर ती परत देते। हे सोय आहे, करार नाही: फाइल पुन्हा तयार करता येते, क्लायंटची ओळख बदलल्यावर मॅपिंग नाहीशी होते, आणि एकच pool सामायिक करणारे दोन सर्व्हर यावर सहमत होणार नाहीत। क्लायंट-विशिष्ट ओव्हरराइड वेगळ्या पद्धतीने काम करते, कारण पत्ता इतिहासातून नाही, संरचनेतून येतो। ते उपकरणाचा रीस्टार्ट आणि पुनर्स्थापनाही टिकून राहते, जर ओव्हरराइड उर्वरित संरचनेसोबत बॅकअप घेतले असेल।

गतिशील पर्याय, म्हणजे client-connect स्क्रिप्ट आणि गतिशील अद्यतनांद्वारे VPN ला DNS शी जोडणे, काम करतो आणि अद्यतने स्वीकारणारा resolver, सोबत प्रत्येक कनेक्शनला स्क्रिप्ट लागतो। उपकरणावर तुम्ही विक्रेता पुरवतो त्या पॅकेजपुरते मर्यादित आहात, आणि सहसा तिथेच ती योजना थांबते।

ज्याचा कोणी आनंद घेत नाही ते /30 गणित

डीफॉल्ट net30 टोपोलॉजीत प्रत्येक क्लायंटला स्वतःचे /30 मिळते: पहिला वापरण्यायोग्य पत्ता सर्व्हर बाजूला जातो, दुसरा क्लायंटला। म्हणून ओव्हरराइड सर्व्हरच्या गतिशील टनल नेटवर्कबाहेर असले पाहिजेत, याचा अर्थ आधी ते नेटवर्क रुंद करावे लागेल। 10.8.0.0/24 वरील सर्व्हर 10.8.0.0/23 वर जाऊ शकतो, जुन्या श्रेणीचा अर्धा भाग गतिशील क्लायंटसाठी आणि दुसरा अर्धा ओव्हरराइडसाठी ठेवून। मूळ /24 अतिरिक्त IPv4 स्थानिक नेटवर्क म्हणून जोडा, जेणेकरून दोन्ही अर्ध्यांकडील रहदारी टनलमध्ये राउट होईल।

प्रत्येक ओव्हरराइड पत्ता /30 सीमेवर पडला पाहिजे, म्हणून शेवटचा ऑक्टेट चारचा गुणक असतो। 10.8.1.0 वरील /30 क्लायंटला 10.8.1.2 देतो, आणि DNS नोंद तोच पत्ता वाहते। त्याऐवजी 10.8.1.3 निवडल्यास जोडणारा पण रहदारी पुढे पाठवू न शकणारा क्लायंट तयार होतो, कारण पत्ता अशा सबनेटचा आहे जे टोपोलॉजीने त्याला कधीच दिले नाही।

रुंद केलेल्या श्रेणीच्या वरून खाली ओव्हरराइड वाटप केल्यास योजना राखणे सोपे होते, जेणेकरून गतिशील pool स्थिर बेटांच्या आसपास नाही, रिकाम्या जागेत पसरते।

स्थानिक नेटवर्क आणि क्लायंट विचारतात तो झोन

क्लायंट-ते-क्लायंट रहदारीला स्वतःची परवानगी लागते। सर्व्हरच्या IPv4 स्थानिक नेटवर्क यादीत श्रेणीचे दोन्ही अर्धे भाग असले पाहिजेत, गतिशील आणि स्थिर; ते नसल्यास सर्व्हर एका क्लायंटकडून पॅकेट स्वीकारतो आणि ते दुसऱ्याकडे जाऊ देणारे धोरण त्याच्याकडे नसते। लक्षण DNS बिघाडासारखे दिसते, कारण नाव सुटते आणि कनेक्शन तरीही अयशस्वी होते। त्याच वेळी क्लायंट-ते-क्लायंट सेटिंगही तपासा, कारण केवळ स्थानिक-नेटवर्क नोंद सहकाऱ्यांमधील फॉरवर्डिंग सुरू करत नाही।

नोंदी त्या झोनमध्ये प्रकाशित करा जो दूरस्थ क्लायंट प्रत्यक्षात विचारतात। केवळ LAN resolver सेवा देत असलेल्या झोनमधील नोंद, ढकललेला resolver दुसरीकडे निर्देश करणाऱ्या क्लायंटला अदृश्य असते, आणि चुकीच्या झोनमध्ये अधिक नोंदी जोडल्याने ते कधीही सुधारत नाही। काहीही जोडण्यापूर्वी ढकललेला DNS पर्याय आणि शोध डोमेन खात्री करा।

नवीन कनेक्शनवर काय तपासावे

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

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