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

ప్రతి కుటుంబం ఏమి చేస్తుంది

పట్టిక నాలుగు పంక్తులలోని యంత్రాంగం, ఒక వరుస చాలా గందరగోళాన్ని వివరిస్తుంది.

BehaviourIPv4IPv6
Router fragments an oversized packetAllowed while DF is clearNever
Signal returned to the senderICMP Fragmentation NeededICMPv6 Packet Too Big
Size that must always work68 bytes1280 bytes
Fragmentation possibleRouters or sourceSource only

IPv6 లో ప్రయాణ తునకలు లేవు మరియు తొలగించాల్సిన DF జెండా కూడా లేదు, కాబట్టి ప్యాకెట్ చాలా పెద్దగా ఉన్నప్పుడు ఆధారపడటానికి ఏమీ లేదు. పంపినవారికి చెప్పాలి, పంపినవారు దాన్ని నమ్మాలి.

సొరంగం మార్గాన్ని నిశ్శబ్దంగా సన్నంగా చేస్తుంది

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

ESP ఓవర్హెడ్ మోడ్ మరియు అల్గోరిథంలపై ఆధారపడి ఉంటుంది, కాబట్టి సరైన సొరంగ MTU ఒక లెక్క, ఆచారం కాదు. మీరు ఏది ఎంచుకున్నా, పూర్తి 1280 బైట్ల లోపలి IPv6 ప్యాకెట్కు స్థలం విడిచిపెట్టాలి, ఎందుకంటే ప్రతి IPv6 లింక్ అంత మోసుకెళ్లాలి. 1280 బైట్ల IPv6 మోసుకెళ్లలేని సొరంగం ట్యూనింగ్ సమస్య కాదు; అది ఆ కుటుంబానికి విరిగిన మార్గం. IPv4 మాత్రమే ఉన్న అమరిక నుండి MTU విలువ కాపీ చేయబడినప్పుడు మాయమయ్యేది ఈ పరిమితే.

లక్షణం ఎందుకు నిలిచిపోవడంగా కనిపిస్తుంది

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

ICMPv6 పెద్ద ప్యాకెట్ సందేశాలు ఫిల్టర్ చేయబడితే, పంపినవారికి ఎప్పటికీ తెలియదు మరియు అదే పరిమాణాన్ని పునరావృతం చేస్తారు. అది నల్ల రంధ్రం, నెమ్మదైన మార్గం కాదు, దాని గుర్తు యాదృచ్ఛిక నష్టం కాదు, పునరావృతమయ్యే పరిమాణ హద్దు. సంబంధిత నియంత్రణ ట్రాఫిక్ను అనుమతించడం పనిచేసే IPv6 అమరికలో భాగం, ఉపకారం కాదు.

మీ స్వంత మార్గం ఆధారపడే సందేశాలను ఆఫ్ చేసి తర్వాత ఫలితాన్ని IPv6 లోపంగా వర్ణించకండి. అదే వాదన IPv4 యొక్క Fragmentation Needed సందేశాలకూ వర్తిస్తుంది, అవి ఫైర్వాల్ రచయితలలో సమానంగా జనప్రియం కావు మరియు సమానంగా అవసరం.

హద్దును కొలవండి, తర్వాత పొరను సరిచేయండి

ఊహించకుండా తనిఖీ చేయండి: IPv4 లో don't-fragment జెండా, IPv6 లో స్థిర పేలోడ్ పరిమాణాలు ఉపయోగించి, ప్రతిస్పందనలు ఎక్కడ ఆగుతాయో నమోదు చేయండి. ping -M do -s 1472 మరియు ping -6 -s 1400 సమస్య ఆకారాన్ని నిర్ణయించడానికి సరిపోతాయి, మరియు tracepath మార్గంలో కనుగొన్న మార్గ MTU ను నివేదిస్తుంది.

తర్వాత ఆ సంఖ్యను కలిగి ఉన్న పొరను సరిచేయండి: సొరంగ ఇంటర్ఫేస్ MTU, TCP కోసం MSS బిగింపు, లేదా మార్గమే. IPv6 నియమానికి RFC 8200 సూచన, అది నివారించే సంఘటన కంటే చిన్న పఠనం.

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

పరిమాణ హద్దును సాక్ష్యంగా పరిగణించండి

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

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

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