डोमेन-आधारित VPN राउटिङ बनाम IP रुट: कुन उपयुक्त हुन्छ?
स्प्लिट-टनेल बाकसमा रहेको होस्टनेम रुट होइन। रिफ्रेस, सबडोमेन दायरा र DNS परिवर्तन हुँदा के हुन्छ भन्ने आधारमा डोमेन नियम र स्पष्ट प्रिफिक्सको तुलना गर्नुहोस्।
एउटा IP रुट ठेगाना प्रिफिक्ससँग मिल्छ, र कर्नेलले थप प्रश्न नसोधी त्यसलाई लागू गर्छ। डोमेन-आधारित VPN नियम एउटा नामसँग मिल्छ, जसको अर्थ स्ट्याकमा केही कुराले त्यो नामले अहिले कुन ठेगानालाई जनाउँछ भनेर निर्णय गर्नुपर्छ र त्यो निर्णय अद्यावधिक राख्नुपर्छ। यी फरक-फरक असफलता ढाँचा भएका फरक संयन्त्र हुन्, र विक्रेताहरू दुवैका लागि एउटै शब्द प्रयोग गर्छन्। तिनीहरूलाई सुविधा-सूचीमा तुलना गर्दा मुख्य कुरा छुट्छ; उत्तर बदलिँदा के हुन्छ भन्ने आधारमा तिनीहरूको तुलना गर्नुहोस्।
उपयोगी विभाजन भनेको समाधान गर्ने नियम र नगर्ने नियमबीचको हो।
प्रत्येक नियम वास्तवमा केसँग मिल्छ
प्रिफिक्स नियम राउटिङ तालिकाका गन्तव्य ठेगानासँग मिल्छ। केही पनि समाधान हुँदैन, केही पनि सकिँदैन, र प्रत्येक प्याकेटका लागि मिलान सटीक हुन्छ। डोमेन नियम एउटा एप्लिकेसनको नामको अनुरोधसँग मिल्छ, जसलाई RFC 1034 ठेगानाको रूपमा होइन, लेबलको रूखको रूपमा परिभाषित गर्छ। केही उत्पादनले नाम एक पटक समाधान गरेर परिणामस्वरूप प्राप्त ठेगानालाई रुटको रूपमा स्थापना गर्छन्, जसले नियमलाई रिफ्रेस टाइमर जोडिएको IP नियम बनाउँछ।
डिबग गर्नुअघि यी दुईमध्ये कुन तपाईंसँग छ भनेर थाहा पाउनुहोस्, किनकि प्रत्येक अवस्थामा असफलता पूर्ण रूपमा फरक देखिन्छ।
स्ट्याकमा डोमेन नियम कहाँ बस्छ
यदि उत्पादनले डोमेन नियमहरू स्थानीय प्रोक्सीमार्फत लागू गर्छ भने, ट्राफिक त्यस प्रोक्सीसम्म पुग्नैपर्छ, र सिस्टम प्रोक्सीलाई बेवास्ता गर्ने एप्लिकेसनहरूले नियमलाई पूर्ण रूपमा बाइपास गर्छन्। यदि यसले नाम समाधान गरेर रुट थपेर लागू गर्छ भने, ठेगानाहरू अन्तिम रिफ्रेसजत्तिकै मात्र ताजा हुन्छन्। यदि यो रिजोल्भरमा हुक हुन्छ भने, DNS व्यवहार राउटिङ नीतिको भाग बन्छ, र फलब्याक रिजोल्भरले यसलाई चुपचाप रद्द गर्न सक्छ।
सेटिङको लेबल होइन, विक्रेताको मोडेल पढ्नुहोस्। Split Tunnel भन्ने बाकस भएका दुई क्लाइन्टले तीन फरक काम गरिरहेका हुन सक्छन्।
के बिग्रन्छ भनेर तुलना गर्नुहोस्
तीन कुरा फरक तरिकाले बिग्रन्छन्। ठेगाना परिवर्तन: CDN होस्टनेम केही मिनेटमै फरक ठेगाना समूहमा समाधान हुन सक्छ, त्यसैले प्रतिलिपि गरिएको सूची छिटो पुरानो हुन्छ। सबडोमेन दायरा: example.com को नियमले api.example.com समेट्न सक्छ वा नसक्ने हुन्छ, र कागजातले सामान्यतया कुन हो भन्ने स्पष्ट पार्छ। समाधान असफलता: रिजोल्भर असफल हुँदा, समाधान गर्ने क्लाइन्टले ट्राफिक टनेल गर्न वा सिधै पठाउनतर्फ फर्कन सक्छ।
दोस्रो मात्र कन्फिगरेसनको प्रश्न हो। बाँकी दुई उत्पादन कति अनुमान गर्न तयार छ भन्ने डिजाइन प्रश्न हुन्।
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
प्रिफिक्स कहिले राम्रो उत्तर हुन्छ
स्थिर निजी सबनेटका लागि स्पष्ट प्रिफिक्स बढी स्पष्ट, छिटो र अडिट गर्न सजिलो हुन्छ। रिजोल्भर अवरोध पनि यसले सहन्छ, किनकि केही पनि समाधान गर्नु पर्दैन। सेवा होस्ट गरिएको बेला, ठेगाना घुमिरहेको बेला, वा गन्तव्य समूह साँच्चै गणना गर्न नसक्ने बेला डोमेन नियम प्रयोग गर्नुहोस्। होस्टनेम भनेकै संयोगवश थाहा भएको कुरा हो भन्ने कारणले मात्र यसको प्रयोग नगर्नुहोस्।
अनुमान गरिएको स्थिर सूची दुवैमध्ये सबैभन्दा खराब हो: यो मर्मत गरिएको जस्तो देखिन्छ, र प्रदायकले होस्ट थप्ने दिन यसले चुपचाप ट्राफिक छुटाउँछ।
नयाँ अनुरोधसँग प्रमाणित गर्नुहोस्
सामान्य पुनःजडानपछि चिसो अनुरोधसँग परीक्षण गर्नुहोस्, किनकि क्यास गरिएको पृष्ठले नियमलाई कहिल्यै छुँदैन। नाम समाधान गर्नुहोस्, त्यसपछि जडान वास्तवमा कहाँ गयो भनेर जाँच्नुहोस्। dig +short app.example.com ले हालको ठेगाना समूह दिन्छ, र क्लाइन्टको जडान सूचीले कुन इन्टरफेसले प्रवाह बोकेको थियो भनेर बताउँछ।
उत्पादनले कागजात गर्ने रिफ्रेस अन्तरालपछि दोहोर्याउनुहोस्। ठेगाना समूह सर्ने र नियमले पछ्याउँदैन भने, तपाईंले वास्तविक व्यवहार भेट्टाउनुभयो।
रिजोल्भर नीति पनि छुट्टै राख्नुहोस्। डोमेन नियमलाई सही नाम-डेटा चाहिन्छ, तर कुन रिजोल्भरले प्रश्नको उत्तर दिन्छ भन्ने कुरा यसले आफैं निर्धारण गर्दैन।