మీ IPv6 టన్నెల్ మరొక వైపుకు ping విఫలమవుతోందా? :: చిరునామాను తనిఖీ చేయండి

మీ IPv6 టన్నెల్ ఒక చివర మరొక చివరకు ping పంపుతుంది, సమాధానం ఇచ్చేది ఒక దిశ మాత్రమే. ఇంటర్‌ఫేస్ పనిచేస్తోంది, రూట్ సరిగ్గా కనిపిస్తోంది, లాగ్‌లో ఏదీ దానిని వివరించడం లేదు. మీరు కేటాయించిన చిరునామా subnet-router anycast చిరునామా, అది హోస్ట్ చిరునామా కాదు, రెండు చివరల లింక్‌పై దానికి సరిగ్గా ఒకే డెలివరీ లక్ష్యం ఉంటుంది: పంపినవారు. ఏ టైమౌట్ విలువా దానిని సరిచేయదు, ఎందుకంటే చిరునామా మీరు అనుకున్న పని చేయడం లేదు.

చిరునామా వైపు చూపించే లక్షణం

లింక్‌పై ఉన్న ప్రతి హోస్ట్ సమాధానం ఇస్తుంది, ఇంటర్‌ఫేస్ ఐడెంటిఫైయర్ పూర్తిగా సున్నాలుగా ఉన్న దానిని తప్ప. ఆ రూపానికి చిరునామా చేయబడిన ప్యాకెట్ నిర్వచనం ప్రకారం subnet లోని రౌటర్‌కు డెలివరీ అవుతుంది, కాబట్టి పాయింట్-టు-పాయింట్ టన్నెల్‌లో అది పంపిన యంత్రానికే తిరిగి వస్తుంది. దూరపు చివర నుండి ఇది చేరుకోలేని భాగస్వామిగా చదవబడుతుంది; దగ్గరి చివర నుండి నిశ్శబ్దంగా చదవబడుతుంది. అదే ప్రిఫిక్స్ నుండి వేరే ఐడెంటిఫైయర్‌ను మార్చండి, మరే మార్పు లేకుండా లక్షణం మాయమవుతుంది, అదే రూట్లను తాకే ముందు పొందవలసిన నిర్ధారణ.

పూర్తి సున్నాల ఐడెంటిఫైయర్ anycast కోసం కేటాయించబడింది

RFC 4291 పూర్తి సున్నాల ఇంటర్‌ఫేస్ ఐడెంటిఫైయర్‌ను subnet-router anycast చిరునామాగా ఉంచుతుంది, కాబట్టి 2001:db8:4a::/64 వంటి /64 లో 2001:db8:4a:: వద్ద ఉపయోగించగల హోస్ట్ ఏదీ లేదు. ఈ కేటాయింపుకు దాని స్థానం ఉంది: router advertisements మరియు neighbour discovery ఆ రూపాన్ని సంబోధిస్తాయి, రౌటర్ తాను సేవించే ప్రిఫిక్స్ కోసం సమాధానం ఇస్తుంది. ఆ విలువను టన్నెల్ చివరకు కేటాయించడం రౌటర్ పాత్రను ఒక ఆకుకు అప్పగిస్తుంది, అందుకే ఏదీ తిరిగి రాదు. ప్రిఫిక్స్‌లోని మరే ఇతర ఐడెంటిఫైయర్ అయినా హోస్ట్‌గా పనిచేస్తుంది, కాబట్టి మరమ్మతు సాధారణంగా ఒక అంకె.

టన్నెల్ చివర నుండి మీరు తీసుకోవడానికి అర్హత లేని పాత్రగా ఈ కేటాయింపును చూడండి, రూటింగ్‌తో దాటవేయాల్సిన వింతగా కాదు.

హోస్ట్ చిరునామాలను కేటాయించి ప్రిఫిక్స్‌ను రూట్ చేయండి

రెండు చివరలకు ::1 మరియు ::2 ఎంచుకోండి, ip -6 addr add 2001:db8:4a::2/64 dev tun0 తో ఒకటి జోడించి, ఆపై దానికి చిరునామా ఇవ్వడానికి ప్రయత్నించడం బదులు దూరపు ప్రిఫిక్స్‌ను రూట్ చేయండి. టన్నెల్ నుండి బయటకు 2001:db8:4a::/64 కోసం రూట్ దూరపు వైపును చేరుకోగలిగేలా చేస్తుంది; చిరునామా మాత్రమే స్థానిక ఇంటర్‌ఫేస్‌ను కాన్ఫిగర్ చేస్తుంది.

