VPN हैंडशेक के चरण: ट्रैफ़िक बहने से पहले क्या होता है

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

पहले श्रोता तक पहुँचें

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

समय-समाप्ति, प्रमाणपत्र अस्वीकृति और अस्वीकृत खाता तीन अलग खराबियाँ हैं जिनकी तीन अलग जाँचें हैं। इन्हें पहले छाँटना ही नेटवर्क समस्या को क्रेडेंशियल समस्या के रूप में डिबग होने से रोकता है।

साथी को सिद्ध करें, फिर कुंजियाँ व्युत्पन्न करें

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

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

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

तीन प्रोटोकॉल, तीन बातचीत

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

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

हैंडशेक क्या नहीं करता

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

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

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

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal