కిల్ స్విచ్ పరీక్ష: మళ్లీ కనెక్ట్ మాత్రమే కాదు, విరామాన్ని కొలవండి
వేగవంతమైన మళ్లీ కనెక్షన్ క్లయింట్ వేగవంతమని నిరూపిస్తుంది. విరామ సమయంలో యంత్రం నుండి ఏమి బయటకు వెళ్లిందో ట్రిగ్గర్తో పాటు నమోదు చేయండి, లేకపోతే పరీక్ష సగాన్ని మాత్రమే కొలిచింది.
ఒక సెకనులో ముగిసే మళ్లీ కనెక్షన్ క్లయింట్ వేగవంతమని చెబుతుంది. టన్నెల్ ఆఫ్లో ఉన్నప్పుడు ఏదైనా తప్పించుకుందా అని అది చెప్పదు. ఒక నిమిషం తీసుకునే మళ్లీ కనెక్షన్ క్లయింట్ నెమ్మదిగా ఉందని చెబుతుంది, మరియు విరామంలో నేరుగా ట్రాఫిక్ అనుమతించబడిందా అని కూడా ఇంకా చెప్పదు. ఇవి రెండు కొలతలు, మరియు మొదటిదాన్ని మాత్రమే నివేదించే కిల్ స్విచ్ పరీక్ష స్విచ్ను పరీక్షించలేదు.
రెండు పరిశీలనలు, రెండు వేర్వేరు తీర్పులు
లభ్యత ప్రశ్న సులభం: టన్నెల్ మళ్లీ ఎప్పుడు ఉపయోగించదగినదైంది, మరియు అక్కడికి చేరుకోవడానికి రక్షిత అనువర్తనానికి కొత్త కనెక్షన్ అవసరమైందా. అమలు ప్రశ్న భిన్నం: రక్షణ పడిపోయిన క్షణం నుండి అది తిరిగి వచ్చిన క్షణం వరకు ఏ ప్యాకెట్లు యంత్రాన్ని విడిచాయి.
వాటికి వేర్వేరు నమోదులతో సమాధానం ఇవ్వండి. ఒక పంక్తి విరామం నిర్దిష్ట సంఖ్యలో సెకన్లు కొనసాగిందని చెబుతుంది. మరొక పంక్తి ఆ విరామంలో రక్షణ లేని అభ్యర్థన విజయవంతమైందా అని చెబుతుంది. వాటిని ఒకే ఉత్తీర్ణత లేదా వైఫల్యంగా కలపడం అత్యంత ముఖ్యమైన సందర్భాన్ని దాచిపెడుతుంది: లీక్తో కూడిన వేగవంతమైన మళ్లీ కనెక్షన్.
సమయాన్ని కొలవగల ప్రోబ్ను నిర్మించండి
ఇలాంటి అభ్యర్థనను ఉపయోగించండి: హానికరం కానిది, చౌకైనది మరియు టన్నెల్ స్వంత నియంత్రణ ఛానెల్ నుండి స్వతంత్రమైనది. క్రింది లూప్ సెకనుకు ఒకసారి టైమ్స్టాంప్, HTTP స్థితి మరియు గడిచిన సమయాన్ని ముద్రిస్తుంది, మరియు వేలాడుతూ ఉండకుండా బిగ్గరగా విఫలమవుతుంది:
while true; do
printf '%s ' "$(date +%H:%M:%S)"
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
sleep 1
done
స్థితి మాత్రమే కాదు, curl నిష్క్రమణ కోడ్లను చదవండి. 28 అంటే అభ్యర్థన సమయం ముగిసింది, బ్లాక్ చేసిన మార్గం ఇలాగే కనిపిస్తుంది. 6 అంటే పేర్ల పరిష్కారం విఫలమైంది, ఇది వేరే కనుగొనడం మరియు తరచుగా మరింత ఆసక్తికరం. విరామంలో తక్కువ గడిచిన సమయంతో 200 వస్తే ట్రాఫిక్ బయటకు వెళ్లడానికి అనుమతించబడింది.
అవుట్పుట్ను ఫైల్లో రాసి ఉంచండి. టెర్మినల్ స్క్రాల్బ్యాక్ సాక్ష్యం కాదు, ఆసక్తికరమైన భాగం సాధారణంగా మధ్యలో మూడు పంక్తులు.
నిజమైన వైఫల్యాన్ని కలిగించండి, చక్కటిది కాదు
క్లయింట్ స్వంత మెనూ నుండి డిస్కనెక్ట్ చేయడం సహకార మార్గాన్ని పరీక్షిస్తుంది, అక్కడ క్లయింట్కు తన బ్లాకింగ్ నియమాలను ఇన్స్టాల్ చేయడానికి సమయం ఉంటుంది. బదులుగా ప్రక్రియను చంపండి, లేదా క్రింది లింక్ను తెంచండి, అప్పుడు నిజమైన వైఫల్యం వెళ్లే మార్గాన్ని పరీక్షిస్తారు.
ప్రతి ట్రిగ్గర్ వేరే కోడ్ మార్గాన్ని సాధన చేస్తుంది. సర్వర్ వైపు అంతరాయం, స్థానిక లింక్ నష్టం మరియు క్లయింట్ క్రాష్ ప్రతి ఒక్కటి వేరే స్థితిని మిగల్చవచ్చు, మరియు వాటిలో ఒకటి చివరికి మీరు ఎదుర్కొనే సందర్భం కావచ్చు. కనీసం రెండు ట్రిగ్గర్లపై ప్రోబ్ను నడపండి మరియు ఫలితాలను ట్రిగ్గర్ ప్రకారం లేబుల్ చేయండి.
అనుమతించిన ట్రాఫిక్ ఎలా ఉంటుందో తెలుసుకోవడానికి లాగ్ చదవండి
విరామంలో 200 లేదా వేగవంతమైన కనెక్షన్ వైఫల్యం లీక్, అది ఏ దిశలో ఉన్నా. మొత్తం విరామంలో సమయం ముగియడం బ్లాకింగ్ విధానం యొక్క ఆశించిన రూపం. కనెక్షన్లు విఫలమవుతుండగా పేర్ల పరిష్కారం విజయవంతం కావడం రిజాల్వర్ ఇంకా చేరుకోగలిగినదని సూచిస్తుంది, ఇది మరో రకమైన లీక్.
ఇప్పటికే ఉన్న సాకెట్లకు జాగ్రత్త అవసరం. ఒక ప్రోగ్రామ్ డిస్కనెక్ట్కు ముందు తెరిచిన కనెక్షన్ను ఉపయోగించడం కొనసాగించవచ్చు, కాబట్టి సజీవంగా కనిపించే ట్రాఫిక్ కొత్త మార్గం అనుమతించబడిందని నిరూపించకపోవచ్చు. సాకెట్ జాబితా కనెక్షన్ సంఘటనకు ముందుదా అని చూపిస్తుంది:
ss -tunp | grep -E 'ESTAB|SYN-SENT' ip route get 198.51.100.7 resolvectl status | sed -n '1,20p'
సాకెట్ ప్రారంభ సమయాన్ని డిస్కనెక్ట్ యొక్క టైమ్స్టాంప్తో పోల్చండి. అంతరాయం కంటే పాత కనెక్షన్ లీక్ యొక్క కాదు, సాకెట్ పునర్వినియోగం యొక్క సాక్ష్యం, మరియు దానిని వైఫల్యంగా నివేదించడం తదుపరి వ్యక్తిని లేని బగ్ వేటకు పంపుతుంది.
అప్డేట్ను తట్టుకునే రూపంలో ఫలితాన్ని నమోదు చేయండి
ట్రిగ్గర్, సెకన్లలో విరామం, బ్లాక్ చేయని ఏదైనా అభ్యర్థన విజయవంతమైందా, పేర్ల పరిష్కారం విజయవంతమైందా, మరియు క్లయింట్ మరియు ఆపరేటింగ్ సిస్టమ్ వెర్షన్లను రాయండి. ఐదు వాస్తవాల ఈ సమూహం విడుదలల మధ్య పోల్చదగినది, ఒక గద్య పేరా అలా చేయలేదు.
క్లయింట్ అప్డేట్ లేదా ప్రొఫైల్ మార్పు తర్వాత అదే పరీక్షను మళ్లీ నడపండి, ఎందుకంటే బ్లాకింగ్ ప్రవర్తన అమలు వివరం మరియు అది కదులుతుంది. నమోదు ఉద్దేశ్యం అది సంఘటనగా మారకముందే కదలికను గమనించడం, క్లయింట్ను ఒకసారి ధృవీకరించడం కాదు.