કિલ સ્વિચ સક્રિય: ખુલ્લા TCP સેશન સાથે શું થાય છે?

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

છોડી દેવું, નકારવું અને રીસેટ કરવું જુદા જુદા છે

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

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

ગેપ દરમિયાન એપ્લિકેશન શું કરે છે

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

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

રિકવરી જરૂરી છે કે નહીં તે નક્કી કરો

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

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

બ્લોક અને રિકવરી અલગ અલગ ચકાસો

લીક સુરક્ષા અને સેશન ટકી રહેવું એ બે ગુણધર્મ ગણો, કારણ કે એક પાસ થવાથી બીજા વિશે કંઈ કહેવાતું નથી. ટકી રહેલું સેશન સીધા ટ્રાફિકને અવરોધ્યો હોવાનો પુરાવો નથી, અને મૃત્યુ પામેલું સેશન દરેક સીધો માર્ગ અવરોધાયો હોવાનો પુરાવો નથી.

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

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

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