Cinq rôles d'adresse dans un profil IPsec, et lequel est faux

Cinq tâches différentes reçoivent une adresse dans une définition de connexion typique, et elles n'ont pas à s'accorder entre elles. Les administrateurs se bloquent parce qu'un réflexe raisonnable, faire pointer tous les champs vers le même hôte, est faux pour au moins trois d'entre eux. L'issue consiste à nommer d'abord le symptôme, puis à regarder le champ ou les deux champs qui pourraient le produire.

Les cinq tâches, dans l'ordre où elles comptent

Le point de terminaison de transport est l'endroit où l'échange IKE est livré. L'identité authentifiée est le nom que chaque côté prouve, et elle est vérifiée par rapport à la politique, non par rapport à une table de routage. Les sous-réseaux protégés sont les sélecteurs qui décident quel trafic interne appartient au tunnel. Vient ensuite la source utilisée lorsque la passerelle elle-même entame une conversation, et enfin le saut suivant de la couche sous-jacente pour atteindre le pair.

Les étiquettes de participant comme left et right sont des conventions pour les deux côtés d'une connexion, pas des synonymes de local et distant. Lisez le manuel de l'implémentation réellement installée avant de supposer qu'une clé signifie ce qu'un autre produit y entendait.

Décision un : rien ne s'établit

Quand aucun échange n'apparaît du tout dans les journaux, le point de terminaison est le premier suspect : une adresse erronée, un chemin filtré ou une interface sur laquelle le démon n'écoute pas. Ne passez aux champs d'identité qu'une fois la poignée de main visible, car l'identité se juge à l'intérieur de l'échange, pas avant. Un chemin filtré et une adresse erronée se ressemblent identiquement depuis le client, vérifiez donc le côté qui écoute avant de modifier quoi que ce soit. Confirmez que le démon est lié à l'interface que vous attendez, car un service qui écoute sur une adresse ressemble exactement à un chemin bloqué.

Une adresse publique observée à travers la traduction n'est pas la même chose que l'identité qu'un pair prouve. Changer une adresse pour qu'elle corresponde à ce qu'une capture de paquets montre à l'extrémité distante est une correction courante et fausse.

Décision deux : le tunnel est monté et le trafic meurt

Les sélecteurs décident de ce qui entre dans le tunnel, et une discordance ici produit une connexion qui négocie avec succès alors que l'application échoue encore. Le côté distant doit nommer votre plage protégée comme sa plage distante, et c'est exactement là que des valeurs inversées se glissent.

Lisez les deux configurations côte à côte avant de modifier. La plage locale d'un hôte est la plage distante de l'autre, et une seule paire inversée explique un tunnel qui ne transporte rien. Rétrécissez la paire avant de toucher aux clés : un sous-réseau dans le tunnel et un autre dehors vous disent si c'est le sélecteur ou le routage qui est en cause.

Décision trois : seul le trafic propre de la passerelle échoue

Le trafic transmis pour les clients peut fonctionner parfaitement tandis qu'une requête que la passerelle entame elle-même échoue, car ce flux n'a pas de source cliente à hériter. Le réglage de source préférée existe pour ce cas, et ce n'est pas de la traduction de source : il choisit une adresse source au lieu d'en réécrire une.

Une application qui lie explicitement une autre adresse peut passer outre la préférence, confirmez donc la source réelle du paquet avant de conclure que le réglage est ignoré. Capturez sur l'interface propre de la passerelle au lieu de faire confiance à l'intention de la configuration.

Le saut suivant est une instruction locale

Le saut suivant de la couche sous-jacente indique à cet hôte comment atteindre le pair, et le côté distant n'a pas besoin de la même valeur. Le traiter comme un réglage partagé, ou coder en dur une passerelle par défaut, casse à l'instant où la route change ou qu'un second chemin apparaît.

Certaines implémentations offrent ici des valeurs spéciales. Ce que le manuel liste pour la version installée est la seule réponse sûre, et la table de routage locale est la preuve que cela a fonctionné. Quand un pair est joignable par nom mais pas par adresse, cette discordance est la trouvaille, pas un détail à contourner.

Lisez le profil des deux extrémités

Inverser les rôles sur le papier est la revue la plus rapide qui soit : échangez les plages protégées, gardez le saut suivant propre à chaque côté et l'identité propre à chaque côté. Tout ce qui ne survit pas à l'échange est probablement affecté à la mauvaise tâche.

Testez ensuite un flux par rôle : joignabilité entre pairs, un flux client interne et une requête issue de la passerelle. Trois tests vous disent quelle tâche est mal affectée sans rouvrir la configuration. Ajoutez le résultat au ticket à côté du champ que vous avez modifié, car l'ingénieur suivant rencontrera le même profil.