Windows पर L2TP/IPsec त्रुटि 789: प्रोफ़ाइल बनाएँ और प्रस्ताव पिन करें
त्रुटि 789 IPsec विनिमय में विफल होती है, पासवर्ड पर नहीं। L2TP प्रोफ़ाइल को स्क्रिप्ट करें, प्रस्ताव पिन करें और बाद के कोड चरण के अनुसार पढ़ें।
Windows पर L2TP कनेक्शन में त्रुटि 789 का अर्थ है कि सुरंग IPsec सुरक्षा विनिमय के भीतर मर गई, जो Windows के कहीं भी उपयोगकर्ता पासवर्ड भेजने से बहुत पहले होता है। पासवर्ड फिर से आज़माना, या निर्देशिका में उसे रीसेट करना, उस चरण को आगे नहीं बढ़ा सकता। उसे आगे बढ़ाने वाला काम है PowerShell से कनेक्शन को फिर से बनाना, उस प्रस्ताव के साथ जो गेटवे वास्तव में देता है, क्योंकि सेटिंग्स विज़ार्ड IPsec रूपांतरणों को चुपचाप चुनता है और आपको कभी नहीं दिखाता कि उसने क्या चुना। यह उसी के लिए रनबुक है: प्रोफ़ाइल बनाएँ, प्रस्ताव पिन करें, फिर चरण तालिका का उपयोग करें ताकि अगला कोड आपको कुछ बताए।
विज़ार्ड के बिना प्रोफ़ाइल बनाएँ
Add-VpnConnection एक मूल फ़ोन-बुक प्रविष्टि लिखता है, इसलिए परिणाम वही ऑब्जेक्ट है जिसे सेटिंग्स ऐप बाद में संपादित करता है। इसे उन्नत सत्र से चलाएँ जब कनेक्शन मशीन के हर खाते के लिए होना चाहिए, या उपयोगकर्ता संदर्भ से जब उसे निजी रहना चाहिए:
Add-VpnConnection -Name "Contoso L2TP" `
-ServerAddress 203.0.113.10 `
-TunnelType L2tp `
-EncryptionLevel Required `
-AuthenticationMethod MSChapv2 `
-RememberCredential -Force-AuthenticationMethod को गेटवे जो देता है उससे मिलाएँ। MSChapv2, EAP और PAP विनिमेय नहीं हैं, और ऐसा प्रोफ़ाइल जो उस विधि की मांग करता है जिसे सर्वर स्वीकार नहीं करेगा, किसी भी उपयोगकर्ता रिकॉर्ड को देखे जाने से पहले विफल हो जाता है। किसी भी वास्तविक चीज़ के लिए -EncryptionLevel Required रखें; Optional Windows को अनएन्क्रिप्टेड सुरंग स्वीकार करने देता है यदि साथी एक प्रस्तुत करता है, जो एक प्रयोगशाला शॉर्टकट है और भेजने योग्य सेटिंग नहीं है।
यदि आप -L2tpPsk देते हैं, तो वह पूर्व-साझा कुंजी डिस्क पर प्रोफ़ाइल में लिखी जाती है, जहाँ से उस मशीन पर प्रोफ़ाइल पढ़ सकने वाला कोई भी उसे पुनर्प्राप्त कर सकता है। जब गेटवे समर्थन करे तो साथी के प्रमाणीकरण के लिए प्रमाणपत्र का उपयोग करें, और जब PSK अपरिहार्य हो तो उसे हर प्रावधान रन में चिपकाने के बजाय रिपॉज़िटरी और शेल इतिहास से बाहर रखें।
डिफ़ॉल्ट स्वीकार करने के बजाय प्रस्ताव पिन करें
Windows स्वयं IPsec रूपांतरण भरता है, इसीलिए समान दिखने वाले कनेक्शन वाली दो मशीनें एक ही गेटवे के विरुद्ध अलग-अलग विफल हो सकती हैं। Set-VpnConnectionIPsecConfiguration उन्हें पिन करने का समर्थित तरीका है:
Set-VpnConnectionIPsecConfiguration -ConnectionName "Contoso L2TP" `
-AuthenticationTransformConstants SHA256128 `
-CipherTransformConstants AES128 `
-EncryptionMethod AES128 `
-IntegrityCheckMethod SHA256 `
-DHGroup Group14 `
-PfsGroup None `
-PassThru -Forceवह सेट एक सामान्य L2TP/IPsec व्यवस्था है, सार्वभौमिक उत्तर नहीं। प्रत्येक पैरामीटर मानों की एक निश्चित सूची स्वीकार करता है, और जिस संयोजन को प्लेटफ़ॉर्म मैप नहीं कर सकता वह चुपचाप कमज़ोर प्रोफ़ाइल के बजाय cmdlet त्रुटि के रूप में लौटता है। ऐसी त्रुटि को मानों के बारे में कथन मानें, अपनी अनुमतियों के बारे में नहीं।
प्रस्ताव को गेटवे के दस्तावेज़ीकरण या उसकी जीवंत चरण-1 और चरण-2 सेटिंग्स से कॉपी करें, और एक समय में केवल एक फ़ील्ड बदलें, केवल तब जब गेटवे उन रूपांतरणों को लॉग कर रहा हो जिन्हें वह अस्वीकार करता है। पाँच फ़ील्ड से गुज़रना ऐसा कनेक्शन बनाता है जो संयोग से काम करता है और ऐसा रिकॉर्ड जो अगले व्यक्ति को कुछ नहीं समझाता।
विफलता को चरण से पढ़ें, त्रुटि पाठ से नहीं
789 कोडों के उस परिवार से संबंधित है जो क्लाइंट संवाद में सभी एक जैसे दिखते हैं। प्रोफ़ाइल को फिर से छूने से पहले कोड को उस चरण के सामने रखें जिसका वह है:
| What you see | Stage that failed | Check first |
|---|---|---|
| Nothing happens, then a timeout | No IKE response at all | Server address, UDP 500 and 4500 reachability, NAT traversal on the gateway |
| Error 789 | IKE security exchange | Proposal, pre-shared key, certificate trust and client clock |
| Error 691 or a repeated password prompt | User authentication | Account state, domain, RADIUS or NPS policy |
| Tunnel up, some hosts unreachable | Routing or DNS after PPP | Split-tunnel routes, pushed DNS, remote subnet mask |
यहाँ साख की दो भूमिकाएँ मायने रखती हैं। पूर्व-साझा कुंजी या प्रमाणपत्र साथियों को एक-दूसरे के प्रति प्रमाणित करता है, जबकि MSChapv2 या EAP आपको सुरंग के भीतर प्रमाणित करता है। उपयोगकर्ता पासवर्ड रीसेट करना पहले को ठीक नहीं कर सकता, नया साझा रहस्य दूसरे को ठीक नहीं कर सकता, और दोनों को एक साथ बदलना इस बात का सबूत नष्ट कर देता है कि कौन सा गलत था।
प्रमाणपत्र के मार्ग पर, सत्यापन ढीला करने पर विचार करने से पहले क्लाइंट की घड़ी, ट्रस्ट चेन और वह पहचान जाँचें जिसकी गेटवे अपेक्षा करता है। सत्यापन बंद करना दृश्यमान 789 को ऐसी सुरंग में बदल देता है जो गलत साथी पर भरोसा करते हुए जुड़ती है, और क्लाइंट में कुछ भी आपको नहीं बताएगा कि ऐसा हुआ। Microsoft की दूरस्थ पहुँच त्रुटि सूची स्वयं कोडों के लिए संदर्भ है, और यह सुरक्षा-परत विफलताओं को लॉगिन विफलताओं से अलग करती है।
ठीक हुआ कहने से पहले दोनों सिरों से सत्यापित करें
प्रोफ़ाइल को वापस पढ़ें, पर आउटपुट में प्रस्ताव की अपेक्षा न करें। Get-VpnConnection नाम, सर्वर पता, सुरंग प्रकार, एन्क्रिप्शन स्तर और प्रमाणीकरण विधि बताता है, और रूपांतरणों के बारे में कुछ नहीं जानता, इसलिए वापस पढ़ना पुष्टि करता है कि प्रविष्टि मौजूद है और सही होस्ट की ओर इशारा करती है:
Get-VpnConnection -Name "Contoso L2TP" |
Select-Object Name, ServerAddress, TunnelType, EncryptionLevel, AuthenticationMethodसंवाद के बजाय संख्या पाने के लिए कमांड लाइन से डायल करें: rasdial "Contoso L2TP" वही विफलता कोड लौटाता है जो इंटरफ़ेस लौटाता, और rasdial "Contoso L2TP" /disconnect प्रयासों के बीच उसे साफ़ करता है। फिर उसी प्रयास के लिए गेटवे का पक्ष पढ़ें। strongSwan का ipsec statusall या राउटर का IKE लॉग बताता है कि कौन सा प्रस्ताव आया और किसे अस्वीकार किया गया, और उसकी cmdlet मानों से तुलना करना ही एकमात्र कदम है जो वास्तव में साबित करता है कि दोनों सिरे सहमत हुए।
सफल कनेक्शन अंतिम रेखा नहीं है। वह ऐप खोलें जो उपयोगकर्ता के लिए मायने रखता है, क्योंकि रूट, धकेला गया DNS और स्प्लिट-सुरंग सेटिंग्स सुरंग ऊपर आने के बाद विफल होते हैं और बिल्कुल भी त्रुटि संवाद नहीं देते।
इसे स्वचालित करें, और साफ़-सुथरे ढंग से वापस जाएँ
बिना निगरानी वाला सेटअप ही इसे स्क्रिप्ट करने का कारण है, और डायल चरण वह जगह है जहाँ साख लीक होती है। rasdial उन्हें अपनी कमांड लाइन पर लेता है, जहाँ अन्य स्थानीय उपयोगकर्ता और अधिकांश लॉग संग्रहकर्ता उन्हें पढ़ सकते हैं:
subprocess.run(["rasdial", "Contoso L2TP"], check=True)कार्य चलाने वाले खाते तक सीमित साख को प्राथमिकता दें, या प्रोफ़ाइल को -RememberCredential के साथ उसे संग्रहीत करने दें, निर्धारित कार्य में पासवर्ड को तर्क के रूप में पारित करने के बजाय। प्रावधान कमांड स्वयं -Force के साथ दोहराने के लिए सुरक्षित हैं, लेकिन वे खुशी से पुराने प्रस्ताव को ऊपर लिख देंगे, इसलिए पुनः चलाना केवल तब मदद करता है जब स्क्रिप्ट वर्तमान मान रखती हो।
प्रोफ़ाइल पुनः आरंभ के पार बनी रहती हैं और जिस गेटवे कॉन्फ़िगरेशन के लिए बनाई गई थीं उससे अधिक जीती हैं। जब गेटवे का प्रस्ताव हिलता है, तो ऊपर मानों का दूसरा सेट चढ़ाने के बजाय प्रविष्टि हटाएँ और उसे फिर से बनाएँ: Remove-VpnConnection -Name "Contoso L2TP" -Force, फिर नए सेट के साथ दोनों cmdlet दोहराएँ।
स्क्रिप्ट के पास रहने वाली चार जाँचों के साथ लूप बंद करें: Get-VpnConnection अपेक्षित सुरंग प्रकार और एन्क्रिप्शन स्तर दिखाता है; गेटवे आपके क्लाइंट पते के लिए पूर्ण चरण 1 और चरण 2 लॉग करता है; rasdial सफलता लौटाता है और ऐप खुलता है; और स्क्रिप्ट में दर्ज प्रस्ताव वर्तमान गेटवे सेटिंग से मेल खाता है। जब अगली 789 आती है, तो वह तुलना दोपहर के बजाय मिनटों में हो जाती है।