TCP काम करता है और UDP उसी पोर्ट पर किसी दूसरे सर्वर तक पहुँचता है

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

एक पोर्ट संख्या, दो स्वतंत्र नियम

अग्रेषण प्रोटोकॉल, गंतव्य पता और पोर्ट के आधार पर तालिका में खोज है। TCP 1194 के लिए नियम और UDP 1194 के लिए नियम रखने वाला गेटवे दो स्वतंत्र निर्णय व्यक्त करता है, और वे अलग-अलग आंतरिक होस्ट बता सकते हैं। साझा संख्या लोगों के लिए सुविधा है, ऐसा गुण नहीं जिसे नेटवर्क थोपता है। पोर्ट संख्या को लेबल की तरह देखें, सेवा परिभाषा की तरह नहीं।

प्रभावी नियम देखें, इच्छित नहीं। गंतव्य पता, अनुवादित पोर्ट और प्रवेश इंटरफ़ेस सभी भाग लेते हैं, और पिछले माइग्रेशन से बचा नियम आमतौर पर इसका कारण होता है कि दोनों हिस्से मेल नहीं खाते।

कुछ और बदलने से पहले दोनों मैपिंग लिख लें। पंक्तियों की जोड़ी पूरी परिकल्पना है।

क्लाइंट ने वास्तव में क्या सत्यापित किया

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

यह अंतर महत्वपूर्ण है क्योंकि दोनों विफलताएँ अलग-अलग सुधारों की ओर ले जाती हैं। भरोसे की समस्या के लिए भरोसे का सुधार चाहिए, जबकि अप्रत्याशित सामने वाले के लिए रूटिंग या अग्रेषण का सुधार चाहिए।

लिखें कि क्लाइंट ने कौन-सी पहचान बताई। वह नाम इस बात का सबसे मज़बूत सुराग है कि कौन-सी मशीन उत्तर दी।

प्रयास को सर्वर से जोड़ें

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

जिस प्रमाणपत्र पहचान से आप मिले उसकी तुलना अपेक्षित पहचान से प्रशासनिक चैनल के माध्यम से करें। यही चैनल से बाहर तुलना जाँच को भरोसेमंद रखती है।

यह निष्कर्ष निकालने से पहले कि दोनों परिवहन एक ही बैकएंड साझा करते हैं, पुराने अग्रेषण नियम, वैकल्पिक श्रोता और भार संतुलन का कोई भी पथ जाँच लें। इनमें से प्रत्येक दूसरे परिवहन को छुए बिना प्रवाह को दूसरी ओर मोड़ सकता है।

भरोसे को गलत सामने वाले के अनुरूप न बनाएँ

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

यदि सामने वाला वैध पर अनपेक्षित निकले, तो सही कार्रवाई उसे बंद करना या नियम को सही होस्ट की ओर मोड़ना है। भरोसा भंडार वह जगह नहीं है जहाँ इन्वेंटरी की गलती सुलझाई जाती है।

अस्वीकृति का पाठ सहेजें। यह क्लाइंट ने जो देखा उसका एकमात्र रिकॉर्ड है।

सुधार के बाद नया प्रवाह जाँचें

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

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