VPN પર આંતરિક નામો નિષ્ફળ જ્યારે જાહેર સાઇટ્સ બરાબર રિઝોલ્વ થાય

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

બે લક્ષણો જે એક જ ખામી નથી

આંતરિક નામ રિઝોલ્વ ન થવાનો અર્થ છે કે પ્રશ્ન એવી જગ્યાએ ગયો જ્યાં તેનો જવાબ નથી. ક્વેરી ટનલમાંથી બહાર જવાનો અર્થ છે કે જવાબ ઉપલબ્ધ હોવા છતાં પ્રશ્ન ખોટી જગ્યાએ ગયો. તે વિરોધી ખામીઓ છે: એક ખૂટતો જવાબ છે, બીજી વધારાનું લક્ષ્ય છે.

છત્રાક એ છે કે ઓફિસ રિઝોલ્વરને બધે ઉમેરવાથી પહેલી સુધરે છે અને બીજીની ખાતરી થાય છે. જાહેર રિઝોલ્વર બધે ઉમેરવાથી ઊલટું થાય છે.

બંને અવલોકનો સમય-છાપ સાથે લખો, પછી નીચેની ચાર તપાસ ક્રમમાં કરો.

કયા એડેપ્ટરનું રિઝોલ્વર પ્રશ્ન મેળવે છે

Windows પર, DNS ક્લાયન્ટ એડેપ્ટર બાઇન્ડિંગ ક્રમ મુજબ સર્વર પસંદ કરે છે, અને ટનલ એડેપ્ટર આપમેળે પહેલું હોતું નથી. એડેપ્ટરની અદ્યતન સેટિંગ્સ ખોલો અને રિમોટ એક્સેસ કનેક્શનને ભૌતિક એડેપ્ટરની ઉપર ખસેડો, પછી ફરી કનેક્ટ કરો જેથી ફેરફાર નવા સેશન પર લાગુ થાય.

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

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

ટૂંકા નામને રૂટ પહેલાં સફિક્સની જરૂર છે

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

કામ કરતી મશીનનું સફિક્સ VPN એડેપ્ટરની IPv4 પ્રોપર્ટીઝમાં DNS ટેબ પર કૉપિ કરો, પછી ફરી કનેક્ટ કરો. Linux પર સમાન વસ્તુ ટનલ લિંક પરનું સર્ચ ડોમેન છે, જે systemd-resolved લિંક દીઠ આપે છે, વૈશ્વિક રીતે નહીં.

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

રિઝોલ્વરને સીધું પૂછો, પછી નામ

ઓફિસ રિઝોલ્વરને સીધી ક્વેરી નામની સમસ્યાને માર્ગની સમસ્યાથી અલગ કરે છે, કારણ કે તે ક્લાયન્ટની રિઝોલ્વર પસંદગીને સંપૂર્ણપણે ટાળે છે.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

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

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

Linux પર, /etc/resolv.conf ફરી લખતો VPN ક્લાયન્ટ સ્થાનિક રિઝોલ્વરને સંપૂર્ણ બદલી નાખે છે. vpnc એ અટકાવવા DNSUpdate no આપે છે, અને systemd-resolved ફક્ત સૂચિબદ્ધ ડોમેનને ટનલ લિંક પર રૂટ કરી શકે છે. બંને અભિગમ જાહેર નામો સ્થાનિક રિઝોલ્વર પર રાખે છે અને આંતરિક નામો ઓફિસે મોકલે છે.

લીક એ નિયમ છે, ચેકબોક્સ નહીં

નામ રિઝોલ્યુશન એ પોર્ટ 53 પરની UDP આપ-લે છે, તેથી વેબ ટ્રાફિક પણ UDP નહીં વહન કરતી ટનલ ક્વેરીને ભૌતિક માર્ગ પર છોડી દે છે. જાહેર નામ રિઝોલ્વ થાય ત્યારે ભૌતિક NIC પર કેપ્ચર કરીને સાબિત કરો. એ ઇન્ટરફેસ પર વાંચી શકાય તેવી ક્વેરી દેખાય તો ટનલ તેને વહન કરતી નથી.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

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

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

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