કલાકદીઠ OpenVPN ડ્રોપ: ફરી વાટાઘાટ કે સાચું ફરી જોડાણ?

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

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

નરમ રીસેટને પુનઃપ્રારંભથી અલગ પાડો

લોગ લાઇન એ આખું નિદાન છે. ફરી વાટાઘાટ નરમ રીસેટ લખે છે અને પછી એ જ ટનલની અંદર નવી કી અદલાબદલી: ઇન્ટરફેસ તેનું સરનામું રાખે છે, રૂટ ફરી ઉમેરાતા નથી, અને સ્થાપિત TCP સત્રો સામાન્ય રીતે વિરામ સાથે ટકી રહે છે. સાચો પુનઃપ્રારંભ સત્રને ફાડી નાખે છે, ઇન્ટરફેસ ફરી બનાવે છે, કદાચ બીજું ક્લાયન્ટ સરનામું આપે છે, અને દરેક લાંબા ગાળાનું જોડાણ મારી નાખે છે. બંને ઘટનાઓ સામાન્ય છે; તેમાંથી ફક્ત એક જ કપાયેલા કૉલને સમજાવે છે.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

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

અમલી ટાઇમર વાંચો, તમારી ફાઇલ નહીં

reneg-sec એ ડેટા ચેનલની ફરી વાટાઘાટો વચ્ચેની સેકન્ડોની સંખ્યા છે અને તેનું મૂળભૂત મૂલ્ય 3600 છે. દરેક પક્ષ પોતાનું મૂલ્ય ધરાવે છે, અને બેમાંથી નાનું જ ખરેખર રિફ્રેશ શરૂ કરે છે. એ જ એક નિયમ મોટાભાગના અહેવાલો સમજાવે છે: મોટી સંખ્યા ગોઠવતી ક્લાયન્ટ પ્રોફાઇલ પણ દર કલાકે ફરી સેટ થાય છે જ્યારે સર્વર મૂળભૂત મૂલ્ય રાખે છે.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

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

જ્યાં ખરેખર પુશ થાય ત્યાં જ તેને બદલો

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

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

જ્યાં પ્રોફાઇલ કેન્દ્રીય રીતે બને છે, તૈનાત કરેલી નકલને બદલે ટેમ્પલેટ સંપાદિત કરો, નહીં તો આગલી પ્રોવિઝનિંગ કામગીરી હમણાં જ દૂર કરેલું મૂલ્ય પુનઃસ્થાપિત કરશે. એક નહીં, બે અંતરાલ જોઈને ચકાસો: એક શાંત કલાક 7200 પર ગોઠવેલા ટાઇમર સાથે પણ સુસંગત છે.

મિશ્ર તૈનાતીમાં શું થાય તે પણ નક્કી કરો. ફેરફાર પહેલા ક્લાયન્ટો સુધી પહોંચાડશો તો એવી વિન્ડો રહે છે જેમાં સર્વર હજી રિફ્રેશ શરૂ કરે છે; તે નુકસાનરહિત છે પણ પુષ્ટિ માટે લોગ જોતા હો તો ગૂંચવણભર્યું છે. પહેલા નાનું મૂલ્ય ધરાવતી બાજુ બદલો અને લક્ષણ તમે અપેક્ષા રાખો તે બિંદુએ જ અદૃશ્ય થશે.

ફરી વાટાઘાટ બંધ કરીને તમે શું છોડો છો

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

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

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

જ્યારે અંતરાલ બીજે ક્યાંક ઇશારો કરે

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

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

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