NPS જૂથ નીતિ VPN સંસાધન અમલીકરણ નથી

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

જૂથ સાથે મેળ ખાતી નેટવર્ક નીતિ પ્રવેશ વિશે પુરાવો છે. તે પેકેટ વિશે પુરાવો નથી, અને આ બે વિધાન વચ્ચેનું અંતર એ છે જ્યાં આ કામનો મોટો ભાગ થાય છે.

એ નીતિ શોધો જેણે ખરેખર સત્ર સ્વીકાર્યું

NPS ક્રમાંકિત નેટવર્ક નીતિઓનું મૂલ્યાંકન કરે છે, અને જે પ્રથમ સક્ષમ નિયમની શરતો મેળ ખાય તે જીતે છે. શરતોમાં વપરાશકર્તા કે કમ્પ્યુટર જૂથની સભ્યપદ, જોડાણનો પ્રકાર, સમય અને ઉપકરણની સ્થિતિ સામેલ હોઈ શકે. તેથી યાદીમાં વહેલા મૂકાયેલી વિશાળ નીતિ, નીચેનો સાંકડો નિયમ વિચારાય તે પહેલાં જ જોડાણ સ્વીકારી લે છે. ક્રમ ઇન્ટરફેસની વિગત નથી; ક્રમ જ નીતિ છે.

યાદી ક્રમમાં વાંચો અને જે મેળ ખાયું તે ઓળખો, પછી તે કઈ સેટિંગ્સ પરત આપી તે નોંધો. એડિટરમાં જૂથનું નામ પરિણામ નથી; પરિણામ એ અધિકૃતિ છે જે સર્વરને મળી. જ્યાં જમાવટ બંને વાપરે છે ત્યાં વપરાશકર્તા અધિકૃતિ અને ઉપકરણ અધિકૃતિ અલગ રાખો, કારણ કે ટનલ ખોલી શકતું ખાતું આપમેળે એવું ખાતું નથી જે દરેક આંતરિક સેવા સુધી પહોંચવું જોઈએ.

RADIUS જવાબ સૂચના છે, ફિલ્ટર નથી

Filter-Id વિશેષતા ફિલ્ટર યાદીનું નામ ધરાવે છે. તે દરેક પ્રાપ્તકર્તા સમજે એવા પેકેટ-ફિલ્ટર નિયમોનો વહનયોગ્ય સમૂહ મોકલતું નથી, અને ગેટવેએ ક્યારેય વ્યાખ્યાયિત ન કર્યું હોય એવું નામ મોકલવાથી કંઈ પણ લાગુ થતું નથી. એ જ સાવચેતી VLAN વિશેષતાઓને લાગુ પડે છે: ટનલ સત્રને VLAN સોંપવું તે પોતે જ તે વપરાશકર્તા માટે રૂટ કરેલ પ્રવેશ નિયમ નથી.

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

અમલીકરણને ત્યાં મૂકો જ્યાં ટ્રાફિક પસાર થાય છે

વપરાશકર્તાના પેકેટ પ્રક્રિયા કરતું ગેટવે દરેક સત્ર માટે ફિલ્ટર લાગુ કરી શકે, જૂથને ગેટવે નીતિ સાથે મેપ કરી શકે, અથવા સત્રને અલગ કરેલા પૂલમાંથી સરનામું આપી શકે જેને ફાયરવોલ જુદી રીતે ગણે છે. આમાંથી કોઈ પણ કામ કરી શકે, અને તે જુદી જુદી રીતે નિષ્ફળ જાય છે. નીતિ લખતા પહેલાં નક્કી કરો કે તમારું ગેટવે કઈ પદ્ધતિને સમર્થન આપે છે. પછી લખો કે તે પદ્ધતિ ન હોય ત્યારે સત્રનું શું થાય, કારણ કે મૌન એ ડિફૉલ્ટ છે.

ઇચ્છિત પરવાનગી ચાર ભાગમાં વર્ણવો: સ્રોત ઓળખ કે જૂથ, ગંતવ્ય, પ્રોટોકૉલ અને પોર્ટ. વપરાશકર્તાને ખરેખર જરૂરી હોય એવી નિર્ભરતાઓ ઉમેરો, જેમ કે DNS અથવા પ્રમાણીકરણ સેવા, નહીં તો પ્રતિબંધ એ લૉગિન પ્રવાહો તોડશે જે ચકાસવાનું કોઈને વિચાર પણ ન આવ્યો. નિયમ એ ઇન્ટરફેસ સામે લખો જે ખરેખર ફિલ્ટર કરે છે, એ ઇન્ટરફેસ સામે નહીં જે એડિટરમાં કિસ્મતથી ખુલ્લું છે.

અનુવાદને પણ ધ્યાનમાં લો. જો નીચેની ફાયરવોલ દરેક ટનલ વપરાશકર્તા માટે એક અનુવાદિત સ્રોત સરનામું જુએ છે, તો તે ફક્ત તે સરનામાથી વ્યક્તિઓને અલગ ન કરી શકે, અને એવી રીતે લખાયેલો નિયમ જાણે તે કરી શકે, તે કાં તો નકામો કાં તો વધુ પડતો વિશાળ હશે.

ક્લાયન્ટ પ્રોફાઇલ અવિશ્વાસપાત્ર બાજુ પર રહે છે

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

ક્લાયન્ટ સેટિંગ્સને સુવિધા અને ગેટવે સેટિંગ્સને નિયંત્રણ ગણો. જ્યારે બંને મતભેદ ધરાવે, ત્યારે ગેટવે સાચું છે, કારણ કે પેકેટ તે જ જુએ છે.

બે ખાતાં સાથે સ્વીકારો, પછી ક્રમમાં શોધ કરો

અલગ ઇચ્છિત પરવાનગીઓ સાથે બે સામાન્ય પરીક્ષણ ખાતાં બનાવો, નવાં સત્ર સ્થાપિત કરો અને દરેક માટે અસરકારક ગેટવે નીતિ ચકાસો. પછી એક નિર્દોષ મંજૂર ક્રિયા અને એક ખાસ નકારાયેલ સંસાધન ચકાસો. નિષ્ફળ ping પોતે બહુ ઓછું સાબિત કરે છે, કારણ કે ICMP ફિલ્ટર થઈ શકે છે જ્યારે તેની પાછળની TCP સેવા આનંદથી જવાબ આપે છે.

જ્યારે બંને ખાતાં હજી વિશાળ પ્રવેશ મેળવે છે, ત્યારે નિશ્ચિત ક્રમમાં શોધ કરો: કઈ નીતિ મેળ ખાઈ, જવાબ કઈ અધિકૃતિ ધરાવતો હતો, અને ગેટવેએ તેની સાથે શું કર્યું. પ્રાપ્તકર્તા તેને અમલમાં મૂકે તેની ખાતરી કરતાં પહેલાં વધુ NPS વિશેષતાઓ ઉમેરવી એ એ રીત છે જેમાં નાની અધિકૃતિ સમસ્યા પરિણામ વિનાની ફેરફાર વિંડો બની જાય છે.