आपका IPv4 VPN नियम IPv6 ट्रैफ़िक के बारे में कुछ नहीं कहता

एक ऑडिट पाता है कि उसी इंटरफ़ेस पर टनल IPv4 के लिए कसकर फ़िल्टर की गई है और IPv6 के लिए पूरी तरह खुली है। टाइपो के अर्थ में कुछ भी गलत कॉन्फ़िगर नहीं था; नियम-समूह ने बस एक परिवार का वर्णन किया और सबने मान लिया कि दूसरा उसका अनुसरण करता है। ऐसा शायद ही होता है। तीन शर्तें तय करती हैं कि आपका नियम वास्तव में दोनों को कवर करता है या नहीं, और पहली नीति के बजाय प्लेटफ़ॉर्म के बारे में है।

शर्त एक: क्या प्लेटफ़ॉर्म में एक तालिका है या दो

कुछ पैकेट फ़िल्टर IPv4 और IPv6 को पूरी तरह अलग नियम-समूहों में रखते हैं, इसलिए एक में जोड़ा गया नियम दूसरे पर तब तक कोई असर नहीं करता जब तक कोई उसे डुप्लिकेट न करे। अन्य ऐसा परिवार देते हैं जो दोनों से मेल खाता है और प्रति पैकेट पतों का अनुवाद करता है। तीसरा समूह एक ही नीति-भाषा रखता है पर उसके पीछे प्रति परिवार अलग ऑब्जेक्ट संग्रहीत करता है।

आप जो फ़िल्टर वास्तव में चलाते हैं उसका दस्तावेज़ पढ़ें, फिर सूची बनाएँ कि कौन-सी तालिकाएँ मौजूद हैं और आपके बदलाव ने किसे छुआ। IPv4 तालिका में नियमों की गिनती उस सवाल का जवाब देती है जो किसी ने नहीं पूछा। फिर सूची बनाएँ कि कौन-सी तालिकाएँ मौजूद हैं और आपके बदलाव ने किसे छुआ।

शर्त दो: नीति कहाँ लागू होती है

तीन जगहें आपस में मिल जाती हैं: वह श्रोता जो टनल स्वीकार करता है, वह पथ जो ट्रैफ़िक आगे भेजता है, और वह सामान्य इंटरफ़ेस जो ग्राहक तब उपयोग करता है जब टनल कोई प्रवाह नहीं ले जा रही होती। एक गेटवे सत्र स्वीकार कर सकता है और साथ ही उससे आगे भेजा गया सब कुछ गिरा सकता है, और यह फ़िल्टर के बजाय टूटी टनल जैसा दिखता है। कुछ भी लिखने से पहले यह भ्रम दूर करें, क्योंकि तीनों जगहों के मालिक और लॉग अलग हैं। बदलाव के रिकॉर्ड में उनके नाम लिखना ही सुधार को खराबी से एक परत दूर उतरने से रोकता है।

लिखें कि आपका नियम तीनों में से किसे नियंत्रित करने के लिए है। श्रोता की रक्षा करने वाला नियम आगे भेजे गए पथ की रक्षा नहीं करता, और दोनों में से कोई भी ग्राहक के सीधे मार्ग को नहीं बंद करता। ध्यान दें कि प्रत्येक जगह का मालिक कौन है, क्योंकि अधिकांश संगठनों में जवाब अलग टीम है।

शर्त तीन: IPv6 को क्या करना चाहिए

तय करें कि IPv6 टनल से होकर जाता है, सुरक्षा उपलब्ध न होने पर अवरुद्ध होता है, या किसी प्रलेखित अपवाद का पालन करता है। हर जवाब अलग नियम-समूह बनाता है, और सवाल को खुला छोड़ना ही वह तरीका है जिससे मूल IPv6 वाला ग्राहक टनल के बाहर उन गंतव्यों तक पहुँच जाता है जहाँ वह IPv4 पर टनल के भीतर पहुँचता है।

नियम लिखने से पहले जवाब ज़ोर से कहें। जो टनल IPv6 नहीं ले जाती उसके लिए अवरोधन वैध विकल्प है, बशर्ते वह जानबूझकर और परखा हुआ हो, खाली तालिका का आकस्मिक नतीजा न हो। जो प्रलेखित नहीं है उसे आगे नियमों को छूने वाला कोई फिर से तय करेगा, और आम तौर पर जल्दबाज़ी में।

ICMPv6 नियंत्रण ट्रैफ़िक है

पड़ोसी खोज और पथ प्रतिक्रिया दोनों ICMPv6 पर चलते हैं, इसलिए IPv4 की आदत से नकल किया गया व्यापक ड्रॉप पतों और बड़े स्थानांतरणों को एक साथ तोड़ देता है। व्यापक अनुमति भी जवाब नहीं है, क्योंकि वह ऐसा चैनल सौंप देती है जिसे कोई नहीं देख रहा।

महत्वपूर्ण संदेश प्रकारों के लिए फ़िल्टरिंग मार्गदर्शन का पालन करें और बाकी को कारण के साथ अस्वीकार करें। जिस खराबी का सबसे अधिक गलत निदान होता है वह है गायब Packet Too Big संदेश, जो ऐसे कनेक्शन के रूप में दिखता है जो खुलता है और फिर अटक जाता है।

इसे साबित करना, एक बार में एक परिवार

प्रत्येक परिवार पर अलग से एक अधिकृत अनुरोध का परीक्षण करें, फिर फिर से जुड़ने के बाद दोहराएँ यदि नीति को सत्र से आगे टिकना है। केवल IPv4 नेटवर्क पर परीक्षण IPv6 मार्ग का अभ्यास नहीं कर सकता, इसलिए सफलता उस लीक के बारे में कुछ नहीं कहती जिसे आप बंद करना चाहते हैं। परीक्षण के दौरान काउंटर देखें, क्योंकि जो नियम कभी मेल नहीं खाता वह अपनी टिप्पणी के दावे के अनुसार काम नहीं करता।

प्रति प्रयास एक सीमित नियम बदलें और पिछली कॉन्फ़िगरेशन हाथ में रखें। जहाँ प्रबंधित प्रोफ़ाइल नीति की मालिक है, स्थानीय रूप से संपादित करने से पहले उसके व्यवस्थापक को शामिल करें, क्योंकि अगला चेक-इन स्थानीय सुधार पर लिख देगा और लीक वापस ले आएगा।