VPS फायरवॉल: फक्त VPN पोर्ट उघडा, मग ते सिद्ध करा

फक्त VPN पोर्टला परवानगी देणारा फायरवॉल एक नियम नाही। हे तीन वेगळे निर्णय आहेत जे योगायोगाने एकाच पोर्ट क्रमांकाशी संबंधित आहेत: इनपुट शृंखला ठरवते की स्थानिक प्रक्रियेपर्यंत काय पोहोचू शकते, फॉरवर्ड शृंखला ठरवते की टनेल क्लायंटच्या वतीने होस्टमधून काय जाऊ शकते, आणि NAT तक्ता बाहेर जाताना स्रोत पत्ता पुन्हा लिहितो। यापैकी एकही चुकल्यास निकाल क्वचितच स्वच्छ खंड होतो। तुम्हाला असा होस्ट मिळतो जो क्लायंट स्वीकारतो पण काहीही लोड करत नाही, किंवा असा होस्ट जो कोणी शृंखलांचा क्रम वाचेपर्यंत बंद दिसतो।

बंद करता न येणारा एकमेव पोर्ट

VPN श्रोत्याला अशा पत्त्यांवरून कनेक्शन स्वीकारावे लागतात ज्यांचा तुम्ही आधीच अंदाज लावू शकत नाही, म्हणून ती व्याख्येने सार्वजनिक सेवा आहे। डिझाइन याच एका अपवादावर उभे आहे: OpenVPN साठी एक UDP पोर्ट, WireGuard साठी एक UDP पोर्ट, SSL VPN साठी एक TCP पोर्ट। बाकी सर्व टनेलच्या मागे आहे, म्हणजे अनुप्रयोग सेवांनी सर्व इंटरफेसऐवजी टनेलच्या पत्त्यावर किंवा loopback वर बांधले पाहिजे।

मात्र बांधणे म्हणजे अंमलबजावणी नाही। 0.0.0.0 ला बांधलेली प्रक्रिया नियम परवानगी देतो तेव्हाच पोहोचण्यायोग्य असते, आणि डीफॉल्ट धोरण हे कोणत्याही नियमाशी जुळलेल्या नसलेल्या रहदारीसाठी पर्यायी मार्ग आहे, पोर्ट नियंत्रित करणारा नियम नाही। तुमच्या ड्रॉपच्या वर ठेवलेली स्वीकृतीही स्वीकृतीच असते, आणि सेवा सार्वजनिक पत्त्यावरून दूर हलवणे हे स्वतंत्र सुधारणा आहे, शृंखलेचा पर्याय नाही।

इनपुट, फॉरवर्ड आणि NAT वेगवेगळ्या प्रश्नांची उत्तरे देतात

इनपुट रहदारी होस्टलाच उद्देशून असते, म्हणून VPN श्रोता आणि प्रशासकीय मार्ग तिथेच असतात। फॉरवर्ड रहदारी होस्टमधून जाते, आणि टनेल क्लायंटना ती net.ipv4.ip_forward=1 सह आवश्यक असते। पारंपरिक अर्धवट तुटलेली संरचना बाहेर जाणाऱ्या प्रवाहाला परवानगी देते आणि परत येण्याची दिशा विसरते, त्यामुळे क्लायंट हातमिळवणी पूर्ण करतो आणि मग काहीही लोड होत नाही; प्रस्थापित आणि संबंधित रहदारीसाठीचा conntrack नियम ती दिशा झाकतो।

NAT हा तिसरा प्रश्न आहे। postrouting मध्ये पुनर्लेखन न केल्यास, फॉरवर्ड केलेले पॅकेट टनेलच्या खाजगी स्रोतासह बाहेर पडतात आणि वरच्या टप्प्यावर टाकले जातात, कारण होस्टच्या पलीकडील कोणत्याही नेटवर्कला पूल परत राउट कसे करायचे हे माहीत नाही। त्या नियमातील स्रोत उपसर्ग VPN पूलाशी जुळला पाहिजे, होस्टच्या स्वतःच्या पत्त्याशी नाही, आणि क्लायंट उपजाळाचे नाव घेणाऱ्या फॉरवर्ड नियमालाही हेच लागू आहे।

