nginx बिग्रनु अघि OpenVPN SNAT नियमको दायरा तोक्नुहोस्

एउटै प्रकारको होस्टबाट दुई विफलता लगातार आउँछन्। पहिलोमा ग्राहकहरू प्रमाणित भएर त्यसपछि सुरुङभन्दा बाहिर केही पनि पुग्दैनन्। दोस्रोमा VPN उठ्छ र सर्भरको आफ्नै वेबसाइट जवाफ दिन बन्द गर्छ, जुन बढी चिन्ताजनक छ किनकि यो सहायक क्षतिजस्तो देखिन्छ। कन्टेनरमा आधारित VPS मा दुवै सामान्यतया उही छोटो जाँचसूचीमा फर्कन्छन्, र क्रम महत्त्वपूर्ण छ: पहिले यन्त्र, दोस्रो अनुवाद, तेस्रो दायरा।

कन्टेनरले tun यन्त्र बनाउन सक्छ भन्ने पुष्टि गर्नुहोस्

सुरुङ इन्टरफेस रहनै नसक्ने भए अरू केही महत्त्वपूर्ण छैन। /dev/net/tun उपस्थित छ र परीक्षण यन्त्र बनाउनु सफल हुन्छ भनी जाँच्नुहोस्, किनकि धेरै प्रदायकले कन्टेनरभित्र tun लाई पूर्वनिर्धारित रूपमा बन्द राख्छन्। कहिल्यै नबनाइएको यन्त्रको क्षतिपूर्ति कुनै firewall कामले गर्दैन।

यन्त्र छैन भने होस्ट वा प्रदायकले मात्र सक्रिय गर्न सक्छ। हप्ताभर चल्ने खुला सहयोग थ्रेडभन्दा अर्को योजना प्रायः सस्तो हुन्छ। OpenVPN लगको एउटा पनि लाइन पढ्नुअघि यो पुष्टि गर्नुहोस्। नत्र कहिल्यै प्याकेट नदेख्ने नियमहरू ट्युन गर्दै साँझ बिताउनुहुनेछ।

यो इन्टरफेसमा MASQUERADE ले के गर्छ भनी निर्णय गर्नुहोस्

सामान्य भर्चुअल मेसिनमा सामान्य इग्रेस नियम मुख्य इन्टरफेसबाट POSTROUTING MASQUERADE हुन्छ। OpenVZ कन्टेनरमा देखिने यन्त्र प्रायः venet0 हुन्छ, अर्थात् होस्टले व्यवस्थापन गर्ने भर्चुअल इन्टरफेस, रुट गरिएको NIC होइन, र MASQUERADE त्यहाँ ट्युटोरियलले मानेजस्तै सधैं व्यवहार गर्दैन।

काम गर्ने रूप भनेको ग्राहकहरू पहिले नै पुग्ने ठेगानामा स्पष्ट अनुवाद हो, दुवै दिशामा फर्वार्डिङलाई अनुमति दिएर। सर्भर कन्फिगरेसनबाट pool बदल्नु ठेगाना बदल्नुजत्तिकै महत्त्वपूर्ण छ। टाँस्नुअघि प्रत्येक लाइन पढ्नुहोस्।

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

फर्वार्डिङ नियमबिना पनि अनुवाद हुन्छ र कर्नेलले फर्वार्ड गर्न अस्वीकार गर्छ। यो संयोजनले NAT नियमका काउन्टर बढ्दै जाँदा ग्राहकले केही नपाउने अन्योलपूर्ण अवस्था बनाउँछ। दुवै FORWARD लाइन पनि उही चेनमा कुनै पनि फराकिलो drop नियमअघि हुनुपर्छ। क्रम कन्फिगरेसनको भाग हो, कार्यान्वयनको विवरण होइन।

नियमलाई एउटा pool र एउटा इन्टरफेसमा सीमित गर्नुहोस्

दोस्रो लक्षणको कारण फरक छ: स्रोत वा आउटपुट प्रतिबन्ध नभएको POSTROUTING नियम। यस्तो नियमले होस्ट छोड्ने प्रत्येक प्याकेट पुनः लेख्छ।

