Varför IPv6-grannupptäckt misslyckas över ett routat VPN

IPv6-grannupptäckt hör till en länk, och en routad tunnel är en gräns mellan två länkar. Den enda meningen förklarar nästan varje rapport om en fjärrvärd som svarar på adressen och inte kan hittas på något annat sätt. Kontrollera omfattningen av adressen du testar innan du kontrollerar tunneln. En länklokal adress är bara meningsfull på sin egen länk, och en multicastgrupp för den efterfrågade noden är begränsad på samma sätt. Ingen av dem korsar en router, och därför kan en ping till en global adress lyckas medan upptäckt för samma värd inte gör det.

Omfattning kommer före konfiguration

Grannbegäran och grannannonsering bär en hoppgräns på 255 och vidarebefordras inte, enligt design. Routern mellan din tunnel och det avlägsna LAN:et vidarebefordrar IPv6-paket och vidarebefordrar inte grannmeddelanden i dess namn. Därför innehåller granncachen på tunnelgränssnittet motparten och lite annat, vilket är korrekt beteende och inte ett fel att åtgärda.

En länklokal adress som en fe80::-post är också zonbegränsad, och samma text kan namnge en annan värd på en annan länk. Att testa en från andra sidan tunneln bevisar ingenting annat än att adressen är tvetydig.

Fällan är antagandet att prefixet finns på länken

En värd som tror att ett prefix finns på länken skickar en grannbegäran i stället för att lämna paketet till sin router, och det gäller även ett /64 som är routat till en avlägsen plats. När ett sådant prefix anländer som på-länken frågar värden den lokala länken efter en värd som bor någon annanstans, och ingenting svarar. Routa något mindre till fjärrvärden, eller avsluta prefixet vid routern som kommer att svara för det.

Ett /128 för en enda tjänst är den minst överraskande ordningen, och den tar bort tvetydigheten helt. Specifikationen för grannupptäckt beskriver meddelandetuppsättningen och på-länken-flaggan som avgör detta.

Bryggning ändrar reglerna med avsikt

När tunneln bär Ethernet-ramar blir det avlägsna och det lokala segmentet en enda länk, multicast når båda sidor, och grannupptäckt beter sig som på en switch. Konsekvenserna kommer med: broadcast- och multicast-översvämning, upptäckt av dubblerade adresser över bryggan och routerannonseringar som läcker in i ett segment som inte borde se dem. Feltillståndets domän omfattar nu också två platser. Inget av detta talar mot bryggning, och varje punkt är ett skäl att brygga medvetet i stället för av en slump.

Att byta en profil från TUN till TAP för att få upptäckt att synas är fel ordning på åtgärderna. Servern, klienten och adressplanen måste vara överens, och mobila klienter erbjuder inte något TAP-gränssnitt alls, så en sådan design fungerar på en bärbar dator och misslyckas på en telefon. Grannproxys och -reläer är separata mekanismer med egna krav, och de hör till nätverksadministratörens dokumenterade ordning och inte till en apps inställningar.

Testa med adressen som applikationen använder

Bekräfta rutten med ip -6 route get, inspektera grannposten med ip -6 neigh, och bekräfta sedan tjänsten över den routade vägen. DNS och returvägen är separata kontroller, och en frisk grannpost bevisar ingen av dem.

Om applikationen insisterar på ett länklokalt eller upptäcktsbaserat mål är det ett designsamtal och inte en trimningsövning, eftersom ingen klientinställning får en länkbunden mekanism att fungera genom en router.

Skriv ned vilken design du har

Anteckna före incidenten om det är routat eller bryggat, eftersom de två utrullningarna svarar olika på dessa frågor och en jourhavande ingenjör inte bör behöva sluta sig till det från en profil.

Att läsa meddelandetuppsättningen en gång tar bort frestelsen att förklara en länkomfattningsegenskap som en VPN-bugg, vilket är den dyraste feldiagnosen på området.