ඔබේ IPv6 ටනලයේ අනෙක් කෙළවරට ping කිරීම අසාර්ථකද? :: ලිපිනය පරීක්ෂා කරන්න
සියලුම ශුන්ය වන අතුරුමුහුණත් හඳුනාගැනීම subnet-router anycast වන අතර එය host එකක් නොවේ. ::1 සහ ::2 පවරන්න, prefix එක route කරන්න, සහ routes වලට දොස් පැවරීමට පෙර multicast පරීක්ෂා කරන්න.
ඔබේ IPv6 ටනලයේ එක් කෙළවරක් අනෙක් කෙළවරට ping කරන අතර පිළිතුරු දෙන්නේ එක් දිශාවක් පමණි. අතුරුමුහුණත සක්රීයයි, මාර්ගය නිවැරදි බව පෙනේ, සහ ලොගයේ කිසිවක් එය පැහැදිලි නොකරයි. ඔබ පවරා ඇති ලිපිනය subnet-router anycast ලිපිනය වන අතර එය කිසිසේත් host ලිපිනයක් නොවේ, සහ කෙළවර දෙකක් සහිත සබැඳියක එයට ඇත්තේ එකම බෙදාහැරීමේ ඉලක්කයක් පමණි: යවන්නා. කිසිදු කාල සීමා අගයකින් එය අලුත්වැඩියා නොවේ, මන්ද ලිපිනය ඔබ සිතන දෙය නොකරන බැවිනි.
ලිපිනය දෙසට යොමු කරන රෝග ලක්ෂණය
සබැඳියේ සිටින සෑම host එකක්ම පිළිතුරු දෙයි, නමුත් අතුරුමුහුණත් හඳුනාගැනීම සම්පූර්ණයෙන්ම ශුන්ය වන එක හැර. එම ආකෘතියට ලිපිනගත කරන ලද පැකට්ටුවක් අර්ථ දැක්වීම අනුව subnet එකේ router එකකට බෙදාහරිනු ලැබේ, එබැවින් point-to-point ටනලයක එය එය යැවූ යන්ත්රයටම ආපසු පැමිණේ. දුර කෙළවරින් මෙය ළඟා නොවන සහකරුවෙක් ලෙස කියවේ; ළඟ කෙළවරින් එය නිහඬතාවක් ලෙස කියවේ. එකම prefix එකේ වෙනත් හඳුනාගැනීමක් ආදේශ කරන්න, වෙනත් කිසිදු වෙනසක් නොමැතිව රෝග ලක්ෂණය අතුරුදහන් වේ, එය මාර්ග ස්පර්ශ කිරීමට පෙර ලබා ගත යුතු තහවුරු කිරීමයි.
සියලුම ශුන්ය හඳුනාගැනීම anycast ලෙස වෙන් කර ඇත
RFC 4291 සියලුම ශුන්ය අතුරුමුහුණත් හඳුනාගැනීම subnet-router anycast ලිපිනය ලෙස රඳවා ගනී, එබැවින් 2001:db8:4a::/64 වැනි /64 එකක 2001:db8:4a:: හි භාවිත කළ හැකි host එකක් නොමැත. මෙම වෙන් කිරීමට එහි තැන ලැබේ: router advertisements සහ neighbour discovery එම ආකෘතිය ඇමතීම කරන අතර router එකක් එය සේවය කරන prefix එක සඳහා පිළිතුරු දෙයි. එම අගය ටනල් කෙළවරකට පැවරීමෙන් router භූමිකාවක් පත්රයකට ලැබේ, එයම නිසා කිසිවක් ආපසු නොපැමිණේ. prefix එකේ වෙනත් ඕනෑම හඳුනාගැනීමක් host එකක් ලෙස ක්රියා කරයි, එබැවින් අලුත්වැඩියාව සාමාන්යයෙන් එක් අංකයකි.
ටනල් කෙළවරකින් ඔබට ගත නොහැකි භූමිකාවක් ලෙස වෙන් කිරීම සලකන්න, මාර්ගගත කිරීමෙන් මග හරවා යා යුතු විකාරයක් ලෙස නොව.
host ලිපින පවරා prefix එක route කරන්න
කෙළවර දෙක සඳහා ::1 සහ ::2 තෝරන්න, ip -6 addr add 2001:db8:4a::2/64 dev tun0 සමඟ එකක් එක් කරන්න, පසුව එය ලිපිනගත කිරීමට උත්සාහ කරනවා වෙනුවට දුර prefix එක route කරන්න. ටනලයෙන් පිටතට 2001:db8:4a::/64 සඳහා වන මාර්ගයක් දුර පැත්ත ළඟා කළ හැකි කරයි; ලිපිනය පමණක් දේශීය අතුරුමුහුණත වින්යාස කරයි.
සම්පූර්ණ ටනලයක් සඳහා තුන්වන පියවරක් ඇත, උපාංගය හරහා ගෝලීය unicast සඳහා පෙරනිමි මාර්ගය, එය සියල්ල ටනලයට යැවීමේ IPv6 සමානකමයි. එය මඟ හැරියොත්, IPv4 ටනලය තුළ ගමන් කරන අතරතුර IPv6 භෞතික සබැඳිය දිගටම භාවිත කරයි, එබැවින් host එක ආවරණය වී ඇතැයි ඔබ විශ්වාස කළ ගමනාගමනයම පිටව යයි. ip -6 route get 2001:4860:4860::8888 සමඟ තහවුරු කර එය නම් කරන උපාංගය කුමක්දැයි කියවන්න, පිළිතුර උපකල්පනය කරනවා වෙනුවට.
routing වලට පෙර multicast ප්රතික්ෂේප වේ
Android VpnService.Builder සඳහා ලිපින සහ මාර්ග LinkAddress හරහා වලංගු කරන අතර එම නිර්මාණකරු multicast සම්පූර්ණයෙන්ම ප්රතික්ෂේප කරයි. එයට මාර්ගයක් ලෙස multicast prefix එකක් දුන් විට ප්රතිඵලය මාර්ගයක් වෙනුවට bad LinkAddress parameters අසාර්ථකත්වයකි, එය ජාල පිළිතුරක් නොව වලංගුකරණ පිළිතුරකි. ප්රතික්ෂේපය මාධ්යයට ගැළපේ: point-to-point tun උපාංගයකට link-layer multicast නොමැත, එබැවින් එය මත කණ්ඩායම් මාර්ගයකට ස්ථාපනය කළ හැකි බෙදාහැරීමේ ආකෘතියක් නොමැත. කණ්ඩායම් ලිපින stack එක විසින්ම නිර්මාණය කර පරිභෝජනය කරයි, අතින් වින්යාස නොකෙරේ.
IPv6 all-nodes සහ solicited-node ලිපින එකම නියමය යටතේ වැටේ. stack එක ඒවා එහි තැබූ නිසා අතුරුමුහුණත ඒවා දරයි, ප්රතිපත්තියක් ඒවා අදහස් කළ නිසා නොවේ.
ඒ වෙනුවට ටනලයකට ගෙන යා හැකි දේ
multicast සොයාගැනීම ටනලයක් හරහා ගෙන යාමට කණ්ඩායම් සාමාජිකත්වය තේරුම් ගන්නා ස්ථරයක් අවශ්ය වේ: Ethernet කොටසක් ඉදිරිපත් කරන TAP පාලමක්, යෙදුම් මට්ටමේ relay එකක්, නැතහොත් කුමන සමකක්ෂවලට ප්රතිනිර්මාණය කළ යුතුදැයි පැහැදිලිව පවසන routing ප්රොටෝකෝලයක්. VpnService ආකෘතියේ ඒ කිසිවක් නොමැත, එහි යෙදුම පැකට් කියවා ලියන අතර ටනලය සඳහා කණ්ඩායමකට එකතු වන කිසිදු ඇමතුමක් නොමැත. කණ්ඩායම් තේරුම් ගන්නා සංරචකය එක් කරන්න, නැතහොත් සැලසුමෙන් අවශ්යතාව ඉවත් කරන්න.
ඊට වෙනස්ව, unicast ට ඉහත ලිපින සහ මාර්ග හැර අමතර කිසිවක් අවශ්ය නොවේ, එයම නිසා ටනල් සාමාන්යයෙන් එය ගෙන යා යුතු යැයි අපේක්ෂා කර, පසුව සොයාගැනීමේ ප්රොටෝකෝලයක් අසාර්ථක වූ විට දොස් පවරනු ලැබේ.
කිසිවක් පැවරීමට පෙර පරීක්ෂණ තුනක්
ලිපිනය anycast ආකෘතිය නොවන බව තහවුරු කරන්න, එය multicast නොවන බව තහවුරු කරන්න, සහ prefix එක උපාංගයට පමණක් පවරා ඇති බව නොව route කර ඇති බව තහවුරු කරන්න. ඉන්පසු ඔබේ පරීක්ෂණය සැබෑ host එකක් වන ගමනාන්තයකට යවන්න, මන්ද anycast ලිපිනයට එල්ල කරන ping එක යවන්නා මනින අතර මාර්ගය ගැන කිසිවක් නොකියයි. ඊළඟ යෙදවුම නැවත සොයා නොගැනීමට එම පරීක්ෂණ තුන වෙනස්කම් වාර්තාවේ සටහන් කරන්න.
වේදිකාව කිසිදා ස්ථාපනය නොකළ මාර්ගයක් වැඩි වේලාවක් බලා සිටීමෙන් නිරාකරණය කළ නොහැක, කිසිදා host එකක් නොවූ ලිපිනයක් වඩා හොඳ ping එකකින් අලුත්වැඩියා කළ නොහැක.