nginx टूटने से पहले OpenVPN SNAT नियम का दायरा तय करें

क्लाइंट प्रमाणित होते हैं पर कुछ भी रूट नहीं होता, या VPN उठने के बाद साइट मर जाती है। tun पहुँच जाँचें, फिर अनुवाद को pool और एक इंटरफ़ेस तक सीमित करें।

एक ही तरह के होस्ट से दो विफलताएँ बार-बार आती हैं। पहली में क्लाइंट प्रमाणित होते हैं और फिर टनल से आगे कुछ नहीं पहुँचते। दूसरी में 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 के लिए सही नियम अगले का गलत अनुवाद करता है।

संबंधित लेख