लिनक्स पर OpenVPN सुरंग (और शायद * BSD) पर गतिशील रूटिंग (विशेष रूप से बीजीपी) की स्थापना

यह लेख क्यों और किस बारे में है?

यदि आप "Openvpn bgp" विषय पर गूगल करते हैं, तो आप व्यावहारिक दृष्टिकोण से कई रोचक और उपयोगी लेख पा सकते हैं (उदाहरण के लिए, एक या दो बार )। लेकिन हेडलाइन में समस्या को हल करना शुरू करना, कई कारणों से मैंने इसे गूगल करने की भी जहमत नहीं उठाई। सामान्य रूप से ओपनवीपीएन के साथ लंबे काम के दौरान (दोनों पक्षों पर नेटवर्क के एक निश्चित सेट के साथ, काफी विशिष्ट कार्यों के ढांचे के भीतर) किसी तरह का विचार आया, मिक्रोटिक राउटरओएस सिस्टम पर ओपनवीपीएन कार्यान्वयन के साथ काम करना और लिनक्स और राउटरओएस पर सिस्टम को एक दूसरे के बीच डॉक करना। वास्तव में, राउटरओएस में ओपनवीपीएन के हमारे स्वयं के कार्यान्वयन को लिखने के कारणों को महसूस करने की प्रक्रिया में, "अंतर्दृष्टि" के बारे में आया कि यह समस्या पूरी तरह से कर्मचारी ओपनवीपीएन संस्करण के ढांचे के भीतर कैसे हल की जा सकती है। तब एक छोटी प्रयोगात्मक जाँच हुई, जिसने विचार की पूर्ण कार्य क्षमता और इस समाधान को "औद्योगिक" ऑपरेशन में लॉन्च किया।

यह ध्यान में रखते हुए कि यह स्थिति विभिन्न अनुप्रयोगों के लिए काफी विशिष्ट है, और नीचे वर्णित समाधान अभी तक प्रस्तुत नहीं किया गया है, मैंने समुदाय के साथ विचार साझा करने का निर्णय लिया।

समस्या का सार ("दोष किसे देना है?")

OpenVPN के नियमित संस्करण और राउटरओएस में लागू होने वाले के बीच क्या अंतर है? शायद कुछ अंतर हैं, लेकिन इस लेख में हम केवल एक ही चीज पर विचार करेंगे: राउटरओएस (और संभवतः कुछ अन्य) के अलावा अन्य प्रणालियों में नियमित ओपनवीपीएन एक संयोजन है जिसमें परिवहन भाग होता है (अर्थात, पैकेट संचरण स्वयं, यह अग्रेषण भी है, यह एक डेटा प्लेन भी है ) और रूटिंग (अर्थात, मार्गों के बारे में जानकारी का आदान-प्रदान करना, यह रूट करना है, यह एक नियंत्रण विमान भी है), और राउटरओएस में ओपनवीपीएन सेवा केवल परिवहन भाग के लिए जिम्मेदार है, और राउटिंग को एक अलग सिस्टम प्रक्रिया द्वारा नियंत्रित किया जाता है, जो एक तरफ रूटिंग की कार्यक्षमता की नकल नहीं करने देता है सिस्टम (और इसके अलावा, विभिन्न सेवाओं में कई समान रूट टेबल नहीं रखते हैं और लगातार उन्हें एक-दूसरे के साथ सिंक्रनाइज़ करते हैं), और दूसरी तरफ, ऐसे वाहनों पर रूट टेबल के पारदर्शी हस्तांतरण और मक्खी पर दोनों तरफ से रूट टेबल बदलने की अनुमति देता है।

इसके अलावा, ओपनवीपीएन के नियमित कार्यान्वयन में एक और कमी है: मार्गों का हस्तांतरण केवल एक दिशा में (सर्वर से क्लाइंट तक) होता है और केवल एक सत्र की स्थापना के समय (यानी, सुरंग को ऊपर उठाना) होता है। सुरंग संचालन के दौरान जाने पर आंतरिक ओपनवीपीएन मार्ग तालिका में एक मार्ग जोड़ने के लिए कोई नियमित तरीका नहीं है, साथ ही साथ मार्गों को एक तरफ से दूसरे स्थान पर स्थानांतरित किया जाता है। इसके अलावा, मार्ग तालिका स्वयं प्राप्त करना भी संभव नहीं है।

