TCP fonctionne et UDP atteint un autre serveur sur le même port

Un profil fonctionne en TCP et échoue en UDP avec un avertissement de certificat. La lecture intuitive est que le chemin UDP a rompu la confiance, et la correction intuitive est d’accepter le certificat. Les deux hypothèses écartent une possibilité qui explique complètement le symptôme : les deux transports ont atteint des machines différentes. Une règle de transfert est appliquée par protocole, et rien n’oblige les moitiés TCP et UDP d’un même numéro de port à pointer vers le même hôte.

Un numéro de port, deux règles indépendantes

Le transfert est une consultation de table indexée sur le protocole, l’adresse de destination et le port. Une passerelle dotée d’une règle pour TCP 1194 et d’une règle pour UDP 1194 exprime deux décisions indépendantes, et celles-ci peuvent désigner des hôtes internes différents. Le numéro partagé est une commodité pour les humains, pas une propriété que le réseau impose. Traitez le numéro de port comme une étiquette et non comme une définition de service.

Regardez les règles effectives plutôt que les règles voulues. L’adresse de destination, le port traduit et l’interface d’entrée participent tous, et une règle oubliée d’une migration antérieure est la raison habituelle pour laquelle les deux moitiés ne concordent pas.

Écrivez les deux correspondances avant de modifier quoi que ce soit d’autre. La paire de lignes constitue toute l’hypothèse.

Ce que le client a réellement vérifié

Pendant la poignée de main, le client vérifie le certificat au regard de la confiance configurée et du nom qu’il attend. Un certificat inattendu est une vérification réussie qui a échoué au contrôle d’identité, ce qui est le résultat correct lorsque le pair n’est pas celui que vous vouliez joindre. Le rejeter prouve que le client fonctionne, et non que le transport est cassé. Lisez le nom signalé avant la chaîne signalée, car c’est le nom que le client a comparé.

La distinction compte parce que les deux défaillances mènent à des corrections différentes. Un problème de confiance exige une correction de confiance, tandis qu’un pair inattendu exige une correction de routage ou de transfert.

Notez quelle identité le client a signalée. Ce nom est l’indice le plus fort sur la machine qui a répondu.

Corréler la tentative avec un serveur

Notez le profil, l’adresse publique, le transport et le port utilisés par le client. Faites ensuite correspondre l’heure de la tentative au journal du serveur que vous vouliez joindre. Son absence est une piste et non la preuve d’un rejet par le pare-feu, car les niveaux de journalisation diffèrent d’un déploiement à l’autre. Un horodatage accompagné d’une adresse source restreint davantage que l’un ou l’autre seul.

Comparez l’identité du certificat rencontrée avec l’identité attendue par un canal administratif. C’est cette comparaison hors bande qui garde le contrôle fiable.

Vérifiez les anciennes règles de transfert, les écouteurs alternatifs et tout chemin d’équilibrage de charge avant de conclure que les deux transports partagent un backend. Chacun d’eux peut rediriger un flux sans toucher à l’autre transport.

Ne pas ajuster la confiance à un pair erroné

Importer l’autorité inattendue fait disparaître le symptôme et change ce en quoi le client a confiance. C’est un état pire qu’une connexion échouée, car cela masque la discordance au lieu de la résoudre. Il en va de même pour la désactivation de la vérification juste pour voir si le tunnel monte.

Si le pair se révèle légitime mais non voulu, l’action correcte est de le retirer ou de diriger la règle vers le bon hôte. Le magasin de confiance n’est pas l’endroit pour réconcilier une erreur d’inventaire.

Conservez le texte du rejet. C’est la seule trace de ce que le client a vu.

Après la correction, tester un nouveau flux

Corrigez la correspondance, puis connectez-vous avec une nouvelle session client. La traduction à état peut maintenir un flux existant vers l’ancienne destination, si bien qu’une connexion établie peut survivre au changement et vous induire en erreur. Lancez-en une nouvelle et confirmez dans le journal du serveur voulu qu’il a traité la tentative.

Si les deux transports atteignent manifestement le même serveur et se comportent encore différemment, la différence restante tient aux écouteurs et à la configuration propres à ce serveur. La comparaison des transports n’a de sens qu’une fois l’identité du point de terminaison fixée.