कार्यालयाच्या 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सैल मोड काय सोडतो, आणि कुठे
सैल मोड अजूनही असा स्रोत नाकारतो ज्यापर्यंत कोणताही मार्ग पोहोचू शकत नाही, आणि योगायोगाने राउट होण्यायोग्य बनावट स्रोत नाकारणे बंद करतो। लॅपटॉपवर ही अरुंद सवलत आहे। स्वतःचा नसलेला रहदारी पुढे पाठवणाऱ्या उपकरणावर तोच निवड खूप रुंद आहे। म्हणून तेच सेटिंग कुठे चालते यावर अवलंबून दोन अतिशय वेगळे अर्थ वाहते।
इतरांसाठी रहदारी पुढे पाठवणाऱ्या होस्टवर पडताळणी पूर्णपणे बंद करणे ही टाळावी लागणारी एकमेव दुरुस्ती आहे। शून्य ती पडताळणी टाकून देते जी सैल मोड काळजीपूर्वक ठेवतो। होस्ट इतरांसाठी पुढे पाठवत असेल, तर त्याऐवजी मागील विभागातील धोरण-नियम पर्यायाची बाजू घ्या।
दोन इंटरफेस, ओव्हरलॅप होणारा प्रीफिक्स आणि आता यशस्वी होणारी नेमकी चाचणी यांची नावे असलेली टीप ठेवा। फिल्टरिंग समायोजित केले अशा ओळीपेक्षा हे पुढील अभियंत्यासाठी अधिक उपयुक्त आहे।