नेस्टेड WireGuard: मधला हॉप स्वतःच्या पोर्टवर उत्तर देऊ शकत नाही
मधला हॉप सर्व काही एका टनेलमध्ये पाठवतो तेव्हा त्याच्या येणाऱ्या सेवेची उत्तरे चुकीच्या मार्गाने बाहेर पडतात. इंटरफेसवरील स्रोत-पोर्ट नियम हे दुरुस्त करतो.
तीन WireGuard हॉप अशा नेटवर्कपर्यंत पोहोचतात ज्याला सार्वजनिक पत्ता नाही, आणि नंतर मधले यंत्र ज्या पोर्टवर ऐकायचे होते त्या पोर्टवर उत्तर देणे थांबवते. पुढचा टनेल अजूनही काम करतो, दूरचा होस्ट अजूनही प्रतिसाद देतो, आणि बाहेरून शांत झालेला फक्त मधला सर्व्हरच आहे. हे संयोजन गोंधळात टाकणारे आहे कारण ते स्वतःच केलेले आहे: मधला हॉप स्वतःच्या राउटिंग तक्त्याचे पालन करत आहे, आणि तक्ता त्याची उत्तरे चुकीच्या दिशेने पाठवतो।
मधल्या बॉक्सशी बोलण्यापर्यंत काम करणारी साखळी
एक उदाहरणात्मक साखळी घ्या: क्लायंट A UDP 500 वर सर्व्हर B पर्यंत पोहोचतो, आणि B UDP 500 वर सर्व्हर C कडे पुढे जातो. C फक्त आपल्या एकमेव सहकारीाच्या पत्त्यावरून रहदारी स्वीकारतो, ज्यामुळे तो पान बनतो आणि त्याचे वर्तन सोपे राहते. B पान नाही, आणि या बिघाडातील सर्व मनोरंजक गोष्ट तिथेच घडते।
हा फरक महत्त्वाचा आहे कारण पान आणि मधल्या भूमिका विरुद्ध दिशांना ओढतात. पान कोणत्याही परिणामाशिवाय सर्व काही एका टनेलमध्ये पाठवू शकते, कारण त्यावर दुसरे काही अवलंबून नाही. मधला हॉप एकाच वेळी क्लायंटसाठी टोक आणि दूरच्या बाजूकडे क्लायंट असतो, आणि या दोन कामांना वेगळे राउटिंग हवे असते।
उत्तर टनेलमधून का बाहेर पडते
B वर, C कडे तोंड असलेला इंटरफेस जुळणाऱ्या डीफॉल्ट मार्गासह AllowedIPs = 0.0.0.0/0 वाहतो. म्हणून B निर्माण करतो ते प्रत्येक पॅकेट त्या टनेलमध्ये जाते, जोपर्यंत अधिक विशिष्ट काही प्राधान्य घेत नाही.
A कडून B ला उद्देशित पॅकेट येते आणि स्वीकारले जाते, कारण B हे गंतव्य आहे आणि स्थानिक वितरण आधी होते. उत्तर हे A च्या सार्वजनिक पत्त्याकडे निर्देशित अगदी नवीन स्थानिकरित्या तयार केलेले पॅकेट आहे, आणि ते गंतव्य टनेलमधील डीफॉल्ट मार्गाशी जुळते. C ते प्राप्त करतो, त्या पत्त्याचा मालक नाही, आणि ते टाकून देतो.
लक्षण फायरवॉल समस्या किंवा की जुळत नसल्यासारखे वाचले जाते, आणि इथे दोन्हीपैकी काहीही खरे नाही. C कडे जाणाऱ्या टनेलवरील कॅप्चर उत्तरे चुकीच्या दिशेने जात असल्याचे दाखवते. ते एक निरीक्षण कितीही कॉन्फिगरेशन वाचण्यापेक्षा जास्त वेळ वाचवते, म्हणून की बदलायला सुरुवात करण्यापूर्वी ते लिहून ठेवा. ज्याने कॅप्चर पाहिले नाही तो टनेलचाच बिघाड झाला आहे असे गृहीत धरेल.
अरुंद दुरुस्ती: स्रोत पोर्टशी जुळणारे धोरण नियम
B च्या ऐकणाऱ्या सॉकेटमधून उत्तरे स्रोत पोर्ट 500 सह बाहेर पडतात. धोरण नियम त्याशी जुळू शकतो आणि ती पॅकेट सामान्य तक्त्याकडे परत पाठवू शकतो:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101धोरण नियम प्राधान्यक्रमाने पाहिले जातात, आणि मुख्य तक्ता 32766 वर असतो, म्हणून 100 वरचा नियम टनेलच्या डीफॉल्ट मार्गापूर्वी विचारला जातो. बाहेरून पोहोचण्यायोग्य राहणे आवश्यक असलेल्या प्रत्येक पोर्टसाठी एक नोंद जोडा आणि त्यापेक्षा जास्त काही नाही, जेणेकरून पुढे पाठवलेली रहदारी ज्या टनेलसाठी ती बांधली गेली तेच वापरत राहील.
या युक्तीची मर्यादा जाणून घ्या. sport निवडक स्थानिकरित्या तयार केलेल्या पॅकेटशी जुळतो, ज्यामुळे उत्तराची बाब नक्की समाविष्ट होते आणि B फक्त दुसऱ्यासाठी पुढे पाठवत असलेली रहदारी मुद्दाम समाविष्ट होत नाही. B च्या मागे होस्ट केलेल्या सेवेला अजूनही स्वतःचे उत्तर आवश्यक असते, आणि उलटे भासवल्यास अशी दुरुस्ती मिळते जी पहिल्या सेवेसाठी चालते आणि दुसऱ्यासाठी अयशस्वी होते.
नियमाला मालक द्या
प्रॉम्प्टवर टाइप केलेला नियम पुढच्या वेळी इंटरफेस पुन्हा तयार होताना नाहीसा होतो. WireGuard सेटअपमध्ये तो जिथे इंटरफेस तयार होतो आणि काढला जातो तिथे ठेवा:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100इंटरफेसचा मालक NetworkManager, वितरण हुक किंवा कंटेनर प्रवेशबिंदू असेल तर ती जोडी हाताने संपादित फाइलऐवजी त्या मालकाची असते. पुन्हा जोडल्यानंतर प्रभावी नियम तपासा, फक्त पहिल्या सुरुवातीनंतर नाही, कारण पहिली सुरुवात ही नेहमी चालणारी परिस्थिती आहे.
पर्यायांची प्रामाणिक तुलना करा
स्रोत-पोर्ट नियम चार मार्गांपैकी एक आहे, आणि त्यातील सर्वात अरुंद आहे. टनेल धोरणाला अजिबात स्पर्श न करण्याचा त्याचा फायदा आहे, म्हणून तो नंतरच्या बदलांमध्ये टिकतो. अरुंद दुरुस्त्या लागू होणे थांबल्यावर मोठ्याने अयशस्वी होतात, तर व्यापक अपवाद त्याचे कारण नाहीसे झाल्यानंतर बराच काळ शांतपणे काम करत राहतो. दोन वर्षांनी जेव्हा बॉक्सचा मालक दुसराच कोणी असेल तेव्हा हा फरक सौंदर्यापेक्षा जास्त महत्त्वाचा असतो.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
निवड केल्यानंतर दोन्ही टोकांकडून पडताळा. A कडून B च्या पोर्टवर कनेक्शन सुरू करा आणि थोडा वेळ व्यस्त ठेवा. B वर, कर्नेलला ip route get <address-of-A> sport 500 सारख्या गोष्टीने उत्तरमार्ग न्याय्य ठरवायला सांगा, आणि तो टनेलऐवजी WAN इंटरफेस सांगतो याची खात्री करा. त्यानंतर, C च्या मागील काहीतरी अजूनही साखळीतून उत्तर देत असल्याचे तपासा, जे अपवाद बायपास न होता अरुंदच राहिला हे सिद्ध करते. शेवटी, पोर्ट डिझाइन नोट्समध्ये नोंदवा, नाहीतर पुढचा ऑपरेटर हे दुसऱ्या सेवेवर पुन्हा शोधेल.