Пинг до отсрещната страна на IPv6 тунел се проваля? Проверете адреса ::

Единият край на вашия IPv6 тунел пингва другия и отговаря само една посока. Интерфейсът е активен, маршрутът изглежда правилен и нищо в журнала не го обяснява. Адресът, който сте задали, е 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 на канално ниво, така че групов маршрут върху него няма модел на доставяне, който да се инсталира. Груповите адреси се създават и консумират от самия стек, а не се конфигурират на ръка.

Адресите IPv6 all-nodes и solicited-node попадат под същото правило. Интерфейсът ги носи, защото стекът ги е сложил там, а не защото политика ги е предвидила.

Какво може да носи тунелът вместо това

За да преместите откриването на multicast през тунел , е нужен слой, който разбира груповото членство: TAP мост, който представя Ethernet сегмент, реле на приложно ниво или маршрутизиращ протокол, на който изрично е казано към кои партньори да репликира. Нищо от това не съществува в модела VpnService, където приложението чете и пише пакети и няма извикване, което да се присъедини към група за тунела. Или добавете компонента, който разбира групи, или откажете изискването от дизайна.

Unicast, за разлика от това, не изисква нищо допълнително извън адресите и маршрутите по-горе, затова обикновено се очаква тунелите да го носят и после те биват обвинявани, когато протокол за откриване се провали.

Три проверки, преди да зададете каквото и да е

Потвърдете, че адресът не е anycast формата, потвърдете, че не е multicast, и потвърдете, че префиксът е маршрутизиран, а не просто зададен на устройството. След това изпратете теста си до местоназначение, което е истински хост, защото пинг към anycast адреса измерва подателя и не казва нищо за пътя. Пазете тези три проверки в записа на промените, за да не ги преоткрива следващото внедряване.

Маршрут, който платформата никога не е инсталирала, не може да се отстрани с по-дълго чакане, а адрес, който никога не е бил хост, не може да се поправи с по-добър пинг.