एउटा OpenVPN हब, तीन LAN: ठेगाना योजना र iroute फाइलहरू

तीन निजी LAN एउटै हबमा भेट्न सक्छन्, कुनै पनि साइटले अरूको आन्तरिक संरचना जान्नु नपर्ने गरी, र सम्पूर्ण डिजाइन चार छोटा कन्फिगरेसन निर्णयमा टिकेको छ। यसलाई काम गराउने कुरा विचित्र प्रोटोकल सुविधा होइन, बरु कसैले अनुमान गर्नु नपर्ने ठेगाना योजना र कुन शाखा कुन प्रिफिक्सको मालिक हो भनी हबलाई बताउने ग्राहक-अनुसारको मार्गहरू हुन्। यीमध्ये एउटा पनि गलत भयो भने पनि सुरुङ उठ्छ, र ठ्याक्कै यसैले असफलतालाई अन्योलपूर्ण बनाउँछ।

चरणहरू क्रममा पूरा गर्नुहोस्। प्रत्येक चरण अघिल्लो चरणको योजनामा निर्भर छ, र तीमध्ये कुनैलाई पनि नयाँ प्रमाणपत्र प्राधिकरण आवश्यक पर्दैन।

कसैले अनुमान गर्नु नपर्ने योजनाबाट सुरु गर्नुहोस्

कन्फिगरेसन फाइल छुनु अघि चार अलग-अलग प्रिफिक्स लेख्नुहोस्: हबको आफ्नै LAN, प्रत्येक शाखाको LAN, र घुम्ती ग्राहकहरूलाई दिइने पूल। अलगावले नै बाँकी सबै सरल राख्छ, किनकि ओभरल्याप हुने दायराहरूले राउटिङलाई सबैभन्दा लामो मिलानको पहेली बनाउँछन्, जसलाई कति पनि ग्राहक-अनुसारको कन्फिगरेसनले सुधार्दैन। त्यसपछि प्रत्येक LAN का लागि कुन मेसिन डिफल्ट गेटवे हो भनी पुष्टि गर्नुहोस्, किनकि आफ्नै LAN को गेटवे नभएको शाखा राउटरले टाढाका मार्गहरू पूर्ण रूपमा अन्तै स्थापना गर्नुपर्छ। अन्तमा, प्रत्येक शाखालाई चिनाउने प्रमाणित नामहरू निर्धारण गर्नुहोस्, किनकि ती नामहरू नै ग्राहक-अनुसारका फाइलहरू खोज्ने कुञ्जीहरू हुन्।

एउटा उदाहरणीय योजनाले पूललाई तीन LAN बाट राम्रै पर राख्छ। तपाईंको फरक हुनेछ, र एकमात्र कडा नियम भनेको कुनै पनि दुई दायरा ओभरल्याप नहुनु हो।

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

शाखाहरू कहाँ छन् भनी हबको कर्नेललाई बताउनुहोस्

हबलाई प्रत्येक शाखाका लागि दुई जानकारी चाहिन्छ: प्रिफिक्सलाई सुरुङ उपकरणमा पठाउने कर्नेल मार्ग, र iroute प्रविष्टि, जसले कुन ग्राहक यसको मालिक हो भनी OpenVPN प्रक्रियालाई बताउँछ। केवल कर्नेल मार्गले प्याकेटहरूलाई सुरुङसम्म पुर्याएर त्यहीँ रोक्छ, किनकि डेमनले अझै कुन पियरले ती लिनुपर्ने हो भनी निर्णय गर्नुपर्छ। केवल iroute प्रविष्टिले ती प्याकेटहरूलाई कर्नेलमै पछ्याउने मार्ग बिना छोड्छ। दुवै लाइन डेमनले वास्तवमै लोड गर्ने कन्फिगरेसनमा पर्छन्, र अरू केही डिबग गर्नु अघि त्यो जाँच गर्न लायक छ।

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

