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

[Emmanuel Thierry]

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 <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 <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


-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.tetaneutral.net/pipermail/technique/attachments/20221023/1fded4d7/attachment-0001.htm>