VPN रूट या फ़ायरवॉल नियम: पैकेट कौन गिरा रहा है?

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

दो निर्णय, एक पैकेट, दो मालिक

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

फ़िल्टरिंग अलग है। Linux होस्ट पर netfilter हुक ट्रैफ़िक को इस आधार पर बाँटते हैं कि पैकेट किसके लिए है: आउटपुट मशीन छोड़ता है, इनपुट उस पर समाप्त होता है, फ़ॉरवर्ड उसके बीच से गुजरता है। जो गेटवे VPN क्लाइंट स्वीकार करता है और उन्हें LAN में रूट करता है, उसे फ़ॉरवर्ड पथ चाहिए, और यही वह श्रृंखला है जिसे अधिकांश डिफ़ॉल्ट कॉन्फ़िगरेशन खाली छोड़ देते हैं।

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

पढ़ें कि खोज ने वास्तव में क्या चुना

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

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

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

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

फ़िल्टरिंग हुक पर लागू होती है, रूट पर नहीं

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

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

क्लाइंट जिस रास्ते का उपयोग करता है उसी से एक प्रोब भेजें

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

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

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

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

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

हर बदलाव को वहाँ रखें जहाँ वह पुनः कनेक्ट के बाद टिके

ip route add से जोड़ा गया रूट तब तक जीवित रहता है जब तक इंटरफ़ेस नीचे न जाए। इसे इसके बजाय कनेक्शन प्रोफ़ाइल में सहेजें: NetworkManager कनेक्शन पर अतिरिक्त रूट स्वीकार करता है, और netplan उन्हें बूट के बीच रखता है। यही नियम क्लाइंट-साइड फ़ायरवॉल अपवाद पर भी लागू होता है, जो अगले रीलोड के बाद चला जाता है।

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

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