डाउन स्क्रिप्ट वा फायरवाल नियम: चुहावट कसले रोक्छ?
डिस्कनेक्टमा इन्टरफेस तल झार्नु कठोर हुन्छ र प्रायः विशेषाधिकार बिना चल्छ। यसलाई पतनपछि पनि टिक्ने र खाली ठाउँ बन्द गर्ने फायरवाल नियमसँग तुलना गर्नुहोस्।
दुई डिजाइनले एउटै कुरा वाचा गर्छन्: सुरुङ खस्दा, केही पनि खुला रूपमा बाहिर जाँदैन. एउटाले टियरडाउनमा स्क्रिप्ट चलाएर इन्टरफेस काट्छ। अर्कोले फायरवाल नियम लागू राख्छ र VPN क्लाइन्टसँग केही माग्दैन। ती कसलाई कार्य गर्ने विशेषाधिकार छ, खाली ठाउँको समयमा के हुन्छ र पछि मेसिन फेरि कसरी अनलाइन आउँछ भन्नेमा फरक पर्छन्। यी तीन बिन्दुमा तिनको तुलना गर्नु कुन कडा छ भन्ने बहस गर्नुभन्दा उपयोगी हुन्छ।
एउटै काम, दुई विधि
प्रोफाइलले स्क्रिप्ट चलाउन अनुमति दिएमा क्लाइन्टले सुरुङ उठ्दा र टियरडाउन हुँदा हुक चलाउन सक्छ। त्यो हुक क्लाइन्टको जीवनचक्रभित्र, जडान बन्द हुने ठ्याक्कै त्यही क्षणमा चल्छ। फायरवाल नियम भने प्रणालीको स्वामित्वमा हुन्छ र क्लाइन्ट चलिरहेको छ, दुर्घटना भयो वा मारियो भन्ने कुराले त्यसलाई फरक पर्दैन।
| Property | Teardown script | Firewall unit |
|---|---|---|
| Runs when the client is killed | No | Yes |
| Needs privilege at teardown time | Usually yes | Configured once, at boot |
| Acts on the whole machine | Often, including recovery paths | Only on the flows it matches |
त्यही तालिका सम्पूर्ण तर्क हो। केवल सफा बन्दमा चल्ने स्क्रिप्टले तपाईंलाई सबैभन्दा कम चिन्ता लागेको अवस्था ढाक्छ; महत्त्वपूर्ण अवस्था क्र्यास वा सञ्जाल हराउनु हो, र दुवैले सफा टियरडाउन दिँदैनन्।
टियरडाउन हुकले के गर्न सक्छ र के गर्न सक्दैन
अभिलेखित ढाँचा सञ्जाल इन्टरफेसहरू हुँदै जान्छ र loopback बाहेक सबै तल झार्छ। भौतिक उपकरण तल भएको बेला सुरुङबाहिर केही पनि भाग्न सक्दैन, र त्यो नै ठ्याक्कै उद्देश्य हो।
#!/bin/sh
for dev in /sys/class/net/*; do
name=$(basename "$dev")
[ "$name" = lo ] || ip link set dev "$name" down
doneयसले स्थानीय सञ्जाल, मेसिनले होस्ट गर्ने हरेक सेवा र समस्या सुधार्न तपाईंले प्रयोग गर्ने बाटो पनि तल झार्छ। ल्यापटपमा ताररहित उपकरणलाई पछि कहिलेकाहीँ हातैले टगल गर्नुपर्ने हुन्छ, त्यसैले छोटो अवरोध मर्मत सत्र बन्छ। अझ नराम्रो, हुकलाई यीमध्ये केही पनि गर्न अनुमति नहुन सक्छ: क्लाइन्टले विशेषाधिकार छोड्दा टियरडाउन स्क्रिप्ट विशेषाधिकार नभएको खातामा चल्छ, र हरेक इन्टरफेस परिवर्तन अनुमति त्रुटिले असफल हुन्छ जुन कसैले लग पढ्दै नगरेको ठ्याक्कै त्यही क्षणमा लेखिन्छ।
हुकमा विश्वास गर्नुअघि क्लाइन्ट कसरी सुरु हुन्छ हेर्नुहोस्। root को रूपमा हातैले चलाउँदा काम गर्ने स्क्रिप्टले बुटमा सुरु हुने सेवाबारे केही पनि प्रमाणित गर्दैन।
फायरवाल नियमले के फरक गर्छ
केवल सुरुङको ट्राफिकलाई अनुमति दिने नियम क्लाइन्ट प्रक्रिया गए पनि काम गरिरहन्छ, किनकि कर्नेल त्यो प्रक्रियामा निर्भर हुँदैन। नियम अझ साँघुरो पनि छ: मिल्ने प्रवाहहरूलाई मात्र रोक्छ र loopback, स्थानीय सबनेट र पुनःप्राप्ति मार्गलाई एक्लै छोड्छ, त्यसैले मेसिनलाई अलपत्र पार्दैन।
मूल्य यो हो कि नियम होस्ट फायरवालको मालिकले लेख्नुपर्छ र जोगाउनुपर्छ, र त्यसले क्लाइन्टले वास्तवमै बनाउने सुरुङ उपकरणको नाम दिनुपर्छ. यसको अर्थ नियम र प्रोफाइल सँगै जोगाउनुपर्छ; नाम बदलिएको इन्टरफेसले सबै रोक्ने र केही नबुझाउने फायरवाल छोड्छ।
कुनै पनि विधिले अर्कोलाई अनावश्यक बनाउँदैन। सम्पादनपछि कहिल्यै पुनः लोड नहुने फायरवाल नियम कहिल्यै नचल्ने स्क्रिप्टजत्तिकै काल्पनिक हुन्छ।
खाली ठाउँ छ कि छैन persist-tun ले निर्धारण गर्छ
सुरुङ उपकरणले डिस्कनेक्ट सहन गरेमा त्यसतर्फ जाने मार्गहरू पनि सहन गर्छन्। त्यसपछि ट्राफिक पुनर्निर्देशन नभई फ्याँकिन्छ, त्यसैले पूर्वनिर्धारित मार्ग भौतिक गेटवेतिर फर्कंदैन। कुनै पनि फायरवाल नियम संलग्न हुनुअघि नै चुहावटलाई असम्भाव्य बनाउने यही व्यवहार हो।
यो सेटिङ बिना उपकरण र त्यससँगै मार्गहरू हटाइन्छन्, र पूर्वनिर्धारित मार्ग फेरि भौतिक गेटवेतिर देखाउन सक्छ। त्यसो हुन्छ कि हुँदैन प्लेटफर्म र क्लाइन्टमा निर्भर छ, र ठ्याक्कै त्यसैले अवस्था अनुमान नगरी अवलोकन गर्नुपर्छ। सेटिङलाई kill switch को भाग मान्नुहोस्, कार्यक्षमताको विकल्प होइन।
पुनःजडान मार्ग जीवित राख्नुहोस्, त्यसपछि चार अवस्था जाँच्नुहोस्
कडा अवरोधले क्लाइन्टलाई फेरि जोडिनबाट पनि रोक्न सक्छ, किनकि बाँकी सबै अस्वीकार हुँदा पनि क्लाइन्टलाई भौतिक गेटवे हुँदै सर्भरसम्म मार्ग चाहिन्छ। सुरुङ उठ्नुअघि त्यो एक ठेगानाका लागि होस्ट मार्ग स्थापना गर्नुहोस्, र पहिले नाम समाधान गर्नुहोस्, किनकि तपाईंलाई आवश्यक पर्दासम्म DNS अवरुद्ध भइसकेको हुन सक्छ।
ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0त्यसपछि लेबल होइन, अवस्थाहरू प्रमाणित गर्नुहोस्। चार क्षण जानाजानी भोग्नुहोस्: सुरुङ बिनाको चिसो सुरुवात, स्वस्थ सत्र, कसैले नमागेको अवरोध, र सुधारपछिको सत्र। हरेक क्षणमा पूर्वनिर्धारित मार्ग पढ्नुहोस् र निर्गमन ठेगाना देखिने एउटा अनुरोध गर्नुहोस्। सुरुङ तल हुँदा हार मान्ने अनुप्रयोगले मेल क्लाइन्ट वा अपडेटरबारे केही भन्दैन, त्यसैले अन्तिम जाँच एउटा पृष्ठभूमि अनुप्रयोगसँग दोहोर्याउनुहोस्। नियम, इन्टरफेसका नाम र पुनःप्राप्तिका चरणहरू लेखेर राख्नुहोस्, किनकि कसैले पनि प्रमाणित गर्न नसक्ने kill switch हल्ला मात्र हो।