Kill switch-ը միանում է. ի՞նչ է պատահում բաց TCP սեսիաների հետ։

Թունելը կտրվում է, kill switch-ը միանում է, և երեք քառորդով ավարտված ներբեռնումը կա՛մ սառչում է, կա՛մ անմիջապես ձախողվում։ Այս երկու ելքերը գալիս են կիրարկման տարբեր ընտրություններից, ոչ թե պաշտպանության տարբեր մակարդակներից։ Բաց թողնված փաթեթը կապը թողնում է սպասման մեջ, մինչդեռ մերժված փաթեթը փակում է այն և տեղեկացնում հավելվածին։ Որոշելը, թե որ վարքագիծն եք ուզում, ձևավորման հարց է, իսկ դրա փորձարկումը՝ առանձին վարժություն։

Բաց թողնելը, մերժելը և վերակայելը տարբեր են

Երթևեկությունը բաց թողնող firewall-ի կանոնը դեն է նետում փաթեթը և ոչինչ հետ չի ուղարկում, այնպես որ ուղարկողը շարունակում է վերաուղարկել իր իսկ ժամաչափերով։ TCP reset-ով մերժող կանոնը անմիջապես փակում է կապը, և հավելվածը տեսնում է սխալ։ Kill switch-ների մեծ մասը բաց է թողնում, որովհետև մերժումը կբացահայտեր քաղաքականությունը և որովհետև բաց թողնելը նման է մեռած ցանցի վարքագծին։

Արգելափակելը նույնը չէ, ինչ socket-ը փակելը։ Հավելվածը դեռ պահում է դեսկրիպտոր հաստատված վիճակում, և միայն փաթեթներն են բացակայում։ Այդ պատճառով էջը կարող է րոպեներ շարունակ մնալ բեռնման ցուցիչի վրա, մինչ օպերացիոն համակարգը պնդում է, որ կապը գոյություն ունի։ Կարդացեք փաստաթղթավորված կիրարկումը, փոխանակ այն եզրակացնեք հավելվածի հաղորդագրությունից, քանի որ երկու վարքագծերն էլ նման են ցանցի անջատմանը։

Ինչ է անում հավելվածը, քանի դեռ ընդմիջումը տևում է

TCP-ն վերաուղարկում է աճող ուշացումներով, և Linux-ի լռելյայն վերափորձերի բյուջեն սպառվում է ոչ թե վայրկյանների, այլ մոտավորապես տասնհինգ րոպեի ընթացքում։ Մինչ այդ socket-ը ոչ օգտակար բաց է, ոչ էլ փակ։ Սեփական keepalive-ով կամ հարցումների ժամկետով հավելվածները հաճախ ավելի շուտ են հանձնվում, դրա համար է, որ նույն մեքենայի երկու ծրագրեր մեկ խափանման ընթացքում տարբեր են վարվում։

Երբ թունելը վերադառնում է, տեղական socket-ը չի փոխվել, բայց ուղին կարող է փոխված լինել։ Նոր հանրային աղբյուրի հասցեն սերվերում ստեղծում է այլ քառյակ, այնպես որ հեռավոր կողմի վիճակային firewall-ը այլևս չի համապատասխանում սեսիային։ Կապը մեռած է, թեև client-ը երբեք սխալ չի տեսել։

Որոշեք՝ վերականգնում է պահանջվում

Ընտրեք երկու պայմանագրերի միջև։ Կա՛մ սեսիան պետք է դիմանա կարճ ընդմիջմանը, ինչը պահանջում է կայուն հասցեավորում և իր վիճակը պահող սերվեր, կա՛մ հավելվածը պետք է մաքուր վերամիանա, ինչը պահանջում է կրկնելու համար անվտանգ վերափորձերի տրամաբանություն։ Միջև ընկած ամեն ինչ տալիս է ամենավատ արդյունքը՝ client, որը վերաուղարկում է այն, ինչ սերվերն արդեն հաստատել է, կամ մեկը, որը հաջողություն է հայտնում սեսիայի համար, որը ոչ ոք չի տեսնում։

Կայուն հասցեավորումը այն մասն է, որը մարդիկ մոռանում են, որովհետև այլ հանրային հասցեով վերամիացումը անվավեր է դարձնում սերվերի կողմի վիճակը նույնիսկ այն ժամանակ, երբ client-ի socket-ը առողջ է թվում։ Գրեք, թե երկու պայմանագրերից որն է կիրառվում յուրաքանչյուր հավելվածի համար, քանի որ դրանք հազվադեպ են բոլորը համընկնում։

Ստուգեք արգելափակումը և վերականգնումը առանձին

Արտահոսքի պաշտպանությունը և սեսիայի գոյատևումը դիտարկեք որպես երկու հատկություն, որովհետև մեկի անցնելը ոչինչ չի ասում մյուսի մասին։ Գոյատևած սեսիան ապացույց չէ, որ ուղիղ երթևեկությունը արգելափակվել է, և մահացած սեսիան ապացույց չէ, որ արգելափակվել է յուրաքանչյուր ուղիղ երթուղի։

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'

Վերականգնումը դիտարկելիս օգտագործեք անվնաս փորձարկման գործողություն, որպեսզի կրկնված ուղարկումը դեպք չդառնա։ Գրանցեք այն ձախողման ձևը, որն իրականում տեսաք՝ ինչ ցուցադրեց հավելվածը, արդյոք socket-ը գոյատևեց, և երբ այն ինքնուրույն վերականգնվեց։

Գրեք սպասվող վարքագիծը կիրարկման կանոնի կողքին և ամսաթիվ դրեք։ Հաջորդ մարդը, ով կփոխի այդ կանոնը, պետք է իմանա, թե երկու պայմանագրերից որն է խոստացել տեղակայումը։