निजी DNS नाम कि केवल IP? साझा गर्नु अघि निर्णय गर्नुहोस्

निजी सेवा टाढाका प्रयोगकर्ताहरूका लागि खोल्दा दुई प्रश्न मिसिन्छन्। पहिलो हो ग्राहकहरूले कुन नाम प्रयोग गर्नुपर्ने; दोस्रो हो सेवाले कुन स्रोतहरू स्वीकार गर्नुपर्ने। तिनीहरूलाई यही क्रममा जवाफ दिनुहोस्, किनकि गलत पहुँच नियमपछाडिको सही नाम पनि असफल हुन्छ, र नहल हुने नामपछाडिको सही नियम कहिल्यै परीक्षण हुँदैन।

पहिलो सर्त: ग्राहकहरूसँग कुन resolver मार्ग छ?

निजी नाम तब मात्र काम गर्छ जब ग्राहकको resolver ले त्यसको जवाफ दिन सक्छ। यसको अर्थ अधिकृत टाढाको ग्राहकले जोन राख्ने DNS सर्भरसम्म पुग्नुपर्छ, या त सुरुङबाट या संस्थाले टाढाका प्रयोगकर्ताका लागि पहिले नै चलाइरहेको resolver बाट। सुरुङ एक वाहन हो, निर्देशिका होइन। यसले ग्राहकलाई resolver सम्मको मार्ग दिन्छ, र कुन जोन सोध्ने भनी बताउँदैन।

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

ल्यापटप VPN मा जोडियो भनेर सार्वजनिक resolver ले निजी जोन सिक्दैन।

प्रत्ययले पनि उत्तिकै ध्यान पाउनुपर्छ। संस्थाले नियन्त्रण गर्ने डोमेनको उपडोमेन प्रयोग गर्नुहोस्, ताकि स्वामित्व र प्रमाणपत्र योजना स्पष्ट रहोस्। .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

त्यसपछि एक पटक निषेधित स्रोत परीक्षण गर्नुहोस्, र नतिजा लेख्नुहोस्।

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

निर्णय सामान्यतया कहाँ गल्ती हुन्छ

सामान्य असफलता भनेको कार्यालय सञ्जालमा मात्र हल हुने नामअन्तर्गत प्रकाशित सेवा र कार्यालय दायरा मात्र स्वीकार गर्ने पहुँच नियम हो। तब टाढाका प्रयोगकर्ताहरूले बिग्रिएको सेवाको रिपोर्ट गर्छन्, जुन वास्तवमा दुई छुट्टाछुट्टै चुक हुन्। दोस्रो सामान्य असफलता उल्टो हो: नामको समस्या हटाउन थपिएको फराकिलो पहुँच नियमले सेवालाई कसैले नचाहेका स्रोतहरूबाट पुग्न सकिने बनाइराख्छ। दुवै कन्फिगरेसनका चुक हुन्, र प्रयोगकर्ताको कुर्सीबाट ती एउटै जस्तो देखिन्छन्।

एउटा सफल परीक्षणबाट कुनै पनि गल्ती देखिँदैन। त्यसैले दुवै निर्णय छुट्टाछुट्टै रेकर्ड र छुट्टाछुट्टै परीक्षणका योग्य छन्, एउटै व्यक्तिले दुवै लिए पनि।

सेवा सुरु हुनुअघि दुवै लेख्नुहोस्, किनकि अर्को परिवर्तनबारे सोच्न सजिलो हुनेछ। रेकर्ड छोटो छ: नाम र त्यसको जोनका लागि एक लाइन, स्वीकृत स्रोत र नियमको मालिकका लागि एक लाइन।