TLS ભૂલ પછી OpenVPN વારંવાર ફરી પ્રયાસ કરે છે: તેને કેવી રીતે રોકવું

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

પ્રથમ ભૂલને છુપાવતું ચક્ર

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

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

કંઈપણ બદલતા પહેલા, એક સંપૂર્ણ ચક્ર કેપ્ચર કરો. દૂરનું સરનામું, ભૂલમાં દર્શાવેલ TLS તબક્કો અને પ્રક્રિયા બહાર નીકળે છે કે નહીં તે નોંધો.

લૂપ પાછળની ફરી પ્રયાસ મશીનરી

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

--tls-exit વિકલ્પ ફક્ત વાટાઘાટનો કિસ્સો બદલે છે. મેન્યુઅલ તેને TLS વાટાઘાટ નિષ્ફળતા પર બહાર નીકળવા તરીકે વર્ણવે છે, જે દરેક ભૂલ પર બહાર નીકળવા કરતાં સાંકડું છે. ટાઇમઆઉટ, રિઝોલ્વર નિષ્ફળતાઓ અને પ્રમાણીકરણ અસ્વીકાર તેમનું પોતાનું વર્તન જાળવી રાખે છે.

TLS નિષ્ફળતા પર ક્લાયન્ટને બહાર નીકળવા દેવો

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

સુપરવાઇઝર નક્કી કરે છે કે તે નિકાસ દૃશ્યમાન છે કે નહીં. Restart=always અથવા Restart=on-failure સાથેનું systemd યુનિટ ક્લાયન્ટને ફરી શરૂ કરે છે, તેથી લૂપ ચાલુ રહે છે અને વિકલ્પ કંઈ કરતું નથી એવું લાગે છે. ક્લાયન્ટને દોષ આપતા પહેલા નીતિ તપાસો:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no પ્રક્રિયાને નીચે રહેવા દે છે, અને Restart=on-failure શૂન્ય-સિવાયની સ્થિતિ પછી પણ ફરી શરૂ કરે છે. જો તમે ઇચ્છો કે નિષ્ફળતા દૃશ્યમાન રહે પરંતુ સેવા અસંબંધિત ક્રેશમાંથી પુનઃપ્રાપ્ત થાય, તો Restart=on-failure સેટ કરો અને પુનઃશરૂઆતના તોફાનને રોકવા StartLimitBurst અને StartLimitIntervalSec વાપરો. પછી છેલ્લો નિકાસ કોડ ખાતરી કરવા યુનિટની સ્થિતિ વાંચો: systemctl status તેની જાણ કરે છે, અને જર્નલ પુનઃશરૂઆત ઉપર પ્રથમ ભૂલ રાખે છે.

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

એક વપરાશના એન્ડપોઇન્ટ સાથે તે સાબિત કરો

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

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

પૂર્ણ થયા પછી પરીક્ષણ પ્રોફાઇલ દૂર કરો. જાણી જોઈને ખોટા એન્ડપોઇન્ટવાળી નકલ પછીથી ડિરેક્ટરીની દરેક પ્રોફાઇલ શરૂ કરનાર કોઈપણ માટે જાળ છે.

જે તબક્કા સુધી આ વિકલ્પ ક્યારેય પહોંચતો નથી

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

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

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