निजी DNS नाम या सिर्फ़ एक IP? साझा करने से पहले तय करें

जब कोई निजी सेवा दूरस्थ उपयोगकर्ताओं के लिए खोली जाती है, तो दो प्रश्न आपस में मिल जाते हैं। पहला यह है कि ग्राहक कौन-सा नाम इस्तेमाल करें; दूसरा यह है कि सेवा किन स्रोतों को स्वीकार करे। इनका उत्तर इसी क्रम में दें, क्योंकि गलत पहुँच नियम के पीछे सही नाम भी विफल होता है, और जो नाम हल नहीं होता उसके पीछे का सही नियम कभी परखा ही नहीं जाता।

शर्त एक: ग्राहकों के पास कौन-सा रिज़ॉल्वर पथ है?

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

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

सार्वजनिक रिज़ॉल्वर निजी ज़ोन को इसलिए नहीं सीखेगा कि लैपटॉप किसी VPN से जुड़ा है।

प्रत्यय भी उतने ही ध्यान के योग्य है। संगठन जिस डोमेन को नियंत्रित करता है उसका उपडोमेन इस्तेमाल करें, ताकि स्वामित्व और प्रमाणपत्र नियोजन स्पष्ट रहें। .local से बचें: मल्टीकास्ट DNS विनिर्देश उस प्रत्यय को लिंक-लोकल हल से जोड़ता है, और रूट किया गया सुरंग वह व्यवहार आपके लिए दोहराता नहीं है।

शर्त दो: सेवा कौन-सा स्रोत प्राप्त करती है?

पहुँच नियम पतों के विरुद्ध लिखे जाते हैं, इसलिए उपयोगी प्रश्न यह है कि रूटिंग और अनुवाद के बाद सेवा कौन-सा पता देखती है। 10.20.30.40 पर एक उदाहरण सेवा के लिए, कार्यालय ग्राहक 10.20.30.0/24 से आते हैं और दूरस्थ ग्राहक अलग पूल से आते हैं, जैसे 10.99.0.0/24।

यदि कोई गेटवे दूरस्थ पूल का अनुवाद करता है, तो सेवा अनुवादक को देखती है, और 10.99.0.0/24 के लिए लिखा नियम मेल नहीं खाएगा।

इसे ग्राहक के पक्ष से नहीं, सेवा के पक्ष से पढ़ें। सेवा होस्ट पर श्रोता लॉग या पैकेट कैप्चर वह स्रोत दिखाता है जो वास्तव में पहुँचा; ग्राहक का अपना पता केवल एक अनुमान है कि पथ में क्या बचा।

शर्त तीन: क्या नाम सेवा से जुड़ा है या होस्ट से?

एक मशीन के पते की ओर इशारा करने वाला नाम हर ग्राहक को उस मशीन से बाँध देता है। लोड बैलेंसर या स्थिर सेवा पते की ओर इशारा करने वाला नाम उसके पीछे के होस्ट के बदलने पर भी टिकता है। सोच-समझकर चुनें, क्योंकि इसे बाद में बदलने का अर्थ है हर ग्राहक के बुकमार्क और हर प्रमाणपत्र का विषय बदलना।

एक ही आंतरिक सेवा के लिए सीधा रिकॉर्ड आमतौर पर ठीक रहता है और समझने में आसान है।

जो भी बदला, फिर बनाया या स्केल किया जाएगा, उसके लिए स्थिर फ़्रंट एंड अतिरिक्त कॉन्फ़िगरेशन के योग्य है। जाँच सरल है: यदि आप उपयोगकर्ताओं को बताए बिना बैकएंड बदल सकते हैं, तो नाम सेवा से जुड़ा है; यदि नहीं, तो यह होस्ट से जुड़ा है।

दोनों निर्णयों की अलग-अलग जाँच करें

पहले हल करें, फिर जुड़ें। अपेक्षित पता लौटाने वाली हल जाँच नाम के पथ को सिद्ध करती है और पहुँच के बारे में कुछ नहीं कहती। कनेक्शन जाँच पथ और नियम को साथ सिद्ध करती है, इसलिए इसे हल सफल होने के बाद ही चलाएँ।

curl -sv --max-time 5 https://files.corp.example/health

फिर एक बार किसी निषिद्ध स्रोत की जाँच करें, और परिणाम लिख लें।

अपने दस्तावेज़ीकरण में दोनों रिकॉर्ड अलग रखें: नाम और उसका ज़ोन, स्वीकृत स्रोत और नियम का स्वामी। जब एक बदले, तो दूसरे को बदलना ज़रूरी नहीं।

निर्णय आमतौर पर कहाँ गलत होता है

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

एक सफल जाँच से कोई भी गलती दिखाई नहीं देती। इसीलिए दोनों निर्णय अलग रिकॉर्ड और अलग जाँचों के योग्य हैं, तब भी जब एक ही व्यक्ति दोनों लेता है।

सेवा शुरू होने से पहले दोनों लिख लें, क्योंकि अगला बदलाव समझने में आसान होगा। रिकॉर्ड छोटा है: नाम और उसके ज़ोन के लिए एक पंक्ति, स्वीकृत स्रोतों और नियम के स्वामी के लिए एक पंक्ति।