किन SRV रेकर्डले आफैले सोध्ने क्लाइन्टलाई मात्र सहयोग गर्छ

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

कसैले नसोधेको रेकर्डले कसैलाई सहयोग गर्न सक्दैन

SRV ले सेवाको स्थान प्रकाशित गर्छ; यसले सेवाको घोषणा गर्दैन। कुनै पनि कुराले रेकर्डलाई क्लाइन्टतर्फ धकेल्दैन, र कुनै रिजोल्भरले कहिल्यै नमागिएको नाम आफैं दिँदैन। एप्लिकेसनले यो गर्ने निर्णय गर्दा खोजी सुरु हुन्छ, त्यसैले लेबल उत्पादनको कागजातबाट वा नेटवर्कमा सफ्टवेयर अवलोकन गरेर आउनुपर्छ। क्लाइन्टसँग खोजीको चरण नभएको ठाउँमा, रेकर्डले क्षेत्र बदल्छ र अरू केही होइन।

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

लेख्नु अघि फिल्डहरू पढ्नुहोस्

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

यीमध्ये कुनै पनि फिल्डले प्रमाणपत्र, प्रमाणपत्र नीति वा एप्लिकेसन संस्करण बोक्दैन, र तौल बेवास्ता गर्ने क्लाइन्ट पनि जोडिन्छ, केवल इच्छित सन्तुलन बिना। लक्ष्यलाई आफ्नै ठेगाना रेकर्ड चाहिन्छ, र त्यो उपनाम नभई प्रामाणिक नाम हुनुपर्छ। श्रोता नभएको होस्टतर्फ देखाउने रेकर्ड प्रकाशित गर्दा DNS खराबीजस्तै पढिने जडान त्रुटि उत्पन्न हुन्छ, र त्यो सबैभन्दा महँगो भ्रम हो। सम्पूर्ण शृंखला प्रकाशित गर्नुहोस् वा त्यसमध्ये केही पनि नगर्नुहोस्।

क्लाइन्टले साँच्चै पठाउने लेबल पत्ता लगाउनुहोस्

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

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

जवाफलाई तपाईंले प्रकाशित गरेको रेकर्डसँग अक्षरैपिच्छे तुलना गर्नुहोस्, किनकि अन्डरस्कोर र अन्त्यको बिन्दु नामको भाग हुन्। साँच्चै पठाइएको क्वेरीको खाली जवाफले क्षेत्रतर्फ संकेत गर्छ, जबकि क्वेरी नै नहुनुले क्लाइन्टतर्फ संकेत गर्छ, र यी निष्कर्षले तपाईंलाई फरक टोलीकहाँ पठाउँछ। वास्तविक जवाफ तलको लाइनजस्तो देखिन्छ, जहाँ प्राथमिकता 20 कुनै पनि कम प्राथमिकताको रेकर्डसँग हार्छ र क्लाइन्टले नाम दिइएको लक्ष्यमा पोर्ट 8443 डायल गर्छ।

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

लक्ष्य पनि हुनुपर्छ

समाधान हुने लक्ष्य जवाफ दिने सेवाजस्तै होइन। लक्ष्यको ठेगाना रेकर्ड जाँच्नुहोस्, त्यसपछि प्रकाशित पोर्ट र प्रोटोकलमा केही सुनिरहेको छ कि जाँच्नुहोस्। UDP मात्र सुन्ने श्रोतातर्फ देखाउने TCP रेकर्ड त्यस्तो असंगति हो जुन कुनै क्षेत्र सम्पादनले सुधार्दैन। लक्ष्य अस्थिर हुँदा TTL छोटो राख्नुहोस्, र नाम चल्न छोडेपछि लामो बनाउनुहोस्।

खोजी साँच्चै कार्यान्वयन गर्ने क्लाइन्टहरू रेकर्डलाई कति आदर गर्छन् त्यसमा फरक छन्। केहीले प्राथमिकता मात्र प्रयोग गर्छन्, केहीले तौललाई सल्लाह मान्छन्, र केहीले पोर्ट बेवास्ता गरेर पूर्वनिर्धारित मान्दछन्। ती फरकहरू लेबलको छेउमा तपाईंका टिप्पणीमा हुनुपर्छ, किनकि तिनले अन्यथा रिजोल्भरको खराबीजस्तो देखिने व्यवहारको व्याख्या गर्छन्।

खोजी भनेको प्रमाणीकरण होइन

SRV जवाफले कहाँ जोडिने भन्छ, र पुगेपछि कसलाई विश्वास गर्ने भन्नेबारे केही भन्दैन। क्लाइन्टको प्रमाणपत्र प्रमाणीकरण र सर्भर पहिचान जाँच जस्तो थियो त्यस्तै राख्नुहोस्, किनकि अरू कसैले नक्कली बनाउन सक्ने रेकर्ड विश्वासको निर्णय बन्नु हुँदैन। DNS जवाफहरू क्यास गर्न सकिन्छ र क्षेत्र नियन्त्रण गर्ने जो कोहीले सम्पादन गर्न सक्छ, जसले नीति कोड गर्नका लागि तिनलाई खराब ठाउँ बनाउँछ।

खोजी समर्थन नभएको क्लाइन्टका लागि, उसले स्वीकार गर्ने प्रोफाइल वा गेटवे URL वितरण गर्नुहोस्, र कुन उत्पादनले कुन विधि प्रयोग गर्छ नोट गर्नुहोस्। त्यो टिप्पणीले अर्को प्रशासकलाई रेकर्ड थपेर सबैतिर चल्ने आशा गर्नबाट रोक्छ। SRV विनिर्देश ले लक्ष्यहरूबीचको छनोट वर्णन गर्छ, र यसलाई अधिकार दिने संयन्त्रका रूपमा पढ्नु भनेको उपयोगी रेकर्डलाई सुरक्षा अनुमान बनाउने बाटो हो। जानाजान प्रकाशित गर्नुहोस्, आफ्नो कागजातमा लेबलको नाम राख्नुहोस्, र यीमध्ये केही महत्त्वपूर्ण छ कि भनेर निर्णय गर्ने घटकका रूपमा क्लाइन्टलाई हेर्नुहोस्।