VPN डोमेन नियम टूट जाता है जब CDN अपने पते बदलता है

आप एक लुकअप से पता अपने रूटिंग नियम में कॉपी करते हैं, साइट काम करती है, और एक सप्ताह बाद नहीं करती। नियम में कुछ नहीं बदला। सेवा दूसरे एज पते पर चली गई, क्लाइंट ने दूसरा होस्टनाम हल किया, या सत्र IPv6 पर चला गया। आपके सामने निर्णय यह है कि नाम-आधारित नियम या स्पष्ट श्रेणी इस सेवा के लिए सही साधन है, और तीन शर्तें इसे तय करती हैं। आगे जो है वह नाम को पते से अलग करता है, क्योंकि उनमें से केवल एक स्थिर है।

एक लुकअप इन्वेंटरी क्यों नहीं है

एक कंटेंट-डिलीवरी नेटवर्क रिज़ॉल्वर, क्षेत्र और क्षण के लिए चुने गए पते के साथ उत्तर देता है। अलग नेटवर्क से दो बार पूछें और आपको अलग उत्तर मिल सकते हैं। एक बार पूछें और उत्तर को सेवा की पता-सूची मान लें, तो आप जो नियम लिखते हैं वह नियम नहीं, स्नैपशॉट है। DNS उत्तर को कॉन्फ़िगरेशन मानने की पूरी समस्या यही है।

दूसरा अंतराल है। एक दिखने वाला होस्टनाम शायद ही पूरे एप्लिकेशन को कवर करता है, क्योंकि लॉगिन, मीडिया और API ट्रैफ़िक अक्सर अलग नाम इस्तेमाल करते हैं। एड्रेस बार के होस्टनाम से बना नियम पृष्ठ को कवर कर सकता है और वीडियो चूक सकता है, जिसे रूटिंग त्रुटि नहीं बल्कि आंशिक विफलता के रूप में पढ़ा जाता है।

तीसरा अंतराल पता-परिवार है। केवल v4 के लिए नियम AAAA रिकॉर्ड के बारे में कुछ नहीं कहता, जिसे क्लाइंट पसंद कर सकता है।

डोमेन नियम या श्रेणियाँ तय करने वाली तीन शर्तें

पहला, क्या सेवा स्थिर प्रीफ़िक्स का ऐसा सेट प्रकाशित करती है जिसे आप रख सकें और दस्तावेज़ कर सकें? यदि हाँ, तो स्पष्ट श्रेणियाँ ईमानदार और सस्ती हैं। यदि नहीं, तो डोमेन नियम ही एकमात्र तंत्र है जो सेवा का अनुसरण कर सकता है।

दूसरा, क्या आपके क्लाइंट का डोमेन तंत्र रीफ़्रेश होता है? जो नियम कनेक्ट होते समय एक बार हल होता है और फिर कभी नहीं, वह बेहतर ब्रांडिंग वाला स्नैपशॉट है। तीसरा, क्या तंत्र सबडोमेन और दोनों पता-परिवारों को कवर करता है, या केवल उन नामों को जो आपने टाइप किए?

इन तीनों का उत्तर दें और चुनाव आमतौर पर स्पष्ट हो जाता है। अनुमान ऐसा नियम बनाता है जो परीक्षण में काम करता है और उत्पादन में विफल होता है।

सत्र जाँचें, पृष्ठ नहीं

पृष्ठ लोड करें, फिर वह क्रिया करें जो मायने रखती है: साइन इन करें, प्लेबैक शुरू करें, फ़ाइल अपलोड करें। इनमें से प्रत्येक अलग होस्ट तक पहुँच सकता है, और जो विफल होता है वही आपके नियम से छूटा हुआ है।

पृष्ठ क्या दिखाता है उसके बजाय यह सूची बनाएँ कि सत्र वास्तव में किससे संपर्क करता है:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

तुलना के दौरान रिज़ॉल्वर दिखाई देता रखें, क्योंकि एक रिज़ॉल्वर से काम करने वाला और दूसरे से विफल होने वाला नियम आपको CDN के उत्तर के बारे में बताता है, टनल के बारे में नहीं। कम TTL का यह भी अर्थ है कि आपके द्वारा दर्ज उत्तर की एक समाप्ति तिथि है।

प्रत्येक तंत्र वास्तव में क्या कवर करता है

दोनों तंत्र सेटिंग्स पृष्ठ पर विनिमेय दिखते हैं और भीतर से अलग व्यवहार करते हैं।

कर्नेल पता-मार्ग प्रीफ़िक्स का मिलान करता है। उसे पता ही नहीं कि होस्टनाम क्या है, इसलिए वह पते बदलने वाली सेवा का अनुसरण नहीं कर सकता। डोमेन नियम नाम हल करता है और परिणाम को रूट करता है; यह सेवा का अनुसरण करता है पर रिज़ॉल्वर, रीफ़्रेश व्यवहार और सबडोमेन के प्रति क्लाइंट के व्यवहार पर निर्भर करता है, इसलिए नामों का अनुसरण करने वाला नियम उसी रिज़ॉल्वर के साथ जाँचा जाना चाहिए जो क्लाइंट वास्तव में इस्तेमाल करता है।

कोई भी दूसरे का सुपरसेट नहीं है, इसलिए बिना नोट के दोनों को मिलाने से बाद में भ्रम पैदा होता है।

सेवा बदलने के बाद फिर जाँचें

क्लाइंट अपडेट या सेवा परिवर्तन के बाद वही सत्र परीक्षण फिर चलाएँ। पहले काम करने वाली पता-सूची उस अवधि का प्रमाण है, सेवा के ढाँचे की स्थायी इन्वेंटरी नहीं।

लिखें कि कौन-सा तंत्र किस होस्टनाम को कवर करता है, और अंतिम सत्यापन की तारीख।

यही नोट उस नियम के बीच का अंतर है जिसकी आप रक्षा कर सकते हैं और उस नियम के बीच जिसे कोई छूने की हिम्मत नहीं करता। यदि सेवा अपनी प्रीफ़िक्स सूची प्रकाशित करती है, तो उसका उपयोग करें और तारीख बताएँ। यदि नहीं, तो यह कहें, और डोमेन नियम को उसके रीफ़्रेश व्यवहार के साथ बगल में लिखा रखें।