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