Waarom IPv6-buurdetectie mislukt over een gerouteerde VPN

IPv6-buurdetectie hoort bij één link, en een gerouteerde tunnel is een grens tussen twee links. Die ene zin verklaart bijna elk rapport over een externe host die op zijn adres antwoordt en via niets anders te vinden is. Controleer het bereik van het adres dat je test voordat je de tunnel controleert. Een linklokaal adres is alleen betekenisvol op zijn eigen link, en een multicastgroep van het opgevraagde knooppunt is op dezelfde manier begrensd. Geen van beide gaat door een router, en daarom kan een ping naar een globaal adres slagen terwijl detectie voor dezelfde host niet werkt.

Bereik komt voor configuratie

Buurverzoek en buuraankondiging dragen een hoplimiet van 255 en worden volgens ontwerp niet doorgestuurd. De router tussen je tunnel en het externe LAN stuurt IPv6-pakketten door en stuurt geen buurberichten namens hem door. Zo bevat de buurcache op de tunnelinterface de peer en weinig anders, wat correct gedrag is en geen defect om te verhelpen.

Een linklokaal adres zoals een fe80::-vermelding is ook zonegebonden, en dezelfde tekst kan op een andere link een andere host aanduiden. Er een testen vanaf de andere kant van de tunnel bewijst niets anders dan dat het adres dubbelzinnig is.

De valkuil is de aanname dat het prefix op de link staat

Een host die gelooft dat een prefix op de link staat, stuurt een buurverzoek in plaats van het pakket aan zijn router te geven, en dat geldt ook voor een /64 die naar een externe locatie is gerouteerd. Wanneer zo'n prefix als op-de-link aankomt, vraagt de host de lokale link naar een host die elders woont, en niets antwoordt. Routeer iets kleiners naar de externe host, of beëindig het prefix op de router die ervoor zal antwoorden.

Een /128 voor één dienst is de minst verrassende regeling, en die neemt de dubbelzinnigheid volledig weg. De specificatie voor buurdetectie beschrijft de berichtenset en de op-de-link-vlag die dit beslist.

Bridging verandert de regels met opzet

Wanneer de tunnel Ethernet-frames draagt, worden het externe en het lokale segment één link, multicast bereikt beide kanten, en buurdetectie gedraagt zich zoals op een switch. De gevolgen komen mee: broadcast- en multicast-overstroming, detectie van dubbele adressen over de bridge en routeraankondigingen die lekken naar een segment dat ze niet zou moeten zien. Het storingsdomein beslaat nu ook twee locaties. Niets daarvan pleit tegen bridging, en elk punt is een reden om bewust te bridgen in plaats van terloops.

Een profiel van TUN naar TAP omzetten om detectie te laten verschijnen is de verkeerde volgorde van handelingen. De server, de client en het adresplan moeten het eens zijn, en mobiele clients bieden helemaal geen TAP-interface, dus zo'n ontwerp werkt op een laptop en mislukt op een telefoon. Buurproxies en -relays zijn afzonderlijke mechanismen met eigen eisen, en ze horen bij de gedocumenteerde regeling van de netwerkbeheerder en niet bij de instellingen van een app.

Test met het adres dat de applicatie gebruikt

Bevestig de route met ip -6 route get, bekijk de buurvermelding met ip -6 neigh, en bevestig daarna de dienst over het gerouteerde pad. DNS en de retourweg zijn afzonderlijke controles, en een gezonde buurvermelding bewijst geen van beide.

Als de applicatie aandringt op een linklokaal of op detectie gebaseerd doel, is dat een ontwerpgesprek en geen tuningsoefening, omdat geen enkele clientinstelling een linkgebonden mechanisme over een router heen laat werken.

Schrijf op welk ontwerp je hebt

Leg voor het incident vast of het gerouteerd of gebridget is, want de twee uitrollingen beantwoorden deze vragen verschillend en een dienstdoende engineer zou het niet uit een profiel moeten afleiden.

Het berichtenset één keer lezen neemt de verleiding weg om een linkbereikeigenschap als een VPN-fout te verklaren, wat de duurste verkeerde diagnose op dit gebied is.