निजी 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

उही रिजोल्भरबाट सार्वजनिक नाम पनि परीक्षण गर्नुहोस्। अपवादबाहिरका नामहरूका लागि सुरक्षाले अझै ठीक व्यवहार गर्नुपर्छ, र त्यो जाँच असफल भयो भने परिवर्तन इच्छितभन्दा फराकिलो थियो। प्रमाणपत्र प्रमाणीकरणलाई अन्त्यसम्म अछुतो राख्नुहोस्, किनकि सही रूपमा घुल्ने नाम पनि सेवाले प्रस्तुत गर्ने प्रमाणपत्रसँग मिल्नुपर्छ।

अस्वीकार गरिएको उत्तर, डोमेन, रिजोल्भर र नीतिको मालिक को हो टिकटमा लेख्नुहोस्। त्यही अभिलेखले रहस्यमय आन्तरिक अवरोधलाई कसैले समीक्षा गर्न सक्ने कन्फिगरेसन परिवर्तनमा बदल्छ।