ऑफ़िस LAN पर VPN क्लाइंट हर जवाब क्यों खो देता है
ऑफ़िस LAN पर और उसी सबनेट के एक टनल पर मौजूद लैपटॉप गलत इंटरफ़ेस से जवाब देता है। ढीला रिवर्स-पाथ फ़िल्टरिंग इस ख़ामोशी को समझाता है।
एक लैपटॉप ईथरनेट से ऑफ़िस के /24 पर बैठा है और उसी /24 में रहने वाले OpenVPN सर्वर से भी जुड़ता है। एक सहकर्मी टनल पते पर पिंग करता है; अनुरोध स्पष्ट रूप से पहुँचता है, और कुछ भी वापस नहीं जाता। टनल का लॉग साफ़ है और ब्राउज़िंग अब भी चलती है, इसलिए टनल गलत संदिग्ध है। प्राप्त करने वाली मशीन पर IPv4 स्रोत सत्यापन पैकेट को कुछ भी पढ़ने से पहले फेंक देता है।
पैकेट पढ़े जाने से पहले ही फेंका जाता है
स्रोत सत्यापन हर आने वाले पैकेट के बारे में एक सवाल पूछता है: अगर यह होस्ट उस स्रोत को जवाब देता, तो क्या जवाब उसी इंटरफ़ेस से बाहर जाता जिस पर से पैकेट अभी आया है? जब जवाब नहीं होता, तो कर्नेल पैकेट को आते ही फेंक देता है। न कोई सॉकेट और न कोई फ़ॉरवर्डिंग पथ इसे कभी देखता है, इसीलिए टनल पर किया गया कैप्चर अब भी ऐसा अनुरोध दर्ज करता है जो एप्लिकेशन को कभी नहीं मिलता।
यहाँ क्लाइंट अपनी टनल पर 10.66.0.9 रखता है, और OpenVPN सर्वर ऑफ़िस प्रीफ़िक्स के भीतर 192.168.80.10 पर जवाब देता है। 192.168.80.25 पर एक सहकर्मी टनल पते पर पिंग करता है, इसलिए अनुरोध LAN पार करता है, सर्वर उसे टनल में भेजता है, और वह ऑफ़िस के स्रोत पते के साथ क्लाइंट के टनल इंटरफ़ेस पर पहुँचता है। उस मशीन की राउटिंग तालिका में ऑफ़िस प्रीफ़िक्स ईथरनेट डिवाइस का है, टनल का नहीं। सत्यापन आगमन इंटरफ़ेस की तुलना रूट से करता है, असंगति पाता है और पैकेट छोड़ देता है, इसलिए सहकर्मी पूरा नुकसान देखता है जबकि दोनों सिरे स्वस्थ टनल की सूचना देते हैं।
दर्पण दिशा का भी वही रूप है: जब क्लाइंट ऑफ़िस की ओर शुरू करता है, तो उसी कारण से ऑफ़िस की ओर जवाब छोड़े जा सकते हैं। केवल एक दिशा में जाँचा गया सुधार आमतौर पर दूसरी टिकट बनकर लौटता है।
किसी भी sysctl को छूने से पहले लागू मोड साबित करें
डिस्ट्रीब्यूशन के डिफ़ॉल्ट पर भरोसा करने के बजाय प्रभावी मान पढ़ें, क्योंकि प्रति-इंटरफ़ेस सेटिंग निर्णय का आधा ही है। लागू मोड इंटरफ़ेस मान और all मान में से ऊँचा है, इसलिए टनल इंटरफ़ेस पर शून्य तब तक कुछ नहीं कहता जब तक all एक है। सख़्त मोड का निर्णय राउटिंग निर्णय है, इसलिए वही खोज चलाएँ जो कर्नेल चलाता है और उसके जवाब की तुलना उस इंटरफ़ेस से करें जिस पर पैकेट वास्तव में आया।
tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filterफिर त्रुटि काउंटर देखते हुए पिंग दोहराएँ। कैप्चर के पहले से दिख रहे अनुरोध के बगल में बढ़ता आँकड़ा इसी फेंकने का हस्ताक्षर है, किसी गुम रूट का नहीं। वहाँ रहते हुए मंगल ग्रही पैकेट लॉगिंग चालू करें, ताकि कर्नेल उस स्रोत और इंटरफ़ेस का नाम बताए जिसे उसने ठुकराया। मिलकर वे साइफ़र, फ़ायरवॉल और गुम iroute को व्याख्या के रूप में बाहर कर देते हैं।
कुछ बदलने से पहले आधार रेखा लिख लें: दोनों मान, वह डिवाइस जो खोज ने चुना, और वह काउंटर जिसे आप देख रहे थे। यही रिकॉर्ड बाद में बताता है कि बदलाव ने वह किया या नहीं जो आप सोचते हैं।
हर rp_filter मोड वास्तव में क्या स्वीकार करता है
कर्नेल प्रति इंटरफ़ेस तीन मान दिखाता है, और ये एक ही नियम के तीन रंग नहीं हैं। शून्य जाँच बंद कर देता है। एक सख़्त है और माँगता है कि स्रोत आगमन इंटरफ़ेस से होकर वापस राउट हो। दो ढीला है और केवल इतना माँगता है कि तालिका में स्रोत तक कोई रूट मौजूद हो, चाहे वह कहीं भी इंगित करे।
| Value | Name | Accepts | Still rejects |
|---|---|---|---|
| 0 | off | any source at all | nothing on this check |
| 1 | strict | a source routed back out the arrival interface | a source whose route points elsewhere |
| 2 | loose | a source with any route in the table | a source with no route at all |
यहाँ मायने वाली पंक्ति ढीली है, और वह जो वह ठुकराती रहती है। आपकी तालिका में कहीं भी राउट होने योग्य नक़ली स्रोत निकल जाता है, जबकि बिना किसी रूट वाला स्रोत अब भी अस्वीकार होता है। लैपटॉप पर यह संकीर्ण छूट है; दूसरों का ट्रैफ़िक फ़ॉरवर्ड करने वाले राउटर पर यह चौड़ी है। मोड होस्ट का है, इसलिए वही संख्या दो जगहों पर अलग वज़न रखती है।
इस टोपोलॉजी को कौन-सी पंक्ति चाहिए, यह आदत से नहीं, तालिका से निकलता है। पैकेट वैध है और उसका स्रोत राउट होने योग्य है, इसलिए ढीला उसे स्वीकार करता है और सख़्त नहीं। इस मामले में कुछ भी शून्य नहीं माँगता, और शून्य चुनना ऐसी जाँच हटा देता जो यहाँ कुछ भी खर्च नहीं करती।
अस्पष्टता हटाने वाला सबसे छोटा बदलाव चुनें
ढीला मोड सबसे छोटा उपयुक्त बदलाव है, और यह कठोरता में सच्ची कमी है, कोई हानिरहित स्विच नहीं। जब भी टोपोलॉजी अनुमति दे, बेहतर विकल्प मौजूद है: ओवरलैप हटाएँ, और अस्पष्टता ग़ायब हो जाती है।
जहाँ ऑफ़िस प्रीफ़िक्स की ज़रूरत केवल ईथरनेट पर है, उसे उन रूटों से हटा दें जो प्रोफ़ाइल खींचती है और पता एक ही रास्ते से पहुँचने योग्य हो जाता है। जब दोनों रास्तों को सचमुच साथ रहना हो, तो हर इंटरफ़ेस पर सत्यापन ढीला करने के बजाय नीति-नियम से स्रोत और डिवाइस को पिन करें। यह मशीन पर बाक़ी सबके लिए सख़्त फ़िल्टरिंग रखता है और अपवाद वहाँ दर्ज करता है जहाँ अगला इंजीनियर उसे खोजेगा।
आप कोई भी रास्ता चुनें, उसे जीवंत कमांड में नहीं, sysctl drop-in में दर्ज करें। all और default कुंजियाँ साथ सेट करें, ताकि फिर से जुड़ना सख़्त मोड चुपचाप बहाल न कर सके।
# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --systemढीला मोड क्या छोड़ता है, और कहाँ
ढीला मोड अब भी ऐसे स्रोत को ठुकराता है जहाँ कोई रूट पहुँच ही न सके, और संयोग से राउट होने योग्य नक़ली स्रोत को ठुकराना बंद कर देता है। लैपटॉप पर यह संकीर्ण छूट है। जो डिवाइस अपना न हो ऐसा ट्रैफ़िक फ़ॉरवर्ड करता है, वहाँ वही चुनाव कहीं ज़्यादा चौड़ा है। इसलिए वही सेटिंग इस पर निर्भर दो बहुत अलग अर्थ रखती है कि वह कहाँ चलती है।
दूसरों के लिए ट्रैफ़िक फ़ॉरवर्ड करने वाले होस्ट पर जाँच पूरी तरह बंद करना ही वह एकमात्र सुधार है जिससे बचना चाहिए। शून्य उस सत्यापन को फेंक देता है जिसे ढीला मोड सावधानी से रखता है। अगर होस्ट दूसरों के लिए फ़ॉरवर्ड करता है, तो इसके बजाय पिछले खंड के नीति-नियम विकल्प की वकालत करें।
एक टिप्पणी छोड़ें जिसमें दोनों इंटरफ़ेस, ओवरलैप करता प्रीफ़िक्स और वह सटीक जाँच हो जो अब सफल होती है। यह अगले इंजीनियर के लिए उस पंक्ति से अधिक उपयोगी है जो कहती है कि फ़िल्टरिंग समायोजित की गई।