वांछित एज डीएनएस कार्यान्वयन और आईपी एनीकास्ट एड्रेस प्राप्त करने तक का सफर - route64.org
नमस्ते, मैं मुनौ (Munou) हूँ।
मैं Edge DNS और CDN बनाने के लिए संघर्ष कर रहा हूँ।
वर्तमान स्थिति
यह एक छद्म (pseudo) वितरण है।
edge.soulminingrig.com के CNAME में pool.soulminingrig.com को पंजीकृत करना किसी तरह के वितरण के लिए है... वर्तमान में यह अर्थहीन है।
$dig www.soulminingrig.com AAAA +short
edge.soulminingrig.com.
pool.soulminingrig.com.
2400:8500:2002:3317:163:44:113:145
2a11:6c7:f07:156::2$dig www.soulminingrig.com A +short
edge.soulminingrig.com.
pool.soulminingrig.com.
163.44.113.145
91.98.169.80किसी कारण से, यह अभी भी निकटतम सर्वर से वितरित किया जा रहा है
फिर भी, HTTP के मामले में, क्लाइंट साइड की बदौलत, और जो आश्चर्यजनक है वह यह है कि HTTP क्लाइंट वास्तव में निकटतम सर्वर तक पहुँचने के लिए बने होते हैं। मुझे नहीं पता कि DNS सर्वर इसे अच्छी तरह से वितरित कर रहा है या नहीं। मुझे नहीं पता कि यह ConoHa DNS का उपयोग करने के कारण है या नहीं, क्योंकि विस्तृत विशिष्टताओं तक कोई जानकारी उपलब्ध नहीं है।
जर्मनी के एक सर्वर से
IPv6:
# curl -I6s https://www.soulminingrig.com/ -vvv 2>&1 | head
01:36:56.631373 [0-x] == Info: [READ] client_reset, clear readers
01:36:57.350639 [0-0] == Info: Host www.soulminingrig.com:443 was resolved.
01:36:57.350725 [0-0] == Info: IPv6: 2a11:6c7:f07:156::2, 2400:8500:2002:3317:163:44:113:145
01:36:57.350801 [0-0] == Info: IPv4: (none)
01:36:57.350916 [0-0] == Info: [HTTPS-CONNECT] adding wanted h2
01:36:57.350949 [0-0] == Info: [HTTPS-CONNECT] added
01:36:57.350980 [0-0] == Info: [HTTPS-CONNECT] connect, init
01:36:57.351107 [0-0] == Info: Trying [2a11:6c7:f07:156::2]:443...
01:36:57.351308 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
01:36:57.351344 [0-0] == Info: [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0IPv4:
# curl -I4s https://www.soulminingrig.com/ -vvv 2>&1 | head
01:38:31.901521 [0-x] == Info: [READ] client_reset, clear readers
01:38:32.847878 [0-0] == Info: Host www.soulminingrig.com:443 was resolved.
01:38:32.847999 [0-0] == Info: IPv6: (none)
01:38:32.848050 [0-0] == Info: IPv4: 91.98.169.80, 163.44.113.145
01:38:32.848139 [0-0] == Info: [HTTPS-CONNECT] adding wanted h2
01:38:32.848251 [0-0] == Info: [HTTPS-CONNECT] added
01:38:32.848315 [0-0] == Info: [HTTPS-CONNECT] connect, init
01:38:32.848440 [0-0] == Info: Trying 91.98.169.80:443...
01:38:32.848657 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
01:38:32.848723 [0-0] == Info: [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0घर के वातावरण से
IPv6:
$curl -I6s https://www.soulminingrig.com/ -vvv 2>&1 | head
01:39:23.182757 [0-x] * [READ] client_reset, clear readers
01:39:23.227731 [0-0] * Host www.soulminingrig.com:443 was resolved.
01:39:23.227855 [0-0] * IPv6: 2400:8500:2002:3317:163:44:113:145, 2a11:6c7:f07:156::2
01:39:23.227996 [0-0] * IPv4: (none)
01:39:23.228072 [0-0] * [HTTPS-CONNECT] adding wanted h2
01:39:23.228171 [0-0] * [HTTPS-CONNECT] added
01:39:23.228253 [0-0] * [HTTPS-CONNECT] connect, init
01:39:23.228369 [0-0] * Trying [2400:8500:2002:3317:163:44:113:145]:443...
01:39:23.228605 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
01:39:23.228711 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0IPv4:
$curl -I4s https://www.soulminingrig.com/ -vvv 2>&1 | head
01:40:52.285758 [0-x] * [READ] client_reset, clear readers
01:40:52.316059 [0-0] * Host www.soulminingrig.com:443 was resolved.
01:40:52.316177 [0-0] * IPv6: (none)
01:40:52.316239 [0-0] * IPv4: 163.44.113.145, 91.98.169.80
01:40:52.316340 [0-0] * [HTTPS-CONNECT] adding wanted h2
01:40:52.316440 [0-0] * [HTTPS-CONNECT] added
01:40:52.316522 [0-0] * [HTTPS-CONNECT] connect, init
01:40:52.316638 [0-0] * Trying 163.44.113.145:443...
01:40:52.316822 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
01:40:52.316929 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0चाहे मैं कितनी भी बार कोशिश करूँ, यह उसी निकटतम IP तक पहुँचता है। अद्भुत।
मुझे लगता है कि शायद ConoHa DNS खुद इस तरह से बनाया गया है कि यह निकटतम IP पते से वितरित हो, क्योंकि इसके बिना यह काम नहीं करेगा।
$dig a.conoha-dns.com +short
157.7.32.89
$dig b.conoha-dns.org +short
157.7.33.89यदि ConoHa के प्राथमिक और द्वितीयक DNS सर्वर सेट हैं और a.conoha-dns.com डाउन हो जाता है, तो b.conoha-dns.org से पूछताछ न होने पर इसका कोई मतलब नहीं है। मुझे आश्चर्य है कि मैंने इस पर पहले ध्यान क्यों नहीं दिया, लेकिन यदि क्लाइंट साइड एक DNS सर्वर के डाउन होने पर दूसरे सक्रिय सर्वर पर समाधान नहीं कर सकता, तो प्राथमिक और द्वितीयक होने का कोई मतलब नहीं है।
यह बहुत अच्छी तरह से बनाया गया है... इसका मतलब है कि भले ही कई A रिकॉर्ड पंजीकृत हों, यह एक तरह से काम कर रहा है।
फिर भी मैं इसे और अधिक वितरित करना चाहता हूँ
वास्तव में, यह पहले से ही पर्याप्त है, लेकिन यदि इसे और अधिक वितरित किया जा सके, तो स्व-वितरित DNS या स्व-वितरित CDN बनाना संभव होगा। वर्तमान में, यदि दो स्थानों के कैश सर्वर डाउन हो जाते हैं, तो संचार संभव नहीं होगा।
शायद प्रमुख क्लाउड प्रदाताओं ने इस वितरित प्रणाली के निर्माण के लिए भारी बुनियादी ढांचे और धन का निवेश किया है, जो थोड़ा डरावना है।
आसान वितरण के बारे में सोचना
यदि लक्ष्य केवल विफलता के एकल बिंदु (Single Point of Failure) से बचना है, तो आप IP Anycast का उपयोग करके कई स्थानों से एक ही IP पता प्रसारित कर सकते हैं। हालाँकि, इसके लिए BGP का सेटअप होना आवश्यक है, जो व्यक्तियों के लिए एक बड़ी बाधा है:
ASN प्राप्त करना
BGP सेटअप के लिए आवश्यक सबनेट मान प्राप्त करना
मुझे नहीं लगता कि इनमें से कोई भी लागत या प्रक्रियाओं के मामले में किसी व्यक्ति के लिए आसानी से किया जा सकता है।
दूसरे शब्दों में, यदि आप उन चरणों को छोड़ सकते हैं और केवल IP Anycast या वह IP पता प्राप्त कर सकते हैं, तो कोई समस्या नहीं होगी।
हालाँकि, मूल रूप से किसी तीसरे पक्ष के स्वामित्व वाले IP पते का उपयोग करना शिष्टाचार के अनुसार सही नहीं है।
route64.org
मुझे यह मिल गया। यह IPv6 को बढ़ावा देने वाला एक गैर-लाभकारी संगठन लगता है।
हालाँकि, मुफ़्त में क्या उपलब्ध है, इसकी पूरी जानकारी नहीं है, लेकिन यह मुख्य रूप से IPv6 टनल जैसा लगता है, और अन्य सेवाओं के लिए आपको दान के माध्यम से अंक (points) मिलते हैं। ऐसा लगता है कि आप उन अंकों का उपयोग BGP या पूरी तरह से प्रबंधित IP Anycast सेवाओं के लिए कर सकते हैं।
भले ही इसमें पैसा खर्च होता है, लेकिन आप केवल कुछ डॉलर में Anycast पता प्राप्त कर सकते हैं, जो अद्भुत है। वैसे, ऐसा लगता है कि बैंडविड्थ सीमाएं हैं, इसलिए उस पर ध्यान दें। चूँकि यह केवल एक टनल है, आप वास्तव में इसके मालिक नहीं हो सकते।
मुझे परेशानी हुई क्योंकि जापानी भाषी समुदाय में इसके बारे में कोई जानकारी नहीं थी।
मैं अपने Hetzner IPv4 सर्वर में IPv6 जोड़ना चाहता था, इसलिए मैंने इसे आज़माया। वैसे, Hetzner पर पहले से ही IPv4 वाले सर्वर में IPv6 पता जोड़ने पर प्रति माह अतिरिक्त $1 खर्च होता है। मैंने सोचा, 'क्या वे IPv6 पते के लिए भी पैसे लेते हैं?' और मुझे खुशी है कि मैंने इसे वहां से नहीं लिया।
चूँकि यह वास्तव में एक IPv6 Tunnel है, इसलिए आपको उस बारे में सावधान रहने की आवश्यकता है।
जो चीज़ आश्चर्यजनक रूप से सुविधाजनक है वह यह है कि यदि आप इसे बहुत खराब प्रतिक्रिया विलंबता (latency) वाले VPS आदि के लिए रिले के रूप में उपयोग करते हैं, तो SSH क्लाइंट और SSH सर्वर के बीच इस IPv6 पते को जारी करने और रिले करने से यह काफी आरामदायक हो जाता है।
IPv6 टनल का उपयोग करना
नीचे 'add tunnelbroker' चुनें
और फिर टनलिंग विधि चुनें
मैंने WireGuard को चुना क्योंकि यह आसान है और मैंने इसे पहले ही अपने सर्वर पर इंस्टॉल कर लिया था।
अब, उस सर्वर का IPv4 पता जोड़ें जिसे आप IPv6 देना चाहते हैं। दूसरे शब्दों में, यह WireGuard क्लाइंट-साइड सेटिंग है।
मेरे मामले में, यह 91.98.169.80 है। यह WireGuard कॉन्फ़िगरेशन फ़ाइल तैयार करेगा, इसलिए आपको बस wg-quick up conf-file करना होगा।
हाँ, जैसा कि आप में से कुछ ने देखा होगा, इस ब्लॉग के AAAA रिकॉर्ड का दूसरा IPv6 पता इसी तरह प्राप्त किया गया था।
Anycast सेवा IPv4 के लिए भी उपलब्ध है
मुझे लगा कि सेवा के नाम के कारण यह केवल IPv6 के लिए है, लेकिन ऐसा लगता है कि Anycast पते IPv4 का भी समर्थन करते हैं। अद्भुत।
तो, मैं जल्द ही एक Anycast पता प्राप्त करने का प्रयास करूँगा। साथ ही, मैंने IPv4 सबनेट प्राप्त करने की उम्मीद नहीं छोड़ी है, इसलिए मुझे यह शोध करने के लिए कुछ समय चाहिए कि क्या इसे यथासंभव कम लागत पर बनाए रखने का कोई तरीका है।