VPN सर्वर के लिए क्लाउड फ़ायरवॉल बनाम होस्ट फ़ायरवॉल

क्लाउड नीति में VPN पोर्ट को अनुमति दें और हैंडशेक फिर भी इंस्टेंस पर मर सकता है: अतिथि अपना फ़िल्टर और अपना श्रोता-बंधन चलाता है, और इनमें से कोई भी वह चीज़ फेंक सकता है जिसे क्लाउड ने मंज़ूर किया था। उल्टा भी होता है, जब होस्ट का नियम पोर्ट को अनुमति देता है और ऊपर की नीति उसे पहले गिरा देती है। दो मालिक, नियमों के दो सेट, एक पैकेट पथ। सबसे संदिग्ध परत पर अंदाज़ा लगाने के बजाय उसे क्रम से चलिए।

किनारे से शुरू करके अंदर की ओर बढ़िए

क्रम तय है: सार्वजनिक एंडपॉइंट, संसाधन इंटरफ़ेस, जुड़ी क्लाउड नीति, अतिथि का पता, प्रक्रिया श्रोता, स्थानीय इनपुट नियम। हर चरण या तो पैकेट को आगे बढ़ाता है या जाँच खत्म कर देता है, इसीलिए अतिथि से शुरू करने में सबसे ज़्यादा समय बर्बाद होता है।

आगे भेजा गया क्लाइंट ट्रैफ़िक अलग चरण है, जिसकी जाँच टनल खोलने के बाद होती है। क्लाउड परत केवल बाहरी टनल देखती है, इसलिए वह कनेक्शन मंज़ूर कर सकती है और फिर भी आंतरिक सेवा अनुरोध से उसका कोई संबंध न हो। जो टनल जुड़ती है पर आंतरिक होस्ट तक नहीं पहुँचती, वह आम तौर पर फ़ॉरवर्डिंग की ओर इशारा करती है, बंद पोर्ट की ओर नहीं।

अतिथि को छूने से पहले क्लाउड नीति पढ़िए

VPN पोर्ट के इनबाउंड नियम, उसके प्रोटोकॉल और उस स्रोत-दायरे की पुष्टि कीजिए जो आपके परीक्षण क्लाइंट से मेल खाता है। सबनेट एक्सेस कंट्रोल सूची भी देखिए: अपने नियमों और डिफ़ॉल्ट वाला दूसरा फ़िल्टर। पैकेट के इंस्टेंस तक पहुँचने से पहले दोनों को प्रवाह की अनुमति देनी चाहिए। एक में अनुमति और दूसरे में अस्वीकृति इस बग का सामान्य रूप है।

दायरे को तब तक सँकरा कीजिए जब तक उसका कोई अर्थ रहे। VPN पोर्ट को पूरे इंटरनेट के लिए खोलना साबित करना आसान और बचाव करना कठिन है, जबकि एक पते पर टिका नियम तब टूटता है जब आपका परीक्षण क्लाइंट नेटवर्क बदलता है। नियम का पहचानकर्ता और नीति का मालिक लिख लीजिए, ताकि अगला बदलाव किसी व्यक्ति तक खोजा जा सके।

पहले श्रोता की पुष्टि कीजिए, फिर इनपुट श्रृंखला की

इंस्टेंस पर जाँचिए कि VPN प्रक्रिया उसी पते और पोर्ट से बँधी है जिसकी आप अपेक्षा करते हैं, उदाहरण के लिए ss -lntp 'sport = :1194' से। केवल 127.0.0.1 से बँधा डेमॉन स्थानीय क्लाइंट स्वीकार करता है और टनल से कुछ नहीं, जो बाहर से ठीक फ़िल्टर किए गए पोर्ट जैसा दिखता है।

फिर स्थानीय नियम उसी वाक्य-रचना में पढ़िए जिसे आप उन्हें बदलने के लिए इस्तेमाल करेंगे, जैसे iptables -S INPUT या nft list chain inet filter input। फ़ाइल में लिखा गया पर कभी लोड न किया गया नियम, या बिना मेल खाती अनुमति वाला डिफ़ॉल्ट ड्रॉप, पैकेटों को चुपचाप गिरा देता है। फ़ॉरवर्डिंग गेटवे के लिए फ़ॉरवर्डिंग और रिवर्स-पथ सेटिंग्स भी देखिए। वही तय करती हैं कि इंस्टेंस से होकर रूट होने वाले, न कि उसे संबोधित, पैकेटों का क्या होगा।

एक परत में स्टेटफ़ुल, अगली में स्टेटलेस

सुरक्षा समूह उन प्रवाहों को याद रखते हैं जिन्हें उन्होंने अनुमति दी और प्रतिक्रियाओं को वापस आने देते हैं। सबनेट एक्सेस कंट्रोल सूचियाँ और बहुत से होस्ट फ़ायरवॉल ऐसी स्थिति नहीं रखते, इसलिए केवल बाहर जाने वाली दिशा को ढकने वाला नियम अनुरोध को पार करा देता है और प्रतिक्रिया गिरा देता है। दूसरी परत का नियम पढ़े बिना परतों के बीच लौटते ट्रैफ़िक की धारणा कभी न ले जाइए (second layer's rule)।

खाते के हर नियम को पढ़ने से जल्दी काउंटर फ़ैसला कर देते हैं। बढ़ता काउंटर मतलब पैकेट वहाँ पहुँचा और वहीं गिराया गया, जबकि शून्य पर जमा काउंटर मतलब वह वहाँ तक पहुँचा ही नहीं; नियम काउंटरों के साथ लोड होने पर iptables -vnL INPUT और nft list ruleset वही आँकड़े दिखाते हैं।

जीवंत नहीं, ताज़ा सत्र से परखिए

दृश्यों की तुलना करते समय स्रोत नेटवर्क और परीक्षण प्रोफ़ाइल को छेड़िए मत, और हर बदलाव के बाद नया कनेक्शन खोलिए। 443 पर वेब कंसोल तक पहुँचना यह नहीं बताता कि VPN डेमॉन 1194 से बँधा है या नहीं, इसलिए जिस पोर्ट की आपको ज़रूरत है उसी को परखिए। मौजूदा सत्र यहाँ सबसे बुरा गवाह है। हर नया लॉगिन ठुकराए जाने के दौरान भी वह चलता रहता है।

दूरस्थ नीति संपादित करने से पहले लौटने का ऐसा रास्ता रखिए जो उस पथ पर निर्भर न हो जिसे आप बदल रहे हैं। फिर VPN परीक्षण के साथ दूसरा प्रशासनिक सत्र खोलिए: पहले बना सत्र उस नियम से ज़्यादा जी सकता है जो नए सत्रों को रोकता है। दोनों नीतियों के मालिक दर्ज कीजिए ताकि कोई पुनर्निर्माण आधा पथ बहाल न कर दे; अगर दोनों परतें सहमत हैं और टनल फिर भी विफल होती है, तो अतिथि इंटरफ़ेस पर कैप्चर कीजिए और वह पता व पोर्ट जाँचिए जो क्लाइंट वास्तव में इस्तेमाल करता है।