CDN ने पत्ते बदलल्यावर VPN डोमेन नियम तुटतो

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

एक शोध इन्व्हेंटरी का नाही

कंटेंट-डिलिव्हरी नेटवर्क रिझोल्व्हर, प्रदेश आणि क्षणासाठी निवडलेल्या पत्त्यासह उत्तर देते। वेगवेगळ्या नेटवर्कमधून दोन वेळा विचारा आणि तुम्हाला वेगळी उत्तरे मिळू शकतात। एकदा विचारा आणि उत्तराला सेवेची पत्ता-यादी माना, तर तुम्ही लिहिलेला नियम नियम नाही, स्नॅपशॉट आहे। DNS उत्तराला कॉन्फिगरेशन मानण्याची सगळी अडचण हीच आहे।

दुसरी पोकळी आहे। एक दिसणारे होस्टनाव संपूर्ण अनुप्रयोग क्वचितच व्यापते, कारण लॉगिन, मीडिया आणि API रहदारी अनेकदा वेगळी नावे वापरतात। पत्ता पट्टीमधील होस्टनावावरून बांधलेला नियम पृष्ठ व्यापू शकतो आणि व्हिडिओ चुकवू शकतो, जे राउटिंग त्रुटी नव्हे तर अंशतः अपयश म्हणून वाचले जाते।

तिसरी पोकळी पत्ता-कुटुंब आहे। फक्त v4 साठीचा नियम AAAA रेकॉर्डबद्दल काहीच सांगत नाही, जे क्लायंटला आवडू शकते।

डोमेन नियम किंवा श्रेणी ठरवणाऱ्या तीन अटी

प्रथम, सेवा स्थिर प्रीफिक्सचा संच प्रकाशित करते का जो तुम्ही बाळगू आणि दस्तऐवजीकरण करू शकता? जर होय, तर स्पष्ट श्रेणी प्रामाणिक आणि स्वस्त आहेत। जर नाही, तर डोमेन नियम हाच सेवेचा मागोवा घेऊ शकणारा एकमेव मार्ग आहे।

दुसरे, तुमच्या क्लायंटची डोमेन पद्धत रिफ्रेश होते का? जो नियम कनेक्ट होताना एकदा सोडवला जातो आणि नंतर कधीच नाही, तो चांगल्या ब्रँडिंगचा स्नॅपशॉट आहे। तिसरे, पद्धत सबडोमेन आणि दोन्ही पत्ता-कुटुंबे व्यापते का, की फक्त तुम्ही टाइप केलेली नावे?

या तीनांना उत्तर द्या आणि निवड सहसा स्पष्ट असते। अंदाज लावल्याने असा नियम तयार होतो जो चाचणीत चालतो आणि उत्पादनात अपयशी ठरतो।

सत्र तपासा, पृष्ठ नाही

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

पृष्ठ काय दाखवते त्याऐवजी सत्र प्रत्यक्षात कशाशी संपर्क साधते त्याची यादी करा:

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

तुलनेदरम्यान रिझोल्व्हर दिसत ठेवा, कारण एका रिझोल्व्हरवरून चालणारा आणि दुसऱ्यावरून अपयशी ठरणारा नियम तुम्हाला CDN च्या उत्तराबद्दल सांगतो, बोगद्याबद्दल नाही। कमी TTL म्हणजे तुम्ही नोंदवलेल्या उत्तराला मुदत आहे असाही अर्थ।

प्रत्येक पद्धत प्रत्यक्षात काय व्यापते

दोन्ही पद्धती सेटिंग्ज पृष्ठावर अदलाबदल करण्यायोग्य दिसतात आणि आतून वेगळ्या वागतात।

कर्नेल पत्ता-मार्ग प्रीफिक्स जुळवतो। त्याला होस्टनाव काय आहे हे माहीत नाही, म्हणून तो पत्ते बदलणाऱ्या सेवेचा मागोवा घेऊ शकत नाही। डोमेन नियम नावे सोडवतो आणि निकाल राउट करतो; तो सेवेचा मागोवा घेतो पण रिझोल्व्हर, रिफ्रेश वर्तन आणि सबडोमेनबाबत क्लायंटच्या हाताळणीवर अवलंबून असतो, म्हणून नावांचा मागोवा घेणारा नियम क्लायंट प्रत्यक्षात वापरत असलेल्या रिझोल्व्हरसह तपासला पाहिजे।

दोन्हीपैकी एकही दुसऱ्याचा सुपरसेट नाही, म्हणून नोंदीशिवाय ते मिसळल्यास नंतर गोंधळ होतो।

सेवा बदलल्यानंतर पुन्हा तपासा

क्लायंट अपडेट किंवा सेवा बदलानंतर तेच सत्र चाचणी पुन्हा चालवा। पूर्वी चाललेली पत्ता-यादी त्या कालावधीचा पुरावा आहे, सेवेच्या पायाभूत सुविधांची कायमची इन्व्हेंटरी नाही।

कोणती पद्धत कोणते होस्टनाव व्यापते आणि शेवटच्या तपासणीची तारीख लिहा।

ही नोंद म्हणजे तुम्ही रक्षण करू शकता अशा नियमातील आणि कोणीही स्पर्श करण्याची हिंमत न करणाऱ्या नियमातील फरक। सेवा स्वतःची प्रीफिक्स यादी प्रकाशित करत असेल, तर ती वापरा आणि तारीख नमूद करा। जर नसेल, तर तसे सांगा, आणि डोमेन नियम त्याच्या रिफ्रेश वर्तनासह शेजारी लिहून ठेवा।