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

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

मानले वास्तवमा के छान्छ

AssumeUDPEncapsulationContextOnSendRule ले NAT यन्त्रपछाडिको सहकर्मीसँग Windows को IPsec कार्यान्वयनले सम्बन्ध स्थापित गर्न प्रयास गर्ने वा नगर्ने निर्धारण गर्छ। अभिलेखित पूर्वनिर्धारित 0 ले त्यो अवस्थालाई अनुमति दिँदैन, सर्भर NAT पछाडिको पक्ष हुँदा 1 ले अनुमति दिन्छ, र 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 यन्त्रले अझै इन्क्याप्सुलेटेड यातायात र फर्किने ट्राफिक बोक्नुपर्छ। रजिस्ट्री मानले कुनै फर्वार्डिङ नियम बनाउँदैन, प्रस्ताव मिलाउँदैन र कुनै पहिचान प्रमाणित गर्दैन, त्यसैले परिवर्तनपछि काम गर्न थालेको जडान पूर्ण रूपमा फरक कारणले काम गरिरहेको हुन सक्छ। मूल टोपोलोजीसँग मूल प्रोटोकल फेरि परीक्षण गर्नुहोस्, त्यसपछि कुन चरण असफल भयो र किन मानले त्यसलाई समाधान गर्ने अपेक्षा गरिएको थियो लेख्नुहोस्। त्यही वाक्यले इन्टरनेटको हल्लालाई रक्षणयोग्य कन्फिगरेसनमा बदल्छ।