IPv6 हे दुसरे धोरण आहे, नंतरचा विचार नाही। कठोर IPv4 शृंखला आणि ip6tables वर खुले धोरण असलेल्या होस्टने काहीही बंद केलेले नाही; सेवा दुसऱ्या कुटुंबातून अजूनही पोहोचण्यायोग्य आहेत। एकतर ip6tables ने नियमसंच प्रतिबिंबित करा, किंवा सार्वजनिक इंटरफेसवर IPv6 जाणूनबुजून बंद करा, आणि तुम्ही कोणते निवडले ते लिहा।

एका वाचनात समजणारा पाया

नाकारण्यापासून सुरुवात करा आणि नंतर होस्टला आवश्यक तेच जोडा। आधी loopback आणि उत्तरे, नंतर प्रशासकीय मार्ग, नंतर टनेल श्रोता, नंतर क्लायंटसाठी फॉरवर्डिंग धोरण:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

इंटरफेसची नावे, पोर्ट आणि पूल हे प्लेसहोल्डर आहेत; ते कॉपी करण्याऐवजी सर्व्हरवरून वाचा। निकाल जतन करणे तो लिहिण्याइतकेच महत्त्वाचे आहे, कारण केवळ स्मृतीत जगणारा नियमसंच पुढील रीबूटमध्ये नाहीसा होतो आणि होस्ट शांतपणे पुन्हा उघडतो। वितरणाच्या यंत्रणेने तो टिकाऊ करा, आणि मशीन बूट होणार नाही अशा दिवसासाठी मशीनबाहेर प्रत ठेवा।

होस्ट न गमावता शेवटचा पोर्ट बंद करणे

डिझाइनमध्ये एक सापळा आहे। जर SSH केवळ टनेलमधूनच असेल, तर अपयशी VPN सेवा SSH लाही घेऊन जाते, आणि परत जाण्याचा एकमेव मार्ग तुम्ही कधीही न उघडलेला कन्सोल असू शकतो। शेवटचा सार्वजनिक पोर्ट बंद करण्यापूर्वी तो कन्सोल अस्तित्वात आहे आणि तुम्ही खरोखर वापरू शकता याची खात्री करा, किंवा टनेलवर अवलंबून नसलेला एक अरुंद प्रशासकीय मार्ग ठेवा: निश्चित पत्त्यावरून SSH, फक्त किल्ल्या, पासवर्ड प्रमाणीकरण बंद।

बदल आधीच प्रस्थापित झालेल्या सत्रातून लागू करा, तुम्ही फिल्टर करणार असलेल्या कनेक्शनमधून नाही। चूक कायमची होण्याऐवजी संपुष्टात येण्यासाठी रोलबॅक नियोजित करा, उदाहरणार्थ मागील नियमसंच पुनर्संचयित करणारे systemd-run --on-active=10min कार्य, आणि पहिले तपासताना दुसरे SSH सत्र उघडे ठेवा। त्यानंतर रोलबॅक कार्य खरोखर सुरू होते का ते तपासा, कारण न तपासलेली पुनर्प्राप्ती पुनर्प्राप्ती नसल्यासारखीच आहे।

स्क्रिप्ट नाही, मार्ग तपासा

लोड झालेले नियम वाचा, ते लोड करायचे होते ती फाइल नाही। अधिकृत बाह्य होस्टवरून फक्त इच्छित पोर्टच उत्तर देतात याची खात्री करा; टनेलच्या आतून तुम्ही प्रकाशित करू इच्छित असलेल्या सेवा पोहोचण्यायोग्य आहेत याची खात्री करा। टनेल रहदारीलाही अडवणारे डीफॉल्ट-नाकार धोरण, कोणी ते वापरण्याचा प्रयत्न करेपर्यंत कार्यरत कुलूपासारखेच दिसते।

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

परवानगी दिलेला पोर्ट, क्लायंट पूल, टनेल इंटरफेस, प्रशासकीय स्रोत आणि कन्सोल प्रक्रिया संरचनेच्या शेजारी नोंदवा। पूल किंवा इंटरफेसच्या नावातील पुढील बदल फिल्टर आणि NAT नियम दोन्हीत जुळला पाहिजे, नाहीतर होस्ट कोणाच्याही लक्षात न येता अर्धा-उघड्या स्थितीत परतेल।

एक सवय नियमसंचापेक्षा जास्त मौल्यवान आहे: प्रत्येक बदलानंतर क्लायंट विनंतीने फॉरवर्ड मार्ग आणि दुसऱ्या सत्राने पुनर्प्राप्ती मार्ग सिद्ध करा। तुम्ही वापरले नाही असे कुलूप हे केवळ एक गृहीतक आहे।