Ping til IPv6-tunnelens motpart mislykkes? Sjekk ::-adressen

Den ene enden av IPv6-tunnelen din pinger den andre, og bare én retning svarer noen gang. Grensesnittet er oppe, ruten ser riktig ut, og ingenting i loggen forklarer det. Adressen du tildelte, er subnet-router anycast-adressen, som slett ikke er en vertsadresse, og på en lenke med to endepunkter har den nøyaktig ett leveringsmål: avsenderen. Ingen timeout-verdi reparerer det, fordi adressen ikke gjør det du tror.

Symptomet som peker på adressen

Hver vert på lenken svarer unntatt den hvis interface-identifikator er alle nuller. En pakke adressert til den formen leveres per definisjon til en ruter på subnettet, så på en punkt-til-punkt-tunnel kommer den tilbake til maskinen som sendte den. Fra den fjerne enden leses det som en utilgjengelig motpart; fra den nære enden som stillhet. Bytt inn en annen identifikator fra samme prefiks, og symptomet forsvinner uten noen annen endring, og det er bekreftelsen du skal skaffe før du rører rutene.

Identifikatoren med alle nuller er reservert som anycast

RFC 4291 beholder interface-identifikatoren med alle nuller som subnet-router anycast-adressen, så en /64 som 2001:db8:4a::/64 inneholder ingen brukbar vert på 2001:db8:4a::. Reservasjonen fortjener plassen sin: ruterannonser og nabo-oppdagelse adresserer den formen, og en ruter svarer for prefikset den betjener. Å tildele den verdien til et tunnelendepunkt gir en ruterrolle til et blad, og derfor kommer ingenting tilbake. Enhver annen identifikator i prefikset fungerer som vert, så reparasjonen er vanligvis ett siffer.

Behandle reservasjonen som en rolle du ikke har rett til å innta fra et tunnelendepunkt, snarere enn som en særhet å rute rundt.

Tildel vertsadresser og rut prefikset

Velg ::1 og ::2 for de to endene, legg til én med ip -6 addr add 2001:db8:4a::2/64 dev tun0, og rut deretter det fjerne prefikset i stedet for å prøve å adressere det. En rute for 2001:db8:4a::/64 ut gjennom tunnelen gjør den fjerne siden tilgjengelig; alene gjør adressen bare det lokale grensesnittet konfigurert.

For en full tunnel er det et tredje trinn, en standardrute for global unicast gjennom enheten, som er IPv6-ekvivalenten til å sende alt inn i tunnelen. Hopper du over den, fortsetter IPv6 å bruke den fysiske lenken mens IPv4 reiser inne i tunnelen, så verten lekker nøyaktig den trafikken du trodde var dekket. Bekreft med ip -6 route get 2001:4860:4860::8888 og les hvilken enhet den nevner i stedet for å anta svaret.

Multicast avvises før ruting

Android validerer adresser og ruter for VpnService.Builder gjennom LinkAddress, og den konstruktøren avviser multicast blankt. Gi den et multicast-prefiks som rute, og resultatet er en feil med dårlige LinkAddress-parametere i stedet for en rute, som er et valideringssvar og ikke et nettverkssvar. Avvisningen passer til mediet: en punkt-til-punkt-tun-enhet har ingen linklags-multicast, så en grupperute på den har ingen leveringsmodell å installere. Gruppeadresser opprettes og forbrukes av stakken selv i stedet for å konfigureres for hånd.

IPv6 all-nodes- og solicited-node-adresser faller under samme regel. Grensesnittet bærer dem fordi stakken satte dem der, ikke fordi en policy hadde til hensikt det.

Hva en tunnel kan bære i stedet

multicast-oppdagelse gjennom en tunnel krever et lag som forstår gruppemedlemskap: en TAP-bro som presenterer et Ethernet-segment, et relé på applikasjonsnivå eller en rutingsprotokoll som eksplisitt får beskjed om hvilke motparter det skal replikeres til. Ingenting av det finnes i VpnService-modellen, der applikasjonen leser og skriver pakker og ikke har noe kall som melder seg inn i en gruppe for tunnelen. Legg enten til komponenten som forstår grupper, eller fjern kravet fra designet.

Unicast krever derimot ingenting ekstra utover adressene og rutene ovenfor, og derfor forventes det vanligvis at tunneler bærer det, og blir deretter klandret når en oppdagelsesprotokoll feiler.

Tre sjekker før du tildeler noe

Bekreft at adressen ikke er anycast-formen, bekreft at den ikke er multicast, og bekreft at prefikset er rutet og ikke bare tildelt enheten. Send deretter testen din til en destinasjon som er en ekte vert, fordi en ping rettet mot anycast-adressen måler avsenderen og sier ingenting om veien. Hold de tre sjekkene i endringsloggen, så neste utrulling ikke oppdager dem på nytt.

En rute som plattformen aldri installerte, kan ikke feilsøkes ved å vente lenger, og en adresse som aldri var en vert, kan ikke repareres med en bedre ping.