स्थिर VPN IP: RADIUS Framed-IP-Address किंवा पूल राखीव

VPN क्लायंटसाठी स्थिर अंतर्गत पत्ता तीन ठिकाणी ठेवता येतो, आणि त्यापैकी फक्त एकाने तो मालकीचा असावा. RADIUS पत्ता Access-Accept मध्ये परत देऊ शकतो, गेटवे खात्यासाठी स्थिर मॅपिंग ठेवू शकतो, आणि क्लायंट अडॅप्टर हाताने सेट करता येतो. पहिले दोन धोरण आहे आणि तिसरे हे गेटवे दुर्लक्ष करू शकते किंवा ओव्हरराइड करू शकते असे स्थानिक अंदाज आहे. पहिल्या दोनमधून निवडणे हा खरा निर्णय आहे, आणि तो नेटवर्क प्रवेश सर्व्हर प्रत्यक्षात काय लागू करतो यावर अवलंबून आहे.

स्थिर पत्ता राहू शकतो अशी तीन ठिकाणे

उत्तरात Framed-IP-Address असेल आणि गेटवे ते मूल्य सत्रावर लागू करेल तेव्हा RADIUS पत्त्याचा मालक असतो. प्रशासक खाते पूलमधील स्थिर पत्त्यावर मॅप करतो तेव्हा गेटवे त्याचा मालक असतो. क्लायंटकडे काहीही नसते, त्याचा अडॅप्टर हाताने दिलेला पत्ता दाखवत असला तरी, कारण सर्व्हर वाटाघाटीदरम्यान अंतर्गत पत्ता नियुक्त करतो आणि सर्व्हर काहीही पाठवत नाही तेव्हाच स्थानिक सेटिंग महत्त्वाची असते. कार्यरत कनेक्शनवर तिन्ही सारखीच दिसतात, म्हणूनच संघर्ष उशिरा समोर येतात. फरक पुन्हा जोडणी, दुसऱ्या उपकरणावर आणि धोरण बदलानंतर दिसतो.

दोन मालक हेच तुटणारे संरचना आहे. RADIUS उत्तर 172.28.4.77 नियुक्त करते आणि गेटवे 172.28.4.90 साठी स्थिर मॅपिंग ठेवते, तेव्हा विक्रेत्याचा कोड आधी तपासतो ते मूल्य मिळते, आणि हरलेले लॉग ओळीशिवाय टाकून दिले जाते. तेच खाते दुसऱ्या उपकरणावर नक्कल पत्ता मिळवते, आणि लक्षण नियुक्ती संघर्ष नव्हे तर राउटिंग बिघाड असे वाचले जाते. दुसरी यंत्रणा जोडण्यापूर्वी मालक ठरवा.

क्लायंट-बाजूचा पर्याय फक्त तो वगळण्यासाठी नामनिर्देश करण्यासारखा आहे. हाताने दिलेला अडॅप्टर पत्ता ही ऑपरेटिंग सिस्टम दाखवू शकणारी पसंती आहे, राखीव नाही, आणि तो दुसऱ्या सत्राला तोच पत्ता मिळण्यापासून थांबवू शकत नाही.

RADIUS उत्तर काय वचन देऊ शकते आणि काय नाही

RFC 2865Framed-IP-Address हा वापरकर्त्यासाठी संरचित करायचा IPv4 पत्ता म्हणून परिभाषित करते, आणि तो Access-Accept मध्ये असतो. Access-Request मधील तोच गुणधर्म सर्व्हर दुर्लक्ष करू शकणारा इशारा आहे, आणि क्लायंट किंवा गेटवे पसंतीचा पत्ता सुचवतो तेव्हा हे महत्त्वाचे आहे. प्रोटोकॉलमध्ये गेटवेला उत्तराचा आदर करण्यास भाग पाडणारे काहीही नाही, कारण ते सत्रावर लागू करणारा घटक नेटवर्क प्रवेश सर्व्हर आहे.

आधार हा उत्पादनाचा प्रश्न आहे, प्रोटोकॉलचा नाही. काही गेटवे फ्रेम केलेले पत्ते डीफॉल्टने लागू करतात, काहींना ते करण्यापूर्वी गट-स्तरीय स्विच सुरू करावा लागतो, आणि काही गुणधर्म स्वीकारतात पण दूरस्थ प्रवेश सत्रांसाठी कधीही वापरत नाहीत. शेवटची स्थिती धोकादायक आहे, कारण लेखा नोंद उत्तर दाखवू शकते तर क्लायंटला पूल पत्ता मिळतो. तुम्ही चालवत असलेल्या नेमक्या गेटवे मॉडेल आणि फर्मवेअरवर वर्तन पुष्टी करा, सहोदर उत्पादनाच्या दस्तऐवजावर नाही.

गेटवे जे उत्तर दुर्लक्षित करते ते कधीही न पाठवलेल्या उत्तरासारखेच दिसते. Access-Accept आणि सत्राचा पत्ता शेजारी शेजारी वाचणे हाच दोन प्रकरणे वेगळे करण्याचा एकमेव मार्ग.

