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 कडे नामांकित अपवाद आहे, सक्रियकरण परवानग्यांनंतर आले, आणि टनेल ओढल्यास सामान्य रहदारी मरते पण क्लायंट कायमचा मरत नाही.