Damien/Notebook
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Add bilingual French/English support with Hugo multilingual config

Browse Source 
Configure Hugo multilingual mode (fr default, en secondary) with
Hextra's language-switch menu entry, and translate all existing
content pages to English using Hugo's per-file language suffix
convention (.en.md alongside .fr.md).
This commit is contained in:
Damien
2026-07-18 09:48:18 +02:00
parent a4cffd8916
commit f49c0f45dd
20 changed files with 2706 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

112
content/_index.en.md Normal file
View File

@@ -0,0 +1,112 @@
---
title: Damien's NoteBook
layout: hextra-home
---
<!-- markdownlint-disable MD033 MD034-->
<div class="hx-mt-6 hx-mb-6">
{{< hextra/hero-headline >}}
Personal NoteBook
for NetDevOps and SRE
{{< /hextra/hero-headline >}}
</div>
<div class="hx-mb-12">
{{< hextra/hero-subtitle style="margin:.3rem 0 2rem 0">}}
Documentation and NetLabs to deploy,
To test and practice 🚀
{{< /hextra/hero-subtitle >}}
</div>
<div class="hx-mt-6"></div>
{{< 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 >}}
<div style="margin-top: 8rem; margin-bottom: 1.5rem;">
<div style="text-align: center; margin-bottom: 3rem;">
<h2 class="tech-title" style="
font-size: clamp(2rem, 5vw, 3.5rem);
font-weight: 800;
background: linear-gradient(135deg, #667eea 0%, #764ba2 50%, #f093fb 100%);
background-size: 200% 200%;
-webkit-background-clip: text;
-webkit-text-fill-color: transparent;
background-clip: text;
animation: gradient-shift 4s ease infinite;
letter-spacing: -0.02em;
margin: 0;
padding: 0.5rem 0;
">
Technologies used
</h2>
<p style="
color: #6b7280;
font-size: 1rem;
margin-top: 0.75rem;
font-weight: 400;
" class="dark:text-gray-400">
The tools and platforms I work with
</p>
</div>
{{< tech-banner speed="60s" height="80px" gap="4rem" >}}
</div>
<style>
@keyframes gradient-shift {
0%, 100% {
background-position: 0% 50%;
}
50% {
background-position: 100% 50%;
}
}
@media (prefers-color-scheme: dark) {
.tech-title {
background: linear-gradient(135deg, #a78bfa 0%, #ec4899 50%, #fbbf24 100%) !important;
background-size: 200% 200% !important;
-webkit-background-clip: text !important;
-webkit-text-fill-color: transparent !important;
background-clip: text !important;
}
}
[data-theme="dark"] .tech-title {
background: linear-gradient(135deg, #a78bfa 0%, #ec4899 50%, #fbbf24 100%) !important;
background-size: 200% 200% !important;
-webkit-background-clip: text !important;
-webkit-text-fill-color: transparent !important;
background-clip: text !important;
}
</style>

29
content/about/_index.en.md Normal file
View File

@@ -0,0 +1,29 @@
# About Me
🚀 As a **Network Automation Specialist at Airbus** — a major player in the **aerospace industry** — I'm dedicated to **simplifying network operations**, **reducing errors**, and **strengthening reliability** through **smart and innovative automation strategies**.
Before that, I built a **solid foundation in network engineering** at **Nokia and Orange**. Over time, my **passion for innovation** naturally led me toward **network automation** — and I never looked back! 💡🤖
I'm also a **big believer in continuous learning** 📚. Within my team, I encourage a **culture of collective growth**, **knowledge sharing**, and **constant curiosity**. Because in the end, **tech moves fast — and we have to keep up!** 🌱✨
## Professional Journey
🧑‍💻 **Network Automation Specialist @ Airbus**
Since 2023, I've been working at **Airbus** in Toulouse as a **Connectivity Automation Technology Specialist**. My mission? ✨ **Making networks smarter and more reliable** through automation. It's about optimizing efficiency, reducing errors, and building robust systems — both in the air and on the ground! 🌐✈️
🔧 **Over 6 Years at Nokia**
At **Nokia**, I specialized in **access network engineering**. I designed high-performance configurations, validated new technologies such as **5G and fiber**, and led customer projects. I also mentored teams and trained newcomers 👨‍🏫. It was an excellent school for **architecture**, **reliability**, and **real-world problem-solving**.
🧠 **My Networking Beginnings at Orange & Beyond**
I started my career at **Orange** as a **network technician**, where I learned the basics — from installing telecom equipment to troubleshooting complex connectivity issues 🔌. Before that, I also served in the **French National Gendarmerie** 👮, an experience that taught me discipline and teamwork.
💡 **From the Field to Automation**
Over the years, I moved from **hands-on engineering** to **network automation**, driven by my passion for innovation 🤖. Today, I focus on **automating processes**, improving **scalability**, and guiding teams toward the **future of networking**.
📚 **Lifelong Learner & Team Spirit Advocate**
I believe in **collective growth**. Whether through knowledge sharing, curiosity, or experimenting with new ideas, I always try to create an environment where **learning is part of everyday life** 🌱.

5
content/blog/_index.en.md Normal file
View File

@@ -0,0 +1,5 @@
---
title: "Blog"
---
My articles and experience feedback on networking, systems, and DevOps.

111
content/blog/aiops-observabilite-reseau-ia/index.en.md Normal file
View File

@@ -0,0 +1,111 @@
---
title: "AIOps and Network Observability: Preparing the Ground for AI"
date: 2026-07-14
authors:
- name: Damien
link: https://gitea.arnodo.fr/Damien
tags:
- AIOps
- Observability
- Network Automation
- AI Agents
---
I just finished building a full observability stack on my EVPN/VXLAN lab: topology, telemetry, and near real-time visualization. While building it, I realized I wasn't just doing monitoring — I was preparing a network to one day be "seen" by an AI. This first article sets the frame for a five-part series: why observability is the mandatory prerequisite before plugging an agent into your infrastructure.
<!--more-->
## What I've actually just built
Over the past few months, I've set up a Containerlab EVPN/VXLAN lab with 28 Arista EOS devices, spread across three sites (campus, core, datacenter). Beyond BGP EVPN itself, I wanted this lab to be **observable**: to be able to say, at any moment, what the real state of the network is. Not just "does it ping," but what the actual topology is, which interfaces are up, and which counters are drifting.
The result is a stack combining four building blocks:
- a network discovery and assurance tool that serves as the **topological source of truth** (who is connected to whom, which VLANs, which VRFs);
- **telemetry collection via gNMI** directly from the EOS devices;
- a **time-series database** for metric storage;
- a **visualization layer** automatically regenerated by cross-referencing topology and metrics.
It works today. But it's not the stack itself that made me write this article: it's a realization I had while building it. I wasn't just setting up monitoring — I was laying the foundations of a pipeline that could, one day, allow an AI agent to reason about my network. And that has a name.
## AIOps, not MLOps
Let's clear up an ambiguity right away, because the two terms are often conflated.
**MLOps** (Machine Learning Operations) is the discipline of operationalizing the lifecycle of machine learning models: training, dataset versioning, deployment, drift monitoring. That's not what I'm doing here. I'm not training any model, I'm not deploying any.
What I'm doing falls under **AIOps**: making an infrastructure observable and usable by automated systems, and eventually by an AI. The center of gravity isn't the model, it's the **infrastructure data**: its freshness, its consistency, its structure. That's exactly the scope of this series.
I still cite MLOps once, as a sister discipline, because it's the one that normalized an idea AIOps directly inherits: **observability isn't an option you bolt on afterward, it's the foundation everything else rests on.** The ML community learned this the hard way: a large share of projects that work in a notebook never survive the move to production, for lack of monitoring. The lesson applies to any system we claim to delegate to a machine. Including a network.
## The blind agent
Here's the central thesis of this article, and the thread running through the whole series.
An AI agent without observability is a blind agent. It only "sees" what it's exposed to. And a blind person given nothing to see doesn't stop moving for that reason: they keep going, with the same confidence as if they could see clearly.
Take a concrete case. I migrated a server from one VLAN to another last weekend. The topological source of truth hasn't yet gone through its discovery cycle: it still describes the old attachment. I open a conversation with an agent that's supposed to help me: "this server has stopped responding since this morning, where's the problem?"
The agent queries what it's been exposed to, reads the old topology, and answers confidently: "The server is attached to leaf-3 on VLAN 20, the uplink is nominal, check its IP configuration instead." The answer is coherent, well phrased, well argued. It's also entirely wrong: the server has been on leaf-7 since Saturday. The agent didn't lie, it didn't hallucinate in the strict sense: it reasoned correctly over stale data. And at no point did it flag that it might be wrong, because at no point was it aware that it couldn't see.
That's the real danger. An experienced human compensates for lack of observability with intuition, tribal memory, historical context ("that link has always been flaky, don't worry about it"). An agent has none of that. Partial data, stale data, or an inconsistency between the declared topology and the real state doesn't make it cautious: it makes it wrongly confident. The assurance of the answer generated in natural language masks the poverty of what it actually perceived.
I should note that no agent runs on this lab today: that will be precisely the subject of the last article in this series.
Observability, then, is not an end in itself. It's **the condition of possibility** for an agent to one day see the network before acting on it. Without it, you're not building an assistant: you're building a confidently blind one.
## A layered reading grid
What helped me structure all this was thinking in stacked layers, and accepting that you don't skip a step:
1. **Infrastructure first.** Is the base data reliable, complete, up to date? Topology, metrics, logs.
2. **The model next.** What's built on top: a correlation rule, a model, an LLM — does it receive quality inputs, and can its relevance be measured over time?
3. **Agent behavior last.** Can its answers and actions be trusted, and can they be audited?
The order isn't negotiable. An agent built on top of a shaky layer 1 inherits all its weaknesses in cascade, with the added bonus of the illusion of reliability that comes from an assertive answer by construction. You can't make up for a poorly instrumented infrastructure with a better prompt.
Applied to the network, this gives a very concrete order of priorities: before thinking "AI," you need reliable telemetry, an up-to-date topological source of truth, and usable logs. That's layer 1. It's what I've been working on for months, and it's what this series is going to detail.
## What "seeing" means for a network
Concretely, giving a network agent sight means bringing together three things:
- **An up-to-date topological source of truth.** Who is connected to what, which VLANs, which VRFs, which site. Without it, the agent doesn't even know what it's talking about: this is the core of the next article.
- **Real-time telemetry.** The living state of the network: interfaces up/down, counters, utilization, drift. Topology tells the structure; telemetry tells the behavior.
- **Usable logs.** The narrative of events: who changed what, when, and which errors were raised.
Of these three pillars, two are in place on my lab. The third, logs, remains a **work item I haven't tackled yet**. I say this honestly, because it's the kind of gap you're tempted to sweep under the rug: "I have the topology and the metrics, that's already good." Except an agent deprived of logs sees the present state without understanding how it got there. It's a prerequisite, not a bonus.
There's a principle running through this entire layer 1, one I've set for myself as a rule: **standardization over adaptability.** When naming conventions are respected everywhere: interfaces, hostnames, labels, no code has to compensate for discrepancies. It's a human who fixes the configuration upstream, not a script that guesses. This choice has a cost, ongoing rigor, but a direct benefit: clean, predictable data. And clean data is precisely what allows an agent to avoid building sound reasoning on false facts.
## Seeing isn't enough: you have to make it visible
Gathering the data: topology, telemetry, logs, isn't enough: it still needs to be structured and intelligently exposed to the agent, rather than dumped on it wholesale, at the risk of saturating its context window and getting answers just as confident but just as unreliable. This is where two concepts worth remembering come in, *context engineering* and the **Model Context Protocol (MCP)**, which I'll cover in detail in the fifth and final article of this series.
## The series
This series will follow the order in which I built (and am still building) this stack:
1. **(this article) AIOps and the importance of network observability**: the general framework.
2. **Topology as source of truth**: using network discovery and assurance to drive the rest of the stack.
3. **Real-time telemetry**: the mechanics of metrics and time series, from device to dashboard.
4. **Log management**: the piece still missing from my stack, which I need to tackle before going further.
5. **Making the network "visible" to an AI agent**: context engineering, MCP, and the early steps of AIOps applied to my lab.
## Conclusion
None of this is revolutionary in isolation: network telemetry has been around for a long time. What changes is the frame. As long as you instrument a network for humans, missing data translates into a question mark, someone notices the gap and goes looking for the info elsewhere. The day you plug in an agent, that same gap no longer produces doubt: it produces a wrong answer, stated with confidence.
That's why observability comes first, and the agent comes last: not because AI is a side matter, but because it's blind by default, and you don't hand a system its eyes before building what it's supposed to see. If you're building something similar, I'd be curious to compare notes on your architecture choices.
## Resources
### Concepts
- [What is AIOps?](https://www.ibm.com/think/topics/aiops) — definition and origin of the term (Gartner)
- [Model Context Protocol — official documentation](https://modelcontextprotocol.io/docs/getting-started/intro)
- [Introducing the Model Context Protocol](https://www.anthropic.com/news/model-context-protocol) — the original announcement, which frames well the problem MCP solves
- [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) — the reference article on context engineering, including the phenomenon of context window saturation
- *Observability Engineering* (O'Reilly, 2nd edition), Charity Majors, Liz Fong-Jones, George Miranda: the field's reference book, with a chapter dedicated to the rise of agents and LLMs
### My repo
- [arista-evpn-vxlan-clab](https://gitea.arnodo.fr/Damien/arista-evpn-vxlan-clab)

602
content/blog/migration-gitlab-gitea/index.en.md Normal file
View File

@@ -0,0 +1,602 @@
---
title: "Self-Hosting and Hybrid Cloud: My Personal Infrastructure with Gitea and Scaleway"
date: 2025-11-20
authors:
- name: Damien
link: https://gitea.arnodo.fr/Damien
tags:
- Homelab
- DevOps
- Self-Hosting
- Network Engineering
---
A write-up on building my personal infrastructure: migrating from GitHub to self-hosted Gitea, and deploying ephemeral network labs on Scaleway. All powered by Proxmox and Wireguard.
<!--more-->
## Context and Motivations
As a network engineer working in automation and orchestration, I've always needed an environment to experiment and learn in. Until recently, I used GitHub for my code and ContainerLab locally/on AWS via [DevPod](/documentation/devpod/) for my network simulations.
But several needs emerged:
- **Learning**: Deploying and managing a full Git server with CI/CD
- **Sovereignty**: Hosting my data in France (or at least in Europe), controlling my infrastructure
- **Flexibility**: Being able to spin up network labs on demand without saturating my local machine
- **Automation**: Scripting the complete provisioning of my environments
## The Overall Architecture
![Architecture](global_architecture.fr.svg)
### Tech Stack
**Homelab**:
- **Proxmox VE**: Hypervisor for VMs and LXC
- **LXC Containers**: Gitea, runners, various services
- **Ansible**: Configuration management and updates
- **Grafana/Prometheus/Loki**: Monitoring and observability
**Public exposure**:
- **Scaleway Dedibox**: Dedicated instance with a fixed IP
- **Nginx Proxy Manager**: Reverse proxy with automatic SSL
- **Wireguard VPN**: Secure tunnel between Scaleway and the homelab
**Scaleway Cloud**:
- **Object Storage**: Hosting for the Hugo blog (S3-compatible)
- **Instances**: Ephemeral network labs provisioned on demand
- **Scaleway CLI**: Full automation
## Part 1: Migrating from GitHub to Self-Hosted Gitea
### Why Gitea?
[Gitea](https://gitea.io/) is a lightweight Git server, perfect for self-hosting:
- **Lightweight**: Ideal for an LXC on Proxmox
- **GitHub Actions compatible**: Migrate workflows without rewriting them
- **Full-featured**: Issues, PRs, CI/CD, webhooks
- **Open-source**: Active community
### Deployment with Proxmox Helper Scripts
Rather than configuring everything manually, I use the excellent [Proxmox Helper Scripts](https://community-scripts.github.io/ProxmoxVE/), which automate the creation of preconfigured LXCs.
**Installing Gitea**:
```bash
# On the Proxmox node, run the script
bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/gitea.sh)"
```
The script:
- Creates a Debian 12 LXC
- Installs Gitea and sqlite
- Configures the systemd services
- Sets up the environment with the correct permissions
**Post-installation configuration**:
- Web access: `http://<IP_LXC>: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 = <private_key>
ListenPort = 51820
[Peer]
# Dedibox Scaleway
PublicKey = <dedibox_public_key>
AllowedIPs = 10.0.0.2/32
Endpoint = <dedibox_public_ip>: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 = <secret_token>
```
**Prometheus scrape config**:
```yaml
scrape_configs:
- job_name: 'gitea'
metrics_path: /metrics
bearer_token: '<secret_token>'
static_configs:
- targets: ['<gitea_lxc_ip>: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>-<arch>)
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&region=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@<IP_PUBLIQUE>
# 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 infrastructure (Proxmox homelab + Scaleway cloud) offers the best of both worlds:
- **Control**: Sensitive data (code, configurations) stays in the homelab
- **Flexibility**: Cloud resources for one-off needs
- **Learning**: A complete environment to experiment in
- **Sovereignty**: Everything hosted in France, with European providers
Self-hosting isn't just about costs (spoiler: I pay about as much as before, if not more), but about learning, mastery, and a deep understanding of systems.
For a network or DevOps engineer, it's the ideal 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/)

13
content/documentation/VXLAN/_index.en.md Normal file
View File

@@ -0,0 +1,13 @@
---
title: "VXLAN"
sidebar:
open: true
cascade:
type: docs
---
<!-- markdownlint-disable MD033 MD034-->
{{< cards >}}
{{< card link="/en/documentation/vxlan/beginners/vxlan-for-beginners/" title="VXLAN for Beginners" subtitle="Introduction to VXLAN" icon="science" >}}
{{< /cards >}}

152
content/documentation/VXLAN/beginners/vxlan-for-beginners.en.md Normal file
View File

@@ -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).
![OSI Layers](media_layers.fr.png#center)
> [!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.).
![Container transport](transports.fr.png#center)
## 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 essential.
## 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, overcomes the limitations of switch MAC address tables, and enables flexible service deployment. Furthermore, when paired with an efficient control plane (BGP EVPN), it greatly simplifies the management of modern **overlay** networks.
### Conclusion 🏁
In short, 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, **VXLAN** becomes essential.
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 better grasp the magic that happens as your data travels further and further, 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.

16
content/documentation/_index.en.md Normal file
View File

@@ -0,0 +1,16 @@
---
title: Documentation
cascade:
type: docs
---
<!-- markdownlint-disable MD033 MD034-->
{{< 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 >}}

317
content/documentation/devpod/_index.en.md Normal file
View File

@@ -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:
![Provider_list](provider.fr.png#center)
We're going to focus on the **AWS Provider** — even though there are plenty of configuration options:
![Provider_list](aws_options.fr.png#center)
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**.
![devpod_user_sumup](devpod_user.fr.png#center)
**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**.
![added_new_provider](new_provider.fr.png#center)
## 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**.
![new_worspace](new_worskapce.fr.png#center)
Wait a few moments, and your cloud-based environment will pop up in VS Code. 🎊
![vscode](vscode.fr.png#center)
### 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. 💰
![Stopped Instance](stopped_instance.fr.png#center)
### 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. ♻️
![Delete Instance](delete_instance.fr.png#center)
## 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! 🎉

14
content/documentation/securité/_index.en.md Normal file
View File

@@ -0,0 +1,14 @@
---
title: "Security"
sidebar:
open: true
cascade:
type: docs
---
<!-- markdownlint-disable MD033 MD034-->
{{< 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 >}}

194
content/documentation/securité/cadenas_vert/ssl.en.md Normal file
View File

@@ -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.
![Certificat](certificat.png)
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's absolutely **ESSENTIAL** 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 is crucial to make sure 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 Is All This Essential For 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 is absolutely crucial 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.
In short, this little padlock is a sign of respect toward your users, a mark of seriousness for your business, and a protection for everyone. 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.
To sum up our journey in a few words:
* 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.

158
content/documentation/securité/ssl_bumping/ssl_bumping.en.md Normal file
View File

@@ -0,0 +1,158 @@
---
title: "SSL Bumping: How to Analyze SSL Traffic"
date: 2025-06-22T20:00:00+02:00
weight: 3
cascade:
type: docs
---
## Introduction: What Happens Behind the Padlock?
The padlock icon in your browser's address bar is supposed to guarantee that your exchanges are encrypted and unreadable by a third party. Yet, in many corporate networks or school environments, this traffic is indeed analyzed. How is this possible without breaking the encryption?
This is where **SSL Bumping** (or TLS interception) comes in. Far from being a simple hacking technique, it's a commonly used and legitimate mechanism for inspecting HTTPS traffic.
Understanding SSL Bumping means understanding the limits of end-to-end encryption in certain contexts, and knowing how companies secure (or monitor) their networks. In this article, we'll dissect how this technique works and see how to set it up via a hands-on lab: [squid-ssl-bumping-lab](https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab).
## Part 1: The Concept of TLS Interception
### An Acknowledged "Man-in-the-Middle"
The principle of HTTPS is comparable to sending mail in a safe where only the sender and the recipient have the key. If a network device (like a corporate proxy) needs to analyze the content to block malware or prevent a data leak, it hits a wall: the traffic is encrypted.
**SSL Bumping** gets around this problem by inserting itself in the middle of the communication:
![SSL Bumping Expliqué](images/ssl_bumping_explique.fr.svg#center)
The proxy will:
1. **Intercept** the client's HTTPS connection.
2. **Decrypt** the traffic to analyze it.
3. **Re-encrypt** the data before sending it to the final server.
Instead of having a single secure connection between your browser and the website, there are two: one between you and the proxy, and another between the proxy and the site. The proxy acts as a relay that reads everything as it passes through.
> [!NOTE] **A Question of Vocabulary**
> We often talk about **SSL Bumping** (the historical term used by the Squid proxy), **TLS interception** (the technically accurate term today), or **HTTPS inspection**. In all cases, it's a *Man-In-The-Middle* (MITM) attack, but one carried out in a controlled and voluntary manner by the network administrator.
### Why Inspect Encrypted Traffic?
TLS interception addresses real needs, mainly in the professional world:
1. **Network security**: Detecting malware downloaded via HTTPS or blocking access to malicious sites.
2. **Data Loss Prevention (DLP)**: Making sure confidential information doesn't leave the company.
3. **Filtering and compliance**: Blocking certain content (social networks, inappropriate sites) according to company or institution policy.
4. **Debugging**: Analyzing API requests or diagnosing complex application issues.
Of course, this total visibility implies great responsibility, since the proxy has access to passwords, session cookies, and personal data.
## Part 2: How Does It Work Technically?
To insert itself into an HTTPS connection without the browser blocking access, the proxy has to pull off a cryptographic sleight of hand.
### Step 1: The Proxy Becomes a Certificate Authority (CA)
For SSL Bumping to work, the proxy must be able to generate certificates on the fly for any website. To do this, the administrator configures the proxy with its own internal Certificate Authority (CA).
### Step 2: On-the-Fly Certificate Generation
When you try to access `https://www.example.com`:
![Génération des faux certificats](images/generation_des_faux_certificats.fr.svg)
1. The proxy intercepts your request.
2. It connects to the real `example.com` server and retrieves its legitimate certificate.
3. It instantly generates a **fake certificate** for `example.com`, signed by its own internal CA.
4. It presents this fake certificate to your browser.
> [!TIP] **Why Doesn't the Browser Block the Connection?**
> Normally, faced with a fake certificate, your browser displays a big security alert. For the interception to be transparent, the proxy's CA certificate must be **deployed and trusted** on your machine (often via group policies in a corporate setting, or manually). This is why you can't do SSL Bumping discreetly on a stranger's network.
### Step 3: Analysis in Plain Text
Once the two TLS tunnels are established (Client ↔ Proxy and Proxy ↔ Server), the proxy sees the HTTP requests passing through in plain text. It has access to the full URLs, headers, POST parameters, and response bodies. It can then apply its filtering or antivirus scanning rules.
## Part 3: Hands-On Practice with Squid
To really understand the mechanism, nothing beats hands-on practice. I've prepared a test environment based on Squid, a widely used open-source proxy that handles SSL Bumping perfectly: [squid-ssl-bumping-lab](https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab).
### Lab Architecture
![Architecture du lab SSL](images/architecture_du_lab_ssl.fr.svg)
### Quick Deployment
1. **Clone the repository**:
```bash
git clone https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab
cd squid-ssl-bumping-lab
```
2. **Generate the lab's Certificate Authority**:
```bash
mkdir -p ssl
openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 \
-keyout ssl/squid-ca-key.pem \
-out ssl/squid-ca-cert.pem \
-subj "/CN=Squid CA/O=Mon Lab/C=FR"
```
3. **Start the environment**:
```bash
docker-compose up --build -d
```
4. **Configure your client**:
- Set the HTTP/HTTPS proxy to `localhost:3128`.
- Import the `ssl/squid-ca-cert.pem` file into the trusted certificate authorities of your browser or your system.
> [!WARNING] **Security Warning**
> This lab is intended for educational use. Never use this CA outside of this test environment, and remember to remove it from your system once you're done experimenting.
### Observing the Interception
Once the configuration is complete, browse a few HTTPS sites and check Squid's logs:
```bash
docker-compose exec squid tail -f /var/log/squid/access.log
```
You'll notice that Squid logs the full URLs of the sites visited, proving that it does decrypt the traffic. If you click on the padlock in your browser, you'll see that the site's certificate is now issued by "Squid CA".
## Part 4: Detection and Alternatives
### How to Know If You're Being Intercepted?
If you're on a corporate network, it's very likely that your traffic is being inspected. To check:
1. Click on the padlock icon in your browser.
2. Display the certificate details.
3. Check the "Issuer" field. If it's the name of your company or a network device (like Fortinet, Palo Alto, Zscaler) instead of a recognized public authority (Let's Encrypt, DigiCert...), your traffic is being intercepted.
Some applications use **Certificate Pinning**: they hardcode the legitimate server's certificate fingerprint. If a proxy tries to present a fake certificate, the application will simply refuse to connect, making interception impossible.
### The Alternative: SNI Filtering
SSL Bumping is heavy to manage and raises privacy concerns. A common alternative is filtering based on **SNI (Server Name Indication)**.
When initializing the TLS connection, the client indicates in plain text, in the initial request, the domain name it wants to reach. The proxy can read this information without needing to decrypt the rest of the traffic. This allows blocking access to certain domains in a much less intrusive way, even though visibility into the full URL and page content is lost.
## Part 5: Legal Issues and Best Practices
TLS interception is not a technical decision to be taken lightly. It involves access to potentially sensitive data (personal credentials, banking data, health information).
In a corporate setting, implementing SSL Bumping must be accompanied by strict rules:
- **Transparency**: Users must be informed that their professional traffic is being analyzed (generally via the IT charter).
- **Exceptions (Bypass)**: It's essential to configure the proxy to not intercept certain categories of sites, particularly banking and healthcare services, in order to respect employees' privacy.
- **CA Security**: The private key of the internal certificate authority must be protected drastically. If it's compromised, an attacker could generate valid fake certificates across the entire IT fleet.
## Conclusion
The padlock in your browser indicates that the connection is encrypted, but it doesn't guarantee that there's no one between you and the final server. SSL Bumping clearly illustrates the ongoing trade-off between a network's overall security and individual privacy.
It's a powerful and often indispensable technique in the corporate world, but one that requires rigorous and ethical implementation. Feel free to use the provided lab to experiment for yourself and better understand the underlying mechanisms of our daily connections.
---
**Useful resources:**
- 🧪 [The Squid SSL Bumping lab](https://gitea.arnodo.fr/Damien/squid-ssl-bumping-lab)
- 📖 [Official Squid documentation on SSL Bump](http://www.squid-cache.org/Doc/config/ssl_bump/)
- 🔐 [OWASP recommendations on TLS inspection](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)

16
content/netlab/_index.en.md Normal file
View File

@@ -0,0 +1,16 @@
---
title: "Netlab"
cascade:
type: docs
---
<!-- markdownlint-disable MD033 MD034-->
{{< hextra/hero-subtitle >}}
A deep dive into NetLabs
{{< /hextra/hero-subtitle >}}
{{< cards >}}
{{< card link="/en/netlab/netlab/" title="What is a Netlab?" subtitle="Why and how we use NetLab" icon="science" >}}
{{< card link="/en/netlab/first_lab/" title="My First NetLab" subtitle="How to deploy a NetLab using DevPod" icon="docker" >}}
{{< /cards >}}

13
content/netlab/automatisation réseau/_index.en.md Normal file
View File

@@ -0,0 +1,13 @@
---
title: "Network Automation"
sidebar:
open: true
cascade:
type: docs
---
<!-- markdownlint-disable MD033 MD034-->
{{< cards >}}
{{< card link="/en/netlab/automatisation-réseau/vxlan_automation/" title="VXLAN Automation with Netbox" subtitle="How to use Netbox to automate network configuration" icon="science" >}}
{{< /cards >}}

326
content/netlab/automatisation réseau/vxlan_automation/_index.en.md Normal file
View File

@@ -0,0 +1,326 @@
---
title: VXLAN Automation with Netbox
date: 2025-04-02T20:00:00+02:00
weight: 3
cascade:
type: docs
---
## Introduction 📚
In this article, we're going to explore how to automate the deployment of a VXLAN infrastructure by relying on **Netbox** as our single source of truth (*Source of Truth*) and its **"Render Config"** feature.
The main idea behind this project is to simplify network configuration management by limiting the use of external orchestration tools, which can sometimes make inventory management more complex. We're going to show how Netbox can automatically generate the configurations for our network devices from Jinja2 templates, provided we respect one fundamental principle: **standardizing our infrastructure.** 💡
To illustrate this approach, we'll use the example of a fictional site, **"Paris"**, designed according to clear and precise standardization rules. This standardization will allow us to:
1. **Model** the entire "Paris" site infrastructure in Netbox (buildings, customers, fabric).
2. **Generate** the network device configurations based on the information centralized in Netbox.
3. **Validate** the proper operation of this automated infrastructure using a **NetLab** lab environment running on ContainerLab.
Through this concrete example, we'll highlight the fact that standardization isn't a constraint, but rather the **essential foundation** for successful automation and simplified, efficient network management.
> [!NOTE] **CookBook**
> All of the actions explained in this article are described [here](https://github.com/darnodo/projet-vxlan-automation/blob/dev/documentation/CookBook.md#-apply-templates).
> This article will **not** provide a step-by-step guide, but will provide links to the Cookbook, which does.
## The Concept of the Standardized Site ⚙️
Effective automation of a network infrastructure relies on a solid foundation of standardization. To illustrate this principle, we've defined a **standard site** model, characterized by a precise structure and precise connectivity rules. Our "Paris" site will be a concrete instance of this standardized model.
### Typical Structure of a Standard Site 🏢
A standard site is defined by the following elements:
* **A Central Server Room:** Unique within the site, it hosts the fabric's two spines (Spine 1 and Spine 2), forming the core of the network infrastructure.
* **One to Five Single-Story Buildings:** Each building is dedicated to hosting a single customer (although the same customers can be spread across multiple buildings).
Each standard building is equipped with an access switch for local connectivity and a single leaf for connecting to the fabric.
### Standard Leaf Connectivity 🔗
In a standard site, the connection of leaf devices to the spines follows these rules:
* **Leaf Eth1 Interface:** Always connected to the Spine 1 Eth1 interface.
* **Leaf Eth2 Interface:** Always connected to the Spine 2 Eth2 interface.
* **Leaf Eth3 Interface:** Always dedicated to connecting to the access switch present in the same building.
![Site Standard](<Site Standard.drawio.svg>)
> [!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)
![Topologie de Paris](fabric_topology.png)
> [!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. ⚙️
## The Magic of Templates: Netbox and Jinja2 Take the Stage ✨
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 super powerful engine called Jinja2. It's 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: Looking and 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](<Render Config.png>)
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 (but that's 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? Future Perspectives 🚀** Of course, 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. In the future, we could imagine tools like Ansible or NAPALM connecting to Netbox, retrieving these generated configurations, and automatically applying them to our devices. That's a path for future adventures in automation! 😉
## 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:
![Extension vscode](leaf1_capture_eth1.png)
![Capture Wireshark](wireshark_eth2_leaf1.png)
## Conclusion ✨
To sum up our journey, we've seen how Netbox becomes our best ally 🥇 for automating the VXLAN network.
The key is to start from **a standardized foundation** 📐 — that's what allows Netbox to generate our configurations almost entirely on its own, thanks to Jinja2 templates.
Even though, for now, we're still doing a bit of copy-pasting 🖐️, the potential is huge! Having all our information centralized in Netbox is the first step toward truly simplifying our network management and opening the door to full automation. Standardization isn't a constraint, but a springboard toward greater efficiency. ✅
This is only the beginning! Think about what comes next: automatically deploying these configs, managing more complex networks... Automation is here, accessible, ready to save you precious time. 🚀💪

219
content/netlab/first_lab/_index.en.md Normal file
View File

@@ -0,0 +1,219 @@
---
title: "My First Lab"
date: 2025-02-14T12:00:00+02:00
weight: 2
sidebar:
open: true
cascade:
type: docs
---
## Introduction 📚
In this article, we're going to explore how to set up our very first Containerlab netlab using **DevPod**.
We'll focus on using a cloud provider, in this case **AWS**, to host our project.
Why the **Cloud**? Because network labs can consume a huge amount of resources, and we need to be able to deploy, stop, and destroy them quickly, both for performance and cost efficiency. 💡💰
We'll achieve this by combining:
- **DevPod**
- **DevContainer**
- **Containerlab**
In addition, we'll use a simple topology that you can find on my [GitHub repository](https://github.com/darnodo/VXLAN-EVPN). Our main goal is to deploy this lab on AWS with DevPod.
Let's get to it! 🚀😊
## Prerequisites 🔧
Before starting, a few important steps need to be taken:
1. **AWS Environment Authorization**:
Make sure DevPod is authorized to access your AWS environment. For a detailed guide on configuring DevPod with AWS, check out my article on this [topic](../../documentation/devpod/). 🔑
2. **Containerlab Topology**:
We need a topology file that Containerlab can understand. In our case, we'll create a simple VXLAN topology. 🗺️
## Containerlab Topology 🔄
Our lab will simulate a VXLAN topology consisting of:
- **1 Spine switch**
- **2 Leaf switches**
- **2 Host nodes**
The following diagram illustrates the VXLAN topology:
![VXLAN Topology](VXLAN.fr.svg#center)
Here's the Containerlab topology file (`lab_vxlan.yml`) used for this configuration:
```yaml
name: vxlan-evpn-irb
topology:
nodes:
spine1:
kind: ceos
image: ceos:4.32.0.1F
mgmt-ipv4: 172.20.20.101
leaf1:
kind: ceos
image: ceos:4.32.0.1F
mgmt-ipv4: 172.20.20.11
leaf2:
kind: ceos
image: ceos:4.32.0.1F
mgmt-ipv4: 172.20.20.12
host1:
kind: linux
image: alpine:latest
binds:
- hosts/h1_interfaces:/etc/network/interfaces
mgmt-ipv4: 172.20.20.21
host2:
kind: linux
image: alpine:latest
binds:
- hosts/h2_interfaces:/etc/network/interfaces
mgmt-ipv4: 172.20.20.22
links:
- endpoints: ["spine1:eth1", "leaf1:eth1"]
- endpoints: ["spine1:eth2", "leaf2:eth1"]
- endpoints: ["leaf1:eth2", "host1:eth1"]
- endpoints: ["leaf2:eth2", "host2:eth1"]
```
### Breaking Down the Topology 🧐
1. **Name and Structure**:
- `name: vxlan-evpn-irb` – This is the name of the lab.
- The topology is split into **nodes** (devices) and **links** (connections between devices).
2. **Nodes**:
- **Spine Layer**:
- `spine1`: A containerized Arista cEOS switch using image version `4.32.0.1F`.
- **Management IP**: `172.20.20.101`
- **Leaf Layer**:
- `leaf1` and `leaf2`: Arista cEOS switches using the same image version.
- **Management IPs**: `172.20.20.11` and `172.20.20.12`
- **Host Layer**:
- `host1` and `host2`: Linux containers running Alpine Linux.
- They include custom network interface configurations mounted from the host.
- **Management IPs**: `172.20.20.21` and `172.20.20.22`
3. **Links**:
- **Spine to Leaf**:
- `spine1:eth1` ↔ `leaf1:eth1`
- `spine1:eth2` ↔ `leaf2:eth1`
- **Leaf to Host**:
- `leaf1:eth2` ↔ `host1:eth1`
- `leaf2:eth2` ↔ `host2:eth1`
This topology represents a typical spine-leaf architecture, common in datacenters to enable Layer 2 and Layer 3 connectivity with VXLAN EVPN configurations. 🔗💻
## Deploying the Lab 🛠️
We'll deploy the lab with **DevPod** in two ways:
### 1. Using the Repository 📥
1. **Validate the AWS Provider Configuration**:
Make sure your AWS provider is properly configured. More details [here](../../documentation/devpod/). ✅
2. **Create a Workspace**:
- Go to the **Workspace** tab and click **Create Workspace**.
- Specify the **Workspace source**: use the [GitHub repository](https://github.com/darnodo/VXLAN-EVPN).
- Select **AWS** as the provider.
- Choose your default IDE.
- Finally, click **Create Workspace**.
![DevPod Configuration](devpod_configuration.fr.png#center)
### 2. Using a Local Folder 🗂️
If you prefer to use your local repository:
- The only difference is in the **Workspace source**.
- Simply point it to your local repository.
![DevPod Configuration - Local](devpod_configuration_local.fr.png#center)
## Starting the Lab 🎬
> [!WARNING] cEOS Images
> The lab uses **cEOS image v4.32.0.1F**.
> To download this image, head over to the [Arista download page](https://www.arista.com/en/support/software-download). ⚠️
1. **Import the cEOS Image**:
Save the cEOS image into your `network_images` folder by dragging and dropping it into VSCode.
Import the image using the following command:
```bash
docker import network_images/cEOS64-lab-4.32.0.1F.tar.xz ceos:4.32.0.1F
```
2. **Deploy the Lab**:
Deploy the lab using Containerlab:
```bash
sudo containerlab deploy -t lab_vxlan.yml
```
Follow the CLI instructions to configure your devices. For detailed configuration steps, check out [this guide](https://github.com/darnodo/VXLAN-EVPN/tree/main/documentation/eos_configuration). 🔧🖥️
3. **Visualize the Architecture**:
Check the deployed topology using Containerlab's graphical view:
```bash
containerlab graph -t lab_vxlan.yml
```
Ports (for example, port 50080 mentioned in `devcontainer.json`) are forwarded. Access the graphical view via [localhost](http://localhost:50080).
![Graph View](Graph_view.fr.png#center)
## Using EdgeShark 🦈
EdgeShark is a web tool that lets you capture packets from your lab environment. It forwards lab captures to Wireshark running locally. 📡🔍
For more information, check out the [EdgeShark getting started guide](https://edgeshark.siemens.io/#/getting-started?id=optional-capture-plugin).
### Configuring EdgeShark in the DevContainer 🐳
In the **DevContainer** configuration, the following `postCreateCommand` was added:
```bash
sudo mkdir -p /opt/edgeshark && sudo curl -sL https://github.com/siemens/edgeshark/raw/main/deployments/wget/docker-compose.yaml -o /opt/edgeshark/docker-compose.yaml
```
This command downloads a Docker Compose file to make it easier to use EdgeShark. 🚀
### Launching EdgeShark ⚡
To start EdgeShark, run:
```bash
cd /opt/edgeshark
DOCKER_DEFAULT_PLATFORM= docker compose up -d
```
Access EdgeShark via [localhost:5001](http://localhost:5001).
- **EdgeShark View**:
![EdgeShark View](edgeshark.fr.png#center)
- **Integration with Wireshark**:
By clicking the Wireshark icon in EdgeShark, you can launch Wireshark locally.
![EdgeShark Interface](edgeshark_interface.fr.png#center)
![EdgeShark and Wireshark](edge_wireshark.fr.png#center)
## Conclusion 🎉
In this article, we walked through the steps to deploy a VXLAN EVPN lab using Containerlab, DevPod, and AWS. We covered the following key points:
- **Setting up the prerequisites** for AWS and Containerlab. 🔑
- **Creating a detailed topology file** for a spine-leaf architecture. 🗺️
- **Deploying the lab** using both a GitHub repository and a local folder. 📥🗂️
- **Starting the lab** with Docker and Containerlab. 🚀🐳
- **Using EdgeShark** to capture packets and integrate Wireshark for in-depth analysis. 🦈🔍
By following these steps, you'll be able to easily deploy and manage a scalable network lab environment in the cloud. Happy networking, and enjoy your lab adventures! 😄🎊

68
content/netlab/netlab.en.md Normal file
View File

@@ -0,0 +1,68 @@
---
title: "Introducing NetLabs"
weight: 1
cascade:
type: docs
---
## Introduction
📡 In a world where computer networks play an ever-growing role in our daily lives, understanding the principles and logic that drive them is becoming increasingly essential.
Virtual network labs (also known as "NetLab" or "Virtual Network Lab") are an ideal approach to teaching these concepts, allowing us to simulate complex network environments and experiment risk-free.
I want to share with you how my "NetLabs" work, which will regularly be linked to documentation articles (in the **documentation** category). They will let us practice, observe, or understand the workings of concepts explained theoretically beforehand.
As part of NetLab, these will mainly be deployed using the ContainerLab tool. For more complex architectures, we'll use GNS3.
## What is ContainerLab? 🛠️
ContainerLab is a powerful open-source tool that enables the creation of complete virtual network labs. With it, you can simulate a multitude of complex network architectures, with equipment such as routers, switches, servers, and other network devices.
This platform offers great flexibility in designing exercises, making it possible to cover various topics such as learning network protocols, security, or device configuration. Users can therefore focus on analyzing and solving problems without worrying about the underlying technical details.
Installing ContainerLab won't be covered here, but all the information is available on the official website [here](https://containerlab.dev/install/).
## What is GNS3? 💻
GNS3, or Graphical Network Simulator-3, is open-source software mainly used for the **simulation** and **emulation** of computer networks. It allows network engineers, students, and professionals to design, test, and troubleshoot complex networks in a virtual environment before deploying them in the real world. GNS3 is particularly appreciated for its ability to integrate various network hardware and software, such as Cisco routers and switches, as well as virtual machines, to create realistic network topologies.
As before, installing GNS3 won't be covered here; for more information, the documentation is available [here](https://docs.gns3.com/docs/).
## GNS3 vs ContainerLab ⚔️
GNS3 and ContainerLab are two powerful tools for network simulation and emulation, but they differ in their approach, features, and main use cases. Here's a quick comparison between the two:
### GNS3
**Advantages:**
1. **Intuitive Graphical Interface:** GNS3 offers a user-friendly graphical interface that lets users drag and drop components to build network topologies.
2. **Multivendor Support:** It supports a wide range of network hardware and software, including Cisco routers and switches, as well as virtual machines.
3. **Flexibility:** GNS3 can be used on Windows, macOS, and Linux, and it integrates well with other tools like Wireshark for traffic analysis.
4. **Active Community:** A large community of users and developers provides extensive support and a wealth of online resources.
**Drawbacks:**
1. **System Resources:** GNS3 can be resource-intensive, especially when emulating complex devices or large topologies.
2. **Configuration Complexity:** Initial setup can be complex, especially for new users.
### ContainerLab
**Advantages:**
1. **Lightweight and Performant:** ContainerLab uses containers to emulate network devices, making it lighter and more performant than VM-based solutions.
2. **Automation and DevOps:** It integrates well with DevOps and automation tools like Ansible, making automated deployment and network management easier.
3. **Simplified Configuration:** Topologies are defined via YAML files, making configuration simpler and scriptable.
4. **Support for Modern Technologies:** It supports modern technologies like Docker and Kubernetes, offering greater flexibility for cloud-native environments.
**Drawbacks:**
1. **Less Multivendor Support:** While ContainerLab supports several types of network containers, it may not have the same level of multivendor support as GNS3.
2. **Learning Curve:** For those unfamiliar with containerization concepts, the learning curve can be steeper.
## Conclusion 📊
**GNS3** is ideal for those looking for an intuitive graphical interface and broad device support, particularly useful for students and traditional network engineers. **ContainerLab**, on the other hand, is better suited to modern environments and DevOps practices, offering a lightweight and scriptable solution for network simulation.
The choice between GNS3 and ContainerLab therefore mainly depends on the user's specific needs in terms of flexibility, performance, and integration with other tools and technologies.

13
content/netlab/sécurité/_index.en.md Normal file
View File

@@ -0,0 +1,13 @@
---
title: "Security"
sidebar:
open: true
cascade:
type: docs
---
<!-- markdownlint-disable MD033 MD034-->
{{< cards >}}
{{< card link="/en/netlab/sécurité/stepca/" title="Self-Hosted Certificate Manager" subtitle="Deploy a certificate authority and manage certificates" icon="document-check" >}}
{{< /cards >}}

312
content/netlab/sécurité/stepca.en.md Normal file
View File

@@ -0,0 +1,312 @@
---
title: "Self-Hosted Certificate Manager"
date: 2024-08-01T20:00:00+02:00
weight: 2
cascade:
type: docs
---
## 🔗 Sources
- [📖 Official Documentation](https://smallstep.com/docs/tutorials/)
- [🛠️ Step-CA as a systemd Service](https://angrysysadmins.tech/index.php/2022/09/grassyloki/step-ca-run-as-a-systemd-service/)
- [🔐 Certificate Management with OpenSSL](https://www.golinuxcloud.com/tutorial-pki-certificates-authority-ocsp/)
## 🤖 About Step-CA
Step-CA is a clever toolset developed by Smallstep, a company specializing in secure identity management and certificate automation. 🚀
Its mission? To simplify setting up and managing your own certificate authorities (CAs) with ease and security!
### Key Features
1. **Certificate Authority Management** 🔑
Easily configure and manage your own CAs. Create root and intermediate CAs, issue certificates, and handle revocations like a pro.
2. **Secure Key Management** 🛡️
Follows best practices for securely storing and managing keys, ensuring your cryptographic keys stay protected from unauthorized access.
3. **Automation and Scalability** ⚙️
Ideal for small to large-scale deployments. Take advantage of APIs and integrations that automate certificate issuance, renewal, and revocation for a smooth lifecycle.
4. **Enhanced Security** 🔒
Through the use of modern cryptographic algorithms and protocols, Step-CA supports industry-standard X.509 certificates, providing robust encryption and digital signatures.
5. **Infrastructure Integration** 🌐
Integrates seamlessly with your existing tools and systems. Supports various authentication methods such as username/password, MFA, and external identity providers.
6. **Auditability and Compliance** 📜
With comprehensive logging and auditing capabilities, you can track certificate activity and meet compliance requirements with ease.
7. **Developer-Friendly APIs** 👩‍💻👨‍💻
APIs and SDKs designed for developers make it easy to integrate certificate management into your applications and custom workflows.
**In short:** Step-CA by Smallstep is designed to make certificate authority management both fun and hassle-free. Thanks to its secure, scalable, and user-friendly features, you can easily manage your certificates' lifecycle while protecting your infrastructure!
## 🚀 Installation
### 🔧 Binary Installation
#### 1. 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
```
#### 2. Step-CA
```bash
wget https://dl.step.sm/gh-release/certificates/docs-ca-install/v0.24.1/step-ca_0.24.1_amd64.deb
sudo dpkg -i step-ca_0.24.1_amd64.deb
```
#### 3. Creating a Dedicated User
```bash
adduser adminCA
```
#### Configuration
```bash
$ step ca init --password-file=password.txt
✔ Deployment type: Standalone
What would you like to name your new PKI?
✔ (e.g. Smallstep) : Lab
✔ (e.g. ca.example.com[,10.1.2.3,etc.]) : ca.lab.loc, localhost, 192.168.1.101
What IP and port will your new CA bind to? (:443 will bind to 0.0.0.0:443). 1.101
✔ (e.g. :443 or 127.0.0.1:443) : :443
What would you like to name the CA's first provisioner?
✔ (e.g. you@smallstep.com) : contact@lab.loc
Choose a password for your CA keys and the first provisioner.
✔ [leave empty and we will generate one] :
Generating root certificate... done! 🎉
Generating intermediate certificate... done! 🎊
✔ Root certificate: /home/adminCA/.step/certs/root_ca.crt
✔ Root private key: /home/adminCA/.step/secrets/root_ca_key
✔ Root fingerprint: 7d754397c6897aa87d21e33c64daad7be087dc6fe18bf04627848ae1c8e26a4f
✔ Intermediate certificate: /home/adminCA/.step/certs/intermediate_ca.crt
✔ Intermediate private key: /home/adminCA/.step/secrets/intermediate_ca_key
✔ Database folder: /home/adminCA/.step/db
✔ Default configuration: /home/adminCA/.step/config/defaults.json
✔ Certificate Authority configuration: /home/adminCA/.step/config/ca.json
Your PKI is ready to go. To generate certificates for individual services, see `step help ca`.
💌 **FEEDBACK**
The step utility is not instrumented for usage statistics. It does not contact a central server. Your feedback is, however, extremely valuable! Please consider writing to feedback@smallstep.com, joining GitHub Discussions, or joining us on Discord at [https://u.step.sm/discord](https://u.step.sm/discord).
```
Start Step-CA:
```bash
step-ca .step/config/ca.json
```
#### Enable ACME
```bash
$ step ca provisioner add acme --type ACME
✔ CA Configuration: /home/adminCA/.step/config/ca.json
Success! Your `step-ca` configuration has been updated. To pick up the new configuration, send a SIGHUP (kill -1 <pid>) 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
}
}

18
hugo.yaml
View File

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