VPN क्लाइन्टहरूलाई टनेलमा एकअर्कासम्म पुग्नबाट रोक्नुहोस्

दुई क्लाइन्टले दुवै जम्प होस्ट खोल्न सक्छन् र तैपनि एकअर्कालाई खोल्ने कुनै काम तिनीहरूसँग हुँदैन। सेवासम्म पुग्नु फर्वार्डिङ निर्णय हो, जबकि पियरसम्म पुग्नु नीति निर्णय हो, र अधिकांश VPN स्ट्याकहरू यी दुईलाई छुट्टाछुट्टै वस्तुमा राख्छन्। पहिलोका लागि तपाईंले कन्फिगर गर्ने कुनै पनि कुराले दोस्रो लागू गर्दैन। त्यसैले काम नियम थप्नु होइन, बरु यो सर्भरमा पियर ट्राफिक निर्धारण गर्ने वस्तु खोज्नु, त्यहाँ निषेध लेख्नु र क्लाइन्टबाट त्यो प्रमाणित गर्नु हो।

साझा सेवासम्मको मार्ग पियरहरूबीचको अनुमति होइन

क्लाइन्ट सबनेट घोषणा गर्नुले पियरलाई अर्को क्लाइन्टको ठेगानातर्फ प्याकेट तारमा कसरी राख्ने भनेर बताउँछ। त्यो प्याकेट पुग्छ कि पुग्दैन भन्ने पछि, त्यसलाई फर्वार्ड गर्ने कुराले निर्धारण गर्छ। Linux गेटवेमा त्यो FORWARD शृंखला हो; प्रयोगकर्ता स्पेसको डेमनभित्र त्यो टनेलको आफ्नै सत्र तालिका हो। मार्गले पहुँचयोग्यताको जवाफ दिन्छ र अनुमतिलाई छुँदैन।

त्यसैले केवल मार्ग पढ्ने अलगाव परीक्षणले केही पनि प्रमाणित गर्दैन। /24 हरेक क्लाइन्टमा पठाउन सकिन्छ, जबकि पियरबीचको हरेक प्याकेट फर्वार्ड हुकमा खसालिन्छ। खतरनाक अवस्था उल्टो हो: कुनै स्पष्ट नियम छैन, अनुमति दिने पूर्वनिर्धारित छ, र अलगाव केवल यसकारण अस्तित्वमा छ कि कसैले यसको परीक्षण गरेन।

टर्मिनल खोल्नु अघि आवश्यकता एक हरफमा लेख्नुहोस्। सेवा ब्लक र जम्प होस्टसम्म पुग्नुहोस्, क्लाइन्ट ब्लकभित्र अरू कतै नपुग्नुहोस्।

पियर प्याकेट वास्तवमा कसले फर्वार्ड गर्छ पत्ता लगाउनुहोस्

सर्भरका दुई व्यवहार क्लाइन्टतर्फबाट एउटै देखिन्छन् र फरक नियम चाहिन्छन्। कि त कर्नेलले प्याकेट फेरि टनेल इन्टरफेसबाट बाहिर फर्वार्ड गर्छ, वा डेमनले त्यो सत्रहरूबीच प्रतिलिपि गर्छ र कर्नेलले त्यो कहिल्यै देख्दैन।

WireGuard पहिलो समूहमा पर्छ: यसमा पियर-देखि-पियर स्विच छैन, त्यसैले 10.8.0.4 बाट 10.8.0.5 सम्मको प्याकेट wg0 मा आउँछ, फर्वार्ड हुकमा ठोकिन्छ र AllowedIPs ले दुवै ठेगाना ढाक्दा फेरि wg0 बाट मार्गिन्छ। OpenVPN दोस्रो समूह हो, सर्भर कन्फिगमा client-to-client सेट भएपछि, किनकि त्यो निर्देशनले प्याकेट प्रयोगकर्ता स्पेसमा सत्रहरूबीच सुम्पन्छ। केही लेख्नु अघि लोड भएको कन्फिगमा त्यो निर्देशन जाँच्नुहोस्। ट्राफिक कहिल्यै नदेख्ने कर्नेल नियमलाई काम गर्ने नियमबाट छुट्याउन सकिँदैन, र यसरी नै एउटा परिनियोजन कुनै अलगावबिना सकिन्छ।

तपाईंले लोड भएको मान्नुभएको फाइलको सट्टा प्रभावकारी कन्फिग पढ्नुहोस्, किनकि डिस्ट्रो प्याकेजहरूले आफ्नै समावेशहरू ल्याउँछन्। डेमनले फर्वार्ड गर्छ भने, निषेध उसको आफ्नै प्रति-क्लाइन्ट नियन्त्रणमा हुन्छ, र होस्ट फायरवालले होस्टतर्फ पठाइएको ट्राफिक मात्र छान्छ। कर्नेलले फर्वार्ड गर्छ भने, फर्वार्ड हुक नै एकमात्र महत्त्वपूर्ण ठाउँ हो।

मार्गित र अनुवादित परिनियोजनलाई अर्को एक जाँच चाहिन्छ: टाढाको क्लाइन्टले देख्ने स्रोत तपाईंले अपेक्षा गरेको नहुन सक्छ। त्यसपछि क्लाइन्ट सबनेटसँग मिल्ने नियम कुनैसँग मिल्दैन। मिलान लेख्नु अघि अनुवादबाट बाँच्ने ठेगाना नोट गर्नुहोस्, र NAT ठेगाना अनुमान गर्नुभन्दा इन्टरफेस जोडी मिलाउन प्राथमिकता दिनुहोस्।

हरेक ठेगानालाई आफै रद्द गर्न सकिने पहिचान दिनुहोस्

