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, а не маршрут, гэта адказ праверкі, а не сеткі. Адмова адпавядае асяроддзю: тунельная прылада пункт-пункт не мае multicast на канальным узроўні, таму групавы маршрут на ёй не мае мадэлі дастаўкі, якую можна ўсталяваць. Групавыя адрасы стварае і спажывае сам стэк, а не наладжвае іх рукамі.

Адрасы IPv6 all-nodes і solicited-node падпадаюць пад тое ж правіла. Інтэрфейс нясе іх, бо стэк паклаў іх туды, а не таму што палітыка іх мела на ўвазе.

Што тунель можа несці замест гэтага

Каб перанесці выяўленне multicast праз тунель , патрэбен узровень, які разумее членства ў групах: мост TAP, які прадстаўляе сегмент Ethernet, рэтранслятар на ўзроўні праграмы або пратакол маршрутызацыі, якому яўна сказана, якім суседзям рэплікаваць. Нічога з гэтага не існуе ў мадэлі VpnService, дзе праграма чытае і піша пакеты і не мае выкліку, які далучаецца да групы для тунеля. Або дадайце кампанент, які разумее групы, або адмоўцеся ад патрабавання ў дызайне.

Unicast, наадварот, не патрабуе нічога звыш адрасоў і маршрутаў вышэй, таму ад тунеляў звычайна чакаюць, што яны яго панясуць, а потым вінавацяць іх, калі пратакол выяўлення збаіць.

Тры праверкі, перш чым нешта прызначаць

Пераканайцеся, што адрас не anycast-формы, што ён не multicast і што прэфікс маршрутызаваны, а не проста прызначаны прыладзе. Затым адпраўце свой тэст на прызначэнне, якое з'яўляецца сапраўдным хостам, бо ping, накіраваны на anycast-адрас, вымярае адпраўніка і нічога не кажа пра шлях. Трымайце гэтыя тры праверкі ў запісе змен, каб наступнае разгортванне не адкрывала іх зноў.

Маршрут, які платформа не ўсталявала, нельга адладзіць чаканнем даўжэй, а адрас, які ніколі не быў хостам, нельга выправіць лепшым ping.