SIGKILL પછી OpenVPN DNS બાકી રહે છે: પહેલા માલિક તપાસો

OpenVPN ક્લાયન્ટ માર્યા પછી DNS ઉકેલવાનું બંધ કરે છે, અને પહેલી વૃત્તિ /etc/resolv.conf ફરીથી લખવાની હોય છે. એ ફેરફાર ચાલતું રિઝોલ્વર તોડી શકે છે જ્યારે અસલ જૂની સ્થિતિ બીજે ક્યાંક હોય છે. પહેલા ઉકેલવાનો પ્રશ્ન એ છે કે ટનલે સ્થાપિત કરેલી DNS સેટિંગ્સનો માલિક કોણ છે, અને સફાઈ છોડી દેનારું બહાર જવું ખરેખર મહત્ત્વનું હતું કે નહીં.

ત્રણ શરતો સમારકામ નક્કી કરે છે: પ્રક્રિયા સમાપ્ત કરનાર સિગ્નલ, સેટિંગ્સ મેળવનાર રિઝોલ્વર ઘટક, અને ટનલ લિંક હજી છે કે નહીં. આ ક્રમમાં જવાબ આપો અને સુધારો સામાન્ય રીતે કોઈ વૈશ્વિક ફાઇલને અડ્યા વિના આવે છે.

કઈ પ્રકારનું બહાર જવું થયું તે નક્કી કરો

Community આવૃત્તિમાં OpenVPN માં SIGINT અને SIGTERM બંને શાંત બહાર જવાની વિનંતીઓ છે. SIGKILL પકડી શકાતું નથી: તેને અવરોધી કે હેન્ડલ કરી શકાતું નથી, તેથી કોઈ શટડાઉન રૂટિનને ચાલવાની તક મળતી નથી. આગળના ટર્મિનલમાં સામાન્ય Ctrl+C SIGINT પેદા કરે છે, જ્યારે રાહ જોવાનું છોડી દેનાર સુપરવાઈઝર સામાન્ય રીતે SIGKILL સુધી વધે છે. ફરક મહત્ત્વનો છે કારણ કે ફક્ત બીજો કિસ્સો જ હૂક્સ છોડી દેવાયા હોવાની ખાતરી આપે છે.

screen કે tmux ની અંદર ચલાવવાથી Ctrl+C કયું સિગ્નલ મોકલે છે તે બદલાતું નથી. ટર્મિનલ સામાન્ય રીતે શું કરે છે તેના બદલે પ્રક્રિયાએ ખરેખર શું મેળવ્યું તે તપાસો.

જ્યારે કોઈ સેવા કે કનેક્શન મેનેજર ટનલ ચલાવે છે, ત્યારે pid મારવાને બદલે તે એક કનેક્શનને તેના માલિક દ્વારા રોકો. મેનેજર પ્રક્રિયાને ફરી ઉપર લાવી શકે છે, જેથી તમારી પાસે નવી ટનલ અને ગૂંચવણભરી રિઝોલ્વર સ્થિતિ રહે. સ્વતંત્ર પ્રક્રિયાને સફાઈ ચાલવા માટે ફક્ત સામાન્ય સમાપ્તિ વિનંતીની જરૂર છે.

રિઝોલ્વરનો માલિક કોણ છે તે નક્કી કરો

systemd-resolved, resolvconf શૈલીની સ્ક્રિપ્ટ અને સાદું ફાઇલ પુનર્લેખન એ ત્રણ અલગ માલિકો છે. પહેલું દરેક લિંકની સેટિંગ્સ મેમરીમાં રાખે છે અને ઇન્ટરફેસ અદૃશ્ય થાય ત્યારે તેમને કાઢી નાખે છે. બીજું એવા રેકોર્ડ રાખે છે જે કંઈક દૂર કરે ત્યાં સુધી ટકે છે. ત્રીજું ફાઇલ લખે છે અને પુનઃસ્થાપન તેને જે લખ્યું તેના પર છોડી દે છે.

સમારકામનો આદેશ પસંદ કરતા પહેલા માલિક ઓળખો. એ જ લક્ષણના કયો વપરાય છે તેના આધારે ત્રણ અલગ સાચા જવાબો છે.

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

down હૂક શું કરી શકે છે અને શું નહીં

સ્ક્રિપ્ટ down TUN/TAP ઉપકરણ બંધ થયા પછી એક વાર ચાલે છે. ઉમેરવાથી down-pre એ ક્રમ ઉલટાવે છે અને ઉપકરણ હજી હાજર હોય ત્યારે સ્ક્રિપ્ટ ચલાવે છે, જે જીવંત લિંકની જરૂર હોય તેવા સહાયકો માટે જરૂરી છે.

બંનેમાંથી કોઈ નિર્દેશ હૂકને SIGKILL પછી ચલાવતું નથી. અધિકારો પણ down-pre દ્વારા પુનઃસ્થાપિત થતા નથી: જો ડિમન user કે group પર ઉતરે અથવા chroot માં પ્રવેશે, તો હૂક તે જે પ્રવેશ છોડે તેની સાથે ચાલે છે. બોલાવવામાં આવેલ હૂક હજી પણ રિઝોલ્વર અપડેટ કરવામાં નિષ્ફળ જઈ શકે છે. OpenVPN સંદર્ભ સિગ્નલો અને કૉલબેક જીવનચક્રને આવરી લે છે.

પ્રક્રિયાની એક્ઝિટ સ્થિતિની બાજુમાં હૂકની પોતાની ભૂલ તપાસો. ખૂટતી સફાઈ અને નિષ્ફળ સફાઈ રિઝોલ્વરમાં સરખી અને લોગમાં અલગ દેખાય છે.

ખરેખર બાકી રહેતી સ્થિતિ તપાસો

systemd-resolved વાપરતી સિસ્ટમ પર, resolvectl status બતાવે છે કે કઈ લિંક હજી VPN ના DNS સર્વરો કે રાઉટિંગ ડોમેન ધરાવે છે. એ લિંક ગયેલા કનેક્શનની હોઈ શકે છે, અથવા હજી ઉપર રહેલી બીજી ટનલની.

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

બીજી લિંક ચોર્યા વિના પુનઃપ્રાપ્ત કરો

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

સંપાદન પહેલાં ખાતરી કરો કે /etc/resolv.conf સંચાલિત સિમ્બોલિક લિંક છે, પછી ક્લાયન્ટને વધુ એક વાર સામાન્ય રીતે રોકો અને ફરી DNS જુઓ. જો બીજા રોકવાથી સાફ થાય, તો અગાઉની સમસ્યા રૂપરેખા નહીં પણ ફરજિયાત બહાર જવું હતું.