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

एक मार्ग दुसऱ्यासाठी पॅकेट फॉरवर्ड करतो; दुसरा ते होस्टकडेच पोहोचवतो।

होस्टला उद्देशून पाठवलेले पॅकेट होस्टमध्येच राहते

दूरस्थ क्लायंट होस्टकडे असलेल्या पत्त्यावर IP पॅकेट पाठवतो। राउटिंग त्या पॅकेटबद्दल एक प्रश्न विचारते: हे गंतव्य स्थानिक आहे का? होस्टकडे असलेला प्रत्येक पत्ता स्थानिक राउटिंग तक्त्यात दिसतो, आणि तो तक्ता मुख्य तक्त्यापूर्वी पाहिला जातो, त्यामुळे पॅकेट दुसऱ्या इंटरफेसने बाहेर जाण्याऐवजी होस्टच्या स्वतःच्या स्टॅकमध्ये जाते। उत्तर स्थानिकपणे तयार होते, आणि चौकशी तिथूनच आली असल्याने ते टनेलमधून परत येते।

हेच संपूर्ण यंत्रणा आहे। कोणतेही फॉरवर्डिंग होत नाही, इंटरफेसच्या स्थितीत बदल सहभागी होत नाही, आणि विचाराधीन पत्ता इतर कोठूनही पोहोचण्यायोग्य असणे आवश्यक नाही।

ip_forward लागू का होत नाही

फॉरवर्डिंग त्या पॅकेट्सना नियंत्रित करते ज्यांना ज्या इंटरफेसवर आले त्यापेक्षा वेगळ्या इंटरफेसने बाहेर जायचे असते। होस्टलाच पिंग कधीही तो मार्ग घेत नाही: पॅकेट स्थानिकपणे वापरले जाते आणि उत्तर स्थानिकपणे तयार होते। म्हणून net.ipv4.ip_forward=0 सेट केल्याने येथे काहीच बदलत नाही, आणि फॉरवर्ड साखळीतील नियम तो रहदारी कधीही पाहत नाही। योग्य नियंत्रण इनपुट मार्गावर आहे, येणाऱ्या इंटरफेस किंवा स्रोताने मर्यादित।

म्हणूनच फॉरवर्डिंग बंद करणे आणि होस्ट वेगळा आहे असे गृहीत धरणे सुरक्षिततेची खोटी भावना निर्माण करते।

निर्णय घेतलेला स्थानिक तक्ता वाचा

ip rule show सामान्यतः शून्य प्राधान्याचा नियम सांगतो जो सर्व शोध प्रथम स्थानिक तक्त्याकडे पाठवतो, आणि ip route show table local होस्टचे स्वतःचे पत्ते स्थानिक व्याप्तीसह सूचीबद्ध करतो। त्या तक्त्यात प्रशासकीयदृष्ट्या बंद असलेल्या पण अजूनही संरचित इंटरफेसवरील पत्ते समाविष्ट आहेत। स्थिरपणे नेमलेले IPv4 पत्ते सामान्यतः दुवा तुटल्यावरही टिकतात, आणि म्हणूनच बंद केलेल्या पुलावर पिंग अजूनही यशस्वी होऊन ऑपरेटरला आश्चर्यचकित करू शकते।

IPv6 नेमके याच मुद्द्यावर वेगळे आहे। दुवा तुटल्यावर त्याचे पत्ते सामान्यतः मागे घेतले जातात, जोपर्यंत keep_addr_on_down सेट केलेले नाही। एक नियम दोन्हींना व्यापतो असे गृहीत धरण्याऐवजी कुटुंबांची तुलना करा।

सहकारी प्रत्यक्षात कुठपर्यंत पोहोचतो

खंडावरील राउटरच्या स्वतःच्या पत्त्यावरून आलेले उत्तर त्या खंडामागील यंत्रांबद्दल काहीही सांगत नाही। सहकारी या मार्गाने दुसऱ्या इंटरफेसामागील होस्टपर्यंत पोहोचू शकत नाही; तो फक्त राउटर स्वतःकडे असलेल्या पत्त्यांपर्यंत पोहोचतो। राउटरच्या पत्त्यावर पिंग करण्याऐवजी वेगळ्या LAN होस्टवर सेवा तपासणे हेच ठरवते की फॉरवर्डिंग अजिबात परवानगी आहे की नाही।

सहकारीला टनेल पत्त्यावर बांधलेल्या सेवांपर्यंत मर्यादित करणे हा इनपुट धोरणाचा प्रश्न आहे। टनेल इंटरफेसवर इच्छित सेवेला परवानगी द्या आणि ती वापरू शकणाऱ्या स्रोतांना मर्यादित करा, कारण पॅकेट खरोखर तिथे पोहोचते।

तुम्ही निवृत्त करू इच्छित असलेले पत्तेही तपासा। इंटरफेसवरून पत्ता काढणे जुन्या पत्त्यावर फायरवॉल नियमांची रास करण्यापेक्षा अधिक विश्वासार्ह आहे।

संबंधित लेख