Alliance-Boreale/alliance-boreale

Fork 0

Dan Allaire e2d5175975

CI / yaml-lint (push) Waiting to run

Details

CI / ssot-export (push) Waiting to run

Details

CI / tests (push) Waiting to run

Details

CI / docs (push) Waiting to run

Details

restructuration de la documentation

2025-10-24 10:50:25 -04:00

29 KiB

Raw Blame History

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

Template: Fiche Partenaire

À créer pour chaque nouveau membre de l'Alliance

# 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

# 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 (master: 10.0.2.10)
nuagelibre.ca (master: 10.1.2.10)
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	MASTER	Tous les membres

Configuration :

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

# 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 :

# Docker Compose
docker-compose -f forge/docker-compose.yml up -d

# URL : forge.partner-example.com
# IP : 10.XXX.10.10

Configurer miroirs automatiques :

# 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 :

# 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 :

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

# 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

# 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 (Daniel)
Nuage Libre : support@nuagelibre.ca (Mathieu)
Autres membres : voir annuaire dans members.yaml

Canal de communication

Matrix : #alliance-boreale:matrix.org
Forum : discourse.alliance-boreale.ca (distribué)
Git : Issues sur forge.alliance-boreale.ca

Documentation

Wiki : docs.alliance-boreale.ca (miroirs multiples)
Forge : 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"

```
 
```
```
 
```

Réplication DNS (réciprocité)

```
 
```
```
 
```
```
 
```
```
 
```

Tests de connectivité

```
 
```
```
 
```
```
 
```
```
 
```
```
 
```

Monitoring

```
 
```
```
 
```
```
 
```
```
 
```

Phase 5 : Production (Jour 8-10)

DNS Publics

```
 
```
```
 
```
```
 
```
```
 
```
```
 
```

Premiers tenants

```
 
```
```
 
```
```
 
```
```
 
```
```
 
```

Documentation

```
 
```
```
 
```
```
 
```
```
 
```
```
 
```

Phase 6 : Validation Finale (Jour 11+)

Tests de résilience

```
 
```
- Routage bascule automatiquement ? ✓
- Services distribués restent accessibles ? ✓
- DNS fonctionne toujours ? ✓
```
 
```
- Pairs continuent sans nous ? ✓
- Services distribués accessibles via pairs ? ✓
- Récupération automatique au redémarrage ? ✓

Tests de charge

```
 
```
```
 
```
```
 
```
```
 
```
```
 
```

Sécurité

```
 
```
```
 
```
```
 
```
```
 
```
```
 
```

Go-Live

```
 
```
```
 
```
```
 
```
```
 
```
```
 
```

Période probatoire (3 mois)

Monitoring intensif

```
 
```
```
 
```
```
 
```
```
 
```
```
 
```

Validation par les pairs

```
 
```
```
 
```
```
 
```
```
 
```

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

# 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`

# 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

# 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

# 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 :

# 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

#!/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

# 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)

# 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

# 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

# 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 :

Chezlepro (Montréal, proximité)
Nuage Libre (Québec, backup)
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 :

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 :

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

29 KiB Raw Blame History Unescape Escape

Templates de Documentation pour Nouveaux Partenaires

Alliance Boréale - Architecture Décentralisée

Table des matières

Template: Fiche Partenaire

Template: Configuration Réseau

Vos zones primaires

Routes statiques à configurer

Services distribués à déployer

1. Forge Boréale (miroir Git)

2. Monitoring (Icinga local)

3. Documentation (miroir)

Firewall - Règles minimales

Autoriser

Bloquer par défaut

Contacts et support

Support technique Alliance

Canal de communication

Documentation

Autonomie et responsabilités

Vous êtes autonome

Vous contribuez au collectif

En cas de problème

Réplication DNS (réciprocité)

Tests de connectivité

Monitoring

Phase 5 : Production (Jour 8-10)

DNS Publics

Premiers tenants

Documentation

Phase 6 : Validation Finale (Jour 11+)

Tests de résilience

Tests de charge

Sécurité

Go-Live

Période probatoire (3 mois)

Monitoring intensif

Validation par les pairs

Rôles et responsabilités

Timeline estimé

Étape 2 : Négocier avec le pair

Étape 3 : Enregistrer dans Git

Configuration WireGuard

Fichier type : /etc/wireguard/wg-pairname.conf

Démarrage

Routage multi-tunnels

Table de routage avec plusieurs pairs

Routage transitif (optionnel)

Monitoring des tunnels

Script de vérification

Intégration Icinga

Troubleshooting

Tunnel ne se connecte pas

Handshake expire (> 3 minutes)

Routage ne fonctionne pas

Sécurité

Bonnes pratiques

Exemples complets

Scénario : 3 tunnels (topologie sélective)

Conclusion

29 KiB

Raw Blame History

Fichier type : `/etc/wireguard/wg-pairname.conf`