Split-DNS કેપ્ચર: દરેક નિરીક્ષણ ક્યાં લેવાયું તે કહો

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

એક લુકઅપ, અનેક નિરીક્ષણ બિંદુઓ

એક આંતરિક નામ માટે જોવાની ઓછામાં ઓછી પાંચ જગ્યાઓ છે: એપ્લિકેશન અને તે જે resolver API ને બોલાવે છે, ક્લાઇન્ટ પર અમલમાં રહેલી ડોમેન નીતિ, એડેપ્ટર કે ફિલ્ટર પરનું કેપ્ચર, નિયંત્રિત ગેટવે સીમા, અને જે resolver ખરેખર ક્વેરી મેળવે છે.

દરેક અલગ પ્રશ્નનો જવાબ આપે છે, અને એકલું કોઈ પણ સાબિત કરતું નથી કે ક્વેરી ક્યાં ગઈ.

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

ક્લાઇન્ટનું ફિલ્ટર એપ્લિકેશન અને વાયર વચ્ચે બેસે છે

Split-DNS સાથેનું VPN ક્લાઇન્ટ પેકેટ મશીન છોડે તે પહેલાં ડોમેન મેળ બનાવે છે. ટનલ કરેલા સફિક્સના નામ આંતરિક resolver પર જાય છે; બાકીનું બધું સ્થાનિક resolver પર જાય છે. ફિલ્ટર નીતિ છે, અને નીતિ પ્લેટફોર્મ તથા ક્લાઇન્ટ આવૃત્તિ પ્રમાણે બદલાઈ શકે છે.

Cisco નું Secure Client Split-DNS માર્ગદર્શન ડોમેન મેળ અને Windows ફિલ્ટર આવરી લે છે, અને એપ્લિકેશન મૂળ resolver API વાપરે ત્યારે શું જુએ છે તેને nslookup જેવા સાધન શું જુએ છે તેનાથી અલગ પાડે છે. એ જ ભેદ મુખ્ય મુદ્દો છે.

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

nslookup એપ્લિકેશન કરતાં અલગ માર્ગ લે છે

nslookup પોતાની DNS ક્વેરી બનાવે છે અને ઓપરેટિંગ સિસ્ટમની resolver નીતિને ટાળી શકે છે. એ તેને ચોક્કસ સર્વરને ચોક્કસ પ્રશ્ન પૂછવા માટે ઉપયોગી સાધન બનાવે છે, અને એપ્લિકેશન શું અનુભવશે તે કસવા માટે ભ્રામક સાધન.

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

નીતિ વાંચો અને પછી સામાન્ય resolver દ્વારા એ જ પ્રશ્ન પૂછો:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

એન્ક્રિપ્ટેડ resolver ક્વેરી છુપાવે છે, જોડાણ નહીં

પોતાનું DNS-over-HTTPS resolver ધરાવતું બ્રાઉઝર સાવ અલગ કિસ્સો છે. ક્વેરી TLS ની અંદર નીકળે છે, તેથી પેકેટ કેપ્ચર resolver સરનામા સાથેનું જોડાણ દર્શાવે છે પણ પૂછાતું નામ દર્શાવતું નથી.

પહેલાં બ્રાઉઝરની સંચાલિત નીતિ શોધો, પછી તેને ઓપરેટિંગ સિસ્ટમના લુકઅપ સાથે સરખાવો. પોતાનું resolver પસંદ કરવાની પરવાનગી ધરાવતું બ્રાઉઝર Split-DNS નીતિ જોઈ શકે જ નહીં.

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

લેબલ કરેલી કસોટી સાથે સરખાવો

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

જ્યાં મંજૂર હોય, resolver ની પ્રાપ્તિને એક સાંકડા ક્લાઇન્ટ કે ગેટવે નિરીક્ષણ સાથે સરખાવો:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

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