તમે NPS RADIUS ક્લાયન્ટ તરીકે કયું સરનામું નોંધો છો?
ગેટવેનું વાસ્તવિક બેકએન્ડ સ્રોત નોંધો, જાહેર હોસ્ટનામ કે ક્લાયન્ટ પૂલ નહીં. શેર્ડ સિક્રેટ મેળવો, પછી એક નિયંત્રિત વિનંતીથી પુષ્ટિ કરો.
Windows NPS ને પ્રમાણીકરણ સોંપતું VPN ગેટવે, કોઈપણ વપરાશકર્તા નીતિ ચાલે તે પહેલાં NPS બાજુ એક ઑબ્જેક્ટ માંગે છે: ગેટવે માટે RADIUS ક્લાયન્ટ એન્ટ્રી. મોટા ભાગના નિષ્ફળ પ્રયાસો ખોટું સરનામું નોંધે છે, કારણ કે મહત્ત્વનું સરનામું એ છે જે ગેટવે તેના બેકએન્ડ માર્ગ પર વાપરે છે, કર્મચારીઓ તેમની VPN એપમાં લખે છે તે હોસ્ટનામ નહીં. આ મૂલ્ય ખોટું હોય તો NPS વિનંતી ચૂપચાપ કાઢી નાખે છે, જે ક્લાયન્ટ બાજુથી ખોટા પાસવર્ડ જેવું લાગે છે. ક્ષેત્રમાં કયું સરનામું આવે તે ત્રણ શરતો નક્કી કરે છે, તેથી કન્સોલ ખોલતા પહેલાં તે નક્કી કરો.
ગેટવે નોંધો, લેપટોપ કે પૂલ નહીં
RADIUS ક્લાયન્ટ ઑબ્જેક્ટ નેટવર્ક ઍક્સેસ ઉપકરણનું પ્રતિનિધિત્વ કરે છે જે પ્રમાણીકરણ વિનંતીઓ મોકલે છે. તે VPN ગેટવે છે, ક્લાયન્ટ ચલાવતું દરેક લેપટોપ નહીં, અને ટનલની અંદર આપવામાં આવતી સરનામાંની શ્રેણી પણ નહીં.
તે ટનલ સરનામાં ક્યારેય RADIUS વિનંતીના સ્રોત તરીકે દેખાતાં નથી, કારણ કે વિનંતી ગેટવેના પોતાના નેટવર્ક માર્ગ પર જાય છે. ક્લાયન્ટ પૂલ એન્ટ્રી નોંધવાથી એવી નીતિ બને છે જે ક્યારેય મેળ ખાઈ શકે નહીં, જ્યારે વાસ્તવિક વિનંતી એવા સરનામેથી આવે છે જે NPS એ ક્યારેય સાંભળ્યું નથી. એ જ ગૂંચવણ લોકોને દરેક કર્મચારીનું ઘરનું IP ઉમેરવા તરફ દોરે છે, જે એકસાથે અનિર્વાહ્ય અને ખોટું છે.
તમે દાખલ કરો છો તે સરનામું ત્રણ શરતો નક્કી કરે છે
પહેલાં, ગેટવે NPS તરફ ખરેખર વાપરે છે તે સ્રોત સરનામું શોધો. બહુ-ઇન્ટરફેસ ગેટવે ઘણી વાર તેના જાહેર VPN શ્રોતા પરથી નહીં પણ સંચાલન કે બેકએન્ડ ઇન્ટરફેસ પરથી મોકલે છે. બીજું, બંને વચ્ચે NAT છે કે નહીં તે તપાસો: વિનંતી અનુવાદિત થાય તો NPS અનુવાદિત સરનામું જુએ છે, અને તે જ નોંધવાનું મૂલ્ય છે. ત્રીજું, જો બે ગેટવે ભૂમિકા વહેંચે, તો દરેક વિનંતી સ્રોતને પોતાની ક્લાયન્ટ એન્ટ્રી જોઈએ, કારણ કે એક સરનામા સાથેનું એક ઑબ્જેક્ટ તેમાંથી ફક્ત એકને આવરે છે.
બે છેડાનો રેકોર્ડ જોડીને સીધી રાખે છે. નીચેનું કોષ્ટક ઉદાહરણ તરીકે ખાનગી સરનામાં વાપરે છે, તેથી તમારો માર્ગ ખરેખર જે વાપરે છે તેનાથી બદલો.
| At NPS | At the VPN gateway |
|---|---|
| RADIUS client address 10.20.0.10 | Authentication server 10.20.0.20 |
| Shared secret, agreed value | The same secret, same value |
| UDP 1812 permitted from 10.20.0.10 | UDP 1812 permitted toward 10.20.0.20 |
અનુમાન કરવાને બદલે સ્રોતની પુષ્ટિ કરો. એક પ્રયાસ દરમિયાન NPS કે ફાયરવૉલ લૉગ જુઓ, અથવા NPS યજમાન પર sudo tcpdump -ni any udp port 1812 વડે કૅપ્ચર કરો. તે કૅપ્ચરનું સરનામું ક્લાયન્ટ એન્ટ્રી માટે એકમાત્ર સમર્થનીય જવાબ છે. ગેટવે પાસે ઘણા શક્ય સ્રોત હોય તો દરેકને તેના પોતાના મિત્રતાપૂર્ણ નામ હેઠળ નોંધો.
શેર્ડ સિક્રેટ ગેટવે અને NPS વચ્ચેનું મૂલ્ય છે
શેર્ડ સિક્રેટ ઉપકરણ સંબંધની પ્રમાણિકતા ચકાસે છે. તે વપરાશકર્તા પાસવર્ડ નથી અને ક્યારેય કર્મચારીઓમાં વહેંચાતું નથી કે ક્લાયન્ટ પ્રોફાઇલમાં ઉમેરાતું નથી.
એક મૂલ્ય પસંદ કરો, તેને બંને જગ્યાએ દાખલ કરો, અને ગેટવેનું રૂપરેખાંકન બેકઅપ જ્યાં રહે છે ત્યાં સાચવો. મેળ ન ખાય તો એવી વિનંતી બને છે જે NPS કોઈ ઉપયોગી ભૂલ વિના કાઢી નાખે છે, જે ગેટવેના લૉગમાં અપ્રાપ્ય સર્વરથી અલગ પડતી નથી. જાળવણી વિન્ડોમાં તેને ફેરવો અને તે જ ફેરફારમાં બંને છેડા અદ્યતન કરો.
એક મંજૂર વિનંતીથી પુષ્ટિ કરો
નિયંત્રિત ખાતું વાપરો અને બંને બાજુ એક પ્રયાસનો સહસંબંધ કરો. ગેટવે પર પુષ્ટિ કરો કે વિનંતી ઇચ્છિત સર્વર તરફ ગઈ; NPS પર પુષ્ટિ કરો કે તે નોંધાયેલ ક્લાયન્ટથી આવી અને અપેક્ષિત જોડાણ વિનંતી નીતિ સાથે મેળ ખાધો. સમયસમાપ્તિ અને અસ્વીકાર જુદી જુદી બાબતો કહે છે, અને બંનેને ઓળખપત્ર સમસ્યા ગણવાથી આગલો કલાક બગડે છે. પછી માન્ય પણ અપાત્ર ખાતું અને ખોટો પાસવર્ડ ચકાસો, કારણ કે બધું સ્વીકારતી નીતિ પહેલી કસોટી પણ પસાર કરે છે.
છેલ્લે, પરત મળેલા અધિકાર સાથે ગેટવે શું કરે છે તે તપાસો. RADIUS ક્લાયન્ટ નોંધવાથી ઉપકરણને ફક્ત ભાગ લેવાની પરવાનગી મળે છે; તે દરેક પરિણામી સત્રને LAN માં પ્રવેશ આપતું નથી.
નિદાન આઉટપુટ મર્યાદિત રાખો: કોઈ શેર્ડ સિક્રેટ નહીં, કોઈ વપરાશકર્તા પાસવર્ડ નહીં, સપોર્ટ ટિકિટમાં કોઈ સંપૂર્ણ પૅકેટ પેલોડ નહીં. જો ડિઝાઇન માંગે કે NPS સર્વર ડિરેક્ટરી લક્ષણો વાંચે, તો તે પરવાનગી ક્લાયન્ટ નોંધણીથી અલગ વહીવટી કાર્ય છે, અને તે ન હોય ત્યારે અલગ રીતે નિષ્ફળ જાય છે.