Azure OpenVPN ટનલ લગભગ દર સાઠ સેકન્ડે કેમ તૂટી પડે છે

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

કોઈપણ ટાઈમરને સ્પર્શ કરતા પહેલા તે લાઇન વાંચો.

દંતકથા: માર્ગમાં કંઈક ટનલને અવરોધે છે

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

લય એ ઉપયોગી સૂત્ર છે. ટાઈમર તેને ઉત્પન્ન કરે છે; પેકેટ ગુમાવવું ભાગ્યે જ.

ટાઈમર પહેલા ડિસ્કનેક્ટનું કારણ વાંચો

OpenVPN તેનું કારણ નામ આપે છે, અને દરેક નામ અલગ સબસિસ્ટમ તરફ ઇશારો કરે છે. Session invalidated: KEEPALIVE_TIMEOUT એ સમાપ્ત થતું ટાઈમર છે, તેથી બંને છેડે ping અને ping-restart મૂલ્યોની સરખામણી કરો. AUTH_FAILED એ ઓળખપત્રો કે પ્રમાણપત્રની સ્થિતિ છે, અને કોઈ ટાઈમર ફેરફાર મદદ કરશે નહીં. TLS ભૂલનો અર્થ છે કે બંને પક્ષ ક્યારેય keepalive તબક્કા સુધી પહોંચ્યા જ નહીં.

કનેક્શનનો સમય, ડિસ્કનેક્ટનો સમય અને અંતરાલ સેકન્ડ સુધી સ્થિર છે કે નહીં તે નોંધો. એ એક જ માપ રૂપરેખાંકિત સમયપત્રકને સંજોગોથી અલગ પાડે છે.

સ્થિર અંતરાલ એ ટાઈમર છે. ખસતું અંતરાલ વધુ સંભવતઃ માર્ગની સમસ્યા કે સ્થળાંતરિત સત્ર છે.

બે keepalive ટાઈમર જે ક્યારેય સંમત ન થયા

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

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

ક્લાયન્ટ બાજુનો સૌથી નાનો ફેરફાર એ છે કે પ્રોફાઇલના ટોચના સ્તરે, દરેક ઇનલાઇન બ્લોકની બહાર, ટાઈમરોને નિષ્ક્રિય કરવા:

keepalive 0 0

સાચવો, પ્રોફાઇલ ફરી લોડ કરો, ફરી કનેક્ટ કરો. મેમરીમાં પહેલેથી રહેલું સત્ર જૂનાં મૂલ્યો રાખે છે, તેથી સંપાદન ક્યારેક કંઈ જ ન કર્યું હોય તેમ લાગે છે.

પ્રમાણપત્રનું નામ તમારા પગ નીચેથી ખસી શકે છે

Azure પ્રમાણપત્ર પ્રમાણીકરણ એના પર આધાર રાખે છે કે ક્લાયન્ટ આજે ગેટવે જે નામ રજૂ કરે છે તેના પર ભરોસો રાખે. જૂની ડાઉનલોડમાંની verify-x509-name લાઇન એવા નામને પિન કરી શકે છે જે ગેટવેની પુનઃનિર્માણ કે પ્રમાણપત્ર નવીકરણે ત્યારથી બદલી નાખ્યું છે, અને અસંગતિ સ્પષ્ટ ભૂલને બદલે પુનઃકનેક્શન લૂપ તરીકે દેખાય છે. લાઇન કાઢી નાખવાથી કનેક્ટિવિટી પાછી આવે છે, જે તેને સારું નિદાન અને ખરાબ કાયમી સુધારો બનાવે છે, કારણ કે તે ચકાસણી પણ દૂર કરે છે. ટનલ ટકી રહે એટલે ગેટવે ખરેખર જે નામ રજૂ કરે છે તેના સાથે લાઇન પુનઃસ્થાપિત કરો.

ગેટવેને સંપાદિત કરતા પહેલા એ જ મશીન પર બીજી પેઢીનો ક્લાયન્ટ ચકાસો. જો એક ક્લાયન્ટ લૂપમાં જાય અને બીજો ટકી રહે, તો પ્રોફાઇલ સમસ્યા નથી.

શું બદલવું, અને કયા ક્રમમાં

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

પછી કેટલાક મિનિટ સુધી સતત ટ્રાફિક ચલાવીને નિષ્ક્રિય માર્ગ ચકાસો. જો ટ્રાફિક વહેતો હોય ત્યારે ટૂટવું અટકે, તો મહત્વનું ટાઈમર માર્ગ પરના NAT ઉપકરણ કે લોડ બેલેન્સરનું છે, OpenVPNનું નહીં.

ફક્ત એ ચાર પરીક્ષણો પછી જ ગેટવે સેટિંગ્સ બદલવાં જોઈએ.