भौगोलिक DNS र anycast: तपाईंले पाउने VPN प्रवेश जाँच्ने

भौगोलिक DNS र anycast ले फरक नियमअनुसार प्रवेश बिन्दु छान्छन्। उत्तरले कुन रिजोल्भरलाई प्रतिबिम्बित गर्छ जाँच्नुहोस्, त्यसपछि नोड परिवर्तनमा सत्र टिक्छ कि टिक्दैन पनि।

नजिकैको DNS उत्तर समाधान भइसकेको समस्या जस्तो लाग्छ, जबसम्म जडान अन्त कतै पुग्दैन। भौगोलिक DNS र anycast दुवै मार्ग छोटो बनाउन खोज्छन्, र तिनीहरू त्यो निर्णय फरक जानकारीबाट गर्छन्। तपाईंले पुग्ने गेटवे पुग्नयोग्य छ, यसले तपाईंको क्लाइन्टले अपेक्षा गर्ने पहिचान प्रस्तुत गर्छ, वा नोड परिवर्तन हुँदा तपाईंको सत्र टिक्छ भन्ने कुराको कुनै पनि ग्यारेन्टी दिँदैन। तलका जाँचहरूले ती चार प्रश्न छुट्याउँछन्।

रिजोल्भरले वास्तवमा कसको स्थान रिपोर्ट गर्छ जाँच्नुहोस्

टोपोलोजी-संवेदनशील प्रश्नको उत्तर दिने अधिकृत सर्भरले सामान्यतया सोध्ने रिकर्सिभ रिजोल्भरको ठेगाना देख्छ, नाम टाइप गर्ने व्यक्तिको ठेगाना होइन। केन्द्रीकृत रिजोल्भरले सेवा गर्ने क्लाइन्टहरूबाट धेरै टाढा बस्न सक्छ, र उत्तरले तिनीहरूलाई होइन रिजोल्भरलाई प्रतिबिम्बित गर्छ। यो दोष होइन; थप जानकारी नदिएसम्म प्रोटोकल यसै गरी व्यवहार गर्छ। EDNS Client Subnet विनिर्देश ले सीमा र वैकल्पिक उपाय दुवै वर्णन गर्छ।

प्रत्येक सहभागीले समर्थन गरेर सक्षम गरेमा EDNS Client Subnet ले उत्पत्ति-नेटवर्क जानकारी बोक्न सक्छ। यो वैकल्पिक हो, यसका गोपनीयता र क्यासिङ परिणामहरू छन्, र कुनै पनि सार्वजनिक रिजोल्भरले प्रयोगकर्ताको सटीक स्थान रिपोर्ट गर्छ भनी मान्ने अनुमति होइन। यसको वरिपरि डिजाइन गर्नु अघि रिजोल्भर अपरेटरहरूलाई सोध्नुहोस्।

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

anycast रुटिङले के निर्णय गर्‍यो जाँच्नुहोस्

anycast मा, धेरै स्थानहरूले एउटै सेवा ठेगानाको पहुँचयोग्यता विज्ञापन गर्छन्, र नेटवर्कले प्रत्येक क्लाइन्टलाई यसको रुटिङले रुचाउने नोडमा पुर्‍याउँछ। त्यो छनोट नक्साको दूरीले होइन, BGP र वरपरको नीतिले गर्छ। टोपोलोजिकल निकटता सामान्यतया राम्रो राउन्ड-ट्रिप प्रदर्शनसँग बराबर हुँदैन, किनकि छोटो देखिने मार्ग भीडभाडयुक्त वा असममित हुन सक्छ। तपाईंलाई दिइएको ठेगानाले कुन नोडले उत्तर दियो भन्ने केही बताउँदैन।

सेवा दिने स्थान सेवा पक्षबाट, वा यसको नाम राख्ने प्रतिक्रियाबाट पुष्टि गर्नुहोस्, DNS उत्तरबाट मात्र होइन। traceroute -n 198.51.100.20 ले तपाईंले लिएको मार्ग देखाउँछ र अझै त्यसको अन्त्यमा रहेको होस्टको नाम राख्दैन, त्यसैले यसलाई उत्तर होइन मार्गको रूपमा पढ्नुहोस्।

नोड परिवर्तनमा सत्र टिक्छ भनी जाँच्नुहोस्

