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

બંને નામ એકસાથે વાંચો અને ડિઝાઇન સ્પષ્ટ થાય છે. એક ડિસ્ક્રિપ્ટર રાખે છે, બીજું કી સામગ્રી રાખે છે, અને બંને વિશેષાધિકારો છોડ્યા પછી જે થાય છે તેને કારણે અસ્તિત્વમાં છે.

બે સંસાધનો અને જે રીસેટ તેઓ સાથે જોડાયેલા છે

OpenVPN બે સામાન્ય પરિસ્થિતિઓમાં તેના પોતાના રીસ્ટાર્ટનો સંકેત આપે છે. સ્પષ્ટ SIGUSR1 તે કરે છે, અને મૃત સાથી દ્વારા ટ્રિગર થયેલ ping-restart પણ એ જ કરે છે. બંને પ્રક્રિયાને જીવંત રાખે છે અને કનેક્શન સેટઅપ ફરી ચલાવે છે, અને ત્યાં જ વિકલ્પો પોતાનું સ્થાન કમાય છે.

EventTUN/TAP deviceKey and auth filesAddresses and routesup/down hooks
Soft reset, from SIGUSR1 or from a ping-restart the daemon sends itselfsurvives only with persist-tunsurvive only with persist-keysurvive with the device, otherwise rebuiltrun again only when restart hooks are enabled
Configuration reload, SIGHUPrecreatedre-read from diskrebuilt once the device returnsrun again
Service stoplostre-read at the next startremovedrun at the next start

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

વિકલ્પો બિલકુલ કેમ અસ્તિત્વમાં છે

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

persist વિકલ્પો વિના, ping-restart ટ્રિગર કરવા પૂરતો સમય ચૂપ રહેતો સાથી તે જ ક્રિયાઓ ફરજિયાત કરાવે. કન્ફિગરેશનમાં કંઈ બદલાયું ન હોવા છતાં ફરી જોડાણ નિષ્ફળ જાય. પ્રક્રિયા કોઈ કારણ વિના મરતી હોય તેવું લાગે, અને લોગ નેટવર્ક ભૂલને બદલે પરવાનગી ભૂલ બતાવે.

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

પહેલી ભૂલ વાંચો, છેલ્લી નહીં

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

હૂકનું પોતાનું સ્વિચ હોય છે. OpenVPN મેન્યુઅલ persist વિકલ્પોને up-restart સાથે જોડે છે, જે નક્કી કરે છે કે રીસ્ટાર્ટ પછી up અને down સ્ક્રિપ્ટ ફરી ચાલશે કે નહીં. તેથી ઊભું રહેલું ઇન્ટરફેસ તમારા રિઝોલ્વર એકીકરણ રિફ્રેશ થયું કે નહીં તે વિશે કંઈ કહેતું નથી.

# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'

# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0

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

જાળવેલું ઇન્ટરફેસ kill switch નથી

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

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

નિદાન પહેલાં ઘટનાનું નામ આપો. નરમ રીસ્ટાર્ટ, નિષ્ફળ કનેક્શન પ્રયાસ અને સેવા બંધ કરવી એ ત્રણ વર્તન સાથેની ત્રણ ઘટનાઓ છે, અને ફક્ત પ્રથમ જ આ વિકલ્પો વર્ણવે છે તે.

સંબંધિત લેખો