स्थिर 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 को विशेषतासँग तुलना गर्नुहोस्। नमिल्नुको अर्थ गेटवेले मानलाई बेवास्ता गर्‍यो वा पुनः लेख्यो, जसले पहिलो खण्डको प्राथमिकता प्रश्न फेरि खोल्छ। अर्को पटक जोड्नुहोस्, किनकि पहिलो प्रयासमा मात्र काम गर्ने आरक्षणले सामान्यतया पुरानो सत्र वा अघिल्लो जडानसँगै रहेको लिजलाई संकेत गर्छ। गेटवे संस्करण र प्रोटोकललाई नतिजाको छेउमा लेख्नुहोस्, ताकि अर्को व्यक्तिले व्यवहार संस्करण-विशिष्ट हो कि होइन जान्न सकोस्।

एकै समयको र रद्दीकरणको योजना बनाउनुहोस्

एउटै प्रयोगकर्ता नाम दुई उपकरणमा एउटै ठेगानामा म्याप हुन सक्दैन, जबसम्म गेटवेले लगइनबाहेक अरू कुराले सत्रहरू छुट्याउँदैन। म्यापिङ व्यक्ति, दर्ता भएको उपकरण वा प्रमाणपत्र पहिचानसँग सम्बन्धित छ कि भन्ने निर्णय गर्नुहोस्, र यो छनोट नीति भण्डारमा स्पष्ट पार्नुहोस्। दोस्रो एकै समयको ग्राहक परीक्षण गर्नुहोस् र दुवै तोकिएका ठेगानाको तुलना गर्नुहोस्, किनकि यहाँको टकराव पछि राउटिङ त्रुटिका रूपमा फेरि देखिन्छ। त्यही सावधानी रद्दीकरण योजनामा पनि चाहिन्छ, किनकि पुराना फायरवाल नियमहरूले अझै त्यसको उल्लेख गरिरहेको बेला पुनः तोकिएको ठेगाना अधिकार त्रुटि बन्छ।

स्थिर ठेगाना प्रणालीले नियम र लग सरल बनाउँछ, तर प्याकेट कसले बनायो भन्ने कहिल्यै प्रमाणित गर्दैन। जब त्यो ठेगाना पछि अर्को सत्रमा जान्छ, प्रमाणीकरण र गन्तव्य अधिकार अझै महत्त्वपूर्ण रहन्छ।