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 उपकरणाला अजूनही एनकॅप्सुलेटेड वाहतूक आणि परतीचा रहदारी वाहून नेणे आवश्यक आहे। रजिस्ट्री मूल्य कोणताही फॉरवर्डिंग नियम तयार करत नाही, प्रस्ताव जुळवत नाही आणि कोणतीही ओळख सत्यापित करत नाही, म्हणून बदलानंतर कार्य करू लागलेले कनेक्शन पूर्णपणे वेगळ्या कारणाने कार्य करत असू शकते। मूळ टोपोलॉजीसह मूळ प्रोटोकॉल पुन्हा तपासा, नंतर कोणता टप्पा अयशस्वी झाला आणि मूल्य त्याचे निराकरण का करेल अशी अपेक्षा होती हे लिहा। तेच वाक्य इंटरनेटवरील अफवेचे संरक्षित करण्यायोग्य कॉन्फिगरेशनमध्ये रूपांतर करते।