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

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

ત્રણ જુદા ટ્રિગર સાથે ત્રણ સ્ટાર્ટર

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

StarterWhat triggers itTypical failure
Init script and templated unitsBoot, plus anything in the autostart listStarts every config, not the one you meant
NetworkManager secondaryActivation of the base Wi-Fi or Ethernet profileNothing happens until that base link comes up
Hand-written unit or wrapperWhatever its WantedBy and ExecStart sayRuns a different binary or environment than your shell

બીજી પંક્તિ એ છે જે લોકો ખોટી રીતે ગોઠવે છે. NetworkManager આયાત કરેલી પ્રોફાઇલ રાખે છે અને તેને શરૂ કરશે, પણ ફક્ત બીજા કનેક્શનના સેકન્ડરી તરીકે, એટલે કે ટ્રિગર VPNનું નહીં, નેટવર્ક લિંકનું છે.

સેટઅપ ખર્ચ અને વ્યાપની સરખામણી કરો

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

હાથે લખેલું unit સૌથી વધુ ખર્ચ કરે છે અને સૌથી વધુ નિયંત્રણ આપે છે, જેમાં બીજી સેવાઓ સામેનો ક્રમ પણ સામેલ છે. વ્યાપ નિર્ણાયક પરિબળ છે. જો મશીનમાં એક નેટવર્ક અને એક ટનલ હોય, તો પેકેજ થયેલી સેવા પ્રામાણિક અને અનુમાનક્ષમ છે. જો ટનલે ચોક્કસ Wi-Fi નેટવર્કને અનુસરવું હોય, તો સેકન્ડરી ત્રણમાંથી એકમાત્ર છે જે વધારાની સ્ક્રિપ્ટિંગ વિના એ શરત વ્યક્ત કરે છે.

એક માલિક પસંદ કરો અને બાકીના દૂર કરો

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

# who is configured to start something?
grep -v '^#' /etc/default/openvpn
systemctl list-units 'openvpn*'
nmcli -g connection.secondaries connection show 'Work Wi-Fi'

# NetworkManager: attach the tunnel to the base link by UUID
TUNNEL=$(nmcli -g UUID connection show 'Corp Tunnel')
nmcli connection modify 'Work Wi-Fi' +connection.secondaries "$TUNNEL"

જો પેકેજ થયેલો રસ્તો જ નિવૃત્ત કરવો હોય, તો યોગ્ય ક્રમમાં કરો: AUTOSTART ને none પર ગોઠવો, જનરેટ થયેલા unit નવી યાદી લે તે માટે systemctl daemon-reload ચલાવો, પછી જે ટેમ્પલેટ ઇન્સ્ટન્સ હવે નથી જોઈતું તે બંધ કરો. રીલોડ છોડી દેવાથી જૂના unit સક્રિય રહે છે, જે એવું લાગે કે ફેરફારની કોઈ અસર ન થઈ.

અટકી જતું સ્ટોપ અલગ સમસ્યા છે જેનો જવાબ મર્યાદિત છે. TimeoutStopSec મર્યાદિત કરે છે કે SIGKILL મોકલતાં પહેલાં systemd કેટલો સમય રાહ જુએ. drop-in ફાઇલ તેને સેટ કરવાની યોગ્ય જગ્યા છે, કારણ કે પેકેજ થયેલું unit સંપાદિત કરવાથી આગલા અપગ્રેડમાં ફેરફાર ગુમાવાય છે.

ખરેખર શું શરૂ થયું તે ચકાસો

રીબૂટ કરો અને કોન્ફિગરેશન ફાઇલ પર ભરોસો કરવાને બદલે પુરાવા વાંચો. ટનલનું માલિક એવું unit સક્રિય સ્થિતિ અને બૂટ સાથે મેળ ખાતો શરૂ થવાનો સમય દર્શાવશે, અને તમે લોગિન કરો તે પહેલાં VPN ઇન્ટરફેસ હાજર હશે.

systemctl is-enabled openvpn-client@office
systemctl status openvpn-client@office --no-pager
nmcli -f GENERAL.STATE,connection.secondaries connection show 'Work Wi-Fi'
ip -brief link show tun0

અહીં એક વધુ તપાસ આવે છે: unitનું ExecStart તમે ધારો છો તે જ બાઇનરી તરફ નિર્દેશ કરે છે તેની ખાતરી કરો. સ્થાનિક રીતે કમ્પાઇલ કરેલા ક્લાયન્ટ અથવા snap પેકેજને ઘણી વાર સ્પષ્ટ પાથ કે snap run રેપરની જરૂર પડે છે, કારણ કે systemd તમારા શેલનો શોધ ક્રમ વારસામાં લેતું નથી. command -v openvpn ને unit ફાઇલ સાથે સરખાવવાથી તે સેકન્ડોમાં નક્કી થાય છે.

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

સંબંધિત લેખો