VPN जोडल्यावरच DNS64 ची उत्तरे का बदलतात?

DNS64 ची उत्तरे सर्व्हरचा गुणधर्म नसून नेटवर्कची मांडणी वर्णन करतात। रिझॉल्व्हर IPv4 पत्त्यावरून IPv6 पत्ता संश्लेषित करतो, आणि निकाल त्या प्रीफिक्सच्या शेवटी भाषांतरकर्ता बसलेला असतो तिथेच काम करतो। मार्गात VPN आणा, आणि ती मांडणी तीन अटींवर अवलंबून टिकू शकते, बदलू शकते किंवा खरी राहणे थांबवू शकते।

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

संश्लेषित AAAA रेकॉर्ड प्रत्यक्षात कशाकडे निर्देश करतो

DNS64 रिझॉल्व्हर फक्त IPv4 असलेल्या नावाच्या AAAA प्रश्नाचे उत्तर IPv4 पत्ता आपण वापरण्यासाठी कॉन्फिगर केलेल्या प्रीफिक्सच्या आत ठेवून देतो, आणि या कामासाठी ज्ञात प्रीफिक्स RFC 6147 मध्ये वर्णन केल्याप्रमाणे 64:ff9b::/96 आहे। ॲप्लिकेशनला रेकॉर्ड इतर कोणत्याही AAAA रेकॉर्डसारखा दिसतो, आणि हाच मुद्दा आहे: फक्त IPv6 असलेला क्लायंट गंतव्यस्थानाला कधीच IPv6 नव्हते हे न कळत जोडणीचा प्रयत्न करू शकतो। मग ती जोडणी मार्गावर कुठेतरी दोन कुटुंबांमध्ये भाषांतर करणाऱ्या NAT64 कार्यावर अवलंबून असते। त्या भाषांतरकर्त्याशिवाय, संश्लेषित पत्ता विश्वासार्ह दिसणारे पण कुठेही न पोहोचणारे गंतव्यस्थान आहे।

म्हणून रेकॉर्ड एकाच वेळी दोन गोष्टी कूटबद्ध करतो: मूळ IPv4 पत्ता आणि भाषांतरकर्ता पोहोचण्यायोग्य आहे हे गृहीतक। उत्तरातच फक्त पहिली गोष्ट दिसते।

तीन अटी ते अजूनही काम करते का हे ठरवतात

पहिली अट म्हणजे कोणत्या रिझॉल्व्हरने रेकॉर्ड तयार केला, कारण DNS64 कॉन्फिगर नसलेला रिझॉल्व्हर त्या नावासाठी काहीही परत देत नाही आणि ॲप्लिकेशन वेगळ्या प्रकारे अपयशी ठरते। दुसरी अट म्हणजे तुमच्या उपकरणाला संश्लेषित प्रीफिक्सपर्यंत मार्ग आहे का, कारण उत्तर वैध असू शकते पण तिथपर्यंतचा रस्ता नसू शकतो। तिसरी अट म्हणजे त्या प्रीफिक्सचा मालक भाषांतरकर्ता तुम्ही वापरणाऱ्या मार्गावर आहे का, कारण 64:ff9b::/96 इतरत्र नेणारा बोगदा वेगळ्या कार्यापर्यंत किंवा काहीही नाही तिथपर्यंत पोहोचतो। तिन्ही बोगद्यापूर्वी खऱ्या असू शकतात आणि नंतर अपयशी ठरू शकतात, आणि म्हणूनच लक्षण अचानक घसरणीसारखे दिसते।

त्या क्रमानेच तपासा। नसलेले उत्तर आणि नसलेला मार्ग ब्राउझरमध्ये सारखेच दिसतात आणि रिझॉल्व्हर लॉगमध्ये पूर्णपणे वेगळे।

रिझॉल्व्हर बदलला की उत्तरही बदलते

VPN क्लायंट अनेकदा स्वतःचा रिझॉल्व्हर लादतो किंवा संपूर्ण प्रश्नमार्ग ताब्यात घेतो, आणि तो रिझॉल्व्हर काहीच संश्लेषित करत नसेल। तेव्हा फक्त IPv4 असलेल्या नावांचे प्रश्न कोणतेही AAAA रेकॉर्ड परत देत नाहीत, जे फक्त IPv6 असलेला क्लायंट पोहोचता न येणारे नाव म्हणून अनुभवतो। उलटेही घडते: खरोखर संश्लेषित करणारा रिझॉल्व्हर तुमचा बोगदा मार्ग वाहून नेणार नाही असा प्रीफिक्स देऊ शकतो।

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

शोध आणि मार्ग स्वतंत्रपणे तपासा

ॲप्लिकेशन गुंतवण्यापूर्वी नावाची थेट विचारणा करा, आणि कोणत्या सर्व्हरने उत्तर दिले ते नोंदवा। खालील आदेश AAAA रेकॉर्ड, वापरला जाणारा रिझॉल्व्हर, आणि संश्लेषित प्रीफिक्सपर्यंत मार्ग आहे का हे दाखवतात। ते बोगदा बंद असताना चालवा, नंतर पुन्हा सुरू असताना।

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

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

प्रत्येक निकालाच्या शेजारी रिझॉल्व्हर, नेटवर्क संदर्भ आणि पत्ता-कुटुंब नोंदवा। पुढील तुलनेला रिझॉल्व्हरचा बदल रूटिंगच्या बदलापासून वेगळा करता येण्याचे कारण तीच नोंद आहे।