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

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