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

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

किन tun0 मा दिइएको अनुमति सुरुमा कसैसँग मेल खाँदैन

सत्र अस्तित्वमा आएपछि क्लाइन्टले tun0 सिर्जना गर्छ। त्यो सत्र निर्माण गर्ने डेटाग्रामहरू पोर्ट 1194 मा प्रदायकलाई पठाइएका साधारण UDP प्याकेट हुन्, र तिनीहरू भौतिक स्रोत ठेगानासहित 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 सँग नाम दिइएको अपवाद छ, सक्रियकरण अनुमतिपछि आयो, र टनेल तान्दा सामान्य ट्राफिक मर्छ तर क्लाइन्ट सधैंका लागि मर्दैन।