ફેલઓવર પરીક્ષણ: સ્થાપિત TCP સ્ટ્રીમ ટકી રહે છે?

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

બે પરિણામ જે એક જ સફળતા જેવા લાગે

વિચારો કે 10.90.0.42 પરના ક્લાયન્ટનું 198.51.100.20:443 સાથે જોડાણ છે. પ્રાથમિક એક્ઝિટ તેને એક જાહેર સરનામા અને પોર્ટમાં રૂપાંતરિત કરે છે, અને બેકઅપ એક્ઝિટ તેને બીજામાં. ક્લાયન્ટનું આંતરિક સરનામું ક્યારેય બદલાતું નથી, તેથી લોકો અપેક્ષા રાખે છે કે જોડાણ ટકી રહેશે.

સર્વર આંતરિક સરનામું જોતું નથી. તે રૂપાંતરિત અંતિમ બિંદુ જુએ છે, અને સ્વિચ પછી તે બિંદુ અલગ હોય છે.

તેથી જૂનો સ્ટ્રીમ સમયસીમા પૂરી કરે છે જ્યારે એ જ સેવા માટે નવું જોડાણ તરત જ કામ કરે છે. બંને અવલોકનો એકસાથે સાચા છે.

એક્ઝિટ બદલાય ત્યારે સર્વર શું જુએ છે

TCP જોડાણ તેના ચતુષ્કોણ દ્વારા ઓળખાય છે, અને સ્રોત સરનામું કે પોર્ટ બદલવાથી સ્વીકારનાર હોસ્ટ માટે અલગ જોડાણ બને છે. સર્વર ન ઓળખતું હોય તેવા જોડાણ પર નવા સ્રોતથી આવતા પેકેટ કાઢી નાખવામાં આવે છે અથવા રીસેટ સાથે જવાબ આપવામાં આવે છે. VPN ક્લાયન્ટના સરનામામાં કંઈ પણ તે ફેરફાર દરમિયાન સંબંધ જાળવી રાખતું નથી.

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

કોઈને સાતત્યનું વચન આપતા પહેલાં ચકાસો કે જોડી ખરેખર સ્ટેટ રાખે છે. નીચેની આદેશો બંને બાજુની વર્તમાન સ્થિતિ દર્શાવે છે.

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

એક જ જાહેર સરનામું કેમ પૂરતું નથી

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

RFC 3022 સરનામા રૂપાંતરણનું વર્ણન કરે છે અને રૂપાંતરણ કરતા ઉપકરણો વચ્ચે સ્ટેટ આપલેને બેકઅપ ડિઝાઇનનો ભાગ ગણે છે. ફ્લોટિંગ સરનામું કે નકલ કરેલી પ્રોફાઇલ રૂપરેખા ખસેડે છે પણ સ્ટેટ ખસેડતું નથી.

તેથી ફક્ત બેકઅપ દ્વારા પિંગ કરતું પરીક્ષણ ઘણું ઓછું સાબિત કરે છે. પિંગ પાસે ગુમાવવા જેવું કોઈ જોડાણ સ્ટેટ નથી.

જરૂરિયાત કેટલી મજબૂત છે તે નક્કી કરો

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

જરૂરિયાતને માપી શકાય તેવા પરિણામવાળા વાક્ય તરીકે લખો, જેમ કે અપલોડ ફરી શરૂ કર્યા વિના પૂર્ણ થાય છે અથવા ઓપરેટર એક મિનિટમાં ફરી જોડાય છે. પછી તેને સંતોષતું સૌથી સસ્તું મિકેનિઝમ પસંદ કરો, અને તે ઘણી વાર પુનઃપ્રાપ્તિ ડિઝાઇન હોય છે.

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

જૂનો સ્ટ્રીમ અને નવી વિનંતી ચકાસો

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

ત્રણ મૂલ્ય જણાવો: જૂનો સ્ટ્રીમ ચાલુ રહ્યો, રીસેટ થયો કે સમયસીમા પૂરી કરી; નવી ક્રિયા પ્રથમ વાર ક્યારે કામ કરી; અને ફેલબેકે કંઈ તોડ્યું કે નહીં. એ જ ત્રણ લીટીઓ સ્વીકૃતિ રેકોર્ડ છે.

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

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