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 होस्टकडून, एकाच फेरीत परतीचा मार्ग आणि धोरण पुष्टी करा। पिंग अयशस्वी होतो पण अनुप्रयोग चालतो, तर राहिलेला भाग मार्ग नाही तर ICMP नियम असण्याची शक्यता आहे। दोन्ही अयशस्वी झाल्यास, VPN संपादित करण्यापूर्वी होस्टवरील मार्ग वाचा। तीनही निकाल बदल तिकिटात नोंदवा, पुढच्या व्यक्तीने पुराव्यापासून सुरुवात करावी।