एउटा 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 वा सर्भरमा खुला पोर्टले यीमध्ये केही पनि प्रमाणित गर्दैन, किनकि समकक्षबीचको फर्वार्डिङ अझै अवरुद्ध हुँदा दुवै सत्य हुन सक्छन्। ती संख्या टनेल माथि हुँदा लेख्नुहोस्, किनकि पुनः जोडिएपछि क्लाइन्टले पाउने ठेगाना अर्कै हुन सक्छ।