डोमेन-आधारित 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 मौजूदा एड्रेस-समूह देता है, और क्लाइंट की कनेक्शन सूची बताती है कि कौन सा इंटरफ़ेस प्रवाह ले गया।
उत्पाद जो रिफ़्रेश अंतराल बताता है, उसके बाद दोहराएँ। अगर एड्रेस-समूह खिसक जाए और नियम उसका पीछा न करे, तो आपने असली व्यवहार ढूँढ लिया है।
रिज़ॉल्वर नीति भी अलग रखें। डोमेन नियम को सही नाम-डेटा चाहिए, लेकिन वह अपने आप तय नहीं करता कि क्वेरी का जवाब कौन सा रिज़ॉल्वर देगा।