आने वाला IPsec पीयर किसी प्रोफ़ाइल से मेल नहीं खाता? चार फ़ील्ड जाँचें

आपका पीयर बताता है कि सुरंग ऊपर है, आपकी ओर कोई सुरक्षा संबंध नहीं दिखता, और कॉन्फ़िगरेशन फ़ाइल में स्पष्ट रूप से मेल खाता कनेक्शन नाम है। ये तीनों कथन एक साथ सत्य हो सकते हैं। आने वाली बातचीत की तुलना चल रहे कॉन्फ़िगरेशन से होती है, पीयर के पते, उसकी प्रस्तुत पहचान और उसके प्रस्तावित ट्रैफ़िक के आधार पर। डिस्क पर पड़ी वह फ़ाइल जो कभी लोड नहीं हुई, अपेक्षित मान से न मेल खाने वाली पहचान, या एक प्रीफ़िक्स से हटी हुई चयनकर्ता जोड़ी — इनमें से हर एक मौन पैदा करता है। उत्तरदाता जिस क्रम में चलता है उसी क्रम में चारों फ़ील्ड-समूहों को देखें।

फ़ाइल से नहीं, पैकेट से शुरू करें

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

इसीलिए “कॉन्फ़िगरेशन सही दिखता है” कोई प्रमाण नहीं है। प्रश्न यह है कि चल रही सेवा ने क्या लोड किया है और इस प्रयास के लिए कौन-सी प्रविष्टि चुनी है। स्थिति सूची एक ही आदेश में उसका उत्तर देती है, जबकि संपादक बफ़र किसी दूसरे प्रश्न का उत्तर देता है। फ़ाइल को फिर बदलने से पहले सूची जाँचें।

पहला फ़ील्ड-समूह: वह परिभाषा जो वास्तव में लोड हुई है

चल रही स्थिति को उस उपकरण से जाँचें जो डेमन का स्वामी है: लोड किए गए कनेक्शनों की सूची देने वाला स्थिति आदेश, संपादक बफ़र नहीं। पुष्टि करें कि अपेक्षित प्रविष्टि मौजूद है, आपके इच्छित प्रारंभिक व्यवहार के लिए सक्षम है, और आपके अंतिम संपादन के बाद लोड हुई है। सहेजी गई पर फिर से लोड न की गई फ़ाइल “मैंने ठीक किया और कुछ नहीं बदला” का सबसे सामान्य कारण है।

यह भी पुष्टि करें कि सेवा कौन-सी फ़ाइल पढ़ती है। वितरण अलग-अलग होते हैं, और गलत समावेश में लिखा गया कनेक्शन अस्वीकार होने के बजाय चुपचाप अनदेखा कर दिया जाता है। यदि स्थिति सूची आपकी प्रविष्टि बिलकुल नहीं दिखाती, तो वाक्य-रचना से पहले समावेश पथ पर संदेह करें।

दूसरा फ़ील्ड-समूह: एंडपॉइंट पहचान नहीं हैं

पीयर जिस पते से जुड़ता है और जिस पहचान से प्रमाणीकरण करता है, वे अलग फ़ील्ड हैं। होस्टनाम, विशिष्ट नाम, कुंजी आईडी और पता — कॉन्फ़िगरेशन के अनुसार सभी IKE पहचान के रूप में काम कर सकते हैं, और उन्हें सार्वजनिक पते जैसा दिखने की ज़रूरत ही नहीं है।

एंडपॉइंट मिलान में NAT दृष्टि भी शामिल हो सकती है: नेटवर्क पर दिखने वाला पता उस पते से भिन्न हो सकता है जो पीयर समझता है कि उसके पास है। libreswan के कनेक्शन मॉडल में left और right दो प्रतिभागियों के लेबल हैं, कोई निश्चित स्थानीय-दूरस्थ क्रम नहीं, इसलिए किसी दूसरी साइट का काम करता कॉन्फ़िगरेशन कॉपी करके पते बदल देना भरोसेमंद अनुवाद नहीं है।

दोनों पक्षों की अपेक्षित पहचान और उसे सत्यापित करने वाला प्रमाण लिख लें। यदि ये दो पंक्तियाँ मेल नहीं खातीं, तो पतों की कोई भी मात्रा मिलान उत्पन्न नहीं करेगी।

तीसरा फ़ील्ड-समूह: जिस ट्रैफ़िक की रक्षा होती है

चयनकर्ता आंतरिक स्रोत और गंतव्य श्रेणियाँ, उनका पता-परिवार और कोई भी प्रोटोकॉल या पोर्ट प्रतिबंध बताते हैं। एक होस्ट पते के लिए प्रस्ताव पूरे सबनेट के लिए वही अनुरोध नहीं है, और सबनेट के लिए कॉन्फ़िगर किया गया उत्तरदाता उसे अस्वीकार या सीमित कर सकता है।

जब दोनों सिरे मेल नहीं खाते, तो हर चयनकर्ता को चौड़ा करने के बजाय दोनों दृष्टिकोणों से इच्छित प्रवाह की तुलना करें। हर प्रशासक से पूछें कि वह किस प्रवाह की रक्षा करने का दावा करता है, फिर दोनों उत्तरों की तुलना करें। असंगति आमतौर पर एक ओर होस्ट प्रीफ़िक्स और दूसरी ओर सबनेट होती है। जो सुरंग अब सब कुछ सुरक्षित करने के कारण मेल खाती है वह अलग सुरक्षा निर्णय है, और ऐसा जिसे किसी ने स्वीकृत नहीं किया।

चौथा फ़ील्ड-समूह: आप एक कार्यान्वयन पढ़ रहे हैं

Libreswan, पुराना Openswan और strongSwan के प्रबंधन उपकरण, कॉन्फ़िगरेशन वाक्य-रचना और मिलान क्रम अलग-अलग हैं। एक का काम करता उदाहरण दूसरे की प्रोफ़ाइल-चयन प्राथमिकता या त्रुटि-शब्दावली के बारे में कुछ सटीक नहीं कहता, इसलिए इस होस्ट पर डेमन के दस्तावेज़ों से सत्यापित करें।

एक प्रयास को शुरू से अंत तक जोड़ें: आरंभकर्ता का स्रोत पता, प्रस्तुत पहचान और प्रस्तावित चयनकर्ता — उत्तरदाता के चयन संदेश और उसके द्वारा नामित लोड की गई प्रविष्टि के सामने। शून्य एनकैप्सुलेशन और डीकैप्सुलेशन काउंटर केवल यह कहते हैं कि देखे गए संबंधों ने वे पैकेट नहीं ढोए; वे प्रस्ताव अस्वीकार करने वाले एंडपॉइंट का नाम नहीं देते और यह साबित नहीं करते कि उस क्षण मेल खाती प्रविष्टि मौजूद थी।

समन्वित सुधार के बाद चुनी गई प्रोफ़ाइल और संबंध की पुष्टि करें, फिर वास्तव में अनुमत सेवा और उसका उत्तर-पथ आज़माएँ। प्रोफ़ाइल मिलान बातचीत को सक्षम करता है, और बातचीत अंतिम पहुँच-जाँच नहीं है।