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 निषेध को प्रभावी दिखने देता है। स्वीकृत और अस्वीकृत परिणाम तारीख के साथ रनबुक में दर्ज करें, क्योंकि अगला स्थानांतरण नियम को फिर से निकालेगा।