खाजगी VPN नावे अपयशी होत आहेत? संशय DNS रीबाइंड संरक्षणावर

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

रीबाइंड संरक्षण एक विशिष्ट युक्ती थांबवण्यासाठी आहे। जाणूनबुजून प्रकाशित केलेले खाजगी नाव संरक्षण कार्यान्वित होईल इतके समान दिसते।

धोरणापूर्वी उत्तर वाचा

VPN प्रत्यक्षात पाठवतो त्या रिझॉल्व्हरला नाव विचारा, घरी तुमचा लॅपटॉप वापरतो त्या रिझॉल्व्हरला नाही। उत्तराची तुम्ही अपेक्षित असलेल्या नोंदीशी तुलना करा, आणि उत्तर रिकामे आहे, नाकारले आहे, की कोणीही नियोजित न केलेल्या सार्वजनिक पत्त्यांनी भरलेले आहे ते नोंदवा।

लक्षणे एकमेकांवर आच्छादतात, म्हणून निदान उत्तराच्या आकारावर ठरते। NXDOMAIN म्हणजे गहाळ नोंद, REFUSED म्हणजे प्रवेश नियम, अंतर्गत नावासाठी सार्वजनिक पत्ता म्हणजे धोरण किंवा split-DNS चुकी, आणि क्लायंट वापरू शकत नाही असा बरोबर खाजगी पत्ता पूर्णपणे वेगळी समस्या। नाकारलेले कनेक्शन किंवा थांबलेली विनंती स्वतःहून काहीही सिद्ध करत नाही, म्हणून अशा तिकिटांमधील पहिली आज्ञा पुनर्प्रारंभ नसून शोध असावा। काहीही बदलण्यापूर्वी उत्तर लिहून ठेवा।

संरक्षण प्रत्यक्षात काय थांबवते

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

dnsmasq नेमके तेच वर्तन डोमेननिहाय अपवादांसह नोंदवते। त्याच्या मार्गदर्शकात अशा पत्त्यांना कायदेशीरपणे परत देऊ शकणाऱ्या डोमेनना नाव देण्याचा मार्ग म्हणून rebind-domain-ok चे वर्णन करते। हे असे संकेत म्हणून वाचा की इच्छित दुरुस्ती मर्यादित परवानगी आहे, जागतिक स्विच नाही।

अपवाद नावांच्या जागेपुरता मर्यादित करा

आधी नावांची जागा दुरुस्त करा, नंतर अपवाद। अपयशी होणारे नाव संस्थेच्या नियंत्रणातील डोमेनचे आहे आणि नोंद जाणूनबुजून ठेवली जाते याची खात्री करा। परिचित LAN श्रेणीसारखा फक्त दिसणारा अनपेक्षित पत्ता अपवाद नसून संशयास पात्र आहे, म्हणून कोणतीही परवानगी लिहिण्यापूर्वी झोनचा मालक तपासा।

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

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

Split DNS त्याच निर्णयाचा भाग आहे। खाजगी नावांच्या जागेला केवळ अंतर्गत रिझॉल्व्हरने उत्तर द्यायचे असेल, तर तेथे प्रकाशित करा आणि सार्वजनिक रिझॉल्व्हरकडे गळती थांबवा, म्हणजे अपवाद प्रत्येक मार्गाऐवजी एक मार्ग व्यापेल।

संसाधन आणि संरक्षण पुन्हा तपासा

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

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

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

नाकारलेले उत्तर, डोमेन, रिझॉल्व्हर आणि धोरणाचा मालक कोण आहे ते तिकिटात नोंदवा। तीच नोंद गूढ अंतर्गत बिघाडाचे कोणीतरी तपासू शकेल अशा संरचना बदलात रूपांतर करते।