DNS प्रश्न छोटो हुन्छ र VPN सत्र लामो हुन्छ, र दुवैका स्थिति आवश्यकताहरू पूर्ण रूपमा फरक छन्। सत्रको बीचमा रुटिङ सर्न सक्छ, र त्यसो हुँदा पछिका प्याकेटहरू तपाईंको टनेल कहिल्यै नदेखेको नोडमा पुग्न सक्छन्। त्यो टिकाउ हुन्छ वा हुँदैन भन्ने कार्यान्वयनमा निर्भर छ: साझा स्थिति, जानाजान पुन: जडान, वा दस्तावेज गरिएको असफलता। ठेगानाले मात्र तीमध्ये केही दिँदैन।

परिवर्तन अनुमान नगरी अवलोकन गर्नुहोस्। मार्ग परिवर्तन हुँदा sudo tcpdump -ni any -c 20 esp ले बाहिरी प्याकेटहरू देखाउँछ, र सहकर्मी ठेगानामा अचानक परिवर्तन भनेको हुँदै गरेको परिवर्तन हो। तपाईंले चलाउने कार्यान्वयनका लागि इच्छित व्यवहार स्पष्ट रूपमा परिभाषित गर्नुहोस्, त्यसपछि मार्ग परिवर्तन गर्न बाध्य पारेर परीक्षण गर्नुहोस्। यदि डिजाइनले सत्र प्रतिकृति मान्छ भने, संयन्त्रको नाम राख्नुहोस् र यसले नसमेट्ने असफलताको नाम पनि राख्नुहोस्।

पहिचान अझै मिल्छ भनी जाँच्नुहोस्

प्रत्येक प्रवेश बिन्दुले तपाईंको क्लाइन्ट प्रोफाइलले अपेक्षा गर्ने पहिचान प्रस्तुत गर्नुपर्छ। सेवा नामका लागि जारी गरिएको प्रमाणपत्र नोडहरूभरि काम गर्छ, जबकि प्रति-नोड प्रमाणपत्रहरूले क्लाइन्टलाई नयाँ कुरा स्वीकार्न बाध्य पार्छ, र प्रयोगकर्ताहरूले चेतावनीहरू पछाडि क्लिक गर्न सिक्ने ठाउँ यही हो। अपेक्षित पहिचान र प्रोफाइललाई प्रवेश मोडेलसँग मिलाइ राख्नुहोस्।

असामान्य नोडमा पुगेको क्लाइन्टबाट यो जाँच्नुहोस्, किनकि प्रति-नोड प्रमाणपत्र देखिने अवस्था त्यही हो। openssl s_client -connect vpn.example.com:443 -servername vpn.example.com ले चेन र नामहरू प्रिन्ट गर्छ, जुन क्लाइन्टले तुलना गर्ने कुरा ठ्याक्कै त्यही हो। त्यसपछि प्रोफाइल साँघुरो गर्ने हो कि प्रमाणपत्र मोडेल परिवर्तन गर्ने हो निर्णय गर्नुहोस्।

रेकर्ड जाँच्नुहोस्, पहिलो उत्तर मात्र होइन

तीन परिदृश्यको मूल्याङ्कन गर्नुहोस् र प्रत्येकका लागि चार तथ्य लेख्नुहोस्: सामान्य प्रवेश, एउटा स्थान अनुपलब्ध, र सहमत भएको पुन:प्राप्ति अवस्था। चार तथ्य भनेका प्रयोग गरिएको रिजोल्भर, फर्काइएको ठेगाना, सेवा दिएको स्थान र नयाँ अनुप्रयोग परिणाम हुन्। त्यो रेकर्डले DNS छनोट समस्यालाई गेटवे समस्या, रुटिङ समस्या वा सत्र-स्थिति समस्याबाट छुट्याउँछ। त्यो नभए, चारै क्लाइन्टबाट उस्तै देखिन्छन्।

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

परिदृश्यहरू कार्यालयबाट मात्र होइन, प्रतिनिधि पहुँच नेटवर्कहरूबाट चलाउनुहोस्, किनकि पूरै प्रश्न फरक क्लाइन्टहरूले वास्तवमा कुन प्रवेश बिन्दुमा पुग्छन् भन्ने हो। एउटा नेटवर्क एउटैको नमुना हो।

सम्बन्धित लेखहरू