nemunaire/nemunai.re
1
0
Fork 0
Code Issues Pull Requests Releases Activity

Fix images src
Some checks are pending
continuous-integration/drone/push Build is running
Details

Browse Source
This commit is contained in:
nemunaire 2023-05-22 15:27:08 +02:00
parent 9b4814c209
commit 56f06ec8fb
4 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/en/post/use-additional-ipv6-blocks-from-isp.md
View File

@ -24,7 +24,7 @@ This is possible because the router regularly transmits information about the su
For our experiment, let's take the following lab: For our experiment, let's take the following lab:
![The basic infrastructure that we will use for our experiments](lab.png) ![The basic infrastructure that we will use for our experiments](/post/use-additional-ipv6-blocks-from-isp/lab.png)
We have all our equipment connected to the box and a series of virtual machines hosted on one of the network machines. We have all our equipment connected to the box and a series of virtual machines hosted on one of the network machines.
@ -42,7 +42,7 @@ The main interest of this segmentation would be to avoid that all this little wo
We could therefore want to segment our network like this: We could therefore want to segment our network like this:
![Example of segmentation by splitting the /64 block into two /65 blocks](lab-segmente.png) ![Example of segmentation by splitting the /64 block into two /65 blocks](/post/use-additional-ipv6-blocks-from-isp/lab-segmente.png)
We would reserve half of the /64 block for real network equipment and allocate the other half to our virtual machines located on a server/Raspberry Pi. We would reserve half of the /64 block for real network equipment and allocate the other half to our virtual machines located on a server/Raspberry Pi.

6
content/en/post/use-ipv6-in-docker.md
View File

@ -15,7 +15,7 @@ In fact, for the same reason we saw in [the introductory article]({{< relref "us
The same phenomenon can be observed with IPv4: each container has an IPv4 in a subnet separate from the one in which our host machine is located. The same phenomenon can be observed with IPv4: each container has an IPv4 in a subnet separate from the one in which our host machine is located.
![Illustration of a classic IPv4 home network](common-network-with-docker.png) ![Illustration of a classic IPv4 home network](/post/use-ipv6-in-docker/common-network-with-docker.png)
In order for the containers to have access to the Internet under these conditions, in IPv4 NAT is implemented: In order for the containers to have access to the Internet under these conditions, in IPv4 NAT is implemented:
@ -72,7 +72,7 @@ On the Freebox, the window for setting additional prefixes is in "Paramètres de
It looks like this: It looks like this:
![Freebox IPv6 prefix delegation settings window](freebox-ipv6-prefix-delegation.png) ![Freebox IPv6 prefix delegation settings window](/post/use-ipv6-in-docker/freebox-ipv6-refix-delegation.png)
Always leave the first field empty, otherwise the box will not offer you IPv6 on the main network. Always leave the first field empty, otherwise the box will not offer you IPv6 on the main network.
@ -85,7 +85,7 @@ That's all! The hardest part is over. Now let's see the Docker configuration.
We will not use the range to which our machine is connected. We are going to use a whole /64 range, the one for which we have given the local IP of our machine to the box. We will not use the range to which our machine is connected. We are going to use a whole /64 range, the one for which we have given the local IP of our machine to the box.
![Our prefix delegation correctly set up on the Freebox](freebox-ipv6-delegation-filled.png) ![Our prefix delegation correctly set up on the Freebox](/post/use-ipv6-in-docker/freebox-ipv6-delegation-filled.png)
According to the previous screenshot, our configuration file `/etc/docker/daemon.json` should look like: According to the previous screenshot, our configuration file `/etc/docker/daemon.json` should look like:

4
content/fr/post/use-additional-ipv6-blocks-from-isp.md
View File

@ -24,7 +24,7 @@ Cela est possible car le routeur émet régulièrement les informations du sous-
Pour notre expérience, prenons le lab suivant : Pour notre expérience, prenons le lab suivant :
![L´infrastructure de base qui va nous servir à faire nos expérimentations](lab.png) ![L´infrastructure de base qui va nous servir à faire nos expérimentations](/post/use-additional-ipv6-blocks-from-isp/lab.png)
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. 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.
@ -42,7 +42,7 @@ L'intérêt principal de cette segmentation serait d'éviter que tout ce petit m
On pourrait donc vouloir segmenter son réseau comme cela : On pourrait donc vouloir segmenter son réseau comme cela :
![Exemple de segmentation par le partage du bloc /64 en deux blocs /65](lab-segmente.png) ![Exemple de segmentation par le partage du bloc /64 en deux blocs /65](/post/use-additional-ipv6-blocks-from-isp/lab-segmente.png)
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. 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.

6
content/fr/post/use-ipv6-in-docker.md
View File

@ -15,7 +15,7 @@ En fait, pour la même raison que nous avons vu dans [l'article introductif]({{<
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. 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.
![Illustration d´un réseau domestique IPv4 classique](common-network-with-docker.png) ![Illustration d´un réseau domestique IPv4 classique](/post/use-ipv6-in-docker/common-network-with-docker.png)
Pour que les conteneurs aient accès à Internet dans ces conditions, en IPv4 du NAT est mis en œuvre : Pour que les conteneurs aient accès à Internet dans ces conditions, en IPv4 du NAT est mis en œuvre :
@ -72,7 +72,7 @@ Sur les Freebox, la fenêtre de paramétrage des préfixes supplémentaires se t
Cela ressemble à ça : Cela ressemble à ça :
![Fenêtre de paramétrage de la délégation de préfixe IPv6 de la Freebox](freebox-ipv6-prefix-delegation.png) ![Fenêtre de paramétrage de la délégation de préfixe IPv6 de la Freebox](/post/use-ipv6-in-docker/freebox-ipv6-prefix-delegation.png)
Laissez toujours le 1ᵉʳ champ vide, sans quoi la box ne vous proposera plus d'IPv6 sur le réseau principal. Laissez toujours le 1ᵉʳ champ vide, sans quoi la box ne vous proposera plus d'IPv6 sur le réseau principal.
@ -85,7 +85,7 @@ C'est tout ! Le plus dur est passé. Voyons maintenant la configuration de Docke
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. 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.
![Notre délégation de préfixe correctement paramétrée sur la Freebox](freebox-ipv6-delegation-filled.png) ![Notre délégation de préfixe correctement paramétrée sur la Freebox](/post/use-ipv6-in-docker/freebox-ipv6-delegation-filled.png)
Selon la capture d'écran précédente, notre fichier de configuration `/etc/docker/daemon.json` devrait ressembler à : Selon la capture d'écran précédente, notre fichier de configuration `/etc/docker/daemon.json` devrait ressembler à :