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 लॉकवर आदळतील. बदलाच्या खिडकीत यातले काहीही ऐच्छिक नाही.

पूलमधील क्लायंट आणि बाहेरील क्लायंटवरून चाचणी करून समारोप करा. तुम्ही टाइप केलेल्या मशीनवरूनच चालणारा नियम धोरण नाही.