તમારું VPN ત્રણ DNS સર્વર ધકેલે છે: કયું જવાબ આપે છે?
વધારાની એન્ટ્રીઓ ફૉલબૅક, પ્રતિ-ડોમેન રૂટ અથવા ભૌતિક લિંકનું અવશેષ હોઈ શકે. સૂચિને લીક કહેતા પહેલાં દરેકને એક વ્યાપ સાથે જોડો.
કનેક્ટ થયા પછી સેટિંગ્સ પૃષ્ઠ ખોલો અને ત્રણ DNS સરનામાં સૂચિબદ્ધ દેખાશે; ઓડિટનો પ્રશ્ન એ છે કે તમારી છેલ્લી ક્વેરી કયાએ સંભાળી. માત્ર સંખ્યા કંઈ જ જવાબ આપતી નથી, કારણ કે ક્લાયન્ટ પુશ, ભૌતિક ઇન્ટરફેસ અને પ્રતિ-ડોમેન નીતિ બધા એક જ દૃશ્યમાં લખે છે. આ એન્ટ્રીઓ જુદા જુદા વ્યાપ ધરાવે છે, અને જવાબ કોણ આપશે તે સ્થિતિ નહીં, વ્યાપ નક્કી કરે છે. સ્ત્રોતોને અલગ કરીને શરૂ કરો, પછી જે તમને મહત્ત્વનું છે તે નામ ધરાવતો સ્ત્રોત ચકાસો.
સૂચિ તમારી પ્રોફાઇલ કરતાં લાંબી કેમ છે
VPN ક્લાયન્ટ ટનલ લિંક માટે રિઝોલ્વર સરનામાં ધકેલે છે, અને ઓપરેટિંગ સિસ્ટમ તેમને ભૌતિક ઇન્ટરફેસ પાસે પહેલેથી જે હતું તેની બાજુમાં રાખે છે. રાઉટર, કોર્પોરેટ DHCP લીઝ, બીજું VPN અને પ્રતિ-ડોમેન નીતિ દરેક પોતાની એન્ટ્રી ઉમેરે છે. તેથી પૃષ્ઠ પર ત્રણ સરનામાં એક કામ માટે ત્રણ ઉમેદવાર નહીં, ત્રણ વ્યાપ દર્શાવી શકે. સંખ્યાને લીકના પુરાવા તરીકે વાંચવું આ ઓડિટની પ્રથમ ભૂલ છે.
એક ઇન્ટરફેસની અંદર ક્લાયન્ટ ખરેખર તેના સર્વરો ક્રમમાં અજમાવે છે, તેથી ક્રમબદ્ધ સૂચિ અર્થહીન નથી. જે કતાર નથી તે સંમિલિત દૃશ્ય છે, જ્યાં પ્રોફાઇલ, ભૌતિક લિંક અને પ્રતિ-ડોમેન નિયમોની એન્ટ્રીઓ એક પણ ક્રમાંકન વિના બાજુબાજુ બેસે છે. એ ભેદ જ નક્કી કરે છે કે તમે શું ચકાસશો: ક્રમ એક વ્યાપની અંદરનું વર્તન સમજાવે છે, અને વ્યાપ બાકીનું બધું.
એન્ક્રિપ્ટેડ DNS એપ્લિકેશનની અંદરથી ચિત્ર તોડે છે. પોતાનું DNS-over-HTTPS રિઝોલ્વર ધરાવતું બ્રાઉઝર કે ચેટ ક્લાયન્ટ ઓપરેટિંગ સિસ્ટમની સૂચિને સંપૂર્ણ બાજુમાં રાખીને ક્વેરી મોકલે છે, તેથી સેટિંગ્સ પૃષ્ઠના સરનામાં એવા ટ્રાફિકનું વર્ણન કરે છે જે એપે ક્યારેય ઉત્પન્ન કર્યો નહીં. નામ ખોટું આવ્યું તે માટે પ્રોફાઇલને દોષ આપતા પહેલાં એપનું પોતાનું રિઝોલ્વર સેટિંગ તપાસો.
ત્રણ તપાસમાંથી દરેક શું કહે છે
દરેક સ્ત્રોત પોતાની છાપ જુદી જગ્યાએ મૂકે છે, અને કોઈ એક કમાન્ડ બધા દેખાડતું નથી. સેટિંગ્સ પૃષ્ઠની બાજુમાં રાખવા લાયક મેપિંગ આ છે:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
systemd-resolved વાપરતી સિસ્ટમમાં resolvectl status સત્તાવાર છે, કારણ કે તે રૂટિંગ ડોમેન સાથે પ્રતિ-લિંક DNS નોંધે છે. macOS scutil --dns દ્વારા જવાબ આપે છે, જે વ્યાપવાળા રિઝોલ્વરને અજમાવવાના ક્રમમાં સૂચિબદ્ધ કરે છે. Windows બે અર્ધ ભાગે છે: પ્રતિ-ઇન્ટરફેસ સર્વર માટે Get-DnsClientServerAddress અને સફિક્સ નિયમો માટે Get-DnsClientNrptPolicy. ખરેખર વપરાતા રિઝોલ્વરનો કમાન્ડ ચલાવો, કારણ કે કન્ટેનર રનટાઇમ અને ડેસ્કટોપ રિઝોલ્વર ધરાવતી મશીનમાં એકથી વધુ સ્થાપિત હોઈ શકે.
બેકઅપ રિઝોલ્વર જે તમારા ઝોનનો જવાબ આપી શકતું નથી
બીજી એન્ટ્રી સામાન્ય રીતે ઉપલબ્ધતા માટે હોય છે, અને ઉપલબ્ધતા ત્યારે જ કામ કરે જ્યારે બેકઅપ નામો જાણતું હોય. જાહેર રિઝોલ્વરને આંતરિક હોસ્ટનામ પૂછો તો તે NXDOMAIN પરત આપે, અથવા તમારા સાથે કોઈ સંબંધ ન હોય તેવા સર્ચ ડોમેન તરફથી વાઇલ્ડકાર્ડ જવાબ આપે. કોઈએ ચકાસ ન કરેલું ફેઇલઓવર પછી જે ક્ષણે તેની જરૂર હોય તે જ ક્ષણે આઉટેજ ઊભું કરે છે.
Split DNS એને રોકવા માટે છે: કંપનીના સફિક્સ ઝોન ધરાવતા રિઝોલ્વર પાસે જાય છે, અને જાહેર નામો ડિફૉલ્ટ માર્ગ પર રહે છે. ડિઝાઇન નક્કર છે, અને તે સફિક્સ સૂચિ પૂર્ણ હોવા પર આધાર રાખે છે. Microsoft એ પ્રતિ-સફિક્સ રિઝોલ્વર નીતિ ને દસ્તાવેજીકરણ કરી છે જે Windows પર આ ચલાવે છે, અને એ જ વિચાર systemd-resolved માં રૂટિંગ ડોમેન તરીકે અને macOS પર વ્યાપવાળા રિઝોલ્વર તરીકે દેખાય છે.
બેકઅપ કયા ઝોનનો જવાબ આપી શકે તેની નીતિમાંના સફિક્સ સાથે તુલના કરો. એ તુલના વપરાશકર્તા ટનલ ફેરફાર પછી એક આંતરિક સાઇટ રિઝોલ્વ થવાનું બંધ થયું હોવાની જાણ કરે તે પહેલાં જ ખાલી જગ્યા શોધી લે છે.
ઓપરેટિંગ સિસ્ટમના રિઝોલ્વર દ્વારા ક્વેરી કરો, તેની આસપાસ નહીં
ઓપરેટિંગ સિસ્ટમના રિઝોલ્વર દ્વારા ક્વેરી કરો, કારણ કે સર્વરને સીધી ક્વેરી નીતિને બાજુમાં રાખે છે અને ફક્ત એ સર્વર શું કહેશે તે નોંધે છે. બે જવાબ વચ્ચેની ખાલી જગ્યા જ આખો મુદ્દો છે:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53જો સિસ્ટમ ક્વેરી ખાનગી સરનામું પરત આપે જ્યારે સીધી ક્વેરી NXDOMAIN પરત આપે, તો નીતિ કામ કરે છે અને બેકઅપ નબળું બિંદુ છે. જો બંને એક જ જાહેર જવાબ પરત આપે, તો નામ તમે ઇચ્છેલા વ્યાપની બહાર રિઝોલ્વ થાય છે, અને સફિક્સ સૂચિ જોવાની જગ્યા છે. બંને આઉટપુટ રાખો, કારણ કે સેટિંગ્સ પૃષ્ઠના સ્ક્રીનશૉટ કરતાં બે લીટીથી રિઝોલ્વર ચર્ચા ઝડપથી પતે છે.
પછી નિષ્ફળતાનો માર્ગ કસો, કારણ કે કોઈએ ન ચકાસેલો ફૉલબૅક એક ધારણા છે. એક ક્વેરી માટે પ્રિફર્ડ રિઝોલ્વરને બ્લેકહોલ બનાવો અને જુઓ કયું સરનામું પાછું આવે છે:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32ક્વેરી પૂરી થતાં જ એ રૂટ કાઢી નાખો, નહીંતર આગલી વ્યક્તિને એક કોયડો વારસામાં મળે. જો એ સમયગાળામાં આંતરિક નામો હજી રિઝોલ્વ થતા હોય, તો ઇચ્છિત વ્યાપની બહારની કોઈ વસ્તુએ તેમને જવાબ આપ્યો છે. જો તેના બદલે સમય પૂરો થાય, તો ફૉલબૅક ગેરહાજર છે અથવા યોગ્ય રીતે મર્યાદિત છે, અને રિઝોલ્વરનો પોતાનો લોગ કહી દેશે કે બેમાંથી કયું હતું.
નક્કી કરો: રાખો, મર્યાદિત કરો કે દૂર કરો
બીજું રિઝોલ્વર ત્યારે રાખો જ્યારે તે તમને જરૂરી નામસ્થાનનો જવાબ આપે અને પ્રોફાઇલ હેઠળ પહોંચી શકાય તેવું રહે. તેને ત્યારે મર્યાદિત કરો જ્યારે તેને ફક્ત એક સફિક્સ જ દેખાવું જોઈએ અને બીજું કંઈ નહીં, અને તેને દૂર કરો જ્યારે તેની પાસે ન વ્યાપ હોય ન દસ્તાવેજી હેતુ હોય. કામ વગરની એન્ટ્રી લાભ વગરનું ભાવિ લીક છે, અને વેન્ડરનું ડિફૉલ્ટ હેતુ નથી.
પરિણામ ચાર કૉલમમાં નોંધો: સફિક્સ, રિઝોલ્વર, ઇન્ટરફેસ અને માલિક. એ લીટી કોઈ પણ સ્ક્રીનશૉટ કરતાં ઝડપથી આગલા ઓડિટ પ્રશ્નનો જવાબ આપે છે, અને સૂચિને શાંતિથી ફરી ગોઠવતા ક્લાયન્ટ અપડેટમાંથી પણ ટકી રહે છે.