Welke IPv6-bron een VPN-verzoek kiest, en waarom dat ertoe doet

Je voegde een VPN-adres toe en verwachtte dat het verzoek dat zou gebruiken, maar de server logde nog steeds het oude prefix. Niets aan de tunnel was mislukt; de host koos een bronadres voordat hij ooit naar de route keek waar je naar staarde. IPv6-bronselectie is een aparte, geordende competitie tussen de kandidaatadressen van de host, en het langst overeenkomende prefix is slechts één regel vlak bij het einde daarvan. Het gewenste resultaat krijgen betekent weten welke regel al gewonnen heeft. De regels zelf zijn saai en precies, en dat is juist de reden om ze op volgorde te lezen.

Twee opzoekingen, niet één

Bestemmingsselectie bepaalt de volgende hop en de uitgaande interface. Daarna bepaalt bronselectie welk van de adressen van de host in de header verschijnt, en de twee vragen worden door verschillende mechanismen beantwoord, ook al gebruiken beide prefixen. Een host met een fysiek adres, een tijdelijk adres en een VPN-adres heeft drie kandidaten voor elke bestemming, en de route naar de VPN nomineert de derde niet automatisch.

Daarom kunnen een correcte route en een onjuiste bron zo gemakkelijk naast elkaar bestaan, en daarom kan hetzelfde verzoek zich anders gedragen vanuit een browser en vanuit een geforceerde binding. Behandel de twee opzoekingen als apart tot je bewijs hebt dat ze verbindt.

Lees de regels als een geordende competitie

RFC 6724 somt de regels in volgorde op, en elke regel doorbreekt alleen een gelijkspel dat de vorige hebben achtergelaten. Voorkeur voor de uitgaande interface en labelovereenkomst verschijnen ruim vóór de prefixvergelijking, dus een adres op de interface die de route gebruikt heeft al een voorsprong die een betere prefixovereenkomst niet kan uitwissen. Veroudering en bereik doen ook mee, en daarom wordt een verouderd adres soms niet meer gekozen zonder dat iemand het beleid wijzigt.

De praktische lezing is dat je over de winnaar niet alleen vanuit de bestemming kunt redeneren. Lijst de kandidaten op, loop de regels op volgorde door en kijk waar de beslissing werkelijk is genomen.

Merk ook op dat dit de bronhelft van het probleem is. De twee prefixvergelijkingen door elkaar halen levert verklaringen op die streng klinken en het verkeerde adres voorspellen. Zeg welke vergelijking je bedoelt telkens wanneer je het woord prefix in een ticket gebruikt.

Een applicatiebinding verandert de vraag

Een applicatie kan om een specifiek bronadres vragen, en een geldige expliciete keuze verplaatst de vraag van “welk adres zou de host verkiezen” naar “kan dat adres de bestemming bereiken en terugkomen”. Hulpmiddelen die aan een bron binden, of die aanvullende gegevens over het gekozen adres opvragen, leggen dat direct bloot, en zij zijn de snelste manier om te bewijzen welk adres een verbinding werkelijk gebruikte. Dat experiment is beter dan de routetabel voor de derde keer lezen, omdat het rapporteert wat de kernel besliste in plaats van wat jij configureerde. Herhaal het na de wijziging en vergelijk de twee antwoorden.

Dat maakt bronbinding zowel een diagnosetool als een tijdelijke oplossing: bind het VPN-adres en kijk of het verzoek slaagt. Als het slaagt, is het pad in orde en was de selectie het probleem. Als het mislukt, was het retourpad of het beleid aan de verre kant steeds het probleem.

Controleer of de verre kant die bron accepteert

Wat de host ook kiest, het moet passen binnen het beschermde bereik van de VPN en bij de retourroute en toegangsregels van het verre uiteinde. Een bron buiten de selectors kan de tunnel in reizen en aan de verre kant worden gedropt, wat eruitziet als een eenzijdige storing en op routing wordt afgeschoven. Vergelijk de gekozen binnenbron met het beschermingsbereik voordat je de versleutelingsinstellingen aanraakt, want een moduswijziging kiest niet tussen kandidaatadressen.

Houd ook het adres van het buitenste eindpunt apart in je redenering. Het identificeert transport tussen de VPN-deelnemers en is niet de bron van het applicatiepakket binnenin.

Beslis met vier waarnemingen

Noteer de gebruikte bestemming, de in aanmerking komende lokale bronnen, de werkelijk gekozen bron en het effectieve uitgaande pad. Vier regels zijn genoeg om bijna elk geval te verklaren, en ze kunnen worden vergeleken tussen een werkende en een falende host zonder de theorie opnieuw te bediscussiëren. Gebruik voor de selectiestap de eigen ondersteunde weergave van het besturingssysteem in plaats van een naam uit de standaard, omdat implementaties eigen lokale voorkeuren toevoegen.

Als het antwoord je nog steeds verrast, doet de ordening iets wat je mentale model niet doet, en de oplossing is de invoer wijzigen in plaats van met het algoritme te discussiëren. Schrijf de vier waarnemingen in het ticket en de volgende lezer kan je conclusie reproduceren.