OpenVPN રિપ્લે બેકટ્રેક લોગમાં: લીટી શું સાબિત કરતી નથી

લીટી કહે છે PID_ERR replay-window backtrack occurred, અને બધા શોધ પરિણામો તેને ખોવાયેલા પેકેટ અને તૂટેલા ટનલ તરીકે સમજાવે છે. Community OpenVPN 2.6 ના UDP માર્ગમાં, એ સંદેશ ત્યારે લખાય છે જ્યારે રિસીવ ફંક્શન હજી નક્કી કરે છે કે પેકેટ સાથે શું કરવું. તે નવો મહત્તમ બેકટ્રેક નોંધે છે, પછી એ જ ફંક્શન સ્વીકાર અથવા નકાર પહેલાં અંતરને વિન્ડો અને નોંધાયેલ સ્થિતિ સાથે સરખાવે છે. લોગ લેબલને ચુકાદા તરીકે વાંચવું એ ભૂલ છે જે આ ચેકલિસ્ટ રોકવા માટે છે.

થોભો એક: લીટી શું છે તે ઓળખો

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

કયા હોસ્ટે તે લખ્યું અને કેટલી વિગત સાથે, તેની ખાતરી કરો. સર્વર અને ક્લાયન્ટ બંને પેકેટ-ID સંદેશા બહાર કાઢી શકે છે, અને એક બાજુનો સંદેશ બીજી બાજુની રિસીવ સ્થિતિ વિશે કંઈ કહેતો નથી.

થોભો બે: તે પેકેટનું પરિણામ શોધો

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

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

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

થોભો ત્રણ: ક્રમ બદલવો વાસ્તવિક છે કે નહીં તે નક્કી કરો

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

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

થોભો ચાર: વિન્ડો પરિમાણો, અને તે શું નથી

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

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

mute વડે ચેતવણી શાંત કરવી એ તમે જે જુઓ છો તે બદલે છે, ડેમન જે કરે છે તે નહીં. જો ધ્યેય જાણીતી ઘટના દરમિયાન શાંત લોગ હોય, તો તે કાયદેસર કામગીરીની પસંદગી છે; જો ધ્યેય ટનલ સુધારવું હોય, તો શાંત કરવું પુરાવો છુપાવે છે.

mute 20
replay-window 64 15

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

થોભો પાંચ: વપરાશકર્તાને મહત્વનો માર્ગ ચકાસો

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

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

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