DNS పరిష్కరమవుతుంది, SSH సెషన్ కొనసాగుతుంది, ఆ తర్వాత పెద్ద అప్లోడ్ గడ్డకడుతుంది, అదే హోస్ట్కు ping ఇంకా సమాధానమిస్తుంది. ఆ విభజన విరిగిన టన్నెల్ వైపు కాదు, ప్యాకెట్ పరిమాణం వైపు సూచిస్తుంది. నెస్టెడ్ టన్నెల్లు ఏ ఒక్క టన్నెల్ ఒంటరిగా చేరుకోలేని పరిమాణాలలో దాన్ని చేరుకుంటాయి. లోపలి సెషన్ బాగానే ఉంది; ఇకపై సరిపోని ప్యాకెట్లే దానికి ఇవ్వబడుతున్నాయి.

మార్గపు MTU నిజానికి ఎక్కడికి వెళ్తుంది

ప్రతి ఎన్క్యాప్సులేషన్ తదుపరి పొర వంతు రాకముందే బైట్లను ఖర్చు చేస్తుంది. Ethernet మార్గం బయటి ప్యాకెట్కు 1500 బైట్లు ఇస్తుంది, బయటి టన్నెల్ తన లోపల ఏదీ చిరునామా పొందకముందే తన వాటాను తీసుకుంటుంది. ఊహించిన ఒక ఓవర్హెడ్ విలువ ముఖ్యమైనంత మేరకు తప్పుగా ఉంటుంది.

పొరలను క్రమంగా జాబితా చేయండి: యాక్సెస్ మార్గం, బయటి రవాణా, బయటి టన్నెల్, లోపలి రవాణా, లోపలి టన్నెల్, అప్లికేషన్. ప్రతి హెడర్ను ఒకసారి లెక్కించండి, UDPను టన్నెల్ సొంత హెడర్ మరియు ట్యాగ్ నుండి వేరుగా ఉంచండి.

రెండు WireGuard పొరలు, ఒకసారి లెక్కించబడ్డాయి

ఒక IPv4 యాక్సెస్ మార్గం తీసుకోండి, దాని లోపల మరో WireGuard టన్నెల్ ఉంది. బయటి పొర 20 బైట్ల IPv4, 8 బైట్ల UDP మరియు WireGuard డేటా హెడర్ తో పాటు దాని ప్రామాణీకరణ ట్యాగ్ కోసం 32 బైట్లు ఖర్చు చేస్తుంది. దాని లోపల, లోపలి టన్నెల్కు దాని రెండో 32 బైట్ల WireGuard ఓవర్హెడ్ ముందు సొంత 20 బైట్ల IPv4 హెడర్ మరియు 8 బైట్ల UDP హెడర్ అవసరం. మిగిలినవి IPv4 హెడర్, TCP హెడర్ మరియు డేటాను ఉంచుతాయి. బయటి మార్గం IPv6 అయితే 20కి బదులు 40 ఖర్చు చేసి 1320 మిగులుతుంది.

LayerBytes
Path MTU1500
Outer IPv4 header20
Outer UDP header8
Outer WireGuard header and tag32
Inner transport IPv4 header20
Inner UDP header8
Inner WireGuard header and tag32
Innermost IPv4 header20
TCP header20
Payload that fits1340

లెక్కింపు 1340 బైట్ల వద్ద ముగుస్తుంది. అదే నియమాలతో ఒక పొర TCP పేలోడ్కు 1400 మిగులుస్తుంది, అంటే 1500 నుండి 20, 8, 32, 20 మరియు 20 తీసివేసిన తర్వాత, 60 బైట్ల వ్యత్యాసం రెండో టన్నెల్ జోడించే అదే లోపలి ఎన్క్యాప్సులేషన్.

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

MTU, MSS మరియు ఫ్రాగ్మెంటేషన్ వేర్వేరు చోట్ల పనిచేస్తాయి

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

వంతెన మరియు మార్గనిర్దేశిత టన్నెల్లు వేర్వేరు ఫ్రేమ్లను మోసుకెళ్తాయి, కాబట్టి మరో అమరిక నుండి సంఖ్యలు అరుదుగా బదిలీ అవుతాయి. మార్గ MTU ఆవిష్కరణ, అది వివరించబడింది RFC 8201 లో, అది ఆధారపడే ICMP సందేశాలు దాటడానికి అనుమతించబడినంత కాలం మాత్రమే సహాయపడుతుంది.

తక్కువగా ఉన్న పొరను కనుగొనడం

అవసరాలు పోలికను అనుమతిస్తే, నెస్ట్ చేయకముందు ప్రతి టన్నెల్ను విడివిడిగా ధృవీకరించండి. స్థిర పరిమాణ ప్రోబ్ దాన్ని నిర్ణయిస్తుంది: ping -M do -s 1472 -c 3 10.8.0.1 ఆ పొర లోపల పూర్తి 1500 బైట్ల IPv4 ప్యాకెట్ను పంపుతుంది. రెండో పొరను జోడించి అదే ప్రోబ్ను పునరావృతం చేయండి, దాంతో ఏ వైఫల్యమైనా తెలిసిన మార్పుకే చెందుతుంది.

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

తదుపరి వ్యక్తి కనుగొనే చోట బడ్జెట్ను రాయండి

ప్రతి పొరకు ఒక వరుస ఉన్న పట్టిక బొటనవేలు నియమం కంటే ఎక్కువ కాలం నిలుస్తుంది. దాన్ని టన్నెల్ రేఖాచిత్రం పక్కన ఉంచండి, ఒత్తిడిలో ఎవరూ లెక్కను మళ్లీ చేయకుండా.

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

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