स्थिर 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 2865ले Framed-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 नीति हो वा गेटवे म्यापिङ भनेर देख्न सक्नेछ।