Ping til IPv6-tunnelen sin motpart mislukkast? Sjekk ::-adressa

Den eine enden av IPv6-tunnelen din pingar den andre, og berre éin retning svarar nokon gong. Grensesnittet er oppe, ruta ser rett ut, og ingenting i loggen forklarer det. Adressa du tildelte, er subnet-router anycast-adressa, som slett ikkje er ei vertsadresse, og på ei lenke med to endepunkt har ho nøyaktig eitt leveringsmål: avsendararen. Ingen timeout-verdi reparerer det, fordi adressa ikkje gjer det du trur.

Symptomet som peikar på adressa

Kvar vert på lenka svarar unntatt den der interface-identifikatoren er alle nullar. Ein pakke adressert til den forma vert per definisjon levert til ein ruter på subnettet, så på ein punkt-til-punkt-tunnel kjem han tilbake til maskinen som sende han. Frå den fjerne enden blir det lese som ein utilgjengeleg motpart; frå den nære enden som stillheit. Byt inn ein annan identifikator frå same prefiks, og symptomet forsvinn utan noka anna endring, og det er stadfestinga du skal skaffe før du rører rutene.

Identifikatoren med alle nullar er reservert som anycast

RFC 4291 held på interface-identifikatoren med alle nullar som subnet-router anycast-adressa, så ein /64 som 2001:db8:4a::/64 inneheld ingen brukbar vert på 2001:db8:4a::. Reserveringa fortener plassen sin: ruterannonsar og nabo-oppdaging adresserer den forma, og ein ruter svarar for prefikset han tener. Å tildela den verdien til eit tunnelendepunkt gir ein ruterrolle til eit blad, og derfor kjem ingenting tilbake. Kvar annan identifikator i prefikset fungerer som vert, så reparasjonen er vanlegvis eitt siffer.

Behandle reserveringa som ei rolle du ikkje har rett til å ta frå eit tunnelendepunkt, snarare enn som ei særheit å rute rundt.

Tildel vertsadresser og rut prefikset

Vel ::1 og ::2 for dei to endane, legg til éin med ip -6 addr add 2001:db8:4a::2/64 dev tun0, og rut deretter det fjerne prefikset i staden for å prøve å adressere det. Ei rute for 2001:db8:4a::/64 ut gjennom tunnelen gjer den fjerne sida tilgjengeleg; aleine gjer adressa berre grensesnittet lokalt konfigurert.

For ein full tunnel er det eit tredje steg, ei standardrute for global unicast gjennom eininga, som er IPv6-ekvivalenten til å sende alt inn i tunnelen. Hoppar du over ho, held IPv6 fram med å bruke den fysiske lenka medan IPv4 reiser inne i tunnelen, så verten lekk nøyaktig den trafikken du trudde var dekt. Stadfest med ip -6 route get 2001:4860:4860::8888 og les kva eining ho nemner i staden for å anta svaret.

Multicast blir avvist før ruting

Android validerer adresser og ruter for VpnService.Builder gjennom LinkAddress, og den konstruktøren avviser multicast blankt. Gi han eit multicast-prefiks som rute, og resultatet er ein feil med dårlege LinkAddress-parametrar i staden for ei rute, som er eit valideringssvar og ikkje eit nettverkssvar. Avvisinga passar til mediet: ei punkt-til-punkt-tun-eining har ingen linklags-multicast, så ei grupperute på ho har ingen leveringsmodell å installere. Gruppeadresser blir laga og brukte av stakken sjølv i staden for å bli konfigurerte for hand.

IPv6 all-nodes- og solicited-node-adresser fell under same regel. Grensesnittet ber dei fordi stakken sette dei der, ikkje fordi ein policy hadde til hensikt det.

Kva ein tunnel kan bere i staden

multicast-oppdaging gjennom ein tunnel krev eit lag som forstår gruppemedlemskap: ei TAP-bru som presenterer eit Ethernet-segment, eit relé på applikasjonsnivå eller ein ruteprotokoll som eksplisitt får beskjed om kva motpartar det skal replikerast til. Ingenting av det finst i VpnService-modellen, der applikasjonen les og skriv pakkar og ikkje har noko kall som melder seg inn i ei gruppe for tunnelen. Legg anten til komponenten som forstår grupper, eller fjern kravet frå designet.

Unicast krev derimot ingenting ekstra utover adressene og rutene ovanfor, og derfor blir det vanlegvis venta at tunnelar ber det, og blir deretter klandra når ein oppdagingsprotokoll feilar.

Tre sjekkar før du tildeler noko

Stadfest at adressa ikkje er anycast-forma, stadfest at ho ikkje er multicast, og stadfest at prefikset er ruta og ikkje berre tildelt eininga. Send deretter testen din til ein destinasjon som er ein ekte vert, fordi ein ping retta mot anycast-adressa måler avsendararen og seier ingenting om vegen. Hald dei tre sjekkane i endringsloggen, så neste utrulling ikkje oppdagar dei på nytt.

Ei rute som plattforma aldri installerte, kan ikkje feilsøkjast ved å vente lenger, og ei adresse som aldri var ein vert, kan ikkje reparerast med ein betre ping.