టన్నెల్ నడుస్తోంది, గేట్వేలు ఒకదానికొకటి సమాధానం ఇస్తున్నాయి, ఇప్పటికీ ఒక సైట్ వినియోగదారులు మరో సైట్ ఫైల్ షేరింగ్ తెరవలేకపోతున్నారు. ఎవరో గేట్వే నుండి ping చేసి సమాధానం పొంది నెట్వర్క్ ఆరోగ్యంగా ఉందని ప్రకటిస్తారు. ఆ సమాధానం ఎప్పుడూ సమస్య కాని రెండు పరికరాల మధ్య ప్రయాణించింది. ఉపయోగకరమైన పరీక్ష సేవ అవసరమైన హోస్ట్ నుండి ప్రారంభమవుతుంది, యాప్ ఉపయోగించే ప్రోటోకాల్ను ఉపయోగిస్తుంది మరియు అది విఫలమయ్యే పరిస్థితిని తిరిగి సృష్టిస్తుంది. మిగతావన్నీ ఎవరూ లేని మార్గానికి పచ్చని కాంతి.

సేవ అవసరమైన క్లయింట్ నుండి ప్రారంభించండి

ఏదైనా పరీక్షించే ముందు నాలుగు విషయాలు రాయండి: క్లయింట్ చిరునామా, గమ్యం చిరునామా, హోస్ట్ పేరు మరియు యాప్ పోర్ట్. తర్వాత సేవ తన సైట్లో స్థానికంగా పనిచేస్తుందని పక్కనున్న హోస్ట్ నుండి నిర్ధారించండి. ఈ ఆధార రేఖ లేకుండా విరిగిన టన్నెల్ను విరిగిన సేవ నుండి వేరు చేయలేరు, ఈ టికెట్లలో సగం రెండవది.

డాక్యుమెంట్ చేసిన హోస్ట్ పేరును ప్రయత్నించండి, సేవ అనుమతించిన చోట అదే పోర్ట్ యొక్క ప్రత్యక్ష చిరునామా తనిఖీని కూడా చేయండి. విఫలమైన పేరు శోధన మరియు చేరుకోలేని పరిష్కరించిన చిరునామా మిమ్మల్ని వేర్వేరు మార్గాలకు తీసుకువెళతాయి. హోస్ట్ పేరుకు బదులుగా IP పెట్టినా, అది పనిచేయడానికి HTTPS గుర్తింపు తనిఖీని ఆపవద్దు; సర్టిఫికెట్ హెచ్చరిక సమాచారం, అడ్డంకి కాదు.

ప్రతి అంచున మార్గాన్ని నడవండి

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

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

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

యాప్ ఉపయోగించే ప్రోటోకాల్ను ఉపయోగించండి

ICMP బలహీనమైన పరీక్ష. దాన్ని ఫిల్టర్ చేయవచ్చు, వేగంతో పరిమితం చేయవచ్చు లేదా సేవ కంటే భిన్నమైన విధానంతో నిర్వహించవచ్చు, ఇది దాని విజయాన్ని మరియు వైఫల్యాన్ని రెండింటినీ అస్పష్టం చేస్తుంది. నిజమైన పోర్ట్ మరియు సాధ్యమైతే నిజమైన ప్రోటోకాల్ హ్యాండ్షేక్ను పరీక్షించండి.

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

పూర్తయిన TCP హ్యాండ్షేక్ ఆ పోర్ట్కు చేరుకోగలిగే సామర్థ్యాన్ని మరియు విధానాన్ని రుజువు చేస్తుంది. యాప్ పనిచేస్తుందని రుజువు చేయదు: ప్రామాణీకరణ, అప్లోడ్ లేదా నిర్దిష్ట API కాల్ ఇంకా విఫలమవచ్చు. వినియోగదారులు నిజంగా చేసే కార్యకలాపాన్ని, నిజమైన లావాదేవీని పదే పదే సమర్పించడం బదులు హానిచేయని సమానమైన దానితో పరీక్షించండి.

విఫలమయ్యే పరిస్థితిని తిరిగి సృష్టించండి

పెద్ద బదిలీలతో మాత్రమే కనిపించే వైఫల్యాలు పరిమాణ సమస్య, కనెక్టివిటీ సమస్య కాదు. don't-fragment బిట్ సెట్ చేసిన పెద్ద ప్యాకెట్ పంపి అది ఎక్కడ ఆగుతుందో చూడండి. చిన్న అభ్యర్థన విజయవంతమై పెద్దది వేలాడితే, టన్నెల్ MTU మరియు గేట్వేల్లో MSS నిర్వహణ తదుపరి అనుమానితులు.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

ఒకే సబ్నెట్ విఫలమైతే, ట్రాఫిక్ ఎంపికలు, మార్గ ప్రకటనలు మరియు ఆ సబ్నెట్ తిరిగి వెళ్లే గేట్వే చూడండి. హోస్ట్ పేరు మాత్రమే విఫలమైతే, DNS అనుసరించండి, క్లయింట్ ఏ రిజాల్వర్ ఉపయోగించింది మరియు ఆ సైట్ నుండి దూరపు దృశ్యం కనిపిస్తుందా అనేది కూడా కలిపి. మూడు వేర్వేరు వైఫల్యాలు, మూడు వేర్వేరు సరిదిద్దులు, మరియు ping పరీక్ష వాటిలో ఏదీ వేరు చేయదు.

సరిదిద్దిన తర్వాత అదే పరీక్షను మళ్లీ చేయండి

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

నాలుగు ఆధార విలువలు మరియు ఫలితాన్ని నమోదు చేయండి. అదే లక్షణం యొక్క తదుపరి నివేదిక అప్పుడు pingకి బదులుగా రుజువుల నుండి ప్రారంభమవుతుంది.

సంబంధిత వ్యాసాలు