आपके OpenVPN सर्वर पर एक क्लाइंट को LAN पहुँच खोनी है जबकि बाकी सभी टनल चालू रहें। इसे खोजें तो सबसे अच्छा उत्तर आमतौर पर कहता है कि डेमन यह नहीं कर सकता, जो आधा ही सच है: OpenVPN में प्रति-क्लाइंट फ़ायरवॉल नहीं है, लेकिन जो होस्ट टनल समाप्त करता है वह पहले से पैकेट फ़िल्टर करता है। असली दो निर्णय हैं आप किस पहचान को ब्लॉक करते हैं और नियम की स्थिति। ये दोनों सही करें तो बदलाव एक पंक्ति बन जाता है जिसे आप जाँच और हटा सकते हैं।

नियम लिखने से पहले क्लाइंट को पिन करें

OpenVPN पूल से टनल पते पट्टे पर देता है, इसलिए 10.8.0.6 व्यक्ति नहीं, सीट है। सत्र खत्म होने पर पट्टा लौटता है और अगले कनेक्शन को दिया जा सकता है, यानी उस पते के विरुद्ध लिखा नियम सीट का पीछा करता है, उपयोगकर्ता का नहीं। इसलिए पहले तय करें कि आप वास्तव में क्या ब्लॉक कर रहे हैं: छोटे प्रयोग के लिए पता, या किसी को बाहर रखने के लिए प्रमाणपत्र।

पते को प्रमाणपत्र से बाँधने के लिए, client-config-dir द्वारा नामित निर्देशिका में एक फ़ाइल बनाएँ और फ़ाइल को प्रमाणपत्र का common name ठीक वैसा ही दें। उसमें एक निर्देश रखें, ifconfig-push 10.8.0.6 255.255.255.0, और वह क्लाइंट फिर से जुड़ने पर भी वही टनल पता रखता है। यह प्रभावी होने के लिए दो सेटिंग होनी चाहिए: सर्वर कॉन्फ़िगरेशन में client-config-dir घोषित होना चाहिए, और भेजा गया पता ऐसे सबनेट में होना चाहिए जिसे सर्वर रूट कर सके। एक भी छूटे तो फ़ाइल बिना त्रुटि अनदेखी हो जाती है, जिससे अगली फ़ायरवॉल जाँच भ्रामक हो जाती है।

अस्थायी ब्लॉक पूल का पता इस्तेमाल कर सकता है, बशर्ते टिकट में दर्ज हो कि उस समय किस सत्र के पास वह था।

क्रम तय करता है कि ड्रॉप चलेगा या नहीं

जो Linux गेटवे टनल और LAN के बीच अग्रेषित करता है, वहाँ पैकेट FORWARD श्रृंखला पार करते हैं। नीचे के आदेश को वाक्य की तरह पढ़ें: FORWARD के शीर्ष पर डालें, tun0 से आने वाला, केवल उसी एक होस्ट का, LAN सबनेट की ओर लक्षित ट्रैफ़िक मिलाएँ और गिरा दें।

iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP

-I ही नियम को चलाता है। -A से जोड़ने पर यह टनल सबनेट के किसी भी व्यापक स्वीकार के नीचे पहुँच जाता है और कभी पैकेट नहीं देखता। iptables -vnL FORWARD --line-numbers से स्थिति जाँचें और काउंटर भी पढ़ें: ऊपर का ड्रॉप अगर कुछ नहीं गिनता तो इसका मतलब है कि ट्रैफ़िक किसी और रास्ते से आ रहा है।

गेटवे का अपना LAN पता अलग रास्ता है। बॉक्स पर ही भेजे गए पैकेट INPUT में जाते हैं, FORWARD में नहीं, इसलिए क्लाइंट LAN होस्ट खोकर भी राउटर का एडमिन पेज खोल सकता है। जब यह मायने रखे तो मिलता-जुलता INPUT नियम जोड़ें।

फ़िल्टर क्या नहीं देख सकता

फ़िल्टरिंग पैकेट के मूल्यांकन पर होती है, इसलिए स्थापित TCP सत्र बंद या रीसेट होने तक चल सकता है। अगर ब्लॉक को तुरंत असर करना है तो नियम डालने के बाद उस स्रोत के ट्रैक किए गए फ़्लो conntrack -D -s 10.8.0.6 से साफ़ करें। अगर कुछ सेकंड का ओवरलैप स्वीकार्य है तो उस चयन को दर्ज करें, उसे अंतर्निहित छोड़ने के बजाय। किसी भी तरह, अगले व्यक्ति को पता होना चाहिए कि नियम जीवित ट्रैफ़िक रोकता है या केवल नए कनेक्शन।

