खाजगी 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

नंतर एकदा प्रतिबंधित स्रोत तपासा, आणि निकाल नोंदवा।

तुमच्या दस्तऐवजीकरणात दोन्ही नोंदी वेगळ्या ठेवा: नाव आणि त्याचा झोन, स्वीकारलेले स्रोत आणि नियमाचा मालक। एक बदलला तरी दुसऱ्याला बदलण्याची गरज नाही।

निर्णय सामान्यतः कुठे चुकतो

सामान्य अपयश असे असते की कार्यालयीन नेटवर्कवरच निराकरण होणाऱ्या नावाखाली प्रकाशित सेवा, आणि फक्त कार्यालयीन श्रेणी स्वीकारणारा प्रवेश नियम। मग दूरस्थ वापरकर्ते तुटलेल्या सेवेची तक्रार करतात, जी प्रत्यक्षात दोन वेगळ्या चुका आहेत। दुसरे सामान्य अपयश उलटे आहे: नावाची अडचण दूर करण्यासाठी जोडलेला व्यापक प्रवेश नियम सेवा अशा स्रोतांपासून पोहोचण्यायोग्य ठेवतो जे कोणीही हेतूने ठेवले नव्हते। दोन्ही कॉन्फिगरेशनच्या चुका आहेत, आणि वापरकर्त्याच्या खुर्चीतून त्या सारख्याच दिसतात।

एकाही यशस्वी चाचणीतून दोन्हीपैकी कोणतीही चूक दिसत नाही। म्हणूनच दोन्ही निर्णय वेगळ्या नोंदी आणि वेगळ्या चाचण्यांना पात्र आहेत, एकच व्यक्ती दोन्ही घेत असली तरीही।

सेवा सुरू होण्यापूर्वी दोन्ही लिहून ठेवा, कारण पुढील बदलाचा विचार करणे सोपे होईल। नोंद छोटी आहे: नाव आणि त्याच्या झोनसाठी एक ओळ, स्वीकारलेले स्रोत आणि नियमाच्या मालकासाठी एक ओळ।