IPv6 թունելի զույգին ping-ը ձախողվում է։ Ստուգեք :: հասցեն

Ձեր IPv6 թունելի մի ծայրը ping է ուղարկում մյուսին, և միշտ պատասխանում է միայն մեկ ուղղություն։ Ինտերֆեյսը միացված է, երթուղին ճիշտ է թվում, և ոչինչ մատյանում չի բացատրում դա։ Ձեր նշանակած հասցեն ենթացանցի երթուղիչի anycast հասցեն է, որը բոլորովին հոսթի հասցե չէ, և երկու ծայր ունեցող կապում այն ունի ուղիղ մեկ առաքման թիրախ՝ ուղարկողը։ Ժամանակաչափի ոչ մի արժեք չի ուղղում դա, որովհետև հասցեն չի անում այն, ինչ դուք կարծում եք։

Ախտանիշը, որը մատնանշում է հասցեն

Կապի վրա ամեն հոսթ պատասխանում է, բացի նրանից, ում ինտերֆեյսի նույնացուցիչը բոլորը զրո են։ Այդ ձևին հասցեավորված փաթեթը ըստ սահմանման առաքվում է ենթացանցի երթուղիչին, ուստի կետ-կետ թունելում այն վերադառնում է այն մեքենային, որն ուղարկել է։ Հեռու ծայրից դա կարդացվում է որպես անհասանելի զույգ, մոտիկ ծայրից՝ որպես լռություն։ Փոխարինեք նույն նախածանցի այլ նույնացուցիչով, և ախտանիշը անհետանում է առանց որևէ այլ փոփոխության, և սա այն հաստատումն է, որը պետք է ստանալ նախքան երթուղիներին դիպչելը։

Բոլոր զրոներից բաղկացած նույնացուցիչը վերապահված է որպես anycast

RFC 4291-ը պահում է բոլոր զրոներից բաղկացած ինտերֆեյսի նույնացուցիչը որպես ենթացանցի երթուղիչի anycast հասցե, ուստի /64-ը, ինչպիսին է 2001:db8:4a::/64 չի պարունակում ոչ մի օգտագործելի հոսթ հասցեում՝ 2001:db8:4a::։ Վերապահումը արժանի է իր տեղին. երթուղիչի հայտարարությունները և հարևանների հայտնաբերումը հասցեավորում են այդ ձևը, և երթուղիչը պատասխանում է իր սպասարկած նախածանցի համար։ Այդ արժեքը թունելի ծայրին նշանակելը տերևին տալիս է երթուղիչի դեր, և դրա համար ոչինչ չի վերադառնում։ Նախածանցի ցանկացած այլ նույնացուցիչ աշխատում է որպես հոսթ, ուստի ուղղումը սովորաբար մեկ թվանշան է։

Վերապահմանը վերաբերվեք որպես դերի, որը թունելի ծայրից զբաղեցնելու իրավունք չունեք, այլ ոչ թե որպես քմահաճույքի, որը կարելի է շրջանցել երթուղով։

Նշանակեք հոսթի հասցեներ և երթուղավորեք նախածանցը

Ընտրեք ::1 և ::2 երկու ծայրերի համար, ավելացրեք մեկը ip -6 addr add 2001:db8:4a::2/64 dev tun0-ով, ապա երթուղավորեք հեռավոր նախածանցը՝ փոխարենը փորձելով հասցեավորել այն։ 2001:db8:4a::/64 -ի համար թունելով դուրս եկող երթուղին հեռավոր կողմը դարձնում է հասանելի, հասցեն ինքնին միայն տեղական ինտերֆեյսն է կարգավորում։

Լրիվ թունելի համար կա երրորդ քայլ՝ սարքի միջով գլոբալ unicast-ի համար կանխադրված երթուղի, ինչը IPv6-ում համարժեք է ամեն ինչ թունել ուղարկելուն։ Եթե բաց թողնեք այն, IPv6-ը շարունակում է օգտագործել ֆիզիկական կապը, մինչ IPv4-ը ճամփորդում է թունելի ներսում, ուստի հոսթը արտահոսում է հենց այն տրաֆիկը, որը դուք կարծում էիք ծածկված։ Հաստատեք ip -6 route get 2001:4860:4860::8888 -ով և կարդացեք, թե որ սարքն է նշում, փոխարենը ենթադրելու պատասխանը։

multicast-ը մերժվում է երթուղավորումից առաջ

Android-ը վավերացնում է VpnService.Builder -ի հասցեներն ու երթուղիները LinkAddress-ի միջոցով, և այդ կոնստրուկտորը multicast-ը մերժում է ուղղակիորեն։ Եթե որպես երթուղի տաք նրան multicast նախածանց, արդյունքը կլինի ոչ թե երթուղի, այլ վատ LinkAddress պարամետրերի ձախողում, ինչը վավերացման պատասխան է, ոչ թե ցանցի։ Մերժումը համապատասխանում է միջավայրին. կետ-կետ tun սարքը չունի կապող շերտի multicast, ուստի դրա վրա խմբային երթուղին առաքման մոդել չունի տեղադրելու։ Խմբային հասցեները ստեղծում և սպառում է ինքը՝ stack-ը, այլ ոչ թե ձեռքով կարգավորվում։

IPv6 all-nodes և solicited-node հասցեները ընկնում են նույն կանոնի տակ։ Ինտերֆեյսը կրում է դրանք, որովհետև stack-ը դրել է դրանք այնտեղ, ոչ թե որևէ քաղաքականություն է նախատեսել։

Ինչ կարող է թունելը կրել փոխարենը

multicast-ի հայտնաբերումը թունելով տեղափոխելու համար պետք է շերտ, որը հասկանում է խմբային անդամակցությունը. TAP կամուրջ, որը ներկայացնում է Ethernet հատված, հավելվածի մակարդակի ռելե կամ երթուղավորման արձանագրություն, որին հստակ ասված է, թե որ զույգերին կրկնօրինակել։ Այս ամենը չկա VpnService մոդելում, որտեղ հավելվածը կարդում և գրում է փաթեթներ և չունի կանչ, որը խմբին միանա թունելի համար։ Կամ ավելացրեք խմբերը հասկացող բաղադրիչը, կամ հանեք պահանջը նախագծից։

unicast-ը, ընդհակառակը, ոչինչ ավելորդ չի պահանջում վերևի հասցեներից և երթուղիներից բացի, դրա համար էլ սովորաբար սպասում են, որ թունելները կրեն այն, և հետո մեղադրում են նրանց, երբ հայտնաբերման արձանագրությունը ձախողվում է։

Երեք ստուգում նախքան ինչ-որ բան նշանակելը

Համոզվեք, որ հասցեն anycast ձևը չէ, որ այն multicast չէ, և որ նախածանցը երթուղավորված է, ոչ թե պարզապես նշանակված սարքին։ Ապա ուղարկեք ձեր թեստը մի նպատակակետի, որը իրական հոսթ է, որովհետև anycast հասցեին ուղղված ping-ը չափում է ուղարկողին և ոչինչ չի ասում ուղու մասին։ Պահեք այդ երեք ստուգումները փոփոխությունների գրառման մեջ, որպեսզի հաջորդ տեղակայումը նորից չհայտնաբերի դրանք։

Երթուղին, որը հարթակը երբեք չի տեղադրել, հնարավոր չէ վրիպազերծել ավելի երկար սպասելով, և հասցեն, որը երբեք հոսթ չի եղել, հնարավոր չէ վերանորոգել ավելի լավ ping-ով։