केवल VPN वाला iptables होस्ट: tun डिवाइस का नाम दें, tun+ नहीं

-o tun+ लिखना एक सटीक निर्देश जैसा लगता है और वास्तव में यह कर्नेल की हर टनल पर लागू होने वाला वाइल्डकार्ड है। दूसरा VPN क्लाइंट, कोई कंटेनर ब्रिज या क्रैश हुए सत्र से बचा कोई इंटरफ़ेस—सब इसे पूरा करते हैं, और तब होस्ट उस ट्रैफ़िक की अनुमति देता है जिसे नीति रोकने के लिए लिखी गई थी। नीचे की प्रक्रिया एक डिवाइस नाम तय करती है, अपवादों को ऐसे क्रम में रखती है कि टनल वास्तव में बन सके, और नियम बुरी तरह पड़ने पर लौटने का रास्ता छोड़ती है। हर चरण अलग से पलटे जाने लायक छोटा है।

चरण 1: अभी जो नियम हैं उन्हें लिख लें

डिफ़ॉल्ट नीति बदलने से पहले मौजूदा स्थिति सहेजें ताकि रोलबैक याद नहीं, आदेश बने। iptables-save > /root/iptables.pre हर तालिका को ऐसी फ़ाइल में लिखता है जिसे आप पुनर्स्थापित कर सकते हैं, और जब आप जो नीति सेट करने वाले हैं वह उसे ढोने वाला कनेक्शन गिरा दे, तब खुले root सत्र वाला दूसरा टर्मिनल सनक नहीं है। अगर आप दूर से काम कर रहे हैं, तो एक flush भी डेड मैन स्विच के रूप में तय करें।

फिर इंटरफ़ेस की सूची बनाएँ, क्योंकि जो नाम आपने मान लिया वह ऐसा नाम है जिसे आपको पढ़ना चाहिए था: ip -br link दिखाता है कि अभी क्या मौजूद है, और टनल तब तक नहीं दिखेगी जब तक वह ऊपर न हो। पढ़ते समय ही डिवाइसों के नाम लिख लें।

चरण 2: टनल को उसका अपना नाम दें

OpenVPN क्लाइंट कॉन्फ़िगरेशन में dev tun_work स्वीकार करता है, और तब Linux tun0 आवंटित करने के बजाय ठीक उसी नाम वाला इंटरफ़ेस बनाता है। जब तक कोई और उस पर दावा न करे, नाम पुनःकनेक्शन के दौरान स्थिर रहता है, और यही डिवाइस का नाम लेने वाले नियम को अर्थपूर्ण बनाता है।

जहाँ नाम नियंत्रित नहीं किया जा सकता, वहाँ टनल पते या पैकेट मार्क से मिलान करें। दोनों काम करते हैं, दोनों पढ़ने में कठिन हैं, और टनल के फिर से क्रमांकित होने पर दोनों अधिक चुपचाप विफल होते हैं। किसी भी तरह, एक ही चीज़ से मिलान करें और स्पष्ट कहें कि किससे।

चरण 3: नीति में endpoint अपवाद पहले रखें

केवल VPN वाला होस्ट छोटी अपवाद सूची के साथ डिफ़ॉल्ट-अस्वीकृति होस्ट है, और सबसे महत्वपूर्ण अपवाद वही है जो टनल को अस्तित्व में रहने देता है। इसे इसी क्रम में बनाएँ, टनल-डिवाइस नियम से पहले endpoint नियम रखकर, ताकि हैंडशेक के पास जाने की जगह हो:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

endpoint का शब्दशः पता और पोर्ट आपके प्रदाता के हैं, इस पृष्ठ के नहीं। अगर endpoint कोई होस्टनाम है, तो उसे एक बार हल करें और परिणाम तय करें, क्योंकि नियम किसी नाम को खोज नहीं सकता और घूमता जवाब अगले DNS बदलाव के बाद नीति को चुपचाप तोड़ देगा। पोर्ट भी जाँचें, क्योंकि जो प्रदाता आपको TCP 443 पर ले जाते हैं उन्हें वरना ऐसा नियम चाहिए जो किसी ने लिखा ही नहीं। केवल एक प्रोटोकॉल पर चलने वाली टनल आमतौर पर यही चूक होती है, फ़ायरवॉल की खराबी नहीं।

राउटर पर यही आकार उसके पीछे के क्लाइंट के लिए FORWARD श्रृंखला में जाता है, और राउटर के अपने ट्रैफ़िक को अपने नियम चाहिए। केवल अग्रेषित पैकेटों को ढकने वाला नियम-समूह SSH और DNS को पुराने रास्ते पर छोड़ देता है, और इसी तरह टनल ऊपर आते ही राउटर अगम्य हो जाता है।

चरण 4: क्रम जाँचें, केवल उपस्थिति नहीं

नियम क्रम में मूल्यांकित होते हैं, इसलिए पहले आने वाला ACCEPT बाद में जोड़े गए REJECT को बस छिपा देता है। established और related मिलान ही वह है जो आपके अपने आउटबाउंड अनुरोधों के जवाबों को सामान्य इनबाउंड रास्ता खोले बिना लौटने देता है, और इसे टनल स्वीकृति के बाद रखने का अर्थ है कि गिरी हुई टनल अब भी अपने इंटरफ़ेस पर वापसी ट्रैफ़िक पार कराती है।

नियमों की संख्या एक स्क्रीन पर पढ़े जाने लायक छोटी रखें। जिस नियम-समूह का आप ऑडिट नहीं कर सकते, वही आप ऊपर अपवाद जोड़कर पैबंद लगाएँगे, और इसी तरह डिफ़ॉल्ट-अस्वीकृति नीतियाँ धीरे-धीरे डिफ़ॉल्ट-अनुमति का किनारा पा लेती हैं। बदलाव से पहले और बाद में ACCEPT गिनें।

चरण 5: इसे बूट और पता परिवार दोनों झेलने लायक बनाएँ

हाथ से दर्ज नियम रीबूट पर मिट जाते हैं, इसलिए उन्हें वितरण की फ़ायरवॉल सेवा या टनल इंटरफ़ेस बनने के बाद चलने वाली unit से लोड करें। OpenVPN शुरू होने से पहले चलने वाली स्क्रिप्ट में tun_work का संदर्भ देना गिरे ट्रैफ़िक का बूट लूप बनाने का आम तरीका है।

फिर IPv6 अलग से जाँचें, क्योंकि IPv4 के लिए अच्छी डिफ़ॉल्ट-अस्वीकृति नीति दूसरे परिवार के बारे में कुछ नहीं कहती। ip -6 route आपको बताएगा कि होस्ट के पास ऐसा मार्ग है या नहीं जो केवल IPv4 संभालने वाली टनल के चारों ओर ट्रैफ़िक ले जा सके, और ip6tables या nftables को अपने बराबर नियम चाहिए। नियम-समूह की सममिति पर भरोसा करने के बजाय IPv6-only गंतव्य से परीक्षण करें।

चरण 6: सत्यापित करें और पुनर्स्थापित के लिए तैयार रहें

टनल ऊपर लाएँ, पुष्टि करें कि आपकी इच्छित सेवा काम करती है, फिर कुछ ऐसा आज़माएँ जिसे नीति को अस्वीकार करना चाहिए। अगर जवाब आपको चौंकाए तो iptables-restore < /root/iptables.pre से पुनर्स्थापित करें, और तभी नियम संपादित करना शुरू करें। दृढ़ता के साथ परखा हुआ पुनर्स्थापन मार्ग ही इसे ऐसा बदलाव बनाता है जिसे आप दो बार कर सकते हैं।