dnsmasq में OpenVPN क्लाइंट नाम: स्क्रिप्ट या स्थिर प्रविष्टियाँ?
क्लाइंट के पते बदलते हैं, सेवाओं के नाम नहीं। VPN सत्र से क्लाइंट नाम बनाएँ, drop-in फ़ाइल में सेवा नाम स्थिर करें, फिर क्लाइंट को उसका उपयोग करने दें।
लगभग हर छोटे OpenVPN गेटवे पर नाम की दो समस्याएँ दिखती हैं। जुड़े हुए लैपटॉप तक उसके प्रमाणपत्र पर लिखे नाम से नहीं पहुँचा जा सकता, और सुरंग के पीछे की सेवाओं के कोई नाम ही नहीं हैं। ये एक ही समस्या जैसी लगती हैं और उलटे उपचार माँगती हैं, क्योंकि एक पता हर सत्र के साथ बदलता है और दूसरा नहीं। कुछ भी संपादित करने से पहले तय करें कि आप किस प्रकार का नाम जोड़ रहे हैं।
हर नाम के लिए तय करें, गेटवे के लिए नहीं
परीक्षण सरल है: जब क्लाइंट फिर से जुड़ता है तो क्या यह पता बदलता है? अगर हाँ, तो नाम VPN सत्र से बनाया जाना चाहिए। अगर नहीं, तो यह एक स्थिर प्रविष्टि में है जिसे आप पढ़ और जाँच सकते हैं।
| Name kind | Source of truth | Where it lives |
|---|---|---|
| Connected client | The address OpenVPN just assigned | Generated hosts file, rewritten per session |
| Service behind the tunnel | A fixed address you chose | Static address= drop-in |
| Anything with a certificate name | The certificate, not the pool | Either, but the name must match the certificate |
दोनों को मिलाना ही सामान्य विफलता है। बनाई गई फ़ाइल में स्थिर किया गया सेवा स्क्रिप्ट द्वारा पहली बार फिर से लिखे जाने पर गायब हो जाता है, और स्थिर प्रविष्टि में लिखा क्लाइंट उस व्यक्ति की ओर इशारा करता है जिसके पास वह पता आखिरी बार था। दोनों गलतियाँ तब तक अदृश्य रहती हैं जब तक कोई नाम गलत मशीन पर हल न हो जाए। तब तक डिबग करने वाला मानता है कि DNS टूटा है, फ़ाइल नहीं।
गतिशील मार्ग: learn-address और पूल
OpenVPN आवंटन जानता है, इसलिए उसे बताने दें। ये सर्वर विकल्प आवंटन को टिकाऊ और स्क्रिप्ट-योग्य बनाते हैं:
client-config-dir /etc/openvpn/ccd
ifconfig-pool-persist /etc/openvpn/ip-pool 60
script-security 2
learn-address /etc/openvpn/learn-address.shlearn-address हर बार कोई पता जोड़े, अद्यतन या हटाए जाने पर आपकी स्क्रिप्ट चलाता है, और ऑपरेशन, पता और सामान्य नाम भेजता है। न्यूनतम स्क्रिप्ट प्रति क्लाइंट एक पंक्ति जोड़ती है और हटाने पर उसे हटा देती है:
#!/bin/sh
HOSTS=/etc/openvpn/hosts.lan
case "$1" in
add|update) echo "$2 $3" >> "$HOSTS" ;;
delete) sed -i "/^$2 /d" "$HOSTS" ;;
esac
kill -HUP $(cat /var/run/dnsmasq.pid)
tun डिवाइस पर दूसरा तर्क क्लाइंट का सुरंग पता है, इसलिए पंक्ति सीधे उपयोगी है। tap डिवाइस पर OpenVPN इसके बजाय क्लाइंट का MAC पता भेजता है, क्योंकि tap खंड IPv4 के अलावा अन्य प्रोटोकॉल भी ले जा सकता है, और तब कुछ भी लिखने से पहले सामान्य नाम से पूल फ़ाइल में पता खोजना पड़ता है।
स्पष्ट रहें कि बनाई गई फ़ाइल क्या है: अभी कौन जुड़ा है इसका स्नैपशॉट। डिस्कनेक्ट पर नाम गायब हो जाते हैं, जो नेटवर्क के बीच घूमने वाले लैपटॉप के लिए ठीक वही है जो आप चाहते हैं और रात भर चालू रहने वाले सर्वर के लिए ठीक वही है जो आप नहीं चाहते।
स्थिर मार्ग: address= और डोमेन विस्तार
सिस्टम की hosts फ़ाइल के बजाय dnsmasq को बनाई गई फ़ाइल की ओर इंगित करें, और उसे एक डोमेन दें ताकि छोटे नाम पूर्ण योग्य नामों में विस्तारित हों:
domain=corp.example
no-hosts
addn-hosts=/etc/openvpn/hosts.lan
listen-address=127.0.0.1,10.8.0.1
bind-interfacesdomain सेट होने पर, 10.8.0.6 alice जैसी पंक्ति alice और alice.corp.example दोनों के लिए उत्तर देती है। listen-address को केवल सुरंग गेटवे और loopback तक रखें, क्योंकि गलती से LAN इंटरफ़ेस पर प्रकाशित रिज़ॉल्वर ऐसी सेवा है जिसे आप देने का इरादा नहीं रखते थे।
जो सेवाएँ कभी पूल से नहीं आतीं उनकी अपनी प्रविष्टियाँ होती हैं। उन्हें वितरण की कॉन्फ़िगरेशन निर्देशिका के अंतर्गत अलग drop-in फ़ाइल में रखें ताकि पैकेज अपग्रेड उन्हें अधिलिखित न कर सके:
address=/files.corp.example/10.8.0.20
address=/db.corp.example/10.9.0.5रिज़ॉल्वर सौंपें वरना कुछ नहीं होगा
जिसे कोई नहीं पूछता ऐसा रिज़ॉल्वर कुछ नहीं बदलता। सर्वर को उसकी घोषणा करनी होगी:
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"Windows क्लाइंट दोनों विकल्प स्वयं लागू करते हैं। अधिकांश Linux क्लाइंट नहीं करते: उन्हें समर्थित रिज़ॉल्वर एकीकरण चाहिए, जैसे वितरण का update-resolv-conf हुक या NetworkManager का DNS प्रबंधन, या मैन्युअल खोज डोमेन और नेमसर्वर। push मान लेने के बजाय क्लाइंट के वास्तविक रिज़ॉल्वर की जाँच करें, क्योंकि अनदेखा किया गया push ठीक वैसा ही दिखता है जैसा उत्तर न देने वाला सर्वर।
तीन परतों पर सत्यापित करें
पहले सीधे सर्वर से पूछें, फिर क्लाइंट से, फिर एप्लिकेशन से:
dig +short @10.8.0.1 alice.corp.example
getent hosts files.corp.exampleअगर सीधी क्वेरी उत्तर देती हैं और एप्लिकेशन नहीं, तो दोष ज़ोन का नहीं बल्कि क्लाइंट हैंडऑफ़ का है। अगर नाम हल होता है और कनेक्शन फिर भी विफल रहता है, तो नाम ठीक है और अगला देखने योग्य मार्ग या फ़ायरवॉल है।
दो श्रेणियाँ कॉन्फ़िगरेशन के बगल में लिखें: कौन से नाम बनते हैं, कौन से स्थिर हैं, और हर एक को किस प्रमाणपत्र से मेल खाना है। अगला व्यक्ति जो सर्वर जोड़ेगा वह पहला पैटर्न कॉपी करेगा जो उसे मिलेगा।