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

ఆ సంఖ్య మరో టన్నెల్ నుండి వచ్చింది

ఓవర్హెడ్ అనేది అమూర్త అర్థంలో IPsec లక్షణం కాదు. అది నిజంగా నిర్మించబడే ప్యాకెట్ లక్షణం: అంగీకరించిన మోడ్, బయటి హెడర్, రక్షణ హెడర్, ప్యాడింగ్, సమగ్రతా క్షేత్రం మరియు బహుశా అదనపు UDP కవచం.

IPv4 తో మరియు NAT లేకుండా రవాణా మోడ్ కోసం చెప్పబడే సంఖ్య, NAT దాటుకునే క్రింద IPv6 ఉన్న టన్నెల్ మోడ్ కంటే చిన్న ప్యాకెట్ను వివరిస్తుంది. రెండూ తమ సందర్భానికి సరైనవి. వాటిలో ఒకదాన్ని మరో అమరికలోకి కాపీ చేయడమే పెద్ద బదిలీలను విరిచే MTU కి చేరుకునే మార్గం. చిన్న అభ్యర్థనలు పని చేస్తూనే ఉంటాయి కాబట్టి వైఫల్యం నిశ్శబ్దంగా ఉంటుంది.

నిజంగా ఉన్న పొరలను కలపండి

బయటి IP హెడర్ నుండి ప్రారంభించి లోపలికి వెళ్లండి. టన్నెల్ మోడ్లో అసలు ప్యాకెట్ లోపల ఉంటుంది, కాబట్టి బయటి హెడర్ భర్తీ కాదు, అదనం. RFC 4303 ESP హెడర్, ప్యాడింగ్ మరియు దాని తర్వాత వచ్చే సమగ్రతా డేటాను వివరిస్తుంది.

LayerWhat it addsWhen it applies
Outer IP header20 bytes for IPv4, 40 for IPv6Always, and 40 rather than 20 if the outer path is v6
ESP header8 bytes of SPI and sequence numberAlways
Block cipher IV8 to 16 bytes depending on the transformWhen the negotiated cipher uses one
Padding and trailerPadding to the block size, plus two trailer bytesAlways, and the amount varies with payload length
Integrity data12 to 16 bytes for common authenticated ciphersWhen integrity protection is negotiated
UDP encapsulation8 bytesNAT traversal on port 4500, which is common for clients behind NAT

ఆ వరుసల్లో ఏదీ అమరికల మధ్య స్థిరం కాదు, ప్యాడింగ్ వరుస ఒకే అమరిక లోపల కూడా స్థిరం కాదు. ప్రచురితమైన ఒకే ఓవర్హెడ్ సంఖ్య నిరాశపరచడానికి ఇదే పూర్తి కారణం.

ఒకే టన్నెల్ గురించి రెండు సైట్లు విభేదించవచ్చు

రక్షిత ప్యాకెట్ ఇంకా బయటి మార్గాన్ని దాటాలి, బయటి మార్గం అంతటా ఒకటే కాదు. PPPoE యాక్సెస్ లింక్ శుభ్రమైన Ethernet విభాగం కంటే తక్కువ మోస్తుంది. మొబైల్ నెట్వర్క్ మరింత కుంచించుకుపోవచ్చు, తన సొంత ట్రాఫిక్ను టన్నెల్ చేసే ప్రదాత ఎవరూ పేర్కొనని మరో ఎన్క్యాప్సులేషన్ను జోడిస్తాడు. ఒక లింక్పై పని చేసి మరో దానిపై విఫలమయ్యే టన్నెల్ రెండో లింక్ను వివరిస్తోంది, ప్రోటోకాల్ను కాదు.

రెండు దిశలు కూడా భిన్నంగా ఉండవచ్చు. అసమమితి మార్గం పని చేసే అప్లోడ్ మరియు ఆగిపోయిన డౌన్లోడ్ ఇవ్వవచ్చు, అది చేరుకోగలిగే సామర్థ్యానికి బదులు ప్యాకెట్ పరిమాణాలను చూసే వరకు అప్లికేషన్ సమస్యగా చదవబడుతుంది. చిన్న ping విజయవంతం కావడం పూర్తి పరిమాణ ప్రతిస్పందన గురించి చాలా తక్కువ నిరూపిస్తుంది.

తీసివేయడానికి బదులు కొలవండి

మార్గం గుండా దాటి మనుగడ సాగించే అతిపెద్ద డేటాగ్రామ్ను కనుగొనండి. తర్వాత ఇంటర్ఫేస్ నివేదించే విలువతో పోల్చండి:

ip link show eth0 | grep -o 'mtu [0-9]*'
ip xfrm state list
ping -M do -s 1400 198.51.100.7
ping -M do -s 1372 198.51.100.7
tcpdump -ni any -c 20 'esp or udp port 4500'

ప్రతిస్పందనలు వచ్చే వరకు ping పరిమాణాన్ని తగ్గించండి, పని చేసే అతిపెద్ద విలువను ఆ మార్గానికి బడ్జెట్గా తీసుకోండి. xfrm అవుట్పుట్ ఏ మోడ్ మరియు ఏ అల్గారిథమ్లు అంగీకరించబడ్డాయో చెబుతుంది, అదే ఏ నిజాయితీ లెక్కకైనా ఇన్పుట్. క్యాప్చర్ తీగపై ESP ఉందో లేదా UDP లో చుట్టబడిన ESP ఉందో నిర్ధారిస్తుంది, అది NAT ప్రశ్నను ఊహ లేకుండా పరిష్కరిస్తుంది.

నియంత్రణ తలానికి కూడా ఒక విలువను కేటాయించండి. IKE హ్యాండ్షేక్ ప్యాకెట్ల నిర్మాణం డేటా ప్యాకెట్లకు భిన్నం, కాబట్టి హ్యాండ్షేక్ క్యాప్చర్ నుండి పొందిన పరిమాణం డేటా తలం యొక్క MTU కాదు.

సంఖ్యను దాని స్థానంలో ఉంచండి

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

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

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