dnsmasq માં તમારું VPN ડોમેન ઝોન ટ્રાન્સફર નથી

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

ક્લાયન્ટે જે સ્વીકાર્યું તે ગેટવેએ જે રજૂ કર્યું તે નથી

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

તે ભેદ કદી ન આવેલા ડોમેનની મોટાભાગની રિપોર્ટ સમજાવે છે. તે રજૂ કરવામાં આવ્યું, અને લાગુ કરવામાં આવ્યું નહીં.

ડોમેન એન્ટ્રીના બે પ્રકાર

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

ખાનગી નામસ્થાન માટે સામાન્ય રીતે માત્ર-રૂટ સ્વરૂપ જ જોઈએ. તે કોર્પોરેટ સફિક્સને કોર્પોરેટ resolver તરફ રાખે છે અને બાકીનું બધું એકલું છોડી દે છે.

resolv.conf માં localhost કોઈ બગ નથી

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

તે એન્ટ્રીને જાહેર resolver સાથે બદલવું ક્લાસિક ખોટું સુધારણા છે. તે જાહેર નામ ઉકેલ પુનઃસ્થાપિત કરે છે અને તે જ સંપાદનમાં શરતી નીતિ ત્યજી દે છે.

બેકએન્ડ ભેગા ન કરો

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

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

નામસ્થાનની કસોટી કરો, ફક્ત જવાબની નહીં

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

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