VPN गळती दुरुस्त करण्यासाठी IPv6 बंद करायचा? त्याऐवजी धोरण ठरवा
लिंक-लोकल पत्ता गळती नाही आणि जागतिक IPv6 मार्गही नाही. आधी अडवणे, वाहून नेणे किंवा तसेच ठेवणे यातून निवडा.
IPv6 श्रेणीतील पत्ता चाचणी पानावर दिसतो, बोगदा तो स्पष्टपणे वाहून नेत नाही, आणि इंटरनेटवरील सर्वात लोकप्रिय सल्ला म्हणजे IPv6 सर्वत्र बंद करणे. तो आदेश पॅनेल खरोखर शांत करतो. पण तो प्रवेश जाळ्याला अवलंबून असू शकणारा प्रोटोकॉलही काढून टाकतो, आणि पत्ता खरी गळती होता, लिंक-लोकल इंटरफेस पत्ता होता, की आपले काम करणारा रिझॉल्व्हर होता याची कल्पनाही तुमच्याकडे ठेवत नाही. योग्य नियंत्रण तीन अटी ठरवतात, आणि त्यातील फक्त एकच अडवण्याकडे नेते.
साधनाने प्रत्यक्षात काय मोजले ते ओळखा
सर्वात सामान्य खोटा इशारा म्हणजे लिंक-लोकल पत्ता, जो fe80: ने सुरू होतो आणि IPv6 सक्षम प्रत्येक इंटरफेसवर असतो, मशीन IPv6 द्वारे इंटरनेटपर्यंत पोहोचू शकते की नाही याच्याशी संबंध नाही. तो इंटरफेस याद्यांमध्ये आणि काही अनुप्रयोग निदानांमध्ये दिसतो, आणि तुमच्या रहदारीच्या मार्गाबद्दल काहीही सांगत नाही.
दुसरा खोटा इशारा म्हणजे fc00::/7 मधील अद्वितीय स्थानिक पत्ता, जो जाळ्यात वापरली जाणारी खाजगी श्रेणी आहे. होस्टचा प्रत्येक पत्ता छापणारे साधन तो सार्वजनिक पत्त्याच्या शेजारी आनंदाने सूचीबद्ध करेल. घाईघाईने वाचणारा कोणी त्याला गळती म्हणतो, आणि मग नसलेल्या समस्येवर एक तास घालवतो.
तिसरा मुळीच खोटा इशारा नाही. बोगद्याबाहेर इंटरनेटपर्यंत पोहोचणारा जागतिक पत्ता हीच खरी गळती आहे, आणि काहीही ठरवण्यापूर्वी तो मोजणे योग्य आहे:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coपहिला आदेश जागतिक पत्ता छापत असेल आणि तिसरा बोगद्याचा नसलेला सार्वजनिक IPv6 पत्ता परत देत असेल, तर बोगद्याबाहेर तुमचा खरा मार्ग आहे. पहिला लिंक-लोकल नोंदींशिवाय काहीही छापत नसेल, तर दुरुस्त करण्यासारखी गळती कधीच नव्हती.
नियंत्रण तीन अटी ठरवतात
निर्णय "IPv6 चांगला" किंवा "IPv6 वाईट" नाही. निर्णय हा आहे की तुम्ही तीन परिस्थितींपैकी कोणत्या आहात, आणि प्रत्येकाचे योग्य उत्तर वेगळे आहे आणि चूक केल्यास किंमतही वेगळी आहे.
| Situation | Correct control | Cost if you disable IPv6 instead |
|---|---|---|
| Exit has no IPv6, host does | Block IPv6 deliberately in the tunnel policy | Same visible result, no documentation of intent |
| Exit carries IPv6, host leaks | Route IPv6 into the tunnel and verify | You lose IPv6 reachability entirely |
| Access network is IPv6-only | Change nothing; use the tunnel's IPv6 | Machine loses connectivity completely |
पहिली ओळ म्हणजे लोक सामान्यतः जे म्हणतात ती, आणि ती योग्य आहे. ज्या क्लायंटच्या एक्झिटला IPv6 आधार नाही, त्याने होस्टची स्वतःची IPv6 रहदारी शांतपणे बाहेर जाऊ देऊ नये, कारण तीच नोंदवलेली दुहेरी-स्टॅक गळती आहे. मुद्दा हा आहे की तिला घोषित धोरण म्हणून अडवणे, कर्नेलमध्ये प्रोटोकॉल बंद करणे नाही. दिसणारा परिणाम सारखाच आहे आणि नंतर तपासता येईल अशी फक्त एकच.
तिसरी ओळ म्हणजे जिथे सामान्य सल्ला सक्रियपणे हानिकारक होतो. मोबाइल ऑपरेटर आणि काही घरगुती जोडण्या IPv4 गंतव्यांसाठी भाषांतरासह IPv6-only जाळी चालवतात. तिथे IPv6 काढला तर जाळ्याने दिलेले एकमेव वाहन काढून टाकता, ज्यामुळे तुम्ही डीबग करत असलेल्या व्यत्ययापेक्षा खूप वाईट खंड पडतो.
एक्झिटला IPv6 नसेल तर जाणूनबुजून अडवा
क्लायंटच्या स्वतःच्या यंत्रणेला प्राधान्य द्या, कारण ती बोगदा उभा असेपर्यंत नेमकी लागू होते आणि तो पडल्यावर मागे घेतली जाते. OpenVPN कडे यासाठी पर्याय आहे, आणि इतर क्लायंटसाठी iptables कडे समतुल्य नियम आहे:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableनिर्देश प्रोफाइलमध्ये असतो; नियम त्या फायरवॉलमध्ये असतो जी तुम्ही तपासू आणि काढू शकता. दोन्ही बंद स्थितीत अयशस्वी होतात, जे तुम्हाला हवे आहे, आणि दोन्ही कॉन्फिगरेशन डिफमध्ये दिसतात, जे स्टार्टअप स्क्रिप्टमध्ये पुरलेले कर्नेल sysctl दिसत नाही.
तो का आहे ते नोंदवा. टिप्पणी नसलेला अडवण्याचा नियम IPv6 दुसऱ्या कशासाठी तरी लागणाऱ्या पुढच्या व्यक्तीने काढून टाकतो, आणि मग गळती शांतपणे परत येते.
एक्झिट IPv6 वाहून नेत असेल तर मार्ग करा आणि दोन्ही कुटुंबे तपासा
सर्व्हरला आधार असेल तर IPv6 वाहून नेणे हे चांगले उत्तर आहे, आणि ते फार कठीण नाही. अट अशी आहे की बोगदा इंटरफेसकडे त्या कुटुंबाचा पत्ता असावा आणि त्याचा डीफॉल्ट मार्ग भौतिक इंटरफेसबाहेर नाही तर बोगद्यात आत दाखवावा:
ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.coमार्ग शोध हीच निर्णायक चाचणी: तो बोगदा इंटरफेसचे नाव घेत असेल तर IPv6 रहदारी वाहून नेली जात आहे. मग दोन curl कॉल प्रत्येक कुटुंब काय पाहते ते पुष्टी करतात, आणि त्यांची तुलना करणे हाच दोन्ही मार्ग आता एकाच एक्झिटने बाहेर पडतात हे सिद्ध करण्याचा मार्ग आहे.
यशस्वी जोडणीवर थांबू नका. बोगदा पुन्हा जोडा आणि पुन्हा तपासा, कारण सर्व्हरने तो फक्त सुरुवातीच्या कॉन्फिगरेशनमध्ये पाठवला तर ढकललेला IPv6 मार्ग पुनर्स्थापनेत हरवू शकतो. मग एक वगळलेले गंतव्य तपासा, कारण स्प्लिट-टनेल नियमांमध्येच दोन्ही कुटुंबे सर्वाधिक वेगळी होतात.
प्रवेश जाळे फक्त IPv6 असेल तर तसेच ठेवा
काही जाळी फक्त IPv6 देतात आणि उपकरण ऑपरेटरच्या बाजूच्या भाषांतर यंत्रणेमार्फत IPv4 सेवांपर्यंत पोहोचेल अशी अपेक्षा करतात. अशा मशीनवर IPv6 बंद करणे सुरक्षा सुधारणा नाही; ते कशाकडेही जाणारा एकमेव मार्ग काढून टाकते. हा स्वतः निर्माण केलेला खंड आहे, ज्याची कोणालाही गरज नव्हती अशा चाचणी निकालासाठी.
इथे चूक करण्याचे लक्षण वेगळे आणि अप्रिय आहे: बोगदा स्थापित होत असल्यासारखे दिसते, नाव विश्लेषण चालते, आणि काहीही लोड होत नाही. IPv6 बदलानंतर असे दिसल्यास लगेच सेटिंग परत आणा आणि निदान दुसरीकडे सुरू ठेवा.
तुम्ही काहीही निवडले तरी निर्णय प्रोफाइल किंवा फायरवॉलमध्ये स्पष्ट ठेवा, एक्झिट प्रत्यक्षात कशाला आधार देते त्याला जोडा, आणि RFC 7359 ची दुहेरी-स्टॅक चर्चा जे दुहेरी-स्टॅक वर्तन वर्णन करते ते नोंदवा. घोषित अडवणूक हे धोरण आहे. बंद केलेला प्रोटोकॉल हा असा मार्ग आहे जो कोणीही लेखापरीक्षण करू शकत नाही, आणि चाचणी पानावरून दोन्ही सारखेच दिसतात.