diff --git a/content/_index.en.md b/content/_index.en.md
new file mode 100644
index 0000000..07077da
--- /dev/null
+++ b/content/_index.en.md
@@ -0,0 +1,112 @@
+---
+
+title: Damien's NoteBook
+layout: hextra-home
+
+---
+
+
+
+
+{{< hextra/hero-headline >}}
+ Personal NoteBook
+ for NetDevOps and SRE
+{{< /hextra/hero-headline >}}
+
+
+
+{{< hextra/hero-subtitle style="margin:.3rem 0 2rem 0">}}
+ Documentation and NetLabs to deploy,
+ To test and practice đ
+{{< /hextra/hero-subtitle >}}
+
+
+
+
+{{< hextra/feature-grid >}}
+ {{< hextra/feature-card
+ title="Documentation"
+ subtitle="List of documents and explanations on networking or system concepts"
+ link="documentation"
+ class="hx:aspect-auto hx:md:aspect-[1.1/1] hx:max-md:min-h-[340px]"
+ image="/images/documentation.png"
+ imageClass="hx:top-[40%] hx:left-[24px] hx:w-[180%] hx:sm:w-[110%] hx:dark:opacity-80"
+ style="background: radial-gradient(ellipse at 50% 80%,rgba(58, 56, 113, 0.1),hsla(0,0%,100%,0));"
+ >}}
+ {{< hextra/feature-card
+ title="NetLab"
+ subtitle="Labs to practice with"
+ link="netlab"
+ class="hx:aspect-auto hx:md:aspect-[1.1/1] hx:max-lg:min-h-[340px]"
+ image="/images/netlab.png"
+ imageClass="hx:top-[40%] hx:left-[36px] hx:w-[180%] hx:sm:w-[110%] hx:dark:opacity-80"
+ style="background: radial-gradient(ellipse at 50% 80%,rgba(203, 28, 66, 0.1),hsla(0,0%,100%,0));"
+ >}}
+ {{< hextra/feature-card
+ title="Blog"
+ subtitle="Experience feedback and technical articles"
+ link="blog"
+ class="hx:aspect-auto hx:md:aspect-[1.1/1] hx:max-md:min-h-[340px]"
+ image="/images/blog.png"
+ imageClass="hx:top-[40%] hx:left-[36px] hx:w-[180%] hx:sm:w-[110%] hx:dark:opacity-80"
+ style="background: radial-gradient(ellipse at 50% 80%,rgba(142, 68, 173, 0.1),hsla(0,0%,100%,0));"
+ >}}
+{{< /hextra/feature-grid >}}
+
+
+
+
+ Technologies used
+
+
+ The tools and platforms I work with
+
+
+ {{< tech-banner speed="60s" height="80px" gap="4rem" >}}
+
đ Homelab Proxmox VE LXC: Gitea LXC: Runner LXC: Grafana/Ansible Scaleway Dedibox Nginx Proxy Manager âïž Internet HTTPS Wireguard VPN Wireguard VPN :3000`
+- Initial setup via the interface
+- Site URL: `https://gitea.arnodo.fr`
+
+### Network architecture: Wireguard + Nginx Proxy Manager
+
+**The problem**: Gitea runs inside my homelab (private IP), but I want to access it from the Internet.
+
+**The solution**:
+1. A **Scaleway Dedibox** with a fixed public IP and Nginx Proxy Manager
+2. A **Wireguard VPN** between the Dedibox and the homelab
+3. The reverse proxy routes `gitea.arnodo.fr` to the LXC's private IP through the tunnel
+
+**Wireguard configuration (homelab side)**:
+
+```ini
+[Interface]
+Address = 10.0.0.1/24
+PrivateKey =
+ListenPort = 51820
+
+[Peer]
+# Dedibox Scaleway
+PublicKey =
+AllowedIPs = 10.0.0.2/32
+Endpoint = :51820
+PersistentKeepalive = 25
+```
+
+**Nginx Proxy Manager**:
+- Proxy Host: `gitea.arnodo.fr`
+- Forward Hostname/IP: `10.0.0.x` (Gitea LXC IP over Wireguard)
+- Forward Port: `3000`
+- SSL: automatic Let's Encrypt
+- Websockets: Enabled
+
+### Management with Ansible
+
+To keep Gitea up to date and manage configurations, I use Ansible.
+
+**Update playbook** (`update-gitea.yml`):
+
+```yaml
+---
+- name: Update Gitea
+ hosts: gitea
+ become: yes
+ tasks:
+ - name: Update apt cache
+ apt:
+ update_cache: yes
+ cache_valid_time: 3600
+
+ - name: Upgrade Gitea and system packages
+ apt:
+ upgrade: dist
+ autoremove: yes
+ autoclean: yes
+
+ - name: Restart Gitea service
+ systemd:
+ name: gitea
+ state: restarted
+ enabled: yes
+
+ - name: Check Gitea version
+ command: gitea --version
+ register: gitea_version
+
+ - debug:
+ msg: "{{ gitea_version.stdout }}"
+```
+
+**Execution**:
+
+```bash
+ansible-playbook -i inventory.ini update-gitea.yml
+```
+
+### Monitoring with Grafana
+
+Gitea exposes Prometheus metrics (https://docs.gitea.com/administration/config-cheat-sheet#metrics-metrics)
+Configuration:
+
+**In Gitea (`app.ini`)**:
+
+```ini
+[metrics]
+ENABLED = true
+TOKEN =
+```
+
+**Prometheus scrape config**:
+
+```yaml
+scrape_configs:
+ - job_name: 'gitea'
+ metrics_path: /metrics
+ bearer_token: ''
+ static_configs:
+ - targets: [':3000']
+```
+
+**Grafana dashboard** (https://grafana.com/docs/grafana-cloud/monitor-infrastructure/integrations/integration-reference/integration-gitea/#gitea-integration-for-grafana-cloud):
+- Number of repositories, users
+- HTTP requests (rate, latency)
+- CI/CD runner status
+- LXC CPU/RAM usage
+
+### Migrating code from GitHub
+
+Simple and fast:
+Use Gitea's import feature (Settings > New Migration > GitHub), which also migrates issues and releases.
+
+### CI/CD: Deploying Hugo to Scaleway Object Storage
+
+My Hugo blog deploys automatically to Scaleway Object Storage on every push.
+
+**Installing the Gitea Runner** (https://docs.gitea.com/usage/actions/act-runner)
+
+Create the system user for the runner:
+
+```bash
+useradd -r -m -d /var/lib/gitea-runner -s /bin/bash gitea-runner
+```
+
+Here's a small script that can help install the runner directly inside an LXC:
+
+```bash
+sudo apt install -y jq curl tar # si pas dĂ©jĂ
+
+LATEST=$(curl -s 'https://gitea.com/api/v1/repos/gitea/act_runner/releases' | jq -r '.[0].tag_name')
+echo "Latest act_runner: $LATEST"
+
+# construire URL de binaire (nommage used: act_runner--)
+OS=$(uname -s | tr '[:upper:]' '[:lower:]')
+ARCH=$(uname -m)
+# Certains serveurs distribuent binaire sans tar; adapter si archive
+URL="https://gitea.com/gitea/act_runner/releases/download/${LATEST}/act_runner-${LATEST#v}-${OS}-${ARCH}"
+
+# essayer télécharger binaire
+curl -fL "$URL" -o /tmp/act_runner || {
+ echo "TĂ©lĂ©chargement direct Ă©chouĂ© â vĂ©rifier le nom exact sur la page release." >&2
+ exit 1
+}
+
+sudo mv /tmp/act_runner /usr/local/bin/act_runner
+sudo chmod +x /usr/local/bin/act_runner
+```
+
+and to verify:
+
+```bash
+/usr/local/bin/act_runner --version
+```
+
+>[!NOTE]
+> It's important to register the runner so it's recognized by Gitea.
+> For more information on configuring the runner, check the official Gitea documentation.
+> https://docs.gitea.io/fr/docs/usage/actions/runner/
+
+**Gitea Actions workflow** (`.gitea/workflows/deploy.yml`):
+
+```yaml
+name: Build and Deploy Hugo
+
+on:
+ pull_request:
+ types: [closed]
+ branches:
+ - main
+
+jobs:
+ build_and_deploy:
+ if: github.event.pull_request.merged == true
+ name: Deploy Hugo Website
+ runs-on: self-hosted
+
+ container:
+ image: debian:bookworm-slim
+
+ steps:
+ - name: Install dependencies
+ run: |
+ apt-get update
+ apt-get install -y git curl ca-certificates wget
+
+ - name: Install Hugo
+ run: |
+ wget https://github.com/gohugoio/hugo/releases/download/v0.152.2/hugo_extended_withdeploy_0.152.2_linux-amd64.deb -O /tmp/hugo.deb
+ dpkg -i /tmp/hugo.deb
+
+ - name: Checkout code
+ run: |
+ git clone --recurse-submodules https://gitea.arnodo.fr/Damien/Notebook.git /tmp/workspace
+ cd /tmp/workspace
+ git checkout ${{ github.sha }}
+
+ - name: Build site
+ run: /usr/local/bin/hugo
+ working-directory: /tmp/workspace
+
+ - name: Deploy to Scaleway
+ run: /usr/local/bin/hugo deploy --force --maxDeletes -1
+ working-directory: /tmp/workspace
+ env:
+ AWS_ACCESS_KEY_ID: ${{ secrets.SCW_ACCESS_KEY }}
+ AWS_SECRET_ACCESS_KEY: ${{ secrets.SCW_SECRET_KEY }}
+
+```
+
+**Hugo configuration** (`hugo.yaml`):
+
+```yaml
+deployment:
+ targets:
+ - name: "notebook-arnodo-fr"
+ URL: "s3://notebook-arnodo-fr?endpoint=https://s3.fr-par.scw.cloud®ion=fr-par"
+```
+
+**Scaleway Object Storage configuration**:
+1. Create a `notebook-arnodo-fr` bucket
+2. Enable "Static Website Hosting" mode
+3. Generate API credentials (Access Key + Secret Key)
+4. Add them as secrets in Gitea (Settings > Secrets > Actions)
+
+**Deployment**:
+
+```bash
+git add .
+git commit -m "New blog post"
+git push origin main
+```
+
+The workflow triggers automatically, Hugo builds the site, and deploys it to Scaleway Object Storage. The site is instantly available via the CDN.
+
+## Part 2: network labs on Scaleway
+
+### The problem
+
+Running ContainerLab with several Arista EOS instances locally is:
+- **Resource-hungry**: 4-8 GB RAM per cEOS container
+- **Local-only**: No access from outside
+- **Conflict-prone**: With other Docker/K8s services
+
+### The solution: on-demand Scaleway instances
+
+**Concept**:
+- Spin up a Scaleway instance whenever I need a lab
+- Automatically install ContainerLab/the VPN via cloud-init
+- Destroy the instance after use
+- Billed by the hour (< âŹ1 for a few hours of lab time)
+
+### Automation script: Scaleway CLI
+
+I built a Bash script that manages the entire lifecycle of a lab instance.
+
+**Features**:
+- **Creation**: Instance + Security Group (SSH from my IP only)
+- **Start/Stop**: Instance management
+- **Deletion**: Full cleanup (instance, volumes, IP, SG)
+
+**Script structure** (`scaleway-instance.sh`):
+
+```bash
+#!/bin/bash
+# Configuration
+INSTANCE_NAME="NetLab"
+ZONE="fr-par-1"
+IMAGE="debian_bookworm"
+VOLUME_SIZE=20 # GB
+USER_DATA_FILE="user_data.txt"
+SECURITY_GROUP_NAME="${INSTANCE_NAME}-SG"
+
+# DĂ©tecte l'IP publique actuelle
+get_public_ip() {
+ curl -4 -s ifconfig.me
+}
+
+# Crée un Security Group limitant SSH à l'IP publique
+create_or_update_security_group() {
+ PUBLIC_IP=$(get_public_ip)
+ # Crée le SG avec inbound SSH uniquement depuis PUBLIC_IP/32
+ # ...
+}
+
+# Actions : create, start, stop, delete
+case "$1" in
+ start)
+ # DĂ©marre l'instance existante
+ scw instance server start "$INSTANCE_ID" --wait
+ ;;
+ stop)
+ # ArrĂȘte l'instance
+ scw instance server stop "$INSTANCE_ID" --wait
+ ;;
+ delete)
+ # Supprime instance + volumes + IP + SG
+ scw instance server terminate "$INSTANCE_ID" --with-ip --with-block
+ scw instance security-group delete "$SG_ID"
+ ;;
+ *)
+ # Crée une nouvelle instance
+ create_instance "$1" # Type d'instance (DEV1-S, GP1-XS, ...)
+ ;;
+esac
+```
+
+### Cloud-init: automatic configuration
+
+The `user_data.txt` file contains the cloud-init instructions to automatically provision the instance.
+
+**Example** (`user_data.txt`):
+
+```yaml
+#cloud-config
+package_update: true
+package_upgrade: true
+
+packages:
+ - git
+ - curl
+ - docker.io
+ - docker-compose
+
+runcmd:
+ # Installation de ContainerLab
+ - bash -c "$(curl -sL https://get.containerlab.dev)"
+
+ # Clone d'un repo avec des topologies
+ - git clone https://gitea.arnodo.fr/Damien/network-labs.git /root/labs
+
+ # Démarrage d'une topologie par défaut
+ - cd /root/labs && containerlab deploy -t spine-leaf.clab.yml
+```
+
+### Practical usage
+
+**Create a lab**:
+
+```bash
+# Crée une instance DEV1-S avec 20 GB de stockage
+./scaleway-instance.sh DEV1-S 20
+
+# Attend quelques minutes pour cloud-init
+# RĂ©cupĂšre l'IP publique
+scw instance server list name=NetLab -o json | jq -r '.servers[0].public_ip.address'
+
+# SSH vers l'instance
+ssh root@
+
+# ContainerLab est déjà lancé !
+containerlab inspect
+```
+
+**Destroy the lab**:
+
+```bash
+./scaleway-instance.sh delete
+```
+
+### Raycast integration
+
+To make things even simpler, I created a Raycast script that lets me manage my instances directly from my Mac.
+
+**Raycast script**:
+
+```bash
+#!/bin/bash
+# @raycast.schemaVersion 1
+# @raycast.title Scaleway Instance
+# @raycast.mode silent
+# @raycast.icon đ„ïž
+# @raycast.argument1 { "type": "text", "placeholder": "Action or instance type" }
+# @raycast.argument2 { "type": "text", "placeholder": "Volume size", "optional": true }
+# @raycast.packageName NetLab
+
+/path/to/scaleway-instance.sh "$1" "$2"
+```
+
+**Usage**:
+- `â + Space` â "Scaleway Instance DEV1-S" â Creates the instance
+- `â + Space` â "Scaleway Instance delete" â Deletes the instance
+
+### Use case: BGP/EVPN lab with Arista
+
+**ContainerLab topology** (`spine-leaf.clab.yml`):
+
+```yaml
+name: evpn-lab
+
+topology:
+ nodes:
+ spine1:
+ kind: ceos
+ image: ceos:latest
+ spine2:
+ kind: ceos
+ image: ceos:latest
+ leaf1:
+ kind: ceos
+ image: ceos:latest
+ leaf2:
+ kind: ceos
+ image: ceos:latest
+
+ links:
+ - endpoints: ["spine1:eth1", "leaf1:eth1"]
+ - endpoints: ["spine1:eth2", "leaf2:eth1"]
+ - endpoints: ["spine2:eth1", "leaf1:eth2"]
+ - endpoints: ["spine2:eth2", "leaf2:eth2"]
+```
+
+**Workflow**:
+1. Create the Scaleway instance
+2. Cloud-init deploys the topology
+3. Configure BGP/EVPN via Ansible or manually
+4. Test, experiment
+5. Destroy the instance
+
+**Cost**: DEV1-S instance (2 vCPU, 2GB) = ~âŹ0.015/hour. 4 hours of lab time = âŹ0.06.
+
+## Digital sovereignty: why it matters
+
+This hybrid infrastructure reflects a personal conviction about digital sovereignty.
+
+### The context
+
+In my work as a network engineer, I see how important it is to be in control of your own infrastructure.
+
+Choosing Scaleway (part of the Iliad group, French) and self-hosting Gitea means:
+- **Supporting the European tech ecosystem**
+- **Ensuring GDPR compliance**: French jurisdiction
+- **Reducing latency**: Datacenters in Paris
+- **Understanding**: Owning your entire chain end-to-end
+
+### Learning by doing
+
+As a network professional (Arista, BGP/EVPN, automation), self-hosting lets me:
+- Apply Infrastructure as Code principles
+- Deeply understand CI/CD mechanics
+- Experiment without limits
+- Reproduce professional environments
+
+## Assessment
+
+### What works well
+
+**Self-hosted Gitea**:
+- Very fast and stable
+- Proxmox Helper Scripts = 5-minute install
+- Ansible handles updates cleanly
+- Grafana monitors everything
+
+**Wireguard + Nginx Proxy Manager**:
+- Secure exposure of the homelab
+- Excellent performance
+- Simple configuration
+
+**Scaleway labs**:
+- Provisioning in 3 minutes
+- Total flexibility (size, duration)
+- Predictable costs (hourly billing)
+
+**CI/CD Hugo â Scaleway Object Storage**:
+- Push-to-deploy in 2 minutes
+- Free (a few cents/month for storage)
+- Built-in CDN = ultra-fast site
+
+### The challenges
+
+**Initial complexity**:
+- Wireguard + reverse proxy = learning curve
+- First Proxmox/LXC setup = a few hours
+
+**Maintenance**:
+- Responsibility for updates (thankfully Ansible helps!)
+- Monitoring to set up yourself
+- Backups to automate
+
+**Dependencies**:
+- If the Dedibox goes down, Gitea becomes unreachable
+- Solution: failover with a second Dedibox or VPS (coming soon)
+
+## Next steps
+
+- **High availability**: A second Dedibox for failover
+- **Automatic backup**: Scripts to back up Gitea to Scaleway Object Storage
+- **More automation**: Terraform to provision the entire Scaleway infrastructure
+- **Arista MCP**: Building an MCP server to interact with network equipment via local LLMs
+- **Netbox integration**: Webhook from Netbox to a network validation pipeline
+
+## Conclusion
+
+This hybrid setup, Proxmox homelab plus Scaleway cloud, gives me control over sensitive data (code, configurations stay in the homelab), cloud resources for one-off needs, and everything hosted in France with European providers.
+
+Self-hosting hasn't saved me money (spoiler: I pay about as much as before, if not more). What it gave me is a deeper understanding of the systems I work with.
+
+For a network or DevOps engineer, it's a good environment to reproduce professional use cases and build up skills.
+
+## Resources
+
+### Documentation
+- [Gitea](https://docs.gitea.io/)
+- [Proxmox Helper Scripts](https://community-scripts.github.io/ProxmoxVE/)
+- [Scaleway CLI](https://www.scaleway.com/en/cli/)
+- [ContainerLab](https://containerlab.dev/)
+- [Nginx Proxy Manager](https://nginxproxymanager.com/)
+
+### My repos
+- [Blog Hugo](https://gitea.arnodo.fr/Damien/blog)
+- [Network Labs](https://gitea.arnodo.fr/Damien/arista-evpn-vxlan-clab) (ContainerLab topologies)
+- [Scaleway Scripts](https://gitea.arnodo.fr/Damien/scaleway-automation)
+
+### Community
+- [Proxmox Forum](https://forum.proxmox.com/)
+- [r/homelab](https://reddit.com/r/homelab)
+- [ContainerLab Slack](https://containerlab.dev/)
diff --git a/content/blog/migration-gitlab-gitea/index.fr.md b/content/blog/migration-gitlab-gitea/index.fr.md
index aea39b5..a3e6f04 100644
--- a/content/blog/migration-gitlab-gitea/index.fr.md
+++ b/content/blog/migration-gitlab-gitea/index.fr.md
@@ -15,7 +15,7 @@ Retour d'expérience sur la construction de mon infrastructure personnelle : mig
-## Contexte et Motivations
+## Contexte et motivations
En tant qu'ingénieur réseau travaillant dans le domaine de l'automatisation et de l'orchestration, j'ai toujours eu besoin d'un environnement pour expérimenter et apprendre. Jusqu'à récemment, j'utilisais GitHub pour mon code et ContainerLab en local/AWS via [DevPod](/documentation/devpod/) pour mes simulations réseau.
@@ -26,11 +26,11 @@ Mais plusieurs envies ont émergé :
- **Flexibilité** : Pouvoir lancer des labs réseau à la demande sans saturer ma machine locale
- **Automatisation** : Scripter le provisionnement complet de mes environnements
-## L'Architecture Globale
+## L'architecture globale
-### Stack Technique
+### Stack technique
**Homelab** :
- **Proxmox VE** : Hyperviseur pour VMs et LXC
@@ -48,7 +48,7 @@ Mais plusieurs envies ont émergé :
- **Instances** : Labs réseau éphémÚres provisionnés à la demande
- **Scaleway CLI** : Automatisation complĂšte
-## Partie 1 : Migration GitHub â Gitea Auto-HĂ©bergĂ©
+## Partie 1 : migration GitHub â Gitea auto-hĂ©bergĂ©
### Pourquoi Gitea ?
@@ -81,7 +81,7 @@ Le script :
- Configuration initiale via l'interface
- URL du site : `https://gitea.arnodo.fr`
-### Architecture RĂ©seau : Wireguard + Nginx Proxy Manager
+### Architecture réseau : Wireguard + Nginx Proxy Manager
**Le problÚme** : Gitea tourne dans mon homelab (IP privée), mais je veux y accéder depuis Internet.
@@ -186,7 +186,7 @@ scrape_configs:
- Ătat des runners CI/CD
- Utilisation CPU/RAM du LXC
-### Migration du Code depuis GitHub
+### Migration du code depuis GitHub
Simple et rapide :
Utiliser la fonction d'import de Gitea (Settings > New Migration > GitHub) qui migre aussi les issues et releases.
@@ -197,7 +197,7 @@ Mon blog Hugo se déploie automatiquement sur Scaleway Object Storage à chaque
**Installation de Gitea Runner** (https://docs.gitea.com/usage/actions/act-runner)
-CrĂ©er lâutilisateur systĂšme runner :
+Créer l'utilisateur systÚme runner :
```bash
useradd -r -m -d /var/lib/gitea-runner -s /bin/bash gitea-runner
@@ -313,16 +313,16 @@ git push origin main
Le workflow se déclenche automatiquement, Hugo génÚre le site, et le déploie sur Scaleway Object Storage. Le site est accessible instantanément via le CDN.
-## Partie 2 : Labs RĂ©seau sur Scaleway
+## Partie 2 : labs réseau sur Scaleway
-### Le ProblĂšme
+### Le problĂšme
ContainerLab avec plusieurs Arista EOS en local, c'est :
- **Gourmand** : 4-8 GB RAM par conteneur cEOS
- **Local** : Pas d'accÚs depuis l'extérieur
- **Conflits** : Avec d'autres services Docker/K8s
-### La Solution : Instances Scaleway Ă la Demande
+### La solution : instances Scaleway Ă la demande
**Concept** :
- Créer une instance Scaleway quand j'ai besoin d'un lab
@@ -330,7 +330,7 @@ ContainerLab avec plusieurs Arista EOS en local, c'est :
- DĂ©truire l'instance aprĂšs utilisation
- Facturation à l'heure (< 1⏠pour quelques heures de lab)
-### Script d'Automatisation : Scaleway CLI
+### Script d'automatisation : Scaleway CLI
J'ai développé un script Bash qui gÚre tout le cycle de vie d'une instance de lab.
@@ -385,7 +385,7 @@ case "$1" in
esac
```
-### Cloud-Init : Configuration Automatique
+### Cloud-init : configuration automatique
Le fichier `user_data.txt` contient les instructions cloud-init pour provisionner l'instance automatiquement.
@@ -413,7 +413,7 @@ runcmd:
- cd /root/labs && containerlab deploy -t spine-leaf.clab.yml
```
-### Utilisation Pratique
+### Utilisation pratique
**Créer un lab** :
@@ -461,7 +461,7 @@ Pour simplifier encore plus, j'ai créé un script Raycast qui me permet de gér
- `â + Space` â "Scaleway Instance DEV1-S" â CrĂ©e l'instance
- `â + Space` â "Scaleway Instance delete" â Supprime l'instance
-### Cas d'Usage : Lab BGP/EVPN avec Arista
+### Cas d'usage : lab BGP/EVPN avec Arista
**Topologie ContainerLab** (`spine-leaf.clab.yml`) :
@@ -499,11 +499,11 @@ topology:
**CoĂ»t** : Instance DEV1-S (2 vCPU, 2GB) = ~0.015âŹ/heure. 4 heures de lab = 0.06âŹ.
-## Souveraineté Numérique : Pourquoi C'est Important
+## Souveraineté numérique : pourquoi c'est important
Cette infrastructure hybride reflÚte une conviction personnelle sur la souveraineté numérique.
-### Le Contexte
+### Le contexte
Dans mon travail d'ingénieur réseau, je vois l'importance de la maßtrise de ses infrastructures.
@@ -513,7 +513,7 @@ Choisir Scaleway (groupe Iliad, français) et self-hoster Gitea, c'est :
- **RĂ©duire la latence** : Datacenters Ă Paris
- **Comprendre** : MaĂźtriser sa chaĂźne complĂšte
-### Apprentissage par la Pratique
+### Apprentissage par la pratique
En tant que professionnel du réseau (Arista, BGP/EVPN, automation), self-hoster me permet de :
- Appliquer les principes Infrastructure as Code
@@ -523,7 +523,7 @@ En tant que professionnel du réseau (Arista, BGP/EVPN, automation), self-hoster
## Bilan
-### Ce qui Fonctionne Bien
+### Ce qui fonctionne bien
**Gitea auto-hébergé** :
- TrĂšs rapide et stable
@@ -546,7 +546,7 @@ En tant que professionnel du réseau (Arista, BGP/EVPN, automation), self-hoster
- Gratuit (quelques centimes/mois pour le stockage)
- CDN intégré = site ultra rapide
-### Les DĂ©fis
+### Les défis
**Complexité initiale** :
- Wireguard + reverse proxy = courbe d'apprentissage
@@ -561,7 +561,7 @@ En tant que professionnel du réseau (Arista, BGP/EVPN, automation), self-hoster
- Si la Dedibox tombe, Gitea n'est plus accessible
- Solution : Failover avec une 2e Dedibox ou VPS (Ă venir)
-## Prochaines Ătapes
+## Prochaines Ă©tapes
- **Haute disponibilité** : Seconde Dedibox pour du failover
- **Backup automatique** : Scripts pour sauvegarder Gitea vers Scaleway Object Storage
@@ -571,16 +571,11 @@ En tant que professionnel du réseau (Arista, BGP/EVPN, automation), self-hoster
## Conclusion
-Cette infrastructure hybride (homelab Proxmox + cloud Scaleway) offre le meilleur des deux mondes :
+Cette infrastructure hybride, homelab Proxmox plus cloud Scaleway, me donne le contrÎle sur les données sensibles (code, configurations restent dans le homelab), des ressources cloud pour les besoins ponctuels, et tout est hébergé en France chez des acteurs européens.
-- **ContrÎle** : Données sensibles (code, configurations) dans le homelab
-- **Flexibilité** : Ressources cloud pour les besoins ponctuels
-- **Apprentissage** : Environnement complet pour expérimenter
-- **Souveraineté** : Tout hébergé en France, chez des acteurs européens
+Le self-hosting ne m'a pas fait économiser d'argent (spoiler : je paie autant qu'avant, voire plus). Ce qu'il m'apporte, c'est une compréhension plus profonde des systÚmes avec lesquels je travaille.
-Le self-hosting n'est pas qu'une question de coûts (spoiler : je paie autant qu'avant, voire plus), mais d'apprentissage, de maßtrise et de compréhension profonde des systÚmes.
-
-Pour un ingénieur réseau ou DevOps, c'est l'environnement idéal pour reproduire des cas d'usage professionnels et monter en compétences.
+Pour un ingénieur réseau ou DevOps, c'est un bon environnement pour reproduire des cas d'usage professionnels et monter en compétences.
## Ressources
@@ -591,7 +586,7 @@ Pour un ingénieur réseau ou DevOps, c'est l'environnement idéal pour reprodui
- [ContainerLab](https://containerlab.dev/)
- [Nginx Proxy Manager](https://nginxproxymanager.com/)
-### Mes Repos
+### Mes repos
- [Blog Hugo](https://gitea.arnodo.fr/Damien/blog)
- [Network Labs](https://gitea.arnodo.fr/Damien/arista-evpn-vxlan-clab) (topologies ContainerLab)
- [Scaleway Scripts](https://gitea.arnodo.fr/Damien/scaleway-automation)
diff --git a/content/documentation/VXLAN/_index.en.md b/content/documentation/VXLAN/_index.en.md
new file mode 100644
index 0000000..ffc3f3f
--- /dev/null
+++ b/content/documentation/VXLAN/_index.en.md
@@ -0,0 +1,13 @@
+---
+title: "VXLAN"
+sidebar:
+ open: true
+cascade:
+ type: docs
+---
+
+
+
+{{< cards >}}
+ {{< card link="/en/documentation/vxlan/beginners/vxlan-for-beginners/" title="VXLAN for Beginners" subtitle="Introduction to VXLAN" icon="science" >}}
+{{< /cards >}}
diff --git a/content/documentation/VXLAN/beginners/media_layers.en.png b/content/documentation/VXLAN/beginners/media_layers.en.png
new file mode 100644
index 0000000..472eb66
Binary files /dev/null and b/content/documentation/VXLAN/beginners/media_layers.en.png differ
diff --git a/content/documentation/VXLAN/beginners/transports.en.png b/content/documentation/VXLAN/beginners/transports.en.png
new file mode 100644
index 0000000..d9bbf14
Binary files /dev/null and b/content/documentation/VXLAN/beginners/transports.en.png differ
diff --git a/content/documentation/VXLAN/beginners/vxlan-for-beginners.en.md b/content/documentation/VXLAN/beginners/vxlan-for-beginners.en.md
new file mode 100644
index 0000000..89c15bf
--- /dev/null
+++ b/content/documentation/VXLAN/beginners/vxlan-for-beginners.en.md
@@ -0,0 +1,152 @@
+---
+title: "VXLAN for Beginners"
+date: 2024-08-01T20:00:00+02:00
+cascade:
+ type: docs
+
+---
+
+## Understanding VLAN and VXLAN: Simplified for Non-Technicians
+
+In the fast-paced world of technology, understanding networking concepts can be intimidating, especially if you're not an expert in the field.
+Today, we're going to break down two important networking concepts: **VLAN** and **VXLAN**, using simple analogies and clear explanations.
+We'll also cover their limitations, real-world use cases, and a few technical notes for the more curious among you.
+
+Let's dive in.
+
+## What is a VLAN?
+
+**VLAN (Virtual Local Area Network)** is like organizing a large office building with several departments: Marketing, Sales, HR, and IT. To keep things orderly, each department gets its own floor. That way, people from Marketing stay on their floor, people from Sales stay on theirs, and so on.
+
+A **VLAN** works similarly for computer networks. It divides a large physical network into smaller, isolated networks. Each VLAN is like a separate floor for a department, allowing devices within the same VLAN to communicate easily while keeping traffic separate from other VLANs.
+
+### Key points about VLAN
+
+- **Separation:** Keeps different groups (like departments) apart.
+- **Efficiency:** Reduces unnecessary traffic and potential network issues.
+- **Security:** Limits access and strengthens security by isolating groups.
+
+### VLAN limitations
+
+- **ID limit:** Historically, a VLAN is identified on 12 bits, allowing up to 4094 VLANs (from 1 to 4094). For a large enterprise or a datacenter, this can turn out to be insufficient.
+- **Local isolation:** VLANs are mostly designed for local use (a single site or a set of locally connected switches). As soon as you want to extend this concept across multiple sites, you need more advanced solutions.
+
+## What is VXLAN?
+
+**VXLAN (Virtual Extensible LAN)** takes things further. Imagine your company grows and expands into several buildings across the city. You still want departments to feel as if they were on their own floors, even though they're now spread across different locations. To achieve this, you create a virtual system that connects all the floors across the buildings, so that Marketing on the 3rd floor of one building is still virtually connected to Marketing on the 3rd floor of another building.
+
+**VXLAN** does exactly that for networks. It extends VLANs across multiple physical locations using a technique called **tunneling**. This way, devices in the same VLAN can communicate as if they were on the same local network, even though they're geographically far apart.
+
+### Key points about VXLAN
+
+- **Scalability:** Extends networks across different locations, and goes beyond the 4094 VLAN limit.
+- **Flexibility:** Enables larger, more dynamic network designs.
+- **Connectivity:** Ensures seamless communication across dispersed networks.
+
+## A technical deep dive into VXLAN
+
+**VXLAN** was developed to address the limitations of traditional VLANs (scalability, geographic reach). It uses a 24-bit VXLAN network identifier (**VNI**) to identify up to **16 million** logical segments, far exceeding the 4094 VLAN limit.
+
+Because of virtualization, MAC address tables in datacenters can grow very large, while physical switches have limited capacity. VXLAN addresses this challenge by using **MAC-in-UDP** encapsulation, which allows Ethernet frames (layer 2) to be carried over an IP network (layer 3).
+
+### How does it work?
+
+The goal of **VXLAN** is to **extend layer 2** across a layer 3 (IP) network. This essentially "tricks" layer 3 into making the user or virtual machine believe it's still on the same local network (layer 2).
+
+> **In plain terms:** Ethernet frames (layer 2) are encapsulated inside a UDP packet (layer 4), which is itself carried over IP (layer 3).
+
+
+
+> [!NOTE]**The "hardware" layers**
+>
+> - The **Data Link layer (2)** is commonly handled by switches.
+> - The **Network layer (3)** is commonly handled by routers.
+
+By encapsulating layer 2 within layer 3, we get the benefits of IP routing (flexibility, scalability) while retaining the isolation and simplicity of layer 2 for applications and virtual machines.
+
+### VXLAN explained through the container transport analogy
+
+#### 1. The trucks (lower layers)
+
+Picture trucks on the road. Their job is to carry containers (your data) from point A to point B. These trucks represent the **Ethernet layer** (layer 2), where each vehicle (frame) has a "license plate" (MAC address).
+
+#### 2. The train (VXLAN tunnel)
+
+When it comes to covering longer distances or crossing varied infrastructure, loading the trucks onto a train becomes more efficient. Here, **the train represents VXLAN**: it encapsulates the trucks (Ethernet frames) inside a wagon (the tunnel). Each train is identified by a **VNI (VXLAN Network Identifier)**, somewhat like a convoy number for each freight line.
+
+#### 3. The rail tracks (IP network)
+
+The train runs on rails (the **IP network**, layer 3). The rail tracks are already built and managed to find the best route: they ensure route convergence and can reroute traffic in case of a problem (failure, congestion, etc.). In the same way, the IP network automatically picks the most optimal path to carry VXLAN packets.
+
+### Key takeaways
+
+- **Overlay:** VXLAN is a transport system that sits "on top of" layer 3 (the rails). It allows multiple layer 2 networks (the trucks) to be interconnected as if they formed a single one.
+- **Dual addressing:**
+ - Trucks (Ethernet frames) are identified via **MAC addresses** (license plate).
+ - The train (VXLAN tunnel) uses **IP addresses** (route plan) to travel on the rails.
+- **Isolation and segmentation:** Just as several trains can run on the same railway line, it's possible to operate different VXLAN tunnels (each with its own VNI) over the same IP infrastructure.
+- **Elasticity and reliability:** By relying on layer 3, VXLAN benefits from all the optimizations of IP routing (route recalculation, fault tolerance, etc.).
+
+
+
+## Real-world use cases
+
+- **Multi-datacenter:** To connect several geographically dispersed datacenters while keeping the feel of a single layer 2 network.
+- **Hybrid cloud:** Extend a corporate network to a public or private cloud provider without reconfiguring the entire addressing plan.
+- **Virtual machine migration:** Enable migration (VM Mobility) between remote sites without losing layer 2 connectivity.
+- **Massive virtualization:** In very dense environments (e.g. hundreds of thousands of virtual machines), the 24-bit VNI identifier is necessary.
+
+## Controlling VXLAN: BGP EVPN and other protocols
+
+In modern deployments, especially in datacenters, VXLAN isn't simply configured statically. It's often paired with a **control plane** via the **BGP EVPN (Ethernet VPN)** protocol.
+
+- **BGP EVPN:** Allows MAC and IP table information to be exchanged between devices, facilitating automation and scalability.
+- **Other technologies:** Historically, you could come across other overlay protocols (NVGRE, STT), but VXLAN has established itself as the de facto standard.
+
+## Performance considerations
+
+- **Encapsulation overhead:** VXLAN adds an extra header (8 bytes + UDP/IP header). This can impact the **maximum frame size (MTU)**, and it's often necessary to configure a **Jumbo MTU** (typically 9000 bytes) to avoid packet fragmentation.
+- **IP network resilience:** The reliability of the VXLAN tunnel depends on the quality of the underlying IP network (routes, congestion, etc.).
+
+## Configuration example (for the curious)
+
+Here's a **simplified excerpt** of a VXLAN configuration on a Cisco NX-OS device (syntax varies by vendor):
+
+```plaintext
+interface nve1
+ no shutdown
+ source-interface loopback1
+ member vni 5001
+ ingress-replication protocol static
+ mcast-group 239.1.1.1
+```
+
+- **interface nve1:** We create an "NVE" (Network Virtualization Endpoint) interface to handle VXLAN encapsulation.
+- **source-interface loopback1:** The IP address of the loopback1 interface will be used to establish the tunnels.
+- **member vni 5001:** We associate a VNI (VXLAN Network Identifier) with our network overlay.
+
+*Note:* In more complex environments, the control plane is also configured (e.g. BGP EVPN).
+
+## Summary
+
+- **VLAN**
+ It's like having separate floors for different departments in a building, keeping their activities isolated.
+ \- **Main limitation**: 4094 VLANs maximum and a scope often limited to a single site.
+
+- **VXLAN**
+ It's like connecting those separate floors across multiple buildings, all while keeping the illusion that they're in the same building.
+ \- **Key advantages**: Huge addressing capacity (16 million segments), L2 extension over L3, flexibility for virtualization and multi-site deployments.
+
+**VXLAN** meets the need for large-scale isolation and gets around the MAC address table limits of physical switches. Paired with a control plane like BGP EVPN, it simplifies the management of modern **overlay** networks.
+
+### Conclusion
+
+If you're looking for **basic segmentation** for your local network, a **VLAN** is largely sufficient. But as soon as you want to link multiple sites, build a highly virtualized network, or go beyond the traditional 4094 VLAN limit, you need **VXLAN**.
+
+Whether you're a **network lab** enthusiast, a NetOps engineer, or simply curious about the inner workings of IT infrastructure, understanding these two concepts will help you grasp what happens as your data travels between sites, all while keeping the illusion of being "at home" on the same local network.
+
+> [!TIP] **Want to go further?**
+>
+> - Take a look at **BGP EVPN** for the VXLAN control plane.
+> - Explore **Jumbo MTU configuration** to optimize your performance.
+> - Compare VXLAN with other protocols (NVGRE, GENEVE) to understand network design choices.
diff --git a/content/documentation/VXLAN/beginners/vxlan-for-beginners.fr.md b/content/documentation/VXLAN/beginners/vxlan-for-beginners.fr.md
index 2753e7e..08ae49a 100644
--- a/content/documentation/VXLAN/beginners/vxlan-for-beginners.fr.md
+++ b/content/documentation/VXLAN/beginners/vxlan-for-beginners.fr.md
@@ -10,69 +10,69 @@ cascade:
Dans le monde rapide de la technologie, comprendre les concepts de rĂ©seau peut ĂȘtre intimidant, surtout si vous n'ĂȘtes pas un expert en la matiĂšre.
Aujourd'hui, nous allons décomposer deux concepts de réseau importants : **VLAN** et **VXLAN**, en utilisant des analogies simples et des explications claires.
-Nous aborderons Ă©galement leurs limites, leurs cas dâusage concrets, ainsi que quelques notions techniques pour les plus curieux.
+Nous aborderons Ă©galement leurs limites, leurs cas d'usage concrets, ainsi que quelques notions techniques pour les plus curieux.
-Allons-y ! đ
+Allons-y !
-## Qu'est-ce qu'un VLAN ? đą
+## Qu'est-ce qu'un VLAN ?
**VLAN (Virtual Local Area Network)**, ou Réseau Local Virtuel, c'est comme organiser un grand immeuble de bureaux avec plusieurs départements : Marketing, Ventes, RH, et Informatique. Pour maintenir l'ordre, chaque département obtient son propre étage. De cette maniÚre, les personnes du Marketing restent à leur étage, celles des Ventes au leur, et ainsi de suite.
Un **VLAN** fonctionne de maniĂšre similaire pour les rĂ©seaux informatiques. Il divise un grand rĂ©seau physique en rĂ©seaux plus petits et isolĂ©s. Chaque VLAN est comme un Ă©tage sĂ©parĂ© pour un dĂ©partement, permettant aux dispositifs au sein du mĂȘme VLAN de communiquer facilement, tout en gardant le trafic sĂ©parĂ© des autres VLAN.
-### Points clĂ©s sur le VLAN â
+### Points clés sur le VLAN
- **Séparation :** Garde les différents groupes (comme les départements) séparés.
- **Efficacité :** Réduit le trafic inutile et les potentiels problÚmes de réseau.
- **Sécurité :** Limite l'accÚs et renforce la sécurité en isolant les groupes.
-### Limites du VLAN â ïž
+### Limites du VLAN
-- **Limite dâID :** Historiquement, un VLAN est identifiĂ© sur 12 bits, permettant jusquâĂ 4094 VLANs (de 1 Ă 4094). Pour une grande entreprise ou un datacenter, cela peut sâavĂ©rer insuffisant.
-- **Isolation locale :** Les VLANs sont plutĂŽt conçus pour un usage local (un mĂȘme site ou un ensemble de switches connectĂ©s localement). DĂšs quâon veut Ă©tendre ce concept Ă plusieurs sites, on a besoin de solutions plus avancĂ©es.
+- **Limite d'ID :** Historiquement, un VLAN est identifié sur 12 bits, permettant jusqu'à 4094 VLANs (de 1 à 4094). Pour une grande entreprise ou un datacenter, cela peut s'avérer insuffisant.
+- **Isolation locale :** Les VLANs sont plutĂŽt conçus pour un usage local (un mĂȘme site ou un ensemble de switches connectĂ©s localement). DĂšs qu'on veut Ă©tendre ce concept Ă plusieurs sites, on a besoin de solutions plus avancĂ©es.
-## Qu'est-ce que le VXLAN ? đ
+## Qu'est-ce que le VXLAN ?
**VXLAN (Virtual Extensible LAN)** va plus loin. Imaginez que votre entreprise grandisse et s'Ă©tende Ă plusieurs immeubles Ă travers la ville. Vous voulez toujours que les dĂ©partements se sentent comme s'ils Ă©taient sur leurs propres Ă©tages, mĂȘme s'ils sont maintenant rĂ©partis dans diffĂ©rents endroits. Pour ce faire, vous crĂ©ez un systĂšme virtuel qui connecte tous les Ă©tages Ă travers les bĂątiments, de sorte que le Marketing au 3e Ă©tage d'un bĂątiment soit toujours virtuellement connectĂ© au Marketing du 3e Ă©tage d'un autre bĂątiment.
Le **VXLAN** fait cela pour les rĂ©seaux. Il Ă©tend les VLANs Ă travers plusieurs emplacements physiques en utilisant une technique appelĂ©e **tunneling**. Ainsi, les dispositifs dans le mĂȘme VLAN peuvent communiquer comme s'ils Ă©taient sur le mĂȘme rĂ©seau local, mĂȘme s'ils sont Ă©loignĂ©s gĂ©ographiquement.
-### Points clĂ©s sur le VXLAN â
+### Points clés sur le VXLAN
- **ĂvolutivitĂ© :** Ătend les rĂ©seaux Ă diffĂ©rents emplacements, et dĂ©passe la limite de 4094 VLANs.
- **Flexibilité :** Permet des conceptions de réseau plus grandes et dynamiques.
- **Connectivité :** Assure une communication fluide à travers des réseaux dispersés.
-## PlongĂ©e technique dans le VXLAN đ
+## Plongée technique dans le VXLAN
Le **VXLAN** a été développé pour répondre aux limites des VLANs traditionnels (scalabilité, étendue géographique). Il utilise un identifiant de réseau VXLAN (**VNI**) de 24 bits pour identifier jusqu'à **16 millions** de segments logiques, surpassant ainsi largement la limite de 4094 VLANs.
-En raison de la virtualisation, les tables d'adresses MAC dans les datacenters peuvent devenir trĂšs grandes, tandis que les switches physiques ont des capacitĂ©s limitĂ©es. Le VXLAN rĂ©pond Ă ce dĂ©fi en utilisant lâencapsulation **MAC-in-UDP**, permettant de transporter des trames Ethernet (couche 2) Ă travers un rĂ©seau IP (couche 3).
+En raison de la virtualisation, les tables d'adresses MAC dans les datacenters peuvent devenir trÚs grandes, tandis que les switches physiques ont des capacités limitées. Le VXLAN répond à ce défi en utilisant l'encapsulation **MAC-in-UDP**, permettant de transporter des trames Ethernet (couche 2) à travers un réseau IP (couche 3).
-### Comment ça marche ? đ€
+### Comment ça marche ?
-Lâobjectif du **VXLAN** est de **prolonger la couche 2** Ă travers un rĂ©seau de couche 3 (IP). Cela revient à « tromper » la couche 3 pour faire croire Ă lâutilisateur ou Ă la machine virtuelle quâil est toujours dans le mĂȘme rĂ©seau local (couche 2).
+L'objectif du **VXLAN** est de **prolonger la couche 2** Ă travers un rĂ©seau de couche 3 (IP). Cela revient à « tromper » la couche 3 pour faire croire Ă l'utilisateur ou Ă la machine virtuelle qu'il est toujours dans le mĂȘme rĂ©seau local (couche 2).
> **En clair :** On encapsule les trames Ethernet (couche 2) dans un paquet UDP (couche 4), lui-mĂȘme transportĂ© par IP (couche 3).
-> [!NOTE]**Les couches âmatĂ©riellesâ**
+> [!NOTE]**Les couches "matérielles"**
>
> - La couche **Liaison (2)** est communément gérée par des switches.
> - La couche **Réseau (3)** est communément gérée par des routeurs.
-En encapsulant la couche 2 dans la couche 3, on profite des avantages du routage IP (souplesse, scalabilitĂ©) tout en conservant lâisolation et la simplicitĂ© de la couche 2 pour les applications et machines virtuelles.
+En encapsulant la couche 2 dans la couche 3, on profite des avantages du routage IP (souplesse, scalabilité) tout en conservant l'isolation et la simplicité de la couche 2 pour les applications et machines virtuelles.
-### VXLAN expliquĂ© par lâanalogie du transport de conteneurs đ đ
+### VXLAN expliqué par l'analogie du transport de conteneurs
#### 1. Les camions (couches basses)
-Imaginez des camions sur la route. Leur mission est dâacheminer des conteneurs (vos donnĂ©es) dâun point A Ă un point B. Ces camions reprĂ©sentent la **couche Ethernet** (niveau 2), oĂč chaque vĂ©hicule (frame) possĂšde une «âŻplaque dâimmatriculationâŻÂ» (adresse MAC).
+Imaginez des camions sur la route. Leur mission est d'acheminer des conteneurs (vos donnĂ©es) d'un point A Ă un point B. Ces camions reprĂ©sentent la **couche Ethernet** (niveau 2), oĂč chaque vĂ©hicule (frame) possĂšde une «âŻplaque d'immatriculationâŻÂ» (adresse MAC).
#### 2. Le train (tunnel VXLAN)
-Quand il sâagit de couvrir de plus longues distances ou de traverser des infrastructures variĂ©es, charger les camions sur un train devient plus efficace. Ici, **le train reprĂ©sente VXLAN**âŻ: il encapsule les camions (frames Ethernet) dans un wagon (le tunnel). Chaque train est identifiĂ© par un **VNI (VXLAN Network Identifier)**, un peu comme un numĂ©ro de convoi pour chaque ligne de fret.
+Quand il s'agit de couvrir de plus longues distances ou de traverser des infrastructures variĂ©es, charger les camions sur un train devient plus efficace. Ici, **le train reprĂ©sente VXLAN**âŻ: il encapsule les camions (frames Ethernet) dans un wagon (le tunnel). Chaque train est identifiĂ© par un **VNI (VXLAN Network Identifier)**, un peu comme un numĂ©ro de convoi pour chaque ligne de fret.
#### 3. Les voies ferrées (réseau IP)
@@ -80,37 +80,37 @@ Le train roule sur des rails (le **réseau IP**, couche 3). Les voies ferrées s
### Points clés à retenir
-- **Superposition (Overlay)** : VXLAN est un systĂšme de transport «âŻpar-dessusâŻÂ» la couche 3 (les rails). Il permet dâinterconnecter plusieurs rĂ©seaux de niveau 2 (les camions) comme sâils nâen formaient quâun seul.
+- **Superposition (Overlay)** : VXLAN est un systĂšme de transport «âŻpar-dessusâŻÂ» la couche 3 (les rails). Il permet d'interconnecter plusieurs rĂ©seaux de niveau 2 (les camions) comme s'ils n'en formaient qu'un seul.
- **Double adressage** :
- - Les camions (frames Ethernet) sâidentifient via des **adresses MAC** (plaque dâimmatriculation).
+ - Les camions (frames Ethernet) s'identifient via des **adresses MAC** (plaque d'immatriculation).
- Le train (tunnel VXLAN) utilise les **adresses IP** (plan de route) pour circuler sur les rails.
-- **Isolation et segmentation** : Comme plusieurs trains peuvent rouler sur la mĂȘme ligne ferroviaire, il est possible dâexploiter diffĂ©rents tunnels VXLAN (chacun avec son VNI) sur la mĂȘme infrastructure IP.
-- **ĂlasticitĂ© et fiabilitĂ©** : En sâappuyant sur la couche 3, VXLAN profite de toutes les optimisations du routage IP (recalcul dâitinĂ©raires, tolĂ©rance aux pannes, etc.).
+- **Isolation et segmentation** : Comme plusieurs trains peuvent rouler sur la mĂȘme ligne ferroviaire, il est possible d'exploiter diffĂ©rents tunnels VXLAN (chacun avec son VNI) sur la mĂȘme infrastructure IP.
+- **ĂlasticitĂ© et fiabilitĂ©** : En s'appuyant sur la couche 3, VXLAN profite de toutes les optimisations du routage IP (recalcul d'itinĂ©raires, tolĂ©rance aux pannes, etc.).
-## Cas d'usage concrets đ
+## Cas d'usage concrets
-- **Multi-datacenter :** Pour connecter plusieurs centres de donnĂ©es gĂ©ographiquement dispersĂ©s, tout en gardant la sensation dâun rĂ©seau unique au niveau 2.
-- **Cloud hybride :** Ătendre un rĂ©seau dâentreprise vers un fournisseur de cloud public ou privĂ© sans reconfigurer tout le plan dâadressage.
+- **Multi-datacenter :** Pour connecter plusieurs centres de données géographiquement dispersés, tout en gardant la sensation d'un réseau unique au niveau 2.
+- **Cloud hybride :** Ătendre un rĂ©seau d'entreprise vers un fournisseur de cloud public ou privĂ© sans reconfigurer tout le plan d'adressage.
- **Migration de machines virtuelles :** Permettre la migration (VM Mobility) entre sites distants sans perdre la connectivité de couche 2.
-- **Virtualisation massive :** Dans les environnements trĂšs denses (par ex. des centaines de milliers de machines virtuelles), lâidentifiant VNI de 24 bits est indispensable.
+- **Virtualisation massive :** Dans les environnements trÚs denses (par ex. des centaines de milliers de machines virtuelles), l'identifiant VNI de 24 bits devient nécessaire.
-## ContrĂŽle du VXLAN : BGP EVPN et autres protocoles đ€
+## ContrĂŽle du VXLAN : BGP EVPN et autres protocoles
-Dans les dĂ©ploiements modernes, surtout en datacenter, le VXLAN nâest pas simplement configurĂ© de maniĂšre statique. Il est souvent associĂ© Ă un **contrĂŽle de plan** via le protocole **BGP EVPN (Ethernet VPN)**.
+Dans les déploiements modernes, surtout en datacenter, le VXLAN n'est pas simplement configuré de maniÚre statique. Il est souvent associé à un **contrÎle de plan** via le protocole **BGP EVPN (Ethernet VPN)**.
-- **BGP EVPN :** Permet dâĂ©changer les informations de tables MAC et IP entre les Ă©quipements, facilitant lâautomatisation et lâĂ©volutivitĂ©.
-- **Autres technologies :** Historiquement, on pouvait croiser dâautres protocoles dâoverlay (NVGRE, STT), mais VXLAN sâest imposĂ© comme standard de fait.
+- **BGP EVPN :** Permet d'échanger les informations de tables MAC et IP entre les équipements, facilitant l'automatisation et l'évolutivité.
+- **Autres technologies :** Historiquement, on pouvait croiser d'autres protocoles d'overlay (NVGRE, STT), mais VXLAN s'est imposé comme standard de fait.
-## ConsidĂ©rations de performance âïž
+## Considérations de performance
-- **Surcharge dâencapsulation :** Le VXLAN ajoute un en-tĂȘte supplĂ©mentaire (8 octets + en-tĂȘte UDP/IP). Cela peut impacter la **taille maximale de trame (MTU)** et il faut souvent configurer un **Jumbo MTU** (gĂ©nĂ©ralement 9000 octets) pour Ă©viter la fragmentation des paquets.
+- **Surcharge d'encapsulation :** Le VXLAN ajoute un en-tĂȘte supplĂ©mentaire (8 octets + en-tĂȘte UDP/IP). Cela peut impacter la **taille maximale de trame (MTU)** et il faut souvent configurer un **Jumbo MTU** (gĂ©nĂ©ralement 9000 octets) pour Ă©viter la fragmentation des paquets.
- **Résilience du réseau IP :** La fiabilité du tunnel VXLAN dépend de la qualité du réseau IP sous-jacent (routes, congestion, etc.).
-## Exemple de configuration (pour les plus curieux) đĄ
+## Exemple de configuration (pour les plus curieux)
-Voici un **extrait simplifiĂ©** dâune configuration VXLAN sur un Ă©quipement Cisco NX-OS (les syntaxes varient selon les constructeurs) :
+Voici un **extrait simplifié** d'une configuration VXLAN sur un équipement Cisco NX-OS (les syntaxes varient selon les constructeurs) :
```plaintext
interface nve1
@@ -121,32 +121,32 @@ interface nve1
mcast-group 239.1.1.1
```
-- **interface nve1 :** On crĂ©e une interface âNVEâ (Network Virtualization Endpoint) pour gĂ©rer l'encapsulation VXLAN.
-- **source-interface loopback1 :** Lâadresse IP de lâinterface loopback1 sera utilisĂ©e pour Ă©tablir les tunnels.
+- **interface nve1 :** On crée une interface "NVE" (Network Virtualization Endpoint) pour gérer l'encapsulation VXLAN.
+- **source-interface loopback1 :** L'adresse IP de l'interface loopback1 sera utilisée pour établir les tunnels.
- **member vni 5001 :** On associe un VNI (VXLAN Network Identifier) à notre overlay réseau.
*Note :* Dans les environnements plus complexes, on configure Ă©galement le plan de contrĂŽle (par ex. BGP EVPN).
-## En rĂ©sumĂ© đŻ
+## En résumé
- **VLAN**
- Câest comme avoir des Ă©tages sĂ©parĂ©s pour diffĂ©rents dĂ©partements dans un bĂątiment, en gardant leurs activitĂ©s isolĂ©es. đą
+ C'est comme avoir des étages séparés pour différents départements dans un bùtiment, en gardant leurs activités isolées.
\- **Limite majeure** : 4094 VLANs maximum et une portĂ©e souvent limitĂ©e Ă un mĂȘme site.
- **VXLAN**
- Câest comme connecter ces Ă©tages sĂ©parĂ©s Ă travers plusieurs bĂątiments, tout en gardant lâillusion quâils se trouvent dans un mĂȘme immeuble. đ
- \- **Avantages clĂ©s** : Ănorme capacitĂ© dâadressage (16 millions de segments), extension L2 sur L3, flexibilitĂ© pour la virtualisation et le multi-site.
+ C'est comme connecter ces Ă©tages sĂ©parĂ©s Ă travers plusieurs bĂątiments, tout en gardant l'illusion qu'ils se trouvent dans un mĂȘme immeuble.
+ \- **Avantages clĂ©s** : Ănorme capacitĂ© d'adressage (16 millions de segments), extension L2 sur L3, flexibilitĂ© pour la virtualisation et le multi-site.
-Le **VXLAN** répond aux besoins d'isolation à grande échelle, dépasse les limitations des tables d'adresses MAC des commutateurs et permet un déploiement flexible des services. De plus, associé à un plan de contrÎle efficace (BGP EVPN), il simplifie grandement la gestion des réseaux modernes en **overlay**.
+Le **VXLAN** répond aux besoins d'isolation à grande échelle et dépasse les limitations des tables d'adresses MAC des commutateurs. Associé à un plan de contrÎle comme BGP EVPN, il simplifie la gestion des réseaux modernes en **overlay**.
-### Conclusion đ
+### Conclusion
-En bref, si vous recherchez une **segmentation de base** pour votre réseau local, un **VLAN** est largement suffisant. Mais dÚs lors que vous voulez relier plusieurs sites, créer un réseau hautement virtualisé, ou dépasser la limite traditionnelle de 4094 VLANs, le **VXLAN** devient incontournable.
+Si vous recherchez une **segmentation de base** pour votre réseau local, un **VLAN** est largement suffisant. Mais dÚs lors que vous voulez relier plusieurs sites, créer un réseau hautement virtualisé, ou dépasser la limite traditionnelle de 4094 VLANs, le **VXLAN** devient incontournable.
-Que vous soyez un passionnĂ© de **Lab rĂ©seau**, un ingĂ©nieur NetOps, ou tout simplement curieux des dessous de lâinfrastructure informatique, comprendre ces deux notions vous aidera Ă mieux apprĂ©hender la magie qui se dĂ©roule lorsque vos donnĂ©es circulent de plus en plus loin, tout en conservant lâillusion dâĂȘtre âchez soiâ sur le mĂȘme rĂ©seau local !
+Que vous soyez un passionnĂ© de **Lab rĂ©seau**, un ingĂ©nieur NetOps, ou tout simplement curieux des dessous de l'infrastructure informatique, comprendre ces deux notions vous aidera Ă mieux saisir ce qui se passe lorsque vos donnĂ©es circulent de plus en plus loin, tout en conservant l'illusion d'ĂȘtre "chez soi" sur le mĂȘme rĂ©seau local !
-> [!TIP] **Envie dâaller plus loin ?**
+> [!TIP] **Envie d'aller plus loin ?**
>
> - Regardez du cÎté du **BGP EVPN** pour le plan de contrÎle du VXLAN.
> - Explorez la **configuration Jumbo MTU** pour optimiser vos performances.
-> - Comparez VXLAN avec dâautres protocoles (NVGRE, GENEVE) pour comprendre les choix de design rĂ©seau.
+> - Comparez VXLAN avec d'autres protocoles (NVGRE, GENEVE) pour comprendre les choix de design réseau.
diff --git a/content/documentation/_index.en.md b/content/documentation/_index.en.md
new file mode 100644
index 0000000..4b5ee8a
--- /dev/null
+++ b/content/documentation/_index.en.md
@@ -0,0 +1,16 @@
+---
+title: Documentation
+cascade:
+ type: docs
+
+---
+
+
+{{< hextra/hero-subtitle >}}
+ Comprehensive documentation and step-by-step practical guides
+{{< /hextra/hero-subtitle >}}
+
+{{< cards >}}
+ {{< card link="https://containerlab.dev/install/" title="ContainerLab" subtitle="How to Install ContainerLab" icon="endpoints" >}}
+ {{< card link="https://devpod.sh" title="DevPod" subtitle="A simple way to deploy Labs" icon="git" >}}
+{{< /cards >}}
diff --git a/content/documentation/devpod/_index.en.md b/content/documentation/devpod/_index.en.md
new file mode 100644
index 0000000..4509c4c
--- /dev/null
+++ b/content/documentation/devpod/_index.en.md
@@ -0,0 +1,317 @@
+---
+title: "DevPod on AWS"
+date: 2025-02-11T20:00:00+02:00
+weight: 1
+cascade:
+ type: docs
+---
+
+## Sources
+
+- [DevPod](https://devpod.sh/docs/what-is-devpod) âïž
+- [DevContainer](https://containers.dev) đł
+
+## Introduction
+
+In this article, I want to introduce a fantastic tool that belongs to the same family as GitPod and Codespaces: **DevPod**! It lets you create development environments effortlessly â without getting locked in to a single provider. đâ
+
+DevPod is based on the **DevContainer** architecture and uses the specifications contained in a [devcontainer.json](https://containers.dev) file to launch your development environment. Personally, I use it to quickly deploy network mockups with ContainerLab. đ»đ§°
+
+## What is a DevContainer?
+
+A development container (often called a "dev container") lets you use a container as a full-fledged development environment. (Check out the official [containers.dev](https://containers.dev) documentation for more details.)
+
+Let's break it down:
+
+Have you ever heard the phrase "It works on my machine"? If you're a developer, you've probably run into this problem when collaborating with others. But guess what? **DevContainers** solve the problem of environment drift by providing consistent, reproducible Docker environments. Say goodbye to installation headaches! đââïž
+
+With DevContainers, all you need is:
+
+1. A `.devcontainer` folder in your project.
+2. A `devcontainer.json` file that tells VS Code how to configure the container.
+3. Docker installed locally
+
+The cornerstone of the DevContainer is the `devcontainer.json` file. For example:
+
+```json
+{
+ "name": "Python DevContainer",
+ "image": "mcr.microsoft.com/devcontainers/python:3.10",
+ "features": {
+ "docker-in-docker": "latest"
+ },
+ "extensions": [
+ "ms-python.python",
+ "ms-azuretools.vscode-docker"
+ ]
+}
+```
+
+**What's happening here?** đ”ïžââïž
+
+- **"image"** â This uses a ready-to-use Python 3.10 environment.
+- **"features"** â This adds Docker support inside the container.
+- **"extensions"** â Installs useful extensions for Python and Docker in VS Code.
+
+DevContainers are great for local development, but sometimes you need more power â maybe your workloads are huge, or you want to run specialized labs. That's where **DevPod** comes in. đȘ
+**So you can easily deploy labs to the Cloud**
+
+## What is DevPod?
+
+**DevPod** is an open-source tool that lets you launch development environments either on your local machine or in the cloud provider of your choice. Think of it as a self-hosted, highly customizable version of GitHub Codespaces. đ
+
+In my day-to-day networking adventures, I deploy ContainerLab-based setups with DevContainers on AWS. Let's see how you can use DevPod to do exactly that (details on ContainerLab will follow in another article, I promise!). đ
+
+## AWS provider
+
+DevPod uses **Providers**, which are configuration modules that define where and how DevPod launches your environment. Here's the list of providers:
+
+
+
+We're going to focus on the **AWS Provider** â even though there are plenty of configuration options:
+
+
+
+Before you panic at all these settings, don't worry. If you're just doing a bit of experimenting, the default values will usually do the job. đ
+
+> [!NOTE] **The perks of open source**
+>
+> The fact that DevPod is open-source means you can peek under the hood to see exactly how it works. Check out the AWS code [here](https://github.com/loft-sh/devpod-provider-aws/tree/main) if you're curious.
+
+## How the AWS code works
+
+Let's look at what DevPod does on AWS by examining the [aws.go code](https://github.com/loft-sh/devpod-provider-aws/blob/main/pkg/aws/aws.go). At a high level, it handles:
+
+1. **Initialization**: Reading the configuration and setting up the AWS SDK clients (with custom credentials if needed).
+2. **Networking**: Finding or creating the appropriate subnet, VPC, and security groups.
+3. **AMI selection**: Choosing a suitable AMI (by default, a recent Ubuntu 22.04 image) and determining the root device.
+4. **IAM setup**: Verifying that an appropriate instance role and instance profile exist, along with the associated policies.
+5. **Instance lifecycle**: Creating, starting, stopping, checking the status of, and deleting instances.
+6. **User data injection**: Generating a script (Base64-encoded) that configures the instance (adds users and SSH keys) on first boot.
+7. **Optional DNS**: Managing Route 53 records for the instance if the configuration requires it.
+
+From my perspective, two points stand out as potentially the most critical:
+
+- **(#4) IAM setup**
+- **(#6) User data injection**
+
+### Why are points #4 and #6 "tricky"?
+
+- **IAM setup** is mainly handled by the `CreateDevpodInstanceProfile` function. It creates a role named `devpod-ec2-role` that can perform the following operations:
+ - **EC2 operations**: For example, it can describe or stop instances â in particular, the instance associated with it.
+ - **SSM operations**: By attaching the AmazonSSMManagedInstanceCore policy, the instance can be managed by AWS Systems Manager.
+ - **KMS operations (optional)**: If configured, it can run `kms:Decrypt` on a specific KMS key, which is useful for managing session data or secrets.
+
+- **User data injection** is essentially a startup script inserted into the instance as Base64. This script sets up a `devpod` user with sudo rights, creates the SSH folders, and inserts your public key into the appropriate file. In the code, [it looks like this](https://github.com/loft-sh/devpod-provider-aws/blob/9d2730c34ecee40cb42596c602381b92ad9c6682/pkg/aws/aws.go#L967-L980):
+
+ ```bash
+ useradd devpod -d /home/devpod
+ mkdir -p /home/devpod
+ if grep -q sudo /etc/groups; then
+ usermod -aG sudo devpod
+ elif grep -q wheel /etc/groups; then
+ usermod -aG wheel devpod
+ fi
+
+ echo "devpod ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/91-devpod
+ mkdir -p /home/devpod/.ssh
+ echo " + string(publicKey) + " >> /home/devpod/.ssh/authorized_keys
+ chmod 0700 /home/devpod/.ssh
+ chmod 0600 /home/devpod/.ssh/authorized_keys
+ chown -R devpod:devpod /home/devpod
+ ```
+
+Since DevPod is open-source, you can easily check it out for yourself. It's a great learning tool if you want to understand all the inner workings! đ©
+
+## IAM roles and policies
+
+You'll need to create an IAM user and attach an IAM policy to it that grants just enough permissions for DevPod. For example:
+
+- **EC2 actions:**
+ - Description: `ec2:DescribeSubnets`, `ec2:DescribeVpcs`, `ec2:DescribeImages`, `ec2:DescribeInstances`, `ec2:DescribeSecurityGroups`
+ - Instance management: `ec2:RunInstances`, `ec2:StartInstances`, `ec2:StopInstances`, `ec2:TerminateInstances`, `ec2:CancelSpotInstanceRequests`
+ - Security groups & tags: `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTags`
+- **IAM actions:**
+ - `iam:GetInstanceProfile`, `iam:CreateRole`, `iam:PutRolePolicy`, `iam:AttachRolePolicy`, `iam:CreateInstanceProfile`, `iam:AddRoleToInstanceProfile`
+- **Route 53 (optional):**
+ - `route53:ListHostedZones`, `route53:GetHostedZone`, `route53:ChangeResourceRecordSets`
+
+## AWS configuration
+
+I usually use the AWS web console to set this up, but you can absolutely do it via the CLI too.
+
+### Step 1: Log in to the AWS console
+
+1. Go to the [AWS Management Console](https://aws.amazon.com/console/).
+2. Use an account with the appropriate rights to create IAM resources.
+
+### Step 2: Create a custom IAM policy
+
+#### **A. Go to the IAM console**
+
+- In the AWS menu, find **IAM**.
+
+#### **B. Create a new policy**
+
+1. Click **Policies** in the left-hand menu.
+2. Click **Create policy**.
+
+#### **C. Switch to the JSON tab**
+
+- Paste something like this, adjusting as needed:
+
+```json
+{
+ "Version": "2012-10-17",
+ "Statement": [
+ {
+ "Sid": "EC2Actions",
+ "Effect": "Allow",
+ "Action": [
+ "ec2:DescribeSubnets",
+ "ec2:DescribeVpcs",
+ "ec2:DescribeImages",
+ "ec2:DescribeInstances",
+ "ec2:DescribeSecurityGroups",
+ "ec2:RunInstances",
+ "ec2:StartInstances",
+ "ec2:StopInstances",
+ "ec2:TerminateInstances",
+ "ec2:CancelSpotInstanceRequests",
+ "ec2:CreateSecurityGroup",
+ "ec2:AuthorizeSecurityGroupIngress",
+ "ec2:CreateTags",
+ "ec2:DeleteTags"
+ ],
+ "Resource": "*"
+ },
+ {
+ "Sid": "IAMActions",
+ "Effect": "Allow",
+ "Action": [
+ "iam:GetInstanceProfile",
+ "iam:CreateRole",
+ "iam:PutRolePolicy",
+ "iam:AttachRolePolicy",
+ "iam:CreateInstanceProfile",
+ "iam:AddRoleToInstanceProfile"
+ ],
+ "Resource": "*"
+ },
+ {
+ "Sid": "Route53Actions",
+ "Effect": "Allow",
+ "Action": [
+ "route53:ListHostedZones",
+ "route53:GetHostedZone",
+ "route53:ChangeResourceRecordSets"
+ ],
+ "Resource": "*"
+ }
+ ]
+}
+```
+
+- Click **Next** (tags are optional), then **Next: Review**.
+
+#### **D. Review and create**
+
+1. Name it `DevpodToolPolicy` (or whatever you prefer).
+2. Add an optional description.
+3. Click **Create policy**.
+
+### Step 3: Create or update the IAM user
+
+#### **A. Create a new user (if needed)**
+
+1. Click **Users** in IAM.
+2. Click **Add user**.
+3. Give it a name (e.g., `devpod-tool-user`).
+4. Choose **Programmatic access** if you want CLI access. đ€
+5. Click **Next**.
+
+#### **B. Attach your new policy**
+
+1. On the permissions page, choose **Attach policies directly**.
+2. Check `DevpodToolPolicy`.
+3. Click **Create**.
+4. And there you go!
+
+### Step 4: Verify and you're done
+
+Go back to **Users** â **devpod-tool-user** â **Permissions** to confirm that `DevpodToolPolicy` is indeed attached. â
+
+### Step 5: Use these credentials
+
+- If you created a programmatic user, make sure to note down the **Access Key ID** and the **Secret Access Key**.
+
+
+
+**Bonus**: Note your **VPC ID** (in the VPC section on AWS). You'll need it when configuring DevPod.
+
+## Configuring DevPod
+
+### 1. Configure the AWS profile
+
+```bash
+aws configure --profile Devpod
+```
+
+When prompted for:
+
+1. The Access Key ID
+2. The Secret Access Key
+3. The default region (e.g., `eu-west-1`)
+4. The output format (I usually leave it blank)
+
+### 2. Add the profile to DevPod
+
+1. In DevPod, create a new provider and choose **AWS**.
+2. Select the **AWS region** (e.g., `eu-west-1`).
+3. Expand the AWS options.
+4. **AWS disk size**: e.g., 40 GB to start.
+5. **Instance type**: e.g., `t2.small`.
+6. **AWS profile**: select `Devpod` (or whatever name you chose).
+7. **AWS VPC ID**: add your VPC.
+8. You can leave the rest as default.
+
+Click **Add Provider**.
+
+
+
+## Testing a deployment
+
+### Deploy
+
+Let's do a quick test using one of the pre-built Docker images:
+
+1. Go to **Workspaces** in DevPod.
+2. Click **Create Workspace**.
+3. Choose your new **AWS** provider.
+4. Choose your preferred IDE (VS Code, etc.).
+5. On the right, select a quick-start example (e.g., Python). đ
+6. Click **Create Workspace**.
+
+
+
+Wait a few moments, and your cloud-based environment will pop up in VS Code. đ
+
+
+
+### Stop
+
+When you're not using the environment, click **Stop** to shut down the EC2 instance. You'll only pay for storage â no compute time. Great for your wallet. đ°
+
+
+
+### Delete
+
+Deleting the workspace removes all AWS resources associated with that environment, so you won't pay a dime. But you'll need to redeploy if you want to use it again. â»ïž
+
+
+
+## Conclusion
+
+By combining **DevContainers** and **DevPod** on **AWS**, you can build flexible, self-managed development environments that scale with your needs, without being locked into vendor-specific platforms. Say goodbye to "It works on my machine!" issues and hello to frictionless coding.
+
+Have fun!
diff --git a/content/documentation/devpod/_index.fr.md b/content/documentation/devpod/_index.fr.md
index a87e1fd..5aea2a7 100644
--- a/content/documentation/devpod/_index.fr.md
+++ b/content/documentation/devpod/_index.fr.md
@@ -11,13 +11,13 @@ cascade:
- [DevPod](https://devpod.sh/docs/what-is-devpod) âïž
- [DevContainer](https://containers.dev) đł
-## Introduction đ
+## Introduction
Dans cet article, je souhaite prĂ©senter un outil fantastique qui fait partie de la mĂȘme famille que GitPod et Codespaces : **DevPod** ! Il vous permet de crĂ©er des environnements de dĂ©veloppement sans effort â sans se retrouver bloquĂ© par un fournisseur. đâ
DevPod est basĂ© sur l'architecture **DevContainer** et utilise les spĂ©cifications contenues dans un fichier [devcontainer.json](https://containers.dev) pour lancer votre environnement de dĂ©veloppement. Personnellement, je l'utilise pour dĂ©ployer rapidement des maquette rĂ©seau avec ContainerLab. đ»đ§°
-## Qu'est-ce qu'un DevContainer ? đ€
+## Qu'est-ce qu'un DevContainer ?
Un conteneur de développement (souvent appelé « dev container ») vous permet d'utiliser un conteneur comme un environnement de développement complet. (Consultez la documentation officielle de [containers.dev](https://containers.dev) pour plus de détails.)
@@ -56,13 +56,13 @@ La pierre angulaire du DevContainer est le fichier `devcontainer.json`. Par exem
Les DevContainers sont formidables pour le dĂ©veloppement local, mais parfois vous avez besoin de plus de puissance â peut-ĂȘtre que vos charges de travail sont Ă©normes, ou que vous souhaitez exĂ©cuter des laboratoires spĂ©cialisĂ©s. C'est lĂ qu'intervient **DevPod**. đȘ
**Pour pouvoir déployer facilement des laboratoires sur le Cloud**
-## Qu'est-ce que DevPod ? đ€
+## Qu'est-ce que DevPod ?
**DevPod** est un outil open-source qui vous permet de lancer des environnements de dĂ©veloppement soit sur votre machine locale, soit dans le cloud de votre choix. Imaginez une version auto-hĂ©bergĂ©e et ultra-personnalisable de GitHub Codespaces. đ
Dans mes aventures quotidiennes en rĂ©seau, je dĂ©ploie des configurations basĂ©es sur ContainerLab avec des DevContainers sur AWS. Voyons comment vous pouvez utiliser DevPod pour faire exactement cela (les dĂ©tails sur ContainerLab suivront dans un autre article, promisâŻ!). đ
-## Fournisseur AWS đ
+## Fournisseur AWS
DevPod utilise des **Providers** (fournisseurs), qui sont des modules de configuration dĂ©finissant oĂč et comment DevPod lance votre environnement. Voici la liste des fournisseurs :
@@ -74,7 +74,7 @@ Nous allons nous concentrer sur le **Provider AWS** â bien qu'il existe de nom
Avant de paniquer devant tous ces rĂ©glages, ne vous inquiĂ©tez pas. Si vous ne faites que quelques expĂ©rimentations, les valeurs par dĂ©faut conviennent gĂ©nĂ©ralement. đ
-> [!NOTE] **Les avantages de l'open-source** đ
+> [!NOTE] **Les avantages de l'open-source**
>
> Le fait que DevPod soit open-source signifie que vous pouvez jeter un Ćil sous le capot pour voir exactement comment il fonctionne. Consultez le code AWS [ici](https://github.com/loft-sh/devpod-provider-aws/tree/main) si vous ĂȘtes curieux.
@@ -136,7 +136,7 @@ Vous devrez créer un utilisateur IAM et lui attacher une politique IAM qui acco
- **Route 53 (optionnel) :**
- `route53:ListHostedZones`, `route53:GetHostedZone`, `route53:ChangeResourceRecordSets`
-## Configuration AWS đïž
+## Configuration AWS
J'utilise généralement la console web AWS pour configurer cela, mais vous pouvez tout à fait le faire via la CLI.
@@ -249,7 +249,7 @@ Retournez dans **Users** â **devpod-tool-user** â **Permissions** pour confi
**Bonus** : Notez votre **ID VPC** (dans la section VPC sur AWS). Vous en aurez besoin lors de la configuration de DevPod.
-## Configurer DevPod đ ïž
+## Configurer DevPod
### 1. Configurer le profil AWS
@@ -279,7 +279,7 @@ Cliquez sur **Add Provider**.
-## Tester un dĂ©ploiement đ§Ș
+## Tester un déploiement
### DĂ©ployer
@@ -310,8 +310,8 @@ Supprimer le workspace supprime toutes les ressources AWS associées à cet envi
-## Conclusion đĄ
+## Conclusion
-En combinant **DevContainers** et **DevPod** sur **AWS**, vous pouvez crĂ©er des environnements de dĂ©veloppement flexibles et autogĂ©rĂ©s qui Ă©voluent avec votre croissance â sans ĂȘtre enfermĂ© dans des plateformes spĂ©cifiques Ă un fournisseur. Dites adieu aux problĂšmes du « Ăa marche sur ma machine ! » et accueillez un codage sans friction. đâš
+En combinant **DevContainers** et **DevPod** sur **AWS**, vous pouvez crĂ©er des environnements de dĂ©veloppement flexibles et autogĂ©rĂ©s qui Ă©voluent avec votre croissance, sans ĂȘtre enfermĂ© dans des plateformes spĂ©cifiques Ă un fournisseur. Dites adieu aux problĂšmes du « Ăa marche sur ma machine ! » et accueillez un codage sans friction.
-Amusez-vous bien ! đ
+Amusez-vous bien !
diff --git a/content/documentation/devpod/aws_options.en.png b/content/documentation/devpod/aws_options.en.png
new file mode 100644
index 0000000..894b6fd
Binary files /dev/null and b/content/documentation/devpod/aws_options.en.png differ
diff --git a/content/documentation/devpod/delete_instance.en.png b/content/documentation/devpod/delete_instance.en.png
new file mode 100644
index 0000000..616f618
Binary files /dev/null and b/content/documentation/devpod/delete_instance.en.png differ
diff --git a/content/documentation/devpod/devpod_user.en.png b/content/documentation/devpod/devpod_user.en.png
new file mode 100644
index 0000000..4f3ba2c
Binary files /dev/null and b/content/documentation/devpod/devpod_user.en.png differ
diff --git a/content/documentation/devpod/new_provider.en.png b/content/documentation/devpod/new_provider.en.png
new file mode 100644
index 0000000..cf8b1ac
Binary files /dev/null and b/content/documentation/devpod/new_provider.en.png differ
diff --git a/content/documentation/devpod/new_worskapce.en.png b/content/documentation/devpod/new_worskapce.en.png
new file mode 100644
index 0000000..46d56e2
Binary files /dev/null and b/content/documentation/devpod/new_worskapce.en.png differ
diff --git a/content/documentation/devpod/provider.en.png b/content/documentation/devpod/provider.en.png
new file mode 100644
index 0000000..629f3c7
Binary files /dev/null and b/content/documentation/devpod/provider.en.png differ
diff --git a/content/documentation/devpod/stopped_instance.en.png b/content/documentation/devpod/stopped_instance.en.png
new file mode 100644
index 0000000..e869662
Binary files /dev/null and b/content/documentation/devpod/stopped_instance.en.png differ
diff --git a/content/documentation/devpod/vscode.en.png b/content/documentation/devpod/vscode.en.png
new file mode 100644
index 0000000..d256906
Binary files /dev/null and b/content/documentation/devpod/vscode.en.png differ
diff --git a/content/documentation/securité/_index.en.md b/content/documentation/securité/_index.en.md
new file mode 100644
index 0000000..6be36b9
--- /dev/null
+++ b/content/documentation/securité/_index.en.md
@@ -0,0 +1,14 @@
+---
+title: "Security"
+sidebar:
+ open: true
+cascade:
+ type: docs
+---
+
+
+
+{{< cards >}}
+ {{< card link="/en/documentation/securité/cadenas_vert/ssl/" title="SSL: Decoding the Green Padlock" subtitle="How HTTPS (SSL/TLS) works" icon="banknotes" >}}
+ {{< card link="/en/documentation/securité/ssl_bumping/ssl_bumping/" title="SSL Bumping" subtitle="How to analyze SSL traffic" icon="clever" >}}
+{{< /cards >}}
diff --git a/content/documentation/securité/cadenas_vert/certificat.en.png b/content/documentation/securité/cadenas_vert/certificat.en.png
new file mode 100644
index 0000000..c7e0688
Binary files /dev/null and b/content/documentation/securité/cadenas_vert/certificat.en.png differ
diff --git a/content/documentation/securité/cadenas_vert/ssl.en.md b/content/documentation/securité/cadenas_vert/ssl.en.md
new file mode 100644
index 0000000..def74f4
--- /dev/null
+++ b/content/documentation/securité/cadenas_vert/ssl.en.md
@@ -0,0 +1,194 @@
+---
+title: "SSL: Decoding the Green Padlock"
+date: 2025-05-26T20:00:00+02:00
+weight: 2
+cascade:
+ type: docs
+---
+
+## Introduction: the padlock, your trust indicator
+
+You've seen it thousands of times, haven't you? That little **green padlock** (or sometimes gray, depending on your browser and the site) that shows up next to a website's address in your navigation bar. You click on it, you look at it, you think "cool, it's secure," and you move on.
+
+
+
+But... do you really know what it means? đ€ All the **mechanics that kick in** just so this little symbol appears? It's much more than a simple icon! It's the visible part of an iceberg. \
+**So, what's our mission today? đ**
+
+We're going to roll up our sleeves and analyze what happens "under the hood"! Promise: we'll explain **clearly, simply, and without indigestible jargon** what actually happens when this padlock appears. We'll dissect together how it helps us know whether we can trust a site and why it matters for our "security".
+
+Get ready, because you'll see that behind this little padlock hides a complex dance of certificates, secret keys, and handshakes... And by the end, you'll never look at this little symbol the same way again.
+
+## Part 1: the SSL certificate
+
+So, this famous SSL certificate, what exactly is it? Hang on tight, because it's the first piece of the puzzle!
+
+### What is it?
+
+Imagine the SSL certificate (or TLS, we'll get to that!) as the **official digital ID card of a website**. When you present it to the police đź, it proves who you are. \
+Well, for a website, it's the same thing!
+
+Its role? To prove that the site you're visiting really is what it claims to be, and not an impostor đ„ž. \
+It's the first guarantee that you're not being fooled by a well-disguised phishing site.
+
+> [!NOTE] **A Small Linguistic Note đ€: SSL or TLS?**
+>
+> We often hear about "SSL certificate". In reality, SSL (Secure Sockets Layer) is the ancestor of the current protocol, which is called **TLS (Transport Layer Security)**. \
+> But since "SSL" remained popular (a bit like calling any tissue a "Kleenex"), it's still widely used. \
+> In this article, we'll juggle between "SSL certificate" and "TLS certificate", but know that we're really talking about the modern, secure technology!
+
+### Who issues it? The certificate authority (CA)
+
+But who makes and distributes these ID cards? These are the **Certificate Authorities (CA)**. \
+Think of them as **"town halls"**.
+
+Before giving you an ID card, your town hall checks who you are, right? Well, CAs do the same for websites! They make sure of the requester's identity before issuing this precious pass. Names like **Let's Encrypt**, **Sectigo**, or **DigiCert** ring a bell? These are examples of these trusted organizations.
+
+And how does your browser (Chrome, Firefox, Safari...) know it can trust a CA? It's simple: it has a **pre-installed list of recognized and trusted CAs**. A bit like having the list of official town halls in the country! If the certificate is signed by a CA on this list, the browser says "OK, I know this one, I trust it".
+
+> [!TIP] **Not All Padlocks Hide the Same Investigation đ”ïžââïž**
+> There are different "levels of scrutiny" before a CA issues a certificate. We talk about:
+>
+> * **DV (Domain Validation):** The most basic. The CA just checks that the requester really controls the domain name (like, "do you have the keys to `arnodo.fr`?"). It's fast and often free (thanks Let's Encrypt!).
+> * **OV (Organization Validation):** Here, we step it up a notch. The CA verifies the legal existence of the organization requesting the certificate (company name, address...).
+> * **EV (Extended Validation):** The top of the top in verification! The CA conducts a thorough investigation into the company's identity. In the past, this often resulted in the company name being displayed in green next to the padlock. Today, browsers tend to simplify this display, but the rigor of the verification remains.
+> The little padlock will be there for all these types, but additional information about the organization may be visible by clicking on it for OV/EV certificates.
+
+### What does it contain?
+
+Concretely, what do we find in this famous digital ID card? The essential information is:
+
+* **The domain name concerned:** For example, `notebook.arnodo.fr`. This confirms you're in the right place.
+* **The name of the owning organization:** Especially visible and verified for OV and EV certificates. This gives you an idea of who's behind the site.
+* **The server's public key:** đ This is an ultra-important piece of code! We'll see its role in Part 2, but remember it's here, snugly stored in the certificate. It's a bit like the address of our mailbox.
+* **The CA's digital signature:** This is the official stamp of the "town hall" (the CA) that proves the certificate is authentic and hasn't been modified or forged since it was issued.
+* **The validity dates:** Like your driver's license or your passport, a certificate has a start date and an end date. An expired certificate is a big NO đ© for your browser!
+
+### How does your browser verify it?
+
+All that's great, but how does your browser manage to verify all this in the blink of an eye (often in just a few milliseconds!) when you land on a site? It's a well-oiled little dance, a sort of express "check-up":
+
+1. **Checking the CA's signature:** The browser looks at the signature affixed to the certificate. Thanks to its list of trusted CAs (and their own "public keys", which it knows), it can make sure the signature is authentic and that the certificate really comes from a recognized authority. It's like checking the seal on an official document.
+2. **Not expired, please!:** It checks that the certificate hasn't expired yet (and that it's even already valid, if there's a start date in the future). An expired certificate is like showing a passport that's no longer valid: straight to the exit!
+3. **Not on the blacklist (revocation):** The browser makes sure the certificate hasn't been revoked. "Revoked?" Yes, that means canceled before its expiration date. This can happen if, for example, the site got hacked and its private key (the server's secret, more on that soon) was compromised. The CA then publishes lists of canceled certificates (called CRL or via OCSP) that browsers consult.
+4. **Right site, right certificate:** It checks that the domain name indicated in the certificate (for example `www.yourfavoritesite.com`) matches EXACTLY the site you're trying to reach. No cheating or identity fraud!
+
+**The verdict:**
+
+* **If everything's OK đ:** The little green padlock (or gray, depending on the browser) proudly displays itself! The connection is deemed safe, and you can browse, buy, or enter your information with a (relatively) peaceful mind.
+* **If something's off đ:** Your browser will sound the alarm! đš You'll see a very visible warning message (something like "Your connection is not private", "Security alert", etc.).
+ > [!WARNING] **Red Alert!**
+ > A friendly tip: **NEVER ignore these warnings**, especially if you were planning to enter sensitive information (credentials, bank details...).
+ > It's often a sign that something shady is going on!
+
+And that's it for the ID card! But this is only the beginning. Now that we know the site really is what it claims to be, how do we make sure our exchanges with it stay secret? That's where the magic of keys comes in... and that's the topic of our next part!
+
+## Part 2: the dance of the keys
+
+Alright, now we know the site really is what it claims to be thanks to its ID card (the SSL/TLS certificate, remember?). That's great, but it's not enough! If our exchanges with this site travel in plain text over the internet, any nosy person (or hacker đŽââ ïž) could read them. Not great if you're sending your credit card number or your most secret passwords!
+
+That's where the second phase of the magic kicks in: **data encryption**. And for that, we're going to witness a real "dance of the keys"!
+
+### Introduction to the magic: asymmetric cryptography
+
+For our data to become illegible gibberish to others, we use a brilliant concept called **asymmetric cryptography**. What's that? It's the idea of having not one, but **two digital keys** that work together, like an inseparable duo:
+
+1. **A Public Key:** đ Imagine it as a **mailbox with a slot open to everyone**. It's shared openly with the whole world (it's even included in the site's SSL certificate, the one we saw in Part 1!). Anyone can use it to drop off a message (encrypted, of course).
+2. **A Private Key:** đ€« This one is the **server's treasure**. It's kept preciously and must NEVER be disclosed. It's the **ONLY key capable of opening the mailbox** and reading the messages that were encrypted with the corresponding public key.
+
+In short: what's encrypted (locked) with the public key can ONLY be decrypted (unlocked) by the corresponding private key. And vice versa (although for our "handshake", it's mostly the first direction that interests us). Clever, isn't it?
+
+### The simplified SSL/TLS "handshake"
+
+Now that we have our keys, how do your browser and the server agree to talk secretly? Thanks to an initial negotiation, a sort of coded "handshake" called the **SSL/TLS Handshake**. Here are the steps, simplified so as not to give you a headache:
+
+1. **Your Browser đ»:** "Hi Server! I'd like us to talk securely. Can you show me your ID card (your SSL/TLS certificate), please?"
+2. **The Server đ„ïž:** "No problem, friend! Here's my certificate. You'll find my famous **public key** (our `mailbox`) in it."
+3. **Your Browser đ»:** (It examines the certificate from every angle, as we saw in Part 1: CA signature, expiration date, domain name, not revoked... In short, the full check-up!)
+4. **If the certificate is valid and trustworthy â
:**
+ * Your browser thinks: "OK, this guy is legit! Now, we need to find a secret code just for the two of us for the rest of the conversation."
+ * It then creates a small temporary secret piece of information, a sort of unique password for this session: this is the **session key**. (This is what's called a *symmetric* key, different from our public/private pair, because it's faster for encrypting large volumes of data).
+ * To send this session key to the server without anyone being able to see it, your browser will use the **server's public key** (the one it found in the certificate) to encrypt it. There, the session key is placed in a "secure envelope" that only the server will be able to open!
+ * It sends this encrypted session key to the server.
+5. **The Server đ„ïž:** It receives the secure envelope. How to open it? Easy! It uses its **private key** (the one it jealously keeps secret) to decrypt the session key sent by your browser. And since it's the only one with this private key... it's the only one who can read the session key!
+6. **Mission Accomplished! đ** Magic! Your browser and the server now have **exactly the same secret session key**. No one else on the network knows it.
+
+From this moment on, **all the data exchanged** between your browser and the server for the rest of your visit (the pages you load, the forms you submit, etc.) will be **encrypted and decrypted with this session key**. It's much faster to use this symmetric key for ongoing exchanges than to keep using the public/private key system (which is a bit heavier for large amounts of data).
+
+The communication is now secure, encrypted end-to-end! đ You can relax, your secrets are (normally) well kept!
+
+## Part 3: why does this matter to you?
+
+OK, we've seen the site's ID card (the certificate) and the secret dance of keys to encrypt our conversations (the SSL/TLS handshake). \
+But concretely, why go through all this trouble?
+
+### For you, as a user
+
+When you browse a site proudly displaying this padlock (and thus using HTTPS), you benefit from several vital protections:
+
+1. **Confidentiality đ€«: Your Secrets Well Kept!**
+ This is the most obvious benefit. Thanks to encryption (that famous session key we established), your sensitive information becomes undecipherable gibberish for anyone trying to spy on your connection.
+ * **Passwords?** Encrypted.
+ * **Credit card numbers during a purchase?** Encrypted.
+ * **Private messages on a forum or social network?** Encrypted.
+ Even if a hacker đŽââ ïž managed to intercept the data traveling between your computer and the site, they would only see a mush of incomprehensible characters. Your information stays private, away from prying eyes.
+
+2. **Integrity â
: What You See Is What You Should See!**
+ The HTTPS protocol also guarantees that the data you receive from the site (and what you send) has **not been modified or corrupted along the way** by a malicious third party.
+
+3. **Authentication đ: You're Really Talking to the Right Counter!**
+ Thanks to the SSL/TLS certificate, you have much better assurance that you're communicating **with the legitimate site and not with a fraudulent clone**.
+
+### For website owners
+
+If you have a website, setting up HTTPS is no longer a "nice-to-have", it has become a "must-have". Here's why:
+
+1. **Building trust (and increasing conversions)**
+ The padlock immediately reassures your visitors. They see that you take their security seriously. This matters a lot for e-commerce (who would want to enter their bank details on an unsecured site?), online banking services, or any site collecting the slightest bit of personal data. An unsecured site can scare visitors away before they've even explored your content, directly impacting your credibility and, potentially, your sales or your goals.
+
+2. **Improving search engine optimization (SEO): Google loves secure sites**
+ For several years now, Google and other search engines have **actively favored HTTPS sites** in their search results. Switching your site to HTTPS can therefore give you a little boost in the rankings. Conversely, not doing so could penalize you.
+
+3. **Protecting your users (and your reputation)**
+ By securing exchanges, you protect your users against the theft of their personal data. Avoiding a data leak or identity theft that would originate from a security flaw on your site also means protecting your own reputation. Bad press on this subject can be devastating.
+
+4. **Regulatory compliance: sometimes, it's the law**
+ For certain activities and in certain regions (think GDPR in Europe, for example), securing the personal data collected and processed is a **legal obligation**. Failing to comply can result in heavy penalties. HTTPS is one of the fundamental building blocks of this compliance.
+
+This little padlock is a sign of respect toward your users and a mark of seriousness for your business. Not bad for such a small icon, right?
+
+## Conclusion
+
+So, this little green (or gray) padlock we've dissected from every angle, it's ultimately much more than a simple graphic detail, isn't it? As we've seen, it's the **visible part of an ingenious and complex system** working hard behind the scenes.
+
+Quick recap:
+
+* It starts with a **digital ID card** (the SSL/TLS certificate) that assures us the site really is what it claims to be, issued by a trusted "web town hall" (the Certificate Authority).
+* Then, there's a **cryptographic "dance of the keys"** (the public key to encrypt a secret, the private key to decrypt it) that allows your browser and the server to agree on a unique secret code (the session key).
+* And all this, for what? To guarantee the **Confidentiality** (your data stays secret), the **Integrity** (it's not modified along the way), and the **Authentication** (you're really talking to the right site) of your exchanges on the web.
+
+But be careful, the magic of TLS doesn't stop at your web browser's door! If the padlock is its best-known ambassador, this technology is actually the **silent guardian of many other aspects of our digital lives**:
+
+* **Your emails đ§:** When you see protocols like SMTPS, IMAPS, or POP3S, it's TLS securing the sending and receiving of your messages.
+* **Your mobile apps đ±:** Many of them use TLS to communicate securely with their servers, protecting the data they exchange.
+* **VPNs (Virtual Private Networks) đ:** Some VPN protocols rely on TLS to create encrypted tunnels and secure your overall internet connection.
+* **Instant messaging đŹ:** Applications use similar mechanisms or directly TLS to encrypt your conversations.
+* **And much more!** (Database connections, secured APIs, etc.)
+
+In short, this padlock is the most visible manifestation of this **personal digital bodyguard** đ”ïžââïž, but the TLS technology itself works in many other corners to protect your information.
+
+**So, the final word?**
+
+Get into the habit of **always checking for the presence of this padlock** (and hence "HTTPS" in the address) before entering any sensitive information or downloading anything on a website. Don't hesitate to **click on it for more information** if you have any doubt. And above all, be **extremely vigilant about security warning messages** that your browser might display. They're there for a good reason!
+
+> [!NOTE] Key and certificate file formats
+>
+> You'll often encounter different file formats for keys and certificates. Here are the most common ones:
+>
+> * `.pem` (Privacy Enhanced Mail): This is a very widespread format that can contain server certificates, intermediate certificates, private keys, or even all of these at once. Its content is Base64-encoded, which makes it readable as text (you'll see lines like `-----BEGIN CERTIFICATE-----`).
+> * `.crt` or `.cer` (Certificate): These files generally contain a certificate, most often the server's. They can be Base64-encoded (like `.pem`) or in binary DER format.
+> * `.key` (Key): This file contains a key, and in the SSL/TLS context, it's almost always the server's private key. It's crucial and must be kept secret. It's often in PEM format.
+> * `.csr` (Certificate Signing Request): This is not a certificate, but a certificate request. It's the file you generate and send to a Certificate Authority (CA). It contains your public key and the information you want to appear in your certificate.
+> * `.p12` or `.pfx` (PKCS#12): This is a package format that can contain certificates (public), intermediate certificates, and the private key (password-protected) in a single binary file. It's often used to import/export certificates and keys on Windows or macOS.
+>
+> Understanding these extensions will help you better manage files when configuring SSL/TLS on a server.
diff --git a/content/documentation/securité/cadenas_vert/ssl.fr.md b/content/documentation/securité/cadenas_vert/ssl.fr.md
index ab322f1..1a470d9 100644
--- a/content/documentation/securité/cadenas_vert/ssl.fr.md
+++ b/content/documentation/securité/cadenas_vert/ssl.fr.md
@@ -6,7 +6,7 @@ cascade:
type: docs
---
-## Introduction : Le Cadenas, Votre Indice de Confiance đ”ïžââïžâš
+## Introduction : le cadenas, votre indice de confiance
Vous l'avez vu des milliers de fois, n'est-ce pas ? Ce petit **cadenas vert** (ou parfois gris, selon votre navigateur et le site) qui se présente à cÎté de l'adresse d'un site web dans votre barre de navigation. On clique dessus, on le voit, on se dit "cool, c'est sécurisé", et on passe à autre chose.
@@ -15,15 +15,15 @@ Vous l'avez vu des milliers de fois, n'est-ce pas ? Ce petit **cadenas vert** (o
Mais... savez-vous vraiment ce qu'il signifie ? đ€ Toute la **mĂ©canique qui se dĂ©clenche** rien que pour que ce petit symbole s'affiche ? C'est bien plus qu'une simple icĂŽne ! C'est la partie visible d'un iceberg. \
**Alors, quelle est notre mission aujourd'hui ? đ**
-On va enfiler nos gants et analyser se qu'il se passe "sous le capot" ! Promis, on va expliquer de façon **claire, simple, et sans jargon indigeste** ce qui se passe réellement quand ce cadenas apparaßt. On va décortiquer ensemble comment il nous aide à savoir si on peut faire confiance à un site et pourquoi c'est absolument **ESSENTIEL** pour notre "sécurité".
+On va enfiler nos gants et analyser ce qu'il se passe "sous le capot" ! Promis, on va expliquer de façon **claire, simple, et sans jargon indigeste** ce qui se passe réellement quand ce cadenas apparaßt. On va décortiquer ensemble comment il nous aide à savoir si on peut faire confiance à un site et pourquoi ça compte pour notre "sécurité".
PrĂ©parez-vous, car vous allez voir que derriĂšre ce petit cadenas se cache une danse complexe de certificats, de clĂ©s secrĂštes, et de poignĂ©es de main... Et Ă la fin, vous ne regarderez plus jamais ce petit symbole de la mĂȘme maniĂšre.
-## Partie 1 : Le Certificat SSL đł
+## Partie 1 : le certificat SSL
Alors, ce fameux certificat SSL, c'est quoi au juste ? Accrochez-vous, car c'est la premiĂšre piĂšce du puzzle !
-### Qu'est-ce que c'est ? đ€
+### Qu'est-ce que c'est ?
Imaginez le certificat SSL (ou TLS, on y reviendra !) comme la **carte d'identitĂ© numĂ©rique officielle d'un site web**. Quand vous la prĂ©sentez Ă la gendarmerie đź, elle prouve qui vous ĂȘtes. \
Eh bien, pour un site web, c'est pareil !
@@ -37,7 +37,7 @@ C'est la premiĂšre garantie que vous n'ĂȘtes pas en train de vous faire avoir pa
> Mais comme "SSL" est resté populaire (un peu comme "Frigidaire" pour parler d'un réfrigérateur), on l'utilise encore beaucoup. \
> Dans cet article, on jonglera entre "certificat SSL" et "certificat TLS", mais sachez qu'on parle bien de la technologie moderne et sécurisée !
-### Qui le dĂ©livre ? L'AutoritĂ© de Certification (CA) đïž
+### Qui le délivre ? L'autorité de certification (CA)
Mais qui fabrique et distribue ces cartes d'identité ? Ce sont les **Autorités de Certification (CA)**. \
Pensez Ă elles comme Ă des **"mairies"**.
@@ -54,17 +54,17 @@ Et comment votre navigateur (Chrome, Firefox, Safari...) sait-il qu'il peut fair
> * **EV (Extended Validation) :** Le top du top de la vĂ©rification ! La CA mĂšne une enquĂȘte approfondie sur l'identitĂ© de l'entreprise. Avant, cela se traduisait souvent par l'affichage du nom de l'entreprise en vert Ă cĂŽtĂ© du cadenas. Aujourd'hui, les navigateurs tendent Ă simplifier cet affichage, mais la rigueur de la vĂ©rification reste.
> Le petit cadenas sera lĂ pour tous ces types, mais des informations supplĂ©mentaires sur l'organisation peuvent ĂȘtre visibles en cliquant dessus pour les certificats OV/EV.
-### Que contient-il đ
+### Que contient-il ?
ConcrÚtement, qu'est-ce qu'on trouve dans cette fameuse carte d'identité numérique ? Les informations essentielles sont :
-* **Le nom du domaine concernĂ© :** Par exemple, `notebook.arnodo.fr`. C'est crucial pour s'assurer que vous ĂȘtes au bon endroit.
+* **Le nom du domaine concernĂ© :** Par exemple, `notebook.arnodo.fr`. Cela permet de s'assurer que vous ĂȘtes au bon endroit.
* **Le nom de l'organisation propriĂ©taire :** Surtout visible et vĂ©rifiĂ© pour les certificats OV et EV. Ăa vous donne une idĂ©e de qui est derriĂšre le site.
* **La clĂ© publique du serveur :** đ C'est un morceau de code ultra-important ! On va voir son rĂŽle dans la partie 2, mais retenez qu'elle est ici, bien au chaud dans le certificat. C'est un peu l'adresse de notre boĂźte aux lettres.
* **La signature numérique de la CA :** C'est le tampon officiel de la "mairie" (la CA) qui prouve que le certificat est authentique et n'a pas été modifié ou falsifié depuis sa délivrance.
* **Les dates de validitĂ© :** Comme votre permis de conduire ou votre passeport, un certificat a une date de dĂ©but et une date de fin. Un certificat expirĂ©, c'est un gros NON đ© pour votre navigateur !
-### Comment votre navigateur le vĂ©rifie-t-il ? â±ïžđš
+### Comment votre navigateur le vérifie-t-il ?
Tout ça, c'est bien beau, mais comment votre navigateur fait-il pour vĂ©rifier tout ça en un clin d'Ćil (souvent en quelques millisecondes Ă peine !) quand vous arrivez sur un site ? C'est une petite danse bien huilĂ©e, une sorte de "check-up" express :
@@ -73,7 +73,7 @@ Tout ça, c'est bien beau, mais comment votre navigateur fait-il pour vérifier
3. **Pas sur la liste noire (rĂ©vocation) :** Le navigateur s'assure que le certificat n'a pas Ă©tĂ© rĂ©voquĂ©. "RĂ©voquĂ© ?" Oui, ça veut dire annulĂ© avant sa date d'expiration. Ăa peut arriver si, par exemple, le site s'est fait pirater et que sa clĂ© privĂ©e (le secret du serveur, on en reparle bientĂŽt) a Ă©tĂ© compromise. La CA publie alors des listes de certificats annulĂ©s (appelĂ©es CRL ou via OCSP) que les navigateurs consultent.
4. **Bon site, bon certificat :** Il vérifie que le nom de domaine indiqué dans le certificat (par exemple `www.votresiteprefere.com`) correspond EXACTEMENT au site que vous essayez de joindre. Pas de triche ou d'arnaque à l'identité !
-đ **Le Verdict :**
+**Le verdict :**
* **Si tout est OK đ :** Le petit cadenas vert (ou gris, selon le navigateur) s'affiche fiĂšrement ! La connexion est jugĂ©e sĂ»re, et vous pouvez naviguer, acheter, ou entrer vos informations l'esprit (relativement) tranquille.
* **Si quelque chose cloche đ :** Votre navigateur va tirer la sonnette d'alarme ! đš Vous verrez un message d'avertissement bien visible (du genre "Votre connexion n'est pas privĂ©e", "Alerte de sĂ©curitĂ©", etc.).
@@ -83,13 +83,13 @@ Tout ça, c'est bien beau, mais comment votre navigateur fait-il pour vérifier
Et voilĂ pour la carte d'identitĂ© ! Mais ce n'est que le dĂ©but. Maintenant qu'on sait que le site est bien qui il prĂ©tend ĂȘtre, comment fait-on pour que nos Ă©changes avec lui restent secrets ? C'est lĂ qu'intervient la magie des clĂ©s... et c'est le sujet de notre prochaine partie !
-## Partie 2 : La Danse des ClĂ©s đđ
+## Partie 2 : la danse des clés
Bon, maintenant on sait que le site est bien celui qu'il prĂ©tend ĂȘtre grĂące Ă sa carte d'identitĂ© (le certificat SSL/TLS, vous vous souvenez ?). C'est super, mais ça ne suffit pas ! Si nos Ă©changes avec ce site se baladent en clair sur internet, n'importe quel petit curieux (ou pirate đŽââ ïž) pourrait les lire. Pas top si vous envoyez votre numĂ©ro de carte bleue ou vos mots de passe les plus secrets !
C'est là qu'intervient la deuxiÚme phase de la magie : **le chiffrement des données**. Et pour ça, on va assister à une véritable "danse des clés" !
-### Introduction à la Magie : La Cryptographie Asymétrique
+### Introduction à la magie : la cryptographie asymétrique
Pour que nos données deviennent un charabia illisible pour les autres, on utilise un concept génial appelé **cryptographie asymétrique**. Késako ? C'est l'idée d'avoir non pas une, mais **deux clés numériques** qui fonctionnent ensemble, comme un duo inséparable :
@@ -117,12 +117,12 @@ Maintenant qu'on a nos clés, comment votre navigateur et le serveur se mettent-
La communication est dĂ©sormais sĂ©curisĂ©e, chiffrĂ©e de bout en bout ! đ Vous pouvez souffler, vos secrets sont (normalement) bien gardĂ©s !
-## Partie 3 : Pourquoi Tout Cela Est Essentiel Pour Vous ? đĄïžđ
+## Partie 3 : pourquoi cela compte pour vous ?
OK, on a vu la carte d'identité du site (le certificat) et la danse secrÚte des clés pour chiffrer nos conversations (le handshake SSL/TLS). \
Mais concrĂštement, pourquoi se donner autant de mal ?
-### Pour Vous, en Tant qu'Utilisateur
+### Pour vous, en tant qu'utilisateur
Quand vous naviguez sur un site affichant fiÚrement ce cadenas (et donc utilisant HTTPS), vous bénéficiez de plusieurs protections vitales :
@@ -139,25 +139,25 @@ Quand vous naviguez sur un site affichant fiĂšrement ce cadenas (et donc utilisa
3. **Authentification đ : Vous Parlez Bien au Bon Guichet !**
Grùce au certificat SSL/TLS, vous avez une bien meilleure assurance que vous communiquez **avec le site légitime et non avec un clone frauduleux**.
-### Pour les PropriĂ©taires de Sites Web đ
+### Pour les propriétaires de sites web
Si vous avez un site web, mettre en place HTTPS n'est plus un "nice-to-have", c'est devenu un "must-have". Voici pourquoi :
-1. **Instaurer la Confiance (et Augmenter les Conversions !) đâĄïžđ°**
- Le cadenas rassure immĂ©diatement vos visiteurs. Ils voient que vous prenez leur sĂ©curitĂ© au sĂ©rieux. C'est absolument crucial pour l'e-commerce (qui voudrait entrer ses infos bancaires sur un site non sĂ©curisĂ© ?), les services bancaires en ligne, ou tout site qui collecte la moindre donnĂ©e personnelle. Un site non sĂ©curisĂ© peut faire fuir les visiteurs avant mĂȘme qu'ils n'aient explorĂ© votre contenu, impactant directement votre crĂ©dibilitĂ© et, potentiellement, vos ventes ou vos objectifs.
+1. **Instaurer la confiance (et augmenter les conversions)**
+ Le cadenas rassure immĂ©diatement vos visiteurs. Ils voient que vous prenez leur sĂ©curitĂ© au sĂ©rieux. Cela compte beaucoup pour l'e-commerce (qui voudrait entrer ses infos bancaires sur un site non sĂ©curisĂ© ?), les services bancaires en ligne, ou tout site qui collecte la moindre donnĂ©e personnelle. Un site non sĂ©curisĂ© peut faire fuir les visiteurs avant mĂȘme qu'ils n'aient explorĂ© votre contenu, impactant directement votre crĂ©dibilitĂ© et, potentiellement, vos ventes ou vos objectifs.
-2. **AmĂ©liorer le RĂ©fĂ©rencement (SEO) đ : Google Aime les Sites SĂ©curisĂ©s !**
+2. **Améliorer le référencement (SEO) : Google aime les sites sécurisés**
Depuis plusieurs années, Google et d'autres moteurs de recherche **favorisent activement les sites en HTTPS** dans leurs résultats de recherche. Passer votre site en HTTPS peut donc vous donner un petit coup de pouce dans les classements. à l'inverse, ne pas le faire pourrait vous pénaliser.
-3. **ProtĂ©ger Vos Utilisateurs (et Votre RĂ©putation !) đĄïž**
+3. **Protéger vos utilisateurs (et votre réputation)**
En sĂ©curisant les Ă©changes, vous protĂ©gez vos utilisateurs contre le vol de leurs donnĂ©es personnelles. Ăviter une fuite de donnĂ©es ou une usurpation d'identitĂ© qui aurait pour origine une faille de sĂ©curitĂ© sur votre site, c'est aussi protĂ©ger votre propre rĂ©putation. Une mauvaise presse Ă ce sujet peut ĂȘtre dĂ©vastatrice.
-4. **ConformitĂ© RĂ©glementaire âïž : Parfois, C'est la Loi !**
+4. **Conformité réglementaire : parfois, c'est la loi**
Pour certaines activités et dans certaines régions (pensez au RGPD en Europe, par exemple), la sécurisation des données personnelles collectées et traitées est une **obligation légale**. Ne pas s'y conformer peut entraßner de lourdes sanctions. HTTPS est une des briques fondamentales de cette conformité.
-En bref, ce petit cadenas, c'est un signe de respect envers vos utilisateurs, un gage de sĂ©rieux pour votre activitĂ©, et une protection pour tout le monde. Pas mal pour une si petite icĂŽne, non ? đ
+Ce petit cadenas est un signe de respect envers vos utilisateurs et un gage de sérieux pour votre activité. Pas mal pour une si petite icÎne, non ?
-## Conclusion đĄïžâš
+## Conclusion
Alors, ce petit cadenas vert (ou gris) qu'on a décortiqué sous toutes ses coutures, c'est finalement bien plus qu'un simple détail graphique, n'est-ce pas ? On l'a vu, c'est la **partie visible d'un ingénieux et complexe systÚme** qui travaille d'arrache-pied en coulisses.
@@ -181,7 +181,7 @@ Bref, ce cadenas est la manifestation la plus visible de ce **garde du corps num
Prenez l'habitude de **toujours vĂ©rifier la prĂ©sence de ce cadenas** (et donc du "HTTPS" dans l'adresse) avant de saisir la moindre information sensible ou de tĂ©lĂ©charger quoi que ce soit sur un site web. N'hĂ©sitez pas Ă **cliquer dessus pour obtenir plus d'informations** si vous avez un doute. Et surtout, soyez **extrĂȘmement vigilants face aux messages d'avertissement de sĂ©curitĂ©** que votre navigateur pourrait afficher. Ils sont lĂ pour une bonne raison !
-> [!NOTE]Les Formats de Fichiers des Clés et Certificats
+> [!NOTE] Les formats de fichiers des clés et certificats
>
> Vous rencontrerez souvent différents formats de fichiers pour les clés et certificats. Voici les plus courants :
>
diff --git a/content/documentation/securité/ssl_bumping/images/architecture_du_lab_ssl.en.svg b/content/documentation/securité/ssl_bumping/images/architecture_du_lab_ssl.en.svg
new file mode 100644
index 0000000..e698642
--- /dev/null
+++ b/content/documentation/securité/ssl_bumping/images/architecture_du_lab_ssl.en.svg
@@ -0,0 +1,4 @@
+
+
+
+Votre Machine
đ» Navigateur
SSL Bump CA Cert : /ssl/squid-ca.pem Cache : /var/cache/squid/ Logs : /var/log/squid Parse Transform avec lua Export OTLP (port 4318) CA du Proxy
1. Configuration Initiale Client : "Je veux https://example.com"
Proxy GénÚre à la volée : CN = example.com Signé par le CA du proxy Validité = Courte durée Faux certificat envoyé au client
2. Interception d'une requĂȘte
3. Validation par le client Navigateur vĂ©rifie: Nom correspond (example.com) Pas expirĂ© SignĂ© par une CA de confiance đ Contenu invisible pour tous les intermĂ©diaires
Tunnel HTTPS Chiffré Connexion directe E2E
Woman Detective Streamline Emoji: https://streamlinehq.com
đ Le proxy peut voir tout le contenu dĂ©chiffrĂ©Â
HTTPS Connexion 1 (Faux Certificat)
HTTPS Connexion 2 (Vrai Certificat)
)
+
+> [!NOTE] Simplification for the POC
+> For the purposes of this **Proof of Concept**, we opted for a simplified architecture without advanced redundancy at the leaf-spine connection level.
+> The main goal is to demonstrate automation based on this standardized structure.
+
+### IP addressing plan for the "Paris" site
+
+For our "Paris" site, we'll use the following Netbox prefix containers, which fit into our overall addressing strategy:
+
+* **Location:**
+ * Region: Europe
+ * City: Paris
+* **Prefix Containers:**
+ * **UnderlayContainer (Paris):**
+ * CIDR: `172.16.0.0/16`
+ * Description: "Container prefix for the Underlay network of the Paris site"
+ * **LoopbackContainer (Paris):**
+ * CIDR: `192.168.100.0/24`
+ * Description: "Container prefix for Loopback addresses of devices at the Paris site"
+ * **CustomersContainer (Paris):**
+ * CIDR: `10.0.0.0/8`
+ * Description: "Container prefix for customer addressing at the Paris site"
+
+These "Container" type prefixes are specific to the "Paris" site and will be used by our automation scripts to assign IP addresses to the various devices and customers at this site, in accordance with the standard structure we've defined.
+
+## The "Paris" site: an instance of our standardized model
+
+Our "Paris" site strictly follows the structure and rules defined in our standard site model. It will therefore include a server room with the two spines and can host up to five single-story buildings, each equipped with a leaf and an access switch, connected according to the established conventions. The IP addressing for "Paris" will come from the standard prefix containers we've defined.
+
+This standardization is the key that will allow us to automate the creation and configuration of our "Paris" site infrastructure using the scripts we're about to present.
+
+## Test environment
+
+The POC will run on ContainerLab, so it's necessary to refer to [this article](../../documentation/devpod) to easily reproduce the installation and the tools.
+
+We'll be using:
+
+* ContainerLab
+* Arista cEOS for the switch/router part
+* Netbox
+ * Plugin: netbox_topology_views
+
+For more details, [here's the installation documentation](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/INSTALLATION.md)
+
+## Scripting: automation in action
+
+Now we get to the heart of the matter: how we use scripts to automate the creation of our VXLAN fabric by relying on Netbox. We'll look at two main scripts that do most of the heavy lifting!
+
+### Step 1: preparing Netbox with `import.py`
+
+Before we build our network, we need to prepare our "Source of Truth," Netbox. The [`import.py`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox) script is here for that! It will inject into Netbox the basic information for our "Paris" site and the models for our devices.
+
+**The Script's Ingredients:**
+
+* **[`Devices/devices_model.yml`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/utilities/Devices/devices_model.yml):** The ID card for our devices (spines, leafs, access cEOS) with their characteristics (number of interfaces, types, etc.).
+* **[`IPAM/subnet.yml`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/utilities/IPAM/subnets.yml):** The information for our "Paris" site (Europe region, city of Paris) and the plans for our IP address blocks (for the underlay, loopbacks, and our customers).
+
+**What the Script Does:**
+
+* It reads the `devices_model.yml` file and creates the corresponding device types in Netbox. It's like registering the types of hardware we're going to use.
+* It reads the `IPAM/subnet.yml` file and creates:
+ * The "Europe" region and the "Paris" site.
+ * The IP address blocks we'll use for our network in Paris (our "container prefixes").
+
+**How to Fire Up the Machine:**
+
+Open a terminal and type the command:
+
+```bash
+uv run import.py http://localhost:8080 YOUR_TOKEN Devices/devices_model.yml IPAM/subnet.yml
+```
+
+Make sure to replace `http://localhost:8080` with your Netbox address and `YOUR_TOKEN` with your Netbox API token! Once launched, this script lays the foundations of our automation.
+
+> [!TIP]
+> Link to the Cookbook [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox)
+
+### Step 2: building the VXLAN fabric with `Create_Fabric/main.py`
+
+Now that Netbox is ready, we move on to building our network with the `Create_Fabric/main.py` script. This script will create all the devices, connect them, and assign them IP addresses, all while following our standardized model for the "Paris" site.
+
+**The Script's Steps:**
+
+1. **Ready check.** The script starts by checking whether everything it needs already exists in Netbox (device roles, IP roles, device types). We don't want to start building on unstable foundations.
+2. **Choosing the site: "Paris" of course.** The script asks us which site we're working on. We select "Paris," our standard site. Its short name "PA" will be used as the base for naming our devices.
+3. **Bringing out the spines (x2).** The script creates our two spines in Netbox, using the correct model and the "spine" role. They're named `padc_sp1_00` and `padc_sp2_00`.
+4. **Leaf/access pairs per building.** For each building in "Paris" (up to 5), the script creates a Netbox "location" and installs a leaf there (e.g. `pa01_lf1_00`) and an access switch (e.g. `pa01_sw1_00`).
+5. **Automatic cabling.** The script virtually connects the devices in Netbox following our rules: `Eth1` of the leaf to `Eth*n*` of Spine 1, `Eth2` of the leaf to `Eth*n*` of Spine 2, and `Eth3` of the leaf to `Eth1` of the access switch. No more getting tangled up with cables.
+6. **IP distribution.** The script draws from the "Paris" IP address blocks and automatically assigns IPs to interfaces (/31s for the links between devices and /32s for loopbacks).
+7. **ASN assignment.** Finally, the script assigns an AS number to each spine and each leaf for BGP routing. These numbers are stored in a special "ASN" field in Netbox.
+
+```bash
+uv run Create_Fabric/main.py
+NetBox URL: http://localhost:8080
+NetBox API Token:
+Number of buildings (1-5): 4
+Spine device type slug: ceos
+Leaf device type slug: ceos
+Access switch device type slug: ceos
+
+Existing Sites:
+ 1. Paris (slug=paris)
+Choose site number or 'new': 1
+```
+
+**The result?** By running this script, we end up with our entire "Paris" VXLAN infrastructure created and connected in Netbox, ready to be configured.
+
+> [!NOTE] Netbox Plugin
+> The configuration can easily be visualized with the help of the plugin: [netbox_topology_views](https://github.com/netbox-community/netbox-topology-views)
+
+
+
+> [!TIP]
+> Link to the Cookbook [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-create-fabric)
+
+### Step 3: configuring our customers with `Create_Fabric/add_customers.py`
+
+At this point, the fabric is functional, but no customer is configured yet. What does that mean? It means that the *underlay* â the foundation of our network â is configured in Netbox, and it's possible to generate a configuration to deploy BGP and configure the ASes. However, the access switches and leafs aren't ready yet to host users or customer services. There's no information in Netbox that allows for that yet.
+
+In our standardized approach, each building is designed to host **one** "customer." A customer could be, for example, a specific team within the company or an external contractor. Each customer will be assigned a VLAN (and, in our VXLAN fabric, a corresponding VNI).
+
+To perform this customer configuration, we use a dedicated script: **Create_Fabric/add_customers.py**. It will guide us step by step, asking for the VLAN and VNI to assign, as well as the building or buildings where our customers are based. Here's an example of it running:
+
+```bash
+⯠uv run Create_Fabric/add_customers.py
+Enter NetBox URL: http://localhost:8080
+Enter NetBox API Token: 4e58e40e6b19d7f6cc53ae5665ca7ddd00558e71
+Enter Customer Name: Orange
+Enter VLAN ID (1-4094): 10
+Enter VNI ID: 10010
+
+Available Locations:
+0: PA1
+1: PA2
+2: PA3
+3: PA4
+Select locations (comma-separated indices): 0,2
+
+⯠uv run Create_Fabric/add_customers.py
+Enter NetBox URL: http://localhost:8080
+Enter NetBox API Token: 4e58e40e6b19d7f6cc53ae5665ca7ddd00558e71
+Enter Customer Name: Purple
+Enter VLAN ID (1-4094): 10
+Enter VNI ID: 10010
+
+Available Locations:
+0: PA1
+1: PA2
+2: PA3
+3: PA4
+Select locations (comma-separated indices): 1,3
+```
+
+Once this information is provided, the script takes care of automating several actions in Netbox:
+
+* Creation of the tenant (representing the customer).
+* Assignment of buildings (locations) to the tenant.
+* Allocation of a /24 prefix for the customer's IP addressing.
+* Logical configuration of the associated VXLAN/VLAN elements.
+* Assignment of specific interfaces on the access devices for this customer.
+
+Once Netbox is properly populated with all this customer data, it then becomes possible to extract the final, ready-to-use network configuration from it.
+
+## Generating configs with Netbox and Jinja2 templates
+
+Now that we have our network inventory all set up in Netbox, how do we tell our devices how to configure themselves? That's where **Render Config** and **Jinja2 templates** come in!
+
+> [!TIP] Templates
+> The templates used are available [here](https://github.com/darnodo/projet-vxlan-automation/tree/dev/templates).
+
+### Jinja templates: our configuration recipes
+
+1. **What are Render Configs, anyway?** Imagine Netbox as a chef who has all the ingredients (our devices, their interfaces, their IPs, etc.). Render Configs are its way of turning these ingredients into prepared dishes, meaning configuration files for our network devices.
+
+2. **Jinja2: our recipe language.** To write these configuration "recipes," Netbox uses a powerful engine called Jinja2, a bit like a simple programming language that lets us create dynamic configuration templates. We can put "holes" (variables) in them that get filled in with the information from our devices in Netbox.
+
+3. **A quick look at a recipe.** Let's take an example of a Jinja2 template for one of our leafs:
+
+ ```jinja
+ hostname {{ device.name }}
+ {% if device.custom_fields.ASN %}
+ router bgp {{ device.custom_fields.ASN }}
+ router-id {{ device.primary_ip4.address.split('/')[0] }}
+ {% endif %}
+ interface Loopback0
+ ip address {{ device.primary_ip4.address }}
+ {% for interface in device.interfaces %}
+ interface {{ interface.name }}
+ description {{ interface.description }}
+ {% if interface.connected_interface %}
+ no shutdown
+ {% endif %}
+ {% endfor %}
+ ```
+
+ See those things between double curly braces `{{ ... }}`? Those are our variables! For example, `{{ device.name }}` will be replaced with the name of our leaf, and `{{ interface.name }}` with the name of each interface. We can even add conditions (`{% if ... %}`) and loops (`{% for ... %}`) to adapt the configuration.
+
+4. **How Netbox prepares the dish.** When we ask Netbox to generate the configuration for a device (say, our `pa01_lf1_00`), here's what happens:
+
+ * It looks up all the information about this leaf: its name, its interfaces, its IPs, its connections, its ASN, etc.
+ * It takes the Jinja2 template that we've associated with the "leaf" role.
+ * It fills in all the "holes" (the Jinja2 variables) in the template with the specific information for our `pa01_lf1_00`.
+ * And there you go! It produces a text configuration file ready to be used.
+
+> [!TIP]
+> Link to the Cookbook [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates)
+
+### From Netbox to the lab: doing it by hand for now
+
+Now that we know how Netbox generates the configurations, let's see how we use them in our Containerlab lab.
+
+1. **Taking a look at the configuration in Netbox.** To view the configuration generated by Netbox for a device, it's simple:
+
+ * In the Netbox interface, go to **Devices**.
+ * Click on the device you're interested in (for example, one of our leafs).
+ * And there we have a magic tab: **Render Config**! Clicking on it shows the configuration Netbox generated for this device using the Jinja2 template and its own data.
+
+ ![PA01 Leaf Configuration]()
+
+2. **The human touch in Containerlab.** For now, we don't have a script that automatically pushes these configurations to our devices in Containerlab. So we're going to do it the old-fashioned way (fine for a demo):
+
+ * We connect to each cEOS device in our lab via SSH (for example, using the Containerlab VSCode extension as we saw in the [cookbook](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-deploy-configuration)).
+ * We copy the configuration we viewed in Netbox (the **Render Config** tab).
+ * And we paste it into the cEOS device's command-line interface (in configuration mode, of course!).
+
+3. **What's next?** This copy-paste step isn't the pinnacle of automation, but it's a first step toward seeing how Netbox can be our central brain. Down the line, tools like Ansible or NAPALM could connect to Netbox, retrieve these generated configurations, and apply them to our devices automatically.
+
+## Validating communication
+
+### Ping
+
+In the cookbook, we chose to configure 2 customers each in 2 different buildings, which lets us run a **ping**. As a reminder:
+
+1. Orange:
+ * Subnet: 10.0.0.0/24
+ * Hosts:
+ * PA1: 10.0.0.10
+ * PA3: 10.0.0.20
+
+2. Purple
+ * Subnet: 10.0.1.0/24
+ * Hosts:
+ * PA2: 10.0.1.10
+ * PA4: 10.0.1.20
+
+A simple "ping" lets us validate connectivity between the 2 sites:
+
+```bash
+/ # ifconfig eth1
+eth1 Link encap:Ethernet HWaddr AA:C1:AB:49:55:B6
+ inet addr:10.0.0.10 Bcast:0.0.0.0 Mask:255.255.255.0
+...
+
+/ # ping 10.0.0.20
+PING 10.0.0.20 (10.0.0.20): 56 data bytes
+64 bytes from 10.0.0.20: seq=0 ttl=64 time=15.378 ms
+64 bytes from 10.0.0.20: seq=1 ttl=64 time=4.349 ms
+...
+```
+
+### Packet capture
+
+To go further, it's also possible to use Wireshark, which is available by default in the devcontainer, with the help of Edgeshark.
+For more information, I'll point you to the article on [My First Lab](../../netlab/first_lab/#utiliser-edgeshark-)
+
+And then, via VSCode, it's possible to launch Wireshark directly:
+
+
+
+
+
+## Conclusion
+
+Netbox turns out to be a solid ally for automating the VXLAN network.
+The key is starting from a standardized foundation: that's what lets Netbox generate our configurations almost entirely on its own, using Jinja2 templates.
+
+We're still copying and pasting the last step by hand, but centralizing all our information in Netbox is the first move toward simplifying network management and opening the door to full automation. Next up: deploying these configs automatically and handling more complex networks.
diff --git a/content/netlab/automatisation réseau/vxlan_automation/_index.fr.md b/content/netlab/automatisation réseau/vxlan_automation/_index.fr.md
index 0dbbdbd..f11f95f 100644
--- a/content/netlab/automatisation réseau/vxlan_automation/_index.fr.md
+++ b/content/netlab/automatisation réseau/vxlan_automation/_index.fr.md
@@ -6,7 +6,7 @@ cascade:
type: docs
---
-## Introduction đ
+## Introduction
Dans cet article, nous allons explorer comment automatiser le déploiement d'une infrastructure VXLAN en nous appuyant sur **Netbox** comme source unique de vérité (*Source of Truth*) et sa fonctionnalité de **"Render Config"**.
@@ -18,17 +18,17 @@ Pour illustrer cette approche, nous allons prendre l'exemple d'un site fictif, *
2. **Générer** les configurations des équipements réseau en se basant sur les informations centralisées dans Netbox.
3. **Valider** le bon fonctionnement de cette infrastructure automatisée à l'aide d'un environnement de laboratoire **NetLab** sous ContainerLab.
-à travers cet exemple concret, nous mettrons en lumiÚre que la standardisation n'est pas une contrainte, mais plutÎt le **socle indispensable** pour une automatisation réussie et une gestion réseau simplifiée et efficace.
+à travers cet exemple concret, nous montrerons que la standardisation n'est pas une contrainte, mais le socle d'une automatisation réussie et d'une gestion réseau simplifiée et efficace.
> [!NOTE] **CookBook**
> L'ensemble des actions expliquées dans cet article sont décrites [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates).
> Cette article **ne** nous fournira **pas** un guide Ă©tape par Ă©tape, mais fournira les liens vers le Cookbook qui lui, le fourni.
-## Le Concept du Site StandardisĂ© âïž
+## Le concept du site standardisé
L'automatisation efficace d'une infrastructure réseau repose sur une base solide de standardisation. Pour illustrer ce principe, nous avons défini un modÚle de **site standard**, caractérisé par une structure et des rÚgles de connectivité précises. Notre site "Paris" sera une instance concrÚte de ce modÚle standardisé.
-### Structure Type d'un Site Standard đą
+### Structure type d'un site standard
Un site standard est défini par les éléments suivants :
@@ -36,7 +36,7 @@ Un site standard est défini par les éléments suivants :
* **Un Ă Cinq BĂątiments Plain-Pied :** Chaque bĂątiment est dĂ©diĂ© Ă l'hĂ©bergement d'un seul client (bien que les mĂȘmes clients puissent ĂȘtre rĂ©partis sur plusieurs bĂątiments).
Chaque bùtiment standard est équipé d'un switch d'accÚs pour la connectivité locale et d'un unique leaf pour la connexion à la fabric.
-### ConnectivitĂ© Standard des Leafs đ
+### Connectivité standard des leafs
Dans un site standard, la connexion des Ă©quipements leaf aux spines suit les rĂšgles suivantes :
@@ -50,7 +50,7 @@ Dans un site standard, la connexion des Ă©quipements leaf aux spines suit les r
> Pour les besoins de ce **Proof of Concept**, nous avons opté pour une architecture simplifiée sans redondance avancée au niveau des connexions leaf-spine.
> L'objectif principal est de démontrer l'automatisation basée sur cette structure standardisée.
-### Plan d'Adressage IP pour le Site "Paris" đ
+### Plan d'adressage IP pour le site "Paris"
Pour notre site "Paris", nous allons utiliser les conteneurs de préfixes Netbox suivants, qui s'inscrivent dans notre stratégie d'adressage globale :
@@ -70,15 +70,15 @@ Pour notre site "Paris", nous allons utiliser les conteneurs de préfixes Netbox
Ces préfixes de type "Conteneur" sont spécifiques au site de "Paris" et seront utilisés par nos scripts d'automatisation pour attribuer les adresses IP aux différents équipements et clients de ce site, en respectant la structure standard que nous avons définie.
-## Le Site "Paris" : Une Instance de Notre ModĂšle StandardisĂ© đ
+## Le site "Paris" : une instance de notre modÚle standardisé
Notre site "Paris" suit scrupuleusement la structure et les rÚgles définies dans notre modÚle de site standard. Il comprendra donc une salle serveur avec les deux spines et pourra accueillir jusqu'à cinq bùtiments plain-pied, chacun équipé d'un leaf et d'un switch d'accÚs, connectés selon les conventions établies. L'adressage IP de "Paris" sera issu des conteneurs de préfixes standard que nous avons définis.
Cette standardisation est la clé qui nous permettra d'automatiser la création et la configuration de l'infrastructure de notre site "Paris" à l'aide des scripts que nous allons présenter ensuite.
-## Environment de test
+## Environnement de test
-Le POC se jouera sur ContainerLab, il est donc nécessaire de se reférencer à [cette article](../../documentation/devpod) afin de facilement reproduire l'installation et les outils.
+Le POC se joue sur ContainerLab, il est donc nécessaire de se référer à [cet article](../../documentation/devpod) pour reproduire facilement l'installation et les outils.
Nous utiliserons :
@@ -87,29 +87,29 @@ Nous utiliserons :
* Netbox
* Plugin : netbox_topology_views
-Pour plus de détails, [voici la documentationation d'installation](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/INSTALLATION.md)
+Pour plus de détails, [voici la documentation d'installation](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/INSTALLATION.md)
-## Scripting : L'Automatisation en Action ! âïž
+## Scripting : l'automatisation en action
Maintenant, on entre dans le vif du sujet : comment on utilise des scripts pour automatiser la création de notre fabric VXLAN en s'appuyant sur Netbox. On va voir deux scripts principaux qui font le gros du boulot !
-### Ătape 1 : On PrĂ©pare Netbox avec `import.py` đ ïž
+### Ătape 1 : on prĂ©pare Netbox avec `import.py`
Avant de construire notre réseau, il faut préparer notre "Source of Truth", Netbox. Le script [`import.py`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox) est là pour ça ! Il va injecter dans Netbox les infos de base de notre site "Paris" et les modÚles de nos équipements.
-**Les Ingrédients du Script :**
+**Les ingrédients du script :**
* **[`Devices/devices_model.yml`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/utilities/Devices/devices_model.yml) :** La carte d'identité de nos équipements (spines, leafs, access cEOS) avec leurs caractéristiques (nombre d'interfaces, types, etc.).
* **[`IPAM/subnet.yml`](https://github.com/darnodo/projet-vxlan-automation/blob/dev/utilities/IPAM/subnets.yml) :** Les infos de notre site "Paris" (région Europe, ville Paris) et les plans de nos blocs d'adresses IP (pour l'underlay, les loopbacks et nos clients).
-**Ce Que Fait le Script :**
+**Ce que fait le script :**
* Il lit le fichier `devices_model.yml` et crée les modÚles d'équipements correspondants dans Netbox. C'est comme enregistrer les types de matériel qu'on va utiliser.
* Il lit le fichier `IPAM/subnet.yml` et crée :
* La région "Europe" et le site "Paris".
* Les blocs d'adresses IP qu'on va utiliser pour notre réseau à Paris (nos "préfixes conteneurs").
-**Comment on Lance la Machine :**
+**Comment on lance la machine :**
On ouvre notre terminal et on tape la commande :
@@ -122,19 +122,19 @@ Remplace bien `http://localhost:8080` par l'adresse de ton Netbox et `YOUR_TOKEN
> [!TIP]
> Lien vers le Cookbook [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-populate-netbox)
-### Ătape 2 : On Monte la Fabric VXLAN avec `Create_Fabric/main.py` đ
+### Ătape 2 : on monte la fabric VXLAN avec `Create_Fabric/main.py`
Maintenant que Netbox est prĂȘt, on passe Ă la construction de notre rĂ©seau avec le script `Create_Fabric/main.py`. Ce script va crĂ©er tous les Ă©quipements, les connecter et leur attribuer des adresses IP, le tout en suivant notre modĂšle standardisĂ© pour le site "Paris".
-**Les Ătapes du Script :**
+**Les Ă©tapes du script :**
-1. **VĂ©rification des PrĂȘts ? â
** Le script commence par vérifier si tout ce dont il a besoin existe dans Netbox (les rÎles des équipements, les rÎles IP, les types d'équipements). On ne veut pas commencer à construire sur des bases instables !
-2. **Choix du Terrain : "Paris" Ăvidemment ! đ«đ·** Le script nous demande sur quel site on travaille. On sĂ©lectionne "Paris", notre site standard. Son petit nom "PA" va servir de base pour nommer nos Ă©quipements.
-3. **On Sort les Spines (x2) đȘ** Le script crĂ©e nos deux spines dans Netbox, en utilisant le bon modĂšle et le rĂŽle "spine". Ils sont baptisĂ©s `padc_sp1_00` et `padc_sp2_00`.
-4. **Les Paires Leaf/Access par BĂątiment đąâĄïž** Pour chaque bĂątiment de "Paris" (jusqu'Ă 5), le script crĂ©e une "location" Netbox et y installe un leaf (par exemple `pa01_lf1_00`) et un switch d'accĂšs (par exemple `pa01_sw1_00`).
-5. **CĂąblage Automatique đ§¶** Le script connecte virtuellement les Ă©quipements dans Netbox en suivant nos rĂšgles : `Eth1` du leaf vers `Eth*n*` du Spine 1, `Eth2` du leaf vers `Eth*n*` du Spine 2, et `Eth3` du leaf vers `Eth1` de l'access switch. Plus besoin de s'embrouiller avec les cĂąbles !
-6. **Distribution des IPs đșïž** Le script pioche dans les blocs d'adresses IP de "Paris" et attribue automatiquement les IPs aux interfaces (des /31 pour les liens entre les Ă©quipements et des /32 pour les loopbacks).
-7. **Attribution des ASNs đ·ïž** Pour finir, le script donne un numĂ©ro d'AS Ă chaque spine et Ă chaque leaf pour le routage BGP. Ces numĂ©ros sont enregistrĂ©s dans un champ spĂ©cial "ASN" dans Netbox.
+1. **Vérification préalable.** Le script commence par vérifier si tout ce dont il a besoin existe dans Netbox (les rÎles des équipements, les rÎles IP, les types d'équipements). On ne veut pas commencer à construire sur des bases instables.
+2. **Choix du site : "Paris" évidemment.** Le script nous demande sur quel site on travaille. On sélectionne "Paris", notre site standard. Son petit nom "PA" va servir de base pour nommer nos équipements.
+3. **On sort les spines (x2).** Le script crée nos deux spines dans Netbox, en utilisant le bon modÚle et le rÎle "spine". Ils sont baptisés `padc_sp1_00` et `padc_sp2_00`.
+4. **Les paires leaf/access par bùtiment.** Pour chaque bùtiment de "Paris" (jusqu'à 5), le script crée une "location" Netbox et y installe un leaf (par exemple `pa01_lf1_00`) et un switch d'accÚs (par exemple `pa01_sw1_00`).
+5. **CĂąblage automatique.** Le script connecte virtuellement les Ă©quipements dans Netbox en suivant nos rĂšgles : `Eth1` du leaf vers `Eth*n*` du Spine 1, `Eth2` du leaf vers `Eth*n*` du Spine 2, et `Eth3` du leaf vers `Eth1` de l'access switch. Plus besoin de s'embrouiller avec les cĂąbles.
+6. **Distribution des IPs.** Le script pioche dans les blocs d'adresses IP de "Paris" et attribue automatiquement les IPs aux interfaces (des /31 pour les liens entre les Ă©quipements et des /32 pour les loopbacks).
+7. **Attribution des ASNs.** Pour finir, le script donne un numéro d'AS à chaque spine et à chaque leaf pour le routage BGP. Ces numéros sont enregistrés dans un champ spécial "ASN" dans Netbox.
```bash
uv run Create_Fabric/main.py
@@ -150,7 +150,7 @@ Existing Sites:
Choose site number or 'new': 1
```
-**Le RĂ©sultat ? đ** En lançant ce script, on se retrouve avec toute notre infrastructure VXLAN de "Paris" crĂ©Ă©e et connectĂ©e dans Netbox, prĂȘte Ă ĂȘtre configurĂ©e !
+**Le rĂ©sultat ?** En lançant ce script, on se retrouve avec toute notre infrastructure VXLAN de "Paris" crĂ©Ă©e et connectĂ©e dans Netbox, prĂȘte Ă ĂȘtre configurĂ©e.
> [!NOTE] Netbox Plugin
> La configuration est facilement visualisable avec l'aide du plugin : [netbox_topology_views](https://github.com/netbox-community/netbox-topology-views)
@@ -160,13 +160,13 @@ Choose site number or 'new': 1
> [!TIP]
> Lien vers le Cookbook [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-create-fabric)
-### Ătape 3 : On configure nos clients avec `Create_Fabric/add_customers.py` đ§âđ»
+### Ătape 3 : on configure nos clients avec `Create_Fabric/add_customers.py`
-Ă ce niveau, la fabric est fonctionnelle, mais aucun client n'est configurĂ©. Qu'est-ce que cela signifie ? đ€ Cela veut dire que l'*underlay* â la base de notre rĂ©seau â est configurĂ© sur Netbox, et qu'il est possible de gĂ©nĂ©rer une configuration pour dĂ©ployer le BGP et configurer les AS. Cependant, les switches d'accĂšs et les leafs ne sont pas encore prĂȘts Ă accueillir des utilisateurs ou des services clients. Aucune information dans Netbox ne nous le permet encore.
+Ă ce niveau, la fabric est fonctionnelle, mais aucun client n'est configurĂ©. Qu'est-ce que cela signifie ? Cela veut dire que l'*underlay* â la base de notre rĂ©seau â est configurĂ© sur Netbox, et qu'il est possible de gĂ©nĂ©rer une configuration pour dĂ©ployer le BGP et configurer les AS. Cependant, les switches d'accĂšs et les leafs ne sont pas encore prĂȘts Ă accueillir des utilisateurs ou des services clients. Aucune information dans Netbox ne nous le permet encore.
-Dans notre approche standardisĂ©e, chaque bĂątiment est conçu pour accueillir **un** "client". Un client peut ĂȘtre, par exemple, une Ă©quipe spĂ©cifique au sein de l'entreprise ou un prestataire externe. Ă chaque client, nous attribuerons un VLAN (et dans notre fabric VXLAN, un VNI correspondant). đąâĄïžđ§âđ»
+Dans notre approche standardisĂ©e, chaque bĂątiment est conçu pour accueillir **un** "client". Un client peut ĂȘtre, par exemple, une Ă©quipe spĂ©cifique au sein de l'entreprise ou un prestataire externe. Ă chaque client, nous attribuerons un VLAN (et dans notre fabric VXLAN, un VNI correspondant).
-Pour rĂ©aliser cette configuration client, nous utilisons un script dĂ©diĂ© : **Create_Fabric/add_customers.py**. Celui-ci va nous guider pas Ă pas en nous demandant le VLAN et le VNI Ă attribuer, ainsi que le ou les bĂątiments oĂč sont basĂ©s nos clients. đ Voici un exemple de son exĂ©cution :
+Pour rĂ©aliser cette configuration client, nous utilisons un script dĂ©diĂ© : **Create_Fabric/add_customers.py**. Celui-ci va nous guider pas Ă pas en nous demandant le VLAN et le VNI Ă attribuer, ainsi que le ou les bĂątiments oĂč sont basĂ©s nos clients. Voici un exemple de son exĂ©cution :
```bash
⯠uv run Create_Fabric/add_customers.py
@@ -198,7 +198,7 @@ Available Locations:
Select locations (comma-separated indices): 1,3
```
-Une fois ces informations fournies, le script se charge d'automatiser plusieurs actions dans Netbox âš :
+Une fois ces informations fournies, le script se charge d'automatiser plusieurs actions dans Netbox :
* La création du tenant (représentant le client).
* L'attribution des bĂątiments (locations) au tenant.
@@ -206,22 +206,22 @@ Une fois ces informations fournies, le script se charge d'automatiser plusieurs
* La configuration logique des éléments VXLAN/VLAN associés.
* L'attribution des interfaces spécifiques sur les équipements d'accÚs pour ce client.
-Une fois Netbox correctement renseignĂ© avec toutes ces donnĂ©es clients đ, il devient alors possible d'en extraire la configuration rĂ©seau finale prĂȘte Ă l'emploi. âïž
+Une fois Netbox correctement renseignĂ© avec toutes ces donnĂ©es clients, il devient alors possible d'en extraire la configuration rĂ©seau finale prĂȘte Ă l'emploi.
-## La Magie des Templates : Netbox et Jinja2 Entrent en ScĂšne âš
+## Générer les configurations avec Netbox et Jinja2
Maintenant qu'on a notre inventaire réseau au top dans Netbox, comment on dit à nos équipements comment se configurer ? C'est là qu'interviennent les **Render Config** et les **templates Jinja2** !
> [!TIP] Templates
> Les templates utilisés sont présents [ici](https://github.com/darnodo/projet-vxlan-automation/tree/dev/templates).
-### Les Templates Jinja : Nos Recettes de Configuration đ
+### Les templates Jinja : nos recettes de configuration
-1. **Les Render Config, KĂ©sako ? đ€** Imagine Netbox comme un chef cuisinier qui a tous les ingrĂ©dients (nos Ă©quipements, leurs interfaces, leurs IPs, etc.). Les Render Config, c'est sa maniĂšre de transformer ces ingrĂ©dients en plats prĂ©parĂ©s, c'est-Ă -dire des fichiers de configuration pour nos Ă©quipements rĂ©seau.
+1. **Les Render Config, késako ?** Imagine Netbox comme un chef cuisinier qui a tous les ingrédients (nos équipements, leurs interfaces, leurs IPs, etc.). Les Render Config, c'est sa maniÚre de transformer ces ingrédients en plats préparés, c'est-à -dire des fichiers de configuration pour nos équipements réseau.
-2. **Jinja2 : Notre Langage de Recettes đŁïž** Pour Ă©crire ces "recettes" de configuration, Netbox utilise un moteur super puissant appelĂ© Jinja2. C'est un peu comme un langage de programmation simple qui nous permet de crĂ©er des modĂšles de configuration dynamiques. On peut y mettre des "trous" (des variables) qui seront remplis par les informations de nos Ă©quipements dans Netbox.
+2. **Jinja2 : notre langage de recettes.** Pour écrire ces "recettes" de configuration, Netbox utilise un moteur puissant appelé Jinja2, un peu comme un langage de programmation simple qui nous permet de créer des modÚles de configuration dynamiques. On peut y mettre des "trous" (des variables) qui seront remplis par les informations de nos équipements dans Netbox.
-3. **Un Petit Coup d'Ćil Ă une Recette đ** Prenons un exemple de template Jinja2 pour un de nos leafs :
+3. **Un petit coup d'Ćil Ă une recette.** Prenons un exemple de template Jinja2 pour un de nos leafs :
```jinja
hostname {{ device.name }}
@@ -242,7 +242,7 @@ Maintenant qu'on a notre inventaire réseau au top dans Netbox, comment on dit
Vous voyez les trucs entre doubles accolades `{{ ... }}` ? Ce sont nos variables ! Par exemple, `{{ device.name }}` sera remplacĂ© par le nom de notre leaf, et `{{ interface.name }}` par le nom de chaque interface. On peut mĂȘme faire des conditions (`{% if ... %}`) et des boucles (`{% for ... %}`) pour adapter la configuration.
-4. **Comment Netbox PrĂ©pare le Plat đł** Quand on demande Ă Netbox de gĂ©nĂ©rer la configuration pour un Ă©quipement (disons, notre `pa01_lf1_00`), voici ce qu'il se passe :
+4. **Comment Netbox prépare le plat.** Quand on demande à Netbox de générer la configuration pour un équipement (disons, notre `pa01_lf1_00`), voici ce qu'il se passe :
* Il va chercher toutes les infos sur ce leaf : son nom, ses interfaces, ses IPs, ses connexions, son ASN, etc.
* Il prend le template Jinja2 qu'on a associé au rÎle "leaf".
@@ -252,11 +252,11 @@ Maintenant qu'on a notre inventaire réseau au top dans Netbox, comment on dit
> [!TIP]
> Lien vers le Cookbook [ici](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates)
-### De Netbox au Lab : On Regarde et On Fait Ă la Main pour l'Instant đ„ïžâĄïžđ»
+### De Netbox au lab : on fait Ă la main pour l'instant
Maintenant qu'on sait comment Netbox génÚre les configurations, voyons comment on les utilise dans notre lab Containerlab.
-1. **On Jette un Ćil Ă la Configuration dans Netbox đ** Pour voir la configuration gĂ©nĂ©rĂ©e par Netbox pour un Ă©quipement, c'est simple :
+1. **On jette un Ćil Ă la configuration dans Netbox.** Pour voir la configuration gĂ©nĂ©rĂ©e par Netbox pour un Ă©quipement, c'est simple :
* Dans l'interface de Netbox, on va dans **Devices**.
* On clique sur l'équipement qui nous intéresse (par exemple, un de nos leafs).
@@ -264,27 +264,27 @@ Maintenant qu'on sait comment Netbox génÚre les configurations, voyons comment
![PA01 Leaf Configuration]()
-2. **La Touche Humaine dans Containerlab đïž** Pour l'instant, on n'a pas de script qui envoie automatiquement ces configurations Ă nos Ă©quipements dans Containerlab. Donc, on va faire Ă l'ancienne (mais c'est pour la dĂ©mo !) :
+2. **La touche humaine dans Containerlab.** Pour l'instant, on n'a pas de script qui envoie automatiquement ces configurations à nos équipements dans Containerlab. Donc, on va faire à l'ancienne (mais c'est bien suffisant pour la démo) :
* On se connecte Ă chaque Ă©quipement cEOS de notre lab via SSH (par exemple, en utilisant l'extension VSCode Containerlab comme on l'a vu dans le [cookbook](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#%EF%B8%8F-deploy-configuration)).
* On copie la configuration qu'on a visualisée dans Netbox (l'onglet **Render Config**).
* Et on la colle dans l'interface de ligne de commande de l'équipement cEOS (en mode configuration, bien sûr !).
-3. **Et AprĂšs ? Les Perspectives d'Ăvolution đ** Bien sĂ»r, cette Ă©tape de copier-coller, c'est pas le top de l'automatisation ! Mais c'est une premiĂšre Ă©tape pour voir comment Netbox peut ĂȘtre notre cerveau central. Dans le futur, on pourrait imaginer des outils comme Ansible ou NAPALM qui se connecteraient Ă Netbox, rĂ©cupĂ©reraient ces configurations gĂ©nĂ©rĂ©es et les appliqueraient automatiquement Ă nos Ă©quipements. C'est une piste pour de prochaines aventures dans l'automatisation ! đ
+3. **Et aprÚs ?** Cette étape de copier-coller n'est pas le sommet de l'automatisation, mais c'est une premiÚre étape pour voir comment Netbox peut devenir notre cerveau central. Plus tard, des outils comme Ansible ou NAPALM pourraient se connecter à Netbox, récupérer ces configurations générées et les appliquer automatiquement à nos équipements.
-## Validation de la communication â
+## Validation de la communication
-### Ping âœ
+### Ping
-Dans le cookbook, nous avons fait le choix de configurer 2 clients chacun dans 2 batiments différent, ce qui nous permet de réalisé un **ping**, pour rappel :
+Dans le cookbook, nous avons fait le choix de configurer 2 clients chacun dans 2 bùtiments différents, ce qui nous permet de réaliser un **ping**, pour rappel :
-1. đ Orange:
- * Sous RĂ©seau: 10.0.0.0/24
- * Hosts:
- * PA1: 10.0.0.10
- * PA3: 10.0.0.20
+1. Orange :
+ * Sous-réseau : 10.0.0.0/24
+ * Hosts :
+ * PA1 : 10.0.0.10
+ * PA3 : 10.0.0.20
-2. đŁ Purple
+2. Purple
* Sous RĂ©seau: 10.0.1.0/24
* Hosts:
* PA2: 10.0.1.10
@@ -316,11 +316,9 @@ Et ensuite, via VSCode, il est possible de lancer wireshark directement :
-## Conclusion âš
+## Conclusion
-Pour rĂ©sumer notre parcours, on a vu comment Netbox devient notre super alliĂ© đ„ pour automatiser le rĂ©seau VXLAN.
-La clĂ©, c'est de partir d'**une base standardisĂ©e** đ, c'est ce qui permet Ă Netbox de gĂ©nĂ©rer nos configurations presque tout seul grĂące aux templates Jinja2.
+Netbox devient un allié solide pour automatiser le réseau VXLAN.
+La clé, c'est de partir d'une base standardisée : c'est ce qui permet à Netbox de générer nos configurations presque tout seul grùce aux templates Jinja2.
-MĂȘme si, pour l'instant, on fait encore un peu de copier-coller đïž, le potentiel est immense ! Avoir toutes nos infos centralisĂ©es dans Netbox, c'est la premiĂšre Ă©tape pour vraiment simplifier la gestion de notre rĂ©seau et ouvrir la porte Ă une automatisation complĂšte. La standardisation n'est pas une contrainte, mais le tremplin vers plus d'efficacitĂ©. â
-
-Ce n'est que le dĂ©but ! Pensez Ă la suite : dĂ©ployer ces configs automatiquement, gĂ©rer des rĂ©seaux plus complexes... L'automatisation est lĂ , accessible, prĂȘte Ă vous faire gagner un temps prĂ©cieux. đđȘ
+On fait encore un peu de copier-coller sur la derniÚre étape, mais centraliser toutes nos infos dans Netbox est la premiÚre étape pour simplifier la gestion de notre réseau et ouvrir la porte à une automatisation complÚte. La suite : déployer ces configurations automatiquement et gérer des réseaux plus complexes.
diff --git a/content/netlab/automatisation réseau/vxlan_automation/fabric_topology.en.png b/content/netlab/automatisation réseau/vxlan_automation/fabric_topology.en.png
new file mode 100644
index 0000000..1728d99
Binary files /dev/null and b/content/netlab/automatisation réseau/vxlan_automation/fabric_topology.en.png differ
diff --git a/content/netlab/automatisation réseau/vxlan_automation/leaf1_capture_eth1.en.png b/content/netlab/automatisation réseau/vxlan_automation/leaf1_capture_eth1.en.png
new file mode 100644
index 0000000..208c00b
Binary files /dev/null and b/content/netlab/automatisation réseau/vxlan_automation/leaf1_capture_eth1.en.png differ
diff --git a/content/netlab/automatisation réseau/vxlan_automation/wireshark_eth2_leaf1.en.png b/content/netlab/automatisation réseau/vxlan_automation/wireshark_eth2_leaf1.en.png
new file mode 100644
index 0000000..9308f8d
Binary files /dev/null and b/content/netlab/automatisation réseau/vxlan_automation/wireshark_eth2_leaf1.en.png differ
diff --git a/content/netlab/first_lab/Graph_view.en.png b/content/netlab/first_lab/Graph_view.en.png
new file mode 100644
index 0000000..cc1ba70
Binary files /dev/null and b/content/netlab/first_lab/Graph_view.en.png differ
diff --git a/content/netlab/first_lab/VXLAN.en.svg b/content/netlab/first_lab/VXLAN.en.svg
new file mode 100644
index 0000000..8b45abe
--- /dev/null
+++ b/content/netlab/first_lab/VXLAN.en.svg
@@ -0,0 +1 @@
+Arista cEOS Arista cEOS Leaf 210.10.11... Host 1... Host 2... Arista cEOS VNI 1050... VLAN 50 VLAN 50 AS: 65001 Leaf 110.10.11... Leaf 110.10.10... AS: 65101 AS: 65102 10.1.1.0/31 10.1.1.2/31 10.1.1.1/31 10.1.1.3/31 SVI VLAN 50... SVI VLAN 50... Text is not SVG - cannot display ) or restart the step-ca process.
+```
+
+#### Running Step-CA as a systemd service
+
+Create a file:
+
+```bash
+vim /etc/systemd/system/step-ca.service
+```
+
+Paste in the following:
+
+```config
+[Unit]
+Description=step-ca
+After=syslog.target network.target
+
+[Service]
+User=adminCA
+Group=adminCA
+ExecStart=/bin/sh -c '/bin/step-ca /home/adminCA/.step/config/ca.json --password-file=/home/step/.step/pwd >> /var/log/step-ca/output.log 2>&1'
+Type=simple
+Restart=on-failure
+RestartSec=10
+
+[Install]
+WantedBy=multi-user.target
+```
+
+Create the log directory:
+
+```bash
+mkdir -p /var/log/step-ca
+chown -R adminCA:adminCA /var/log/step-ca
+```
+
+Reload the systemd daemon:
+
+```bash
+systemctl daemon-reload
+systemctl start step-ca.service
+```
+
+### Docker installation
+
+```bash
+docker run -it -v step:/home/step \
+ -p 9000:9000 \
+ -e "DOCKER_STEPCA_INIT_NAME=Lab" \
+ -e "DOCKER_STEPCA_INIT_DNS_NAMES=caserver.lab.loc,localhost,192.168.1.101" \
+ -e "DOCKER_STEPCA_INIT_REMOTE_MANAGEMENT=true" \
+ -e "DOCKER_STEPCA_INIT_ACME=true" \
+ smallstep/step-ca
+```
+
+## Accessing the CA from another client
+
+> [!NOTE] Adjust the port based on your installation:
+>
+> - **Binary:** port **443**
+> - **Docker:** port **9000**
+
+Install the Step CLI:
+
+```bash
+wget https://dl.step.sm/gh-release/cli/docs-cli-install/v0.24.3/step-cli_0.24.3_amd64.deb
+sudo dpkg -i step-cli_0.24.3_amd64.deb
+```
+
+Initialize your CA:
+
+```bash
+step ca bootstrap --ca-url https://caserver.lab.loc:$PORT/ --fingerprint 685059c30eb305db5272a7a199a2b5823624d55c732121ac65c06b0915d3c887
+```
+
+> [!TIP] To get the **fingerprint**, simply run:
+>
+> ```bash
+> step certificate fingerprint $(step path)/certs/root_ca.crt
+> ```
+>
+> For Docker, check the container logs.
+
+Example output:
+
+```bash
+admin@User:~$ step ca bootstrap --ca-url https://caserver.lab.loc:$PORT --fingerprint 685059c30eb305db5272a7a199a2b5823624d55c732121ac65c06b0915d3c887
+The root certificate has been saved in /home/admin/.step/certs/root_ca.crt.
+The authority configuration has been saved in /home/admin/.step/config/defaults.json.
+```
+
+Install the certificate:
+
+```bash
+step certificate install $(step path)/certs/root_ca.crt
+```
+
+---
+
+> [!TIP] **Installation on Debian:**
+>
+> - Copy the individual CRT files (PEM format) into `/usr/local/share/ca-certificates/`
+> - The files must be owned by `root:root` with `644` permissions
+> - Make sure the `ca-certificates` package is installed (if not, install it)
+> - Then, run as root:
+>
+> ```bash
+> # /usr/sbin/update-ca-certificates
+> ```
+>
+> All certificates will be consolidated into: `/etc/ssl/certs/ca-certificates.crt`
+
+---
+
+### Obtaining a certificate
+
+```bash
+admin@User:~$ step ca certificate nas.lab.loc srv.crt srv.key
+â Provisioner: contact@lab.loc (JWK) [kid: chyGkrZqp-BGSHUZ8v3jsPipegt2JLcC7y6RPq4OOkU]
+Please enter the password to decrypt the provisioner key:
+â CA: https://caserver.lab.loc:443
+â Certificate: srv.crt
+â Private Key: srv.key
+```
+
+---
+
+> [!TIP] To perform a health check:
+>
+> ```bash
+> curl https://caserver.lab.loc:443/health -k
+> ```
+
+---
+
+You may need to customize the `ca.json` file to increase the minimum certificate validity duration. Here's the directory structure:
+
+```bash
+.
+|-- certs
+| |-- intermediate_ca.crt
+| `-- root_ca.crt
+|-- config
+| |-- ca.json
+| `-- defaults.json
+|-- db
+| |-- 000000.vlog
+| |-- 000020.sst
+| |-- KEYREGISTRY
+| |-- LOCK
+| `-- MANIFEST
+|-- secrets
+| |-- intermediate_ca_key
+| |-- password
+| `-- root_ca_key
+`-- templates
+```
+
+Example `ca.json` file:
+
+```json
+{
+ "root": "/home/step/certs/root_ca.crt",
+ "federatedRoots": null,
+ "crt": "/home/step/certs/intermediate_ca.crt",
+ "key": "/home/step/secrets/intermediate_ca_key",
+ "address": ":9000",
+ "insecureAddress": "",
+ "dnsNames": [
+ "caserver.lab.loc",
+ "caserver",
+ "localhost",
+ "192.168.1.200"
+ ],
+ "logger": {
+ "format": "text"
+ },
+ "db": {
+ "type": "badgerv2",
+ "dataSource": "/home/step/db",
+ "badgerFileLoadingMode": ""
+ },
+ "authority": {
+ "enableAdmin": true,
+ "claims": {
+ "maxTLSCertDuration": "4380h"
+ }
+ },
+ "tls": {
+ "cipherSuites": [
+ "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
+ "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
+ ],
+ "minVersion": 1.2,
+ "maxVersion": 1.3,
+ "renegotiation": false
+ }
+}
diff --git a/content/netlab/sécurité/stepca.fr.md b/content/netlab/sécurité/stepca.fr.md
index ca06c22..fd8798b 100644
--- a/content/netlab/sécurité/stepca.fr.md
+++ b/content/netlab/sécurité/stepca.fr.md
@@ -6,45 +6,38 @@ cascade:
type: docs
---
-## đ Sources
+## Sources
-- [đ Documentation Officielle](https://smallstep.com/docs/tutorials/)
-- [đ ïž Step-CA en tant que Service systemd](https://angrysysadmins.tech/index.php/2022/09/grassyloki/step-ca-run-as-a-systemd-service/)
-- [đ Gestion des Certificats avec OpenSSL](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/)
+- [Documentation officielle](https://smallstep.com/docs/tutorials/)
+- [Step-CA en tant que service systemd](https://angrysysadmins.tech/index.php/2022/09/grassyloki/step-ca-run-as-a-systemd-service/)
+- [Gestion des certificats avec OpenSSL](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/)
-## đ€ Ă propos de Step-CA
+## Ă propos de Step-CA
-Step-CA est un ensemble d'outils astucieux dĂ©veloppĂ© par Smallstep, une entreprise spĂ©cialisĂ©e dans la gestion sĂ©curisĂ©e des identitĂ©s et l'automatisation des certificats. đ
-Sa mission ? Simplifier la mise en place et la gestion de vos propres autorités de certification (AC) avec facilité et sécurité !
+Step-CA est un ensemble d'outils développé par Smallstep, une entreprise spécialisée dans la gestion sécurisée des identités et l'automatisation des certificats.
+Sa mission est de simplifier la mise en place et la gestion de vos propres autorités de certification (AC).
### Principales fonctionnalités
-1. **Gestion des AutoritĂ©s de Certification** đ
- Configurez et gérez facilement vos propres AC. Créez des AC racines et intermédiaires, délivrez des certificats et gérez les révocations comme un pro.
+1. Gestion des autorités de certification : configurez et gérez facilement vos propres AC. Créez des AC racines et intermédiaires, délivrez des certificats et gérez les révocations.
-2. **Gestion SĂ©curisĂ©e des ClĂ©s** đĄïž
- Respecte les bonnes pratiques pour le stockage et la gestion sécurisés des clés, garantissant que vos clés cryptographiques restent protégées contre les accÚs non autorisés.
+2. Gestion sécurisée des clés : respecte les bonnes pratiques pour le stockage et la gestion des clés, afin que vos clés cryptographiques restent protégées contre les accÚs non autorisés.
-3. **Automatisation et ScalabilitĂ©** âïž
- Idéal pour les déploiements de petite à grande envergure. Profitez des API et intégrations qui automatisent la délivrance, le renouvellement et la révocation des certificats pour un cycle de vie sans accrocs.
+3. Automatisation et scalabilité : adapté aux déploiements de petite à grande envergure. Les API et intégrations automatisent la délivrance, le renouvellement et la révocation des certificats tout au long du cycle de vie.
-4. **SĂ©curitĂ© RenforcĂ©e** đ
- Grùce à l'utilisation d'algorithmes et de protocoles cryptographiques modernes, Step-CA prend en charge les certificats X.509 conformes aux normes de l'industrie, offrant un chiffrement robuste et des signatures numériques.
+4. Cryptographie moderne : Step-CA prend en charge les certificats X.509 conformes aux normes de l'industrie, avec des algorithmes et protocoles cryptographiques modernes pour le chiffrement et les signatures numériques.
-5. **IntĂ©gration avec l'Infrastructure** đ
- S'intÚgre parfaitement avec vos outils et systÚmes existants. Prend en charge diverses méthodes d'authentification telles que nom d'utilisateur/mot de passe, MFA et fournisseurs d'identité externes.
+5. Intégration avec l'infrastructure : s'intÚgre avec vos outils et systÚmes existants, et prend en charge diverses méthodes d'authentification telles que nom d'utilisateur/mot de passe, MFA et fournisseurs d'identité externes.
-6. **AuditabilitĂ© et ConformitĂ©** đ
- Avec des capacités complÚtes de journalisation et d'audit, vous pouvez suivre les activités des certificats et satisfaire aux exigences de conformité en toute simplicité.
+6. Auditabilité et conformité : la journalisation et l'audit complets permettent de suivre les activités des certificats et de répondre aux exigences de conformité.
-7. **API Conviviales pour les DĂ©veloppeurs** đ©âđ»đšâđ»
- Des API et SDK conçus pour les développeurs facilitent l'intégration de la gestion des certificats dans vos applications et flux de travail personnalisés.
+7. API conviviales pour les développeurs : des API et SDK conçus pour les développeurs facilitent l'intégration de la gestion des certificats dans vos applications et flux de travail personnalisés.
-**En résumé :** Step-CA de Smallstep est conçu pour rendre la gestion des autorités de certification à la fois ludique et sans tracas. Grùce à ses fonctionnalités sécurisées, scalables et conviviales, vous pouvez gérer facilement le cycle de vie de vos certificats tout en protégeant votre infrastructure !
+Step-CA de Smallstep est conçu pour rendre la gestion des autorités de certification simple : vous gérez le cycle de vie de vos certificats tout en protégeant votre infrastructure.
-## đ Installation
+## Installation
-### đ§ Installation Binaire
+### Installation binaire
#### 1. Step CLI
@@ -60,7 +53,7 @@ wget https://dl.step.sm/gh-release/certificates/docs-ca-install/v0.24.1/step-ca_
sudo dpkg -i step-ca_0.24.1_amd64.deb
```
-#### 3. Création d'un Utilisateur Spécifique
+#### 3. Création d'un utilisateur dédié
```bash
adduser adminCA
@@ -81,8 +74,8 @@ Quel nom souhaitez-vous donner au premier provisionneur de l'AC ?
Choisissez un mot de passe pour vos clés AC et le premier provisionneur.
â [laissez vide et nous en gĂ©nĂ©rerons un] :
-GĂ©nĂ©ration du certificat racine... fait ! đ
-GĂ©nĂ©ration du certificat intermĂ©diaire... fait ! đ
+Génération du certificat racine... fait !
+Génération du certificat intermédiaire... fait !
â Certificat racine : /home/adminCA/.step/certs/root_ca.crt
â ClĂ© privĂ©e racine : /home/adminCA/.step/secrets/root_ca_key
@@ -95,7 +88,7 @@ GĂ©nĂ©ration du certificat intermĂ©diaire... fait ! đ
Votre PKI est prĂȘte ! Pour gĂ©nĂ©rer des certificats pour des services individuels, consultez `step help ca`.
-đ **RETROACTION**
+**Retours :**
L'utilitaire step n'est pas instrumenté pour les statistiques d'utilisation. Il ne contacte pas un serveur central. Toutefois, vos retours sont trÚs précieux ! N'hésitez pas à nous écrire à feedback@smallstep.com, rejoindre les Discussions GitHub ou nous rejoindre sur Discord à [https://u.step.sm/discord](https://u.step.sm/discord).
```
@@ -111,10 +104,10 @@ step-ca .step/config/ca.json
$ step ca provisioner add acme --type ACME
â Configuration de l'AC : /home/adminCA/.step/config/ca.json
-SuccĂšs ! La configuration de votre `step-ca` a Ă©tĂ© mise Ă jour. Pour prendre en compte la nouvelle configuration, envoyez un SIGHUP (kill -1 ) ou redĂ©marrez le processus step-ca. đ
+SuccÚs ! La configuration de votre `step-ca` a été mise à jour. Pour prendre en compte la nouvelle configuration, envoyez un SIGHUP (kill -1 ) ou redémarrez le processus step-ca.
```
-#### Exécuter Step-CA en tant que Service systemd
+#### Exécuter Step-CA en tant que service systemd
Créez un fichier :
@@ -155,7 +148,7 @@ systemctl daemon-reload
systemctl start step-ca.service
```
-### đł Installation avec Docker
+### Installation avec Docker
```bash
docker run -it -v step:/home/step \
@@ -167,11 +160,11 @@ docker run -it -v step:/home/step \
smallstep/step-ca
```
-## đ AccĂšs Ă l'AC avec un Autre Client
+## AccĂšs Ă l'AC avec un autre client
-> [!NOTE] Adaptez le port en fonction de votre installation :
+> [!NOTE] Adaptez le port en fonction de votre installation :
>
-> - **Binaire :** port **443**
+> - **Binaire :** port **443**
> - **Docker :** port **9000**
Installez le Step CLI :
@@ -226,7 +219,7 @@ step certificate install $(step path)/certs/root_ca.crt
---
-### đ Obtenir un Certificat
+### Obtenir un certificat
```bash
admin@User:~$ step ca certificate nas.lab.loc srv.crt srv.key
diff --git a/hugo.yaml b/hugo.yaml
index 3414aa0..200b574 100644
--- a/hugo.yaml
+++ b/hugo.yaml
@@ -3,7 +3,16 @@ title: đ§âđ» Notebook
theme: hextra
defaultContentLanguage: fr
-locale: fr
+
+languages:
+ fr:
+ label: Français
+ locale: fr-FR
+ weight: 1
+ en:
+ label: English
+ locale: en-US
+ weight: 2
menu:
main:
@@ -23,8 +32,13 @@ menu:
weight: 5
params:
type: search
- - name: Gitea
+ - name: Language
weight: 6
+ params:
+ type: language-switch
+ label: true
+ - name: Gitea
+ weight: 7
url: "https://gitea.arnodo.fr/Damien"
params:
icon: gitea