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 अनुरोध तीनवटै टनेल बन्द हुँदा असफल भएपछि, र टनेल माथि आउँदा तीनवटै फेरि चलेपछि मात्र सेटअप स्वीकार गर्नुहोस्।