Miért hiúsul meg az IPv6 szomszéd-felderítés egy irányított VPN-en át

Az IPv6 szomszéd-felderítés egy kapcsolathoz tartozik, az irányított alagút pedig két kapcsolat közötti határ. Ez az egyetlen mondat magyarázza szinte az összes olyan jelentést, amelyben egy távoli gazdagép cím alapján válaszol, és semmi más nem találja meg. A tesztelt cím hatókörét az alagút ellenőrzése előtt vizsgáld meg. A kapcsolathoz kötött cím csak a saját kapcsolatán értelmes, és a kért csomópont multicast csoportja ugyanígy korlátozott. Egyik sem halad át útválasztón, ezért egy globális címre küldött ping sikerülhet, miközben ugyanannak a gazdagépnek a felderítése nem.

A hatókör megelőzi a konfigurációt

A szomszédkérés és a szomszédhirdetés 255 ugrási korlátot hordoz, és a tervezés szerint nem továbbítódik. Az alagút és a távoli LAN közötti útválasztó továbbítja az IPv6 csomagokat, és nem továbbítja helyette a szomszédüzeneteket. Így az alagút interfészének szomszéd-gyorsítótára a partnert és kevés mást tartalmaz, ami helyes viselkedés, nem javítandó hiba.

A kapcsolathoz kötött cím, például egy fe80:: bejegyzés, zónához is kötött, és ugyanaz a szöveg más kapcsolaton más gazdagépet jelölhet. Egy ilyennek az alagút túloldaláról való tesztelése semmit nem bizonyít azon kívül, hogy a cím kétértelmű.

A csapda a kapcsolaton-lét feltételezése

Az a gazdagép, amely azt hiszi, hogy egy előtag a kapcsolaton van, szomszédkérést küld ahelyett, hogy a csomagot az útválasztójának adná, és ebbe beletartozik egy távoli helyre irányított /64 is. Amikor egy ilyen előtag kapcsolaton-lévőként érkezik, a gazdagép a helyi kapcsolattól kérdez egy máshol élő gazdagépről, és semmi sem válaszol. Irányíts valami kisebbet a távoli gazdagéphez, vagy fejezd be az előtagot azon az útválasztón, amely helyette válaszolni fog.

Egyetlen szolgáltatáshoz a /128 a legkevésbé meglepő elrendezés, és teljesen megszünteti a kétértelműséget. A szomszéd-felderítési specifikáció leírja az üzenetkészletet és a kapcsolaton-lét jelzőt, amely ezt eldönti.

A hidazás szándékosan változtatja meg a szabályokat

Amikor az alagút Ethernet kereteket szállít, a távoli és a helyi szegmens egyetlen kapcsolattá válik, a multicast mindkét oldalt eléri, és a szomszéd-felderítés úgy viselkedik, mint egy kapcsolón. A következmények vele járnak: broadcast- és multicast-áradat, duplikált címek felderítése a hídon át, és olyan szegmensbe szivárgó útválasztó-hirdetések, amelyeknek nem kellene látniuk őket. A hiba tartománya immár két telephelyre terjed ki. Ebből semmi nem érv a hidazás ellen, és minden pont ok arra, hogy szándékosan, ne mellékesen építs hidat.

Egy profil TUN-ról TAP-ra váltása, hogy megjelenjen a felderítés, rossz műveleti sorrend. A kiszolgálónak, a kliensnek és a címzési tervnek egyet kell értenie, a mobil kliensek pedig egyáltalán nem kínálnak TAP interfészt, így egy ilyen terv laptopon működik, telefonon pedig elbukik. A szomszéd-proxyk és -relék saját követelményekkel bíró külön mechanizmusok, és a hálózati adminisztrátor dokumentált elrendezéséhez tartoznak, nem egy alkalmazás beállításaihoz.

Az alkalmazás által használt címmel tesztelj

Erősítsd meg az útvonalat az ip -6 route get paranccsal, nézd meg a szomszéd bejegyzést az ip -6 neigh paranccsal, majd erősítsd meg a szolgáltatást az irányított úton. A DNS és a visszaút külön ellenőrzések, és egy egészséges szomszéd bejegyzés egyiket sem bizonyítja.

Ha az alkalmazás ragaszkodik a kapcsolathoz kötött vagy felderítésalapú célhoz, az tervezési beszélgetés, nem hangolási gyakorlat, mert semmilyen kliensbeállítás nem teszi működőképessé a kapcsolathoz kötött mechanizmust egy útválasztón át.

Írd le, melyik terv van nálad

Az incidens előtt jegyezd fel, hogy irányított vagy hidazott, mert a két telepítés eltérően válaszol ezekre a kérdésekre, és egy ügyeletes mérnöknek nem kellene ezt egy profilból kitalálnia.

Az üzenetkészlet egyszeri elolvasása megszünteti a kísértést, hogy egy kapcsolathatósági tulajdonságot VPN-hibaként magyarázzunk, ami ezen a területen a legdrágább téves diagnózis.