VPN ద్వారా పాత్ MTU కనుగొనడం: పరిమాణం మరియు ICMP ఖాళీ

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

పాత్ MTU నిజానికి ఏమి కొలుస్తుంది

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

టన్నెల్ కోసం ముఖ్యమైన సంఖ్య లోపలి MTU, అంటే బయటి మార్గం అనుమతి నుండి ఎన్క్యాప్సులేషన్ ఖర్చు చేసేది తీసివేసిన తర్వాత మిగిలినది. WireGuard బయటి IP హెడర్ మరియు UDP హెడర్ను జోడిస్తుంది; ఇతర రవాణాలు తమవి జోడిస్తాయి. లోపలి పరిమాణాన్ని చాలా ఎక్కువగా పెట్టండి, పూర్తి పరిమాణ ప్యాకెట్ ప్రతిదానికీ ఎప్పుడూ జరగని ఫ్రాగ్మెంటేషన్ అవసరమవుతుంది.

టన్నెల్ ఉపయోగించగల ప్యాకెట్ను ఎందుకు చిన్నదిగా చేస్తుంది

టన్నెల్ ఇంటర్ఫేస్ భౌతిక లింక్ MTUని ఉంచుకుంటే, ప్రతి పెద్ద ప్యాకెట్ కింద ఎవరైనా దాన్ని ఫ్రాగ్మెంట్ చేయడానికి సిద్ధంగా ఉండటంపై ఆధారపడి ఉంటుంది. IPv4 సూత్రప్రాయంగా దాన్ని అనుమతిస్తుంది, కానీ ఫ్రాగ్మెంట్ చేయవద్దని చెప్పిన రౌటర్ బదులుగా లోపాన్ని తిరిగి ఇస్తుంది. IPv6 రౌటర్లు ట్రాన్సిట్లో ఎప్పుడూ ఫ్రాగ్మెంట్ చేయవు, కాబట్టి అదే సెట్టింగ్ చిరునామా కుటుంబం ప్రకారం భిన్నంగా ప్రవర్తిస్తుంది. ఏదేమైనా, ఏదో తిరిగి నివేదించే వరకు పంపేవాడు ఏమీ నేర్చుకోడు.

ఆచరణాత్మక పరిణామం హ్యాండ్షేక్కు సరిపోయే కానీ పేలోడ్కు సరిపోని పరిమాణం. TLS ClientHello లేదా DNS క్వెరీ చిన్నదిగా మారిన మార్గాన్ని తాకకుండా దాటడానికి సరిపోయేంత చిన్నది, అయితే పెద్ద బదిలీ అలా కాదు. అందుకే లక్షణాలు నిర్దిష్ట హోస్ట్ల చుట్టూ కాదు, నిర్దిష్ట కార్యకలాపాల చుట్టూ గుమిగూడుతాయి.

ఫీడ్బ్యాక్ వచ్చినప్పుడే కనుగొనడం పని చేస్తుంది

IPv4 కనుగొనడం don't-fragment బిట్పై ఆధారపడి ఉంటుంది: ప్యాకెట్ను ముందుకు పంపలేని రౌటర్ తదుపరి హాప్ MTUతో ICMP fragmentation-neededని తిరిగి ఇస్తుంది, మరియు పంపేవాడు తన అంచనాను తగ్గిస్తాడు. IPv6 బదులుగా Packet Too Big సందేశాలను ఉపయోగిస్తుంది, ఎందుకంటే రౌటర్లు ట్రాన్సిట్లో ఫ్రాగ్మెంట్ చేయవు. రెండు యంత్రాంగాలు సందేశం పంపేవాడి వద్దకు తిరిగి వెళ్లే దారిని కనుగొంటుందని ఊహిస్తాయి, టన్నెల్ గుండా మరియు తిరిగి వెళ్లే మార్గంలో ఏదైనా ఫైర్వాల్ దాటి. ఆ ఊహ విఫలమైనప్పుడు, పంపేవాడు మార్గం మోయలేని పరిమాణాన్ని పదే పదే ప్రయత్నిస్తాడు.

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

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

సంఖ్యను ఊహించడం బదులు మార్గాన్ని పరీక్షించండి

గమ్యం, యాక్సెస్ నెట్వర్క్ మరియు టన్నెల్ను స్థిరంగా ఉంచి, ప్యాకెట్ పరిమాణాన్ని మాత్రమే మార్చండి. MTU సూచనతో విఫలమయ్యే don't-fragment పరీక్ష తదుపరి హాప్ పరిమితిని ఇస్తుంది; ఏదైనా పరిమాణం దాటే వరకు పునరావృతం చేయండి, మరియు పరిమాణం మరియు చిరునామా కుటుంబం రెండింటినీ నమోదు చేయండి.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

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

RFC 4821లో వివరించిన PLPMTUD పైకి పరీక్షిస్తుంది మరియు పంపిణీ చేయబడిన లోపాలను నమ్మడం బదులు రవాణా ధృవీకరణలను ఉపయోగిస్తుంది. ICMP ఫిల్టర్ చేసే మార్గాల్లో ఇది సహాయపడుతుంది, కానీ మద్దతు స్టాక్ మరియు అప్లికేషన్ ప్రకారం మారుతుంది. TCP ప్రవాహం తనంతట తానే కోలుకోవచ్చు, స్థిర డేటాగ్రామ్ పరిమాణంతో ఉన్న UDP అప్లికేషన్ విఫలమవుతూనే ఉంటుంది.

విలువను ఎంచుకోండి మరియు కారణాన్ని నమోదు చేయండి

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

IPv4 యంత్రాంగం RFC 1191 లో మరియు IPv6 ప్యాకెటైజేషన్ మార్గదర్శకం RFC 8201లో వివరించబడ్డాయి; రెండింటినీ పేర్కొనడం తదుపరి ఇంజనీర్ ఊహను మళ్లీ పొందకుండా నిరోధిస్తుంది. మీరు ఎంచుకున్న పరిమాణంలో బదిలీ ఇంకా ఆగిపోతే, సంఖ్యను తగ్గించడం ఆపి తదుపరి పొరను చూడండి. ప్రతి పరిమాణంలో విఫలమయ్యే మార్గం MTU సమస్య కాదు.