This commit is contained in:
parent
5d742c0bf4
commit
9862b5aa22
19 changed files with 305 additions and 1 deletions
207
content/fr/post/post-mortem-cryptominer-on-CI-infrastructure.md
Normal file
207
content/fr/post/post-mortem-cryptominer-on-CI-infrastructure.md
Normal file
|
|
@ -0,0 +1,207 @@
|
|||
---
|
||||
title: Post-mortem cryptominer on CI infrastructure
|
||||
date: !!timestamp '2022-03-06 19:32:00'
|
||||
tags:
|
||||
- security
|
||||
- cryptominer
|
||||
- continuous integration
|
||||
---
|
||||
|
||||
Après les [grandes plateformes de
|
||||
cloud](https://stackoverflow.com/questions/63629722/gcp-has-suspended-my-machine-and-says-im-mining-cryptocurrency-how-do-i-fix-th),
|
||||
puis [d'intégration
|
||||
continue (CI)](https://therecord.media/github-investigating-crypto-mining-campaign-abusing-its-server-infrastructure/),
|
||||
se plaignant des cryptomineurs, il semble que la course à leur
|
||||
déploiement dans les petites installations de CI soit lancée.
|
||||
|
||||
Mon infrastructure a été la cible d'un hacker individuel hier, m'obligeant à
|
||||
changer moi aussi quelques éléments de configuration pour m'adapter à ce
|
||||
nouveau contexte.
|
||||
|
||||
<!-- more -->
|
||||
|
||||
# Une sacrée surprise pour démarrer un beau samedi
|
||||
|
||||
Dans ma quête de séparation des GAFAM et de contrôle de mes données
|
||||
personnelles, j'héberge depuis de nombreuses années une forge qui
|
||||
devient de plus en plus centrale pour mes projets.
|
||||
|
||||
Il y a quelques années, je lui ai notamment ajouté une plateforme
|
||||
d'intégration continue : d'abord uniquement sur mon architecture de
|
||||
prédilection : arm64, puis voyant tous les bienfaits de la CI, j'ai
|
||||
ajouté une première machine amd64, pour les quelques déploiements que
|
||||
j'avais besoin avec cette architecture. Ma principale utilisation est
|
||||
la composition de documents avec `pandoc`, qui n'est pas disponible
|
||||
sur d'autres architectures.
|
||||
|
||||
|
||||
# Que s'est-il passé ?
|
||||
|
||||
Samedi matin, alors que je voulais lancer une tâche de composition de
|
||||
document, via Drone, je constatais que la tâche ne se lançait
|
||||
pas. Comme il s'agit d'un machine premier prix, elle a tendance à se mettre en défaut
|
||||
facilement. Je me connecte donc dessus et constate qu'une tâche est en
|
||||
cours, pourtant rien n'est affiché dans mon interface de DroneCI.
|
||||
|
||||
Je regarde directement les journaux du conteneur afin de déterminer de
|
||||
quel projet il s'agit mais je ne le reconnais pas : il s'agit d'un
|
||||
conteneur `ubuntu` (alors que la plupart de mes conteneurs utilisent
|
||||
`alpine`), et la dernière commande ne log rien et utilise `tensorflow`.
|
||||
Cela ne correspond vraiment à aucun des projets que j'héberge sur ma
|
||||
forge.
|
||||
|
||||
Comme j'ai déjà été victime de bots de spam sur mon instance Gitea,
|
||||
mon premier réflexe fut de consulter la liste des utilisateurs
|
||||
nouvellement inscrits, pour voir s'il n'y avait pas quelqu'un que je
|
||||
ne reconnaissais pas.
|
||||
|
||||
Sur la page listant les comptes utilisateurs, je constate la présence
|
||||
d'un utilisateur fraîchement enregistré, j'apprends qu'il s'est
|
||||
connecté via GitLab et qu'il s'est déjà créé un dépôt. En parcourant
|
||||
son dépôt, je m'aperçois que c'est bien le dépôt qui est en cours
|
||||
d'exécution.
|
||||
|
||||
|
||||
# Ma première réaction
|
||||
|
||||
Maintenant que l'origine du problème était établie, j'ai commencé par
|
||||
désactiver le compte de l'utilisateur puis j'ai stoppé brutalement son
|
||||
conteneur, en utilisent `docker stop`.
|
||||
|
||||
Avant de désactiver le dépôt sur Drone, j'ai constaté que le pirate
|
||||
avait mis en place une tâche `cron` chaque heure pour relancer sa tâche
|
||||
de CI. Les tâches étant automatiquement arrêtées au bout de 60
|
||||
minutes, il avait donc toujours une tâche en cours d'exécution sur
|
||||
l'infrastructure.
|
||||
|
||||
|
||||
# Mon analyse minutieuse de la situation
|
||||
|
||||
|
||||
|
||||
Une fois le calme revenu, vient l'analyse du code et du contexte. Le
|
||||
code, qui est récupéré depuis un dépôt sur GitLab montre plusieurs
|
||||
scripts shell obfusqués par un simple encodage base64. Une fois
|
||||
décodé, on voit tout de suite que l'on a affaire à un cryptominer
|
||||
basique. Il ne semble pas y avoir un groupe bien rodé derrière cette
|
||||
intrusion, mais bien un individu qui explore les possibilités.
|
||||
|
||||
|
||||
|
||||
En remontant la piste jusqu'au portefeuille unique, on voit que les
|
||||
sommes perçues sont de l'ordre de 25$ par semaine, et cela fait une
|
||||
vingtaine de jours que notre protagoniste est actif.
|
||||
|
||||
Une rapide analyse des journaux a montré qu'il était arrivé sur mon
|
||||
instance en recherchant précisément sur Google un fichier
|
||||
`.drone.yml`. On le voit ensuite se connecter, via gitlab puis passer
|
||||
l'étape de liaison à un éventuel compte existant protégée par un
|
||||
captcha. Les temps entre chaque requête et les assets téléchargés
|
||||
laissent supposer qu'il s'agit bien d'un humain et que l'on a donc pas
|
||||
(encore) affaire à un script automatique.
|
||||
|
||||
Voici le cheminement exact :
|
||||
|
||||
1. arrivée sur git.nemunai.re depuis Google, sur un fichier `.drone.yml` ;
|
||||
1. connexion via GitLab, via le lien OAuth2 disponible ;
|
||||
1. création puis activation de son compte sur git.nemunai.re ;
|
||||
1. recherche d'un dépôt sur la page d'accueil (mais apparemment j'en ai trop) ;
|
||||
1. nouvelle arrivée depuis Google, sur un autre fichier `.drone.yml`, a priori le suivant dans la liste ;
|
||||
1. passage sur la partie publique de DroneCI ;
|
||||
1. connexion à Drone → création de l'utilisateur ;
|
||||
1. retour sur Gitea pour créer le dépôt (il choisit la migration depuis GitLab) ;
|
||||
1. synchronisation des dépôts sur Drone ;
|
||||
1. activation de son dépôt ;
|
||||
1. déclenchement manuel d'une synchronisation du dépôt afin de récupérer un nouveau commit, ce qui lance sa première tâche dans Drone ;
|
||||
1. ajout de la tâche `cron` dans Drone pour relancer sa tâche chaque heure.
|
||||
|
||||
Tout cela s'est déroulé dans un intervalle de 6 minutes, ce n'était
|
||||
donc pas un robot, mais bien un humain qui savait ce qu'il faisait.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Mon instance Gitea est reliée à un système de statistique de
|
||||
fréquentation (Umami, qui me permet de ne pas avoir de bandeau
|
||||
RGPD). Dessus, on voit effectivement la connexion depuis GitLab.com et
|
||||
l'accès au dépôt déclencheur, malgré le fait que l'utilisateur et le
|
||||
dépôt soient privés. D'après Umami, notre visiteur serait
|
||||
[indonésien](https://ipinfo.io/AS7713). Une rapide recherche sur le nom du compte GitLab qui a
|
||||
effectué la connexion montre également un profil LinkedIn indonésien
|
||||
d'un Deep Learning Specialist, ayant fait ses premiers pas sur GitLab
|
||||
il y a environ 2 semaines... Cependant le dépôt du crytominer n'est
|
||||
pas hébergé par son compte. On peut donc se demander s'il s'agit de la
|
||||
même personne ou si son compte GitLab a été compromis.
|
||||
|
||||
Dans le doute, j'ai fait un rapport d'abus sur GitLab pour cet utilisateur.
|
||||
|
||||
|
||||
|
||||
Je n'ai pas été contacté par GitLab suite à ce rapport, et je ne
|
||||
pensais d'ailleurs pas qu'il serait traité le jour même, considérant
|
||||
que d'une part il ne s'agit pas d'un problème critique comme de la
|
||||
pédo-pornographie ou similaire, et que, d'autre part, cela nécessitait
|
||||
sans doute de faire valider mon analyse par un ingénieur qualifié.
|
||||
|
||||
Toujours est-il que les deux comptes ont été bloqués dans les deux heures.
|
||||
|
||||
|
||||
# Remédiation
|
||||
|
||||
Estimant que j'avais une suffisamment bonne vision sur la situation et son
|
||||
contexte, je me suis enfin attelé à trouver les solutions pour remédier aux
|
||||
différents problèmes.
|
||||
|
||||
Tout d'abord mon instance Gitea a pour vocation d'être accessible à tous, afin
|
||||
que n'importe qui puisse facilement contribuer, notamment en faisant des
|
||||
rapports de bug ou des pull-requests sur mes projets.
|
||||
|
||||
Considérant le faible taux de création de fork, face aux problèmes que
|
||||
cela peut engendrer -- notamment via la création de pull-requests
|
||||
indésirables qui, en remplaçant la logique du `.drone.yml`, pourrait
|
||||
permettre de lancer un cryptominer jusqu'à l'expiration du délais
|
||||
d'exécution de la tâche -- j'ai donc décidé de changer le nombre maximal
|
||||
de dépôt que peut créer un nouvel utilisateur de 1 à 0. J'attendrai
|
||||
désormais qu'un utilisateur me sollicite afin de lui augmenter sa
|
||||
limite individuelle.
|
||||
|
||||
Concernant Drone, j'ai cherché une option permettant de limiter les
|
||||
utilisateurs autorisés à en faire usage.
|
||||
|
||||
Il se trouve qu'il y a justement une option :
|
||||
[`DRONE_USER_FILTER`](https://docs.drone.io/server/reference/drone-user-filter/)
|
||||
qui permet de lister les groupes d'utilisateurs et/on les utilisateurs
|
||||
individuels qui sont autorisés à se connecter.
|
||||
|
||||
Cette option répond exactement à mon besoin, je l'ai donc ajoutée aux options de
|
||||
déploiement de mon instance de DroneCI.
|
||||
|
||||
Pour être exhaustif, c'est également à ce moment que j'ai désactivé le
|
||||
dépôt du cryptominer et supprimé l'utilisateur malveillant de Drone,
|
||||
car il aurait encore pu s'y connecter.
|
||||
|
||||
|
||||
# Conclusion
|
||||
|
||||
J'ai été très agréablement surpris de la réactivité des équipes de
|
||||
GitLab : pour avoir désactivé les comptes contrevenants, malgré le
|
||||
fait que cela ne concernenait pas directement un abus des conditions
|
||||
d'utilisation de leur plateforme.
|
||||
|
||||
Je ne sais pas s'ils sont allés jusqu'à contacter tous les comptes
|
||||
pour lesquels l'utilisateur malveillant a fait usage de leur lien
|
||||
OAuth 2. D'autres infrastructures sont, en effet, toujours utilisées
|
||||
par ce hacker d'après les activités de son porte-feuille.
|
||||
|
||||
Une chose est sûre, plus que jamais, il faut bien faire attention aux
|
||||
options que l'on choisit lorsque l'on souhaite exposer un service au
|
||||
public, car on ne s'attend pas toujours à ce qui peut se passer. Et
|
||||
bien que cet utilisateur ait été bloqué, rien ne l'empêche de
|
||||
continuer de chercher de nouvelles forges à exploiter.
|
||||
|
||||
En complément, citons ce récent rapport [publié par le NCC
|
||||
Group](https://research.nccgroup.com/2022/01/13/10-real-world-stories-of-how-weve-compromised-ci-cd-pipelines/)
|
||||
à propos des principaux vecteurs de compromissions des environnements
|
||||
d'intégration continue.
|
||||
|
||||
|
||||
70
content/fr/post/use-additional-ipv6-blocks-from-isp.md
Normal file
70
content/fr/post/use-additional-ipv6-blocks-from-isp.md
Normal file
|
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
title: Utiliser les plages IPv6 supplémentaires du réseau Free et Orange
|
||||
date: !!timestamp '2023-04-05 14:43:00'
|
||||
tags:
|
||||
- network
|
||||
- ipv6
|
||||
- freebox
|
||||
---
|
||||
|
||||
Chez Free et Orange, lorsque l'on n'a pas désactivé l'IPv6 les Freebox (et certaines Livebox) mettent à disposition des équipements connectés une plage d'IPv6 /64.
|
||||
Mais il se trouve en fait que c'est une plage /60 qui est mise à disposition et utilisable par chaque abonné.
|
||||
Cela représente en tout 8 réseaux /64 adressables.
|
||||
Voyons à quoi cela peut-il bien servir et comment les utiliser.
|
||||
|
||||
<!-- more -->
|
||||
|
||||
# Rappels IPv6
|
||||
|
||||
Contrairement à l'IPv4, avec des IPv6 on évite de faire du NAT, c'est-à-dire que l'on attribue à chaque machine sur le réseau une adresse IPv6 directement routable sur Internet.
|
||||
Bien entendu il est toujours nécessaire de passer par le routeur (la box) qui sert alors de simple passerelle vers Internet.
|
||||
|
||||
En IPv6, les équipements sont capables de choisir eux-même leur IP, sans l'aide du protocole DHCP.
|
||||
Cela est possible car le routeur émet régulièrement les informations du sous-réseau dans lequel on se trouve (il s'agit du [Router Advertisement (RA)](https://en.wikipedia.org/wiki/Router_advertisement)).
|
||||
|
||||
Pour notre expérience, prenons le lab suivant :
|
||||
|
||||
|
||||
|
||||
Nous avons tous nos équipements reliés à la box et une série de machines virtuelles hébergées sur l'une des machines du réseau.
|
||||
|
||||
À ce stade, si l'on veut que nos machines virtuelles soient joignables depuis Internet en IPv6, on est obligé de configurer le réseau de l'hyperviseur en mode *bridge*.\
|
||||
En effet si le réseau de nos machines virtuelles est distinct du réseau de la box, celle-ci ne sera pas en mesure de communiquer avec nos machines virtuelles. En utilisant le mode *bridge*, on simule le fait que la machine virtuelle est directement reliée à la box, ou à un switch. En tous cas aucun équipement nécessitant de faire du routage.
|
||||
|
||||
Si nos machines virtuelles sont uniquement des clients IPv6 et n'ont pas vocation à servir directement du contenu sur Internet, cette solution est tout-à-fait acceptable. Mais si on veut servir du contenu, on pourrait vouloir segmenter notre réseau pour tenter d'isoler les équipements.
|
||||
|
||||
|
||||
# Segmenter le réseau de la box
|
||||
|
||||
Du fait du très grand nombre d'adresses IPv6 publiques que nos opérateurs nous fournissent, on pourrait commencer par vouloir segmenter notre réseau entre nos serveurs virtuels et nos autres équipements : chacun serait dans un sous-réseau séparé.
|
||||
|
||||
L'intérêt principal de cette segmentation serait d'éviter que tout ce petit monde partage le même sous-réseau : comme ils peuvent tous communiquer directement entre-eux, il est plus compliqué de filtrer efficacement les échanges malveillant. Par exemple si l'une des machines virtuelles exposée sur Internet est compromise, elle peut accéder à tous nos équipements locaux (téléphones, objects connectés, ...) qui ne sont pas forcément sécurisés, ou inversement, un objet du réseau peut se mettre à intercepter tout le trafic des machines virtuelles en se faisant passer pour la box.
|
||||
|
||||
On pourrait donc vouloir segmenter son réseau comme cela :
|
||||
|
||||
|
||||
|
||||
On réserverait la moitié du bloc /64 aux équipements réels du réseau et on attribuerait l'autre moitié à nos machines virtuelles situées sur un serveur/Raspberry Pi.
|
||||
|
||||
Malgré le très grand nombre d'adresses IPv6 que l'on peut attribuer, il n'est pas évident de subdiviser notre /64 pour l'attribuer à un routeur secondaire ou un serveur de machines virtuelles. Cette segmentation n'est en effet pas possible sans changer la configuration de la box car celle-ci s'attend à pouvoir joindre nos machines virtuelles directement, sans passer par une machine/hôte/routeur intermédiaire.
|
||||
|
||||
Cependant nous avons accès aux paramètres de routage des 7 autres blocs /64 distribués par l'opérateur. Nous pouvons par exemple en attribuer un à l'hôte de nos machines virtuelles.
|
||||
|
||||
|
||||
# Déléguer un préfixe IPv6 supplémentaire
|
||||
|
||||
Comme on le disait en introduction, certains opérateurs mettent à disposition de leur abonnés une plage d'adresses IPv6 bien plus grande que le bloc /64 du réseau principal.
|
||||
|
||||
Certaines box permettent en outre de tirer parti des blocs complémentaires en proposant de déléguer les autres blocs à des machines du réseau.
|
||||
|
||||
Concrètement, cela signifie que lorsque la box recevra un paquet à destination d'un des blocs délégués, elle ne le traitera pas elle-même, elle le transmettra à la machine désignée comme destinataire. En d'autres termes, elle routera le trafic de ce bloc vers le routeur désigné. Et ce n'est pas forcément compliqué !
|
||||
|
||||
|
||||
# Différents cas d'usage
|
||||
|
||||
Maintenant que l'on a vu la théorie, voyons justement différents cas d'usage, pour ne pas nous limiter à nos machines virtuelles :
|
||||
|
||||
- Utiliser un bloc /64 pour donner de l'IPv6 à ses machines virtuelles
|
||||
- [Utiliser un bloc /64 pour donner de l'IPv6 à ses conteneurs Docker]({{< relref "use-ipv6-in-docker.md" >}})
|
||||
- Utiliser un bloc /64 pour avoir de l'IPv6 dans plusieurs sous-réseaux isolés
|
||||
- Utiliser un bloc /64 pour avoir de l'IPv6 publique dans son tunnel Wireguard
|
||||
138
content/fr/post/use-ipv6-in-docker.md
Normal file
138
content/fr/post/use-ipv6-in-docker.md
Normal file
|
|
@ -0,0 +1,138 @@
|
|||
---
|
||||
title: Donner une connectivité IPv6 à ses conteneurs Docker en utilisant un bloc d'IPv6 de son opérateur
|
||||
date: !!timestamp '2023-05-04 15:10:00'
|
||||
tags:
|
||||
- network
|
||||
- ipv6
|
||||
- docker
|
||||
---
|
||||
|
||||
Il peut paraître étonnant qu'un service moderne comme Docker n'offre pas d'IPv6 dans les conteneurs par défaut, en particulier lorsqu'on se trouve dans un réseau avec de l'IPv6.
|
||||
|
||||
En fait, pour la même raison que nous avons vu dans [l'article introductif]({{< relref "use-additional-ipv6-blocks-from-isp.md" >}}), étant donné que les conteneurs se trouvent dans un réseau virtuel, ils ne peuvent pas être joignables par la box/le routeur distribuant le sous-réseau IPv6.
|
||||
|
||||
<!-- more -->
|
||||
|
||||
On observe d'ailleurs le même phénomène avec l'IPv4 : chaque conteneur dispose d'une IPv4 dans un sous-réseau distinct de celui dans lequel se trouve notre machine hôte.
|
||||
|
||||
|
||||
|
||||
Pour que les conteneurs aient accès à Internet dans ces conditions, en IPv4 du NAT est mis en œuvre :
|
||||
|
||||
```
|
||||
42sh$ iptables -t nat -vnL POSTROUTING
|
||||
Chain POSTROUTING (policy ACCEPT 3 packets, 228 bytes)
|
||||
pkts bytes target prot opt in out source destination
|
||||
14713 978K MASQUERADE all -- * !docker0 172.17.0.0/16 0.0.0.0/0
|
||||
```
|
||||
|
||||
Comme on ne fait généralement pas de NAT sur les IPv6, rien de similaire n'est fait par Docker dans ce sens.
|
||||
|
||||
|
||||
# Docker comme routeur IPv6
|
||||
|
||||
Sans IPv6 dans un conteneur, il est impossible pour les conteneurs de s'adresser à d'autres services écoutant exclusivement en IPv6 sur Internet.
|
||||
|
||||
Afin que les programmes conteneurisés puissent se connecter à d'autres services en IPv6, il convient d'activer l'option *Enable IPv6* et de définir le préfixe à utiliser au travers de l'option *IPv6 Prefix*.
|
||||
|
||||
Attention, ce n'est pas tout de définir ces options, il faut aussi que la box route correctement les paquets à destinations des conteneurs vers votre machine.
|
||||
|
||||
C'est pour cela que nous avons besoin de tirer parti des autres blocs d'IPv6 fournis par notre opérateur. En indiquant à la box l'adresse de notre machine hébergeant nos conteneurs, elle y routera tous les paquets à destination des conteneurs sans poser de question.
|
||||
|
||||
Tout ne peut donc pas se faire exclusivement sur la machine, le réseau doit aussi être configuré. Commençons d'ailleurs par cela.
|
||||
|
||||
|
||||
# Paramétrer la délégation de préfixe IPv6 sur la Freebox
|
||||
|
||||
La box va nous demander l'adresse (IPv6) vers laquelle elle devra router les paquets. On indique généralement une [IP de lien local](https://en.wikipedia.org/wiki/Link-local_address).
|
||||
|
||||
On commence donc par regarder quelle est notre IPv6 locale sur le lien sortant vers la box.
|
||||
|
||||
⚠️ Attention toutes les interfaces ont une adresse locale, elles commencent toutes par `fe80:`, elles ne sont valables que sur la carte réseau considérée. Si vous récupérez la mauvaise adresse, il ne se passera rien (cela ne cassera pas votre réseau pour autant).
|
||||
|
||||
Dans mon cas, c'est l'interface `eth0` qui est connectée à la box :
|
||||
|
||||
```
|
||||
42sh$ ip address show eth0
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
|
||||
link/ether fd:54:01:98:cd:ba brd ff:ff:ff:ff:ff:ff
|
||||
inet 192.168.0.42/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
|
||||
valid_lft 35141sec preferred_lft 35141sec
|
||||
inet6 2a01:...:2420:24ac:f101:c280:50c2/64 scope global noprefixroute
|
||||
valid_lft forever preferred_lft forever
|
||||
inet6 fe80::5a43:3580:173c:395e/64 scope link noprefixroute
|
||||
valid_lft forever preferred_lft forever
|
||||
```
|
||||
|
||||
Mon IP locale est donc `fe80::5a43:3580:173c:395e`.
|
||||
|
||||
C'est cette IP que je vais indiquer dans la configuration de la box.
|
||||
|
||||
Sur les Freebox, la fenêtre de paramétrage des préfixes supplémentaires se trouve dans « Paramètres de la Freebox », « Configuration IPv6 », sous l'onglet « Général ». C'est le cadre « Délégation de préfixe » qui va nous intéresser.
|
||||
|
||||
Cela ressemble à ça :
|
||||
|
||||
|
||||
|
||||
Laissez toujours le 1ᵉʳ champ vide, sans quoi la box ne vous proposera plus d'IPv6 sur le réseau principal.
|
||||
|
||||
Indiquez dans le 1ᵉʳ champ vide suivant (le deuxième a priori donc !) l'adresse locale récupérée plus tôt.
|
||||
|
||||
C'est tout ! Le plus dur est passé. Voyons maintenant la configuration de Docker.
|
||||
|
||||
|
||||
# Paramétrer Docker pour l'IPv6
|
||||
|
||||
Nous n'allons pas utiliser la plage à laquelle notre machine est connectée. Nous allons utiliser toute une plage /64, celle pour laquelle on a donné l'IP locale de notre machine à la box.
|
||||
|
||||
|
||||
|
||||
Selon la capture d'écran précédente, notre fichier de configuration `/etc/docker/daemon.json` devrait ressembler à :
|
||||
|
||||
```
|
||||
{
|
||||
"ipv6": true,
|
||||
"fixed-cidr-v6": "2a01:1234:abcd:2421::/64"
|
||||
}
|
||||
```
|
||||
|
||||
On relance Docker et on peut tester :
|
||||
|
||||
```
|
||||
42sh$ docker run -it alpine
|
||||
/ # ip address show eth0
|
||||
58: eth0@if59: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
|
||||
link/ether 02:42:ac:11:00:09 brd ff:ff:ff:ff:ff:ff
|
||||
inet 172.17.0.9/16 brd 172.17.255.255 scope global eth0
|
||||
valid_lft forever preferred_lft forever
|
||||
inet6 2a01:1234:abcd:2421:0:242:ac11:9/64 scope global flags 02
|
||||
valid_lft forever preferred_lft forever
|
||||
inet6 fe80::42:acff:fe11:9/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
```
|
||||
|
||||
Si vous avez une IPv6 en plus de l'IPv4 habituelle, c'est que Docker est correctement configuré. Pour savoir si la configuration côté box a réussi, lançons un `ping` dans le conteneur :
|
||||
|
||||
```
|
||||
/ # ping ping6.online.net
|
||||
PING ping6.online.net (2001:bc8:1::40): 56 data bytes
|
||||
64 bytes from 2001:bc8:1::40: seq=0 ttl=52 time=11.008 ms
|
||||
64 bytes from 2001:bc8:1::40: seq=1 ttl=52 time=8.822 ms
|
||||
^C
|
||||
--- ping6.online.net ping statistics ---
|
||||
2 packets transmitted, 2 packets received, 0% packet loss
|
||||
round-trip min/avg/max = 8.822/9.915/11.008 ms
|
||||
```
|
||||
|
||||
Si le ping répond, c'est tout bon : vos conteneurs auront désormais accès à et seront accessibles en IPv6.
|
||||
|
||||
|
||||
# Autres cas d'usage
|
||||
|
||||
Ce billet fait partie d'une série de billets sur l'usage des plages d'IPv6 supplémentaires :
|
||||
|
||||
- [Introduction : Utiliser les plages IPv6 supplémentaires du réseau Free et Orange]({{< relref "use-additional-ipv6-blocks-from-isp.md" >}})
|
||||
- Utiliser un bloc /64 pour donner de l'IPv6 à ses machines virtuelles
|
||||
- Utiliser un bloc /64 pour donner de l'IPv6 à ses conteneurs Docker
|
||||
- Utiliser un bloc /64 pour avoir de l'IPv6 dans plusieurs sous-réseaux isolés
|
||||
- Utiliser un bloc /64 pour avoir de l'IPv6 publique dans son tunnel Wireguard
|
||||
Loading…
Add table
Add a link
Reference in a new issue