Ping-от до партнерот на 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 и дека префиксот е рутиран, а не само доделен на уредот. Потоа испратете го тестот до дестинација што е вистински домаќин, зашто ping-от насочен кон anycast адресата го мери испраќачот и не кажува ништо за патеката. Чувајте ги тие три проверки во записот за промени, за да не ги открие повторно следното распоредување.

Рута што платформата никогаш не ја инсталирала не може да се дебагира со подолго чекање, а адреса што никогаш не била домаќин не може да се поправи со подобар ping.