डाउन स्क्रिप्ट या फ़ायरवॉल नियम: लीक कौन रोकता है?
डिस्कनेक्ट पर इंटरफ़ेस नीचे करना कठोर है और अक्सर बिना विशेषाधिकार के चलता है। इसकी तुलना ऐसे फ़ायरवॉल नियम से करें जो गिरावट के बाद भी टिका रहता है और अंतराल बंद करता है।
दो डिज़ाइन एक ही बात का वादा करते हैं: जब टनल गिरती है, कुछ भी खुले रूप में बाहर नहीं जाता. एक टियरडाउन पर स्क्रिप्ट चलाकर इंटरफ़ेस काट देता है। दूसरा फ़ायरवॉल नियम को लागू रखता है और 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 को कोई सत्यापित नहीं कर सकता वह अफ़वाह है।