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 विनंती तिन्ही टनेल बंद असताना अपयशी झाल्यावर, आणि टनेल वर आल्यावर तिन्ही पुन्हा चालल्यावरच सेटअप स्वीकारा.