VPN કહે છે કે જોડાયેલું છે, પણ ડિફૉલ્ટ રૂટ મૃત છે

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

જૂના ટુકડા તમે ધ્યાન આપ્યું તે પહેલાં જ ખોટા હતા. કેબલ ખેંચી કાઢવાથી ફક્ત તે દેખાયા.

કર્નલને પૂછો પેકેટ ક્યાં જશે

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

લુકઅપ બે વાર ચલાવો, એક વાર જાહેર સરનામા માટે અને એક વાર આંતરિક સરનામા માટે, કારણ કે સ્પ્લિટ-ટનલ નીતિ એકને પ્રામાણિકપણે રૂટ કરી શકે છે અને બીજાને પડતું મૂકી શકે છે.

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

રિઝોલ્વર પણ મૃત લિંક રાખે છે

systemd-resolved ધરાવતા હોસ્ટ પર, DNS સર્વર લિંક સાથે જોડાયેલા હોય છે, એક વૈશ્વિક યાદી સાથે નહીં. નીચે પડેલી VPN લિંક થોડા સમય માટે તેના સર્વર સાથે નોંધાયેલી રહી શકે છે, અને પછી દરેક લુકઅપ એવા સરનામા પર રાહ જુએ છે જે કદી જવાબ આપશે નહીં. એ વિલંબ મૃત નેટવર્ક જેવો લાગે છે અને લોકોને રૂટ તરફ જોવા મોકલે છે જ્યારે રૂટ ઠીક છે.

resolvectl status
resolvectl query intranet.example.com

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

રજિસ્ટ્રેશન સુધારો, નહીં કે /etc/resolv.conf. હાલની Ubuntu અને Fedora ઇન્સ્ટોલેશનમાં એ પથ રિઝોલ્વરની રનટાઇમ સ્થિતિની સિમ્બોલિક લિંક છે, તેથી સંપાદન કાં તો અવગણાય છે કાં તો આગલી નેટવર્ક ઘટનામાં ફરી લખાય છે.

VPN કદી જાતે શરૂ થતું નથી

NetworkManager બેઝ કનેક્શનની ઉપર VPN ઉઠાવે છે, અને કયા પાછળ જવું તે શીખે છે connection.secondaries તે બેઝ પર. કનેક્શન સેટિંગ્સ સંદર્ભ સ્પષ્ટ કહે છે કે VPN પ્રોફાઇલ માટે ઑટોકનેક્ટ લાગુ કરાયેલ નથી. આ આખી કાર્યવિધિ આ પ્રકારની નિષ્ફળતા પાછળ છે: બેઝ બદલો, અને VPN ને ફરી જોડવું પડે અથવા હાથે ફરી સક્રિય કરવું પડે.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

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

અપગ્રેડ સંદેશ વગર સેટિંગ્સ પડતી મૂકી શકે છે

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

હાથે લખેલા હૂક પણ ખસે છે. જૂના ક્રમમાં અનુમાનિત ક્ષણે રૂટ ઇન્સ્ટોલ કરતી સ્ક્રિપ્ટ હવે ઇન્ટરફેસ બન્યા પહેલા ચાલી શકે છે, અથવા ક્લાયન્ટનો સમય પૂરો થયા પછી.

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

ત્રણ સ્થિતિ, ત્રણ અલગ સુધારા

કંઈપણ અડકતા પહેલા નક્કી કરો કે તમે કઈ સ્થિતિમાં છો, કારણ કે રીબૂટ પુરાવા નષ્ટ કરે છે અને આગલા નેટવર્ક ફેરફારમાં ખામી પાછી આવે છે.

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