कनेक्ट थिच्दा चार अलग कामहरू सुरु हुन्छन्, जो स्वतन्त्र रूपमा सफल वा असफल हुन्छन्। क्लाइन्टले श्रोतासम्म पुग्नुपर्छ, साथी को हो भनेर सहमत हुनुपर्छ, कुञ्जीहरू व्युत्पन्न गर्नुपर्छ र त्यसपछि काम गर्ने सुरुङ प्रणालीको बाँकी भागलाई हस्तान्तरण गर्नुपर्छ। धेरैजसो असफल जडानहरू गलत काममा निदान गरिन्छ। त्यसैले पहिलो त्रुटि तेस्रो प्रयासभन्दा बढी महत्त्वपूर्ण छ।

पहिले श्रोतासम्म पुग्नुहोस्

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

समय सकिनु, प्रमाणपत्र अस्वीकार र अस्वीकृत खाता तीन फरक जाँचका साथ तीन फरक खराबी हुन्। तिनीहरूलाई पहिले छुट्याउनु नै नेटवर्क समस्यालाई प्रमाण समस्याका रूपमा डिबग हुनबाट रोक्छ।

साथीलाई प्रमाणित गर्नुहोस्, त्यसपछि कुञ्जीहरू व्युत्पन्न गर्नुहोस्

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

त्यसपछि आदानप्रदानले प्रोटोकलकै इनपुटबाट ट्राफिक कुञ्जीहरू व्युत्पन्न गर्छ, र लगइन पासवर्ड सामान्यतया प्रत्येक प्याकेटमा छापिने कुञ्जी होइन। दीर्घकालीन पहिचान सामग्री र छोटो अवधिका सत्र कुञ्जीहरूको आयु र काम फरक हुन्छ। अगाडितिरको गोपनीयता यही छुट्याइको बारेमा हो।

समस्या समाधान गर्दा प्रमाणीकरण खुला राख्नुहोस्, किनभने जाँच बन्द गरेपछि जोडिने सुरुङले त्यो जाँच केही गरिरहेको थियो भन्नेबाहेक केही प्रमाणित गर्दैन। तपाईंले के बदल्नुभयो लेख्नुहोस् र अर्को परीक्षणअघि त्यो फर्काउनुहोस्।

तीन प्रोटोकल, तीन कुराकानी

TLS आधारित OpenVPN तैनाथीमा नियन्त्रण च्यानल सुरक्षा मापदण्डमा वार्ता गर्छ भने डेटा च्यानल सुरुङको ट्राफिक बोक्छ, त्यसैले डेटा च्यानल विकल्प र प्रमाणपत्र समस्या फरक ठाउँमा रहन्छन्। IKEv2 दुवै सहभागीलाई प्रमाणीकरण गर्छ र त्यसपछि आफ्नै आयु भएका IPsec सुरक्षा संघहरू स्थापना गर्छ। WireGuard Noise आधारित आदानप्रदानमार्फत कुञ्जीहरू व्युत्पन्न गर्छ र अवस्था मेसिन जानाजान छोटो राख्छ। तीनमध्ये कुन चलाउनुहुन्छ भन्ने जान्नाले कुन लग पढ्न योग्य छ भन्ने निर्धारण गर्छ।

उस्तै देखिने क्लाइन्टहरूको अर्थ तलका सन्देशहरू आदानप्रदानयोग्य छन् भन्ने होइन, र एउटा उत्पादनमा भएको कन्फिगरेसन फिल्डको अर्कोमा समान नहुन सक्छ। तिनीहरूबीच प्रोफाइल प्रतिलिपि गर्नु माइग्रेसन होइन, अनुमान हो।

ह्यान्डशेकले के गर्दैन

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

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

माथिको क्रममा चरणहरू चलाउनुहोस् र पहिलो त्रुटि दिने चरणमा रोक्नुहोस्। प्रत्येक पछिल्लो चरणले अघिल्ला चरणहरूको अवस्था पाउँछ, त्यसैले तेस्रो चरणको असफलताले चौथोको बारेमा केही भन्दैन।

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

सम्बन्धित लेखहरू