పేజీలు లోడ్ అవుతాయి, VPN కనెక్ట్ అయిందని తెలియజేస్తుంది, మరియు ఫైల్ అప్లోడ్ ప్రతిసారీ అదే ప్రదేశంలో గడ్డకట్టుకుపోతుంది. ఈ వివరణకు నాలుగు వివరణలు సరిపోతాయి: ప్యాకెట్ పరిమాణ సమస్య, పేరు పరిష్కార సమస్య, యాప్ పరిమితి మరియు పదే పదే రీసెట్ అయ్యే సొరంగం. ప్రతి ఒక్కటి వేరే పరిశీలనతో నిర్ధారించవచ్చు లేదా తోసిపుచ్చవచ్చు, కాబట్టి నిర్ణయం కారణాన్ని ఊహించడం కాదు, సరైన పరీక్షను ఎంచుకోవడం.

నాలుగు అభ్యర్థులు ఒక ఆకారం

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

నాలుగవ అభ్యర్థి యాప్. అప్లోడ్ పరిమితులు, అభ్యర్థనల కాల పరిమితులు మరియు ప్రాక్సీలోని బాడీ పరిమాణ ఎగువ పరిమితులు బ్రౌజర్ నుండి నెట్వర్క్ లోపంలా కనిపించే వైఫల్యాలను సృష్టిస్తాయి, అవి సాధారణంగా నిలిచిపోవడం కాకుండా తిరస్కరణగా వస్తాయి.

ఏదైనా పరీక్షించే ముందు గమనించిన ఆకారాన్ని రాయండి. "సుమారు అదే బైట్ సంఖ్యలో, ప్రతిసారీ, సొరంగం పైన ఉన్నప్పుడు ఆగిపోతుంది" అనేది "అప్లోడ్లు పనిచేయవు" కంటే చాలా బలమైన ప్రారంభ స్థానం.

తర్వాత పరీక్ష సమయంలో మార్గాన్ని స్థిరంగా ఉంచండి. నిష్క్రమణ, ప్రోటోకాల్ మరియు సర్వర్ను ఒకేసారి మార్చడం వాటిలో దేనికీ ఆపాదించలేని ఫలితాన్ని ఇస్తుంది. ప్రతి పరుగుకు ఒక చరరాశి, మరియు దాన్ని రాయండి.

విధానాన్ని తాకే ముందు పరిమాణాన్ని సగానికి విభజించండి

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

ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/upload

మొదటి ఆదేశం పూర్తి పరిమాణ ప్యాకెట్ మార్గం గుండా వెళుతుందో లేదో తెలియజేస్తుంది. 1500 బైట్ MTU వద్ద, ఖండించబడని అతిపెద్ద ICMP పేలోడ్ 1472 బైట్, మరియు లోపలి ప్యాకెట్ ప్రారంభం కాకముందే సొరంగం ఆ బడ్జెట్ నుండి మరింత తీసుకుంటుంది. రెండవది యాప్-స్థాయి బదిలీకి పరిమాణం మరియు వ్యవధిని ఇస్తుంది, నిజంగా ముఖ్యమైన సంఖ్య అదే.

CandidateObservation that confirms itObservation that rules it out
Path MTU or blocked ICMP feedbackStall at a consistent size; large do-not-fragment probes failSmall and large transfers both complete
Name resolutionThe connection never opens for that nameThe connection opens and then stalls mid-transfer
Application or proxy limitA clean rejection at a documented sizeNo log entry on the server at all
Tunnel instabilityReconnects or rekeying during the transferThe tunnel uptime is unchanged across the failure

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

తర్వాత బదిలీ సమయంలో స్థిరత్వాన్ని తనిఖీ చేయండి, ఎందుకంటే పెద్ద అప్లోడ్ మధ్యలో కీని పునరుద్ధరించే సొరంగం పరిమాణంపై ఆధారపడినట్టు కనిపించే కానీ కాని వైఫల్యాన్ని సృష్టిస్తుంది. అప్టైమ్ పఠనం దాన్ని నిర్ధారించడానికి అత్యంత చవకైన మార్గం.

మరమ్మత్తు మరియు ప్రత్యామ్నాయం మధ్య ఎంచుకోండి

సాక్ష్యాలు పరిమాణం వైపు సూచిస్తే, రెండు నిజాయితీ సమాధానాలు మరియు ఒక అనిజాయితీ సమాధానం ఉన్నాయి. నిజాయితీవి: అవసరమైన ICMP ప్రతిస్పందనను అనుమతించి మార్గ-MTU ఆవిష్కరణను పునరుద్ధరించడం, లేదా ప్రకటించిన సెగ్మెంట్ పరిమాణాన్ని పరిమితం చేసి తోటివారు చిన్న సెగ్మెంట్లు పంపేలా చేయడం. అనిజాయితీది: ఇంటర్ఫేస్ MTUని ఫోరమ్ నుండి కాపీ చేసిన విలువకు తగ్గించి, అది ఏమి మార్చిందో ఎప్పటికీ తనిఖీ చేయకపోవడం.

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

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

ఏదేమైనా, అసలు విలువలను ఉంచి తిరిగి మార్చిన తర్వాత మళ్లీ పరీక్షించండి. విజయవంతమైన బదిలీతో ఏకకాలంలో జరిగిన మార్పు అదే కారణమని రుజువు కాదు, మార్పును రద్దు చేసే సామర్థ్యమే నిర్ధారణను యాదృచ్ఛికం నుండి వేరు చేస్తుంది.

తదుపరి సంఘటన వరకు నిలిచేలా నిర్ణయాన్ని నమోదు చేయండి

నాలుగు వాస్తవాలు సరిపోతాయి: గమనించిన వైఫల్య ఆకారం, ప్రోబ్ ఫలితాలు, మీరు చేసిన మార్పు మరియు పునఃపరీక్ష ఫలితం. వాటితో తదుపరి వ్యక్తి సమస్య అదేనా లేదా అదే లక్షణంతో కొత్తదా అని చెప్పగలరు.

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

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

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