એક એડાપ્ટર પરના બે DNS સર્વર નેમસ્પેસને વિભાજિત કરતા નથી

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

દંતકથા: બે સરનામાં બે ડોમેનને વિભાજિત કરે છે

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

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

Windows પસંદગી માટે ખરેખર શું વાપરે છે

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

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

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

દરેક નેમસ્પેસ માટે એક નિયમ, ઑબ્જેક્ટ રાખો

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

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

શરૂઆતનું બિંદુ પ્રત્યય મેળ દર્શાવે છે, તેથી નિયમ app.svc.internal.example અને તેની નીચેનું બીજું બધું આવરી લે છે. અહીંના બે સરનામાં આ લેબની પોતાની રૂટિંગ યોજનાના છે; નિયમ ઝોન બનાવતો નથી, રૂટ ઇન્સ્ટોલ કરતો નથી કે અંતે જોડાતી એપ્લિકેશનને અધિકૃત કરતો નથી, અને Add-DnsClientNrptRule સંદર્ભ કયો પેરામીટર શું કરે છે તે બરાબર દસ્તાવેજ કરે છે.

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

સાબિત કરો કે ક્લાયન્ટે સર્વર પસંદ કર્યું

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

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

નિયમો અસ્તિત્વમાં આવ્યા તે પહેલાના સમયના કૅશ થયેલા જવાબો પર અને પોતાના એન્ક્રિપ્ટેડ DNS સાથે સિસ્ટમ રિઝોલ્વરને સંપૂર્ણપણે ટાળતી એપ્લિકેશનો પર નજર રાખો. સર્ચ પ્રત્યય બીજી અલગ સુવિધા છે: નિયમ સંપૂર્ણ નામ માટે રિઝોલ્વર પસંદ કરી શકે છે, પણ Windows ને એ શીખવ્યા વિના કે નરી હોસ્ટનામને એ નેમસ્પેસમાં વિસ્તારવું.

તમે જે બનાવ્યું તે બરાબર દૂર કરો

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

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

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