VPN क्लाइंट ट्रैफ़िक और फ़ायरवॉल स्थिति: बाहरी बनाम भीतरी प्रवाह

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

जब तक आप इन दोनों को अलग नहीं करते, हर नियम बदलाव एक अनुमान है।

फ़ायरवॉल दो अलग पैकेट देखता है

डीकैप्सुलेशन से पहले, फ़ायरवॉल VPN एंडपॉइंट को संबोधित ट्रैफ़िक देखता है: श्रोता की ओर बाहरी UDP प्रवाह। डीकैप्सुलेशन के बाद, फ़ॉरवर्ड किया गया पैकेट क्लाइंट का भीतरी पता और सेवा का गंतव्य ले जाता है।

बाहरी प्रवाह की अनुमति फ़ॉरवर्ड किए गए TCP कनेक्शन को अधिकृत नहीं करती। इनका मूल्यांकन अलग चेन में, अलग इंटरफ़ेस के सामने और अनुवाद के बाद अलग पतों के साथ हो सकता है।

दोनों ओर के समतुल्य स्थानों से लिए गए कैप्चर की तुलना करें। टनल के किनारे का कैप्चर और सर्वर पर का कैप्चर एक ही सत्र के लिए अलग ट्यूपल दिखाते हैं।

पहला निर्णय: टनल या सेवा की अनुमति

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

क्लाइंट की श्रेणी और सेवा का दायरा संकीर्ण रखें। टनल सबनेट से पूरे LAN तक की अनुमति हर होस्ट पर भरोसा करने का निर्णय है, एक एप्लिकेशन के लिए शॉर्टकट नहीं।

दोनों नियम अलग-अलग लिखें। टनल नियम और सेवा नियम अलग तरह से विफल होते हैं और अलग साक्ष्यों से डीबग किए जाते हैं। जब एक विफल हो, आप जानते हैं कि पहले कौन-सी परत जाँचनी है।

दूसरा निर्णय: हर सीमा पर स्थिति के साथ या बिना

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

यदि नियम बदलता है, तो मौजूदा ट्रैक किए गए प्रवाह काम करते रह सकते हैं जबकि नए विफल हो जाते हैं, या उल्टा। वह अंतर उपयोगी संकेत है, जीवंत गेटवे पर सारी कनेक्शन स्थिति खाली करने का कारण नहीं।

नए नियंत्रित अनुरोध से परीक्षण करें और संबंधित काउंटर जाँचें। स्वच्छ परीक्षण बाधित रीसेट से बेहतर है। परिवर्तन रिकॉर्ड में काउंटर का नाम लिखें ताकि अगला परीक्षण वही साक्ष्य इस्तेमाल करे।

उसी नीति के अंतर्गत लौटने का मार्ग सत्यापित करें

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

इच्छित क्लाइंट श्रेणी और सेवा का दायरा संकीर्ण रखें, और लौटने का मार्ग उसी नियम-सेट के अंतर्गत सत्यापित करें जिसने अनुरोध की अनुमति दी। जो नियम केवल इसलिए काम करता है कि पुराना प्रवाह अभी खुला है, वह काम करने वाला नियम नहीं है।