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

खाम पहिले आउँछ

हरेक सुरुङ प्याकेट प्रोटोकलको आफ्नै हेडरबाट सुरु हुन्छ: सन्देश प्रकार, कुञ्जी पहिचानकर्ता र बाइट-स्ट्रिम यातायातमा प्याकेट कहाँ अन्त्य हुन्छ भनी देखाउने लम्बाइ उपसर्ग। त्यो खाम विश्लेषण नगर्ने पाठकले अर्को फिल्ड कहाँ सुरु हुन्छ थाहा पाउन सक्दैन।

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

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

विश्वसनीयता तह प्रोटोकलकै हो

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

फाइदा यो हो कि बाह्य यातायात UDP हुँदा पनि TLS ह्यान्डसेकले विश्वसनीय वाहक पाउँछ। लागत यो हो कि एउटा डेटाग्रामले त्यो कुराकानीको थोरै भाग मात्र राख्न सक्छ, त्यसैले यसलाई स्वतन्त्र TLS रेकर्डका रूपमा लिँदा बेतुकता उत्पन्न हुन्छ। पुनःजोड प्रोटोकल तहमै हुनुपर्छ। त्यसैले कैद गरिएको प्याकेट पूरा ह्यान्डसेक चरणजस्तो विरलै देखिन्छ।

बाह्य यातायातलाई TCP मा बदल्दा यो तह हट्दैन। विश्वसनीय यातायात भन्नाले प्रोटोकल स्तरमा कम पुनःप्रेषण, फ्रेमिङ हराउनु वा ट्राफिक HTTP हुनु होइन।

डेटा प्याकेटले फरक ढाँचा प्रयोग गर्छन्

सत्र अस्तित्वमा आएपछि उपयोगी पेलोड आन्तरिक IP प्याकेट वा Ethernet फ्रेम बोक्ने डेटा सन्देशका रूपमा आउँछ। तिनीहरू आफ्नै कुञ्जी र आफ्नै प्रशोधनले सुरक्षित हुन्छन्, र TLS पुस्तकालयले स्वीकार गर्ने कुनै पनि अर्थमा ती TLS अनुप्रयोग रेकर्ड होइनन्।

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

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

HTTPS प्रोक्सीले किन सहयोग गर्न सक्दैन

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

बाइट वा डेटाग्राम व्याख्या नगरी पठाउने पारदर्शी फर्वार्डरले काम गर्न सक्छ, यदि त्यसले प्रवाह पुनःलेखन वा पुनःजोड गर्दैन। कुनै पनि मध्यस्थबारे सोध्नुपर्ने प्रश्न यो हो कि त्यसले वास्तविक यातायात र फ्रेमिङ पठाउँछ कि कतै TLS समर्थन गर्छ। प्रोक्सी नियममा साँझ बिताउनुअघि यो सोध्नुहोस्। यहाँका अधिकांश असफलता छुटेको सेटिङ होइन, संरचनागत हुन्।

ट्रेसलाई सही रूपमा पढ्ने

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

कुञ्जी-विधिका ऐतिहासिक विवरणहरू प्रोटोकल कागजातमा दिइएको संस्करणले अझै सबै पुरानो ढाँचा समर्थन गर्छ भन्ने अर्थ लाग्दैन। तपाईंले चलाउनुभएको संस्करण जाँच्नुहोस्, त्यसपछि चीजहरू पहिले कसरी काम गर्थे भनी वर्णन गर्ने अनुच्छेदमा अपेक्षा नबनाउनुहोस्।

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