दुई उपकरणले एउटै प्रमाणहरू साझा गर्नेबित्तिकै अलगाव भत्किन्छ। त्यो पहिचानसँग बाँधिएको नियमले तिनीहरूलाई छुट्याउन सक्दैन, र हराएको ल्यापटप रद्द गर्दा पूरै समूह रद्द हुन्छ। प्रति-उपकरण प्रमाणपत्र वा प्रति-पियर कुञ्जीहरूले रद्दीकरण स्थानीय र नीति पढ्नयोग्य राख्छन्, किनकि हरेक ठेगाना ठ्याक्कै एक व्यक्ति वा मेसिनसँग मिल्छ। जहाँ डिजाइनले त्यो गर्न सक्दैन, त्यहाँ नियमलाई सूक्ष्म भनी वर्णन गर्नुभन्दा रनबुकमा भन्नुहोस्।

ठेगाना बाँडफाँट नीतिसँग मिल्नुपर्छ। सेवाहरूका लागि एउटा ब्लक, क्लाइन्टहरूका लागि एउटा ब्लक आरक्षित गर्नुहोस्, र क्लाइन्ट ठेगानाहरू तपाईंले नियन्त्रण गर्ने पूलबाट दिनुहोस्, पहिलो आउनेले पाउने दायराबाट होइन। सर्भरले अनुवाद वा ब्रिज गर्छ भने, म्यापिङ तालिका कन्फिगको छेउमा राख्नुहोस्, किनकि अर्को पाठकलाई नियम फेरि निकाल्न त्यही तालिका चाहिन्छ।

निषेध त्यहाँ राख्नुहोस् जहाँ प्याकेट टनेल पार गर्छ

WireGuard ट्राफिक फर्वार्ड गर्ने गेटवेमा दुई नियमले यो अवस्था ढाक्छन्: सेवा ब्लकलाई अनुमति दिनुहोस्, त्यसपछि क्लाइन्ट ब्लकको बाँकी खसाल्नुहोस्। इन्टरफेस जोडी ठेगानाजत्तिकै महत्त्वपूर्ण छ, किनकि गन्तव्यमा मात्र मिलाउँदा LAN बाट आउने ट्राफिक पनि समातिन्छ। अनुमति पहिले मूल्याङ्कन होस् भनेर तिनीहरूलाई त्यही क्रममा लोड गर्नुहोस्।

nftables सँग जोडी विद्यमान inet filter तालिकामा जान्छ, पहिले अनुमति र त्यसपछि खसाल्ने। दुवै मिलानले ठेगानासँगै इन्टरफेस जोडी पनि पिन गर्छन्।

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

लोड गरेपछि निर्गमन स्थितिमा भरोसा गर्नुभन्दा शृंखला फेरि पढ्नुहोस्, र दुवै नियम तपाईंले चाहेको क्रममा छन् भनी पुष्टि गर्नुहोस्। IPv6 पूलका लागि मिल्ने ip6 नियम थप्नुहोस्, नत्र दोहोरो स्ट्याक टनेलमा v4 जोडी केवल सजावट हो। सर्भरसँग पहिले नै अनुमति दिने फर्वार्ड नीति छ भने, शृंखला पूरै बदल्नुभन्दा खसाल्ने थप्नुहोस्।

OpenVPN मा client-to-client सक्षम हुँदा, यी फर्वार्ड नियम पियर ट्राफिकसँग कहिल्यै मिल्दैनन् र निषेध डेमनकै आफ्नै नियन्त्रणमा बस्नुपर्छ। होस्टतर्फ पठाइएको ट्राफिकका लागि कर्नेल नियम राख्नुहोस्, तर तिनलाई अलगाव नियन्त्रणका रूपमा नगन्नुहोस्।

निषेध सर्भरबाट होइन, क्लाइन्टबाट प्रमाणित गर्नुहोस्

गेटवेबाट परीक्षणले केही प्रमाणित गर्दैन, किनकि स्थानीय रूपमा उत्पन्न ट्राफिक निर्गमन मार्ग लिन्छ र फर्वार्ड हुक कहिल्यै पार गर्दैन। दुई वास्तविक क्लाइन्ट प्रयोग गर्नुहोस्: एउटा जसले सेवासम्म पुग्नुपर्छ, एउटा जसलाई अस्वीकार गर्नुपर्छ। पहिले अनुमतिको अवस्था चलाउनुहोस्, ताकि बिग्रिएको टनेललाई काम गर्ने नीति ठानिँदैन।

अनुमति पाएको क्लाइन्टबाट सेवा आफ्नो पोर्टमा जवाफ दिन्छ भनी पुष्टि गर्नुहोस्। त्यही क्लाइन्टबाट पियरको ठेगाना प्रयास गर्नुहोस् र अस्वीकृतिको सट्टा चुपचाप खसालिएको अपेक्षा गर्नुहोस्:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

खसालिएको प्याकेट र अफलाइन पियर दुवै समय सकिएजस्तो देखिन्छन्, त्यसैले कुनै निष्कर्षमा पुग्नु अघि काउन्टरहरू जाँच्नुहोस्। पियर स्पष्ट रूपमा चालु हुँदा खसाल्ने नियमको काउन्टर बढ्छ भनी पुष्टि गर्नुहोस्। IPv6 मा दोहोर्याउनुहोस्, जहाँ अनुपस्थित ip6 नियमले v4 निषेधलाई प्रभावकारी देखाउँछ। स्वीकृत र अस्वीकृत नतिजा मितिसहित रनबुकमा लेख्नुहोस्, किनकि अर्को स्थानान्तरणले नियम फेरि निकाल्नेछ।