Ping til din IPv6-tunnelpeer fejler? Tjek ::-adressen

Den ene ende af din IPv6-tunnel pinger den anden, og kun én retning svarer nogensinde. Interfacet er oppe, ruten ser rigtig ud, og intet i loggen forklarer det. Den adresse, du tildelte, er subnet-router anycast-adressen, som slet ikke er en værtadresse, og på et link med to endepunkter har den præcis ét leveringsmål: afsenderen. Ingen timeout-værdi reparerer det, fordi adressen ikke gør det, du tror.

Symptomet der peger på adressen

Hver vært på linket svarer undtagen den, hvis interface-identifikator er alle nuller. En pakke adresseret til den form leveres per definition til en router på undernettet, så på en punkt-til-punkt-tunnel kommer den tilbage til maskinen, der sendte den. Fra den fjerne ende læses det som en uopnåelig peer; fra den nære ende læses det som tavshed. Byt en anden identifikator fra samme præfiks ind, og symptomet forsvinder uden nogen anden ændring, og det er den bekræftelse, du skal have, før du rører ved ruter.

Identifikatoren med alle nuller er reserveret som anycast

RFC 4291 beholder interface-identifikatoren med alle nuller som subnet-router anycast-adressen, så en /64 som 2001:db8:4a::/64 indeholder ingen brugbar vært på 2001:db8:4a::. Reservationen fortjener sin plads: routerannonceringer og nabo-opdagelse adresserer den form, og en router svarer for det præfiks, den betjener. Tildeler man den værdi til et tunnelendepunkt, gives en routerrolle til et blad, og derfor kommer intet tilbage. Enhver anden identifikator i præfikset virker som vært, så reparationen er som regel ét ciffer.

Behandl reservationen som en rolle, du ikke har ret til at indtage fra et tunnelendepunkt, snarere end som en særhed at route udenom.

Tildel værtadresser og rut præfikset

Vælg ::1 og ::2 til de to ender, tilføj en med ip -6 addr add 2001:db8:4a::2/64 dev tun0, og rut derefter det fjerne præfiks i stedet for at prøve at adressere det. En rute for 2001:db8:4a::/64 ud gennem tunnelen gør den fjerne side tilgængelig; alene gør adressen kun det lokale interface konfigureret.

For en fuld tunnel er der et tredje trin, en standardrute for global unicast gennem enheden, som er IPv6-ækvivalenten til at sende alt i tunnelen. Spring den over, og IPv6 fortsætter med at bruge det fysiske link, mens IPv4 rejser inde i tunnelen, så værten lækker præcis den trafik, du troede var dækket. Bekræft med ip -6 route get 2001:4860:4860::8888 og læs, hvilken enhed den nævner, i stedet for at antage svaret.

Multicast afvises før routing

Android validerer adresser og ruter for VpnService.Builder gennem LinkAddress, og den konstruktør afviser multicast blankt. Giv den et multicast-præfiks som rute, og resultatet er en fejl med dårlige LinkAddress-parametre i stedet for en rute, hvilket er et valideringssvar og ikke et netværkssvar. Afvisningen matcher mediet: en punkt-til-punkt-tun-enhed har ingen linklags-multicast, så en grupperute på den har ingen leveringsmodel at installere. Gruppeadresser oprettes og forbruges af stakken selv i stedet for at blive konfigureret i hånden.

IPv6 all-nodes- og solicited-node-adresser falder under samme regel. Interfacet bærer dem, fordi stakken satte dem der, ikke fordi en politik havde til hensigt det.

Hvad en tunnel kan bære i stedet

At flytte multicast-opdagelse gennem en tunnel kræver et lag, der forstår gruppemedlemskab: en TAP-bro, der præsenterer et Ethernet-segment, et relæ på applikationsniveau eller en routingprotokol, der eksplicit får at vide, hvilke peers der skal replikeres til. Intet af det findes i VpnService-modellen, hvor applikationen læser og skriver pakker og ikke har noget kald, der melder sig ind i en gruppe for tunnelen. Føj enten komponenten, der forstår grupper, til, eller drop kravet fra designet.

Unicast kræver derimod intet ekstra ud over adresserne og ruterne ovenfor, og derfor forventes tunneler normalt at bære det og bliver derefter bebrejdet, når en opdagelsesprotokol fejler.

Tre tjek, før du tildeler noget

Bekræft, at adressen ikke er anycast-formen, bekræft, at den ikke er multicast, og bekræft, at præfikset er rutet og ikke bare tildelt enheden. Send derefter din test til en destination, der er en rigtig vært, fordi en ping rettet mod anycast-adressen måler afsenderen og intet siger om vejen. Hold de tre tjek i ændringsloggen, så den næste udrulning ikke genopdager dem.

En rute, som platformen aldrig installerede, kan ikke fejlfindes ved at vente længere, og en adresse, der aldrig var en vært, kan ikke repareres med en bedre ping.