Windows NAT-T रजिस्ट्री मान: पहले टोपोलॉजी जाँचें

Windows VPN कनेक्शन विफल होता है, खोज एक रजिस्ट्री मान लौटाती है, और वह मान रीबूट के साथ डाल दिया जाता है। वह क्रम कभी-कभी काम करता है और कभी कुछ समझाता नहीं। विचाराधीन सेटिंग सर्वर NAT डिवाइस के सापेक्ष कहाँ है, इस एक प्रश्न का उत्तर देती है, और जब तक आप नहीं जानते कि कौन-सा प्रोटोकॉल किस चरण पर विफल हुआ, यह अर्थहीन है।

मान वास्तव में क्या चुनता है

AssumeUDPEncapsulationContextOnSendRule तय करता है कि Windows का IPsec कार्यान्वयन NAT डिवाइस के पीछे के सहकर्मी के साथ संबंध बनाने का प्रयास करेगा या नहीं। प्रलेखित डिफ़ॉल्ट 0 उस स्थिति की अनुमति नहीं देता, 1 उसे तब अनुमति देता है जब सर्वर NAT के पीछे वाला पक्ष हो, और 2 दोनों सिरों के अनुवादित होने को समाहित करता है। ये टोपोलॉजी के कथन हैं—कौन कहाँ है।

क्रम के रूप में पढ़ने पर संख्याएँ क्रमशः अधिक विश्वसनीयता नहीं, बल्कि क्रमशः अधिक अनुवाद बताती हैं। ऐसे नेटवर्क पर 2 सेट करना जहाँ कुछ भी अनुवादित नहीं होता, कनेक्शन को तेज़ या अधिक स्थिर नहीं बनाता, और प्रमाणीकरण विफलता को ठीक भी नहीं करता। Microsoft की L2TP/IPsec के लिए NAT मार्गदर्शिका नीति और उसके ऐतिहासिक प्लेटफ़ॉर्म संदर्भ का दस्तावेज़ीकरण करती है। उस संदर्भ को उस Windows संस्करण और भूमिका से मिलाएँ जो आप वास्तव में चलाते हैं, क्योंकि कई संस्करणों तक टिका दस्तावेज़ हर वर्तमान बिल्ड के बारे में कथन नहीं है।

संख्या से पहले टोपोलॉजी मिलाएँ

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

यह दावा कि वर्तमान Windows Server संस्करण सीधे NAT traversal बंद के साथ आते हैं, कार्रवाई के लिए बहुत व्यापक है। मायने यह रखता है कि आपके सिस्टम पर नीति क्या है, उसके सामने की टोपोलॉजी क्या है और कौन-सा आदान-प्रदान विफल हुआ—इसी क्रम में। यदि दोनों सिरों के पते सार्वजनिक हैं, तो सेटिंग आपकी समस्या नहीं है। इसके बजाय प्रस्ताव, प्रमाणपत्र या खाते को देखें, और रजिस्ट्री को छोड़ दें।

पहले विफलता का चरण जाँचें

L2TP/IPsec कम से कम तीन भिन्न विफलताएँ उत्पन्न करता है: सहकर्मी तक पहुँच नहीं है, IPsec सुरक्षा स्थापित नहीं हो सकती, और सुरंग बनने के बाद PPP उपयोगकर्ता प्रमाणीकरण अस्वीकार हो जाता है। अस्वीकृत खाता NAT नीति बदलकर ठीक नहीं होता, और प्रस्ताव की असंगति रीबूट से ठीक नहीं होती।

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

बिना उत्तरदाता का टाइमआउट नीति की नहीं, पहुँच या फ़िल्टरिंग की ओर संकेत करता है। प्रस्ताव संदेश के साथ तेज़ अस्वीकृति एल्गोरिदम की ओर इशारा करती है। सुरंग उठने के बाद की विफलता प्रमाणीकरण चरण की है, जो भिन्न स्वामी और भिन्न उपाय है।

HTTPS पर SSTP और मूल IKEv2 के अपने लॉग और अपने नियंत्रण हैं। केवल Windows पर चलने के कारण उनमें से कोई NAT-traversal मामला नहीं बन जाता।

बदलाव वापसी के रास्ते के साथ करें

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

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