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 नियम दुवैमा मिल्नुपर्छ, नत्र होस्ट कसैलाई थाहा नहुँदै आधा खुला अवस्थामा फर्कन्छ।

एउटा बानी नियमसमूहभन्दा बढी मूल्यवान छ: प्रत्येक परिवर्तनपछि क्लाइन्ट अनुरोधले फर्वार्ड मार्ग र दोस्रो सत्रले पुनःप्राप्ति मार्ग प्रमाणित गर्नुहोस्। तपाईंले प्रयोग नगरेको लकडाउन केवल एउटा परिकल्पना हो।