IPv6-tunnelin vastapään ping epäonnistuu? Tarkista ::-osoite

IPv6-tunnelin toinen pää pingaa toista, ja vain yksi suunta vastaa koskaan. Liitäntä on ylhäällä, reitti näyttää oikealta, eikä mikään lokissa selitä sitä. Määrittämäsi osoite on aliverkon reitittimen anycast-osoite, joka ei ole lainkaan isäntäosoite, ja kahden päätepisteen linkillä sillä on täsmälleen yksi toimituskohde: lähettäjä. Mikään aikakatkaisuarvo ei korjaa sitä, koska osoite ei tee sitä, mitä luulet.

Oire, joka osoittaa osoitteeseen

Jokainen linkin isäntä vastaa paitsi se, jonka liitäntätunniste on kaikki nollia. Tuohon muotoon osoitettu paketti toimitetaan määritelmän mukaan aliverkon reitittimelle, joten point-to-point-tunnelissa se palaa koneelle, joka sen lähetti. Kauempaa päästä se luetaan tavoittamattomaksi vastapääksi; lähemmästä päästä hiljaisuudeksi. Vaihda saman etuliitteen toinen tunniste tilalle, niin oire katoaa ilman mitään muuta muutosta, ja se on vahvistus, joka pitää saada ennen reitteihin koskemista.

Kaikkien nollien tunniste on varattu anycastiksi

RFC 4291 pitää kaikkien nollien liitäntätunnisteen aliverkon reitittimen anycast-osoitteena, joten /64 kuten 2001:db8:4a::/64 ei sisällä yhtään käyttökelpoista isäntää osoitteessa 2001:db8:4a::. Varaus ansaitsee paikkansa: reitittimen ilmoitukset ja naapureiden löytäminen osoittavat tuohon muotoon, ja reititin vastaa palvelemansa etuliitteen puolesta. Tuon arvon määrittäminen tunnelin päätepisteelle antaa reitittimen roolin lehdelle, ja siksi mitään ei tule takaisin. Mikä tahansa muu etuliitteen tunniste toimii isäntänä, joten korjaus on yleensä yksi numero.

Kohtele varausta roolina, jota sinulla ei ole oikeutta ottaa tunnelin päätepisteestä, äläkä omituisuutena, jonka voi kiertää reitillä.

Määritä isäntäosoitteet ja reititä etuliite

Valitse ::1 ja ::2 kahdelle päälle, lisää yksi komennolla ip -6 addr add 2001:db8:4a::2/64 dev tun0, ja reititä sitten etäinen etuliite sen sijaan että yrittäisit osoittaa sen. Reitti kohteelle 2001:db8:4a::/64 tunnelin läpi tekee kaukaisesta puolesta tavoitettavan; pelkkä osoite tekee vain paikallisesta liitännästä määritetyn.

Täydellisessä tunnelissa on kolmas vaihe, oletusreitti globaalille unicastille laitteen kautta, mikä on IPv6-vastine kaiken lähettämiselle tunneliin. Jos jätät sen pois, IPv6 jatkaa fyysisen linkin käyttöä samalla kun IPv4 kulkee tunnelin sisällä, joten isäntä vuotaa juuri sen liikenteen, jonka luulit olevan katettu. Vahvista komennolla ip -6 route get 2001:4860:4860::8888 ja lue, minkä laitteen se nimeää, sen sijaan että olettaisit vastauksen.

Multicast hylätään ennen reititystä

Android validoi VpnService.Builder -rajapinnalle annettavat osoitteet ja reitit LinkAddress kautta, ja tuo konstruktori hylkää multicastingin suoraan. Jos annat sille multicast-etuliitteen reittinä, tuloksena on huonojen LinkAddress-parametrien virhe eikä reitti, mikä on validoinnin eikä verkon vastaus. Hylkäys vastaa välinettä: point-to-point-tun-laiteella ei ole linkkikerroksen multicastingia, joten ryhmäreitillä siinä ei ole toimitusmallia asennettavaksi. Ryhmäosoitteet luo ja kuluttaa pino itse sen sijaan että ne määritettäisiin käsin.

IPv6 all-nodes- ja solicited-node-osoitteet kuuluvat saman säännön alle. Liitäntä kantaa niitä, koska pino laittoi ne sinne, ei siksi että käytäntö tarkoitti niitä.

Mitä tunneli voi kantaa sen sijaan

multicast-löytämisen siirtäminen tunnelin yli vaatii kerroksen, joka ymmärtää ryhmäjäsenyyttä: TAP-silta, joka esittää Ethernet-segmentin, sovellustason välitys tai reititysprotokolla, jolle sanotaan nimenomaisesti, mille vertaisille replikoida. Mitään tästä ei ole VpnService-mallissa, jossa sovellus lukee ja kirjoittaa paketteja eikä sillä ole kutsua, joka liittyisi ryhmään tunnelia varten. Joko lisää komponentti, joka ymmärtää ryhmiä, tai poista vaatimus suunnittelusta.

Unicast sitä vastoin ei tarvitse mitään ylimääräistä yllä olevien osoitteiden ja reittien lisäksi, minkä vuoksi tunneleiden odotetaan yleensä kantavan sitä, ja sitten niitä syytetään, kun löytämisprotokolla epäonnistuu.

Kolme tarkistusta ennen kuin määrität mitään

Varmista, ettei osoite ole anycast-muoto, varmista, ettei se ole multicast, ja varmista, että etuliite on reititetty eikä vain määritetty laitteelle. Lähetä sitten testisi kohteeseen, joka on todellinen isäntä, koska anycast-osoitteeseen suunnattu ping mittaa lähettäjää eikä kerro polusta mitään. Pidä nuo kolme tarkistusta muutoskirjauksessa, jotta seuraava käyttöönotto ei löydä niitä uudelleen.

Reittiä, jota alusta ei koskaan asentanut, ei voi debugata odottamalla kauemmin, eikä osoitetta, joka ei koskaan ollut isäntä, voi korjata paremmalla pingillä.