पीयर ट्रैफ़िक कभी होस्ट फ़ायरवॉल को नहीं छूता। client-to-client सक्षम होने पर OpenVPN वे पैकेट डेमन के भीतर अग्रेषित करता है, इसलिए FORWARD या INPUT उन्हें नहीं देखते। एकमात्र उपाय client-to-client बंद करना या यह स्वीकारना है कि पीयर एक-दूसरे तक पहुँच सकते हैं; iptables नियम वह ट्रैफ़िक नहीं देखेगा।

IPv6, फ़र्मवेयर और रीबूट के बाद बने रहना

IPv4 नियम IPv6 के बारे में कुछ नहीं कहता। अगर टनल और LAN दोनों परिवार ढोते हैं, तो समतुल्य नियम ip6tables में होना चाहिए, या उस होस्ट पर नीति रखने वाले nftables नियम-समूह में। राउटर फ़र्मवेयर अक्सर netfilter को अपने अमूर्तन के पीछे छिपाता है, इसलिए फ़ोरम से कॉपी किया गया सिंटैक्स और तालिका नाम लागू नहीं हो सकते।

OpenWrt पर दस्तावेज़ी रास्ता फ़ायरवॉल कॉन्फ़िगरेशन प्रविष्टि है, हाथ से लिखी iptables पंक्ति नहीं, और हाथ से लिखी पंक्ति फ़ायरवॉल फिर से लोड होने पर गायब हो सकती है। अन्य वितरण नियम netfilter-persistent, बूट इकाई या विक्रेता भंडार के माध्यम से बहाल करते हैं, और वे तंत्र विनिमेय नहीं हैं। आपने जो चुना उसे रीबूट से सिद्ध करें, क्योंकि फिर से लोड होना अलग रास्ता अपनाता है।

रास्ते के अनुसार जाँचें, फिर साफ़ तरीके से वापस लौटाएँ

हर रास्ते को अलग जाँचें, क्योंकि एक सफल जाँच बाकी छिपा देती है। ब्लॉक किए गए क्लाइंट को टनल से इंटरनेट तक पहुँचना चाहिए पर LAN होस्ट पर विफल होना चाहिए, दूसरे क्लाइंट को उसी होस्ट तक पहुँचना चाहिए, और गेटवे पता तथा पीयर रास्ते को अलग-अलग अवलोकन चाहिए। परिणाम नियम के पास लिखें ताकि अगले बदलाव को आधार मिले। नीचे की तालिका वह समूह है जिसे टिकट में रखना उचित है।

रास्तानियम के साथ अपेक्षितजब विफल हो
ब्लॉक किया गया क्लाइंट LAN होस्ट की ओरकोई उत्तर नहींनियम स्वीकार के नीचे है, या स्रोत मेल नहीं खाता
ब्लॉक किया गया क्लाइंट इंटरनेट की ओरtun0 से काम करता हैनियम बहुत व्यापक है, गंतव्य मेल के बिना
दूसरा क्लाइंट उसी LAN होस्ट की ओरकाम करता हैनियम ने इच्छित होस्ट से अधिक मिलान किया
ब्लॉक किया गया क्लाइंट गेटवे के LAN पते की ओरकेवल मिलते-जुलते INPUT नियम के साथ ब्लॉकINPUT नियम अनुपस्थित
ब्लॉक किया गया क्लाइंट पीयर टनल पते की ओरफिर भी काम करता हैclient-to-client सक्षम है और फ़ायरवॉल के दायरे से बाहर

वापस लौटाना विनिर्देश के अनुसार हटाना है, फ़्लश नहीं: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP ठीक उसी प्रविष्टि को हटाता है और श्रृंखला का बाकी हिस्सा अक्षुण्ण रखता है। जो भी फ़ाइल बूट पर नियम बहाल करती है उससे वही पंक्ति हटाएँ, उसे फिर से लोड करें, और पुष्टि करें कि क्लाइंट फिर LAN होस्ट तक पहुँचता है। FORWARD को फ़्लश करना आपके न लिखे नियम भी रद्द कर देगा, जिससे वापसी दूसरी घटना बन जाती है।

टिकट बंद करने से पहले तीन बातें पुष्टि करें: पिन किया गया पता प्रमाणपत्र से मेल खाता है, नियम स्वीकारों के ऊपर है और काउंटर शून्य नहीं है, और स्थायित्व फ़ाइल में वही नियम है जिसे आपने जाँचा। इनमें से कोई न हो तो ब्लॉक शेल सत्र का भ्रम है।

संबंधित लेख