SSL VPN की TLS आवरण? जी सीमा अपयशी ठरली तिची तुलना करा
दोन रचना 443 वर TLS चालवू शकतात आणि पूर्णपणे वेगळा अर्थ देतात. चार तपासण्या: संरचित मार्ग, बॅकएंड, वाहून नेला जाणारा रहदारी आणि अपयशी सीमा.
दोन रचना 443 पोर्टवर TLS चालवू शकतात आणि त्यामुळे पूर्णपणे वेगळ्या गोष्टी सुचवू शकतात। आवरण स्थानिक पोर्ट आणि दूरच्या बॅकएंडमधील एका संरचित जोडणीचे संरक्षण करते। नेटवर्क-प्रवेश रचना निवडलेली रहदारी वाहून नेते आणि क्लायंट कुठवर पोहोचू शकतो हे बदलते। खालील चार तपासण्या क्रमाने करा आणि तुम्हाला कळेल की तुम्ही कोणती पाहत आहात, जे सहसा कोणत्या स्तराचे अपयश झाले हे जाणून घेण्यासाठी पुरते।
तुम्ही प्रत्यक्षात संरचित केलेल्या जोडणीपासून सुरुवात करा
उत्पादनांची तुलना करण्यापूर्वी पुढचा आणि मागचा भाग लिहून घ्या। आवरण स्थानिक पत्त्यावर ऐकते आणि दूरच्या पत्त्यावर पाठवते, किंवा दूरच्या बाजूला कार्यक्रम सुरू करते, आणि ती जोडी म्हणजे त्याचा संपूर्ण करार। क्लायंटच्या इतर अनुप्रयोगांना त्याबद्दल काहीच माहीत नसते, जोपर्यंत तुम्ही त्यांना त्याकडे वळवत नाही। ही साधनाची कमतरता नाही, साधन यासाठीच आहे।
नेटवर्क रचनेचा करार वेगळा आहे, आणि तो पोर्ट-जोडीत नाही, मार्ग आणि धोरणात व्यक्त होतो।
त्या दोन वर्णनांपैकी कोणते तुमच्या आकृतीशी जुळते ते पहा। उत्तर मध्यभागी प्रमाणपत्र असलेले एक पोर्ट मॅपिंग असेल, तर उत्पादनाचे नाव VPN असेल तरी तुमच्याकडे आवरण आहे। उत्तर टनेल इंटरफेस आणि मार्ग बदल असेल, तर ते 443 वर चालले तरी तुमच्याकडे नेटवर्क रचना आहे।
आवरण कशाशी जोडले जाते ते तपासा
ऐकण्याच्या आणि जोडण्याच्या सेटिंग्ज वाचा आणि त्या खऱ्या बॅकएंडपर्यंत पाठवा। डेटाबेस पोर्टवर पाठवणारे आवरण वेब अनुप्रयोग उघडत नाही, आणि कार्यक्रम चालवणारे आवरण होस्टवरील बाकी सर्व प्रकाशित करण्याऐवजी तोच कार्यक्रम सुरू करते। बॅकएंड हीच एकमेव गोष्ट आहे जी आवरणाला माहीत आहे।
नंतर TLS संपल्यावर पाठवला जाणारा प्रवाह साधा मजकूर आहे का ते ठरवा। आवरण केलेली जोडणी दोन आवरणांमधील भागाचे संरक्षण करते, आणि दूरच्या आवरणानंतर काय होते हा वेगळा प्रश्न आहे। म्हणूनच स्वतःचे संरक्षण असलेल्या गोष्टीचे आवरण करणे कधी युक्तिवादाचे असते आणि कधी फक्त जास्त हलणारे भाग असते। दोनपैकी कोणतेही उत्तर गृहीत धरण्याऐवजी पुढचे पाऊल तपासा।
openssl s_client -connect wrapper.lab.example:443 -servername wrapper.lab.example -verify_return_error
sudo ss -ltnp | grep 443पहिली आज्ञा क्लायंटला प्रत्यक्षात दिले जाणारे प्रमाणपत्र दाखवते, आणि दुसरी होस्टवर काय ऐकत आहे ते दाखवते। दुसरे काही वाचण्यापूर्वी त्या प्रमाणपत्राच्या नावाची तुम्ही अपेक्षित असलेल्या नावाशी तुलना करा।
रचना कोणती रहदारी वाहून नेते ते तपासा
नेटवर्क-प्रवेश रचना निवडलेली रहदारी वाहून नेतात आणि क्लायंटच्या मार्गनिर्देशन आणि प्रवेश धोरणाशी एकत्र येतात। प्रवेश हा अधिकृतता नाही, म्हणून प्रमाणित जोडणीलाही कोणत्या संसाधनांपर्यंत पोहोचता येईल याचा निर्णय लागतो। क्लायंट-रहित पोर्टल हे तिसरे मॉडेल आहे जे समर्थित क्रिया प्रॉक्सी करते पण कधीही tun इंटरफेस म्हणून दिसत नाही।
उत्पादनाचे लेबल तुम्ही यापैकी कोणते मॉडेल विकत घेतले हे सांगत नाही, आणि पोर्ट क्रमांक त्याहून कमी सांगतो।
स्तररचना शक्य आहे आणि ती तुलनेला गोंधळवू नये। टनेल प्रोटोकॉल स्वतः समर्थित TCP मांडणीत TLS मध्ये गुंडाळला जाऊ शकतो, ज्यामुळे टनेलभोवती स्तर वाढतो पण आवरण टनेल होत नाही। हा स्वतःच्या कार्यप्रदर्शन आणि अपयश वर्तनासह रचना-निर्णय आहे, आणि आकृतीत एका ओळीचा हक्कदार आहे। तो नोंदवा, नंतर बाहेरील आवरण नाही तर मूळ मॉडेलांची तुलना करा।
अपयशी सीमा तपासा, लेबल नाही
एका अपयशी प्रयत्नाच्या तथ्ये लिहा: पुढच्या भागाचा पत्ता, श्रोता, क्लायंटने पडताळलेली ओळख, बॅकएंडचे लक्ष्य आणि मागितलेली क्रिया। यशस्वी हातमिळवणी बाहेरील TLS पूर्ण झाले हे सिद्ध करते आणि बॅकएंडबद्दल काहीच सांगत नाही। बॅकएंडचा नकार पुढच्या ओळखीच्या अपयशापेक्षा वेगळी घटना आहे, आणि क्लायंटमधून -verify_return_error काढून दोन्हीपैकी कोणतेही सुधारत नाही। समानाची समानाशी तुलना करा, कारण दुसऱ्या होस्टनाव किंवा पोर्टद्वारे मिळालेले यश अटी सारख्याच होत्या हे दाखवत नाही।
443 पोर्ट ही TLS ला मधल्या पेट्यांमधून जाऊ देणारी परंपरा आहे। ती अनियंत्रित रहदारी धोरण उपकरणासाठी वेब विनंतीसारखी करत नाही।
शेवटची जोडी, काय वाहून नेले जाते, कोणते अनुप्रयोग ते वापरतात आणि गंतव्य कोणती परवानगी लागू करते हे नाव देणाऱ्या एका वाक्याने संपवा। त्या चार रिकाम्या जागा भरू न शकणारी रचना, तिचे लेबल काहीही दावा करो, पूर्ण नाही। तेच वाक्य फायरवॉलच्या मालकाला रचना समजावण्याचा सर्वात वेगवान मार्ग आहे।