समस्या का समाधान ("क्या करें")

मेरी लिपियों का विश्लेषण जो विभिन्न ग्राहकों को मार्गों के काम को स्वचालित करता है, मैंने देखा कि OpenVPN के पास दो अलग-अलग विकल्प हैं जो मार्ग निर्दिष्ट करते हैं:

• i route - OpenVPN प्रक्रिया के राउटिंग टेबल के अंदर मार्गों को सेट करता है।
• route - उन मार्गों को सेट करता है जो OpenVPN प्रक्रिया सिस्टम मार्ग तालिका में गुजरती है (अर्थात, डिस्कनेक्ट होने पर उन्हें कनेक्ट और हटाते समय अपने सुरंग इंटरफ़ेस के माध्यम से तालिका में मार्गों को जोड़ता है)।

स्पष्ट प्रश्न उठता है: यदि i route का उपयोग कर दोनों तरफ मार्ग 0.0.0.0/0 जोड़ देता i route तो क्या होगा और फिर सुरंग इंटरफ़ेस पर आवश्यक मार्गों (जिनमें वे गतिशील रूप से दिखाई देते हैं या गायब हो जाते हैं) को जोड़ते हैं या हटाते हैं, उदाहरण के लिए, एक रूटीन सेवा के साथ कराई, ज़ेबरा / क्वैगा, पक्षी, आदि)?

प्रयोग से पता चला कि इस तरह की योजना वास्तव में थोड़ी प्रतिबंध-असुविधा के साथ काम करती है: केवल एक ग्राहक को एक सर्वर सुरंग से जोड़ा जा सकता है। बाकी सर्किट पूरी तरह से चालू हो गए।

यह योजना टीएलएस-ओवर-टीसीपी मोड में चल रही है, अर्थात, कॉन्फ़िगरेशन के लिए, आपको सबसे पहले एसएसएल कीज और सर्टिफिकेट तैयार करना होगा।

नीचे मैं सर्वर और क्लाइंट पक्ष के लिए एक उदाहरण OpenVPN कॉन्फ़िगरेशन देता हूं।

सर्वर-साइड कॉन्फ़िगरेशन (प्रत्येक क्लाइंट के लिए एक)।

server_dyn_rt.conf फ़ाइल (सर्वर साइड)

 daemon compress ping-timer-rem persist-tun persist-key tls-server proto tcp-server topology net30 mode server script-security 3 keepalive 15 45 tun-mtu 1500 remote-cert-tls client verify-x509-name <CLIENT_DISTINGUISHED_NAME> name auth <TLS_AUTH_ALGORITHM> cipher <CIPHER_ALGORITHM> local <SERVER_PUBLIC_IP> lport <SERVER_PUBLIC_PORT> dev-type tun dev <TUNNEL_INTERFACE_NAME> ifconfig <TUNNEL_SERVER_SIDE_IP> <TUNNEL_CLIENT_SIDE_IP> client-connect client_connect.sh push "route-gateway <TUNNEL_SERVER_SIDE_IP>" push "topology net30" push&nbsp"persist-tun" push&nbsp"persist-key" <dh> ... Diffie-Hellman data <</dh> <ca> ... Certificate Authority certificate data </ca> <cert> ... Server certificate data </cert> <key> ... Server Private Key data </key> 

फ़ाइल client_connect.sh (सर्वर साइड)

 #!/bin/sh echo 'ifconfig-push TUNNEL_CLIENT_SIDE_IP TUNNEL_SERVER_SIDE_IP' >> ${1} echo 'push "iroute 0.0.0.0 0.0.0.0"' >> ${1} echo 'iroute 0.0.0.0 0.0.0.0' >> ${1} exit 0 

client_dyn_rt.conf फ़ाइल (क्लाइंट पक्ष)

 daemon compress tls-client auth <TLS_AUTH_ALGORITHM> cipher <CIPHER_ALGORITHM> client dev-type tun dev <TUNNEL_INTERFACE_NAME> script-security 3 remote-cert-tls server verify-x509-name <SERVER_DISTINGUISHED_NAME> name remote <SERVER_PUBLIC_IP> <SERVER_PUBLIC_PORT> tcp <ca> ... Certificate Authority certificate data </ca> <cert> ... Client certificate data </cert> <key> ... Client Private Key data </key> 