कर्नेललाई नियम कार्यान्वयनको बिन्दु बनाउनुपर्ने बेलामा client-to-client बन्द राख्नुहोस्। त्यो विकल्पले पियरबीचको ट्राफिक डेमनभित्रै पठाउँछ, जुन सुविधाजनक छ र यसको अर्थ तपाईंका फर्वार्डिङ नियमहरूले त्यो प्रवाह कहिल्यै देख्दैनन् पनि हो। तलका सबै कुराले कर्नेलले प्रत्येक शाखा-अन्तर प्याकेट देख्छ भन्ने मान्छन्।

प्रत्येक शाखालाई आवश्यक मार्गहरू दिनुहोस्

प्रत्येक शाखालाई अन्य शाखाहरू र हबको LAN का लागि मार्ग चाहिन्छ, र आफ्नै जोडिएको LAN का लागि मार्ग चाहिँदैन। टाढाका प्रिफिक्सहरू प्रत्येक राउटरमा टाँस्नुको सट्टा हबबाट धकेल्नुहोस्, ताकि चौथो साइट पछि चार सम्पादनको सट्टा एउटा नयाँ ग्राहक-अनुसारको फाइल मात्र होस्। ग्राहक-अनुसारको फाइलमा iroute लाइन पनि हुन्छ, जसले स्वामित्व र घोषणा एउटै ठाउँमा राख्छ। डाइरेक्टरी र त्यसका फाइलहरूलाई सर्भरको विशेषाधिकार मोडेलअनुसार पढ्न योग्य बनाउनुहोस्, नत्र खोजी सन्देश बिना असफल हुन्छ।

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

चौथो साइटले पनि त्यही ढाँचा पछ्याउँछ: छुट्टै प्रमाणित नाम, स्वामित्वको प्रिफिक्स, हबको कर्नेल मार्ग, iroute प्रविष्टि, र त्यहाँ पुग्न अनुमति पाएका साइटहरूलाई मात्र घोषणा।

सकियो भन्नु अघि दुवै दिशामा परीक्षण गर्नुहोस्

तीनै राउटरमा IPv4 फर्वार्डिङ सक्रिय गर्नुहोस्, त्यसपछि फायरवालले अभिप्रेत प्रवाहहरूलाई दुवै दिशामा अनुमति दिन्छ भनी पुष्टि गर्नुहोस्, किनकि एकतर्फी परीक्षण भाँचिएको फिर्ती मार्गसँग कसैले अपेक्षा गरेभन्दा बढी पटक उत्तीर्ण हुन्छ। साइटहरूबीच स्रोत ठेगानाको अनुवाद आवश्यक पर्दैन, र मूल स्रोत जोगाउनु नै प्रत्येक शाखालाई अनुरोधमा आफ्नै नीति लागू गर्न दिने कुरा हो।

एउटा शाखा LAN को होस्टबाट अर्को शाखाको सेवासम्म परीक्षण गर्नुहोस्, त्यसपछि दिशा उल्टाउनुहोस्, त्यसपछि शाखाबाट हबको LAN सम्म परीक्षण गर्नुहोस्। ती तीन परिणाम फरक प्रमाण हुन्, र कुनैले पनि अरूलाई जनाउँदैन। शाखा राउटर आफ्नै LAN को डिफल्ट गेटवे होइन भने, वास्तविक गेटवेमा टाढाका प्रिफिक्सहरू स्थापना गर्नुहोस् र सुरुङ ग्राहकहरूले त्यो LAN मा जडान सुरु गर्नुपर्ने बेलामा पूल पनि समावेश गर्नुहोस्।

योजना, ग्राहक-अनुसारका फाइलहरू र फायरवाल नियमहरूलाई एउटै कागजातका रूपमा अभिलेख गर्नुहोस्, किनकि अर्को साइट थपाइ तिनैका आधारमा मूल्याङ्कन गरिनेछ।

डिजाइन एकजुट छ किनकि प्रत्येक तहको एउटै काम छ: योजनाले प्रिफिक्सहरू अद्वितीय राख्छ, कर्नेल मार्गले प्याकेटहरू सार्छ, iroute ले मालिकको नाम लिन्छ, र फायरवालले के अनुमति छ भनी निर्णय गर्छ। केही बिग्रँदा त्यही सूची जाँचको क्रम पनि हुन्छ।