DNS रीडायरेक्टनंतर dnsmasq क्वेरी VPN मधून का बाहेर पडतात

LAN क्लायंट आपल्या VPN पर्यंत योग्यरीत्या पोहोचतो आणि तरीही त्याच्या DNS क्वेरी चुकीच्या वरच्या लिंकवर दिसतात. हे नेहमीच्या अर्थाने गळती नाही; राउटर क्वेरी पुढे पाठवणे थांबवतो आणि स्वतः तिचे उत्तर देतो तेव्हा हे घडते. इंटरसेप्शन गंतव्य स्थानिक सॉकेटमध्ये पुन्हा लिहिते, आणि नंतर रिझॉल्व्हर स्वतःच्या स्रोत पत्त्यासह आणि स्वतःच्या राउटिंग निर्णयासह दुसरे, असंबंधित संभाषण उघडते. क्लायंटच्या फ्लोवर लावलेल्या खुणा पहिल्या संभाषणाचे वर्णन करतात आणि दुसऱ्याबद्दल काहीही सांगत नाहीत.

खूण क्वेरीसोबत प्रवास करत नाही

पॅकेटच्या खुणा conntrack नोंदीवर आणि उडत्या पॅकेटवर राहतात. REDIRECT नियम ते उड्डाण संपवतो: पेलोड स्थानिक सॉकेटला दिला जातो आणि मूळ नोंदीने आपले काम पूर्ण केलेले असते. त्यानंतर राउटरमधून जे बाहेर पडते ते रिझॉल्व्हर प्रक्रियेने तयार केलेले नवे सॉकेट असते, ज्याचा स्रोत राउटरचाच पत्ता.

म्हणूनच LAN क्लायंटच्या पत्त्यावर आधारित धोरण मार्ग अपस्ट्रीम क्वेरीशी कधीही जुळत नाही. नवे सॉकेट क्लायंटचे नसून dnsmasq चे आहे, आणि कर्नल मार्गाचे मूल्यांकन राउटरच्या स्वतःच्या रहदारीसाठी करते. स्रोत नियम, इंटरफेस नियम आणि खुणांचे नियम सर्व वेगळा tuple पाहतात. खूण पुढे पसरते असे गृहीत धरणे ही या सेटअपमधील सर्वात सामान्य चूक आहे, आणि क्लायंटच्या बाजूच्या कॅप्चरमध्ये ती अदृश्य असते.

दोन्ही संभाषणे खरेच एक नाव आणि एक वेळ सामायिक करतात, आणि कॅप्चरवर झटपट नजर टाकताना ती एकच फ्लो वाटण्याचे कारण तेच.

कुठे पुढे पाठवणे स्थानिक निराकरण होते

पोर्ट 53 रीडायरेक्ट होत आहे, दुसऱ्या होस्टवर भाषांतरित होत आहे, की तसाच ठेवला आहे हे शोधून सुरुवात करा, कारण तीनही प्रकरणे वेगळी वागतात. स्थानिक पोर्टवरचे रीडायरेक्ट पुढे पाठवणे संपवते, तर दुसऱ्या यंत्रावरचे भाषांतर पॅकेट हालचालीत ठेवते आणि क्लायंटचे tuple अर्थपूर्ण ठेवते.

दोन्ही प्रोटोकॉल पहा. UDP आणि TCP वरून पोहोचणारे रिझॉल्व्हर दोन्हींवर चाचणीले जाईल, आणि फक्त UDP व्यापणारा नियमसंच मोठ्या उत्तरांसाठी शांत भोक सोडतो. राउटरच्या स्वतःच्या कॉन्फिगरेशन व्यवस्थापकाने तयार केलेले नियमही मोजले जातात, आणि तयार केलेली फाइल संपादित करणे सहसा पुढील रीलोडकडून हरते.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

ती आउटपुट क्रमाने तीन प्रश्नांची उत्तरे देतात: क्वेरी काय पुन्हा लिहिते, ती काय स्वीकारते, आणि ऐकणाऱ्या सॉकेटचा मालक कोणती प्रक्रिया आहे. मालक कळल्यावर अपस्ट्रीम धोरणाला राहण्याची जागा मिळते.

