VPN क्लायंट रहदारी आणि फायरवॉल स्थिती: बाहेरील आणि आतील प्रवाह

VPN हँडशेक पूर्ण होतो, क्लायंटला पत्ता मिळतो, तरीही गेटवेमागील सेवा कनेक्शन नाकारते. फायरवॉल बहुतेक वेळा त्याला सांगितलेलेच करते. त्याने बाहेरील टनेल प्रवाहाला परवानगी दिली, जो डीकॅप्स्युलेटेड अनुप्रयोग कनेक्शनपेक्षा वेगळा पॅकेट आहे. यातून दोन निर्णय येतात: तुम्ही कोणत्या प्रवाहाला परवानगी देता, आणि सीमा स्थितीचा मागोवा घेते का.

ही दोन वेगळी करेपर्यंत प्रत्येक नियम बदल हा एक अंदाज आहे.

फायरवॉल दोन वेगवेगळे पॅकेट पाहते

डीकॅप्स्युलेशनपूर्वी फायरवॉल VPN एंडपॉइंटला पाठवलेली रहदारी पाहते: श्रोत्याकडे जाणारा बाहेरील UDP प्रवाह. डीकॅप्स्युलेशननंतर पुढे पाठवलेले पॅकेट क्लायंटचा आतील पत्ता आणि सेवेचे गंतव्य घेऊन जाते.

बाहेरील प्रवाहाची परवानगी पुढे पाठवलेल्या TCP कनेक्शनला अधिकृत करत नाही. त्यांचे मूल्यांकन वेगवेगळ्या साखळ्यांमध्ये, वेगवेगळ्या इंटरफेससमोर आणि भाषांतरानंतर वेगवेगळ्या पत्त्यांसह होऊ शकते.

दोन्ही बाजूंच्या समतुल्य ठिकाणांहून घेतलेल्या कॅप्चरची तुलना करा. टनेलच्या काठावरील कॅप्चर आणि सर्व्हरवरील कॅप्चर एकाच सत्रासाठी वेगवेगळे ट्युपल दाखवतात.

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

क्लायंटला फक्त VPN एंडपॉइंटच आवश्यक असल्यास बाहेरील परवानगी पुरेशी असू शकते. गेटवेच्या पलीकडे सेवा आवश्यक असल्यास त्या गंतव्यासाठी आणि पोर्टसाठी पुढे पाठवण्याची परवानगी आवश्यक आहे. सेवेलाही परवानगी देणारा टनेल नियम हा तुम्ही नाव देऊ पाहिजे असा रचना-निर्णय आहे, अपघात नाही.

क्लायंटची श्रेणी आणि सेवेचा व्याप कमी ठेवा. टनेल सबनेटपासून संपूर्ण LAN पर्यंतची परवानगी म्हणजे प्रत्येक होस्टवर विश्वास ठेवण्याचा निर्णय, एका अनुप्रयोगासाठीचा शॉर्टकट नाही.

दोन्ही नियम वेगळे लिहा. टनेल नियम आणि सेवा नियम वेगवेगळ्या पद्धतीने अयशस्वी होतात आणि वेगवेगळ्या पुराव्यांनी डीबग होतात. एक अयशस्वी झाल्यास कोणता स्तर आधी तपासायचा हे तुम्हाला कळते.

दुसरा निर्णय: प्रत्येक सीमेवर स्थितीसह किंवा स्थितीशिवाय

प्रस्थापित प्रवाहाचा नियम परवानगी दिलेल्या देवघेवीसाठी प्रतिसाद आत सोडू शकतो, पण त्याचे वर्तन उत्पादनावर अवलंबून आहे. क्लाउड सुरक्षा गट सहसा स्थिती ठेवतो; सबनेट प्रवेश नियंत्रण सूची बहुतेक वेळा स्थिती ठेवत नाही आणि दोन्ही दिशांना स्पष्ट हाताळणी आवश्यक असते. मार्गावरील प्रत्येक सीमा स्थितीला सारखेच पाहते असे गृहीत धरू नका. नियम रचण्यापूर्वी प्रत्येक सीमा सूचीबद्ध करा आणि स्थितीसह किंवा स्थितीशिवाय असे चिन्हांकित करा.

नियम बदलल्यास, विद्यमान मागोवा घेतलेले प्रवाह चालू राहू शकतात आणि नवीन अयशस्वी होऊ शकतात, किंवा उलटही. तो फरक उपयुक्त सुगावा आहे, जिवंत गेटवेवर सर्व कनेक्शन स्थिती रिकामी करण्याचे कारण नाही.

नवीन नियंत्रित विनंतीने चाचणी करा आणि संबंधित काउंटर तपासा. स्वच्छ चाचणी व्यत्यय आणणाऱ्या रीसेटपेक्षा बरी आहे. बदलाच्या नोंदीत काउंटरचे नाव लिहा, पुढील चाचणी तोच पुरावा वापरावा.

त्याच धोरणाखाली परतीचा मार्ग सत्यापित करा

क्लायंटकडून सेवेकडे नवीन विनंती पाठवा, नंतर प्रत्येक सीमेवर पुढे आणि परतीचे काउंटर तपासा. प्रतिसाद अपेक्षित मार्ग वापरत असल्याची खात्री करा, विशेषतः भाषांतर सामील असल्यास.

अपेक्षित क्लायंट श्रेणी आणि सेवेचा व्याप कमी ठेवा, आणि विनंतीला परवानगी देणाऱ्या त्याच नियमसंचाखाली परतीचा मार्ग सत्यापित करा. जुना प्रवाह अजून उघडा आहे म्हणूनच चालणारा नियम हा चालणारा नियम नाही.