साठी सेकेन्डको TLS समयसीमा: कुन छेउ साँच्चै रोकियो?
TLS सेटिङमा हात हाल्नुअघि एउटा क्लाइन्ट प्रयासलाई सर्भरका आफ्नै घटनासँग मिलाउनुहोस्। मौनता, चाँडो बहिष्कार र नाम दिइएको अस्वीकारका लागि फरक सुधार चाहिन्छ।
क्लाइन्ट साठी सेकेन्डपछि कुञ्जी वार्ताबारे सन्देशसहित हार मान्छ, र ल्यापटपले किन भनेर कुनै मत दिँदैन। त्यो वाक्यले क्लाइन्टको धैर्यको वर्णन गर्छ, सर्भरको व्यवहारको होइन। तीन पूर्ण रूपमा फरक परिस्थितिले यो उत्पन्न गर्छन्: प्याकेट कहिल्यै सही सेवासम्म पुगेन, सेवाले केही लग गर्नुअघि नै त्यसलाई फालिदियो, वा सेवाले त्यसलाई अस्वीकार गर्यो र क्लाइन्टले देख्न नसक्ने ठाउँमा भन्यो। दुवै छेउमा एउटा प्रयास मिलाउनु नै तिनलाई छुट्याउँछ।
एउटा प्रयासलाई तपाईंले खोज्न सक्ने पहिचान दिनुहोस्
सुरु समय त्यसको समय क्षेत्रसहित, प्रोफाइलको नाम, क्लाइन्टले वास्तवमै समाधान गरेको गन्तव्य, पोर्ट, र जडान UDP हो कि TCP भन्ने लेख्नुहोस्। प्रोफाइलमा धेरै टाढाका प्रविष्टि भए, त्यो प्रयासले कुन छान्यो भनी नोट गर्नुहोस्, किनकि पुनः प्रयास तपाईं पढिरहेको फाइल नबदली अर्को प्रविष्टिमा गएको हुन सक्छ।
अन्तिम बिन्दु सक्रिय लगबाट लिनुहोस्, तपाईंलाई सम्झना भएको डाउनलोडबाट होइन। निजी ठेगानातर्फ देखाउने प्रोफाइल पूर्ण रूपमा मान्य छ र त्यहाँ रुट गर्न नसक्ने सञ्जालबाट पूर्ण रूपमा अनुपयोगी छ, र त्यो अवस्था बन्द सर्भरजस्तै देखिन्छ।
त्यसपछि अपरेटरसँग इच्छित इन्स्टेन्समा त्यही विन्डो माग्नुहोस्। घडीको भिन्नता यति सामान्य छ कि केही मिनेटको फरकले मिल्ने घटनालाई अनुपस्थित देखाउन सक्छ, त्यसैले घटना थिएन भन्ने निष्कर्षमा पुग्नुको सट्टा फरक नोट गर्नुहोस्।
चार अवलोकन, चार फरक अर्को कदम
सर्भरले के लग गर्छ त्यसले शाखा निर्धारण गर्छ। कुनै पनि प्रयासको अभावले ठेगाना, यातायात वा सेवासम्मको बाटोतर्फ सङ्केत गर्छ। सामान्य आदानप्रदानअघि हराउने आउने प्याकेटले वास्तविक सेवाको नियन्त्रण च्यानलका आवश्यकतातर्फ सङ्केत गर्छ। नाम दिइएको अस्वीकारले त्यसले नाम दिने वस्तुतर्फ सङ्केत गर्छ। सर्भर छोडेर कहिल्यै क्लाइन्टसम्म नपुग्ने जवाफले फर्कने बाटोतर्फ सङ्केत गर्छ।
खाली अनुप्रयोग लग देखिनेभन्दा कमजोर प्रमाण हो। लगिङ आदानप्रदानको निश्चित बिन्दुबाट सुरु हुन्छ, र त्यो बिन्दुअघि फालिएका प्याकेटले तपाईं पढिरहेको फाइलमा कुनै चिन्ह छोड्दैनन्। जहाँ अनुमति छ, अपरेटरले सेवा र सञ्जालका अवलोकनबाट केही पुग्यो कि पुगेन हेर्न सक्छ।
तपाईंका नोटमा चारै नतिजा छुट्टै राख्नुहोस्। तिनलाई “सर्भर जवाफ दिँदैन” मा मिसाउने प्रलोभन हुन्छ, र वास्तविक समस्या फायरवाल नियम हुँदा मानिसलाई साइफर बदल्न पठाउने त्यही वाक्यांश हो। केवल समयसीमा शब्द नोट गर्ने नोटले तपाईंले भर्खरै मूल्य तिरेको भिन्नता फालिदिएको छ।
प्रमाणले नाम दिने चरण सुधार्नुहोस्
पूरा भएको TCP जडानले केही कुराले सकेट स्वीकार गर्यो भन्ने मात्र प्रमाणित गर्छ। सुन्ने व्यक्ति तपाईंले कन्फिगर गरेको OpenVPN सेवा हो भन्ने प्रमाणित गर्दैन, र त्यही होस्टनामको वेब सर्भरले ब्राउजरलाई उत्तम जवाफ दिन्छ तर सुरुङसँग यसको कुनै सम्बन्ध हुँदैन।
सर्भरले म्याद सकिएको रद्द सूची रिपोर्ट गरे त्यो क्लाइन्टको अन्तिम समयसीमाभन्दा धेरै विशिष्ट तथ्य हो, र सुधार सञ्जालको होइन, प्रमाणपत्र अधिकारीको हो। दुवै छेउ नियन्त्रण च्यानल सुरक्षा वा साझा सामग्रीमा सहमत नभए पासवर्ड रिसेट गर्दा केही बदलिँदैन, किनकि कुनै पनि प्रमाण जाँचिनुअघि नै बहिष्कार हुन्छ।
प्रमाणले साँच्चै समर्थन गर्ने एउटा कुरा बदल्नुहोस्, त्यसपछि त्यही प्रोफाइल त्यही अन्तिम बिन्दुमा दोहोर्याउनुहोस्। जडान अघि बढ्यो भने पहिलो नयाँ घटना सुरक्षित राख्नुहोस्, किनकि त्यो घटना नयाँ समस्या होइन, अनुसन्धानको अर्को चरण हो।
grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3
विन्डो लम्ब्याउँदा साँच्चै के बदलिन्छ
साठी सेकेन्ड क्लाइन्टको ह्यान्डशेक विन्डो हो, र समुदाय क्लाइन्ट सन्दर्भ त्यसलाई समायोजन गर्ने विकल्पको दस्तावेजीकरण गर्छ। यसलाई बढाउँदा क्लाइन्ट हार मान्नुअघि बढी समय कुर्छ। यसले अनुपस्थित सेवा प्रकट गर्दैन र अस्वीकृत प्याकेटलाई स्वीकार्य बनाउँदैन।
ढिलो लिंक वा भारी भार भएको सर्भरमा लामो विन्डोको वैध उपयोग छ, र आदानप्रदान बिस्तारै अघि बढिरहेको छ, बिल्कुलै हुँदैन भन्ने होइन भन्ने प्रमाण भएपछि यसलाई प्रयास गर्न लायक छ। पहिले प्रयास गर्दा त्यही निदानलाई अझै एक मिनेट ढिलो बनाउँछ र समयरेखा पढ्न गाह्रो बनाउँछ। समयरेखाले अघि बढेर रोकिने आदानप्रदान देखाए विन्डो भारको लक्षण हो, पहुँचको होइन।