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

પછી ક્લાયન્ટથી એક મંજૂર અને એક નિષેધ સંસાધન ની પરીક્ષા કરો, કારણ કે સાચા પૂલનું સરનામું અલગાવ સાબિત કરતું નથી. જો ગેટવે પાસે તમે ઇચ્છો છો તે સોંપણી માટે કોઈ પદ્ધતિ ન હોય, તો એટ્રિબ્યુટની વધુ નકલો એક બનાવશે નહીં. અપેક્ષિત પૂલનું સરનામું અન્ય દરેક પૂલની સંપૂર્ણ ઍક્સેસ સાથે સહઅસ્તિત્વ ધરાવી શકે છે. સમર્થિત નીતિ પદ્ધતિ પસંદ કરો અથવા નેટવર્ક ડિઝાઇન જાણી જોઈને બદલો.