લેપટોપ જાગ્યા પછી OpenVPN કેમ મરી જાય છે?

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

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

સ્વયંસંચાલિત કરતાં પહેલાં જાગવાની પ્રક્રિયા પુનઃઉત્પાદિત કરો

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

જો ક્લાયન્ટ જાતે જ પાછો આવે, તો હૂક વિશ્વસનીયતાને બદલે વધારાની ગૂંચ ઉમેરે છે. જો તે ક્યારેય સાજું ન થાય, તો સ્વયંસંચાલન જ પ્રામાણિક ઉપાય છે.

systemd સ્લીપ હૂક ખરેખર ક્યાં રહે છે

ઘણા જૂના માર્ગદર્શિકાઓ /etc/pm/sleep.d તરફ ઇશારો કરે છે, જે pm-utils ની માલિકીની ડિરેક્ટરી છે અને systemd આધારિત સ્લીપ ક્યારેય તેની સલાહ લેતું નથી. systemd /usr/lib/systemd/system-sleep/ અને /etc/systemd/system-sleep/ માંથી હૂક વાંચે છે, પહેલા તબક્કો અને પછી ક્રિયા આપે છે, તેથી pre અને post એ જ મૂલ્યો છે જેના પર હૂક શાખા પાડે છે. પેકેજ કરેલી ફાઇલ સંપાદિત કરવાને બદલે સ્થાનિક નકલ /etc હેઠળ રાખો, અને યાદ રાખો કે સ્ક્રિપ્ટ સંક્રમણની વચ્ચે root તરીકે ચાલે છે, તેથી તેણે ઝડપથી પાછું ફરવું પડે.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

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

સેવા પુનઃપ્રાપ્ત કરો, tun0 ને એકલું છોડો

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

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

જે સમય તમે નિયંત્રિત કરી શકતા નથી તે સંભાળો

વાયરલેસ સંગઠન અને DHCP ઘણી વખત હૂક ચાલ્યા પછી પૂર્ણ થાય છે, તેથી સર્વર તરફ કોઈ માર્ગ હજી ન હોય ત્યારે ફરી શરૂ કરવું નિષ્ફળ જઈ શકે. તે સરનામા માટે થોડી વાર રાહ જુઓ, એક વાર ફરી પ્રયાસ કરો અને પરિણામ લોગ કરો.

નામ નિરાકરણ એ અલગ સ્પર્ધા છે, કારણ કે ડેસ્કટોપ નેટવર્ક સ્ટેક ટનલ ઉપર આવ્યા પછી પણ DNS પુનઃસ્થાપિત કરી શકે છે. કાર્યરત માર્ગ પરથી અનુમાન કરવાને બદલે resolvectl query internal.example સાથે લુકઅપ અલગથી ચકાસો. જે ટનલ યોગ્ય રીતે રૂટ કરે છે અને કંઈ જ ઉકેલતી નથી તે DNS સમસ્યા છે, હૂકની સમસ્યા નહીં.

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