Quelle source IPv6 une requête VPN choisit, et pourquoi c’est important

Vous avez ajouté une adresse VPN et vous attendiez à ce que la requête l’utilise, mais le serveur consignait toujours l’ancien préfixe. Rien n’a échoué dans le tunnel ; l’hôte a fait un choix d’adresse source avant même de consulter la route que vous fixiez. La sélection de source IPv6 est une compétition ordonnée et distincte entre les adresses candidates de l’hôte, et le préfixe correspondant le plus long n’est qu’une règle près de la fin de cette compétition. Obtenir le résultat voulu suppose de savoir quelle règle a déjà gagné. Les règles elles-mêmes sont ennuyeuses et précises, et c’est justement pour cela qu’il faut les lire dans l’ordre.

Deux recherches, pas une

La sélection de destination choisit le saut suivant et l’interface de sortie. Ensuite, la sélection de source choisit laquelle des adresses de l’hôte apparaît dans l’en-tête, et les deux questions reçoivent des réponses de mécanismes différents alors que les deux utilisent des préfixes. Un hôte doté d’une adresse physique, d’une adresse temporaire et d’une adresse VPN a trois candidates pour n’importe quelle destination, et la route vers le VPN ne désigne pas automatiquement la troisième.

C’est pourquoi une route correcte et une source incorrecte coexistent si facilement, et pourquoi la même requête peut se comporter différemment depuis un navigateur et depuis un rattachement forcé. Traitez les deux recherches comme distinctes tant que vous n’avez pas de preuve qui les relie.

Lisez les règles comme une compétition ordonnée

La RFC 6724 énumère les règles dans l’ordre, et chacune ne départage que ce que les précédentes ont laissé. La préférence d’interface de sortie et la correspondance d’étiquette apparaissent bien avant la comparaison des préfixes, si bien qu’une adresse sur l’interface qu’utilise la route a déjà gagné un avantage qu’une meilleure correspondance de préfixe ne peut effacer. La dépréciation et la portée participent aussi, et c’est pourquoi une adresse ancienne cesse parfois d’être choisie sans que personne ne change la politique.

La lecture pratique est que vous ne pouvez pas raisonner sur le gagnant à partir de la seule destination. Listez les candidates, parcourez les règles dans l’ordre et voyez où la décision a réellement été prise.

Notez aussi que c’est la moitié source du problème. Confondre les deux comparaisons de préfixes produit des explications qui sonnent rigoureuses et prédisent la mauvaise adresse. Dites de quelle comparaison vous parlez chaque fois que vous employez le mot préfixe dans un ticket.

Le rattachement d’une application change la question

Une application peut demander une adresse source précise, et un choix explicite valide déplace la question de « quelle adresse l’hôte préférerait » vers « cette adresse peut-elle atteindre la destination et revenir ». Les outils qui se rattachent à une source, ou qui demandent des données auxiliaires sur l’adresse choisie, l’exposent directement, et ils sont le moyen le plus rapide de prouver quelle adresse une connexion a réellement utilisée. Cette expérience vaut mieux qu’une troisième lecture de la table de routage, car elle rapporte ce que le noyau a décidé et non ce que vous avez configuré. Répétez-la après le changement et comparez les deux réponses.

Cela fait du rattachement de source à la fois un outil de diagnostic et un contournement : rattachez l’adresse VPN et regardez si la requête réussit. Si elle réussit, le chemin est correct et le problème venait de la sélection. Si elle échoue, le problème était depuis le début le chemin de retour ou la politique de l’extrémité distante.

Vérifiez que l’extrémité distante accepte cette source

Quoi que choisisse l’hôte, cela doit correspondre à la portée protégée du VPN ainsi qu’à la route de retour et aux règles d’accès de l’extrémité distante. Une source hors des sélecteurs peut entrer dans le tunnel et être rejetée à l’extrémité distante, ce qui ressemble à une panne unidirectionnelle et se voit imputer au routage. Comparez la source interne choisie avec la portée de protection avant de toucher aux réglages de chiffrement, car un changement de mode ne choisit pas parmi les adresses candidates.

Gardez aussi l’adresse du point de terminaison externe à part dans votre raisonnement. Elle identifie le transport entre les participants du VPN et n’est pas la source du paquet d’application à l’intérieur.

Décidez avec quatre observations

Notez la destination utilisée, les sources locales éligibles, la source réellement choisie et le chemin de sortie effectif. Quatre lignes suffisent à expliquer presque tous les cas, et elles se comparent entre un hôte qui fonctionne et un hôte en panne sans rouvrir le débat théorique. Pour l’étape de sélection, utilisez la vue prise en charge du système d’exploitation lui-même plutôt qu’un nom de la norme, car les implémentations ajoutent leurs propres préférences locales.

Quand la réponse vous surprend encore, l’ordonnancement fait quelque chose que votre modèle mental ne fait pas, et le remède consiste à changer les entrées plutôt qu’à discuter avec l’algorithme. Écrivez les quatre observations dans le ticket et le prochain lecteur pourra reproduire votre conclusion.