Multilingual blog
continuous-integration/drone/push Build is passing
Details
continuous-integration/drone/push Build is passing
Details
This commit is contained in:
parent
5d742c0bf4
commit
9862b5aa22
37
config.yml
37
config.yml
|
|
@ -32,6 +32,7 @@ author:
|
|||
github: "nemunaire"
|
||||
gitlab: "nemunaire"
|
||||
bitbucket: "nemunaire"
|
||||
linkedin: "pmercier1"
|
||||
|
||||
menu:
|
||||
main:
|
||||
|
|
@ -47,3 +48,39 @@ menu:
|
|||
- name: "Talks"
|
||||
url: "talks/"
|
||||
weight: 4
|
||||
|
||||
languages:
|
||||
en:
|
||||
contentDir: content/en
|
||||
fr:
|
||||
contentDir: content/fr
|
||||
|
||||
params:
|
||||
thumb:
|
||||
- src: "https://cdn.nemunai.re/img/octotron.jpg"
|
||||
desc: "Nemubot: a smart and modulable IM bot!"
|
||||
link: "https://github.com/nemunaire/nemubot/"
|
||||
- src: "https://cdn.nemunai.re/img/book-containers-cover.jpg"
|
||||
desc: "Mon livre sur les conteneurs."
|
||||
link: "https://alpo.tf/books/2493960009/"
|
||||
- src: "https://you.p0m.fr/images/egrets"
|
||||
desc: "YouP0m: daily cute pictures."
|
||||
link: "https://you.p0m.fr/"
|
||||
- src: "https://cdn.nemunai.re/img/epita.png"
|
||||
desc: "Mon école: Épita."
|
||||
link: "http://epita.fr/"
|
||||
|
||||
menu:
|
||||
main:
|
||||
- name: "Articles"
|
||||
url: ""
|
||||
weight: 1
|
||||
- name: "Tags"
|
||||
url: "tags"
|
||||
weight: 2
|
||||
- name: "À propos"
|
||||
url: "a-propos/"
|
||||
weight: 3
|
||||
- name: "Conférences"
|
||||
url: "conferences/"
|
||||
weight: 4
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: "nemunaire"
|
||||
title: "Pierre-Olivier `nemunaire`"
|
||||
date: !!timestamp '2017-07-31T00:50:07+02:00'
|
||||
update: !!timestamp '2021-07-24T00:00:00+01:00'
|
||||
---
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: "Books"
|
||||
date: !!timestamp '2022-03-02T15:10:10+01:00'
|
||||
---
|
||||
|
||||
I publish my first book in March 2022. It is written in french.
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
title: Use the additional IPv6 blocks of the Free and Orange network
|
||||
date: !!timestamp '2023-04-05 14:43:00'
|
||||
tags:
|
||||
- network
|
||||
- ipv6
|
||||
- freebox
|
||||
---
|
||||
|
||||
With Free and Orange, when IPv6 is not disabled, the Freebox (and some Livebox) provide a /64 IPv6 range to the connected equipment.
|
||||
But it turns out that it is a /60 range that is available and usable by each subscriber.
|
||||
This represents a total of 8 addressable /64 networks.
|
||||
Let's see what it can be used for and how to use it.
|
||||
|
||||
<!-- more -->
|
||||
|
||||
# IPv6 reminders
|
||||
|
||||
Contrary to IPv4, with IPv6 one avoids making NAT, i.e. one allocates to each machine on the network an IPv6 address directly routable on Internet.
|
||||
Of course it is always necessary to go through the router (the box) which is then used as a simple gateway to the Internet.
|
||||
|
||||
In IPv6, devices are able to choose their own IP, without the help of the DHCP protocol.
|
||||
This is possible because the router regularly transmits information about the subnet in which you are located (this is the [Router Advertisement (RA)](https://en.wikipedia.org/wiki/Router_advertisement)).
|
||||
|
||||
For our experiment, let's take the following lab:
|
||||
|
||||
|
||||
|
||||
We have all our equipment connected to the box and a series of virtual machines hosted on one of the network machines.
|
||||
|
||||
At this stage, if we want our virtual machines to be reachable from the Internet in IPv6, we have to configure the hypervisor network in *bridge* mode.\
|
||||
Indeed if the network of our virtual machines is distinct from the network of the box, this one will not be able to communicate with our virtual machines. By using the *bridge* mode, we simulate the fact that the virtual machine is diconnected to the box, or to a switch. In any case no equipment requiring to make routing.
|
||||
|
||||
If our virtual machines are only IPv6 clients and are not intended to serve content directly on the Internet, this solution is perfectly acceptable. But if we want to serve content, we might want to segment our network to try to isolate the content. But if we want to serve content, we might want to segment our network to try to isolate the devices.
|
||||
|
||||
|
||||
# Segment the network of the box
|
||||
|
||||
Because of the very large number of public IPv6 addresses that our operators provide us with, we could start by segmenting our network between our virtual servers and our other equipment: each would be in a separate subnet.
|
||||
|
||||
The main interest of this segmentation would be to avoid that all this little world shares the same subnet: as they can all communicate directly with each other, it is more complicated to filter efficiently malicious exchanges. For example, if one of the virtual machines exposed on the Internet is compromised, it can access all our local equipment (telephones, connected objects, etc.) which are not necessarily secure, or conversely, an object on the network can start to intercept all the data. network object can start intercepting all the traffic of the virtual machines by pretending to be the box.
|
||||
|
||||
We could therefore want to segment our network like this:
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
Despite the large number of IPv6 addresses that can be assigned, it is not easy to subdivide our /64 to assign it to a secondary router or a virtual machine server. This segmentation is indeed not possible without changing the configuration of the box because it expects to be able to reach our virtual machines directly, without going through an intermediate machine/host/router.
|
||||
|
||||
However, we have access to the routing parameters of the other 7 /64 blocks distributed by the operator. We can for example assign one of them to the host of our virtual machines.
|
||||
|
||||
|
||||
# Delegate an additional IPv6 prefix
|
||||
|
||||
As mentioned in the introduction, some operators make available to their subscribers a range of IPv6 addresses much larger than the /64 block of the main network.
|
||||
|
||||
Some ISP routers also make it possible to take advantage of additional blocks by offering to delegate the other blocks to machines on the network.
|
||||
|
||||
In concrete terms, this means that when the box receives a packet destined for one of the delegated blocks, it will not process it itself, but will transmit it to the machine designated as the recipient. In other words, it will route the traffic of this block to the designated router. And it doesn't have to be complicated!
|
||||
|
||||
|
||||
# Different use cases
|
||||
|
||||
Now that we have seen the theory, let's look at different use cases, so we are not limited to our virtual machines:
|
||||
|
||||
- Use a /64 block to give IPv6 to its virtual machines
|
||||
- [Use a /64 block to give IPv6 to your Docker containers]({{< relref "use-ipv6-in-docker.md" >}})
|
||||
- Use a /64 block to have IPv6 in several isolated subnets
|
||||
- Use a /64 block to have public IPv6 in your Wireguard tunnel
|
||||
|
|
@ -0,0 +1,138 @@
|
|||
---
|
||||
title: Give IPv6 connectivity to its Docker containers using an IPv6 block from its ISP
|
||||
date: !!timestamp '2023-05-04 15:10:00'
|
||||
tags:
|
||||
- network
|
||||
- ipv6
|
||||
- docker
|
||||
---
|
||||
|
||||
It may seem surprising that a modern service like Docker does not offer IPv6 in containers by default, especially when in a network with IPv6.
|
||||
|
||||
In fact, for the same reason we saw in [the introductory article]({{< relref "use-additional-ipv6-blocks-from-isp.md" >}}), since the containers are in a virtual network, they cannot be reached by the box/router distributing the IPv6 subnet.
|
||||
|
||||
<!-- more -->
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
In order for the containers to have access to the Internet under these conditions, in IPv4 NAT is implemented:
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
Since NAT is generally not done on IPv6, nothing similar is done by Docker in this sense.
|
||||
|
||||
|
||||
# Docker as IPv6 router
|
||||
|
||||
Without IPv6 in a container, it is impossible for containers to address other services listening exclusively in IPv6 on the Internet.
|
||||
|
||||
In order for containerized programs to be able to connect to other services in IPv6, the *Enable IPv6* option must be activated and the prefix to be used must be defined through the *IPv6 Prefix* option.
|
||||
|
||||
Be careful, it is not enough to define these options, it is also necessary that the box correctly routes the packets to the destinations of the containers to your machine.
|
||||
|
||||
This is why we need to take advantage of the other IPv6 blocks provided by our operator. By telling the box the address of the machine hosting our containers, it will route all packets to the containers without question.
|
||||
|
||||
So not everything can be done exclusively on the machine, the network must also be configured. Let's start with that.
|
||||
|
||||
|
||||
# Set up IPv6 prefix delegation on the Freebox
|
||||
|
||||
The router will ask us for the address (IPv6) to which it should route the packets. We usually indicate a [local link IP](https://en.wikipedia.org/wiki/Link-local_address).
|
||||
|
||||
So we start by looking at our local IPv6 on the outgoing link to the router.
|
||||
|
||||
⚠️ Be careful, all interfaces have a local address, they all start with `fe80:`, they are only valid on the network card considered. If you get the wrong address, nothing will happen (it won't break your network though).
|
||||
|
||||
In my case, it is the `eth0` interface that is connected to the router:
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
My local IP is therefore `fe80::5a43:3580:173c:395e`.
|
||||
|
||||
It is this IP that I will indicate in the configuration of the router.
|
||||
|
||||
On the Freebox, the window for setting additional prefixes is in "Paramètres de la Freebox", "Configuration IPv6", under the "Général" tab. It is the "Délégation de préfixe" box that will interest us.
|
||||
|
||||
It looks like this:
|
||||
|
||||
|
||||
|
||||
Always leave the first field empty, otherwise the box will not offer you IPv6 on the main network.
|
||||
|
||||
Indicate in the next empty field (normally the second one!) the local address retrieved earlier.
|
||||
|
||||
That's all! The hardest part is over. Now let's see the Docker configuration.
|
||||
|
||||
|
||||
# Setting up Docker for IPv6
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
According to the previous screenshot, our configuration file `/etc/docker/daemon.json` should look like:
|
||||
|
||||
```
|
||||
{
|
||||
"ipv6": true,
|
||||
"fixed-cidr-v6": "2a01:1234:abcd:2421::/64"
|
||||
}
|
||||
```
|
||||
|
||||
We restart Docker and we can test:
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
If you have an IPv6 in addition to the usual IPv4, Docker is correctly configured. To find out if the configuration on the box side was successful, let's do a `ping` in the container:
|
||||
|
||||
```
|
||||
/ # 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
|
||||
```
|
||||
|
||||
If the ping responds, it's all good: your containers will now have access to and be accessible in IPv6.
|
||||
|
||||
|
||||
# Others use cases
|
||||
|
||||
This post is part of a series of posts on the use of additional IPv6 ranges:
|
||||
|
||||
- [Introduction: Use the additional IPv6 blocks of the Free and Orange network]({{< relref "use-additional-ipv6-blocks-from-isp.md" >}})
|
||||
- Use a /64 block to give IPv6 to its virtual machines
|
||||
- Use a /64 block to give IPv6 to your Docker containers
|
||||
- Use a /64 block to have IPv6 in several isolated subnets
|
||||
- Use a /64 block to have public IPv6 in your Wireguard tunnel
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
---
|
||||
title: "Pierre-Olivier `nemunaire`"
|
||||
date: !!timestamp '2017-07-31T00:50:07+02:00'
|
||||
update: !!timestamp '2021-07-24T00:00:00+01:00'
|
||||
aliases:
|
||||
- a-propos
|
||||
---
|
||||
|
||||
{{<icon "fa fa-briefcase about-icon">}}
|
||||
Aujourd'hui **entrepreneur** à la tête de différentes entreprises. J'ai travaillé avant comme **devops** pour [Novaquark](http://novaquark.com), avant d'être **ingénieur système/logiciel embarqué** chez [Qarnot computing](https://qarnot.com/), puis **responsable de la sécurité des systèmes d'information** and **architecte logiciel sénior** chez [Qarnot computing](https://qarnot.com/).
|
||||
|
||||
{{<icon "fa fa-graduation-cap about-icon">}}
|
||||
Après 5 ans d'études à l'[Epita](http://epita.fr/), j'ai, en 2014, obtenu mon diplôme d'ingénieur ! J'ai suivi les enseignements de la majeure [***Systèmes, Réseaux et Sécurité***](https://srs.epita.fr/).
|
||||
{{<br>}}
|
||||
Durant mes études, j'étais *root* (responsable du parc informatique) du [laboratoire des assistants](https://assistants.epita.fr/) ainsi que du laboratoire *Systèmes, Réseaux et Sécurité*.
|
||||
|
||||
{{<icon "fa fa-terminal about-icon">}}
|
||||
L'esprit toujours en ébulition, je travaille constamment sur de nombreux projets passionnants.
|
||||
Je passe aussi beaucoup de temps à contribuer à des projets libres : généralement à améliorer le support, la documentation et faire la promotion des **ordinateurs à base de processeurs ARM**, et maintenant RISC-V.
|
||||
{{<br>}}
|
||||
Jetez un œil à mon [instance gitea](https://git.nemunai.re) ou à mon [compte GitHub](https://github.com/nemunaire).
|
||||
|
||||
{{<icon "far fa-thumbs-down about-icon">}}
|
||||
Vous ne me trouverez pas sur les réseaux sociaux : je n'apprécie pas de gaspiller mon temps pour vendre ma vie privée gratuitement (d'ailleurs je lutte activement contre leur usage).
|
||||
|
||||
{{<icon "fa fa-heart about-icon">}}
|
||||
Découvrir de nouvelles connaissances et techniques est quelque chose que j'apprécie particulièrement (surtout dans les domaines des sciences, de la typographie, des entreprises, de la faune et de la flore, ...).
|
||||
Je recherche plus de libertés au sens large et d'indépendance.
|
||||
|
||||
{{<icon "fa fa-drum about-icon">}}
|
||||
Sur mon temps libre, je joue de [la batterie](https://storage.nemunai.re/scores/_list.html) et [cuisine](https://food.p0m.fr/).
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
---
|
||||
title: "Talks"
|
||||
date: !!timestamp '2017-07-31T00:07:37+02:00'
|
||||
aliases:
|
||||
- conferences
|
||||
---
|
||||
|
||||
Voici les supports des conférences que j'ai données :
|
||||
|
||||
* [[FR] L'authentification forte](2fa.pdf)
|
||||
* [[FR] L'autohébergement](autohebergement.pdf)
|
||||
* [[FR] Le DNS](QTechNote%20DNS.pdf)
|
||||
* [[FR] Prise en main de Docker](QTechNote%20Docker.pdf)
|
||||
* [[FR] Prise en main de gRPC/Protobuf](QTechNote%20%231.pdf)
|
||||
|
||||
|
||||
## Enseignement
|
||||
|
||||
À l'[Epita](http://www.epita.fr/), j'enseigne l'usage des conteneurs et leur fonctionnement technique au sein du noyau Linux dans un cours de 24 heures nommé [*Virtualisation légère*](https://virli.nemunai.re/) ainsi que l'[*ADministration LINux avancée*](https://adlin.nemunai.re).
|
||||
|
||||
D'autre part, j'encadre le projet de fin d'études des étudiants de la majeure SRS pour lequel ils conçoivent un [challenge de forensic](https://fic.srs.epita.fr/) pour l'[European Cyber Cup](https://european-cybercup.com), présenté au [Forum International de la Cybersécurité](https://www.forum-fic.com/).
|
||||
À ce titre, je maintiens et coordonne les développements de [la plateforme de validation](https://git.nemunai.re/fic/server).
|
||||
Loading…
Reference in New Issue