गेटवे पर OpenVPN DNS: dnsmasq और फ़ायरवॉल का दायरा

टनल पते पर dnsmasq चलाएँ, केवल क्लाइंट पूल से DNS की अनुमति दें, रिज़ॉल्वर पुश करें, और फिर सीधी क्वेरी तथा ऐप की अपनी लुकअप जाँचें।

टनल पर मौजूद क्लाइंट गेटवे तक पहुँच सकते हैं, और गेटवे आंतरिक रिज़ॉल्वर तक पहुँच सकता है, इसलिए DNS को काम करना चाहिए। यह काम नहीं करता, क्योंकि ये दो अलग अनुमतियाँ हैं और काम करती DNS सेवा तीसरी चीज़ है। लिसनर ऐसे पते पर होना चाहिए जहाँ क्लाइंट पहुँच सकें, फ़ायरवॉल को उस पते पर क्वेरी की अनुमति देनी चाहिए, और क्लाइंट को बताया जाना चाहिए कि वह इसका उपयोग करे। टनल को दोनों दिशाओं में खोलना पहले दो को संयोग से हल करता है और तीसरे को अधूरा छोड़ देता है।

लिसनर दो दिशाओं वाली स्थानीय सेवा है

अंदर की दिशा में क्लाइंट गेटवे के टनल पते पर पोर्ट 53 पर क्वेरी भेजता है। बाहर की दिशा में डेमॉन वह क्वेरी अपने कॉन्फ़िगर किए गए अपस्ट्रीम को भेजता है। दोनों आधे हिस्सों को काम करना है, और वे अलग-अलग तरह से विफल होते हैं।

क्लाइंट द्वारा बताया गया टाइमआउट और गेटवे पर दिखने वाला टाइमआउट एक ही खराबी नहीं हैं।

टनल पता बाँधें, हर पता नहीं

इस काम के लिए समर्पित dnsmasq इंस्टेंस को स्पष्ट लिसन पता, शुरू होने के बाद टनल दिखने को सहने वाला बाइंड मोड, और एक स्पष्ट अपस्ट्रीम चाहिए। यह सबसे छोटा संस्करण है जो मैं उपयोग करता हूँ:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic अलग-अलग पतों को बाँधता है और tun0 बाद में दिखने पर सँभालता है, जो ऐसे होस्ट पर मायने रखता है जहाँ VPN सेवा फिर से शुरू होती है। loopback को सूचीबद्ध करना सार्वजनिक लिसनर जोड़े बिना स्थानीय टूल को चालू रखता है। no-resolv डेमॉन को होस्ट की रिज़ॉल्वर कॉन्फ़िगरेशन से अपस्ट्रीम विरासत में लेने से रोकता है, और no-hosts इस इंस्टेंस को गेटवे की hosts फ़ाइल प्रकाशित करने से रोकता है। इनमें से कोई भी विकल्प किसी को सेवा से क्वेरी करने की अनुमति नहीं देता।

दूसरा डेमॉन शुरू करने से पहले जाँचें कि पोर्ट 53 पर पहले से कोई लिसनर है या नहीं, और गलत डायरेक्टरी में पड़ी भटकी फ़ाइल के बजाय डिस्ट्रिब्यूशन के कॉन्फ़िगरेशन मालिक का उपयोग करें।

DNS इनपुट की अनुमति दें, टनल ट्रांज़िट की नहीं

इसे काम कराने वाले फ़ायरवॉल नियम स्थानीय-इनपुट नियम हैं, जो टनल इंटरफ़ेस, क्लाइंट पूल, गेटवे पता और पोर्ट 53 तक सीमित हैं। दो नियम, हर प्रोटोकॉल के लिए एक, पर्याप्त हैं:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS UDP के साथ-साथ TCP पर भी चलता है, इसलिए केवल UDP वाला नियम बड़े उत्तरों को ऐसे विफल छोड़ता है जो रुक-रुक कर लगता है। ये ufw route अनुमतियाँ नहीं हैं, और इन्हें tun0 पर व्यापक अनुमति नहीं बनना चाहिए। क्रम का महत्व सामग्री जितना ही है: सारा इनपुट tun0 से गिराने वाला पुराना नियम फिर भी जीतता है, और अंतिम ड्रॉप के नीचे अनुमति जोड़ने से कुछ नहीं बनता।

