కిల్ స్విచ్ సక్రియమైనప్పుడు: తెరిచిన TCP సెషన్లకు ఏమవుతుంది?

టన్నెల్ పడిపోతుంది, కిల్ స్విచ్ సక్రియమవుతుంది, మరియు మూడు వంతుల పూర్తయిన డౌన్లోడ్ గాని స్తంభించిపోతుంది, గాని వెంటనే విఫలమవుతుంది. ఈ రెండు ఫలితాలు రక్షణ యొక్క వేర్వేరు స్థాయిల నుండి కాదు, అమలు యొక్క వేర్వేరు ఎంపికల నుండి వస్తాయి. విస్మరించిన ప్యాకెట్ కనెక్షన్ను వేచి ఉండనిస్తుంది, అయితే తిరస్కరించిన ప్యాకెట్ దాన్ని మూసి అప్లికేషన్కు తెలియజేస్తుంది. ఏ ప్రవర్తన కావాలో నిర్ణయించడం డిజైన్ ప్రశ్న, దాన్ని పరీక్షించడం వేరే వ్యాయామం.

విస్మరించడం, తిరస్కరించడం మరియు రీసెట్ చేయడం వేర్వేరు

ట్రాఫిక్ను విస్మరించే ఫైర్వాల్ నియమం ప్యాకెట్ను పడేసి ఏమీ తిరిగి పంపదు, కాబట్టి పంపేవాడు తన సొంత టైమర్ల ప్రకారం మళ్లీ పంపుతూనే ఉంటాడు. TCP reset తో తిరస్కరించే నియమం కనెక్షన్ను వెంటనే మూస్తుంది మరియు అప్లికేషన్కు లోపం కనిపిస్తుంది. చాలా కిల్ స్విచ్లు విస్మరిస్తాయి, ఎందుకంటే తిరస్కరణ విధానాన్ని బయటపెడుతుంది మరియు విస్మరించడం చనిపోయిన నెట్వర్క్ ప్రవర్తనను పోలి ఉంటుంది.

బ్లాక్ చేయడం సాకెట్ను మూసేయడం వంటిది కాదు. అప్లికేషన్ ఇంకా స్థాపిత స్థితిలో డిస్క్రిప్టర్ను కలిగి ఉంది, ప్యాకెట్లు మాత్రమే లేవు. అందుకే ఆపరేటింగ్ సిస్టమ్ కనెక్షన్ ఉందని పట్టుబడుతున్నప్పుడు పేజీ నిమిషాల పాటు స్పిన్నర్పై కూర్చోగలదు. అప్లికేషన్ సందేశం నుండి ఊహించడం బదులు డాక్యుమెంట్ చేసిన అమలును చదవండి, ఎందుకంటే రెండు ప్రవర్తనలు నెట్వర్క్ పడిపోయినట్లే కనిపిస్తాయి.

విరామం కొనసాగుతున్నప్పుడు అప్లికేషన్ ఏమి చేస్తుంది

TCP పెరుగుతున్న ఆలస్యాలతో మళ్లీ పంపుతుంది, మరియు Linux డిఫాల్ట్ రీట్రై బడ్జెట్ సెకన్లలో కాదు, సుమారు పావు గంటలో ముగుస్తుంది. అప్పటి వరకు సాకెట్ ఉపయోగకరంగా తెరిచి ఉండదు, మూసి ఉండదు. సొంత keepalive లేదా అభ్యర్థన కాల పరిమితి ఉన్న అప్లికేషన్లు తరచుగా ముందే వదిలేస్తాయి, అందుకే ఒకే మెషీన్లో రెండు ప్రోగ్రామ్లు ఒక అంతరాయం సమయంలో భిన్నంగా ప్రవర్తిస్తాయి.

టన్నెల్ తిరిగి వచ్చినప్పుడు స్థానిక సాకెట్ మారలేదు, కానీ మార్గం మారి ఉండవచ్చు. కొత్త పబ్లిక్ మూల చిరునామా సర్వర్లో వేరే నాలుగు-జోడిని ఉత్పత్తి చేస్తుంది, కాబట్టి అవతలి వైపు స్థితి ఫైర్వాల్ ఇకపై సెషన్కు సరిపోలదు. క్లయింట్ ఎప్పుడూ లోపం చూడకపోయినా కనెక్షన్ చనిపోయింది.

రికవరీ అవసరమా అని నిర్ణయించండి

రెండు ఒప్పందాల్లో ఒకటి ఎంచుకోండి. గాని సెషన్ చిన్న విరామాన్ని దాటాలి, దానికి స్థిర చిరునామా మరియు తన స్థితిని నిలుపుకునే సర్వర్ అవసరం, లేదా అప్లికేషన్ శుభ్రంగా మళ్లీ కనెక్ట్ కావాలి, దానికి పునరావృత్తికి సురక్షితమైన రీట్రై లాజిక్ అవసరం. వీటి మధ్య ఏదైనా అత్యంత దారుణ ఫలితం ఇస్తుంది: సర్వర్ ఇప్పటికే నమోదు చేసినదాన్ని మళ్లీ పంపే క్లయింట్, లేదా ఎవరూ చూడలేని సెషన్ కోసం విజయాన్ని నివేదించే క్లయింట్.

స్థిర చిరునామా అనేది ప్రజలు మరచిపోయే భాగం, ఎందుకంటే వేరే పబ్లిక్ చిరునామాలో దిగే పునఃకనెక్షన్ క్లయింట్ సాకెట్ ఆరోగ్యంగా కనిపించినా సర్వర్ వైపు స్థితిని చెల్లదని చేస్తుంది. రెండు ఒప్పందాల్లో ఏది ప్రతి అప్లికేషన్కు వర్తిస్తుందో రాయండి, ఎందుకంటే అవన్నీ సరిపోలడం అరుదు.

బ్లాక్ మరియు రికవరీని విడివిడిగా తనిఖీ చేయండి

లీక్ రక్షణ మరియు సెషన్ మనుగడను రెండు లక్షణాలుగా పరిగణించండి, ఎందుకంటే ఒకటి దాటడం మరొకదాని గురించి ఏమీ చెప్పదు. బతికిన సెషన్ ప్రత్యక్ష ట్రాఫిక్ బ్లాక్ అయిందనడానికి రుజువు కాదు, మృత సెషన్ ప్రతి ప్రత్యక్ష మార్గం బ్లాక్ అయిందనడానికి రుజువు కాదు.

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'

రికవరీని గమనిస్తున్నప్పుడు హానికరం కాని పరీక్షా చర్యను ఉపయోగించండి, తద్వారా నకిలీ సమర్పణ సంఘటన కాదు. మీరు నిజంగా చూసిన వైఫల్య విధానాన్ని నమోదు చేయండి: అప్లికేషన్ ఏమి చూపింది, సాకెట్ బతికిందా, మరియు అది తనంతట తానే ఎప్పుడు కోలుకుంది.

ఆశించిన ప్రవర్తనను అమలు నియమం పక్కన రాసి తేదీ పెట్టండి. ఆ నియమాన్ని తర్వాత మార్చే వ్యక్తి అమరిక ఏ ఒప్పందాన్ని వాగ్దానం చేసిందో తెలుసుకోవాలి.