FORWARD, OUTPUT और IPv6 को कवर करने वाला राउटर किल स्विच
सिर्फ़ FORWARD में किल स्विच राउटर को खुलकर लीक करने देता है, और सिर्फ़ IPv4 नियम IPv6 को खुला छोड़ देते हैं। चेन क्रम में रखें और टनल बंद रहने पर जाँचें।
आप राउटर में लॉग इन करते हैं, किसी फ़ोरम पोस्ट से किल स्विच नियमों का सेट चिपकाते हैं, और जिस पल टनल गिरती है LAN ब्राउज़ करना बंद कर देता है। दो दिन बाद भी राउटर सामान्य WAN से अपना डायनामिक DNS रिकॉर्ड अपडेट करता रहता है, और गेस्ट लैपटॉप अब भी IPv6 साइटों तक पहुँचता है। दोनों व्यवहार सामान्य हैं, क्योंकि चिपकाए गए नियम एक चेन और एक पता परिवार को कवर करते थे, और इनमें से कोई भी पूरा राउटर नहीं है। पैकेटों के रास्तों को क्रम से देखने पर ठीक वही दिखता है जो छूट गया।
राउटर से शुरू करें, लैपटॉप से नहीं
राउटर स्तर की नीति छोटे दफ़्तर के लिए आकर्षक है क्योंकि इसके पीछे का हर डिवाइस वही व्यवहार विरासत में पाता है और कोई भी क्लाइंट पर स्विच चालू करना नहीं भूल सकता। यह हर फ़र्मवेयर अपडेट के बाद जाँचने के लिए एक ही जगह भी देती है। जो यह नहीं देती वह राउटर के अपने ट्रैफ़िक या दूसरे पता परिवार की स्वचालित कवरेज है, और यही वे दो खाई हैं जिनके पीछे ज़्यादातर नाकाम तैनातियाँ हैं।
कुछ भी बदलने से पहले कागज़ पर तीन तथ्य लिखें: WAN इंटरफ़ेस का नाम, LAN ब्रिज का नाम, और VPN एंडपॉइंट का पता और पोर्ट। तीनों नियमों में चाहिए होंगे, और इंटरफ़ेस के नाम का अंदाज़ा लगाना सबसे आम वजह है कि सही दिखने वाला नियम-सेट कुछ नहीं करता।
उन तीन रास्तों से गुज़रें जो एक पैकेट ले सकता है
लैपटॉप से इंटरनेट की ओर ट्रैफ़िक फ़ॉरवर्ड होता है, इसलिए वह FORWARD चेन से गुज़रता है। जो ट्रैफ़िक राउटर खुद बनाता है, जैसे DNS फ़ॉरवर्डिंग, NTP क्वेरी, DDNS अपडेट और VPN का कंट्रोल चैनल, वह OUTPUT से गुज़रता है। राउटर को संबोधित प्रबंधन ट्रैफ़िक INPUT से आता है।
इसलिए सिर्फ़ FORWARD में बना किल स्विच क्लाइंटों की रक्षा करता है और किसी और चीज़ की नहीं। तालिका दिखाती है कि शुरुआती दृश्य का लीक क्यों रहस्य नहीं, पहले से अनुमानित है।
| Packet path | Example | Chain that sees it |
|---|---|---|
| LAN client to WAN or tunnel | Browser request | FORWARD |
| Router-originated | DDNS update, NTP | OUTPUT |
| Addressed to the router | SSH from the LAN | INPUT |
ज़्यादातर डिज़ाइनों में आपको INPUT पर किल स्विच की ज़रूरत नहीं, लेकिन टनल बंद रहने के दौरान प्रबंधन पहुँच काम करती रहनी चाहिए। वरना VPN की पहली नाकामी पर आप कंसोल केबल लेकर दफ़्तर जाएँगे।
नियमों को इस तरह रखें कि टनल फिर भी ऊपर आ सके
काम करने वाला किल स्विच इजाज़तों की वह सूची है जो इनकार पर ख़त्म होती है, और क्रम ही उसे किल स्विच बनाता है, ईंट नहीं। पहले loopback, VPN एंडपॉइंट, स्थापित फ़्लो के जवाब और टनल इंटरफ़ेस की अनुमति दें; बाक़ी को आख़िर में अस्वीकार करें।
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECTइस मोड़ पर एंडपॉइंट एक पता होना चाहिए, होस्ट नाम नहीं। जैसे ही अंतिम इनकार DNS को ब्लॉक करता है, प्रदाता के होस्ट नाम वाला नियम फिर हल नहीं हो सकता, और टनल दोबारा शुरू होने के बाद कभी ऊपर नहीं आती. अगर प्रदाता एंडपॉइंट बदलता है, तो नीति लागू होने से पहले नाम हल करें और उस नियम को उसी स्क्रिप्ट से ताज़ा करें।
क्लाइंट ट्रैफ़िक के लिए वही आकार FORWARD में दोहराएँ, और इनकार के ऊपर एक स्पष्ट प्रबंधन नियम रखें। उस प्रबंधन नियम को सँकरा पर पहुँचने योग्य रखें, और पहला SSH सत्र बंद करने से पहले दूसरा सत्र खोलकर उसे पुष्ट करें। किल स्विच बदलते समय खुद को बाहर ताला लगाना इतना आम है कि इसकी योजना बनाई जाए। WireGuard चलाने वाले राउटर पर पीयर के allowed-ips तय करते हैं कि टनल में क्या जाता है, जबकि ये नियम तय करते हैं कि उसके बिना क्या बाहर जा सकता है।
IPv6 को अपना दरवाज़ा चाहिए
ऊपर का सब कुछ IPv4 है। अगर आपके LAN में IPv6 काम कर रहा है और टनल सिर्फ़ IPv4 ले जाती है, तो हर कवर डिवाइस के पास इंटरनेट का सीधा रास्ता अब भी है जो आपके नए नियम कभी नहीं देखते। दोहरे स्टैक वाला लैपटॉप उसे ख़ुशी से चुनेगा, और किल स्विच सिर्फ़ उसी को टूटा दिखेगा जो IPv4 से जाँच रहा हो।
ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPTयहाँ भी क्रम मायने रखता है: loopback की अनुमति WAN के इनकार से पहले आनी चाहिए, वरना राउटर पर स्थानीय सेवाएँ अजीब तरीक़ों से नाकाम होने लगती हैं। अगर नेटवर्क IPv6 बिल्कुल नहीं इस्तेमाल करता, तो उसे WAN और LAN पर बंद करना आसान है और भूलने के लिए कुछ नहीं बचता।
कुछ VPN क्लाइंट सिर्फ़ IPv4 के लिए डिफ़ॉल्ट रूट लगाते हैं और मौजूदा IPv6 डिफ़ॉल्ट रूट को अछूता छोड़ देते हैं। टनल जुड़ने के बाद रूटिंग तालिका जाँचें, बजाय यह मान लेने के कि क्लाइंट ने संभाल लिया।
टनल बंद रहने पर इसे साबित करें
टनल को राउटर से रोकें और तीन जगहों से इस क्रम में जाँचें:
# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | headरूट खोज बताती है कि पैकेट कहाँ जाएगा, और काउंटर बताते हैं कि आपके नियम कभी मिले या नहीं। नाकाम जाँच के बाद शून्य पैकेट वाला नियम कुछ नहीं बचाता, और आम वजह इंटरफ़ेस का वह नाम है जो आपके लिखे से अलग है। राउटर के बनाए ट्रैफ़िक को स्पष्ट रूप से जाँचें, क्योंकि LAN की ओर से जाँच OUTPUT नहीं चला सकती।
नाकामी का तरीक़ा ज़रूरत से पहले तय करें। fail-closed क्लाइंटों को तब तक ऑफ़लाइन रखता है जब तक टनल लौट न आए; fail-open सामान्य WAN पहुँच बहाल करता है और उस ट्रैफ़िक का मक़सद ख़त्म कर देता है जिसकी आपको परवाह थी। ऊँचे मीट्रिक वाला VPN पूल की ओर blackhole रूट fail-closed डिज़ाइनों के लिए उपयोगी दूसरी परत है, क्योंकि टनल रूट गायब होने पर यह डिफ़ॉल्ट पर गिरने के बजाय बचा रहता है।
सेटअप तभी स्वीकारें जब LAN क्लाइंट, राउटर से बना अनुरोध और IPv6 अनुरोध तीनों टनल बंद रहने पर नाकाम हों, और टनल ऊपर आने पर तीनों फिर काम करें।