अगर गेटवे DNS अब डिज़ाइन का हिस्सा है, तो उस पुरानी नीति को जानबूझकर संशोधित करें और कारण दर्ज करें।

अपस्ट्रीम आधा हिस्सा अलग रास्ता है

क्वेरी गेटवे से उसके अपने पते से अपस्ट्रीम रिज़ॉल्वर की ओर निकलती हैं, इसलिए गेटवे का रूट और उस रिज़ॉल्वर के प्रति आउटपुट नीति को यह अदला-बदली अनुमत करनी चाहिए। यह उस नियम से अलग है जो क्लाइंट को लिसनर तक पहुँचने देता है, और यह अलग लक्षण के साथ विफल होता है।

उत्तरों को काम कराने के लिए असीमित टनल आउटपुट न जोड़ें; ट्रैक किए गए उत्तरों को इसकी ज़रूरत नहीं है।

विकल्प पुश करें, फिर हैंडऑफ़ जाँचें

सर्वर पुश किए गए विकल्प के साथ क्लाइंट को रिज़ॉल्वर की घोषणा कर सकता है। यह विकल्प है, ऐसा निर्देश नहीं जिसे ऑपरेटिंग सिस्टम को मानना ही होगा:

push "dhcp-option DNS 10.90.0.1"

कमांड-लाइन Linux क्लाइंट को अपने कनेक्शन मैनेजर का रिज़ॉल्वर एकीकरण चाहिए हो सकता है, और प्रबंधित डिवाइस को अद्यतन प्रबंधन प्रोफ़ाइल चाहिए हो सकता है। कनेक्ट करने के बाद क्लाइंट पर सक्रिय रिज़ॉल्वर की पुष्टि करें, यह मानने के बजाय कि पुश लागू हो गया। जब दो तंत्र एक साथ DNS सेट करने की कोशिश करते हैं, तो ऐसी दौड़ बनती है जो टिमटिमाते रिज़ॉल्यूशन के रूप में दिखती है।

लक्ष्य क्लाइंट की रिज़ॉल्वर कॉन्फ़िगरेशन का एक ही मालिक होना है, और पुश आमतौर पर वह मालिक तभी होता है जब क्लाइंट प्लेटफ़ॉर्म सहमत हो।

वह जाँचें जो आपने वास्तव में बनाया

एक निजी पूर्ण योग्य नाम और एक अनुमत बाहरी नाम सीधे टनल पते के विरुद्ध, UDP और TCP दोनों पर क्वेरी करें। फिर ऐप के सामान्य लुकअप पथ से दोहराएँ।

अगर सीधी क्वेरी काम करती हैं और ऐप फिर भी विफल होता है, तो खराबी सर्वर पर नहीं, हैंडऑफ़ में है:

  • क्लाइंट ने पुश किया गया विकल्प कभी लागू नहीं किया।
  • बाद में कोई दूसरा रिज़ॉल्वर सेट हुआ और दौड़ जीत गया।
  • ऐप अपनी रिज़ॉल्वर लाइब्रेरी या कैश किया गया उत्तर उपयोग करता है।

अंत में पुष्टि करें कि अनुमोदित VPN पथ के बाहर का कोई स्रोत लिसनर का उपयोग बिल्कुल नहीं कर सकता। सफल रिज़ॉल्यूशन उस पते को अधिकृत नहीं करता जो उसने लौटाया, इसलिए इन दो सवालों को अलग रखें।

संबंधित लेख