[technique] Logs des requêtes http en IPv6 avec Docker

Dim 23 Oct 19:26:57 CEST 2022

> Le 23 oct. 2022 à 19:06, manu chez Z <emmanuel.courcelle at zaclys.net> a écrit :
> 
> Le 23/10/2022 à 18:59, Emmanuel Thierry a écrit :
>> Bonjour,
>> 
>>> Le 23 oct. 2022 à 15:11, Laurent GUERBY via technique <technique at lists.tetaneutral.net> a écrit :
>>> 
>>> On Sun, 2022-10-23 at 14:36 +0200, manu chez Z via technique wrote:
>>>> Le 23/10/2022 à 13:56, Albert ARIBAUD a écrit :
>>>>> Bonjour,
>>>>> 
>>>>> Le dimanche 23 octobre 2022 à 12:37 +0200, manu chez Z via
>>>>> technique a
>>>>> écrit :
>>>>>> Bonjour
>>>>>> Nous (le pic) utilisons une architecture à base de conteneurs
>>>>>> docker,
>>>>>> avec un reverse-proxy connecté aux ports 80 et 443, qui renvoie
>>>>>> les
>>>>>> requêtes sur divers conteneurs en fonction du virtual host
>>>>>> demandé.
>>>>>> Il y a un gros problème avec cette architecture, car les logs du
>>>>>> proxy (et donc aussi les logs des conteneurs qui sont derrière)
>>>>>> contiennent l'adresse IP source lorsqu'il s'agit d'une requête
>>>>>> IPv4,
>>>>>> mais l'adresse IPv4 du gateway lorsqu'il s'agit de requêtes IPv6
>>>>>> !
>>>>>> Donc nous n'avons pas connaissance de l'adresse IPv6 utilisée. Un
>>>>>> exemple avec le cloud du pic, qui repose sur le travail
>>>>>> d'oxytanet
>>>>>> (mais c'est la même chose avec nos autres services):
>>>>>> web_1 | 2022-10-23T10:21:06.535228752Z 172.18.0.2 - -
>>>>>> [23/Oct/2022:10:21:06 +0000] "GET /s/xxxxxxxxxxxx HTTP/1.1" 200
>>>>>> 7447
>>>>>> "-" "curl/7.74.0" "172.18.0.1"
>>>>>> C'est très ennuyeux, ne serait-ce que pour des raisons légales.
>>>>>> Et
>>>>>> c'est de plus en plus ennuyeux, car il y a de plus en plus de
>>>>>> requêtes IPv6.
>>>>>> J'ai cherché tous les tutos du monde qui parlent de ça, mais je
>>>>>> n'ai
>>>>>> pas réussi à m'en sortir, même sur une machine de tests
>>>>>> rebootable à
>>>>>> l'envie. Est-ce que quelqu'un a déjà fait ça ?
>>>>>> Merci de votre aide !
>>>>> 
>>>>> J'ai eu le problème avec NGINX en reverse proxy d'une autre
>>>>> machine,
>>>>> mais je pense que c'est la même chose qu'avec des containers.
>>>>> 
>>>>> Ma solution s'est appuyée sur les options
>>>>> 
>>>>>      proxy_pass <URI du serveur>;
>>>>>      proxy_set_header Host $host;
>>>>>      proxy_set_header X-Forwarded-For $remote_addr;
>>>>> 
>>>>> où "proxy_pass <URI du serveur>" est la directive qui réalise le
>>>>> reverse proxy, et les deux "proxy_set_header" sont ce qui permet au
>>>>> serveur final de savoir quelle était l'adresse du vrai client.
>>>>> 
>>>>> Comme tu ne précises pas de détails sur ton reverse proxy, ce qui
>>>>> précède ne s'applique peut-être pas à ton cas, mais tu dois trouver
>>>>> l'équivalent chez Apache et autres.
>>>>> 
>>>> 
>>>> Bonjour
>>>> 
>>>> Merci de ta réponse, mais il ne s'agit pas d'un problème de 
>>>> configuration du proxy: on voit dans les logs les adresses IPv4, pas
>>>> les 
>>>> adresses IPv6. Si c'était un problème de proxy il se produirait de
>>>> la 
>>>> même manière pour les deux stacks.  Et par ailleurs nous avons le
>>>> même 
>>>> problème sur une machine qui héberge des sites web, où le reverse
>>>> proxy 
>>>> est un nginx (https://hub.docker.com/r/jwilder/nginx-proxy) et sur
>>>> la 
>>>> machine qui héberge le cloud, là il s'agit de l'infra oxytanet à base
>>>> de 
>>>> traefik (cf. https://framagit.org/oxyta.net/docker-atelier).
>>>> 
>>>> Il y a les directives dont tu parles dans la conf du proxy nginx mais
>>>> le 
>>>> problème est en amont du proxy: Docker transforme les requêtes IPv6
>>>> en 
>>>> IPv4, et au passage on perd l'information de l'adresse IPv6. J'ai 
>>>> évidemment essayé de jouer avec les options de configuration d'IPv6
>>>> dans 
>>>> Docker, mais c'est là que je me suis perdu....
>>> 
>>> En regardant les fichiers docker d'oxyta :
>>> 
>>> https://framagit.org/oxyta.net/proxyta.net/-/blob/master/prod-le/docker
>>> -compose.yml
>>> 
>>> On voit :
>>> 
>>> ipv6nat:
>>>     image: robbertkl/ipv6nat
>>> 
>>> Sur la page github de ipv6nat :
>>> 
>>> https://github.com/robbertkl/docker-ipv6nat#why-would-i-need-this
>>> 
>>> On trouve pas mal d'information sur pourquoi docker et ipv6 c'est ...
>>> compliqué. (Et rien vu sur les logs dans ipv6nat).
>> 
>> Le seul argument entendable (et vaguement évoqué dans le thread) étant que certains hébergeurs ne fournissent qu’un /128 (donc 1 IPv6) et non un /64, auquel cas tu es obligé de faire du NAT (stateful) comme en IPv4. Dans tous les autres cas il y a de meilleures solutions que le NAT. Ils voulaient juste un truc qui marchait comme en IPv4…
>> 
>> Concernant le problème initial, tu peux toujours déployer ton propre reverse proxy configuré comme il faut (avec un nginx bien entendu !).
>> 
>> Manu
>> 
>> 
> Bonjour
> 
> En fait nous avons deux serveurs avec des services docker qui se trouvent derrière un reverse proxy: sur l'un il y a nextcloud packagé par oxytanet qui repose sur traefik, sur l'autre il y a des sites webs vivant dans plusieurs conteneurs, et cette fois le reverse-proxy est le jwilder, qui repose cette fois sur nginx.
> 
> Le problème est le même dans les deux cas: on arrive facilement à avoir l'IP d'origine dans les logs lorsqu'il s'agit d'IPv4, pas du tout en IPv6. Le problème est en amont du proxy, c'est un problème de configuration de docker (pas du proxy) que je n'arrive pas à régler.

Je dirais que ça peut venir de partout :
* Des applications qui ne sauraient gérer l’entête X-Forwarded-For qu’en IPv4 et non en IPv6
* Des proxys qui ne sauraient pas remplir l’entête X-Forwarded-For dans certains cas
* De docker ou du composant NAT IPv6

Je comprends que le fait que cela apparaisse sur 2 applications différentes relayées par 2 proxys différents laisse à penser que le problème se situe en aval, mais d’un autre côté je ne vois pas comment tu pourrais te retrouver avec une adresse IPv4 dans les logs à cause d’un NAT IPv6. A ce que je vois, c’est un NAT66, pas un NAT64/46, donc il n’y a pas de translation IPv4<->IPv6 dans le réseau. Si la requête est émis en IPv6, alors en principe elle arrive au proxy en IPv6.

L'idéal serait donc de regarder ce qu’il se passe à chaque endroit, avec des logs (ou une capture mais je suppose que sous docker ça va être compliqué) :
* Entre le client et le proxy (est-ce que les paquets arrivent bien au proxy avec la bonne adresse source et destination)
* Entre le proxy et l’application

En tout cas c’est comme ça que j’aurais raisonné et cherché personnellement.

Mais je vais également laisser les gens d’oxyta répondre, probablement que tu auras une réponse plus directe. ;)

Manu