AH कि ESP? प्याकेटले के सुरक्षित गर्नुपर्छ भन्ने कुराबाट निर्णय गर्नुहोस्

दुई IPsec प्रस्तावले एउटै SHA-आधारित अखण्डता एल्गोरिदम उल्लेख गर्दै पनि फरक सुरक्षा प्रोटोकल माग्न सक्छन्; AH र ESP एउटै प्रमाणीकरण सेटिङका दुई हिज्जे होइनन्। पहिले प्रोटोकल, त्यसपछि यसका एल्गोरिदम, त्यसपछि यसको मोड पढ्नुहोस्, र अधिकांश अस्पष्टता हराउँछ। AH ले प्याकेट प्रमाणित गर्छ, यात्रामा नबदलिने IP हेडर फिल्डसमेत, जबकि ESP ले आफूले समेटेको सामग्री प्रमाणित र इन्क्रिप्ट गर्छ र बाहिरी हेडर यथावत् राख्छ। यही भिन्नताले कुनै पनि ह्यास नामभन्दा बढी तैनाथी निर्धारण गर्छ।

AH ले के ढाक्छ जो ESP ले ढाँक्दैन

AH ले अखण्डता, डेटाको स्रोत प्रमाणीकरण र आफैंले परिभाषित गरेको पुनरावृत्ति-रोकथाम सेवा दिन्छ, र कुनै गोपनीयता दिँदैन। यसको दायरामा माथिल्लो तहको डेटा र यसका नियमले अपरिवर्तनीय मान्ने IP हेडर फिल्ड पर्छन्, अर्थात् ESP ले ढुवानी मोडमा बाहिर राख्ने भाग नै। जब आवश्यकताले IP हेडर आफैं प्रमाणित गर्नुपर्छ भन्छ, त्यसको जवाफ दिने प्रोटोकल AH हो।

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

NAT ले छनोटलाई बाधामा बदल्छ

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

छ भने AH बाहिरिन्छ, र कुरा ESP र यसको एल्गोरिदम छनोटमा जान्छ। यो प्राथमिकता होइन बाधा हो, त्यसैले यसको स्थान निर्णयको अन्त्यमा होइन, सुरुमा हुन्छ।

मोडले प्रश्नलाई गुणन गर्छ

ESP ले ढुवानी मोडमा माथिल्लो तहको भार सुरक्षित गर्छ र IP हेडर यथावत् राख्छ; सुरुङ मोडमा भित्री IP हेडरसमेत पूरै भित्री प्याकेट समेटेर सुरक्षित गर्छ। AH सँग पनि त्यही दुई मोड छन्, त्यसैले AH वा ESP कुनै पनि एल्गोरिदम छान्नुअघि वास्तवमा चार संयोजन हुन्।

संयुक्त मोडका ESP एल्गोरिदमले त्यसपछि दोस्रो प्रोटोकलबिना अखण्डता टुंगो लगाउँछन्। AES-GCM र ChaCha20-Poly1305 एउटै संरचनामा प्रमाणीकरण र इन्क्रिप्शन गर्छन्, त्यसैले माथि AH थप्दा केही पाइँदैन तर अर्को हेडर र अर्को वार्ता खर्च हुन्छ। वास्तुकलाले AH र ESP सँगै अनुमति दिन्छ, र व्यावहारिक प्रश्न हो तपाईंको गेटवे र संस्करणले यो संयोजन समर्थन गर्छ कि गर्दैन र पछि कसैले यसको मर्मत गर्न सक्छ कि सक्दैन।

केवल-AH का लागि इमानदार विकल्प

केवल-अखण्डता ESP प्रकारले एल्गोरिदम राख्छ र इन्क्रिप्शनको दाबी नक्कली नबनाई छोड्छ, र NAT पार गर्छ। यदि पुरानो डिजाइनले गोपनीयताबिना प्रमाणीकरण चाहिएको हुनाले AH प्रयोग गरेको थियो भने, त्यही प्रकार सिधा अनुवाद हो, टिप्पणी टाँसिएको इन्क्रिप्टेड सुरुङ होइन।

प्रस्तावमा ESP देख्नु पनि इन्क्रिप्शनको प्रमाण होइन। इन्क्रिप्शन एल्गोरिदम पढ्नुहोस्: NULL प्रविष्टिको अर्थ केवल अखण्डता, र संयुक्त-मोड प्रविष्टिको अर्थ दुवै।

तीन प्रश्नमा निर्णय गर्नुहोस्

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

त्यसपछि स्वीकारिएको जाँच्नुहोस्, प्रस्ताव गरिएको होइन। ip xfrm state ले स्थापित संघको प्रोटोकल, मोड र एल्गोरिदम देखाउँछ, र बेमेल भएमा केही पनि स्थापित हुँदैन, जुन अभिप्रेत सुरक्षाबिना उठ्ने सुरुङभन्दा सफा असफलता हो।

प्रमाणीकरण असफलता, छनोटकर्ताको दायरा र रुटिङ त्रुटिलाई यो छनोटबाट अलग राख्नुहोस्। तिनले फरक लक्षण दिन्छन्, र छनोटकर्ताको समस्याका लागि प्रोटोकललाई दोष दिनु कारणबिना ह्यास बदल्दै एक दिन बिताउने भरपर्दो तरिका हो।