పూర్తి టన్నెల్ కోసం మూడవ దశ ఉంది, పరికరం ద్వారా గ్లోబల్ unicast కోసం డిఫాల్ట్ రూట్, అది ప్రతిదీ టన్నెల్‌లోకి పంపడానికి IPv6 సమానం. దానిని దాటవేస్తే, IPv4 టన్నెల్ లోపల ప్రయాణిస్తుండగా IPv6 భౌతిక లింక్‌ను ఉపయోగించడం కొనసాగిస్తుంది, కాబట్టి హోస్ట్ మీరు కవర్ అయిందని నమ్మిన ట్రాఫిక్‌ను సరిగ్గా లీక్ చేస్తుంది. ip -6 route get 2001:4860:4860::8888 తో నిర్ధారించి, సమాధానాన్ని ఊహించడం బదులు అది పేర్కొనే పరికరాన్ని చదవండి.

రూటింగ్‌కు ముందే multicast నిరాకరించబడుతుంది

Android VpnService.Builder కోసం చిరునామాలు మరియు రూట్లను LinkAddress ద్వారా ధృవీకరిస్తుంది, ఆ కన్‌స్ట్రక్టర్ multicast ను పూర్తిగా నిరాకరిస్తుంది. దానికి రూట్‌గా multicast ప్రిఫిక్స్ ఇస్తే ఫలితం రూట్ బదులు bad LinkAddress parameters వైఫల్యం, అది నెట్‌వర్క్ సమాధానం కాదు, ధృవీకరణ సమాధానం. నిరాకరణ మాధ్యమానికి సరిపోతుంది: పాయింట్-టు-పాయింట్ tun పరికరానికి link-layer multicast లేదు, కాబట్టి దానిపై గ్రూప్ రూట్‌కు ఇన్‌స్టాల్ చేయగల డెలివరీ నమూనా లేదు. గ్రూప్ చిరునామాలు stack ద్వారానే సృష్టించబడి వినియోగించబడతాయి, చేతితో కాన్ఫిగర్ చేయబడవు.

IPv6 all-nodes మరియు solicited-node చిరునామాలు అదే నియమం కిందకు వస్తాయి. stack వాటిని అక్కడ ఉంచినందున ఇంటర్‌ఫేస్ వాటిని మోస్తుంది, ఏదైనా విధానం వాటిని ఉద్దేశించినందున కాదు.

బదులుగా టన్నెల్ ఏమి మోయగలదు

multicast డిస్కవరీని టన్నెల్ ద్వారా తరలించడానికి గ్రూప్ సభ్యత్వాన్ని అర్థం చేసుకునే పొర అవసరం: Ethernet విభాగాన్ని అందించే TAP వంతెన, అప్లికేషన్ స్థాయి relay, లేదా ఏ భాగస్వాములకు ప్రతిరూపం చేయాలో స్పష్టంగా చెప్పబడే రూటింగ్ ప్రోటోకాల్. VpnService నమూనాలో అవేవీ లేవు, అక్కడ అప్లికేషన్ ప్యాకెట్లను చదివి రాస్తుంది, టన్నెల్ కోసం గ్రూప్‌లో చేరే కాల్ ఏదీ లేదు. గ్రూపులను అర్థం చేసుకునే భాగాన్ని జోడించండి, లేదా డిజైన్ నుండి అవసరాన్ని తీసివేయండి.

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

ఏదైనా కేటాయించే ముందు మూడు తనిఖీలు

చిరునామా anycast రూపం కాదని నిర్ధారించండి, అది multicast కాదని నిర్ధారించండి, ప్రిఫిక్స్ పరికరానికి కేటాయించబడటమే కాదు రూట్ చేయబడిందని కూడా నిర్ధారించండి. ఆపై మీ పరీక్షను నిజమైన హోస్ట్ అయిన గమ్యానికి పంపండి, ఎందుకంటే anycast చిరునామా వైపు సారించిన ping పంపినవారిని కొలుస్తుంది, మార్గం గురించి ఏమీ చెప్పదు. తదుపరి డిప్లాయ్‌మెంట్ మళ్లీ కనుగొనకుండా ఆ మూడు తనిఖీలను మార్పు రికార్డులో రాయండి.

ప్లాట్‌ఫారమ్ ఎప్పుడూ ఇన్‌స్టాల్ చేయని రూట్‌ను ఎక్కువసేపు వేచి ఉండటం ద్వారా పరిష్కరించలేము, ఎప్పుడూ హోస్ట్ కాని చిరునామాను మెరుగైన ping తో సరిచేయలేము.