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 मा फर्काउँछ। कुनै पनि पहिचान परिवर्तनपछि त्यसको अपेक्षा गर्नुहोस्।