> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wirespeed.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Redirecteurs de journaux

> Envoyez des journaux à Wirespeed à l’aide d’un redirecteur dédié

De nombreuses intégrations Wirespeed acceptent les journaux provenant de pare-feu, d’équipements réseau et d’autres sources par l’intermédiaire d’un **redirecteur**. Une fois l’intégration ajoutée, Wirespeed prépare ce redirecteur et affiche les informations de connexion dont vous avez besoin.

## Configurer un redirecteur

1. Connectez-vous à Wirespeed et accédez à Intégrations > [**Ajouter une intégration**](https://app.wirespeed.co/settings/integrations?tab=browse)
2. Sélectionnez l’intégration correspondant à votre fournisseur ou à votre source de journaux, puis cliquez sur **Intégrer**
3. Définissez un **Nom de la source** afin de distinguer plusieurs instances d’un même fournisseur dans Intégrations. Ajoutez une intégration distincte pour chaque pare-feu ; consultez [Quand ai-je besoin de plusieurs redirecteurs ?](#quand-ai-je-besoin-de-plusieurs-redirecteurs)
4. Wirespeed prépare le redirecteur une fois l’intégration ajoutée
5. **Détails du redirecteur** s’ouvre automatiquement à la fin de la configuration si vous restez sur la page de l’intégration
6. Copiez l’adresse IP ou le domaine ainsi que le ou les ports d’écoute qui y sont indiqués
7. Configurez votre fournisseur ou votre source pour envoyer les journaux à l’aide de ces informations
8. Vérifiez que les journaux apparaissent dans **Événements**

La page de chaque intégration décrit les étapes propres au fournisseur, les choix de protocole et les formats.

Pour vérifier ce que reçoit votre redirecteur, dépanner des journaux manquants et des erreurs du redirecteur, ou comprendre pourquoi l’intégration est **Instable** ou **Défaillante**, utilisez l’onglet **Utilisation des données** de l’intégration. Consultez [Utilisation des données du redirecteur](https://docs.wirespeed.co/fr/integrations/forwarder-data-usage.md).

## Comprendre les informations de connexion

**Détails du redirecteur** affiche une adresse IP ou un domaine et un ou plusieurs ports d’écoute. Pour chaque port d’écoute, la connexion est indiquée comme chiffrée par TLS (**TLS : Activé**) ou non (**TLS : Désactivé**). Vos appareils envoient les journaux à cette destination. Le port identifie l’intégration Wirespeed à laquelle appartiennent les journaux, afin qu’ils apparaissent sous le bon fournisseur dans **Événements**.

## Syslog sur TLS

N’activez **Activer TLS sur le socket TCP** que si le fournisseur envoie du syslog TCP sur TLS.

Wirespeed présente un certificat Let’s Encrypt. Les navigateurs font déjà confiance à cette chaîne. Ce n’est pas le cas de nombreux pare-feu et appliances, qui peuvent nécessiter l’import d’une autorité de certification comme point de confiance (trustpoint) avant que le syslog sécurisé puisse se connecter.

### Autorité de certification racine

Importez les deux racines Let’s Encrypt comme autorités de certification de confiance (points de confiance) sur l’appareil :

* [ISRG Root X1](https://letsencrypt.org/certs/isrgrootx1.pem)
* [ISRG Root X2](https://letsencrypt.org/certs/isrgrootx2.pem)

Les chaînes Let’s Encrypt peuvent se terminer par l’une ou l’autre racine, et certaines appliances ne suivent pas le certificat à signature croisée de la chaîne. Faire confiance aux deux racines couvre les renouvellements de certificat sans autre modification.

Utilisez les racines lorsque c’est possible. Les autorités de certification intermédiaires changent plus souvent ; si vous installez l’une d’elles à la place, vous devrez peut-être mettre à jour l’appareil de nouveau plus tard.

### Inspecter la chaîne de certificats

Remplacez les espaces réservés par le domaine et le port TLS indiqués dans Détails du redirecteur. Cette commande affiche le sujet et l’émetteur de chaque certificat servi par le redirecteur :

```bash theme={null}
echo Q | openssl s_client -connect <WIRESPEED_DOMAIN>:<PORT> \
  -servername <WIRESPEED_DOMAIN> -showcerts 2>/dev/null \
| awk '
  /-----BEGIN CERTIFICATE-----/ { n++; cert = "" }
  /-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/ { cert = cert $0 "\n" }
  /-----END CERTIFICATE-----/ {
    print "--- cert " n " ---"
    printf "%s", cert | "openssl x509 -noout -subject -issuer"
    close("openssl x509 -noout -subject -issuer")
  }
'
```

Exemple de sortie (les certificats et les noms changent au fil du temps) :

```text theme={null}
--- cert 1 ---
subject=CN = forwarder.example.com
issuer=C = US, O = Let's Encrypt, CN = YE1
--- cert 2 ---
subject=C = US, O = Let's Encrypt, CN = YE1
issuer=C = US, O = ISRG, CN = Root YE
--- cert 3 ---
subject=C = US, O = ISRG, CN = Root YE
issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X2
--- cert 4 ---
subject=C = US, O = Internet Security Research Group, CN = ISRG Root X2
issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1
```

Pour lire la sortie :

* L’émetteur du **dernier** certificat est la racine nécessaire à un appareil qui suit la chaîne complète. Dans cet exemple, il s’agit d’ISRG Root X1.
* Toute `ISRG Root X*` qui apparaît comme émetteur d’un certificat **antérieur** est la racine nécessaire aux appareils qui s’arrêtent avant le certificat à signature croisée. Dans cet exemple, il s’agit d’ISRG Root X2.
* Si vous ne savez pas laquelle votre appareil nécessite, importez les deux.

> [!NOTE]
>
> La chaîne servie peut changer lors du renouvellement du certificat. Considérez la sortie ci-dessus comme un exemple, et non comme une description permanente de la chaîne.

### Vérifier avant de configurer l’appareil

Depuis un poste de travail, vérifiez qu’une racine valide le certificat du redirecteur. Téléchargez le fichier PEM de la racine depuis les liens ci-dessus (par exemple `isrgrootx1.pem`) et exécutez :

```bash theme={null}
openssl s_client -connect <WIRESPEED_DOMAIN>:<PORT> \
  -servername <WIRESPEED_DOMAIN> -verify_hostname <WIRESPEED_DOMAIN> \
  -CAfile isrgrootx1.pem -verify_return_error </dev/null
```

Une vérification réussie se termine par `Verify return code: 0 (ok)`. Un échec affiche une ligne `verify error`, par exemple `unable to get local issuer certificate`. Recommencez avec `-CAfile isrgrootx2.pem` pour vérifier l’autre racine ; la chaîne est validée par l’une ou l’autre.

### Chaîne intermédiaire

N’utilisez cette méthode que si l’appareil n’accepte pas de point de confiance racine et exige l’autorité de certification émettrice. Remplacez les espaces réservés par le domaine et le port TLS indiqués dans Détails du redirecteur :

```bash theme={null}
echo Q | openssl s_client -connect <WIRESPEED_DOMAIN>:<PORT> \
  -servername <WIRESPEED_DOMAIN> -showcerts \
| awk '
  /-----BEGIN CERTIFICATE-----/ { n++; keep = (n > 1) }
  keep { print }
  /-----END CERTIFICATE-----/ { keep = 0 }
' > chain.pem
```

`chain.pem` contient tous les certificats que le redirecteur sert après son propre certificat : la ou les autorités de certification intermédiaires et les éventuels certificats à signature croisée. Importez ce fichier sur l’appareil. Si l’appareil n’accepte qu’un certificat par import, divisez le fichier et importez les certificats un par un.

> [!WARNING]
>
> Les intermédiaires et les certificats à signature croisée changent lors du renouvellement du certificat du redirecteur. Si vous les importez, vous devez importer les nouveaux après un renouvellement. Les racines changent beaucoup moins souvent, c’est pourquoi il est préférable d’importer les racines.

### Vérifications de révocation des certificats (CRL)

Si votre pare-feu ou votre appliance vérifie la révocation (CRL) du certificat du redirecteur Wirespeed, vous devez autoriser l’accès sortant au domaine `*.c.lencr.org` (par exemple `r13.c.lencr.org`) en **HTTP (port TCP 80)**.

> [!WARNING]
>
> Si l’appareil ne peut pas joindre `*.c.lencr.org` en HTTP, la vérification CRL échoue et la connexion TLS au redirecteur peut être rejetée ; aucun journal n’arrive alors. Ajoutez `*.c.lencr.org` (HTTP) à la liste d’autorisation de votre pare-feu, ou désactivez la vérification CRL pour le point de confiance.

### Dépannage

Si les poignées de main TLS commencent à échouer juste après un renouvellement de certificat, la chaîne servie a changé. Relancez la commande d’[inspection de la chaîne](#inspecter-la-chaîne-de-certificats) et importez toute `ISRG Root X*` qu’elle affiche comme émetteur. Importer les deux racines évite ce problème dans la plupart des cas.

## Quand ai-je besoin de plusieurs redirecteurs ?

**Des fournisseurs ou services différents** nécessitent des intégrations distinctes, et donc des redirecteurs distincts. Par exemple, un pare-feu SonicWall et un déploiement Cisco Meraki disposent chacun de leurs propres informations de connexion.

**Plusieurs appareils d’un même fournisseur**, comme plusieurs pare-feu FortiGate, doivent être répartis sur plusieurs intégrations. Ajoutez une intégration par pare-feu (ou par paire haute disponibilité) et attribuez à chacune un **Nom de la source** distinct, par exemple `FortiGate - Siège Paris`. Un seul redirecteur peut atteindre ses limites de ressources lorsque le débit d’événements est élevé ; une intégration par pare-feu maintient donc une faible charge sur chaque redirecteur.

> [!NOTE]
>
> Si vous avez de nombreux pare-feu et préférez vivement ne pas configurer plusieurs redirecteurs, contactez le support Wirespeed.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.