OpenVPN up પર સેવા ફરી શરૂ કરવી: હૂક્સ tun0.device કરતાં ચડિયાતા

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

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

ડિવાઇસ યુનિટ ખરેખર શું ટ્રેક કરે છે

systemd નેટવર્ક ઇન્ટરફેસ વિશે કર્નલના દૃષ્ટિકોણથી ડિવાઇસ યુનિટ બનાવે છે, તેથી ઇન્ટરફેસ દેખાય ત્યારે tun0.device સક્રિય થાય છે અને દૂર થાય ત્યારે નિષ્ક્રિય થાય છે. persist-tun સાથે, નરમ રીસ્ટાર્ટ ઇન્ટરફેસને તેની જગ્યાએ રાખે છે, તેથી યુનિટ ક્યારેય ફ્લેપ થતું નથી અને તેની સાથે બંધાયેલું કંઈપણ ટ્રિગર થતું નથી. ટકાઉપણા વિના પણ, યુનિટ રૂટ, DNS અથવા દૂરનો છેડો જવાબ આપે છે કે નહીં તે વિશે કંઈ કહેતું નથી.

તે તેને 'VPN તૈયાર છે' માટે નબળો વિકલ્પ બનાવે છે. ફક્ત સ્થાનિક સરનામું જોઈતા શ્રોતાને ઇન્ટરફેસના અસ્તિત્વથી સંતોષ થઈ શકે છે, જ્યારે દૂરના નેટવર્ક પર એપ્લિકેશનને બોલાવતી સેવાને રૂટ અને પહોંચની જરૂર હોય છે, જે ડિવાઇસ યુનિટ વ્યક્ત કરી શકતું નથી.

up, route-up અને up-restart જુદા જુદા અર્થ ધરાવે છે

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

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

ક્રિયાને તેની રાહ જોયા વિના મોકલો

જે હૂક systemctl restart ને સમકાલિક રીતે બોલાવે છે તે યુનિટ સામે ડેડલોક થઈ શકે છે જેનો ક્રમ ટનલની રાહ જુએ છે. systemctl --no-block try-restart vpn-dependent.service કાર્યને કતારમાં મૂકે છે અને પાછું ફરે છે, જે હૂકને તે કનેક્શનને બ્લોક કરતું અટકાવે છે જેના પર તે પ્રતિક્રિયા આપી રહ્યો હતો. try-restart ફક્ત ચાલતા યુનિટ પર કાર્ય કરે છે, જ્યારે restart નિષ્ક્રિય યુનિટ પણ શરૂ કરે છે; ટેવથી નહીં, જાણી જોઈને પસંદ કરો.

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

રીસ્ટાર્ટ નીતિ યુનિટમાં રહે છે, હૂકમાં નહીં

RemainAfterExit=yes વાળું oneshot યુનિટ તેનો આદેશ પૂરો થયા પછી સક્રિય રહે છે, અને બીજી શરૂઆતની વિનંતી કંઈ કરતી નથી કારણ કે systemd તેને પહેલેથી શરૂ થયેલું માને છે. તે એવી મિલકત છે જેની આસપાસ રચના કરવી પડે, એવો ખામી નહીં જેને વારંવાર શરૂઆતના કૉલ્સથી ટાળવામાં આવે. જો ક્રિયા દરેક કનેક્શન પર ચાલવી જોઈએ, તો યુનિટને એવો આકાર જોઈએ જે તેને મંજૂરી આપે.

After= યુનિટને ક્રમ આપે છે, અને BindsTo= આયુષ્યને બાંધે છે, પરંતુ બંમાંથી કોઈનો અર્થ 'VPN ફરી કનેક્ટ થાય ત્યારે આને ફરી શરૂ કરો' એવો નથી. ટનલ સાથે બંધાયેલું યુનિટ ટનલ અટકે ત્યારે અટકે છે; ટનલ પાછી આવે ત્યારે તે પોતાને ફરી શરૂ કરતું નથી, સિવાય કે કંઈક તેને ફરી શરૂ કરે.

એક નહીં, ત્રણ રીકનેક્ટની કસોટી કરો

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

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