RRAS के VPN क्लाइंट को अपना IPv4 पूल और लौटने का रास्ता चाहिए

VPN क्लाइंट जुड़ता है और एक पता पाता है, फिर भी जिस LAN होस्ट की उसे ज़रूरत है वह उसे जवाब नहीं दे पाता। Windows Routing and Remote Access में VPN क्लाइंट का भीतरी पता सर्वर के LAN अडैप्टर से अलग कॉन्फ़िगर किए गए पूल से आता है, और LAN पक्ष को उस पूल तक वापसी मार्ग चाहिए। दो बदलाव, एक नहीं, और वे अलग-अलग तरीक़ों से विफल होते हैं। इन्हें क्रम से पूरा करें ताकि पुरानी रेंज हटाने से पहले पता योजना और वापसी मार्ग सिद्ध हो जाएँ।

कंसोल खोलने से पहले रेंज आरक्षित करें

ऐसा प्रीफ़िक्स चुनें जो LAN, दूसरी VPN रेंज या साइट में रूट होने वाली किसी भी चीज़ से ओवरलैप न हो। परीक्षण के लिए /24 सुविधाजनक आकार है, और पहला उपयोगी हिस्सा क्लाइंट को दिया जा सकता है जबकि बाकी वृद्धि के लिए खुला रहे। कंसोल में लिखने से पहले इसे उसके उद्देश्य और स्वामी के साथ दर्ज करें। ब्लॉक के दोनों सिरों पर जगह छोड़ें ताकि बाद का विभाजन फिर से नंबर देने को मजबूर न करे।

केवल कंसोल में रहने वाली पता योजना एक पुनर्निर्माण की दूरी पर टकराव से है। इसकी बढ़ने की प्रवृत्ति भी होती है: कोई बाद में दूसरी रेंज जोड़ता है और कोई पहली की जाँच नहीं करता। योजना को सर्वर दस्तावेज़ के पास रखें, चैट थ्रेड में नहीं।

सर्वर का LAN अडैप्टर इस पूल को परिभाषित नहीं करता। सार्वजनिक श्रोता बदलना या LAN में अडैप्टर जोड़ना बिल्कुल कुछ और करता है। इसी कारण क्लाइंट जुड़ सकते हैं और फिर भी ग़लत जगह से पता पा सकते हैं। पूल सर्वर के IPv4 गुणों में रहता है, अडैप्टर सूची में नहीं।

विधि बदलना रेंज जोड़ना नहीं है

RRAS में एक आवंटन विधि और रेंजों का समूह है। DHCP से स्थिर पूल की ओर जाना विधि परिवर्तन है। स्थिर पूल पहले से सक्रिय होने पर दूसरा ब्लॉक जोड़ना रेंज परिवर्तन है।

किसी एक को चलाने से पहले दोनों क्रियाओं का पूर्वावलोकन करें, और पढ़ें कि कौन सर्वर की वर्तमान स्थिति से मेल खाती है:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

यदि सर्वर अभी भी DHCP आवंटन पर है तो दूसरा cmdlet विफल होता है या अनुपयोगी पूल बनाता है। पहला मौजूदा पूल को बढ़ाने के बजाय विधि बदल देता है। कोई भी पूर्वावलोकन कुछ लागू नहीं करता, इसलिए जो मेल खाता है उसे चलाएँ, फिर कंसोल में बने पूल की पुष्टि करें। यदि आपको निश्चित नहीं कि सर्वर किस स्थिति में है, तो IPv4 गुण पृष्ठ पर आवंटन विधि पढ़ें और कॉन्फ़िगर की गई रेंज सूचीबद्ध करें:

Get-VpnIPAddressRange

खाली रेंज सूची वाली DHCP विधि का अर्थ है कि पहला पूर्वावलोकन लागू होता है। मौजूदा रेंज वाला स्थिर पता पूल का अर्थ है कि दूसरा लागू होता है।

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

