Ping naar je IPv6-tunnelpeer mislukt? Controleer het ::-adres

Het ene uiteinde van je IPv6-tunnel pingt het andere, en altijd antwoordt maar één richting. De interface is up, de route ziet er goed uit, en niets in het log verklaart het. Het adres dat je hebt toegewezen is het subnet-router anycast-adres, dat helemaal geen hostadres is, en op een link met twee eindpunten heeft het precies één afleverdoel: de afzender. Geen enkele timeoutwaarde repareert dat, omdat het adres niet doet wat je denkt.

Het symptoom dat naar het adres wijst

Elke host op de link antwoordt behalve degene wiens interface-identificatie alle nullen is. Een pakket dat naar die vorm is geadresseerd wordt per definitie aan een router op het subnet afgeleverd, dus op een point-to-point-tunnel komt het terug bij de machine die het stuurde. Vanaf het verre uiteinde leest dat als een onbereikbare peer; vanaf het nabije uiteinde als stilte. Vervang door een andere identificatie uit hetzelfde prefix en het symptoom verdwijnt zonder enige andere wijziging, en dat is de bevestiging die je moet krijgen voordat je aan routes komt.

De identificatie met alle nullen is gereserveerd als anycast

RFC 4291 houdt de interface-identificatie met alle nullen aan als het subnet-router anycast-adres, dus een /64 zoals 2001:db8:4a::/64 bevat geen bruikbare host op 2001:db8:4a::. De reservering verdient zijn plek: routeraankondigingen en buurontdekking adresseren die vorm, en een router antwoordt voor het prefix dat hij bedient. Die waarde aan een tunneleindpunt toewijzen geeft een routerrol aan een blad, en daarom komt er niets terug. Elke andere identificatie in het prefix werkt als host, dus de reparatie is meestal één cijfer.

Behandel de reservering als een rol die je vanaf een tunneleindpunt niet mag innemen, niet als een eigenaardigheid om met een route omheen te gaan.

Wijs hostadressen toe en routeer het prefix

Kies ::1 en ::2 voor de twee uiteinden, voeg er een toe met ip -6 addr add 2001:db8:4a::2/64 dev tun0, en routeer dan het verre prefix in plaats van het te proberen adresseren. Een route voor 2001:db8:4a::/64 door de tunnel maakt de verre kant bereikbaar; het adres alleen maakt alleen de lokale interface geconfigureerd.

Voor een volledige tunnel is er een derde stap, een standaardroute voor global unicast via het apparaat, wat het IPv6-equivalent is van alles de tunnel in sturen. Sla je die over, dan blijft IPv6 de fysieke link gebruiken terwijl IPv4 in de tunnel reist, dus de host lekt precies het verkeer waarvan je dacht dat het gedekt was. Bevestig met ip -6 route get 2001:4860:4860::8888 en lees welk apparaat het noemt in plaats van het antwoord aan te nemen.

Multicast wordt geweigerd vóór routing

Android valideert adressen en routes voor VpnService.Builder via LinkAddress, en die constructor weigert multicast ronduit. Geef hem een multicast-prefix als route en het resultaat is een fout met slechte LinkAddress-parameters in plaats van een route, wat een validatieantwoord is en geen netwerkantwoord. De weigering past bij het medium: een point-to-point-tun-apparaat heeft geen multicast op linklaag, dus een groepsroute erop heeft geen aflevermodel om te installeren. Groepsadressen worden door de stack zelf gemaakt en verbruikt in plaats van met de hand geconfigureerd.

IPv6 all-nodes- en solicited-node-adressen vallen onder dezelfde regel. De interface draagt ze omdat de stack ze daar heeft neergezet, niet omdat een beleid ze bedoelde.

Wat een tunnel in plaats daarvan kan dragen

multicast-ontdekking door een tunnel verplaatsen vraagt een laag die groepslidmaatschap begrijpt: een TAP-brug die een Ethernet-segment presenteert, een relay op applicatieniveau of een routingprotocol dat expliciet te horen krijgt naar welke peers te repliceren. Niets daarvan bestaat in het VpnService-model, waar de applicatie pakketten leest en schrijft en geen aanroep heeft die voor de tunnel bij een groep komt. Voeg ofwel de component toe die groepen begrijpt, ofwel haal de eis uit het ontwerp.

Unicast daarentegen heeft niets extra nodig boven de adressen en routes hierboven, en daarom wordt van tunnels meestal verwacht dat ze het dragen en krijgen ze daarna de schuld als een ontdekkingsprotocol faalt.

Drie controles voordat je iets toewijst

Bevestig dat het adres niet de anycast-vorm is, bevestig dat het geen multicast is, en bevestig dat het prefix is gerouteerd en niet alleen aan het apparaat toegewezen. Stuur dan je test naar een bestemming die een echte host is, want een ping naar het anycast-adres meet de afzender en zegt niets over het pad. Houd die drie controles in het wijzigingsrecord, zodat de volgende uitrol ze niet opnieuw ontdekt.

Een route die het platform nooit heeft geïnstalleerd kun je niet debuggen door langer te wachten, en een adres dat nooit een host was kun je niet repareren met een betere ping.