UFW का किल स्विच आपके VPN को रोक रहा है? पीयर को अनुमति दें

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

tun0 पर अनुमति शुरू में किसी चीज़ से क्यों मेल नहीं खाती

सत्र होने के बाद क्लाइंट tun0 बनाता है। उस सत्र को बनाने वाले डेटाग्राम सामान्य UDP पैकेट हैं जो पोर्ट 1194 पर प्रदाता को संबोधित होते हैं, और वे भौतिक स्रोत पते के साथ wlan0 या eth0 से बाहर जाते हैं। allow out on tun0 केवल उस ट्रैफ़िक से मेल खाता है जिसका आउटगोइंग इंटरफ़ेस tun0 है, इसलिए हैंडशेक के दौरान यह किसी चीज़ से मेल नहीं खाता।

उसके ऊपर default deny outgoing रखें और बाहरी पैकेट इंटरफ़ेस दिखने से पहले ही गिरा दिए जाते हैं। क्लाइंट फिर कोशिश करता है, समय समाप्त होता है और TLS या हैंडशेक विफलता की सूचना देता है, जिससे लोग प्रमाणपत्रों और MTU में खोजबीन करने लगते हैं जबकि फ़ायरवॉल चुपचाप कनेक्शन खा जाता है। आपके ट्रैफ़िक को रोकने के लिए बनाया गया नियम उसी ट्रैफ़िक को रुकने से रोक रहा है।

तत्काल सुधार लीक को स्थायी बना देता है। sudo ufw allow out on wlan0, या डिफ़ॉल्ट को वापस अनुमति पर लौटाना, टनल को ऊपर लाता है और मशीन को किल स्विच के बिना छोड़ देता है: अगली बार जब टनल गिरेगा, सब कुछ भौतिक एडाप्टर पर फिर शुरू हो जाएगा। मैंने ठीक उसी जोड़ी बदलावों पर एक दोपहर खोई, इससे पहले कि मैं समझ पाता कि मैं वास्तव में कौन सा पैकेट फ़िल्टर कर रहा हूँ।

दोनों पैकेट समूहों को क्या चाहिए

आपका ट्रैफ़िक फ़ायरवॉल को दो बार, दो आकारों में पार करता है। भीतरी पैकेट टनल पते से tun0 के ज़रिए बाहर जाता है। बाहरी पैकेट भौतिक पते से पीयर तक जाता है, और तार पर दिखने वाली यही एकमात्र चीज़ है। हर आकार के लिए एक नियम:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

पता और पोर्ट अपनी प्रोफ़ाइल वाले से बदलें। WireGuard पीयर आमतौर पर 51820/udp पर जवाब देते हैं; TCP 443 से चलने वाली OpenVPN प्रोफ़ाइलों को इसके बजाय वही पोर्ट चाहिए। ब्यौरे अलग हैं, आकार नहीं: दोनों नियम संकीर्ण हैं, और साथ मिलकर वे वही गंतव्य तय करते हैं जहाँ टनल बंद होने पर मशीन पहुँच सकती है।

क्रम दूसरा मिथक है। कच्चे iptables के साथ आप शृंखला को ऊपर से नीचे पढ़ते हैं और सोचते हैं कि कौन सा नियम जीतता है। ufw आपकी टाइप की गई सूची के चारों ओर पतला आवरण नहीं है; यह आपके नियमों को अपनी शृंखलाओं में संकलित करता है और डालने के बिंदु चुनता है। ufw status उन्हें ufw के क्रम में छापता है, आपके क्रम में नहीं। जब कोई नियम अनदेखा लगे, तो तुलना करें ufw show added को संकलित समूह से iptables -S | grep ufw कुछ भी फिर से लिखने से पहले।

अपवाद एक पते की चौड़ाई का ही रहना चाहिए

पीयर नियम केवल तब तक सही है जब तक वह उस पते का नाम लेता है जिसे क्लाइंट डायल करता है। प्रदाता एंडपॉइंट घुमाते हैं, और होस्टनाम हल करने वाली प्रोफ़ाइल DNS बदलाव का अनुसरण करके नए पते पर चली जाएगी जबकि नियम पुराने की ओर संकेत करता रहेगा। जब महीनों से चल रही टनल ऊपर आना बंद कर दे, तो कुछ भी चौड़ा करने से पहले नियम के पते की तुलना उस पते से करें जिसे क्लाइंट खोज रहा है।

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

नाम हल करना अपनी अलग पंक्ति का हक़दार है। खोज टनल के अस्तित्व में आने से पहले, भौतिक इंटरफ़ेस पर होती है, इसलिए सख़्त आउटगोइंग-अस्वीकार नीति क्लाइंट को अपना सर्वर खोजने में अक्षम छोड़ सकती है। अपने रिज़ॉल्वर के पते पर पोर्ट 53 की अनुमति दें, या एक बार हल करें और पता प्रोफ़ाइल में पिन करें। हर इंटरफ़ेस पर DNS की अनुमति एक निर्णय है, डिफ़ॉल्ट नहीं।

टनल की ज़रूरत पड़ने से पहले नीति बनाएँ

ufw enable पूरी नीति एक साथ लागू करता है और अपनी शृंखलाएँ फिर से लोड करता है, और चल रहे फ़ायरवॉल पर डिफ़ॉल्ट नीति बदलने से वे भी फिर से लोड होती हैं। ufw मैनुअल चेतावनी देता है कि इससे SSH जैसे मौजूदा कनेक्शन गिर सकते हैं। इसलिए आदेश इस क्रम में जाते हैं, SSH नियम सक्रिय करने से पहले और कंसोल सत्र खुला रखते हुए:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset जानबूझकर उस ब्लॉक से बाहर रखा गया है। यह हर नियम मिटा देता है और फ़ायरवॉल बंद कर देता है, और दूरस्थ होस्ट पर इसके बाद का सक्रियण ही आपका सत्र गिराता है। अगर आप फिर भी रीसेट करें, तो SSH नियम जोड़ें और आगे बढ़ने से पहले कंसोल के ज़रिए लौटने का दूसरा रास्ता पक्का करें।

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

अवरुद्ध स्थिति जाँचें, और पूर्ववत करने की सुविधा रखें

बिना जाँचा किल स्विच एक अनुमान है. क्लाइंट को जानबूझकर डिस्कनेक्ट करें और पेज लोड करने की कोशिश करें: यह विफल होना चाहिए। फिर कनेक्ट करें और यह किसी नियम को छुए बिना ठीक हो जाना चाहिए। sudo ufw status verbose डिफ़ॉल्ट और लॉगिंग स्थिति की पुष्टि करता है, और ufw status numbered दिखाता है कि परीक्षण नियम अपने उद्देश्य से अधिक जीने पर कौन सा हटाना है।

उल्टी स्क्रिप्ट को आगे वाली के बगल में रखें। आउटगोइंग-अस्वीकार और मृत टनल वाली मशीन अपनी मरम्मत खुद डाउनलोड नहीं कर सकती, इसलिए पूर्ववत करना डिस्क पर होना चाहिए और कंसोल से पढ़ा जा सकना चाहिए:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

इसे तब चलाएँ जब टनल पहले ही नीचे हो और नियम हटाने हों, नियमित कदम के रूप में नहीं। टर्मिनल बंद करने से पहले चार बातें सही होनी चाहिए: पीयर नियम ठीक एक पते का नाम लेता है, DNS का एक नामित अपवाद है, सक्रियण अनुमतियों के बाद आया है, और टनल खींचने से सामान्य ट्रैफ़िक मरता है पर क्लाइंट हमेशा के लिए नहीं मरता।