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

पत्ता कोणत्या स्तराचा आहे ते ठरवा

दूरस्थ प्रवेश गेटवेमध्ये सहसा स्थानिक पूल असतो, आणि अनेक प्रमाणीकरण उत्तरातूनही पत्ता स्वीकारू शकतात। कोण जिंकेल हे प्लॅटफॉर्म, प्रोटोकॉल आणि सेवा संरचनेवर अवलंबून असते, म्हणून वापरात असलेल्या नेमक्या आवृत्तीसाठी प्राधान्याचा नियम वाचा। जिथे स्थानिक पूलला प्राधान्य आहे तिथे गुणधर्म केवळ सजावट आहे आणि क्लायंट तरीही यादृच्छिक पत्त्यावर पोहोचतो। निर्णय लिहून ठेवा, त्यात परत मिळालेले मूल्य पूलच्या श्रेणीतच असले पाहिजे की बाहेरही असू शकते हे समाविष्ट करा।

RFC 2865 Framed-IP-Address हा वापरकर्त्यासाठी संरचित करावयाचा पत्ता म्हणून परिभाषित करतो आणि एखाद्या विशिष्ट गेटवेची तो मानण्याची तयारी याबद्दल काहीही सांगत नाही। प्राधान्याबाबत अधिकार उत्पादकाच्या दस्तऐवजांना आहे, गुणधर्माच्या व्याख्येला नाही।

चाचणी विनंती पाठवा आणि उत्तर वाचा

प्रथम सर्व्हर स्वतंत्रपणे तपासा, जेणेकरून गहाळ गुणधर्म गेटवेची समस्या मानला जाणार नाही। radtest एक Access-Request पाठवतो आणि परत येणारे गुणधर्म छापतो।

radtest alice 'S3cret' 127.0.0.1 0 testing123

Access-Accept मध्ये Framed-IP-Address शोधा आणि मूल्य इच्छित आहे, बॅकअप नियमातून आलेला पूल पत्ता नाही याची खात्री करा। जेव्हा गुणधर्म नसतो, तेव्हा वापरकर्ता नोंद किंवा अधिकृतता धोरण जुळत नाही, आणि गेटवे कधीही न पाठवलेले सर्व्हर देऊ शकत नाही। उत्तर एखाद्या विशिष्ट नियमाशी जोडणे कठीण असल्यास सर्व्हर डीबग मोडमध्ये चालू असताना विनंती पुन्हा करा। शेल इतिहास आणि तिकिटांपासून सामायिक रहस्य दूर ठेवा, कारण वरील प्लेसहोल्डर लॉगिन क्रेडेन्शियल नाही।

गेटवेने मूल्याचा आदर केला याची खात्री करा

योग्य उत्तर कराराचा फक्त अर्धा भाग आहे। टनेल इंटरफेसवर दिसणारा पत्ता हेच महत्त्वाचे निरीक्षण आहे, आणि तो गेटवे संरचनेतून अनुमान काढण्याऐवजी क्लायंटवर वाचला जातो।

ip -4 addr show tun0

त्या पत्त्याची Access-Accept मधील गुणधर्माशी तुलना करा। विसंगतीचा अर्थ गेटवेने मूल्य दुर्लक्षित केले किंवा पुन्हा लिहिले, ज्यामुळे पहिल्या विभागातील प्राधान्याचा प्रश्न पुन्हा उघडतो। आणखी एकदा जोडा, कारण केवळ पहिल्या प्रयत्नात काम करणारे आरक्षण सहसा जुने सत्र किंवा मागील कनेक्शनकडे अजून असलेली भाडेपट्टी दर्शवते। गेटवे आवृत्ती आणि प्रोटोकॉल निकालाच्या बाजूला नोंदवा, जेणेकरून पुढील व्यक्तीला वर्तन आवृत्ती-विशिष्ट आहे का ते कळेल।

एकाचवेळी आणि रद्दीकरणाची योजना करा

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

स्थिर पत्तापद्धत नियम आणि नोंदी सोप्या करते, पण पॅकेट कोणी तयार केले हे कधीही सिद्ध करत नाही। जेव्हा तो पत्ता नंतर दुसऱ्या सत्रात जातो तेव्हा प्रमाणीकरण आणि गंतव्य अधिकृतता अजूनही महत्त्वाची असते।

संबंधित लेख