RADIUS को VLAN जवाफले VPN प्रयोगकर्ताका लागि किन केही गर्दैन

तपाईं NPS नीतिमा VLAN विशेषता थप्नुहुन्छ, VPN प्रयोगकर्ता जोडिन्छ, र ल्यापटप अझै पूर्वनिर्धारित पूलमा अवतरण हुन्छ। RADIUS सर्भर तपाईंले मागेको नै फर्काइरहेको छ, जसले गर्दा विफलता क्यास समस्याजस्तो देखिन्छ। सामान्यतया त्यस्तो हुँदैन। Access-Accept अधिकारका सङ्केतहरू बोक्छ, र ती प्राप्त गर्ने नेटवर्क पहुँच सर्भरले मात्र एउटालाई नेटवर्क आबन्टनमा बदल्न सक्छ।

नीतिबाट होइन, गेटवेबाट सुरु गर्नुहोस्

केही बदल्नु अघि ग्राहकबाट भित्रतिर शृंखला पछ्याउनुहोस्। ग्राहकले गेटवेसँग सत्र माग्छ, गेटवेले RADIUS लाई प्रयोगकर्ताले एउटा पाउन सक्छ कि भनी सोध्छ, र RADIUS नतिजा तथा विशेषताको समूहसँग जवाफ दिन्छ। त्यसपछि गेटवेले जानेको कुरा लागू गर्छ।

तपाईंको जाँच चौथो चरणबाट सुरु हुन्छ, त्यसैले पहिलो तीन स्वस्थ देखिन्छन्। आदानप्रदानमा केहीले पनि गेटवेलाई प्राप्त विशेषता लागू गर्न बाध्य गर्दैन। जवाफ गेटवेप्रति अनुरोध हो, ग्राहकबारे तथ्य होइन।

स्विचले गर्ने र VPN ले नसक्ने

802.1X पहुँच स्विच पोर्ट भएको प्रमाणक हो, र गतिशील VLAN आबन्टनले ती पोर्टमध्ये एकलाई स्विचले पहिले नै बोकेको VLAN मा सार्छ। RADIUS सुरुङ विशेषताहरूले त्यो मनसायलाई स्विचले बुझ्ने रूपमा वर्णन गर्छन्। राउटेड VPN सुरुङ अन्त्य गर्छ, स्विच पोर्ट होइन, र यसका ग्राहकहरूले सामान्यतया प्रसारण डोमेनको सदस्यताको सट्टा ठेगाना र मार्ग पाउँछन्। सार्न पोर्ट छैन, त्यसैले त्यही विशेषतासँग काम गर्न केही छैन।

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

सर्भरले वास्तवमा पठाएको जवाफ पढ्नुहोस्

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

radtest alice secret 10.0.0.10 0 testing123

यदि त्यो जवाफमा VLAN विशेषताहरू छैनन् भने पहिले नीति मिलान सुधार्नुहोस्। यदि ती छन् भने सर्भरले आफ्नो भाग गरेको छ र खाडल तलतिर छ।

पहिले सत्र नीति प्रमाणित गर्नुहोस्, त्यसपछि पहुँच

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

swanctl --list-sas

त्यसपछि ग्राहकबाट एउटा अनुमत र एउटा अस्वीकृत स्रोत परीक्षण गर्नुहोस्, किनकि सही पूलको ठेगानाले अलगाव प्रमाणित गर्दैन। यदि गेटवेसँग तपाईंले चाहेको आबन्टनका लागि कुनै संयन्त्र छैन भने विशेषताका थप प्रतिले एउटा बनाउँदैनन्। अपेक्षित पूलको ठेगाना अन्य सबै पूलमा पूर्ण पहुँचसँगै रहन सक्छ। समर्थित नीति संयन्त्र छान्नुहोस् वा नेटवर्क डिजाइन जानाजान बदल्नुहोस्।