एका 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 किंवा सर्व्हरवर उघडा पोर्ट यापैकी काहीही सिद्ध करत नाही, कारण समवयस्कांमधले फॉरवर्डिंग अजूनही अडवलेले असताना दोन्ही खरे असू शकतात. ते आकडे टनल वर असताना लिहा, कारण पुन्हा जोडल्यानंतर क्लायंटला मिळणारा पत्ता वेगळा असू शकतो.