Ajout documentation OpenWRT et article freeze SSH, MTU et MSS clamping
- Ajouter documentation complète OpenWRT dans section Homelab actuel - Créer article blog expliquant problème freeze SSH via tunnel GRE-TAP - Documenter solutions MTU et MSS clamping pour tunnels réseau - Ajouter traductions anglaises complètes pour nouveau contenu
This commit is contained in:
parent
8ed3805789
commit
87a2508769
22 changed files with 1086 additions and 0 deletions
122
docs/openwrt/backhaul-wifi-mesh.md
Normal file
122
docs/openwrt/backhaul-wifi-mesh.md
Normal file
|
|
@ -0,0 +1,122 @@
|
|||
---
|
||||
sidebar_position: 2
|
||||
title: Backhaul WiFi Mesh avec 802.11s
|
||||
---
|
||||
|
||||
# Backhaul WiFi Mesh avec 802.11s
|
||||
|
||||
Ce guide explique comment créer un backhaul WiFi entre deux routeurs sous OpenWRT en utilisant le protocole 802.11s (mesh point).
|
||||
|
||||
## Objectif
|
||||
|
||||
Créer un lien WiFi mesh entre deux routeurs OpenWRT pour étendre le réseau sans câble Ethernet. Le second routeur sera configuré en "Dumb AP" et communiquera avec le routeur principal via un backhaul mesh sécurisé.
|
||||
|
||||
## Prérequis
|
||||
|
||||
- Deux routeurs avec OpenWRT installé
|
||||
- Accès SSH ou interface web LuCI sur les deux routeurs
|
||||
- Un routeur principal configuré (avec DHCP et firewall actifs)
|
||||
|
||||
## Étape 1 : Configuration du second routeur en Dumb AP
|
||||
|
||||
Le second routeur doit être transformé en "Dumb AP" (Access Point basique sans services réseau). Il existe un script automatique pour cette configuration, mais nous allons détailler la méthode manuelle via l'interface LuCI.
|
||||
|
||||
### Script automatique (optionnel)
|
||||
|
||||
Pour une configuration automatique, vous pouvez utiliser le script de **OneMarcFifty** disponible sur [GitHub - onemarcfifty/openwrt-mesh](https://github.com/onemarcfifty/openwrt-mesh).
|
||||
|
||||
### Configuration manuelle via LuCI
|
||||
|
||||
Il faut **désactiver** les services suivants sur le second routeur :
|
||||
|
||||
1. **Firewall** : **System → Startup** → Désactiver `firewall`
|
||||
2. **DNS** : **Network → DHCP and DNS** → Décocher "DNS server"
|
||||
3. **Serveur DHCP** : **Network → Interfaces → LAN → DHCP Server** → Cocher "Ignore interface"
|
||||
|
||||
Ces services ne sont pas nécessaires car le routeur principal gère la sécurité, le DNS et la distribution d'adresses IP.
|
||||
|
||||
### Configuration de l'interface LAN
|
||||
|
||||
Configurez l'interface LAN du second routeur pour qu'elle soit sur le **même subnet** que le routeur principal :
|
||||
|
||||
1. Accédez à **Network → Interfaces → LAN**
|
||||
2. Configurez les paramètres suivants :
|
||||
- **Protocol** : DHCP client (recommandé) ou Static address
|
||||
- Si Static : **IPv4 address** : `.2` sur le subnet (exemple : si le routeur principal est en `192.168.1.1`, mettre `192.168.1.2`)
|
||||
|
||||
|
||||
|
||||
:::tip Sauvegarde de configuration
|
||||
Avant de modifier l'interface LAN, notez l'IP actuelle ou configurez une interface de secours pour pouvoir accéder au routeur en cas de problème.
|
||||
|
||||
|
||||
:::
|
||||
|
||||
## Étape 2 : Configuration du réseau mesh 802.11s
|
||||
|
||||
Le protocole 802.11s permet de créer un réseau mesh WiFi natif. Les deux routeurs utiliseront ce protocole pour établir le backhaul.
|
||||
|
||||
### Paramètres du mesh
|
||||
|
||||
Les deux routeurs doivent avoir **exactement les mêmes paramètres** suivants :
|
||||
|
||||
1. **Mode WiFi** : Mesh Point
|
||||
2. **Mesh ID** : identifiant unique pour votre mesh (même valeur sur les deux routeurs)
|
||||
3. **Interface réseau** : créer une interface dédiée au mesh (exemple : `mesh0`)
|
||||
4. **Sécurité** : WPA3-SAE (Personal) recommandé
|
||||
5. **Mot de passe** : mot de passe fort et aléatoire
|
||||
|
||||
### Génération d'un mot de passe sécurisé
|
||||
|
||||
Utilisez cette commande pour générer un mot de passe fort aléatoire :
|
||||
|
||||
```bash
|
||||
openssl rand -base64 32
|
||||
```
|
||||
|
||||
Ou depuis OpenWRT :
|
||||
|
||||
```bash
|
||||
dd if=/dev/urandom bs=1 count=32 2>/dev/null | base64
|
||||
```
|
||||
|
||||
### Configuration via LuCI
|
||||
|
||||
1. Accédez à **Network → Wireless**
|
||||
2. Sélectionnez l'interface WiFi à utiliser pour le mesh (généralement radio0 ou radio1)
|
||||
3. Configurez les paramètres suivants :
|
||||
|
||||
|
||||
|
||||
**Paramètres essentiels** :
|
||||
- **Mode** : Mesh Point (802.11s)
|
||||
- **Mesh ID** : votre identifiant mesh (identique sur les deux routeurs)
|
||||
- **Network** : créer ou sélectionner une interface réseau dédiée au mesh
|
||||
- **Encryption** : WPA3-SAE
|
||||
- **Key** : le mot de passe généré précédemment
|
||||
|
||||
:::warning Synchronisation des paramètres
|
||||
Les deux routeurs doivent avoir **exactement** le même Mesh ID et le même mot de passe, sinon ils ne pourront pas établir la connexion mesh.
|
||||
:::
|
||||
|
||||
### Interface réseau pour le mesh
|
||||
|
||||
Créez une interface réseau dédiée pour le mesh :
|
||||
1. **Network → Interfaces → Add new interface**
|
||||
2. **Name** : `mesh0` (ou tout autre nom descriptif)
|
||||
3. **Protocol** : Static address ou DHCP client
|
||||
4. **Device** : sélectionner le device mesh créé (généralement `mesh0`)
|
||||
|
||||
Cette interface servira de base pour le tunnel GREtap dans la partie suivante.
|
||||
|
||||
## Vérification
|
||||
|
||||
Après configuration, vérifiez que :
|
||||
1. Le second routeur obtient une IP sur le même subnet que le routeur principal
|
||||
2. Les deux routeurs peuvent se pinguer mutuellement
|
||||
3. L'interface mesh est active et connectée (vérifiable dans **Network → Wireless**)
|
||||
4. Le backhaul mesh est établi et stable
|
||||
|
||||
## Prochaine étape
|
||||
|
||||
Une fois le backhaul mesh configuré, vous pouvez passer à la [configuration GREtap pour étendre les VLANs](./gretap-vlan.md) à travers ce lien mesh.
|
||||
210
docs/openwrt/gretap-vlan.md
Normal file
210
docs/openwrt/gretap-vlan.md
Normal file
|
|
@ -0,0 +1,210 @@
|
|||
---
|
||||
sidebar_position: 3
|
||||
title: Tunnels GREtap pour VLANs
|
||||
---
|
||||
|
||||
# Tunnels GREtap pour VLANs à travers le mesh
|
||||
|
||||
Ce guide explique comment étendre des VLANs à travers le backhaul WiFi mesh en utilisant des tunnels GREtap.
|
||||
|
||||
## Prérequis
|
||||
|
||||
- Backhaul WiFi mesh configuré selon le [guide précédent](./backhaul-wifi-mesh.md)
|
||||
- Les deux routeurs doivent pouvoir communiquer via l'interface mesh
|
||||
- Accès à l'interface LuCI sur les deux routeurs
|
||||
|
||||
## Pourquoi GREtap plutôt que BATMAN-adv ?
|
||||
|
||||
Pour un réseau mesh composé de **seulement deux routeurs**, GREtap est préférable à BATMAN-adv pour plusieurs raisons :
|
||||
|
||||
### Avantages de GREtap dans ce scénario
|
||||
|
||||
1. **Point-à-point suffisant** : Avec deux routeurs, un tunnel point-à-point simple est suffisant. BATMAN-adv est conçu pour des topologies mesh complexes avec de nombreux nœuds et chemins redondants.
|
||||
|
||||
2. **Moins d'overhead** : GREtap a un overhead de protocole plus faible que BATMAN-adv. Avec seulement deux nœuds, les fonctionnalités avancées de routage mesh de BATMAN ne sont pas nécessaires.
|
||||
|
||||
3. **Simplicité de configuration** : GREtap est plus simple à configurer et à déboguer. Pas besoin de gérer les tables de routage mesh, les métriques de chemin, ou les algorithmes de sélection de route.
|
||||
|
||||
4. **Prévisibilité** : Le trafic emprunte toujours le même chemin (le tunnel direct). Pas de changements dynamiques de route.
|
||||
|
||||
5. **Support natif** : GREtap est largement supporté et documenté dans OpenWRT sans nécessiter de modules kernel additionnels complexes.
|
||||
|
||||
:::info BATMAN-adv : quand l'utiliser ?
|
||||
BATMAN-adv devient intéressant quand vous avez :
|
||||
- 3 nœuds mesh ou plus
|
||||
- Plusieurs chemins possibles entre nœuds
|
||||
- Besoin de redondance et de basculement automatique
|
||||
- Topologie mesh dynamique avec nœuds mobiles
|
||||
:::
|
||||
|
||||
## Installation des packages requis
|
||||
|
||||
Installez le package nécessaire sur **les deux routeurs** :
|
||||
|
||||
```bash
|
||||
opkg update
|
||||
opkg install luci-proto-gre
|
||||
```
|
||||
|
||||
Ou via l'interface LuCI : **System → Software**, recherchez et installez `luci-proto-gre`.
|
||||
|
||||
## Configuration du tunnel GREtap
|
||||
|
||||
### Étape 1 : Créer l'interface GREtap
|
||||
|
||||
Sur **les deux routeurs**, créez une nouvelle interface GREtap :
|
||||
|
||||
1. Accédez à **Network → Interfaces → Add new interface**
|
||||
2. Configurez les paramètres de base
|
||||
|
||||
**Paramètres de base** :
|
||||
- **Name** : nom court (exemple : `gr`)
|
||||
- **Protocol** : GRETAP (Ethernet over GRE)
|
||||
|
||||
:::danger Limitation de longueur des noms d'interface
|
||||
OpenWRT créé automatiquement l'interface avec le préfixe `gretap-`. Par exemple, si vous nommez votre interface `trunk`, OpenWRT créera `gretap-trunk`.
|
||||
|
||||
**Problème** : Pour faire passer des VLANs, la notation sera `gretap-trunk.100`, ce qui fait **16 caractères** et dépasse la limite !
|
||||
|
||||
**Exemple problématique** :
|
||||
- Interface nommée `trunk` → Device créé : `gretap-trunk` (13 caractères)
|
||||
- VLAN 100 → `gretap-trunk.100` (16 caractères) ❌ **TROP LONG**
|
||||
|
||||
**Solution** : Utilisez un nom **très court** comme `gr`, `t`, ou `g`.
|
||||
- Interface nommée `gr` → Device créé : `gretap-gr` (9 caractères)
|
||||
- VLAN 100 → `gretap-gr.100` (13 caractères) ✅ **OK**
|
||||
|
||||
:::
|
||||
|
||||
:::info Origine de cette limitation
|
||||
Les noms d'interface réseau sous Linux sont stockés dans une structure qui utilise un tableau de 16 octets. Ce tableau inclut le terminateur nul `\0`, donc la longueur maximale d'un nom d'interface réseau est de **15 caractères** (16 - 1 = 15).
|
||||
:::
|
||||
|
||||
**Paramètres du tunnel (General Settings)** :
|
||||
- **Remote IPv4 address or FQDN** : IP de l'autre routeur sur l'interface mesh
|
||||
- **Local IPv4 address** : IP de ce routeur sur l'interface mesh
|
||||
|
||||
|
||||
|
||||
**Options avancées (Advanced Settings)** :
|
||||
|
||||
Il est important de configurer les options avancées correctement :
|
||||
|
||||
- ⬜ **Use TTL on tunnel interface** : laisser décoché
|
||||
- ⬜ **Use PMTU discovery** : laisser décoché (équivalent à **Don't fragment**)
|
||||
- ⬜ **Default gateway** : DÉCOCHER cette option (important !)
|
||||
- **Bind interface** : sélectionner l'interface mesh (par exemple `lan`)
|
||||
|
||||
|
||||
|
||||
:::tip Pourquoi décocher ces options ?
|
||||
- **PMTU discovery / Don't fragment** : Le trafic WiFi mesh peut nécessiter de la fragmentation. Autoriser la fragmentation évite les pertes de paquets.
|
||||
- **Default gateway** : Le tunnel GREtap ne doit pas devenir la passerelle par défaut du routeur.
|
||||
:::
|
||||
|
||||
## Extension des VLANs à travers le tunnel
|
||||
|
||||
### Principe
|
||||
|
||||
Pour faire passer un VLAN à travers le tunnel GREtap, il faut créer un **bridge device** qui contient :
|
||||
- Le port physique ou l'interface VLAN locale
|
||||
- Le port GREtap VLAN correspondant
|
||||
|
||||
La notation utilisée pour un port GREtap VLAN est : `@<nom_device_gretap>.<numero_vlan>`
|
||||
|
||||
**Exemple** : Pour le VLAN 100 avec un tunnel nommé `gr` (device : `gretap-gr`) → `@gretap-gr.100`
|
||||
|
||||
### Configuration sur le routeur principal
|
||||
|
||||
#### Étape 1 : Créer le bridge device pour le VLAN
|
||||
|
||||
1. Accédez à **Network → Interfaces → Devices → Add device configuration**
|
||||
2. Créez un **Bridge device** :
|
||||
|
||||
**Configuration du bridge** :
|
||||
- **Device type** : Bridge device
|
||||
- **Device name** : `br-lab` (ou nom descriptif pour votre VLAN)
|
||||
- **Bridge ports** : Ajouter les ports suivants :
|
||||
- Le port physique ou VLAN local (exemple : `lan3` pour un port physique)
|
||||
- Le port GREtap VLAN : `@gretap-gr.100` (adapter selon votre device et numéro VLAN)
|
||||
|
||||
|
||||
|
||||
#### Étape 2 : Créer l'interface réseau pour le VLAN
|
||||
|
||||
1. **Network → Interfaces → Add new interface**
|
||||
2. Configurez l'interface :
|
||||
|
||||
**Paramètres (General Settings)** :
|
||||
- **Name** : `LAB` (ou nom descriptif)
|
||||
- **Protocol** : Static address
|
||||
- **Device** : Sélectionner le bridge créé précédemment (`br-lab`)
|
||||
- **IPv4 address** : L'adresse IP de ce routeur sur le VLAN (exemple : `192.168.100.1`)
|
||||
- **IPv4 netmask** : Le masque du VLAN (exemple : `255.255.255.0`)
|
||||
|
||||
|
||||
|
||||
**Serveur DHCP (DHCP Server)** :
|
||||
|
||||
Configurez le serveur DHCP pour ce VLAN afin de distribuer des IPs aux clients :
|
||||
|
||||
|
||||
|
||||
**Firewall Settings** :
|
||||
|
||||
Assignez l'interface à une zone firewall appropriée (exemple : `homelab_zone` ou créer une nouvelle zone) :
|
||||
|
||||
|
||||
|
||||
:::tip Static DHCP Leases
|
||||
Une fois que le Dumb AP récupère une IP via DHCP sur ce VLAN, vous pouvez configurer un **static DHCP lease** pour lui assigner une IP fixe.
|
||||
|
||||
Exemple : mettre le Dumb AP à l'IP `.2` sur chaque VLAN pour une configuration cohérente (exemple : `192.168.100.2`).
|
||||
:::
|
||||
|
||||
Répétez cette configuration pour chaque VLAN à étendre à travers le tunnel.
|
||||
|
||||
### Configuration sur le Dumb AP
|
||||
|
||||
Sur le second routeur (Dumb AP), les interfaces VLAN doivent être configurées en **DHCP client** pour récupérer automatiquement une IP sur chaque VLAN.
|
||||
|
||||
1. **Network → Interfaces → Add new interface**
|
||||
2. Configurez l'interface :
|
||||
- **Name** : `vlan100` (ou nom descriptif)
|
||||
- **Protocol** : DHCP client
|
||||
- **Device** : `@gretap-gr.100` (le port GREtap VLAN)
|
||||
|
||||
Le Dumb AP récupérera automatiquement une adresse IP du serveur DHCP du routeur principal sur ce VLAN.
|
||||
|
||||
### Exemple de configuration multi-VLAN
|
||||
|
||||
**Configuration typique** :
|
||||
- VLAN 10 (Management) → `@gretap-gr.10`
|
||||
- VLAN 100 (Homelab) → `@gretap-gr.100`
|
||||
- VLAN 200 (IoT) → `@gretap-gr.200`
|
||||
|
||||
Chaque VLAN traverse le tunnel GREtap de manière transparente et isolée.
|
||||
|
||||
## Vérification et tests
|
||||
|
||||
### Tests de connectivité
|
||||
|
||||
Depuis le Dumb AP, testez la connectivité sur chaque VLAN :
|
||||
|
||||
```bash
|
||||
# Ping vers la passerelle du VLAN 100
|
||||
ping -I vlan100 192.168.100.1
|
||||
|
||||
# Vérifier l'obtention d'une IP via DHCP
|
||||
ip addr show dev gretap-gr.100
|
||||
```
|
||||
|
||||
Depuis le routeur principal, vérifiez que le Dumb AP apparaît dans les baux DHCP :
|
||||
|
||||
- **Network → Interfaces → LAB → DHCP Server → Active DHCP Leases**
|
||||
|
||||
## Conclusion
|
||||
|
||||
Avec GREtap, vous pouvez étendre efficacement vos VLANs à travers un backhaul WiFi mesh entre deux routeurs OpenWRT. Cette solution offre un bon compromis entre simplicité, performance et fonctionnalité pour des topologies point-à-point.
|
||||
|
||||
Pour des réseaux mesh plus complexes avec 3 nœuds ou plus, considérez l'utilisation de BATMAN-adv qui offre des fonctionnalités de routage mesh plus avancées.
|
||||
16
docs/openwrt/index.md
Normal file
16
docs/openwrt/index.md
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
---
|
||||
sidebar_position: 1
|
||||
title: OpenWRT
|
||||
---
|
||||
|
||||
# OpenWRT
|
||||
|
||||
Le projet OpenWrt est un système d'exploitation basé sur Linux destiné aux matériels embarqués (routeurs principalement). Au lieu d'être un système d'exploitation figé et verrouillé, OpenWrt offre un système d'exploitation totalement modifiable grâce à un gestionnaire de paquets. Ceci vous permet de vous libérer des applications et de la configuration installées par le fabricant, afin de personnaliser votre appareil, grâce à l'ajout et l'utilisation de paquets apportant de nouvelles fonctions.
|
||||
|
||||
Pour les développeurs, OpenWrt est l'environnement idéal pour construire une application sans avoir à construire tout un firmware autour. Pour les utilisateurs, OpenWrt permet une totale personnalisation, ainsi que la possibilité d'utiliser l'appareil à des fins qu'on n'avait jamais envisagées.
|
||||
|
||||
## Ressources
|
||||
|
||||
- [Site officiel OpenWRT](https://openwrt.org/fr/start)
|
||||
- [Documentation OpenWRT](https://openwrt.org/fr/docs/start)
|
||||
- [Wiki OpenWRT](https://openwrt.org/fr/start)
|
||||
Loading…
Add table
Add a link
Reference in a new issue