रिझॉल्व्हरला त्याचे स्वतःचे इग्रेस धोरण द्या

फक्त काही नावांना बोगदा लागतो तेव्हा डोमेन-विशिष्ट अपस्ट्रीम हे सर्वात स्वच्छ साधन आहे. dnsmasq डोमेनपुरता मर्यादित server ओळ स्वीकारतो, ऐच्छिक इंटरफेस किंवा स्रोत पत्त्यासह क्वेरी निवडलेल्या उपकरणातून बाहेर काढतो. तेच मार्गदर्शन दुसऱ्या संभाषणाला VPN च्या मागे जायला लावते.

server=/corp.example/10.30.0.53@tun_work
log-queries

वरील डोमेन, पत्ता आणि इंटरफेस तुमच्या स्वतःच्या मूल्यांसाठी जागाधारक आहेत. डोमेन निवड आणि इग्रेस नियंत्रण वेगळे निर्णय राहतात: मार्ग असणे आवश्यक आहे, स्रोत पत्त्याला अपस्ट्रीम रिझॉल्व्हरने परवानगी द्यावी, आणि फायरवॉलने उत्तरास परवानगी द्यावी. केवळ इंटरफेस मार्गदर्शन fail-closed नाही, कारण नाहीशा झालेला बोगदा रिझॉल्व्हरला दुसऱ्या मार्गावर पडू देऊ शकतो. कोणताही सार्वजनिक पर्याय अशा नामजागेपासून दूर ठेवा जी खाजगी राहिली पाहिजे.

ओळ तयार केलेल्या फाइलमध्ये नाही तर राउटरला समर्थित असलेल्या कॉन्फिगरेशन मालकाकडे ठेवा, अन्यथा पुढील रीलोड दुरुस्ती पुसून टाकेल.

सामायिक कॅश काय जपू शकत नाही

एक कॅश असलेला एक फॉरवर्डर प्रत्येक LAN क्लायंटला सेवा देतो, आणि त्यामुळे काही नेटवर्कांना आवश्यक असलेला फरक कोसळतो. दोन क्लायंटना एकच नाव वेगळ्या पद्धतीने सोडवायचे असल्यास, सामायिक सॉकेटकडे कोणी विचारले हे परत मिळवण्याचा मार्ग नाही. प्रति-क्लायंट धोरण वेगळ्या रिझॉल्व्हर उदाहरणांमध्ये किंवा ओळख जपणाऱ्या फॉरवर्डिंग सुविधेत राहिले पाहिजे.

कॅश केलेले उत्तरही नव्या मार्गाचा पुरावा नाही. अपस्ट्रीम मार्ग तुटलेला असतानाही उत्तर स्मृतीतून येऊ शकते.

पोर्ट 53 चे नियम DNS हे HTTPS किंवा TLS वर बोलणाऱ्या अनुप्रयोगांबद्दल काहीही सांगत नाहीत. त्या क्वेरी कधीही रीडायरेक्टपर्यंत पोहोचत नाहीत, म्हणून फक्त पोर्ट 53 वर उभे केलेले धोरण रहदारीचा एक उपसंच वर्णन करते आणि ते उपसंच म्हणून नोंदवले पाहिजे.

दुसरे संभाषण तपासा, पहिले नाही

तुम्ही नियंत्रित करता अशा एका नावाने चाचणी करा आणि दोन्ही बाजू पहा. क्लायंटच्या बाजूचे कॅप्चर सिद्ध करते की क्वेरीने LAN सोडले; त्यानंतर ती कुठे गेली हे फक्त राउटरची बाजू सिद्ध करते.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

प्रत्येक प्रयत्नापूर्वी कॅश रिकामा करा, कारण उबदार उत्तर तुटलेला अपस्ट्रीम लपवते. TCP वर पुनरावृत्ती करा, नंतर बोगदा बंद असताना पुनरावृत्ती करा, रिझॉल्व्हरला त्याचा पसंतीचा मार्ग गेल्यावर काय करायचे ते पाहण्यासाठी. तेच शेवटचे वर्तन ठरवते की रचना fail-closed आहे की फक्त भाग्यवान.