કઈ લિંક જવાબ આપે છે: સ્પ્લિટ-ટનલ VPN DNS માટે રૂટિંગ ડોમેન
ડિફૉલ્ટ રૂટ અને DNS રૂટિંગ ડોમેન અલગ સેટિંગ્સ છે. કંપનીની સફિક્સને ટિલ્ડા સાથે ઉમેરો, પછી resolvectl ને પૂછો કે કઈ લિંકે ખરેખર જવાબ આપ્યો.
સામાન્ય બ્રાઉઝિંગ સ્થાનિક લિંક પર રાખો, જ્યારે કંપનીના નામ ટનલ પૂરો પાડે છે તે DNS સર્વર દ્વારા ઉકેલાય. VPN નો ડિફૉલ્ટ રૂટ બંધ કરવાથી પ્રથમ અડધો ભાગ મળે છે અને બીજો અડધો અણબનેલો રહે છે. નીચે આવે છે ખૂટતું સેટિંગ, અર્થ બદલતું વિરામચિહ્ન, અને એકમાત્ર આદેશ જે બતાવે છે કે કઈ લિંકે ખરેખર જવાબ આપ્યો. આખા લખાણમાં NetworkManager અને systemd-resolved ધારી લેવાયા છે, કારણ કે સામાન્ય રીતે ગૂંચવણ ત્યાંથી જ શરૂ થાય છે.
પગલું એક: રૂટને રિઝોલ્વરથી અલગ કરો
ipv4.never-default રૂટિંગ પ્રશ્નનો જવાબ આપે છે અને NetworkManager ને આ કનેક્શનને બધા IPv4 ટ્રાફિકના માર્ગ તરીકે સ્થાપિત કરતું અટકાવે છે. DNS રૂટિંગ ડોમેન બીજા પ્રશ્નનો જવાબ આપે છે: કઈ લિંકના નામ સર્વરને મેળ ખાતી સફિક્સ માટેની ક્વેરી મળે છે. એક બીજાને સૂચવતું નથી, અને પ્રોફાઇલ વર્ષો સુધી એક વહન કરી શકે જ્યારે બીજું ખૂટે. ફક્ત-રૂટ એટલે ટનલ કંપનીના સબનેટ વહન કરે છે અને તેનો રિઝોલ્વર કંપનીના નામોનો જવાબ આપે છે, જ્યારે બાકીનું બધું અડ્યા વગર રહે છે.
ફક્ત રૂટ પ્રોપર્ટી સેટ કરો તો અંદરના નામ નિષ્ફળ જાય, સામાન્ય રીતે ટાઇમઆઉટ સાથે જે તૂટેલી ટનલ જેવો લાગે. ફક્ત ડોમેન સેટ કરો તો મશીન પરના દરેક ટૂંકા નામમાં ચૂપચાપ સર્ચ સફિક્સ ઉમેરી દીધી છે. બંને ભૂલો ટિકિટને VPN સર્વર પર મોકલે છે, જે ભાગ્યે જ ખોટો ભાગ હોય છે.
પગલું બે: પ્રોફાઇલમાં ફક્ત-રૂટિંગ ડોમેન ઉમેરો
ધારો કે કનેક્શનનું નામ corp-vpn છે, કંપનીની સફિક્સ internal.example છે, અને ટનલનો રિઝોલ્વર પહેલેથી પહોંચી શકાય તેવો છે. પહેલા વર્તમાન મૂલ્યો વાંચો, કારણ કે નીચેના આદેશો એવી પ્રોપર્ટી બદલે છે જેમાં પહેલેથી એન્ટ્રી હોઈ શકે.
nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yesતમારા પોતાના કનેક્શન નામ અને સફિક્સ મૂકો, કારણ કે ઉપરનાં મૂલ્યો ઉદાહરણરૂપ છે. પ્લસ ચિહ્ન દેખાય તેનાથી વધુ મહત્ત્વનું છે: તેની સાથે મૂલ્ય હાલની યાદીમાં ઉમેરાય છે, જ્યારે તેના વગર પ્રોપર્ટી બદલાઈ જાય છે અને ગઈકાલે કામ કરતી પ્રોફાઇલમાંથી અસંબંધિત ડોમેન અદૃશ્ય થાય છે. ટિલ્ડા શૈલી નહીં, વર્તન બદલે છે, અને નીચેનો ફકરો જણાવે છે કે તે શું પસંદ કરે છે. લખતાં પહેલાં વાંચન રાખો, જેથી બદલીનું સ્વરૂપ તમને ક્યારેય ચોંકાવે નહીં.
શરૂઆતનું ટિલ્ડા ફક્ત-રૂટિંગ ડોમેન દર્શાવે છે, એટલે મેળ ખાતી ક્વેરી આ લિંકના સર્વર પર જાય છે અને સફિક્સ ટૂંકા નામોમાં ઉમેરાતી નથી. ટિલ્ડા કાઢી નાખો તો એ જ સ્ટ્રિંગ સર્ચ સફિક્સ પણ બને છે, જે અલગ પરિણામ છે અને લોકો ભાગ્યે જ તે ઇચ્છે છે. ઉપરનાં બંને સેટિંગ IPv4 છે, તેથી ડ્યુઅલ-સ્ટેક પ્રોફાઇલને ipv6.never-default અને ipv6.dns-search માં એ જ રૂટિંગ ડોમેન જોઈએ, નહીં તો IPv6 બાજુ ડિફૉલ્ટ રૂટ વાપરવાનું ચાલુ રાખે છે અને ત્યાં અંદરના નામ નિષ્ફળ જાય છે.
પગલું ત્રણ: resolvectl ને પૂછો કે કઈ લિંકે જવાબ આપ્યો
resolvectl status ચલાવો અને દરેક લિંકના DNS સર્વર અને ડોમેન વાંચો, પછી એક વાસ્તવિક અંદરના નામ પર resolvectl query host.internal.example ચલાવો જેની ક્વેરી કરવાની તમને પરવાનગી છે. બીજો આદેશ એ એકમાત્ર સીધો પુરાવો છે કે રૂટિંગ ડોમેન પોતાનું કામ કરે છે, કારણ કે તે જવાબ આપનાર લિંકનું નામ લે છે. ફક્ત સ્ટેટસ યાદી રૂપરેખા પુરવાર કરે છે; ક્વેરી રિઝોલ્યુશન પુરવાર કરે છે.
systemd-resolved સૌથી સારી રીતે મેળ ખાતું રૂટિંગ ડોમેન પસંદ કરે છે, તેથી બીજી લિંક પરનું વધુ ચોક્કસ ડોમેન હજી દોડ જીતી શકે છે. ક્વેરી તમે અપેક્ષા ન કરી હોય તેવી લિંક પરથી પાછી આવે તો VPN ના DNS સર્વરને અડતાં પહેલાં ડોમેન યાદીઓ વાંચો. ~. રૂટ ડોમેન બધા સાથે મેળ ખાય છે, અને જો તે પહેલેથી હાજર હોય તો તમારું ચોક્કસ ડોમેન પોતાના નામો માટે હજી જીતે છે જ્યારે લિંક તમે માંગ્યું તેના કરતાં ઘણું વધારે જવાબ આપે છે. હેતુ ફક્ત કંપનીના નામ હોય ત્યારે તે રૂટ એન્ટ્રી દૂર કરો અથવા સાંકડી કરો.
VPN લિંક કોઈ DNS સર્વરની યાદી જ ન આપે તો ક્લાયંટે ક્યારેય એક પણ નોંધ્યો નથી. પાછળ સર્વર વગરનું રૂટિંગ ડોમેન ખૂટતા ડોમેન કરતાં અલગ રીતે નિષ્ફળ જાય છે, તેથી પહેલા નોંધણી સુધારો.
પગલું ચાર: જ્યારે નામ ઉકેલાય પણ સેવા નહીં
સાચો જવાબ ફક્ત એ પુરવાર કરે છે કે રિઝોલ્યુશન કામ કર્યું, અને એપ્લિકેશનને હજી મળેલા સરનામા સુધીનો રૂટ જોઈએ. એ રૂટે હમણાં રૂપરેખાંકિત કરેલા વિભાજિત ડિફૉલ્ટમાં ટકી રહેવું પડે, તેથી ફરી DNS ને દોષ આપતાં પહેલાં તેને તપાસો. પછી સેવાના પોર્ટ પર પહોંચને તપાસો, કારણ કે ફાઇલ શેરિંગ કે ડિરેક્ટરી સેવા રિઝોલ્યુશન, રૂટિંગ કે પ્રમાણીકરણમાં નિષ્ફળ જાય છે અને દરેક કિસ્સામાં લગભગ સમાન સંદેશા આપે છે. પરિણામ જણાવતી વખતે આ ત્રણ સ્તર અલગ રાખો, નહીં તો આગલી વ્યક્તિ પહેલેથી સાચા DNS ને ફરી તપાસે છે.
આ પ્રશ્ન સાથે ફરતું Samba ફેરફાર એક્સેસ સ્તરને લગતું છે, DNS પસંદગીને નહીં. નામ-રિઝોલ્યુશનની ખામી પર તેને લાગુ કરવું એ જ રીતે નાની સમસ્યાને બીજી મળે છે.
પગલું પાંચ: ખૂટતું ડોમેન સુધારવા રિઝોલ્વર બદલશો નહીં
રિઝોલ્વર ફાઇલ ઉપર લખી નાખતી કે બીજો રિઝોલ્વર મેનેજર સ્થાપિત કરતી સલાહ બીજી સમસ્યા ઉકેલે છે. તે સિસ્ટમ-ઇન્ટિગ્રેશન ફેરફારો છે જેમના પોતાના નિષ્ફળતાના પ્રકારો છે, અને તેમાંથી કોઈ પણ ક્યારેય રૂપરેખાંકિત ન થયેલું રૂટિંગ ડોમેન ઉમેરતું નથી. બદલતાં પહેલાં નક્કી કરો કે મશીન પર નામ-રિઝોલ્યુશન કયા ઘટકનું છે, કારણ કે systemd-resolved સાથેના NetworkManager ડેસ્કટોપ પર એ માલિકી પહેલેથી નિર્ધારિત છે. તેની સામે લડવું એ જ રીતે કામ કરતું સેટઅપ એવું બને છે જે કોઈ ફરી બનાવી શકતું નથી.
કામનો ક્રમ: ટનલ રિઝોલ્વર પૂરો પાડે છે તેની ખાતરી કરો, ફક્ત-રૂટિંગ ડોમેન ઉમેરો, પ્રોફાઇલ નિયંત્રણો દ્વારા ફરી જોડાઓ, જવાબ આપનાર લિંક ચકાસો, અને પછી સેવાને તેના પોર્ટ પર કસોટો. આ ક્રમ એવું પરિણામ છોડે છે જે બીજી મુલાકાત વગર આગલી વ્યક્તિને સોંપી શકાય.