તમારો OpenVPN ક્લાયંટ એક ટાઇમઆઉટ પછી કેમ બંધ રહે છે

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

યુનિટે ખરેખર શું કર્યું તેનાથી શરૂ કરો, મોનિટરિંગ જે દાવો કરે છે તેનાથી નહીં. systemctl status openvpn-client@office અને journalctl -u openvpn-client@office -n 50 બહાર નીકળવાનું કારણ અને ક્લાયંટ જતાં પહેલાં લખેલી છેલ્લી લાઇન બતાવે છે.

કોઈએ ધ્યાન આપે તે પહેલાં પ્રક્રિયા બહાર નીકળી ગઈ

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

બે ping નિર્દેશ એક જ પ્રોફાઇલમાં સાથે રહી શકતા નથી, તેથી એક પસંદ કરો અને પસંદગી નોંધો. સર્વર પણ જુઓ, કારણ કે તેનું પોતાનું ping-exit ક્લાયંટે શું માંગ્યું તે ધ્યાનમાં લીધા વિના સેશન બંધ કરે છે, અને કોણે એ નિર્ણય લીધો તે ફક્ત સર્વર લોગમાં લખાય છે.

ping-exit અને ping-restart વચ્ચે પસંદગી

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

પછી ખાતરી કરો કે ખરેખર પ્રક્રિયા જ બહાર નીકળી છે. ટનલ મૃત હોય ત્યારે સક્રિય હોવાનું જણાવતું યુનિટ બીજી નિષ્ફળતા છે, જે નીચે ચર્ચાઈ છે.

એવી દેખરેખ જે યુનિટને ખરેખર ફરી શરૂ કરે

systemd હોસ્ટ પર સૌથી નાનો ટકાઉ ફેરફાર એક drop-in ફાઇલ છે: Restart=on-failure અને RestartSec=10, જે /etc/systemd/system/[email protected]/restart.conf ફાઇલમાં છે. drop-in ફક્ત ત્યારે વંચાય છે જ્યારે systemd પોતાની વ્યાખ્યાઓ ફરી લોડ કરે, તેથી પછી systemctl daemon-reload ચલાવો. મૂલ્ય પહોંચ્યું છે એમ ધારવાને બદલે systemctl show -p Restart -p ExecMainStatus openvpn-client@office વડે ચકાસો. ફાઇલના નામમાંનું ઇન્સ્ટન્સ એ જ પ્રોફાઇલ હોવું જોઈએ જે યુનિટ ખરેખર લોડ કરે છે, તેથી office માટે લખેલી ફાઇલ openvpn-client@home માટે કંઈ કરતી નથી.

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

Restart=always જાણી જોઈને થોભાવ્યા પછી પણ સક્રિય થાય છે. જાળવણી માટે systemctl stop વાપરો, અને જો તમે કામ કરો ત્યારે યુનિટ બંધ રહેવું હોય તો તેને માસ્ક કરો.

ટનલ બંધ હોય ત્યારે લીક પકડો

દેખરેખ ટનલને પાછી લાવે છે; ટનલ ગેરહાજર હોય ત્યારે ટ્રાફિક બહાર જવાથી તે અટકાવતી નથી. persist-tun ફરી જોડાણો વચ્ચે ઉપકરણ અને તેના રૂટ રાખે છે, જે અનુકૂળ છે અને એક બારી ખોલે છે. ઉપકરણ ટકી રહે છે, રૂટ હજી તેના તરફ જ છે, અને પેકેટ અસુરક્ષિત અને અજાણ રીતે બહાર વહે છે. આ નીતિનો નિર્ણય છે, તટસ્થ ડિફોલ્ટ નહીં.

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

ક્લાયંટને જાણી જોઈને થોભાવીને તેને ચકાસો. systemctl stop openvpn-client@office ચલાવો, પછી curl -m 5 https://example.com, જે ભૌતિક લિંક પર સફળ થવાને બદલે નિષ્ફળ થવું જોઈએ. સફળતાનો અર્થ એ છે કે ફાયરવોલ નિયમ ખૂટે છે અથવા વધુ પડતો પરવાનગીપ્રદ છે.

ફરી જોડાઓ, ટનલ ફરી ટ્રાફિક વહન કરે છે તેની ખાતરી કરો, અને પછી જ મોનિટરિંગમાં ચેક ઉમેરો. cron થી ip addr વડે tun ઉપકરણ માટે પૂછપરછ કરવી સૌથી વધુ નિષ્ફળ થતી દેખરેખ છે, કારણ કે persist-tun સાથે ઉપકરણ સેશન કરતાં વધુ ટકે છે અને કંઈ વહન ન થતું હોય ત્યારે પણ પ્રોબ સ્વાસ્થ્ય જણાવે છે.