VPN ક્લાયન્ટ માટે ડોમેન કંટ્રોલર પિન કરવા સામે AD સાઇટ મેપિંગ

VPN પૂલ પરના રિમોટ-એક્સેસ ક્લાયન્ટ આખરે દુનિયાના બીજા છેડેના ડોમેન કંટ્રોલર સાથે વાત કરી શકે છે, અને તેને સુધારવાની બે રીતો છે: પૂલને યોગ્ય કંટ્રોલર ધરાવતી સાઇટ સાથે જોડાયેલા Active Directory સબનેટ તરીકે વર્ણવો, અથવા ક્લાયન્ટ કે એપ્લિકેશનને એક ચોક્કસ કંટ્રોલર પર પિન કરો. પહેલી રીત એ ટોપોલોજીનું નિવેદન છે જેના પર DC Locator કાર્ય કરી શકે. બીજી રીત દરેક એપ્લિકેશન માટેનું ઓવરરાઇડ છે જે ટોપોલોજીને સંપૂર્ણ અવગણે છે. બંનેનો ખર્ચ અલગ છે, અને આજે ઝડપી વાળી પસંદ કરવી એ જ રીતે ડિરેક્ટરી ટીમ આખરે બંને જાળવવા લાગે છે.

દરેક અભિગમ ખરેખર શું બદલે છે

સબનેટ ઑબ્જેક્ટ એ ડિરેક્ટરી રેકોર્ડ છે જે કહે છે કે એડ્રેસ રેન્જ કઈ સાઇટની છે. Active Directory મોડ્યુલ અને હાલની સાઇટ સાથે, ઑપરેશન પૂર્વદર્શન કરવા જેટલું નાનું છે:

New-ADReplicationSubnet -Name "10.90.0.0/24" -Site "Remote-Access-Hub" -WhatIf
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

-WhatIf ડિરેક્ટરી રાઇટનું પૂર્વદર્શન કરે છે. તે ઑબ્જેક્ટ બનાવતું નથી અને તે રેન્જના ક્લાયન્ટ કંઈક સુધી પહોંચી શકે છે કે નહીં તે ચકાસતું નથી, અને લોકો એ જ ભાગની અપેક્ષા રાખે છે. DC Locator સાઇટ મોડેલ વાંચે છે જ્યારે તે સેવા રેકોર્ડ ઉકેલે છે, તેથી સચોટ સબનેટ ઑબ્જેક્ટ ક્લાયન્ટને શું આપવામાં આવે છે તે બદલે છે.

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

સબનેટ મેપિંગ ક્યાં જીતે છે

પૂલને મેપ કરવાથી DC Locator વાપરતા દરેક ક્લાયન્ટ માટે નેટવર્ક સ્થાન એક વાર વર્ણવાય છે. જ્યારે પૂલ એક /24 થી ત્રણ સુધી વધે છે, ત્યારે મોડેલ એપ્લિકેશન ઇન્વેન્ટરીમાં નહીં પણ બે કે ત્રણ ઑબ્જેક્ટમાં બદલાય છે. આખો ફાયદો એ જ છે, અને જ્યારે ક્લાયન્ટ સંખ્યા તમારા નિયંત્રણમાં ન હોય ત્યારે તે મોટો છે.

ઝચવું એ છે કે ઑબ્જેક્ટ કંટ્રોલર ખરેખર જે એડ્રેસ જુએ તેની સાથે મેળ ખાવો જોઈએ. જો VPN ગેટવે દરેક ક્લાયન્ટને હબ એડ્રેસમાં રૂપાંતરિત કરે, તો અનુવાદ ન કરેલ પૂલ ઉમેરવાથી એવું નેટવર્ક સ્થાન વર્ણવાય છે જે કોઈ કંટ્રોલર ક્યારેય જોતું નથી. ડિઝાઇન ક્લાયન્ટનું સ્રોત એડ્રેસ જાળવે છે કે નહીં તે વહેલું નક્કી કરો, અને ન જાળવે તો VPN સર્વર પર ગોઠવેલ પૂલને બદલે રૂપાંતરિત રેન્જ મેપ કરો.

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

પિનિંગ ક્યાં જીતે છે

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

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

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

ત્રણ શરતો પર પસંદ કરો

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

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

VPN ક્લાયન્ટથી ચકાસો અને કરાર અલગ રાખો

સાઇટમાં પહેલેથી હાજર LAN વર્કસ્ટેશનથી નહીં, વાસ્તવિક રિમોટ માર્ગથી પરીક્ષણ કરો. ફક્ત ક્લાયન્ટનું પોતાનું દૃશ્ય જ મહત્વનું છે:

nltest /dsgetsite
nltest /dsgetdc:corp.example.com /force
echo %LOGONSERVER%

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

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