Ien ein fan jo IPv6-tunnel pingt de oare, en mar ien rjochting antwurdet ea. De ynterface is oan, de rûte liket goed, en neat yn it logboek ferklearret it. It adres dat jo tawiisd hawwe is it subnet-router anycast-adres, dat hielendal gjin hostadres is, en op in ferbining mei twa einpunten hat it krekt ien leveringsdoel: de stjoerder. Gjinge timeoutwearde reparearret dat, om't it adres net docht wat jo tinke.

It symptoom dat nei it adres wiist

Elke host op 'e ferbining antwurdet útsein dy waans ynterface-identifikaasje allegear nullen is. In pakket dat nei dy foarm adressearre is wurdt per definysje by in rûter op it subnet besoarge, dus op in punt-nei-punt-tunnel komt it werom by de masine dy't it stjoerd hat. Fan 'e fiere ein lêst dat as in net te berikken maat; fan 'e tichte ein as stilte. Wikselje in oare identifikaasje út itselde foarheaksel yn en it symptoom ferdwynt sûnder oare feroaring, en dat is de befêstiging dy't jo krije moatte foardat jo oan rûtes komme.

De identifikaasje fan allegear nullen is as anycast reservearre

RFC 4291 hâldt de ynterface-identifikaasje fan allegear nullen as it subnet-router anycast-adres, dus in /64 lykas 2001:db8:4a::/64 befettet gjin brûkber host op 2001:db8:4a::. De reservearring fertsjinnet syn plak: rûter-oankundigings en buorlju-ûntdekking adressearje dy foarm, en in rûter antwurdet foar it foarheaksel dat er tsjinnet. It tawizen fan dy wearde oan in tunneleinpunt jout in blêd in rûterrol, en dêrom komt der neat werom. Elke oare identifikaasje yn it foarheaksel wurket as host, dus de reparaasje is meastal ien sifer.

Behannelje de reservearring as in rol dy't jo fan in tunneleinpunt ôf net ynnimme meie, net as in eigenaardichheid om mei in rûte omhinne te gean.

Tawize hostadressen en rût it foarheaksel

Kies ::1 en ::2 foar de twa einen, foegje ien ta mei ip -6 addr add 2001:db8:4a::2/64 dev tun0, en rût dan it fiere foarheaksel ynstee fan te besykjen it te adressearjen. In rûte foar 2001:db8:4a::/64 troch de tunnel makket de fiere kant berikber; it adres allinnich makket allinne de lokale ynterface konfigurearre.

Foar in folsleine tunnel is der in tredde stap, in standertrûte foar globale unicast troch it apparaat, wat it IPv6-ekwivalint is fan alles de tunnel yn stjoere. Lit it weil en IPv6 bliuwt de fysike ferbining brûken wylst IPv4 yn 'e tunnel reizget, dus de host lekt krekt it ferkear dat jo mienden dat bedutsen wie. Befêstigje mei ip -6 route get 2001:4860:4860::8888 en lês hokker apparaat it neamt ynstee fan it antwurd oan te nimmen.

Multicast wurdt foar it rûtjen wegere

Android falidearret adressen en rûtes foar VpnService.Builder fia LinkAddress, en dy konstruktor wegeret multicast daliks. Jou it in multicast-foarheaksel as rûte en it resultaat is in mislearring fan minne LinkAddress-parameters ynstee fan in rûte, wat in falidaasje-antwurd is en gjin netwurk-antwurd. De wegering past by it medium: in punt-nei-punt tun-apparaat hat gjin multicast op 'e keppellaach, dus in groepsrûte dêrop hat gjin leveringsmodel om te ynstallearjen. Groepsadressen wurde troch de stapel sels makke en ferbrûkt ynstee fan mei de hân konfigurearre.

IPv6 all-nodes- en solicited-node-adressen falle ûnder deselde regel. De ynterface draacht se om't de stapel se dêr set hat, net om't in belied se bedoelde.

Wat in tunnel ynstee drage kin

multicast-ûntdekking troch in tunnel ferpleatsen freget in laach dy't groepsmedskiplidmaatskip begrypt: in TAP-brêge dy't in Ethernet-segment presintearret, in relais op applikaasjenivo of in rûtjeprotokol dêr't eksplisyt tsjin sein wurdt nei hokker maten te replikearjen. Neat dêrfan bestiet yn it VpnService-model, dêr't de applikaasje pakketten lêst en skriuwt en gjin oprop hat dy't foar de tunnel by in groep komt. Foegje dan de komponint ta dy't groepen begrypt of lit de eask út it ûntwerp.

Unicast, oarsom, freget neat ekstra boppe de adressen en rûtes hjirboppe, dêrom wurdt fan tunnels ornaris ferwachte dat se it drage en wurde se dêrnei beskuldige as in ûntdekkingsprotokol mislearret.

Trije kontrôles foardat jo wat tawize

Befêstigje dat it adres net de anycast-foarm is, befêstigje dat it gjin multicast is, en befêstigje dat it foarheaksel rût is en net allinnich oan it apparaat tawiisd. Stjoer dan jo test nei in bestimming dy't in echte host is, om't in ping nei it anycast-adres de stjoerder mjit en neat oer it paad seit. Hâld dy trije kontrôles yn it feroaringsrekord sadat de folgjende ymplemintaasje se net wer ûntdekt.

In rûte dy't it platfoarm nea ynstallearre hat kin net debugt wurde troch langer te wachtsjen, en in adres dat nea in host wie kin net reparearre wurde troch in bettere ping.

Relatearre artikelen