Nabigo ang ping sa kabilang dulo ng iyong IPv6 tunnel? Suriin ang adres ::

Ang isang dulo ng iyong IPv6 tunnel ay nagpi-ping sa kabila, at isang direksyon lang ang sumasagot. Nakataas ang interface, mukhang tama ang ruta, at walang ipinaliwanag sa log. Ang adres na itinalaga mo ay ang subnet-router anycast address, na hindi talaga host address, at sa link na may dalawang dulo mayroon itong eksaktong isang target ng paghahatid: ang nagpadala. Walang halaga ng timeout ang makakapag-ayos niyan, dahil hindi ginagawa ng adres ang inaakala mong ginagawa nito.

Ang sintomas na tumuturo sa adres

Sumasagot ang bawat host sa link maliban sa isa na ang interface identifier ay puro zero. Ang packet na naka-address sa ganoong anyo ay inihahatid sa isang router sa subnet ayon sa depinisyon, kaya sa point-to-point tunnel bumabalik ito sa makina na nagpadala nito. Mula sa malayong dulo ito ay binabasang isang peer na hindi maabot; mula sa malapit na dulo binabasang katahimikan. Palitan ng ibang identifier mula sa parehong prefix at mawawala ang sintomas nang walang ibang pagbabago, at iyon ang kumpirmasyong dapat makuha bago hawakan ang mga ruta.

Ang identifier na puro zero ay nakalaan bilang anycast

Pinapanatili ng RFC 4291 ang interface identifier na puro zero bilang subnet-router anycast address, kaya ang isang /64 tulad ng 2001:db8:4a::/64 ay walang magagamit na host sa 2001:db8:4a::. May saysay ang reserbasyong ito: ang router advertisements at neighbour discovery ay tumutungo sa ganoong anyo at sumasagot ang router para sa prefix na pinaglilingkuran nito. Ang pagtatalaga ng halagang iyon sa dulo ng tunnel ay nagbibigay ng papel na router sa isang dahon, at iyon ang dahilan kung bakit walang bumabalik. Gumagana bilang host ang anumang ibang identifier sa prefix, kaya kadalasan isang digit lang ang pag-aayos.

Ituring ang reserbasyon bilang papel na wala kang karapatang kunin mula sa dulo ng tunnel, hindi bilang kakaibang dapat iwasan sa ruta.

Italaga ang host address at iruta ang prefix

Piliin ang ::1 at ::2 para sa dalawang dulo, magdagdag ng isa gamit ang ip -6 addr add 2001:db8:4a::2/64 dev tun0, at pagkatapos ay iruta ang malayong prefix sa halip na subukang bigyan ito ng adres. Ang rutang para sa 2001:db8:4a::/64 palabas ng tunnel ang nagpapabukas sa malayong panig; ang adres lang ang nagko-configure ng lokal na interface.

Para sa buong tunnel may ikatlong hakbang, isang default route para sa global unicast sa pamamagitan ng device, na katumbas ng IPv6 ng pagpapadala ng lahat papasok sa tunnel. Kapag nilaktawan ito, patuloy na ginagamit ng IPv6 ang pisikal na link habang ang IPv4 ay naglalakbay sa loob ng tunnel, kaya tumutulo ang host ng eksaktong trapikong inaakala mong sakop. Kumpirmahin gamit ang ip -6 route get 2001:4860:4860::8888 at basahin kung aling device ang sinasabi nito sa halip na hulaan ang sagot.

Tinatanggihan ang multicast bago ang routing

Binabalidate ng Android ang mga address at ruta para sa VpnService.Builder sa pamamagitan ng LinkAddress, at tahasang tinatanggihan ng constructor na iyon ang multicast. Bigyan ito ng multicast prefix bilang ruta at ang resulta ay isang bad LinkAddress parameters na pagpalya sa halip na ruta, na sagot ng balidasyon at hindi sagot ng network. Tumutugma ang pagtanggi sa midyum: ang point-to-point tun device ay walang link-layer multicast, kaya ang rutang pangkat dito ay walang modelong paghahatid na maiinstall. Ang mga address ng pangkat ay nililikha at ginagamit ng stack mismo sa halip na i-configure nang manu-mano.

Ang IPv6 all-nodes at solicited-node address ay nasa ilalim ng parehong tuntunin. Dinadala sila ng interface dahil inilagay sila ng stack doon, hindi dahil sinadya sila ng anumang patakaran.

Ano ang maaaring dalhin ng tunnel sa halip

Ang paglipat ng multicast discovery sa isang tunnel ay nangangailangan ng layer na nakakaunawa ng pagiging miyembro ng pangkat: isang TAP bridge na nagpapakita ng Ethernet segment, isang relay sa antas ng aplikasyon, o isang routing protocol na tahasang sinabihan kung aling mga peer ang kokopyahan. Wala sa mga iyon sa modelong VpnService, kung saan binabasa at sinusulatan ng aplikasyon ang mga packet at walang tawag na sumasali sa isang pangkat para sa tunnel. Magdagdag ng component na nakakaunawa sa mga pangkat o alisin ang pangangailangan sa disenyo.

Sa kabilang banda, ang unicast ay walang kailangan pang idagdag sa mga address at ruta sa itaas, kaya inaasahang dinadala ito ng tunnel at pagkatapos ay sinisisi kapag nabigo ang isang protocol ng discovery.

Tatlong pagsusuri bago magtalaga ng kahit ano

Kumpirmahin na ang adres ay hindi anycast na anyo, kumpirmahin na hindi ito multicast, at kumpirmahin na ang prefix ay niruta at hindi lang itinalaga sa device. Pagkatapos ay ipadala ang iyong pagsubok sa isang destinasyong tunay na host, dahil ang ping na nakatutok sa anycast address ay sumusukat sa nagpadala at walang sinasabi tungkol sa ruta. Isulat ang tatlong pagsusuring iyon sa talaan ng pagbabago upang hindi na muling matuklasan ng susunod na deployment.

Ang rutang hindi kailanman iniinstall ng platform ay hindi maaayos sa mas mahabang paghihintay, at ang adres na kailanman ay hindi naging host ay hindi maaayos ng mas mahusay na ping.