मैं पैकेट की विविधता और राउटिंग प्रोटोकॉल की वजह से या तो पैकेट की विविधता के कारण या स्वयं की विविधता के कारण (वास्तव में, कॉन्फ़िगरेशन के उदाहरणों के स्रोत के रूप में, आप लेख के दूसरे भाग का उपयोग कर सकते हैं, जो लिंक लेख की शुरुआत में दिए गए हैं)। मैं बस यह नोट करना चाहता हूं कि उपरोक्त सेटिंग आपको विशेष रूप से बीजीपी (जो मुझे व्यक्तिगत रूप से पसंद है क्योंकि इसकी "नियंत्रणीयता" और एक ही सत्र के भीतर विभिन्न प्रोटोकॉल के मार्गों को प्रसारित करने की क्षमता) दोनों का उपयोग करने की अनुमति देता है। बीजीपी के मामले में, पता <TUNNEL_CLIENT_SIDE_IP> का उपयोग पड़ोसी के पते के रूप में "सर्वर" पक्ष पर किया जाना चाहिए, और पता <TUNNEL_SERVER_SIDE_IPIP या संबंधित पक्ष के "आंतरिक" पते का उपयोग क्लाइंट पक्ष पर किया जाना चाहिए, लेकिन फिर आपको संबंधित मार्गों को जोड़ना होगा। सर्वर और / या ग्राहक।

ऊपर दिए गए समाधान के पेशेवरों और विपक्ष

विपक्ष:

1. प्रति सर्वर पर बिल्कुल एक क्लाइंट होना चाहिए, इसलिए कई क्लाइंट के लिए आपको कई ओपनवीपीएन प्रक्रियाओं को सक्रिय रखना होगा। एक परिणाम के रूप में - कुछ स्मृति उग आया और वह सब।
2. आप OpenVPN में प्रेस्क्राइब्ड की-मोड का उपयोग नहीं कर सकते, क्योंकि इस मोड में सर्वर से क्लाइंट (पुश / पुल) में मापदंडों का डायनामिक ट्रांसफ़र प्रतिबंधित है। इस वजह से, एक अधिक जटिल कॉन्फ़िगरेशन की आवश्यकता होती है, जिसमें कुंजी और प्रमाण पत्र के एक सेट की पीढ़ी भी शामिल है, साथ ही सर्वर साइड पर क्लाइंट कॉन्फिगरेशन चंक उत्पन्न करने के लिए एक स्क्रिप्ट भी है (जो, client-connect /path/to/script विकल्प के साथ client-connect-dir /path/to/config/dir ऑप्शन द्वारा स्टैटिक फ़ाइलों की निर्देशिका से बदला जा सकता है) client-connect-dir /path/to/config/dir , जो सर्वर साइड के सुरक्षा स्तर को बढ़ाता है।

पेशेवरों:

1. GRE / IPIP जैसे प्रोटोकॉल के विपरीत, OpenVPN सुरंगों में 1500 बाइट्स का MTU हो सकता है (क्योंकि OpenVPN प्रक्रिया सुरंग इंटरफ़ेस में पूर्ण लंबाई के पैकेट भेजकर "हुड के नीचे" सभी विखंडन / डीफ़्रेग्मेंटेशन छुपाती है)। इससे ओपनवीपीएन सुरंग पर सभी प्रकार की माध्यमिक सुरंगों को कॉन्फ़िगर करना आसान हो जाता है।
2. OpenVPN सुरंग एक साथ IPv4 और IPv6 दोनों के संचरण का समर्थन करती है, जो नोड्स के जोड़े के बीच सुरंगों की संख्या को कम करती है, उनके विन्यास और प्रशासन की लागत, साथ ही IPv4 मार्गों के साथ समान BGP सत्र के भीतर IPv6 मार्गों को प्रसारित करती है।
3. OpenVPN प्रोटोकॉल के सभी फायदे, जैसे मध्यवर्ती नेटवर्क उपकरण स्थापित करने में आसानी (या इसके लिए आवश्यकता की कमी), HTTPS के तहत ट्रैफ़िक को मुखौटा करने की क्षमता, अधिकांश प्लेटफार्मों के लिए कार्यान्वयन की उपस्थिति एट वगैरह, वगैरह।

मुझे उम्मीद है कि किसी को उपरोक्त गाइड उपयोगी मिलेगा।