resolvectl આઉટપુટમાંથી દરેક લિંક માટે VPN DNS રાઉટિંગ કેવી રીતે વાંચવું
resolvectl status દરેક લિંક માટે સર્વર, ડોમેન અને ડિફોલ્ટ રૂટ દર્શાવે છે। તેમને સાથે વાંચો, પછી નામ પૂછો અને કઈ લિંકે જવાબ આપ્યો તે નોંધો।
resolvectl status ચલાવો અને તમને દરેક લિંક માટે બ્લોકની દીવાલ મળશે, દરેકને પોતાના સર્વર અને પોતાની ડોમેન લાઇન હોય છે। રાઉટિંગ નક્કી કરતી લાઇન ડોમેન યાદી છે, નામસર્વરનું સરનામું નહીં, કારણ કે સ્થાનિક સ્ટબ દરેક પ્રશ્ન તે લિંકને મોકલે છે જે નામનો દાવો કરે છે। જવાબ વાંચતા પહેલાં તે દાવાઓ વાંચો, પછી નામ પૂછો અને કઈ લિંકે તે બનાવ્યું તે તપાસો। સાચી લિંકથી ખોટો જવાબ એ ખોટી લિંકથી સાચા જવાબ કરતાં જુદી સમસ્યા છે।
દરેક લિંક-બ્લોક તમને શું કહે છે
દરેક બ્લોક તે સર્વરની યાદી આપે છે જે રિઝોલ્વર તે ઇન્ટરફેસ માટે વાપરશે, ડોમેન યાદી અને લિંક ડિફોલ્ટ રૂટ છે કે નહીં। ડોમેન યાદી દાવાઓનો સમૂહ છે અને રિઝોલ્વર સૌથી લાંબા પ્રત્યયની મેળ લગાવે છે: host.corp.example માટેનો પ્રશ્ન corp.example ધરાવતી લિંક દાવો કરે છે, ફક્ત ડિફોલ્ટ રૂટ ધરાવતી લિંક પહેલાં। એક જ પ્રત્યયનો દાવો કરતી બે લિંક પરિણામને પ્રાથમિકતા અને ક્રમ પર છોડી દે છે, તેથી નકલો પહેલાં ધ્યાન માગે છે। વર્તમાન સર્વર લાઇન બતાવે છે કે યાદીમાંનું કયું સર્વર તે ક્ષણે વપરાય છે।
/etc/resolv.conf માં 127.0.0.53 જેવું સ્ટબ સરનામું ફક્ત એટલું કહે છે કે સ્ટબ આગળ છે। તે જવાબ આપનાર ઉપરના પ્રવાહનું નામ લેતું નથી, તેથી ફક્ત resolv.conf પર આધારિત નિદાન અટકી જાય છે।
ત્રણ પ્રકારની ડોમેન એન્ટ્રી યોગ્ય રીતે વાંચો
| એન્ટ્રી | શું દાવો કરે છે | સામાન્ય ભૂલ |
|---|---|---|
| corp.example | રાઉટિંગ ડોમેન અને શોધ પ્રત્યય: તેની નીચેનાં નામ આ લિંક પર જાય છે, અને શબ્દમાળા નગ્ન નામોમાં ઉમેરાય છે | દૂર કરવામાં આવી કારણ કે રાઉટિંગ તેમ છતાં કામ કરતું લાગે છે |
| ~corp.example | ફક્ત રૂટ: તેની નીચેનાં નામ આ લિંક પર જાય છે, પણ પ્રત્યય ઉમેરાતો નથી | રાઉટિંગ માટે જરૂરી માનવામાં આવ્યું |
| ~. | ~. | વિભાજિત પ્રોફાઇલ પર સક્રિય રાખવામાં આવી, તેથી જાહેર નામો ટનલને અનુસરે છે |
ટિલ્ડા શોધનું વર્તન બદલે છે, રાઉટિંગ નહીં। ટિલ્ડા વગરની એન્ટ્રી રાઉટિંગ ડોમેન અને શોધ ડોમેન બંને છે, તેથી તેની નીચેનાં નામ તે લિંક પર મોકલાય છે અને એક-લેબલ નામોમાં પ્રત્યય ઉમેરાય છે। ટિલ્ડા એન્ટ્રી એ જ પ્રત્યયને રાઉટ કરે છે પણ તેને શોધ યાદીની બહાર રાખે છે। તેથી ટિલ્ડા દૂર કરવાથી કયાં નગ્ન નામો ઉકેલાય છે તે બદલાય છે, અને તેથી ખૂટતો ટિલ્ડા શોધની સમસ્યા છે, વિભાજિત DNS ની નિષ્ફળતા નહીં।
ડિફોલ્ટ રૂટ એન્ટ્રી એ બધાનો દાવો કરે છે જેને બીજી કોઈ લિંક મેળ ખાતી નથી। પૂર્ણ-ટનલ પ્રોફાઇલ સામાન્ય રીતે તે ઇચ્છે છે અને વિભાજિત પ્રોફાઇલ સામાન્ય રીતે નહીં, કારણ કે પછી જાહેર નામો ખાનગી રિઝોલ્વર પર જાય છે અને ત્યાં નિષ્ફળ થઈ શકે છે। પ્રોફાઇલ વચ્ચે ફ્લેગની નકલ કરવાને બદલે પ્રોફાઇલના ઇરાદા સામે કોષ્ટક વાંચો। જ્યારે બે લિંક એક જ પ્રત્યયનો દાવો કરે, ત્યારે બીજું કંઈ પણ સંપાદિત કરતા પહેલાં પ્રાથમિકતાનો પ્રશ્ન નક્કી કરો।
નામ પૂછો અને જુઓ કઈ લિંકે જવાબ આપ્યો
query ઉપ-આદેશ સરનામું, પ્રોટોકોલ અને જે લિંક અથવા વ્યાપે જવાબ બનાવ્યો તે છાપે છે। ખાનગી પ્રત્યયે દાવો કરવો જોઈએ એવું એક નામ અને એક સામાન્ય જાહેર નામ ચકાસો, પછી જણાવેલા સ્રોતોની તુલના કરો। જો ખાનગી નામ વાયરલેસ લિંકથી જવાબ આપે, તો દાવો ખૂટે છે અથવા ટનલ બંધ છે; જો વિભાજિત પ્રોફાઇલમાં જાહેર નામ ટનલથી જવાબ આપે, તો ડિફોલ્ટ રૂટ ખૂબ પહોળો છે। આ બંને નિષ્ફળતા બ્રાઉઝરમાં સરખી અને આ આઉટપુટમાં વિરુદ્ધ દેખાય છે।
resolvectl status
resolvectl query host.corp.exampleજણાવેલા પ્રોટોકોલ પર પણ ધ્યાન આપો, કારણ કે કેશ અથવા હોસ્ટ-ફાઇલમાંથી જવાબ કોઈ પણ ઉપરના પ્રવાહને પૂછ્યા વગર આવી શકે છે। કેશનો જવાબ સાબિત કરે છે કે નામ ક્યારેક ઉકેલાયું હતું, એ નહીં કે વર્તમાન નીતિ તેને યોગ્ય રીતે રાઉટ કરે છે।
નામ રાઉટિંગને પેકેટ રાઉટિંગથી અલગ રાખો
રિઝોલ્વરનો નિર્ણય માર્ગ બનાવતો નથી। પસંદ કરેલા સર્વરને હજી પોતાના સરનામા સુધીનો રૂટ જોઈએ છે, અને પરત મળેલા સરનામાને હજી ખાનગી નેટવર્કમાં રૂટ જોઈએ છે, તેથી સાચી DNS નીતિ એવા જોડાણ સાથે સહઅસ્તિત્વ ધરાવી શકે છે જે કદી ખૂલતું નથી। જ્યારે નામ ઉકેલાય અને એપ્લિકેશન નિષ્ફળ જાય, ત્યારે ફરી DNS બદલવાને બદલે સરનામું અને રૂટ તપાસો। નામ ઉકેલવું અને પહોંચ તે બે જુદા માલિકોવાળા બે પ્રશ્નો છે।
એપ્લિકેશનો પોતાના સુરક્ષિત DNS સેટિંગ અથવા બંડલ કરેલા રિઝોલ્વર દ્વારા સિસ્ટમ રિઝોલ્વરને સંપૂર્ણપણે ટાળી શકે છે। resolvectl પરિણામ સિસ્ટમ માર્ગનું વર્ણન કરે છે, અને તેને અવગણતું બ્રાઉઝર તમે કરો તે દરેક પરીક્ષણ સાથે અસંમત થશે। નીતિ તૂટેલી છે એવું નિષ્કર્ષ કાઢતા પહેલાં તે સેટિંગ તપાસો।
જે સરનામા પર નામ ઉકેલાયું તે લિંકની બાજુમાં નોંધો। ખોટા સરનામે નિર્દેશ કરતું સાચું નામ રાઉટિંગ નહીં, રેકોર્ડની સમસ્યા છે।
લિંક બદલાયા પછી ફરી તપાસો
ફરી જોડાણ અથવા વાયરલેસ બદલાવ લિંકની સ્થિતિ ફરી બાંધે છે, અને નેટવર્ક મેનેજર હાથે સેટ કરેલા બધા ઉપર પોતાનાં ડોમેન અને સર્વર ફરી મૂકી શકે છે। પછી એ જ બે નામ પૂછો અને નોંધેલી આધારરેખા સાથે તુલના કરો। જો હાથનું સંપાદન અદૃશ્ય થયું હોય, સુધારો કનેક્શન પ્રોફાઇલમાં હોવો જોઈએ શેલ આદેશમાં નહીં। પહેલાં અને પછી નોંધવું એ જ તેને દૃશ્ય બનાવે છે।
અહેવાલને જે નામ અને સર્વર સંદર્ભ જોઈએ તે જ શેર કરો, કારણ કે આંતરિક પ્રત્યય ટોપોલોજી જાહેર કરે છે। systemd-resolved નું ડોમેન રાઉટિંગ દસ્તાવેજીકરણ સૌથી લાંબી મેળનો નિયમ અને ટિલ્ડાનું વર્તન આવરે છે, અને એક વાર વાંચવાથી ઉપરના કોષ્ટકની મોટાભાગની ભૂલો અટકે છે: systemd-resolved પ્રશ્ન રાઉટિંગ।