मूल स्रोतमा निर्भर सेवाहरू त्यसपछि गलत व्यवहार गर्छन्। स्थानीय प्रोक्सीपछाडिको वेब सर्भरले जवाफ दिन बन्द गर्न सक्छ, र पुनः सुरु गर्दा केही फरक पर्दैन किनकि नियम अझै बाटोमा छ। होस्टले आफ्नै सार्वजनिक ठेगानामा पठाउने ट्राफिक पनि प्रभावित हुन्छ, त्यसैले विफलता firewall नभई DNS वा प्रमाणपत्रको समस्या जस्तो देखिन सक्छ। नियम पहिलो लक्षण सुधार्नकै लागि थपिएको हुन् भन्ने लगभग निश्चित छ।

समाधान भनेको मिलानलाई सुरुङ pool र इग्रेस इन्टरफेसमा साँघुरो पार्नु, त्यसपछि धेरै ढाक्न एउटा नियम फराकिलो पार्नुको सट्टा प्रत्येक pool का लागि एउटा नियम थप्नु हो।

नियमहरूलाई स्थायी बनाउनुहोस् र ती अरू कसको स्वामित्वमा छन् पत्ता लगाउनुहोस्

हातले थपिएका नियम रिबुटमा हराउँछन्, त्यसैले तिनलाई iptables-save ले सुरक्षित गर्नुहोस् वा जहाँ स्थापित छ त्यहाँ netfilter-persistent मार्फत व्यवस्थापन गर्नुहोस्। पुनर्स्थापना OpenVPN सुरु हुनुअघि चल्छ भनी पुष्टि गर्नुहोस्। त्यसपछि घटनाको क्रममा खाडल पत्ता लगाउनुको सट्टा जानाजान एकपटक रिबुट गर्नुहोस्।

कन्टेनर होस्टमा, स्थायित्व फाइल लेख्न सकिने कन्टेनर भण्डारणमा छ र प्रदायकले बुटमा फिल्टरिङ बदल्दैन भन्ने पनि पुष्टि गर्नुहोस्। केही प्लेटफर्मले नीति कन्टेनरबाहिर व्यवस्थापन गर्छन्, जहाँ स्थानीय नियम या त बेवास्ता गरिन्छ वा होस्टका आफ्नै नियमसँग ठोकिन्छ।

काउन्टर र एउटा कैप्चर गरिएको प्रवाहले प्रमाणित गर्नुहोस्

जोडिएको ग्राहकबाट, बाह्य सेवाले जनाउने सार्वजनिक ठेगाना जाँच्नुहोस्। यदि त्यो सर्भरको ठेगानासँग मिल्छ भने अनुवाद काम गर्छ; नमिले प्याकेट अर्को बाटोबाट बाहिरिँदै छ वा बाहिरिँदै छैन। त्यसपछि सर्भरमा होस्ट गरिएको सेवा र सार्वजनिक इन्टरनेटमा रहेको सेवा दुवै प्रयास गर्नुहोस्, किनकि ती एउटै नियमसमूहबाट फरक बाटो लिन्छन्।

सर्भरमा iptables -t nat -L -v -n प्रयोग गरी NAT र FORWARD नियमका प्याकेट काउन्टर पढ्नुहोस् र कैप्चरमा एउटा प्रवाह हेर्नुहोस्। यदि कैप्चरमा ग्राहकको ठेगाना देखिन्छ र कुनै जवाफ आउँदैन भने खाडल फर्कने बाटोमा वा प्रदायकको फिल्टरिङमा छ, ग्राहक प्रोफाइलमा होइन। कैप्चर गरिएको स्रोतलाई नियमले अनुवाद गर्ने ठेगानासँग तुलना गर्नुहोस्, किनकि नमिल्नु भनेको पहिले अर्को नियम मिल्यो भन्ने हो। एउटा अवलोकित प्रवाहले कन्फिगरेसन पढ्ने एक पृष्ठभन्दा बढी कुरा टुंग्याउँछ।

pool, अनुवादित ठेगाना र इन्टरफेसको नाम परिवर्तन अभिलेखमा सँगै राख्नुहोस्। एउटा pool का लागि सही नियमले अर्कोलाई गलत अनुवाद गर्छ।