एक OpenVPN क्लाइंट को SSH से दूसरे तक पहुँचने दें, पूल खोले बिना

एक क्लाइंट को दूसरे क्लाइंट की SSH सेवा तक पहुँचना है, और पूल का बाकी हिस्सा आज जितना अलग है उतना ही रहना चाहिए। लुभावना स्विच client-to-client है, जो सभी के लिए एक साथ सहकर्मी पहुँच चालू कर देता है और निर्णय कर्नल के बजाय OpenVPN को सौंप देता है। अधिक सीमित उत्तर उस स्विच को बंद रखता है और सर्वर के अपने रूटिंग और फ़ायरवॉल को ठीक एक प्रवाह उठाने देता है।

तंत्र नियम के पाठ से अधिक मायने रखता है, क्योंकि दोनों दृष्टिकोण पैकेट को अलग-अलग जगह रखते हैं। यह जानना कि आपने कौन सा चुना, उस नियम को भी समझाता है जो कुछ न करता दिखता है और उस सहकर्मी को भी जो उसके बिना जुड़ता है।

client-to-client पैकेट को कहाँ ले जाता है

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

अदला-बदली स्पष्ट है: आप एक नीति बिंदु पाते हैं और वह रूटिंग और फ़ॉरवर्डिंग अपने ऊपर लेते हैं जो शॉर्टकट आपके लिए कर रहा था। वह काम एक प्रवाह के लिए छोटा है और हर उस अपवाद के साथ बढ़ता है जो आप जोड़ते हैं। अपवाद अभी गिनें, क्योंकि नियम-समुच्चय ही वह जगह है जहाँ सहकर्मियों के बीच नीति वास्तव में रहती है।

वह रास्ता जो सहकर्मी का पैकेट वास्तव में लेता है

मान लें Linux Community OpenVPN 2.6 सेवा, DCO के बजाय उपयोगकर्ता स्थान में TUN प्रसंस्करण, सबनेट टोपोलॉजी, tun0, और 10.44.0.0/24 का पूल जिसमें क्लाइंट A 10.44.0.21 पर और क्लाइंट B 10.44.0.37 पर है। सबनेट टोपोलॉजी में A को मिला पता और नेटमास्क पहले ही पूल को ढकते हैं, इसलिए A पैकेट को बिना किसी अतिरिक्त धकेले गए रूट के टनल डिवाइस तक भेजता है। A पर प्रभावी रूट जाँचें, बजाय मान लेने के।

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

सर्वर पर दो नियम, इसी क्रम में

तीन नियम पूरी अनुमति उठाते हैं: फ़ॉरवर्डिंग, जोड़ी का अपवाद, और टनल जोड़ी के लिए डिफ़ॉल्ट ड्रॉप। स्वीकृति नियम जोड़ी और सेवा का नाम लेता है, इसलिए अनुमति बढ़ते पूल में टिकी रहती है। इसे टनल-से-टनल ट्रैफ़िक के किसी भी व्यापक इनकार से पहले रखें, क्योंकि पहला मेल जीतता है:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

ये आदेश उदाहरण हैं और उसी तंत्र के हैं जो आपका होस्ट नियम सहेजने के लिए इस्तेमाल करता है; चलते समय डाला गया नियम अगली बार बूट पर गायब हो जाता है। स्थिति वाला नियम ही B के उत्तरों और TCP हाथ मिलाने को दूसरी, प्रतिबिंबित स्वीकृति के बिना लौटने देता है।

बाद में नियमों की सूची नहीं, काउंटर जाँचें, क्योंकि जो नियम कभी मेल नहीं खाता वह काम करने वाले जैसा ही दिखता है। अगर काउंटर शून्य पर रहें, तो पैकेट वह रास्ता नहीं ले रहा जो आप सोचते हैं।

B को अभी भी क्या अनुमति देनी है

B ही SSH सेवा चलाता है, इसलिए B तय करता है कि टनल पते पर कुछ सुन रहा है या नहीं और उसका अपना होस्ट फ़ायरवॉल स्रोत स्वीकार करता है या नहीं। सर्वर पर नेटवर्क अनुमति B के किसी भी खाते के लिए अनुमति नहीं है, और होस्ट कुंजी सत्यापन तथा उपयोगकर्ता प्रमाणीकरण आज भी कहीं और से आने की तरह लागू हैं।

पहले सकारात्मक स्थिति जाँचें: A से B के टनल पते तक नया SSH कनेक्शन, अपेक्षित होस्ट कुंजी के साथ स्वीकृत। फिर कोई दूसरा सहकर्मी या दूसरा पोर्ट जाँचें और पुष्टि करें कि वह अस्वीकृत है, क्योंकि चुपचाप सब कुछ अनुमति देने वाली अनुमति काम करने वाली से तब तक अलग नहीं दिखती जब तक बात महत्वपूर्ण न हो। उस परीक्षण के दोनों आधे ज़रूरी हैं, और दूसरा वही है जिसे लोग छोड़ देते हैं।

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