डोमेन-आधारित 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 सध्याचा ॲड्रेस संच देतो, आणि क्लायंटची कनेक्शन यादी कोणत्या इंटरफेसने प्रवाह वाहून नेला ते सांगते.
उत्पादन दस्तऐवज करते त्या रिफ्रेश अंतरानंतर पुन्हा करा. ॲड्रेस संच सरकला आणि नियम त्याच्यामागे गेला नाही, तर तुम्ही खरे वर्तन शोधले आहे.
रिझॉल्व्हर धोरणही वेगळे ठेवा. डोमेन नियमाला बरोबर नाव-डेटा लागतो, पण कोणता रिझॉल्व्हर क्वेरीला उत्तर देतो हे तो स्वतः ठरवत नाही.