LAN को वापसी मार्ग चाहिए

मान लें कि LAN 10.60.0.0/24 है और RRAS सर्वर उस पर 10.60.0.10 है। उस LAN का जो होस्ट 10.250.50.0/24 के क्लाइंट को जवाब देता है उसे RRAS सर्वर के ज़रिए पूल तक मार्ग चाहिए। उस मार्ग के बिना अनुरोध पहुँचता है और जवाब मर जाता है।

यदि होस्ट का डिफ़ॉल्ट गेटवे दूसरा राउटर है, तो उस राउटर को VPN प्रीफ़िक्स के लिए वापसी मार्ग चाहिए। RRAS सर्वर पर स्थिर मार्ग यहाँ मदद नहीं करता; वापसी मार्ग उस उपकरण पर होना चाहिए जिसके पास LAN गेटवे है, इसलिए इसे रूटिंग तालिका में या गतिशील रूटिंग प्रक्रिया में जोड़ें, जो भी साइट उपयोग करती हो।

नई स्रोत रेंज के सामने होस्ट की फ़ायरवॉल और किसी भी नेटवर्क एक्सेस नियम की भी जाँच करें। पुरानी क्लाइंट रेंज के लिए लिखे नियम नई को अस्वीकार करते हैं, भले ही आवंटन सफल रहा हो। LAN की ओर क्लाइंट के मार्ग और DNS रिज़ॉल्यूशन अलग आवश्यकताएँ हैं, और टनल स्वस्थ दिखने के दौरान दोनों विफल हो सकते हैं। हर एक को अलग जाँचें।

पुराना हटाने से पहले नया पूल एक उपकरण पर सिद्ध करें

आपके नियंत्रण वाला एक प्राधिकरण लें, दोबारा जुड़ें और क्लाइंट को मिला पूल पता पढ़ें। वही एक संख्या आवंटन को रूटिंग से अलग करती है। फिर नामित एप्लिकेशन चलाएँ, वापसी ट्रैफ़िक देखें और ऐसा गंतव्य आज़माएँ जो अस्वीकृत ही रहना चाहिए। तीन अवलोकन, तीन अलग विफलता के ढंग।

नाम रिज़ॉल्यूशन अपने अलग परीक्षण का हक़दार है: IP से पहुँच काम कर सकती है जबकि क्लाइंट का DNS अभी भी ऐसे रिज़ॉल्वर की ओर इशारा करता है जहाँ वह पहुँच नहीं सकता। LAN पर DNS सर्वर तभी पहुँच में है जब क्लाइंट का उस तक मार्ग हो और सर्वर नई रेंज से क्वेरी स्वीकार करे। पूल खिसकने पर दोनों आम चूक हैं।

सक्रिय सत्रों और रखरखाव प्रक्रिया का हिसाब करने के बाद ही पुरानी रेंज और उनके अपवाद हटाएँ। नए पते वाला जुड़ा क्लाइंट आवंटन सिद्ध करता है, एक्सेस नीति नहीं। पुरानी रेंज को तब तक दस्तावेज़ित रखें जब तक उसका उपयोग करने वाला अंतिम सत्र समाप्त न हो जाए।

तीन अवलोकनों से परिणाम जाँचें

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

क्लाइंट से, पता और एक LAN होस्ट तक का मार्ग पुष्ट करें:

ipconfig | findstr /i "IPv4"
route print -4

LAN होस्ट से, एक ही पास में वापसी मार्ग और नीति पुष्ट करें। यदि ping विफल हो पर एप्लिकेशन चले, तो छूटा हिस्सा संभवतः ICMP नियम है, मार्ग नहीं। यदि दोनों विफल हों, तो VPN संपादित करने से पहले होस्ट पर मार्ग पढ़ें। तीनों परिणाम बदलाव टिकट में दर्ज करें ताकि अगला व्यक्ति प्रमाण से शुरू करे।