VPN યુનિટ નેટવર્ક પહેલાં કેમ શરૂ થાય છે અને પછી મરી જાય છે

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

લક્ષ્ય મિલનસ્થળ છે, સંચાલક નહીં

network-online.target ને ખબર નથી કે નેટવર્ક શું છે. તે એક સંકલન બિંદુ છે જે એ સેવાને એકઠી કરે છે જે લિંક વપરાયોગ્ય થાય ત્યાં સુધી શરૂઆતમાં વિલંબ કરવાની હોય છે, અને તે વ્યાખ્યાને એ નેટવર્ક મેનેજરને સોંપે છે જે મશીનનો માલિક છે. મોટાભાગના ડેસ્કટોપ અને સર્વર પર તેનો અર્થ NetworkManager અથવા systemd-networkd દ્વારા પૂરી પાડવામાં આવતી રાહ-સેવા છે. બંનેમાંથી એક પણ સક્રિય ન કરો તો લક્ષ્ય પાસે રાહ જોવા માટે કંઈ રહેતું નથી, તેથી જે ક્ષણે કંઈ તેને ખેંચે તે ક્ષણે જ તે પૂર્ણ થાય છે, જે DHCP જવાબ આપે તે પહેલાં ઘણું વહેલું હોઈ શકે. તમારા યુનિટની ક્રમ-લાઇન પ્રામાણિક હતી અને તોપણ નકામી.

તેથી પહેલો પ્રશ્ન એ નથી કે તમારું યુનિટ શું ઘોષિત કરે છે. પ્રશ્ન એ છે કે આ મશીન પર ખરેખર કંઈક રાહ જોઈ રહ્યું છે કે નહીં.

યુનિટ ફાઇલને બદલે છેલ્લું બૂટ વાંચો

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

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

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

રાહ ઉમેરો, પછી ફરી પ્રયાસ

પેકેજ કરેલા યુનિટને સંપાદિત કરવાને બદલે ડ્રોપ-ઇન વાપરો, જેથી પેકેજ અપડેટ ફેરફારને શાંતિથી ફેંકી ન દે. બે નિર્દેશ મહત્ત્વના છે: યુનિટ લક્ષ્ય પછી ગોઠવાયેલું હોવું જોઈએ, અને તેણે લક્ષ્યને એ જ વ્યવહારમાં ખેંચવું જોઈએ. ફક્ત ક્રમ લક્ષ્યને બોલાવતો નથી; ઇચ્છા તે કરે છે.

OpenVPN ક્લાયન્ટનું પેકેજ કરેલું યુનિટ પહેલેથી બંને ધરાવે છે. હાથે લખેલા યુનિટ સામાન્ય રીતે એક અથવા કંઈ જ ધરાવતા નથી, જે કંઈ ઉમેરતા પહેલાં તપાસવા યોગ્ય છે.

[Service]
Restart=on-failure
RestartSec=15

શા માટે નિશ્ચિત ઊંઘ એ ફાંદો છે

ExecStartPre માં ઊંઘ ક્રમ-સુધારણા જેવી લાગે છે અને વધારાના પગલાં સાથેના વિલંબ જેવી વર્તે છે. તે દરેક બૂટને ધીમું કરે છે, જે સ્વસ્થ હતા તે પણ, અને તમે પસંદ કરેલી સંખ્યા કરતાં લિંક વધુ સમય લે ત્યારે તે તોપણ હારે છે.

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

જ્યારે ક્રમ સાચો હોય અને નામ તોપણ નિષ્ફળ જાય

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

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