Trusted proxies

Lorsque l'agent redirection.io est utilisé comme reverse proxy, il est généralement déployé devant un ou plusieurs serveurs backend. Il peut également arriver qu'il soit déployé derrière un load balancer ou un CDN. Dans ces différents cas, l'agent doit être configuré pour faire confiance aux proxies en amont qui lui transmettent les requêtes, afin d'identifier correctement l'adresse IP du client et d'autres informations qui seraient sinon perdues lorsque la requête est transmise à l'agent.

Le nœud de configuration trusted_proxies permet d'ajuster précisément le comportement des proxies de confiance :

• lister les adresses IP des proxies auxquels vous souhaitez faire confiance
• spécifier s'il faut ou non faire individuellement confiance aux headers Forwarded, X-Forwarded-For, X-Forwarded-Proto et X-Forwarded-Host envoyés par les proxies, qui sont couramment utilisés pour transmettre l'adresse IP du client et d'autres informations

Comportement par défaut

Lorsque le nœud trusted_proxies n'est pas défini, l'agent applique les valeurs par défaut suivantes :

• toutes les adresses IP privées sont de confiance : les adresses de loopback, les adresses link-local, et les plages privées définies par la RFC 1918 (10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16)
• les headers Forwarded et X-Forwarded-For envoyés par ces proxies sont pris en compte
• les headers X-Forwarded-Proto et X-Forwarded-Host ne sont pas pris en compte

Ces deux derniers headers doivent être activés explicitement, et pour une bonne raison : leur faire confiance revient à laisser l'appelant décider du schéma et du nom de domaine utilisés pour le matching des règles et pour l'enregistrement des logs. Ne les activez que si le proxy situé devant l'agent les positionne systématiquement, en écrasant toujours la valeur qu'un client aurait pu envoyer.

Notez que la directive ips est facultative : si vous ne la définissez pas, les adresses IP privées listées ci-dessus sont considérées comme de confiance. C'est pratique lorsque l'agent est exécuté dans un conteneur ou dans un orchestrateur, où l'adresse du proxy situé devant lui n'est pas connue à l'avance.

Exécuter l'agent derrière un proxy de terminaison TLS

Il est très courant d'exécuter l'agent derrière un load balancer, un CDN, ou un autre reverse proxy (HAProxy, Varnish, nginx, Envoy, Traefik, un load balancer AWS, Cloudflare, etc.) qui termine la connexion TLS et transmet les requêtes à l'agent en HTTP simple.

Dans ce type d'installation, et tant que l'agent ne fait pas confiance au header X-Forwarded-Proto, ces requêtes sont vues comme des requêtes http, alors même que le client a effectué une requête https. Cela a deux conséquences visibles :

• les requêtes sont logguées avec le schéma http dans le manager redirection.io
• les règles utilisant des déclencheurs avec des URL absolues (https://example.com/une-page) ne matchent jamais

Pour retrouver le schéma d'origine, faites confiance au header X-Forwarded-Proto envoyé par le proxy de terminaison TLS :

L'agent détermine alors le schéma de la requête en lisant d'abord le header Forwarded, puis le header X-Forwarded-Proto, et se rabat enfin sur le schéma de la connexion qu'il a reçue. Les requêtes transmises en HTTP simple par votre proxy de terminaison TLS sont dès lors matchées et logguées en tant que requêtes https.

Il en va de même pour le nom de domaine, avec le header X-Forwarded-Host, lorsque le proxy situé devant l'agent réécrit le header Host des requêtes.

Si le proxy situé devant l'agent n'envoie aucun de ces headers, vous pouvez tout de même forcer le schéma et le domaine utilisés pour le matching, avec les directives override_request_scheme et override_request_host. Les trusted proxies restent malgré tout à privilégier, car ils préservent la valeur réelle de chaque requête.

Un exemple plus détaillé

Le nœud trusted_proxies permet également de restreindre la liste des proxies de confiance, et de désactiver les headers auxquels vous ne souhaitez pas faire confiance. Par exemple, avec la configuration suivante :

instance:
    name: 'My Instance'
reverse_proxy:
    listen:
        - 'tcp://0.0.0.0:80'
    trusted_proxies:
        ips:
            - 192.168.0.0/16
            - 172.16.0.16
        forwarded: true
        x_forwarded_for: true
        x_forwarded_host: false
        x_forwarded_proto: true
    forward:
        address: 'backend:8080'
    agent:
        project_key: my-project-key

Avec cette configuration, l'agent fera confiance aux headers Forwarded et X-Forwarded-For qui pourraient être transmis par les proxies aux adresses IP 172.16.0.16 ou dans la plage CIDR 192.168.0.0/16. Il fera également confiance au header X-Forwarded-Proto, mais pas au header X-Forwarded-Host. Les requêtes provenant de toute autre adresse IP sont considérées comme des requêtes clientes directes, et l'ensemble de leurs headers de forwarding est ignoré.