Ping na jou IPv6-tonnelmaat misluk? Kyk na die ::-adres

Een kant van jou IPv6-tonnel ping die ander, en net een rigting antwoord ooit. Die koppelvlak is op, die roete lyk reg, en niks in die logboek verduidelik dit nie. Die adres wat jy toegewys het, is die subnet-router-anycast-adres, wat glad nie 'n gasheeradres is nie, en op 'n skakel met twee eindpunte het dit presies een afleweringsdoel: die sender. Geen tydsperkwaarde maak dit reg nie, want die adres doen nie wat jy dink dit doen nie.

Die simptoom wat na die adres wys

Elke gasheer op die skakel antwoord behalwe die een wie se koppelvlak-identifiseerder alles nulle is. 'n Pakket wat na daardie vorm geadresseer is, word per definisie by 'n roeteerder op die subnet afgelewer, so op 'n punt-tot-punt-tonnel kom dit terug na die masjien wat dit gestuur het. Van die verre kant af lees dit as 'n onbereikbare maat; van die nabye kant af lees dit as stilte. Ruil 'n ander identifiseerder uit dieselfde voorvoegsel in en die simptoom verdwyn sonder enige ander verandering, en dit is die bevestiging wat jy moet kry voordat jy aan roetes raak.

Die alles-nul identifiseerder is as anycast gereserveer

RFC 4291 hou die alles-nul koppelvlak-identifiseerder as die subnet-router-anycast-adres, so 'n /64 soos 2001:db8:4a::/64 bevat geen bruikbare gasheer by 2001:db8:4a::. Die reservering verdien sy plek: roeteerderaankondigings en buurontdekking adresseer daardie vorm, en 'n roeteerder antwoord vir die voorvoegsel wat hy bedien. Om daardie waarde aan 'n tonneleindpunt toe te wys, gee 'n roeteerderrol aan 'n blaar, en daarom kom niks terug nie. Enige ander identifiseerder in die voorvoegsel werk as 'n gasheer, so die herstel is gewoonlik een syfer.

Behandel die reservering as 'n rol wat jy nie geregtig is om vanaf 'n tonneleindpunt te beklee nie, eerder as as 'n eienaardigheid om om te roete.

Wys gasheeradresse toe en roet die voorvoegsel

Kies ::1 en ::2 vir die twee punte, voeg een by met ip -6 addr add 2001:db8:4a::2/64 dev tun0, en roet dan die verre voorvoegsel eerder as om te probeer om dit te adresseer. 'n Roete vir 2001:db8:4a::/64 uit die tonnel maak die verre kant bereikbaar; die adres alleen maak net die plaaslike koppelvlak opgestel.

Vir 'n volle tonnel is daar 'n derde stap, 'n standaardroete vir globale unicast deur die toestel, wat die IPv6-ekwivalent is van alles in die tonnel instuur. Slaan dit oor en IPv6 hou aan om die fisiese skakel te gebruik terwyl IPv4 binne die tonnel reis, so die gasheer lek juis die verkeer wat jy geglo het gedek is. Bevestig met ip -6 route get 2001:4860:4860::8888 en lees watter toestel dit noem in plaas daarvan om die antwoord te aanvaar.

Multicast word voor roetering geweier

Android valideer adresse en roetes vir VpnService.Builder deur LinkAddress, en daardie konstruktor weier multicast heeltemal. Gee dit 'n multicast-voorvoegsel as 'n roete en die resultaat is 'n mislukking met slegte LinkAddress-parameters eerder as 'n roete, wat 'n valideringsantwoord is en nie 'n netwerkantwoord nie. Die weiering pas by die medium: 'n punt-tot-punt tun-toestel het geen skakellaag-multicast nie, so 'n groepsroete daarop het geen afleweringsmodel om te installeer nie. Groepadresse word deur die stapel self geskep en verbruik eerder as om met die hand opgestel te word.

IPv6 all-nodes- en solicited-node-adresse val onder dieselfde reël. Die koppelvlak dra hulle omdat die stapel hulle daar gesit het, nie omdat 'n beleid dit bedoel het nie.

Wat 'n tonnel eerder kan dra

Om multicast-ontdekking oor 'n tonnel te skuif vereis 'n laag wat groepildmaatskap verstaan: 'n TAP-brug wat 'n Ethernet-segment aanbied, 'n toepassingvlak-aflosser, of 'n roeteringsprotokol wat eksplisiet gesê word na watter eweknieë gerepliseer moet word. Niks daarvan bestaan in die VpnService-model nie, waar die toepassing pakkette lees en skryf en geen oproep het wat by 'n groep vir die tonnel aansluit nie. Voeg óf die komponent by wat groepe verstaan, óf laat vaar die vereiste in die ontwerp.

Unicast, daarenteen, benodig niks ekstra bo die adresse en roetes hierbo nie, en daarom word daar gewoonlik van tonnele verwag om dit te dra en word hulle dan geblameer wanneer 'n ontdekkingsprotokol misluk.

Drie kontroles voordat jy iets toewys

Bevestig die adres is nie die anycast-vorm nie, bevestig dit is nie multicast nie, en bevestig die voorvoegsel is geroteer eerder as bloot aan die toestel toegewys. Stuur dan jou toets na 'n bestemming wat 'n werklike gasheer is, want 'n ping wat op die anycast-adres gemik is, meet die sender en sê niks oor die pad nie. Hou daardie drie kontroles in die veranderingsrekord sodat die volgende ontplooiing dit nie weer ontdek nie.

'n Roete wat die platform nooit geïnstalleer het nie, kan nie ontfout word deur langer te wag nie, en 'n adres wat nooit 'n gasheer was nie, kan nie deur 'n beter ping herstel word nie.