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 स्थापित संघटनेचा प्रोटोकॉल, मोड आणि अल्गोरिदम दाखवते, आणि विसंगती असल्यास काहीही स्थापित होत नाही, जे इच्छित संरक्षणाशिवाय उभे राहणार्‍या बोगद्यापेक्षा स्वच्छ अपयश आहे.

प्रमाणीकरण अपयश, निवडकर्त्यांची व्याप्ती आणि मार्गक्रमण दोष या निवडीपासून वेगळे ठेवा. ते वेगवेगळी लक्षणे देतात, आणि निवडकर्त्याच्या समस्येसाठी प्रोटोकॉलला दोष देणे हे कारणाशिवाय हॅश बदलत एक दिवस घालवण्याचा विश्वासार्ह मार्ग आहे.