लिनक्स डिस्ट्रीब्यूशन का फ़ायरवॉल आपका VPN ट्रैफ़िक रोक सकता है

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

प्रबंधक और बैकएंड खोजें

जो वास्तव में लोड है उससे शुरू करें, जो इंस्टॉल है उससे नहीं। कोई डिस्ट्रीब्यूशन firewalld, ufw और एक साधारण nftables सेवा के साथ आ सकता है, और इनमें से केवल एक चल रहे नियम-समूह का मालिक है। पैकेज शांति से साथ रहते हैं, और गलत फ़्रंटएंड से दर्ज नियम कभी कर्नेल तक नहीं पहुँचता। सक्रिय सेवा पढ़ें, फिर उसके द्वारा बनाया गया नियम-समूह पढ़ें।

बैकएंड उतना ही महत्वपूर्ण है जितना फ़्रंटएंड। firewalld का इंस्टॉलेशन संस्करण और कॉन्फ़िगरेशन के अनुसार nftables या पुराने iptables बैकएंड को चला सकता है, और दोनों अलग निरीक्षण आउटपुट देते हैं। अपने सिस्टम की किसी भी गाइड से तुलना करने से पहले डिस्ट्रीब्यूशन, संस्करण और बैकएंड टिकट में लिखें।

दिशा और इंटरफ़ेस का मेल कराएँ

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

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

नियमों के मालिकों को एकमत रखें

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

संकीर्ण काउंटर अस्वीकृत प्रवाह खोजने का सस्ता तरीका हैं। एक गंतव्य और एक पोर्ट तक सीमित लॉगिंग नियम दिखाता है कि ड्रॉप स्थानीय रूप से होता है या नहीं, किसी और का ट्रैफ़िक पकड़े बिना। जाँच पूरी होने पर लॉगिंग नियम हटा दें, क्योंकि यह निदान है नीति नहीं, और firewalld का ज़ोन दस्तावेज़ बताता है कि इंटरफ़ेस और सेवाएँ कैसे मिलते हैं।

लॉकडाउन खोए बिना सुधार जाँचें

लागू स्थिति का निरीक्षण उस प्रबंधक से करें जो उसका मालिक है, उन कमांडों का उपयोग करते हुए जो आपके दर्ज किए बैकएंड से मेल खाते हैं। नीचे दी सूची मानती है कि firewalld ज़िम्मेदार है; सभी चलाने के बजाय nftables या ufw के समतुल्य से बदलें। एक सत्र में उपकरणों को मिलाना ही वह तरीका है जिससे मशीन दो परस्पर विरोधी नियम-समूहों के साथ रह जाती है।

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

पहला कमांड ज़ोनों और उन्हें सौंपे गए इंटरफ़ेसों के नाम बताता है, जो दिखाता है कि टनल वास्तव में कहाँ पहुँची। दूसरा किसी ज़ोन के नियम और सेवाएँ छापता है, ताकि आप देख सकें कि VPN इंटरफ़ेस बिल्कुल कवर है या नहीं। nftables सूची प्रयुक्त बैकएंड के लिए मूल सत्य है, और केवल कॉन्फ़िगरेशन फ़ाइल में मौजूद नियम वहाँ नहीं दिखता। तीनों आउटपुट की तुलना आपके जोड़े नियम से करें, और असंगति सामान्यतः स्वयं अपना नाम बता देती है।

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