વપરાશકર્તાને VPN જૂથમાં ઉમેરવાથી એકલું ઍક્સેસ મળતું નથી
જૂથ સભ્યપદ એ એક શરત છે, પરવાનગી નથી. ગેટવેએ ખરેખર શું મેળવ્યું તે જુઓ, સ્વીકાર કે નકારનો રેકોર્ડ વાંચો અને બંને પરિણામ ચકાસો.
તમે ખાતું સાચા જૂથમાં મૂક્યું, લોગિન સફળ થયું, અને કનેક્શન હજી નકારવામાં આવે છે, અથવા જોડાય છે અને કંઈ ઉપયોગી સુધી પહોંચતું નથી. સામાન્ય પ્રતિક્રિયા એ છે કે કંઈક નરમ ન પડે ત્યાં સુધી વપરાશકર્તાને વધુ જૂથોમાં ઉમેરવો, અને એમ સંસ્થાઓ ટિકિટે માગ્યું હોય તેનાથી ઘણું વધારે આપે છે. જૂથ સભ્યપદ ઑથરાઇઝેશન નિર્ણયમાં એક ઇનપુટ છે, ક્યારેય નિર્ણય પોતે નહીં: ગેટવે સત્ર વિશે થોડી હકીકતો એકત્રિત કરે છે, તેમને ક્રમબદ્ધ નીતિ સાથે મેળવે છે અને પછી જ નક્કી કરે છે કે સત્ર શું સ્પર્શી શકે. જો બીજી કોઈ શરત નિષ્ફળ ગઈ હોય, તો જૂથ બદલવાથી તમારા એક્સપોઝર સિવાય કંઈ બદલાતું નથી.
જૂથ સભ્યપદ એ શરત છે, પરવાનગી નથી
RADIUS માં જૂથ ઑથરાઇઝેશન એટ્રિબ્યુટ તરીકે આવે છે, અને એટ્રિબ્યુટ સત્રનું વર્ણન કરે છે, પરવાનગી આપતા નથી. સર્વર Access-Accept અથવા Access-Reject થી જવાબ આપે છે; સ્વીકાર વખતે તે Filter-Id, Class અથવા RFC 2868 ના ટનલ એટ્રિબ્યુટ જોડી શકે છે, અને બીજી બાજુનું નેટવર્ક સાધન ઉત્પાદકના નિર્ણય મુજબ તેમનું અર્થઘટન કરે છે. પ્રોટોકોલમાં કંઈ પણ જૂથને સંપૂર્ણ ઍક્સેસમાં બદલતું નથી; એ મેપિંગ ગેટવે કે નેટવર્ક ઍક્સેસ સર્વર પર નીતિ ગોઠવનાર લખે છે.
તેથી એક જ જૂથનું નામ બે સિસ્ટમ પર અલગ રીતે વર્તે છે. Microsoft NPS શરતો, મર્યાદાઓ અને સેટિંગ્સમાંથી નેટવર્ક નીતિઓ બનાવે છે અને નક્કી કરેલા ક્રમમાં મૂલ્યાંકન કરે છે. OpenVPN Access Server પાસે પોતાનું જૂથ અને ઍક્સેસ નિયમ મોડેલ છે, જ્યારે કોમ્યુનિટી OpenVPN સર્વર ઘણી વાર આખો પ્રશ્ન client-connect સ્ક્રિપ્ટ કે client-config-dir ફાઇલને સોંપે છે.
જે નિયમ મેળ ખાધો તે નક્કી કરે છે, તમે ધારેલું જૂથ નહીં
મોટાભાગના એન્જિન પહેલી મેળ ખાતી નીતિ પર કે સૌથી ચોક્કસ પર અટકે છે. જો નીતિ 3 નકારે અને નીતિ 7 મંજૂરી આપે, તો સત્ર તેને પસાર થવા દેતા નિયમ સુધી પહોંચ્યા વિના નિષ્ફળ થઈ શકે. ક્રમ NPS અને મોટાભાગના નેટવર્ક ઍક્સેસ નિયંત્રણ ઉત્પાદનોમાં વાસ્તવિક સેટિંગ છે, અને વર્ષો સાથે સરકે છે.
જૂથ સાથે ચાલતી શરતો બીજો અડધો ભાગ છે. ઉપકરણની સ્થિતિ, પ્રમાણીકરણ પદ્ધતિ, પૂર્ણ થયેલ MFA, સ્રોત નેટવર્ક, પ્રમાણપત્રનો વિષય કે સમય-વિસ્તાર એક જ નીતિમાં હોઈ શકે. તેમાંથી એક પૂરી ન થાય તો નીતિ મેળ ખાતી નથી, એન્જિન નીચે પડે છે અને મૂળભૂત નકાર લાગુ પડે છે. વપરાશકર્તાની ખુરશીથી જૂથ અવગણાયું લાગે છે; એન્જિનની ખુરશીથી જૂથને પૂછવામાં જ આવ્યું નથી.
ડિરેક્ટરીની વિગતો એ જ ભ્રમ ઊભો કરે છે. Windows જૂથ સભ્યપદ પર મેળ ખાતી નીતિ વપરાશકર્તાના ટોકનમાંના SID વાંચે છે, અને ત્યાં ફક્ત સુરક્ષા જૂથો સૂચિબદ્ધ થાય છે, વિતરણ જૂથ ક્યારેય દેખાતું નથી. પ્રાથમિક જૂથ પોતાના ક્ષેત્રમાં રહે છે, સૂચિમાં નહીં, તેથી તેના પર તાળું મારેલી નીતિ ચૂપચાપ નિષ્ફળ થઈ શકે.
જૂથને અડકતા પહેલાં સ્વીકાર કે નકારનો રેકોર્ડ વાંચો
પહેલાં એક પ્રશ્ન પૂછો: વિનંતી ઑથરાઇઝેશન તબક્કે પહોંચી હતી? NPS પર જવાબ ઇવેન્ટ લોગમાં છે, જ્યાં 6272 આપેલ ઍક્સેસ, 6273 નકાર અને 6274 એ વિનંતી નોંધે છે જે સર્વરે નીતિ મૂલ્યાંકન પહેલાં ફેંકી દીધી. એ ત્રણ નંબર સમસ્યાને ત્રણ અલગ તપાસમાં વિભાજિત કરે છે, અને તેમાંથી ફક્ત એક જ જૂથો વિશે છે.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
લોગ પહોંચમાં ન હોય ત્યારે સર્વરને સીધું પૂછો અને તે શું પરત આપે છે તે વાંચો. Filter-Id અને ટનલ એટ્રિબ્યુટ વગરનો જવાબ કહે છે કે સર્વર સત્રને સામાન્ય માને છે અને ગેટવે પોતાના નિયમો લાગુ કરે છે. જે એટ્રિબ્યુટ અમલબદ્ધ બિંદુ લાગુ કરતું નથી તેવો જવાબ બીજી ખામી છે: ઑથરાઇઝેશન પસાર થયું અને ઉપકરણે પરિણામ અવગણ્યું.
radtest alice 'password' 10.0.0.5 0 testing123પરત મળેલા એટ્રિબ્યુટની ગેટવે જે દસ્તાવેજ કરે છે તેની સાથે સરખામણી કરો, જૂથના નામે જે સૂચવે છે તેની સાથે નહીં. એ સરખામણી સામાન્ય રીતે નીતિની સમસ્યાને અમલબદ્ધીની સમસ્યાથી અલગ પાડે છે.
જૂથ ફેરફાર ભૂતકાળમાં લાગુ પડતો નથી
ઑથરાઇઝેશન એટ્રિબ્યુટ એક વાર પરત મળે છે, જ્યારે સત્ર પ્રમાણિત થાય છે. ગેટવે તેમને સત્ર પર રાખે છે અને દરેક પેકેટ માટે ડિરેક્ટરી ફરી વાંચતું નથી, તેથી કોઈને જૂથમાંથી કાઢ્યા પછી પણ સ્થપાયેલું સત્ર ચાલુ રહે છે, અને નવું નિષ્ફળ થઈ શકે.
ફેરફાર અમલમાં આવે તે માટે નવો ઑથરાઇઝેશન નિર્ણય જોઈએ, ફક્ત નવી ચાવીઓ નહીં. જ્યાં સર્વર RFC 5176 ગતિશીલ ઑથરાઇઝેશનને સપોર્ટ કરે છે, ત્યાં UDP 3799 પર Disconnect-Request કે CoA-Request સત્રને ફરી મૂલ્યાંકન કરવા દબાણ કરે છે; નહીં તો ક્લાયન્ટ ડિસ્કનેક્ટ કરો અને ફરી જોડાવા દો. ફરી વાટાઘાટ ટનલ ચાવીઓ તાજી કરે છે અને સામાન્ય રીતે ઑથરાઇઝેશન પરિણામ અકબંધ રાખે છે.
શરત સુધારો, જૂથ નહીં
કઈ નીતિ ચાલી તે જાણ્યા પછી સુધારો સામાન્ય રીતે નાનો હોય છે: ઇચ્છિત મંજૂરીને ઢાંકતા નકારનો ક્રમ બદલો, જે નીતિ ધ્યાનમાં હતી તેમાં ખૂટતી ઉપકરણ કે MFA શરત ઉમેરો, અથવા વપરાશકર્તાને બીજા દસ ધરાવતા જૂથમાં લઈ જવાને બદલે એક સંસાધન માટે સાંકડો નિયમ લખો.
ટૂંકું લૂપ ફેરફારને પ્રામાણિક રાખે છે:
- મૂળ ખાતા સાથે નકાર ફરી ઉત્પન્ન કરો અને કંઈ બદલતા પહેલાં ઇવેન્ટ ID લખી લો.
- એક જ ઑબ્જેક્ટ બદલો, નીતિ ક્રમ, એક શરત કે એક જૂથ, અને કયું બદલ્યું તે નોંધો.
- નવું સત્ર ખોલો, લોગમાં મંજૂરી દેખાય છે અને સંસાધન ખરેખર ખૂલે છે તેની ખાતરી કરો.
- એવા વપરાશકર્તાનું પરીક્ષણ કરો જેને હજી નકારવો જોઈએ, જેથી સુધારાએ નીતિ ભૂલથી પહોળી ન કરી હોય.
મંજૂરી સાચી હોય અને સંસાધન ન ખૂલે તો, ઑથરાઇઝેશન પસાર થયાની ક્ષણે જ સમસ્યા રૂટિંગ કે નામ-નિરાકરણ તરફ ખસી ગઈ છે. એ બે ખામી અલગ રાખો, આગલી ટિકિટ અડધા દિવસને બદલે મિનિટો લેશે.