स्थिर VPN क्लाइंट पते के लिए RADIUS Framed-IP-Address

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 की विशेषता से करें। बेमेल का अर्थ है कि गेटवे ने मान को अनदेखा किया या फिर से लिखा, जिससे पहले खंड का प्राथमिकता प्रश्न फिर खुल जाता है। एक बार और जुड़ें, क्योंकि केवल पहले प्रयास में काम करने वाला आरक्षण आम तौर पर पुराने सत्र या पिछले कनेक्शन के पास अब भी मौजूद लीज़ की ओर संकेत करता है। गेटवे संस्करण और प्रोटोकॉल को परिणाम के बगल में लिखें, ताकि अगला व्यक्ति जान सके कि व्यवहार संस्करण-विशिष्ट है या नहीं।

समवर्ती और निरसन की योजना बनाएँ

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

स्थिर पताकरण नियमों और लॉग को सरल बनाता है, पर कभी सिद्ध नहीं करता कि पैकेट किसने बनाया। जब वह पता बाद में किसी दूसरे सत्र में जाता है तब भी प्रमाणीकरण और गंतव्य प्राधिकरण महत्वपूर्ण रहते हैं।