Nem megy a ping az IPv6-alagút társához? Ellenőrizze a :: címet

Az IPv6-alagút egyik vége pingel a másikra, és mindig csak egy irány válaszol. Az interfész aktív, az útvonal helyesnek látszik, és semmi sem magyarázza meg a naplóban. A hozzárendelt cím az alhálózati útválasztó anycast címe, ami egyáltalán nem gazdagép-cím, és egy két végpontú kapcsolaton pontosan egy kézbesítési célja van: a feladó. Semmilyen időtúllépési érték nem javítja meg, mert a cím nem azt teszi, amit gondol.

A tünet, amely a címre mutat

A kapcsolat minden gazdagépe válaszol, kivéve azt, amelynek interfész-azonosítója csupa nulla. Az ilyen formára címzett csomag definíció szerint az alhálózat egyik útválasztójához kerül, így pont-pont alagúton visszatér ahhoz a géphez, amely elküldte. A távoli végről ez elérhetetlen partnerként olvasható; a közeli végről csendként. Cserélje ki egy másik azonosítóra ugyanabból a prefixből, és a tünet minden más változtatás nélkül eltűnik, és ez az a megerősítés, amelyet az útvonalak érintése előtt be kell szerezni.

A csupa nullás azonosító anycastként van fenntartva

Az RFC 4291 a csupa nullás interfész-azonosítót alhálózati útválasztó anycast címként tartja meg, ezért egy /64, például 2001:db8:4a::/64 nem tartalmaz használható gazdagépet a következő címen: 2001:db8:4a::. A fenntartás megérdemli a helyét: az útválasztó-hirdetések és a szomszéd-felderítés ezt a formát címzi, és az útválasztó a kiszolgált prefixért válaszol. Ha ezt az értéket alagút-végpontnak adja, egy levél kap útválasztói szerepet, és ezért nem jön vissza semmi. A prefix bármely más azonosítója gazdagépként működik, így a javítás általában egy számjegy.

Tekintse a fenntartást olyan szerepnek, amelyet alagút-végpontból nincs joga betölteni, nem pedig olyan furcsaságnak, amelyet útvonallal meg lehet kerülni.

Rendeljen gazdagép-címeket, és irányítsa a prefixet

Válassza a ::1 és a ::2 címeket a két véghez, adjon hozzá egyet ezzel: ip -6 addr add 2001:db8:4a::2/64 dev tun0, majd irányítsa a távoli prefixet ahelyett, hogy címezni próbálná. Egy útvonal a következőhöz: 2001:db8:4a::/64 az alagúton át elérhetővé teszi a távoli oldalt; a cím önmagában csak a helyi interfészt konfigurálja.

Teljes alagúthoz van egy harmadik lépés, egy alapértelmezett útvonal a globális unicast számára az eszközön át, ami az IPv6 megfelelője annak, hogy mindent az alagútba küldünk. Ha kihagyja, az IPv6 továbbra is a fizikai kapcsolatot használja, miközben az IPv4 az alagúton belül utazik, így a gazdagép pontosan azt a forgalmat szivárogtatja, amelyről azt hitte, hogy le van fedve. Erősítse meg ezzel: ip -6 route get 2001:4860:4860::8888 és olvassa el, melyik eszközt nevezi meg, ahelyett hogy feltételezné a választ.

A multicastot az útválasztás előtt elutasítják

Az Android az alábbihoz tartozó címeket és útvonalakat ellenőrzi: VpnService.Builder ezen keresztül: LinkAddress, és ez a konstruktor a multicastot egyenesen elutasítja. Adjon neki multicast prefixet útvonalként, és az eredmény nem útvonal, hanem rossz LinkAddress-paraméterek hibája, ami validációs válasz, nem hálózati. Az elutasítás illik a médiumhoz: egy pont-pont tun eszköznek nincs kapcsolati rétegű multicastja, így egy csoportos útvonalon nincs mit telepíteni kézbesítési modellként. A csoportcímeket maga a verem hozza létre és fogyasztja, nem kézzel kell beállítani.

Az IPv6 all-nodes és solicited-node címek ugyanezen szabály alá esnek. Az interfész azért hordozza őket, mert a verem tette oda őket, nem azért, mert egy szabályzat így szánta.

Mit hordozhat helyette az alagút

multicast-felderítés alagúton át átmozgatásához olyan réteg kell, amely érti a csoporttagságot: egy TAP-híd, amely Ethernet-szegmenst mutat be, egy alkalmazásszintű átjátszó, vagy egy útválasztási protokoll, amelynek kifejezetten megmondják, mely partnereknek replikáljon. Ilyesmi nem létezik a VpnService-modellben, ahol az alkalmazás csomagokat olvas és ír, és nincs hívása, amely csatlakozna egy csoporthoz az alagút számára. Vagy adja hozzá a csoportokat értő komponenst, vagy vegye ki a követelményt a tervből.

A unicast ezzel szemben semmit sem igényel a fenti címeken és útvonalakon túl, ezért általában elvárják az alagutaktól, hogy hordozzák, majd hibáztatják őket, amikor egy felderítési protokoll meghibásodik.

Három ellenőrzés, mielőtt bármit hozzárendel

Erősítse meg, hogy a cím nem anycast-forma, hogy nem multicast, és hogy a prefix irányított, nem csak az eszközhöz rendelt. Ezután küldje a tesztjét olyan célra, amely valódi gazdagép, mert az anycast címre irányuló ping a feladót méri, és semmit sem mond az útvonalról. Tartsa ezt a három ellenőrzést a változási rekordban, hogy a következő telepítés ne fedezze fel újra őket.

Egy útvonalat, amelyet a platform soha nem telepített, nem lehet hosszabb várakozással hibakeresni, és egy címet, amely soha nem volt gazdagép, nem lehet jobb pinggel megjavítani.