तुम्ही आधीच राउट करत असलेल्या पूलमध्ये पत्ता राखीव ठेवा

गेटवे आधीच राउट करतो आणि फायरवॉल आधीच विश्वास ठेवतो त्या पूल सबनेटमधून स्थिर पत्ता निवडा. त्या श्रेणीबाहेरील पत्ता धोरण बदलाचे राउटिंग प्रकल्पात रूपांतर करतो, आणि VPN वर येईल पण त्यामागे काहीही उत्तर देऊ शकणार नाही. जर प्रति-पत्ता प्रवेश नियम असतील, तर त्याच बदलात स्थिर पत्ता त्यांना जोडा.

दुसऱ्या एकाचवेळी सत्राने काय करावे ते ठरवा. एक पत्ता दोनदा नियुक्त करणे हे उपकरण व्यवस्थापन नाही, आणि त्यातून निर्माण होणारा संघर्ष दोन्ही सत्रांसाठी अधूनमधून कनेक्टिव्हिटी म्हणून दिसतो. एकतर प्रत्येक उपकरणासाठी वेगळी ओळख द्या, किंवा वेगळ्या नियुक्ती, किंवा समर्थित तपासणीसह एकाचवेळकता लागू करा, उदाहरणार्थ Simultaneous-Use, जुन्या सत्राची मुदत संपण्यापूर्वी क्लायंट कधीही पुन्हा जोडणार नाही अशी आशा करण्याऐवजी.

परतीचे मार्ग नियुक्तीएवढ्याच लक्ष देण्यास पात्र आहेत. गेटवेला पूलकडे मार्ग हवा, अंतर्गत राउटरना गेटवेकडे परतीचा मार्ग हवा, आणि स्थिर पत्ता दोन्ही वारसा म्हणून घेतो. एक क्लायंट काम करतो आणि बाकी सर्व अयशस्वी होतात याचा अर्थ सहसा पूल मार्ग आहे पण राखीव पत्त्याचा होस्ट मार्ग नाही.

राखीववर विश्वास ठेवण्यापूर्वी उत्तर तपासा

AAA बाजू आणि सत्र बाजू स्वतंत्रपणे तपासा, कारण त्या वेगवेगळ्या कारणांनी अयशस्वी होतात. स्थानिक radtest गेटवे सहभागी न करता सर्व्हर खात्यासाठी काय परत देतो हे दाखवते, आणि वापरकर्ता फाइलमधील नोंद सर्व्हरने कशाशी जुळले पाहिजे हे दाखवते. नंतर क्लायंट पुन्हा जोडा आणि मिळालेल्या पत्त्याची उत्तरातील गुणधर्माशी तुलना करा.

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

गुणधर्माशिवाय Access-Accept म्हणजे सर्व्हरने नोंद जुळवली नाही किंवा त्या वापरकर्त्यावर गुणधर्म लागू झाला नाही. गुणधर्मासह Access-Accept आणि अजूनही पूल पत्ता मिळणारा क्लायंट म्हणजे गेटवेने तो दुर्लक्षित केला. Access-Reject तुम्हाला क्रेडेन्शियल्स किंवा गट धोरणाकडे परत पाठवतो, आणि यापैकी कोणताही निकाल क्लायंट अडॅप्टर संपादित करून डीबग करू नये.

पुन्हा जोडणीनंतर आणि दुसऱ्या उपकरणावरून दुसऱ्या लॉगिननंतर तपासणीची पुनरावृत्ती करा. फक्त पहिल्या सत्रासाठी टिकणारे राखीव हा घडण्याची वाट पाहणारा पूल संघर्ष आहे, आणि ऑडिटदरम्यान शोधण्यापेक्षा आताच शोधणे स्वस्त आहे.

एक मालक निवडा आणि तो लिहा

गेटवे फ्रेम केलेले पत्ते विश्वासार्हपणे लागू करत असेल, तर नियुक्तीचा मालक RADIUS राहू द्या आणि त्याच खात्यासाठी कोणतेही स्थिर मॅपिंग काढून टाका. नसेल तर गेटवे त्याचा मालक राहू द्या आणि उत्तरातून गुणधर्म काढून टाका, जेणेकरून दोन स्रोत भिन्न होऊ शकणार नाहीत. दोन्ही ठेवणे कारण प्रत्येक जवळपास काम करते, भविष्यातील सत्र चुकीच्या पत्त्याने आणि स्पष्ट कारणाशिवाय होण्याची खात्री देते.

निवडलेला मालक, राखीव पत्ता आणि तो ज्या पूलमधून आला ते खाते नोंदीत लिहा. नंतर उपकरण जोडणारी व्यक्ती दोन्हींपैकी कोणतेही बदलण्यापूर्वी पत्ता AAA धोरण आहे की गेटवे मॅपिंग हे पाहू शकेल.