iptables: VPN क्लाइंट्स को सिर्फ़ एक होस्ट तक पहुँचने दें

दो सपोर्ट टिकट जो असंबंधित लगते हैं, आख़िर में एक ही कारण साझा करते हैं। पहले में, एक प्रशासक चाहता है कि सर्वर सिर्फ़ टनल से कनेक्शन स्वीकार करे; दूसरे में, VPN उपयोगकर्ताओं को एक आंतरिक होस्ट तक पहुँचना चाहिए, उससे ज़्यादा कुछ नहीं। दोनों नीतियाँ FORWARD में हैं, और दोनों आम तौर पर INPUT में आज़माई जाती हैं। नतीजा फ़ायरवॉल जैसा दिखता है और प्लेसहोल्डर जैसा व्यवहार करता है।

कौन सी चेन आपके सवाल का जवाब देती है

VPN क्लाइंट जो पैकेट LAN होस्ट को या आगे इंटरनेट की ओर भेजता है, उन्हें कर्नेल फ़ॉरवर्ड करता है और FORWARD में उनका मूल्यांकन होता है। INPUT और OUTPUT सिर्फ़ वह ट्रैफ़िक देखते हैं जो सर्वर पर ही ख़त्म होता है या वहीं से शुरू होता है। इसलिए जो कुछ tun0 पर नहीं आता, उसे अस्वीकार करना सर्वर के अपने श्रोताओं की रक्षा करता है, और यह आपका SSH सत्र भी ख़त्म कर देगा, जब तक स्थापित फ़्लो को पहले अनुमति न दी जाए। इससे इस बात में कुछ नहीं बदलता कि क्लाइंट कहाँ जा सकते हैं।

पहले सवाल का नाम रखें: सर्वर तक कौन पहुँच सकता है, या क्लाइंट कहाँ जा सकते हैं। ज़्यादातर नेटवर्क को दोनों जवाब चाहिए, अलग-अलग चेन में।

पहले स्थिति, फिर अनुमति, फिर अस्वीकृति

अनुमति-सूची तभी काम करती है जब विशिष्ट अनुमति सामान्य अस्वीकृति के ऊपर हो और वापसी ट्रैफ़िक दोनों के ऊपर अनुमत हो। नियमों को स्पष्ट स्थानों पर डालें, फिर iptables -S FORWARD से चेन को डंप करें ताकि क्रम अनुमानित नहीं, दिखने वाला हो।

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

दो ब्यौरे तय करते हैं कि यह असली ट्रैफ़िक के संपर्क में टिकेगा या नहीं। स्थिति-नियम के बिना, जिन कनेक्शनों को आपने अभी अनुमति दी, उनके जवाब ख़ुद अस्वीकृति के सामने आँके जाते हैं और गिरा दिए जाते हैं। बिना सीमा वाला LOG नियम पहली स्कैन में ही छोटा विभाजन भर सकता है, इसलिए लॉग करना जारी रखने से पहले -m limit --limit 10/min जोड़ें। REJECT तुरंत त्रुटि लौटाता है, जो सूची साधते समय ज़्यादा सौहार्दपूर्ण है; DROP चुपचाप गिरा देता है, इसलिए हर ग़लती टाइमआउट जैसी दिखती है। जान-बूझकर एक चुनें और चुनाव को परिवर्तन रिकॉर्ड में लिखें।

फ़ॉरवर्डिंग और NAT को पहले से काम करना चाहिए

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

मास्करेड कहाँ बैठेगा यह इस पर निर्भर है कि क्लाइंट कहाँ से बाहर जाते हैं। अगर वे टनल से किसी दूरस्थ नेटवर्क की ओर जाते हैं, तो NAT नियम WAN इंटरफ़ेस पर नहीं, उसी इंटरफ़ेस पर जाता है। फिर काउंटर देखें: अगर POSTROUTING काउंटर कभी नहीं हिलता जबकि FORWARD में स्वीकृतियों की संख्या बढ़ती है, तो वापसी का रास्ता टूटा है और फ़िल्टर ठीक है। यह पढ़ाई उन नियमों को फिर से लिखने में एक दोपहर बचाती है जो कभी समस्या ही नहीं थे।

मेल ब्लॉक एक चेन आगे का है

INPUT में पोर्ट 25 ब्लॉक करना सिर्फ़ VPN सर्वर को भेजे गए मेल को रोकता है। टनल से मेल भेजने वाला संक्रमित क्लाइंट फ़ॉरवर्ड होता है, इसलिए ब्लॉक को 465 और 587 के बगल में FORWARD में बैठना होगा। अगर कोई एक एप्लिकेशन वैध रूप से मेल रिले करता है, तो उसका गंतव्य और पोर्ट उस नियम के ऊपर रखें।

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

कुछ और कसने से पहले अस्वीकृति काउंटर को एक हफ़्ते चलने दें। जो संख्या बढ़ना बंद कर दे, वही वैध प्रवाह है जिसे आपने अभी तोड़ा है।

इसे वापस पढ़ें, फिर क्लाइंट से सिद्ध करें

नियम-समूह को वैसे पढ़ें जैसे कर्नेल रिपोर्ट करता है, वैसे नहीं जैसे आपकी स्क्रिप्ट ने लिखा। iptables -S FORWARD से शुरू करें, फिर iptables -t nat -L POSTROUTING -n -v से NAT तालिका, फिर उस प्रवाह की conntrack प्रविष्टि जिसकी आप जाँच कर रहे हैं। जब तक काम चले, रोलबैक कमांड या निर्धारित फ़्लश रखें। हर कॉल के लिए -w चाहिए, वरना दो प्रशासक xtables लॉक पर टकराएँगे। बदलाव की खिड़की में इनमें से कुछ भी वैकल्पिक नहीं है।

पूल के अंदर के क्लाइंट और बाहर के क्लाइंट से परीक्षण करके समाप्त करें। जो नियम सिर्फ़ उसी मशीन से चलता है जिस पर आपने उसे टाइप किया, वह नीति नहीं है।