Debian resolvconf રેકોર્ડ ક્રમ: VPN રેકોર્ડને પહેલો મૂકો
VPN નું નામસર્વર વારંવાર LAN ના નામસર્વર નીચે જાય છે કારણ કે resolvconf રેકોર્ડના નામ સૉર્ટ કરે છે. interface-order સંપાદિત કરો, ફરી બનાવો અને બે લુકઅપ ચકાસો.
VPN નું નામસર્વર વારંવાર LAN ના નામસર્વર નીચે પડે છે, અને /etc/resolv.conf સંપાદિત કરવાથી તે થોડી મિનિટો માટે સુધરે છે. એ ફાઇલ બનાવવામાં આવે છે, તેથી સુધારો કદી ટકતો નથી. Debian ના resolvconf માં ક્રમનું ઇનપુટ /etc/resolvconf/interface-order છે, અને તે DNS સરનામાં નહીં પણ રેકોર્ડના નામ સૉર્ટ કરે છે. બંનેમાંથી કોઈપણ ફાઇલને અડકતા પહેલાં ખાતરી કરો કે કયો resolver સ્ટેક ખરેખર જવાબદાર છે.
ખાતરી કરો કે આઉટપુટ resolvconf નું છે
વર્તમાન ફાઇલ કોણે લખી અને ફરી કોણ લખશે તે પૂછીને શરૂ કરો. resolvconf પેકેજ પોતાને ડાયનેમિક resolver રૂપરેખાંકન માટેના ફ્રેમવર્ક તરીકે વર્ણવે છે, અને systemd-resolved અથવા NetworkManager દ્વારા સંચાલિત resolver ચલાવતું હોસ્ટ બહારથી સરખું દેખાઈ શકે છે, જ્યારે તે સાવ અલગ નીતિ વાપરતું હોય.
readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1
જો ઉકેલાયેલો માર્ગ resolvconf ની રનટાઇમ ડિરેક્ટરીમાં ન જાય, તો અહીં જ અટકો: આ રનબુક બીજા સ્ટેકની છે.
એ ચકાસણી પછી જ resolvconf હાલમાં જે રેકોર્ડ રાખે છે તેની યાદી કરવી યોગ્ય છે.
પેટર્ન લખતા પહેલાં રેકોર્ડ વાંચો
interface-order સપ્લાયર રેકોર્ડના નામ સાથે મેળ ખાય છે, સરનામાં કે કર્નલ ઇન્ટરફેસના નામ સાથે નહીં. શું નોંધાયેલું છે તેની યાદી કરો જેથી તમારી પેટર્ન હાલની એન્ટ્રીનો ઉલ્લેખ કરે.
ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order
રેકોર્ડના નામમાં સામાન્ય રીતે પ્રત્યય હોય છે જે તેના સપ્લાયરને ઓળખાવે છે, તેથી ટનલ રેકોર્ડ અને DHCP રેકોર્ડ એક જ ઇન્ટરફેસ ઉપસર્ગ વહેંચી શકે છે અને તેમ છતાં અલગ રીતે સૉર્ટ થઈ શકે છે. ડિરેક્ટરીની યાદીમાંથી ચોક્કસ નામ કૉપિ કરો. ઇન્ટરફેસના નામ પરથી નામ અનુમાન કરશો નહીં, કારણ કે ક્લાયન્ટ ઇન્ટિગ્રેશન જ નક્કી કરે છે કે શું નોંધવું છે. તમે ઊપજાવેલું નામ કદી મેળ ન ખાય, અને રેકોર્ડ કોઈપણ ભૂલસંદેશ વગર બધું પકડતી પેટર્નમાં પડી જશે.
ક્રમને પ્રથમ-મેળ પેટર્ન તરીકે લખો
ફાઇલ shell glob પેટર્નની યાદી છે, દરેક લાઇને એક. રેકોર્ડ તે પહેલી પેટર્નનું સ્થાન લે છે જેની સાથે તે મેળ ખાય છે, તેથી ચોક્કસ પેટર્ન ઉપર પહોળી પેટર્ન હોય તો ચોક્કસ લાઇન પહોંચવી અશક્ય બને છે.
# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*
ચોક્કસ ટનલ પેટર્નને બધું પકડતી પેટર્ન ઉપર અને ફિઝિકલ ઇન્ટરફેસ પેટર્ન ઉપર મૂકો.
ફાઇલમાં પહેલેથી હતી તે બીજી લાઇન રાખો. આખી નીતિને ઉદાહરણથી બદલવી એ જ રીત છે જેમાં અસંબંધિત સપ્લાયર ચૂપચાપ ખસી જાય છે; એક લાઇન બદલો, ફરી બનાવો અને સરખાવો. પેટર્નમાં ખાલી જગ્યા, સ્લેશ કે શરૂઆતમાં બિંદુ કે ટિલ્ડે હોઈ શકે નહીં, અને ખાલી લાઇન તથા હેશ ટિપ્પણી અવગણવામાં આવે છે.
ફરી બનાવો અને પરિણામ ચકાસો
અપડેટ સ્ક્રિપ્ટ ફાઇલ ફરી બનાવે ત્યારે ક્રમ લાગુ થાય છે. બનાવેલા આઉટપુટને સંપાદિત કરવાને બદલે સમર્થિત અપડેટ માર્ગ ચલાવો, પછી resolver ને ખરેખર શું મળ્યું તે વાંચો.
resolvconf -u
cat /etc/resolv.conf
એક નહીં, બે લુકઅપ ચકાસો: એક ખાનગી નામ જે ટનલ દ્વારા ઉકેલાવું જોઈએ, અને એક જાહેર નિયંત્રણ નામ. જો ક્રમ સાચો દેખાતો હોવા છતાં ખાનગી નામ હજી નિષ્ફળ જાય, તો સમસ્યા રેકોર્ડ અગ્રતા નહીં પણ નામસ્પેસ રાઉટિંગ છે, અને કોઈ પણ પુનર્ગઠન તેને સુધારશે નહીં. દરેક જવાબને ફક્ત સફળતા સાથે નહીં, પણ તે પરત આપનાર સર્વર સાથે સરખાવો. ખોટા resolver દ્વારા આપેલો ખાનગી નામનો જવાબ પણ નિષ્ફળતા છે, અને વપરાશકર્તાને તે DNS વિક્ષેપ જેવું લાગે છે.
જૂનું રેકોર્ડ નીચું કરવાને બદલે તેને નિવૃત્ત કરો
ડિસ્કનેક્ટ થયા પછી ફરી દેખાતું જૂનું VPN રેકોર્ડ ક્લાયન્ટ ઇન્ટિગ્રેશનમાં જીવનચક્રની ભૂલ છે. તેને તળિયે ખસેડવાથી લક્ષણ છુપાય છે અને યાદીમાં મૃત resolver રહી જાય છે.
જે ઘટક તેને નોંધે છે તેના દ્વારા તેને નિવૃત્ત કરો, પછી ખાતરી કરો કે રેકોર્ડ ડિરેક્ટરી હવે તેની યાદી કરતી નથી.
સપ્લાયરનું નામ, તમે બદલેલી પેટર્ન અને તમે ચલાવેલા બે લુકઅપ નોંધો. આગલી વ્યક્તિને વાર્તા કરતાં એ નામોની વધુ જરૂર છે.