MTU నల్ల రంధ్రం: చిన్న అభ్యర్థనలు ఎందుకు పనిచేస్తాయి కానీ అప్లోడ్లు ఆగిపోతాయి

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

రంధ్రాన్ని నల్లగా చేసేది ఏమిటి

ప్రతి లింక్కు గరిష్ఠ ప్రసార యూనిట్ ఉంటుంది, మరియు తదుపరి హాప్ పరిమితి కంటే పెద్ద ప్యాకెట్ను విభజించాలి లేదా అది చెప్పే ICMP సందేశంతో తిరస్కరించాలి. మార్గ MTU అన్వేషణ ఆ సందేశం చేరుకోవడం మరియు గౌరవించబడటం మీద ఆధారపడి ఉంటుంది. దాన్ని ఫిల్టర్ చేయడం లేదా నిర్లక్ష్యం చేయడం ఎప్పటికీ సరిపోని ప్యాకెట్ను పంపినవారు పునరావృతం చేయడానికి వదిలివేస్తుంది.

ఎన్క్యాప్సులేషన్ దీన్ని VPN చుట్టూ సాధారణం చేస్తుంది, ఎందుకంటే టన్నెల్ ఇప్పటికే భౌతిక లింక్ కోసం కొలిచిన ప్యాకెట్కు బయటి హెడర్ను జోడిస్తుంది. లోపలి ప్యాకెట్ 1500 బైట్లో చట్టబద్ధం మరియు ఎన్క్యాప్సులేట్ చేయబడినది కాదు, కాబట్టి అది సరిహద్దులో మరణిస్తుంది, చిన్న ప్యాకెట్లు దాటిపోతాయి. పూర్తయిన హ్యాండ్షేక్ మరియు పనిచేసే లాగిన్ పేజీ చిన్న ప్యాకెట్లు పనిచేస్తాయని మాత్రమే నిరూపిస్తాయి. అప్లికేషన్ పంపడానికి ప్రయత్నించే అతిపెద్ద ప్యాకెట్ ముఖ్యమైనది.

అది విరిగే పరిమాణాన్ని కనుగొనండి

విభజన చేయని పరీక్షతో పేలోడ్ పరిమాణాన్ని ద్విమాన శోధనతో కనుగొనండి, టన్నెల్లోని ఒక వైపు హోస్ట్ నుండి మరొక వైపు హోస్ట్కు. దాటే అతిపెద్ద పేలోడ్ మీ ఉపయోగించగల మార్గ MTU నుండి హెడర్ ఓవర్హెడ్ తీసివేసినది.

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

1472 బైట్ల పేలోడ్ శుభ్రమైన 1500 బైట్ల Ethernet మార్గంలో విజయవంతమవుతుంది, IPv4 మరియు ICMP హెడర్ల 28 బైట్లు జోడించినప్పుడు. టన్నెల్ లేచిన తర్వాత అదే పరీక్ష చిన్న పేలోడ్లో మాత్రమే విజయవంతమైతే, తేడా ఎన్క్యాప్సులేషన్ ఓవర్హెడ్, మరియు టన్నెల్ సరిహద్దే తిరస్కరణ సందేశం ఉత్పన్నం కావాల్సిన స్థలం. కనెక్ట్ చేయడానికి ముందు మరియు తర్వాత రెండు సంఖ్యలను నమోదు చేయండి, ఆ జంటే సాక్ష్యం. అప్లికేషన్ IPv6 ఉపయోగిస్తే దానికి కూడా పరీక్షను పునరావృతం చేయండి, ఎందుకంటే హెడర్ పెద్దది మరియు వైఫల్య పరిమితి కదులుతుంది.

టన్నెల్ను నిందించే ముందు సాక్ష్యాలు చదవండి

దూర అప్లికేషన్ లోపాలు, రద్దీ మరియు సాధారణ నష్టం కూడా అప్లోడ్లను ఆపుతాయి, కాబట్టి ఒక విఫల బదిలీ నల్ల రంధ్రాన్ని గుర్తించదు. వాటిని వేరు చేసేది పరిమాణ సంబంధం: 1200 బైట్లో పునరావృత విజయం మరియు 1400 బైట్లో పునరావృత ఆగుడు, అదే దిశలో, అదే చివరి బిందువు ద్వారా.

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

రెండు రవాణాలలో మరమ్మత్తును తనిఖీ చేయండి

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

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

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