तीन निजी 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

जब कर्नेल को प्रवर्तन बिंदु होना है तो क्लाइंट-टू-क्लाइंट बंद रखें। वह विकल्प डेमन के भीतर साथियों के बीच ट्रैफ़िक रिले करता है, जो सुविधाजनक है और इसका मतलब यह भी है कि आपके फ़ॉरवर्डिंग नियम इस प्रवाह को कभी नहीं देखते। नीचे सब कुछ मानता है कि कर्नेल हर शाखा-से-शाखा पैकेट देखता है।

हर शाखा को ज़रूरी रूट दें

हर शाखा को दूसरी शाखाओं और हब के 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 मालिक का नाम लेता है, और फ़ायरवॉल तय करता है कि किसकी अनुमति है। जब कुछ टूटता है, तो वही सूची जाँचने का क्रम भी है।

संबंधित लेख