एक OpenVPN हब, तीन LAN: पत्ता योजना आणि iroute फाइल्स
चार वेगळे प्रीफिक्स, प्रत्येक शाखेसाठी एक कर्नेल मार्ग, प्रत्येक मालकासाठी एक 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 मालकाचे नाव घेते, आणि फायरवॉल काय परवानगी आहे हे ठरवते। काही बिघडल्यास तीच यादी तपासणीचा क्रमही असते।