IPsec नीति आपके स्थानीय ट्रैफ़िक को निगल रही है: इसे कैसे पहचानें

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

चयनक बदलने से पहले प्रवाह पर चलें

असफल अनुरोध से शुरू करें और चार मान लिखें: वह स्रोत पता जो मशीन उपयोग करती है, सटीक गंतव्य, वह मार्ग जो कर्नेल चुनता है, और वह नीति जो इस जोड़ी से मेल खाती है।

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

यह कुछ भी संपादित करने से पहले करें, क्योंकि दिलचस्प स्थिति वह स्थानीय सबनेट है जो कनेक्शन द्वारा संरक्षित निजी रेंज से ओवरलैप करता है। 192.168.0.0/16 जैसे परिचित उपसर्ग कई नेटवर्क में दिखते हैं, और उनमें से किसी एक के लिए लिखा चयनक आपका चुपचाप कवर कर सकता है।

स्थानीय के तीन प्रकार जो अलग व्यवहार करते हैं

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

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

उपयोगी आदत यह है कि स्थिति को ज़ोर से नाम दें: क्या यह पैकेट मुझसे आता है, मेरे लिंक की ओर जाता है या मुझमें से गुज़रता है? हर जवाब सीमित करने की अलग जगह की ओर इशारा करता है। स्थिति लिख लेना अगले व्यक्ति को भी वही काम दोबारा करने से रोकता है।

जब संरक्षित रेंज पूरा निजी स्थान हो, तो तीनों स्थितियाँ एक साथ उसमें आ सकती हैं, और लक्षण ऐसी मशीन बन जाता है जो टनल के अंतिम बिंदु के सिवा कहीं नहीं पहुँचती।

स्थापित नीति पढ़ें, फ़ाइल नहीं

कॉन्फ़िगरेशन फ़ाइलें मंशा बताती हैं; कर्नेल वे नीतियाँ रखता है जो वास्तव में मेल खाती हैं। दोनों दिखाएँ और बेमेल को पहली खोज मानें।

ये आदेश गंतव्य के लिए चुना गया मार्ग और हर दिशा में स्थापित नीतियाँ दिखाते हैं:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

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

चयनक सीमित करें या गंतव्य से बचें

दो समर्थित मरम्मतें हैं और वे अलग सवालों का जवाब देती हैं। चयनक को सीमित करना कहता है कि यह कनेक्शन केवल छोटी रेंज की रक्षा करता है, जो सही है जब चौड़ी रेंज गलती थी। बचाव जोड़ना कहता है कि यह विशिष्ट गंतव्य कभी संरक्षित नहीं होना चाहिए, जो सही है जब संरक्षित रेंज वाकई चौड़ी है और एक गंतव्य अपवाद है।

जब कर सकें पहला चुनें, क्योंकि छोटे चयनक पर सोचना आसान है और वह कनेक्शन की परिभाषा में दिखता है। जब चौड़ी रेंज जानबूझकर हो और अपवाद कोई एक होस्ट या सबनेट हो जिसका नाम आप ले सकें, तो दूसरा चुनें।

दोनों उस कॉन्फ़िगरेशन के हैं जिसके पास कनेक्शन है। हाथ से जोड़ा गया रनटाइम नियम अगले पुनः कनेक्शन पर गायब हो जाता है, और खराबी उस पल लौटती है जब किसी को वह अस्थायी उपाय याद नहीं रहता।

पुनः स्थापना में टिकने वाले अपवाद

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

ये दो जाँचें पुष्टि करती हैं कि अपवाद बचा और सुरक्षा नहीं:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

फिर टनल को जानबूझकर डिस्कनेक्ट और पुनः कनेक्ट करें, और दोनों दोहराएँ। जो अपवाद पुनः कनेक्शन से पहले काम करता है और बाद में विफल होता है, वह गलत परत पर लागू हुआ है, और यही इस समस्या के लौटने का सबसे आम तरीका है।