OpenWrt पॉलिसी राउटिंग: स्थानिक DNS पकडणारी चेन

LAN मधील क्लायंट टनेलमधून सोडवतात आणि राउटरचे स्वतःचे लुकअप शांतपणे तसे करत नाहीत। पॅकेज अपडेट, वेळ सिंक आणि डायनॅमिक DNS सर्व सामान्य अपलिंकमधून बाहेर पडतात, तर प्रत्येक फॉरवर्ड केलेली क्वेरी VPN घेते, आणि इंटरफेसमध्ये दोन वेगळे मार्ग आहेत असे काहीही सुचवत नाही। स्पष्टीकरण पॉलिसीमधील बग नाही तर कोणता हुक पॅकेट पाहतो हा प्रश्न आहे। दोन फ्लो, एक रिझॉल्व्हर पत्ता, आणि त्यापैकी फक्त एकच राउटर ओलांडतो। त्यांना वेगळे करणे हाच संपूर्ण उपाय आहे।

दोन फ्लो, एक रिझॉल्व्हर पत्ता

पहिला फ्लो लोक कल्पना करतात तो आहे। क्लायंट राउटरच्या रिझॉल्व्हरला विचारतो, रिझॉल्व्हर वरच्या दिशेने फॉरवर्ड करतो, आणि ते फॉरवर्ड केलेले पॅकेट बाहेर जाताना राउटरमधून जाते। ते पॅकेट फॉरवर्ड केलेला ट्रॅफिक पाहणाऱ्या कोणत्याही गोष्टीला दिसते।

दुसरा फ्लो कधीही कुठूनही येत नाही। राउटर तो तयार करतो, म्हणून येणारे पॅकेट नाही आणि जुळवण्यासाठी फॉरवर्डिंग पायरीही नाही।

दोन्ही एकाच रिझॉल्व्हर पत्त्याला लक्ष्य करू शकतात, आणि म्हणूनच फरक चुकवणे सोपे आहे। तेच गंतव्य, वेगळा उगम, वेगळी चेन। उगम दिसताच उर्वरित निदान मागे येते।

फॉरवर्ड केलेले आणि स्थानिकपणे तयार केलेले पॅकेट वेगळ्या पद्धतीने प्रवेश करतात

फॉरवर्ड केलेला ट्रॅफिक दुसऱ्या इंटरफेसवरून आल्यावर मूल्यांकन केला जातो। पॉलिसी राउटिंग पॅकेज ते prerouting चेन म्हणून उघड करतात, आणि तिथे ठेवलेला नियम राउटर ओलांडणारे प्रत्येक पॅकेट पाहतो। म्हणूनच क्लायंटचे लुकअप पॉलिसी वर्णन करते तसेच वागतात, आणि म्हणूनच राउटर त्याकडे दुर्लक्ष करतो। नियम चुकीचा नाही, तो फक्त राउटर कधीही न पोहोचणाऱ्या हुकला जोडलेला आहे। तो हलवा, आणि तोच जुळणी काम करू लागते।

स्थानिकपणे तयार केलेला ट्रॅफिक राउटरवरील प्रक्रियेने तयार होतो आणि त्याऐवजी आउटपुट मार्गात प्रवेश करतो। राउटरच्या स्वतःच्या निर्णयाने त्याचे राउटिंग होते आणि पॉलिसी ती चेन व्यापत असेल तरच तो पॉलिसीशी भेटतो। जुळवण्यासाठी येणारा इंटरफेस नाही आणि निरीक्षण करण्यासाठी फॉरवर्डिंग निर्णयही नाही।

हे पॅकेट कुठे जन्मतात याचे गुणधर्म आहे, कोणत्याही विशिष्ट पॅकेजचे नाही। एका चेनसाठी लिहिलेल्या नियमाला दुसऱ्याबद्दल साधारणपणे मत नसते। कोणतेही नियम ट्यूनिंग ते बदलत नाही।

आउटपुट चेन निवडा, मग जुळणी अरुंद करा

उपाय म्हणजे तोच हेतू आउटपुट चेनलाही जोडणे, किंवा राउटरच्याच क्वेरी महत्त्वाच्या असतील तर नियम तिथे हलवणे। पॉलिसी राउटिंग पॅकेजवर बांधलेल्या OpenWrt सेटअपमध्ये याचा अर्थ नियमाच्या चेन सेटिंगमध्ये prerouting ऐवजी output निवडणे। दोन्ही लोकसंख्यांना कव्हरेज हवे असेल तर दोन्ही नियम ठेवा।

मग नियम कशाशी जुळतो ते अरुंद करा। रिझॉल्व्हर प्रत्यक्षात वापरत असलेल्या पोर्टवरील गंतव्य रिझॉल्व्हर पत्ते, राउटर तयार करतो ते सर्व टनेलमध्ये पाठवण्यापेक्षा खूप लहान निर्णय आहेत।

दोन्ही चेन व्यापणारा एक नियम लिहिण्याचा प्रयत्न करण्याऐवजी दोन्ही नियम स्पष्ट ठेवा। वेगळे नियम वाचायला सोपे असतात, आणि डीबग करताना क्लायंट ट्रॅफिकला त्रास न देता राउटरचा मार्ग बंद करू देतात। ते काउंटर एका वेळी एक अर्थपूर्ण करतात।

टनेलची स्वतःची वाहतूक नियमाबाहेर ठेवा

टनेलचे बाह्य कनेक्शनही राउटर तयार करतो। स्थानिकपणे तयार केलेला सर्व ट्रॅफिक टनेलमध्ये पाठवणारा नियम टनेलला त्याच्याच मार्गाने राउट करेल, आणि ते अजिबात वर येणार नाही।

व्यवस्थापन प्रवेश हा दुसरा बळी आहे। राउटरमधून उगवलेली प्रशासकीय सत्रे किंवा त्यांना दिलेली उत्तरे खूप रुंद स्थानिक नियमामुळे टनेलमध्ये ओढली जाऊ शकतात आणि LAN वरून पोहोचता येणार नाहीत असे होऊ शकते।

टनेलचा शेवटचा बिंदू जुळणीतून वगळा, आणि नियम रिझॉल्व्हर पत्त्यांपुरता मर्यादित ठेवा। ते DNS गरजेसाठी पुरेसे आहे आणि त्याबद्दल विचार करण्यासाठी पुरेसे लहान आहे।

एक नाही, दोन्ही लोकसंख्यांची चाचणी करा

राउटर स्वतःची क्वेरी करताना पहा आणि कोणत्या इंटरफेसने ती वाहिली ते नोंदवा। LAN होस्टवरून लुकअप पुन्हा करा आणि त्याने घेतलेला मार्ग नोंदवा। पॉलिसी नियमांवरील काउंटर अंदाज न लावता दोन्ही उत्तरे दिसू करतात।

निकालांना दोन स्वतंत्र शोध म्हणून घ्या। टनेलमधून सोडवणारा क्लायंट राउटरबद्दल काहीही सांगत नाही, आणि बरोबर सोडवणारा राउटर दुसऱ्या श्रोत्यावरील क्लायंटबद्दल काहीही सांगत नाही। बदल नोंदीत ते वेगळ्या ओळी म्हणून लिहा।

पोर्टही तपासा: गंतव्य पोर्ट 53 शी जुळणारा नियम 853 वर DNS over TLS किंवा HTTPS अंतिम बिंदूमधून पोहोचणारा रिझॉल्व्हर चुकवतो। कॉन्फिगर केलेला upstream प्रत्यक्षात वापरत असलेल्या वाहतुकीशी जुळवा, आणि गळती योग्य कारणाने बंद होते।