फ़िक्स्ड VPN IP: RADIUS Framed-IP-Address या पूल आरक्षण

VPN क्लाइंट के लिए स्थिर आंतरिक पता तीन जगहों पर रह सकता है, और उनमें से केवल एक के पास ही उसका स्वामित्व होना चाहिए। RADIUS पता Access-Accept में लौटा सकता है, गेटवे खाते के लिए स्थिर मैपिंग रख सकता है, और क्लाइंट एडाप्टर हाथ से सेट किया जा सकता है। पहले दो नीति हैं और तीसरा स्थानीय अनुमान है जिसे गेटवे अनदेखा या अधिलेखित करने के लिए स्वतंत्र है। पहले दो के बीच चुनाव असली निर्णय है, और यह इस पर निर्भर करता है कि नेटवर्क एक्सेस सर्वर वास्तव में क्या लागू करता है।

तीन जगहें जहाँ स्थिर पता रह सकता है

RADIUS पते का स्वामी तब होता है जब उत्तर में Framed-IP-Address हो और गेटवे उस मान को सत्र पर लागू करे। गेटवे तब उसका स्वामी होता है जब व्यवस्थापक खाते को पूल के भीतर स्थिर पते पर मैप करे। क्लाइंट के पास कुछ नहीं होता, तब भी जब उसका एडाप्टर हाथ से सेट पता दिखाए, क्योंकि सर्वर बातचीत के दौरान आंतरिक पता आवंटित करता है और स्थानीय सेटिंग तभी मायने रखती है जब सर्वर कुछ न भेजे। काम करने वाले कनेक्शन पर तीनों एक जैसे दिखते हैं, इसीलिए टकराव देर से सामने आते हैं। अंतर पुनः कनेक्ट पर, दूसरे डिवाइस पर और नीति बदलने के बाद दिखता है।

दो स्वामी वह विन्यास है जो टूटता है। 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 नीति है या गेटवे मैपिंग।