alliance-boreale/docs/vieustoq/2025-10-11 - L'Alliance Boréale - Partenariats.md

1259 lines
29 KiB
Markdown
Raw Normal View History

2025-10-19 09:19:08 -04:00
# Templates de Documentation pour Nouveaux Partenaires
## Alliance Boréale - Architecture Décentralisée
**Version:** 2.0
**Date:** Octobre 2025
**Mise à jour majeure:** Cohérence avec décentralisation
---
## Table des matières
1. [Template: Fiche Partenaire](#template-fiche-partenaire)
2. [Template: Configuration Réseau](#template-configuration-r%C3%A9seau)
3. [Template: Checklist Onboarding](#template-checklist-onboarding)
4. [Template: Procédures Opérationnelles](#template-proc%C3%A9dures-op%C3%A9rationnelles)
5. [Template: Configuration VPN Mesh](#template-configuration-vpn-mesh)
6. [Template: Accord d'Alliance](#template-accord-dalliance)
---
## Template: Fiche Partenaire
**À créer pour chaque nouveau membre de l'Alliance**
```yaml
# config/partners/partner-example.yml
partner:
# Identification
id: "partner-example"
name: "Partner Example Inc."
shortname: "PE"
# Contact
contact:
technical:
name: "John Doe"
email: "tech@partner-example.com"
phone: "+1-555-0100"
pgp_key: "0xABCDEF123456"
administrative:
name: "Jane Smith"
email: "admin@partner-example.com"
phone: "+1-555-0101"
billing:
name: "Finance Dept"
email: "billing@partner-example.com"
# Réseau
network:
ip_block: "10.XXX.0.0/16" # Alloué via script décentralisé
segments:
management: "10.XXX.0.0/24"
platform: "10.XXX.1.0/24"
public_dns: "10.XXX.2.0/24"
tenant_infra: "10.XXX.10.0/23"
reserved: "10.XXX.20.0/22"
expansion: "10.XXX.128.0/17"
gateway: "10.XXX.0.1"
dns:
primary: "10.XXX.2.10"
secondary: "10.XXX.2.11"
public_nameservers:
- name: "ns1.partner-example.com"
ipv4: "203.0.113.10"
ipv6: "2001:db8::10"
- name: "ns2.partner-example.com"
ipv4: "203.0.113.11"
ipv6: "2001:db8::11"
# VPN Tunnels (topologie libre - peer-to-peer)
vpn:
topology: "selective" # complete, regional, selective
wireguard:
public_key: "base64_encoded_public_key_here"
endpoint: "vpn.partner-example.com:51820"
# Connexions choisies par le membre
peers:
- peer: "chezlepro"
network: "10.200.X.X/30"
local_ip: "10.200.X.X"
remote_ip: "10.200.X.X"
status: "active"
reason: "Proximité géographique (Montréal)"
- peer: "nuagelibre"
network: "10.200.X.X/30"
local_ip: "10.200.X.X"
remote_ip: "10.200.X.X"
status: "active"
reason: "Partenaire technologique"
- peer: "partner-quebec"
network: "10.200.X.X/30"
local_ip: "10.200.X.X"
remote_ip: "10.200.X.X"
status: "active"
reason: "Backup géographique (Québec)"
# Infrastructure
infrastructure:
location:
datacenter: "DC-Example-1"
city: "Montreal"
region: "Montréal"
country: "Canada"
coordinates:
lat: 45.5017
lon: -73.5673
connectivity:
primary_isp: "Bell Canada"
bandwidth_primary: "10Gbps"
backup_isp: "Videotron"
bandwidth_backup: "1Gbps"
hardware:
hypervisor: "Proxmox VE 8.x"
nodes: 3
total_cpu_cores: 128
total_ram_gb: 512
total_storage_tb: 50
# Services distribués hébergés
distributed_services:
forge:
enabled: true
url: "forge.partner-example.com"
ip: "10.XXX.10.10"
mirrors:
- "forge.chezlepro.ca"
- "forge.nuagelibre.ca"
monitoring:
enabled: true
icinga_ip: "10.XXX.0.10"
monitors:
- "chezlepro"
- "nuagelibre"
- "partner-quebec"
dns_secondary:
enabled: true
zones_hosted: 150
axfr_sources:
- "10.200.X.X" # chezlepro via tunnel
- "10.200.X.X" # nuagelibre via tunnel
backups:
enabled: true
backup_to:
- peer: "nuagelibre"
method: "borg"
frequency: "daily"
- peer: "partner-quebec"
method: "rsync"
frequency: "weekly"
# Capacité
capacity:
tenants_current: 0
tenants_max: 200
zones_current: 0
zones_max: 5000
vms_current: 0
vms_max: 500
# Status
status:
operational_status: "active"
joined_date: "2025-10-15"
last_health_check: "2025-10-15T10:30:00Z"
uptime_percent: 99.95
# Allocation IP (géré par qui)
ip_allocation:
allocated_by: "chezlepro" # Membre qui a alloué depuis SA plage
allocation_date: "2025-10-15"
delegated_range: null # null si pas fondateur, sinon {start: X, end: Y}
# Compliance
compliance:
gdpr_compliant: true
soc2_certified: false
iso27001_certified: false
backup_retention_days: 90
data_residency: "Canada"
# Notes
notes: |
Partner Example rejoint l'Alliance Boréale le 15 octobre 2025.
Spécialisé dans l'hébergement pour institutions éducatives.
Topologie VPN : connexions sélectives (3 pairs proches).
```
---
## Template: Configuration Réseau
**Document à fournir au nouveau membre**
```markdown
# Configuration Réseau - Partner Example
## Alliance Boréale - Architecture Décentralisée
## Informations d'allocation
**Bloc IP assigné**: `10.XXX.0.0/16`
**Date d'allocation**: 2025-10-15
**Alloué par**: Chezlepro (depuis sa plage déléguée)
**Partenaire**: Partner Example Inc.
---
## Segmentation de votre réseau
### Vue d'ensemble
| Segment | CIDR | Hôtes | Usage |
|----------------------|-------------------|-------|------------------------------------|
| Management | 10.XXX.0.0/24 | 254 | Infrastructure, monitoring, admin |
| Platform Services | 10.XXX.1.0/24 | 254 | API, DB, DNS autoritaire |
| Public DNS | 10.XXX.2.0/24 | 254 | Serveurs NS publics |
| Tenant Infrastructure| 10.XXX.10.0/23 | 512 | VMs et services de vos tenants |
| Reserved | 10.XXX.20.0/22 | 1,024 | Réservé pour usage futur |
| Expansion | 10.XXX.128.0/17 | 32,766| Expansion (50% du bloc) |
---
## Topologie VPN : Votre choix
### Principe de l'Alliance Boréale
**Il n'y a pas de hub central obligatoire.**
Vous choisissez librement :
- Avec quels membres vous connecter
- Combien de connexions établir
- Votre stratégie de résilience
### Recommandations
**Minimum conseillé** : 3 connexions VPN vers différents membres
**Critères de choix** :
- **Proximité géographique** (latence < 50ms)
- **Répartition géographique** (résilience)
- **Partenaires technologiques** (collaboration fréquente)
- **Backup mutuel** (échange de sauvegardes)
### Patterns suggérés
#### Option A : Maillage complet (3-10 membres)
```
Connectez-vous à TOUS les autres membres → Latence minimale → Résilience maximale → Simple
```
#### Option B : Maillage régional (votre région)
```
Connectez-vous à tous les membres de votre région
- 2-3 connexions longue distance → Bon compromis latence/résilience
```
#### Option C : Sélectif (vos besoins)
```
Choisissez 3-5 pairs stratégiques → Faible overhead → Adapté à vos besoins spécifiques
```
---
## Tunnels VPN à établir
### Exemple : 3 connexions recommandées
#### Tunnel 1 : Vers Chezlepro (Montréal)
```
Raison : Proximité géographique, membre fondateur Réseau tunnel : 10.200.X.X/30 Votre IP : 10.200.X.X IP Chezlepro : 10.200.X.X Port : 51820
```
#### Tunnel 2 : Vers Nuage Libre (Québec)
```
Raison : Répartition géographique, backup mutuel Réseau tunnel : 10.200.Y.Y/30 Votre IP : 10.200.Y.Y IP Nuage Libre : 10.200.Y.Y Port : 51820
```
#### Tunnel 3 : Vers Partner Saguenay (Saguenay)
```
Raison : Résilience géographique Nord Réseau tunnel : 10.200.Z.Z/30 Votre IP : 10.200.Z.Z IP Partner Saguenay : 10.200.Z.Z Port : 51820
````
### Allocation des blocs /30
**Processus décentralisé** :
1. Contactez le pair avec qui vous voulez vous connecter
2. Ensemble, choisissez un bloc /30 libre dans 10.200.0.0/16
3. Vérifiez dans `tunnels-registry.yaml` (Git) qu'il est disponible
4. Ajoutez votre allocation au fichier
5. Commit + merge request
6. Configurez vos tunnels WireGuard
---
## Configuration DNS
### Zones à héberger en secondaire
Vous hébergez les zones des autres membres (réciprocité) :
**Processus automatique** :
```bash
# PowerDNS configuré pour recevoir NOTIFY
# et faire AXFR automatiquement
# /etc/powerdns/pdns.conf
slave=yes
allow-notify-from=10.200.0.0/16 # Tous les tunnels VPN
````
**Zones actuelles de l'Alliance** (exemple) :
- [chezlepro.ca](http://chezlepro.ca) (master: 10.0.2.10)
- [nuagelibre.ca](http://nuagelibre.ca) (master: 10.1.2.10)
- [partner-quebec.qc.ca](http://partner-quebec.qc.ca) (master: 10.2.2.10)
- ... (toutes les zones des membres)
### Vos zones primaires
Les zones suivantes seront hébergées en secondaire par les autres :
| Zone | Type | Réplication |
|---------------------|--------|------------------|
| [partner-example.com](http://partner-example.com) | MASTER | Tous les membres |
**Configuration** :
```sql
-- Dans votre PostgreSQL
INSERT INTO domains (name, type) VALUES ('partner-example.com', 'MASTER');
-- Configurer NOTIFY vers tous vos pairs
-- (via tunnels VPN)
```
---
## Routes statiques à configurer
```bash
# Vers vos pairs directs
ip route add 10.0.0.0/16 via 10.200.X.X dev wg-chezlepro
ip route add 10.1.0.0/16 via 10.200.Y.Y dev wg-nuagelibre
ip route add 10.2.0.0/16 via 10.200.Z.Z dev wg-saguenay
# Via vos pairs, vous pouvez atteindre les autres membres
# (routage transitif)
```
---
## Services distribués à déployer
### 1. Forge Boréale (miroir Git)
**Déployer votre instance Forgejo** :
```bash
# Docker Compose
docker-compose -f forge/docker-compose.yml up -d
# URL : forge.partner-example.com
# IP : 10.XXX.10.10
```
**Configurer miroirs automatiques** :
```bash
# Hook post-receive pour synchroniser vers autres miroirs
# /data/git/hooks/post-receive
git push --mirror git@forge.chezlepro.ca:projet.git
git push --mirror git@forge.nuagelibre.ca:projet.git
```
### 2. Monitoring (Icinga local)
**Déployer votre Icinga** :
```bash
# Monitorer tous les autres membres
icinga2 object Host "chezlepro" {
address = "10.200.X.X" # Via tunnel
check_command = "hostalive"
}
icinga2 object Host "nuagelibre" {
address = "10.200.Y.Y"
check_command = "hostalive"
}
```
**Fédération** : exportez vos métriques vers Prometheus
### 3. Documentation (miroir)
**Cloner le repo docs** :
```bash
git clone https://forge.alliance-boreale.ca/alliance/docs.git
cd docs
mkdocs build
```
**Héberger localement** :
```
docs.partner-example.com → 10.XXX.10.20
```
---
## Firewall - Règles minimales
### Autoriser
```bash
# DNS AXFR/NOTIFY depuis les tunnels
iptables -A INPUT -s 10.200.0.0/16 -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -s 10.200.0.0/16 -p udp --dport 53 -j ACCEPT
# ICMP pour diagnostics
iptables -A INPUT -s 10.200.0.0/16 -p icmp -j ACCEPT
# WireGuard
iptables -A INPUT -p udp --dport 51820 -j ACCEPT
# Monitoring (NRPE, SNMP si utilisé)
iptables -A INPUT -s 10.200.0.0/16 -p tcp --dport 5666 -j ACCEPT
```
### Bloquer par défaut
```bash
# Tout le reste venant d'autres blocs membres
iptables -A INPUT -s 10.0.0.0/8 -j DROP
```
---
## Contacts et support
### Support technique Alliance
**Pas de support central unique.**
Contactez n'importe quel membre pour assistance :
- **Chezlepro** : [support@chezlepro.ca](mailto:support@chezlepro.ca) (Daniel)
- **Nuage Libre** : [support@nuagelibre.ca](mailto:support@nuagelibre.ca) (Mathieu)
- **Autres membres** : voir annuaire dans `members.yaml`
### Canal de communication
- **Matrix** : #alliance-boreale:[matrix.org](http://matrix.org)
- **Forum** : [discourse.alliance-boreale.ca](http://discourse.alliance-boreale.ca) (distribué)
- **Git** : Issues sur [forge.alliance-boreale.ca](http://forge.alliance-boreale.ca)
### Documentation
- **Wiki** : [docs.alliance-boreale.ca](http://docs.alliance-boreale.ca) (miroirs multiples)
- **Forge** : [forge.alliance-boreale.ca](http://forge.alliance-boreale.ca) (miroirs multiples)
- **Runbooks** : `docs/operations/` dans Git
---
## Autonomie et responsabilités
### Vous êtes autonome
- Gérez votre infrastructure comme vous l'entendez
- Choisissez vos connexions VPN
- Hébergez vos services à votre façon
- Pas de dépendance à un membre central
### Vous contribuez au collectif
- Hébergez les zones DNS des autres (secondaire)
- Déployez les services distribués (Forge, monitoring)
- Participez aux décisions (1 membre = 1 voix)
- Partagez votre savoir (documentation)
### En cas de problème
**Aucun membre n'est indispensable.**
Si un membre tombe (même Chezlepro) :
- Les autres continuent de fonctionner
- Les services distribués restent accessibles
- Vous pouvez toujours allouer des IPs (via un autre membre)
- Le réseau reste opérationnel
**C'est ça, la résilience distribuée.**
---
**Bienvenue dans l'Alliance Boréale ! 🌲**
````
---
## Template: Checklist Onboarding
**Checklist mise à jour avec architecture décentralisée**
```markdown
# Checklist Onboarding Nouveau Membre
## Alliance Boréale - Architecture Décentralisée
**Membre**: Partner Example
**ID**: partner-example
**Bloc IP**: 10.XXX.0.0/16
**Date début**: 2025-10-15
**Responsable onboarding**: Chezlepro (Daniel)
---
## Phase 1 : Préparation (Jour 0)
- [ ] Fiche membre créée (`partners/partner-example.yml`)
- [ ] Bloc IP /16 alloué (via script décentralisé)
- [ ] Membre allocateur : ____________
- [ ] Plage utilisée : 10.X-10.Y
- [ ] Commit dans `ip-allocations.yaml`
- [ ] Merge request validée
- [ ] Tunnels VPN planifiés (minimum 3 pairs)
- [ ] Pair 1 : ____________
- [ ] Pair 2 : ____________
- [ ] Pair 3 : ____________
- [ ] Documentation réseau générée et envoyée
- [ ] Accès Forge (Git) fourni
- [ ] Accès Matrix fourni
---
## Phase 2 : Configuration Infrastructure (Jours 1-3)
### Proxmox SDN
- [ ] VNet créée : `tenant-partner-example`
- [ ] Subnet configuré : 10.XXX.0.0/16
- [ ] Gateway : 10.XXX.0.1
- [ ] VLAN Tag assigné : XXX
- [ ] Firewall rules appliquées (isolation)
- [ ] SDN appliqué : `pvesh set /cluster/sdn`
### WireGuard VPN (peer-to-peer)
#### Tunnel 1
- [ ] Pair choisi : ____________
- [ ] Bloc /30 alloué : 10.200.X.X/30
- [ ] Clés échangées
- [ ] Configuration créée : `/etc/wireguard/wg-peer1.conf`
- [ ] Interface démarrée : `wg-quick up wg-peer1`
- [ ] Test ping : `ping 10.200.X.X`
- [ ] Routes configurées
#### Tunnel 2
- [ ] Pair choisi : ____________
- [ ] Bloc /30 alloué : 10.200.Y.Y/30
- [ ] Configuration + test
#### Tunnel 3
- [ ] Pair choisi : ____________
- [ ] Bloc /30 alloué : 10.200.Z.Z/30
- [ ] Configuration + test
### DNS Configuration
- [ ] PostgreSQL déployé (primary + standby)
- [ ] PowerDNS Authoritative installé
- [ ] Backend PostgreSQL configuré
- [ ] Zone primaire créée : `partner-example.com`
- [ ] SOA record configuré
- [ ] NS records ajoutés (local + pairs)
- [ ] Allow-AXFR configuré pour IPs tunnels
- [ ] Also-Notify configuré vers pairs
- [ ] Test AXFR local
### Platform API
- [ ] FastAPI déployé
- [ ] Admin API accessible
- [ ] Tenant API accessible
- [ ] PostgreSQL connecté
- [ ] JWT configuré
- [ ] Comptes admin créés
- [ ] Dashboard web déployé
- [ ] Health checks OK
---
## Phase 3 : Services Distribués (Jours 4-5)
### Forge Boréale (miroir Git)
- [ ] Forgejo déployé : `forge.partner-example.com`
- [ ] Miroirs configurés vers autres membres
- [ ] Hooks post-receive testés
- [ ] Synchronisation bidirectionnelle OK
- [ ] Ajouté au DNS round-robin
### Monitoring (Icinga fédéré)
- [ ] Icinga2 installé : `10.XXX.0.10`
- [ ] Checks configurés vers tous les pairs
- [ ] Export Prometheus activé
- [ ] Fédération avec autres Icinga testée
- [ ] Alertes configurées
### Documentation (miroir)
- [ ] Repo docs cloné
- [ ] MkDocs configuré
- [ ] Site généré : `docs.partner-example.com`
- [ ] Webhook Git configuré (rebuild auto)
### Backups croisés
- [ ] Peer backup 1 configuré : ____________
- [ ] Peer backup 2 configuré : ____________
- [ ] Borg / rsync testé
- [ ] Rotation configurée
---
## Phase 4 : Intégration Alliance (Jours 6-7)
### Enregistrement décentralisé
- [ ] Ajouté à `members.yaml` (Git)
```yaml
- id: partner-example
name: "Partner Example Inc."
ip_block: "10.XXX.0.0/16"
joined: "2025-10-15"
status: "probatoire"
````
- \[ \] Merge request validée par les pairs
- \[ \] API fédération testée (si applicable)
### Réplication DNS (réciprocité)
- \[ \] Zones des autres membres reçues en SLAVE
- \[ \] AXFR testés depuis tous les pairs
- \[ \] NOTIFY reçus et traités
- \[ \] Serial numbers synchronisés
### Tests de connectivité
- \[ \] Ping vers tous les pairs directs
- \[ \] Ping vers réseaux des pairs
- \[ \] DNS query via tunnels
- \[ \] AXFR via tunnels
- \[ \] Routage transitif testé (via pairs)
### Monitoring
- \[ \] Checks actifs sur tous les pairs
- \[ \] Métriques exportées
- \[ \] Alertes testées
- \[ \] Dashboards configurés
---
## Phase 5 : Production (Jour 8-10)
### DNS Publics
- \[ \] IPs publiques assignées
- \[ \] NAT configuré
- \[ \] Glue records au registrar
- \[ \] NS records propagés (24-48h)
- \[ \] Test résolution publique
### Premiers tenants
- \[ \] Tenant test créé
- \[ \] Zone test créée
- \[ \] Records ajoutés
- \[ \] Résolution testée (interne + publique)
- \[ \] AXFR vers pairs vérifié
### Documentation
- \[ \] Runbook opérationnel créé
- \[ \] Procédures d'urgence
- \[ \] Contacts mis à jour
- \[ \] Diagrammes réseau
- \[ \] Post-mortem onboarding
---
## Phase 6 : Validation Finale (Jour 11+)
### Tests de résilience
- \[ \] Simulation panne d'un pair
- Routage bascule automatiquement ? ✓
- Services distribués restent accessibles ? ✓
- DNS fonctionne toujours ? ✓
- \[ \] Simulation panne locale
- Pairs continuent sans nous ? ✓
- Services distribués accessibles via pairs ? ✓
- Récupération automatique au redémarrage ? ✓
### Tests de charge
- \[ \] 10+ zones créées
- \[ \] 100+ enregistrements DNS
- \[ \] Queries/sec mesurées
- \[ \] Latence AXFR mesurée
- \[ \] Performance acceptable
### Sécurité
- \[ \] Audit de sécurité
- \[ \] Firewall validé
- \[ \] ACLs DNS vérifiées
- \[ \] Certificats SSL/TLS valides
- \[ \] Scan vulnérabilités
### Go-Live
- \[ \] ✅ Statut changé : `probatoire``active`
- \[ \] ✅ Annonce aux autres membres (Matrix)
- \[ \] ✅ Ajouté au monitoring global
- \[ \] ✅ Page status mise à jour
- \[ \] ✅ 🎉 Célébration !
---
## Période probatoire (3 mois)
### Monitoring intensif
- \[ \] Uptime > 99.5% maintenu
- \[ \] Réponse aux incidents < 2h
- \[ \] Pas de violation sécurité majeure
- \[ \] Services distribués déployés et fonctionnels
- \[ \] Participation aux décisions collectives
### Validation par les pairs
- \[ \] Évaluation à 1 mois : \__________\_
- \[ \] Évaluation à 2 mois : \__________\_
- \[ \] Évaluation à 3 mois : \__________\_
- \[ \] **Vote final** : membre permanent ? ☐ Oui ☐ Non
---
## Rôles et responsabilités
| Tâche | Responsable | Support disponible |
|---------------------|----------------------------|------------------------|
| Allocation IP | Membre avec plage libre | Chezlepro, Nuage Libre |
| Config Proxmox SDN | Partner Example (autonome) | Docs + forum |
| Config WireGuard | Partner Example + pairs | Assistance pairs |
| Config DNS | Partner Example (autonome) | Runbooks |
| Services distribués | Partner Example (autonome) | Templates disponibles |
| Tests intégration | Partner Example + pairs | Collaboration |
| Validation finale | Tous les membres (vote) | \- |
---
## Timeline estimé
- **Jours 1-3** : Configuration infrastructure (80% autonome)
- **Jours 4-5** : Services distribués (70% autonome)
- **Jours 6-7** : Intégration Alliance (50/50 collaboration)
- **Jours 8-10** : Production (90% autonome)
- **Jour 11+** : Validation (tests avec pairs)
- **3 mois** : Période probatoire
**Total** : \~10-15 jours pour onboarding complet + 3 mois probatoire
---
**Note importante** : Dans l'Alliance Boréale, vous êtes autonome dès le départ.
Aucun membre n'est votre "supérieur" ou "gestionnaire".
Vous configurez, vous choisissez, vous contribuez.
Le collectif vous aide, mais vous êtes maître de votre infrastructure.
🌲 **Bienvenue dans l'écosystème distribué !**
````
---
## Template: Configuration VPN Mesh
**Nouveau document spécifique à l'architecture peer-to-peer**
```markdown
# Configuration VPN Mesh - Alliance Boréale
## Topologie Décentralisée WireGuard
**Version:** 1.0
**Date:** Octobre 2025
---
## Principe : Pas de hub central
Dans l'Alliance Boréale, **il n'y a pas de serveur VPN central**.
Chaque membre établit des tunnels **peer-to-peer** (point-à-point) avec les membres de son choix.
````
❌ Architecture hub-and-spoke (centralisée) Hub / |
A B C
✅ Architecture mesh (décentralisée) A ←→ B ↕ × ↕ C ←→ D
```
---
## Choisir votre topologie
### Option 1 : Maillage complet (3-10 membres)
**Vous connectez à** : TOUS les autres membres
**Avantages** :
- Latence minimale (connexions directes)
- Résilience maximale
- Routage simple
**Inconvénients** :
- Nombre de tunnels = N-1 (où N = total membres)
- Gestion configuration (mais scriptable)
**Exemple pour 5 membres** :
```
Vous : ├── Tunnel vers membre A ├── Tunnel vers membre B ├── Tunnel vers membre C └── Tunnel vers membre D
Total : 4 tunnels WireGuard
```
---
### Option 2 : Maillage régional (10-30 membres)
**Vous connectez à** :
- Tous les membres de votre région
- 2-3 membres d'autres régions (backbone)
**Exemple Montréal** :
```
Vous (Montréal) : ├── Tunnels locaux (Montréal) │ ├── Membre A (MTL) │ ├── Membre B (MTL) │ └── Membre C (MTL) │ └── Tunnels longue distance (backbone) ├── Membre Q1 (Québec) └── Membre S1 (Saguenay)
Total : 5 tunnels
```
**Avantages** :
- Latence locale faible
- Résilience géographique
- Passage à l'échelle
---
### Option 3 : Sélectif (30+ membres)
**Vous connectez à** : 3-5 pairs stratégiques
**Critères de sélection** :
- Proximité géographique (< 50ms latence)
- Partenaires technologiques (collaboration)
- Répartition géographique (résilience)
- Backups mutuels
**Exemple** :
```
Vous : ├── Pair 1 : Même ville (< 5ms) Pair 2 : Région voisine (< 50ms) Pair 3 : Autre région (backup géo)
Total : 3 tunnels (minimum recommandé)
````
---
## Allocation des blocs /30
### Processus décentralisé
**Pas de registre central**. Coordination via Git.
#### Étape 1 : Choisir un bloc libre
```bash
# Consulter tunnels-registry.yaml
cat tunnels-registry.yaml
# Trouver un bloc non utilisé dans 10.200.0.0/16
# Exemple : 10.200.5.0/30 est libre
````
#### Étape 2 : Négocier avec le pair
```
Vous → Email/Matrix au pair :
"Salut ! On établit un tunnel ?
Je propose 10.200.5.0/30
Toi = 10.200.5.1
Moi = 10.200.5.2
OK ?"
Pair → "OK, j'enregistre dans le registry"
```
#### Étape 3 : Enregistrer dans Git
```yaml
# tunnels-registry.yaml
tunnels:
- network: "10.200.5.0/30"
peer_a:
id: "nuagelibre"
ip: "10.200.5.1"
endpoint: "vpn.nuagelibre.ca:51820"
peer_b:
id: "partner-example"
ip: "10.200.5.2"
endpoint: "vpn.partner-example.com:51820"
established: "2025-10-15"
status: "active"
```
**Commit + merge request** → validation par les pairs
---
## Configuration WireGuard
### Fichier type : `/etc/wireguard/wg-pairname.conf`
```ini
# Tunnel Partner Example ↔ Nuage Libre
# Fichier : /etc/wireguard/wg-nuagelibre.conf
[Interface]
# Mon adresse dans le tunnel
Address = 10.200.5.2/30
# Ma clé privée
PrivateKey = <private_key_partner_example>
# Port d'écoute (51820 standard, ou autre)
ListenPort = 51820
# Post-up : ajouter route vers réseau du pair
PostUp = ip route add 10.1.0.0/16 via 10.200.5.1 dev %i
PostUp = iptables -A FORWARD -i %i -j ACCEPT
PostUp = iptables -A FORWARD -o %i -j ACCEPT
# Post-down : nettoyer
PostDown = ip route del 10.1.0.0/16 via 10.200.5.1 dev %i
PostDown = iptables -D FORWARD -i %i -j ACCEPT
PostDown = iptables -D FORWARD -o %i -j ACCEPT
[Peer]
# Nuage Libre
PublicKey = <public_key_nuagelibre>
# Son endpoint public
Endpoint = vpn.nuagelibre.ca:51820
# IPs autorisées depuis ce pair
AllowedIPs = 10.200.5.1/32, 10.1.0.0/16
# Keepalive (maintenir tunnel actif)
PersistentKeepalive = 25
```
### Démarrage
```bash
# Démarrer le tunnel
wg-quick up wg-nuagelibre
# Vérifier état
wg show wg-nuagelibre
# Activer au boot
systemctl enable wg-quick@wg-nuagelibre
# Test connectivité
ping -c 3 10.200.5.1 # IP pair dans tunnel
ping -c 3 10.1.0.1 # Gateway réseau pair
```
---
## Routage multi-tunnels
### Table de routage avec plusieurs pairs
```bash
# Routes locales
10.XXX.0.0/16 via 10.XXX.0.1 dev vmbr0
# Routes vers pairs directs
10.0.0.0/16 via 10.200.3.1 dev wg-chezlepro # Chezlepro
10.1.0.0/16 via 10.200.5.1 dev wg-nuagelibre # Nuage Libre
10.2.0.0/16 via 10.200.7.1 dev wg-quebec # Partner Québec
# Réseau d'interconnexion
10.200.0.0/16 dev wg*
```
### Routage transitif (optionnel)
Si vous voulez atteindre un membre C via un membre B :
```bash
# Vous ←→ B ←→ C
# Vous n'avez pas de tunnel direct vers C
# Ajouter route via B
ip route add 10.C.0.0/16 via 10.200.Y.Y dev wg-memberB
# Demander à B d'autoriser le forwarding
# (via iptables sur le serveur B)
```
**Note** : Nécessite coordination avec le membre B.
---
## Monitoring des tunnels
### Script de vérification
```bash
#!/bin/bash
# check-vpn-tunnels.sh
echo "=== VPN Tunnels Status ==="
for tunnel in /etc/wireguard/wg-*.conf; do
name=$(basename $tunnel .conf)
if wg show $name >/dev/null 2>&1; then
# Tunnel actif
handshake=$(wg show $name latest-handshakes | awk '{print $2}')
age=$(($(date +%s) - handshake))
if [ $age -lt 180 ]; then
echo "✓ $name : OK (handshake ${age}s ago)"
else
echo "⚠ $name : STALE (handshake ${age}s ago)"
fi
else
echo "✗ $name : DOWN"
fi
done
```
### Intégration Icinga
```
# /etc/icinga2/conf.d/vpn-tunnels.conf
object CheckCommand "check_wg_tunnel" {
command = [ "/usr/local/bin/check-vpn-tunnel.sh" ]
arguments = {
"-t" = "$tunnel_name$"
}
}
object Service "VPN Tunnel Nuage Libre" {
host_name = "localhost"
check_command = "check_wg_tunnel"
vars.tunnel_name = "wg-nuagelibre"
}
```
---
## Troubleshooting
### Tunnel ne se connecte pas
```bash
# 1. Vérifier configuration
wg showconf wg-nuagelibre
# 2. Vérifier firewall
iptables -L -n | grep 51820
# 3. Vérifier DNS endpoint
nslookup vpn.nuagelibre.ca
# 4. Test manuel avec IP statique
# Éditer .conf : remplacer hostname par IP
# 5. Logs
journalctl -u wg-quick@wg-nuagelibre -f
```
### Handshake expire (> 3 minutes)
```bash
# Forcer reconnexion
wg-quick down wg-nuagelibre
wg-quick up wg-nuagelibre
# Ou forcer handshake
wg set wg-nuagelibre peer <PUBLIC_KEY> endpoint vpn.nuagelibre.ca:51820
```
### Routage ne fonctionne pas
```bash
# Vérifier routes
ip route show | grep 10.1.0.0
# Vérifier forwarding activé
sysctl net.ipv4.ip_forward
# Si = 0 : activer avec sysctl -w net.ipv4.ip_forward=1
# Test traceroute
traceroute -n 10.1.0.1
```
---
## Sécurité
### Bonnes pratiques
```bash
# 1. Permissions strictes
chmod 600 /etc/wireguard/*.conf
chmod 700 /etc/wireguard
# 2. Clés privées sécurisées
# Ne JAMAIS partager la clé privée
# Ne JAMAIS committer dans Git
# 3. Firewall : autoriser uniquement port WireGuard
iptables -A INPUT -p udp --dport 51820 -j ACCEPT
iptables -A INPUT -p udp --dport 51821 -j ACCEPT # Si multi-tunnels
# 4. Rotation des clés (annuel)
wg genkey | tee new.private | wg pubkey > new.public
# Coordonner avec le pair pour mise à jour
```
---
## Exemples complets
### Scénario : 3 tunnels (topologie sélective)
**Vous = Partner Example**
**Tunnels** :
1. Chezlepro (Montréal, proximité)
2. Nuage Libre (Québec, backup)
3. Partner Saguenay (Saguenay, résilience Nord)
**Fichiers** :
```
/etc/wireguard/
├── wg-chezlepro.conf (10.200.3.0/30)
├── wg-nuagelibre.conf (10.200.5.0/30)
└── wg-saguenay.conf (10.200.7.0/30)
```
**Démarrage** :
```bash
wg-quick up wg-chezlepro
wg-quick up wg-nuagelibre
wg-quick up wg-saguenay
systemctl enable wg-quick@wg-chezlepro
systemctl enable wg-quick@wg-nuagelibre
systemctl enable wg-quick@wg-saguenay
```
**Table de routage** :
```
10.0.0.0/16 via 10.200.3.1 dev wg-chezlepro
10.1.0.0/16 via 10.200.5.1 dev wg-nuagelibre
10.2.0.0/16 via 10.200.7.1 dev wg-saguenay
```
**Test** :
```bash
ping 10.0.1.1 # Gateway Chezlepro → OK
ping 10.1.1.1 # Gateway Nuage Libre → OK
ping 10.2.1.1 # Gateway Saguenay → OK
# DNS via tunnels
dig @10.0.2.10 chezlepro.ca → OK
dig @10.1.2.10 nuagelibre.ca → OK
```
---
## Conclusion
**Vous êtes maître de votre topologie VPN.**
- Choisissez vos pairs
- Négociez vos tunnels
- Configurez librement
- Aucune dépendance à un hub central
**C'est ça, l'autonomie distribuée.** 🌲
---
**Fin du document - Configuration VPN Mesh v1.0**