Templates de Documentation pour Nouveaux Partenaires

Table des matières

Template: Fiche Partenaire
Template: Configuration Réseau
Template: Checklist Onboarding
Template: Procédures Opérationnelles
Template: Configuration WireGuard
Template: Accord de Fédération

Template: Fiche Partenaire

À créer pour chaque nouveau nœud de la fédération

                # 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"  # Remplacer XXX par le numéro assigné
    
    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"  # IP publique réelle
        ipv6: "2001:db8::10"   # Optionnel
      - name: "ns2.partner-example.com"
        ipv4: "203.0.113.11"
        ipv6: "2001:db8::11"
  
  # VPN Tunnels
  vpn:
    wireguard:
      public_key: "base64_encoded_public_key_here"
      endpoint: "vpn.partner-example.com:51820"
      
      tunnels:
        - peer: "chezlepro"
          network: "10.200.X.X/30"  # Assigné par coordination
          local_ip: "10.200.X.X"
          remote_ip: "10.200.X.X"
          status: "active"
        
        - peer: "partner-a"
          network: "10.200.X.X/30"
          local_ip: "10.200.X.X"
          remote_ip: "10.200.X.X"
          status: "active"
  
  # Infrastructure
  infrastructure:
    location:
      datacenter: "DC-Example-1"
      city: "Montreal"
      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
  
  # 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"  # active, maintenance, degraded, offline
    joined_date: "2025-10-15"
    last_health_check: "2025-10-15T10:30:00Z"
    uptime_percent: 99.95
  
  # Compliance
  compliance:
    gdpr_compliant: true
    soc2_certified: false
    iso27001_certified: false
    backup_retention_days: 90
    data_residency: "Canada"
  
  # Notes
  notes: |
    Partner Example joined the federation on October 15, 2025.
    Specializes in hosting for educational institutions.

Template: Configuration Réseau

Document à fournir au nouveau partenaire

                # Configuration Réseau - Partner Example

## Informations d'allocation

**Bloc IP assigné**: `10.XXX.0.0/16`  
**Date d'allocation**: 2025-10-15  
**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)            |

### Détail des segments

#### Management Network - 10.XXX.0.0/24

10.XXX.0.1 Gateway/Router 10.XXX.0.10 Icinga/Monitoring 10.XXX.0.20 Bastion/Jump host 10.XXX.0.30 Backup server 10.XXX.0.40 Ansible control 10.XXX.0.50-99 Réservé infrastructure 10.XXX.0.100+ Libre

                
#### Platform Services - 10.XXX.1.0/24

10.XXX.1.1 Gateway 10.XXX.1.10 PostgreSQL Primary 10.XXX.1.11 PostgreSQL Standby 10.XXX.1.20 API Platform (FastAPI) 10.XXX.1.30 Dashboard (Nginx + React) 10.XXX.1.40 PowerDNS Authoritative Primary 10.XXX.1.41 PowerDNS Authoritative Standby 10.XXX.1.50+ Réservé croissance plateforme

                
#### Public DNS - 10.XXX.2.0/24

10.XXX.2.1 Gateway 10.XXX.2.10 ns1.partner-example.com (NATé vers IP publique) 10.XXX.2.11 ns2.partner-example.com (NATé vers IP publique) 10.XXX.2.20 PowerDNS Recursor 1 10.XXX.2.21 PowerDNS Recursor 2 10.XXX.2.30+ Réservé

                
## Tunnels VPN assignés

### Tunnel vers Chezlepro

Réseau tunnel: 10.200.X.X/30 Votre IP: 10.200.X.X IP Chezlepro: 10.200.X.X Port: 51820 (WireGuard)

                
**Votre clé publique WireGuard**:

[À générer avec: wg genkey | tee private.key | wg pubkey > public.key]

                
**Clé publique Chezlepro**:

[Fournie par Chezlepro lors de l'onboarding]

                
### Autres tunnels

[Liste des autres partenaires avec lesquels établir des tunnels]

## Configuration DNS

### Zones à héberger en secondaire

Vous devez configurer les zones suivantes en SLAVE (secondaire):

| Zone              | Master (IP tunnel) | Type   |
|-------------------|--------------------|--------|
| chezlepro.ca      | 10.200.X.X         | SLAVE  |
| [autres zones]    | 10.200.X.X         | SLAVE  |

### Vos zones primaires

Les zones suivantes seront hébergées en secondaire par les autres partenaires:

| Zone                  | Type   | Réplication    |
|-----------------------|--------|----------------|
| partner-example.com   | MASTER | Tous les pairs |

## Routes statiques à configurer

```bash
# Vers Chezlepro
ip route add 10.100.0.0/16 via 10.200.X.X dev wg0

# Vers autres partenaires
ip route add 10.101.0.0/16 via 10.200.X.X dev wg1
ip route add 10.102.0.0/16 via 10.200.X.X dev wg2

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

Bloquer par défaut

                # Tout le reste venant d'autres blocs partenaires
iptables -A INPUT -s 10.100.0.0/13 -j DROP

Contacts techniques

Pour assistance:

Email: federation-support@chezlepro.ca
Slack: #federation-partners
Urgence: +1-XXX-XXX-XXXX

Documentation:

Wiki: https://wiki.chezlepro.ca/federation
API: https://api.federation.chezlepro.ca/docs

                
---

## Template: Checklist Onboarding

**Checklist à suivre lors de l'ajout d'un nouveau partenaire**

```markdown
# Checklist Onboarding Nouveau Partenaire

**Partenaire**: Partner Example  
**ID**: partner-example  
**Bloc IP**: 10.XXX.0.0/16  
**Date début**: 2025-10-15  
**Responsable**: [Nom]

## Phase 1: Préparation (Jour 0)

- [ ] Fiche partenaire créée (`partners/partner-example.yml`)
- [ ] Bloc IP /16 alloué (prochain disponible: 10.XXX.0.0/16)
- [ ] Réseaux de tunnels VPN alloués
- [ ] Documentation réseau générée et envoyée
- [ ] Accès au repo Git fourni
- [ ] Accès Slack/communication 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é sur cluster: `pvesh set /cluster/sdn`

### WireGuard VPN

- [ ] Clés WireGuard générées (privée + publique)
- [ ] Clé publique partagée avec Chezlepro
- [ ] Clé publique Chezlepro reçue
- [ ] Configuration tunnel Chezlepro créée (`/etc/wireguard/wg0.conf`)
- [ ] Interface WireGuard démarrée: `wg-quick up wg0`
- [ ] Test ping vers 10.200.X.X (IP Chezlepro dans tunnel)
- [ ] Routes statiques configurées vers 10.100.0.0/16
- [ ] Tunnels additionnels configurés (si applicable)

### 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: `dig @localhost partner-example.com AXFR`

### Platform API

- [ ] FastAPI déployé
- [ ] Admin API accessible: https://admin.partner-example.com
- [ ] Tenant API accessible: https://api.partner-example.com
- [ ] PostgreSQL connecté et migré
- [ ] Authentification JWT configurée
- [ ] Premiers comptes admin créés
- [ ] Dashboard web déployé
- [ ] Health checks fonctionnels

## Phase 3: Intégration Fédération (Jours 4-5)

### Enregistrement dans la fédération

- [ ] Enregistré dans base IPAM centrale
  ```sql
  INSERT INTO federation_peers (peer_name, api_endpoint, public_key, ...)
  VALUES ('partner-example', 'https://api.partner-example.com', '...', ...);

[ ] API fédération testée
[ ] Webhook notifications configurées

Réplication DNS

[ ] Zone chezlepro.ca ajoutée en SLAVE
[ ] AXFR reçu depuis Chezlepro (via tunnel)
[ ] Zone locale synchronisée
[ ] Serial numbers vérifiés
[ ] NOTIFY reçus et traités correctement

Tests de connectivité

[ ] Ping vers Chezlepro: ping 10.200.X.X
[ ] Ping vers réseau Chezlepro: ping 10.100.1.1
[ ] DNS query via tunnel: dig @10.200.X.X chezlepro.ca
[ ] AXFR via tunnel: dig @10.200.X.X chezlepro.ca AXFR
[ ] Test reverse: requête DNS depuis Chezlepro vers nous

Monitoring

[ ] Agent Icinga installé sur serveurs critiques
[ ] Checks configurés (DNS, API, DB, VPN)
[ ] Alertes configurées (email, Slack)
[ ] Dashboard Grafana configuré
[ ] Métriques exportées vers fédération (optionnel)

Phase 4: Production (Jour 6-7)

DNS Publics

[ ] IPs publiques assignées pour ns1/ns2
[ ] NAT configuré: IP publique → 10.XXX.2.10
[ ] Glue records créés au registrar
[ ] NS records partner-example.com pointent vers:
- [ ] ns1.partner-example.com
- [ ] ns2.partner-example.com
- [ ] ns1.chezlepro.ca (secondaire)
- [ ] [autres secondaires]
[ ] Propagation DNS vérifiée (24-48h)
[ ] Test résolution publique: dig @8.8.8.8 partner-example.com

Premiers tenants

[ ] Tenant test créé via API
[ ] Zone test créée
[ ] Records A/AAAA ajoutés
[ ] Résolution testée (interne)
[ ] Résolution testée (publique)
[ ] AXFR vers pairs fonctionne

Documentation

[ ] Runbook opérationnel créé
[ ] Procédures d'urgence documentées
[ ] Contacts mis à jour dans wiki
[ ] Diagrammes réseau ajoutés
[ ] Post-mortem onboarding rédigé (leçons apprises)

Phase 5: Validation Finale (Jour 8+)

Tests de charge

[ ] 10 zones créées
[ ] 100+ enregistrements DNS
[ ] Queries/sec mesurées
[ ] Latence AXFR mesurée
[ ] Performance acceptable

Résilience

[ ] Test failover PostgreSQL (primary → standby)
[ ] Test failover PowerDNS (primary → standby)
[ ] Test perte tunnel VPN (réétablissement auto)
[ ] Test panne serveur (HA Proxmox)
[ ] Backups testés (restauration)

Sécurité

[ ] Audit de sécurité effectué
[ ] Firewall rules validées
[ ] ACLs DNS vérifiées
[ ] Certificats SSL/TLS valides
[ ] Scan vulnérabilités passé

Go-Live

[ ] ✅ Partenaire marqué "active" dans fédération
[ ] ✅ Annonce aux autres partenaires
[ ] ✅ Ajouté au monitoring global
[ ] ✅ Page status publique mise à jour
[ ] ✅ 🎉 Célébration !

Rôles et responsabilités

Tâche	Responsable	Contact
Allocation IP	Chezlepro Admin	admin@chezlepro.ca
Config Proxmox SDN	Chezlepro Ops	ops@chezlepro.ca
Config WireGuard	Partner Ops	ops@partner-example.com
Config DNS	Partner Ops	ops@partner-example.com
Tests intégration	Les deux	-
Validation finale	Chezlepro Admin	admin@chezlepro.ca

Timeline estimé

Jours 1-3: Configuration infrastructure (70% effort Partner)
Jours 4-5: Intégration fédération (50/50)
Jours 6-7: Mise en production (80% Partner, 20% support Chezlepro)
Jour 8+: Validation et optimisation

Total: ~8-10 jours ouvrables pour onboarding complet

                
---

## Template: Procédures Opérationnelles

**Runbook pour opérations courantes**

```markdown
# Runbook Opérations - Partner Example

## Procédures de maintenance courantes

### 1. Redémarrage serveur DNS

**Contexte**: Maintenance planifiée ou problème nécessitant redémarrage

**Étapes**:

```bash
# 1. Notification aux pairs (au moins 2h à l'avance)
curl -X POST https://api.chezlepro.ca/federation/v1/maintenance \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "peer_id": "partner-example",
    "type": "planned",
    "service": "dns",
    "start": "2025-10-15T02:00:00Z",
    "duration_minutes": 30
  }'

# 2. Vérifier que secondaires sont à jour
dig @ns1.chezlepro.ca partner-example.com SOA

# 3. Passer en mode maintenance
systemctl stop pdns

# 4. Effectuer maintenance

# 5. Redémarrer
systemctl start pdns

# 6. Vérifier logs
journalctl -u pdns -f

# 7. Tester résolution
dig @localhost partner-example.com SOA

# 8. Notifier fin de maintenance
curl -X POST https://api.chezlepro.ca/federation/v1/maintenance/complete \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"maintenance_id": "xxx"}'

Rollback: Si problème, revenir à version précédente du config

SLA: Maximum 30 minutes downtime

2. Ajout d'une nouvelle zone

Contexte: Nouveau tenant demande hébergement d'une zone

Étapes:

                # 1. Via API
curl -X POST https://api.partner-example.com/api/v1/zones \
  -H "Authorization: Bearer $TENANT_TOKEN" \
  -d '{
    "zone": "example.com",
    "type": "MASTER",
    "tenant_id": "tenant-uuid"
  }'

# 2. Vérifier création
pdnsutil list-zone example.com

# 3. Ajouter NS records
pdnsutil add-record example.com @ NS ns1.partner-example.com
pdnsutil add-record example.com @ NS ns1.chezlepro.ca
pdnsutil add-record example.com @ NS ns1.partner-a.com

# 4. Incrémenter serial
pdnsutil increase-serial example.com

# 5. Notifier les secondaires
pdnsutil notify example.com

# 6. Vérifier AXFR chez pairs
dig @10.200.X.X example.com AXFR

Vérification: Zone accessible depuis Internet sous 5 minutes

3. Restauration depuis backup

Contexte: Perte de données, corruption, incident majeur

Étapes:

                # 1. STOP tous les services
systemctl stop pdns
systemctl stop postgresql

# 2. Identifier le backup à restaurer
ls -lh /backup/postgresql/
# Exemple: postgresql_2025-10-15_daily.sql.gz

# 3. Restaurer PostgreSQL
gunzip -c /backup/postgresql/postgresql_2025-10-15_daily.sql.gz | \
  psql -U postgres dnsplatform

# 4. Vérifier intégrité
psql -U postgres dnsplatform -c "SELECT COUNT(*) FROM domains;"

# 5. Redémarrer services
systemctl start postgresql
systemctl start pdns

# 6. Resynchroniser avec pairs
for zone in $(pdnsutil list-all-zones); do
  pdnsutil notify $zone
done

# 7. Vérifier serial numbers
psql -U postgres dnsplatform -c "SELECT name, notified_serial FROM domains LIMIT 10;"

RTO: 2 heures
RPO: 24 heures (backups quotidiens)

4. Résolution problème tunnel VPN

Contexte: Perte de connectivité avec un pair

Diagnostic:

                # 1. Vérifier statut WireGuard
wg show wg0

# Sortie attendue:
# interface: wg0
#   public key: xxxxx
#   private key: (hidden)
#   listening port: 51820
# peer: yyyyy
#   endpoint: chezlepro.ca:51820
#   allowed ips: 10.200.0.1/32, 10.100.0.0/16
#   latest handshake: 30 seconds ago    # ⚠️ doit être récent!
#   transfer: 1.5 GiB received, 800 MiB sent

# 2. Test ping dans tunnel
ping -c 3 10.200.0.1  # IP Chezlepro dans tunnel

# 3. Vérifier firewall local
iptables -L -n | grep 51820

# 4. Vérifier logs
journalctl -u wg-quick@wg0 -f

Solutions courantes:

                # A. Handshake expiré (> 3 minutes)
wg-quick down wg0
wg-quick up wg0

# B. Endpoint DNS ne résout pas
# Éditer /etc/wireguard/wg0.conf
# Remplacer hostname par IP statique temporairement

# C. Clé publique changée (réinitialisation peer)
# Contacter le pair pour obtenir nouvelle clé
wg set wg0 peer NEW_PUBLIC_KEY allowed-ips 10.200.0.1/32,10.100.0.0/16

# D. Problème firewall distant
# Contacter le pair via canal alternatif (email, Slack)

Escalation: Si non résolu en 30 min, contacter pair + Chezlepro support

5. Mise à jour plateforme

Contexte: Nouvelle version de l'API ou PowerDNS disponible

Avant de commencer:

[ ] Lire release notes
[ ] Tester en environnement staging
[ ] Planifier fenêtre de maintenance
[ ] Notifier les pairs
[ ] Backup complet

Étapes:

                # 1. Activer mode maintenance
touch /var/www/html/maintenance.html

# 2. Stopper services
systemctl stop dns-platform-api
systemctl stop pdns

# 3. Backup config actuelle
cp -r /opt/dns-platform /opt/dns-platform.backup-$(date +%Y%m%d)

# 4. Pull nouvelle version
cd /opt/dns-platform
git fetch origin
git checkout v2.1.0  # Version à déployer

# 5. Appliquer migrations DB
docker-compose run --rm api alembic upgrade head

# 6. Rebuild containers
docker-compose build
docker-compose up -d

# 7. Vérifier logs
docker-compose logs -f api

# 8. Tests de smoke
curl https://api.partner-example.com/health
dig @localhost partner-example.com SOA

# 9. Désactiver maintenance
rm /var/www/html/maintenance.html

# 10. Monitoring intensif pendant 24h

Rollback:

                cd /opt/dns-platform
git checkout v2.0.5  # Version précédente stable
docker-compose up -d --force-recreate
# Restaurer DB si migration problématique

Incidents et escalation

Niveaux de sévérité

Niveau	Description	Délai réponse	Escalation
P0	Service complètement down	15 min	Immédiate
P1	Service dégradé, impact majeur	1 heure	2 heures
P2	Impact mineur, workaround existe	4 heures	1 jour
P3	Amélioration, pas d'impact service	1 semaine	-

Contacts d'urgence

P0/P1 - Disponibles 24/7:

On-call: +1-XXX-XXX-XXXX (PagerDuty)
Slack: @oncall dans #incidents
Email: oncall@partner-example.com

P2/P3 - Heures ouvrables:

Email: support@partner-example.com
Slack: #support

Fédération:

Chezlepro support: +1-XXX-XXX-XXXX
Slack fédération: #federation-ops

Modèle de rapport d'incident

                # Incident Report - [Numéro incident]

**Date**: 2025-10-15  
**Sévérité**: P1  
**Status**: Résolu  
**Durée**: 2h 15min

## Résumé
[Description courte du problème]

## Impact
- Services affectés: PowerDNS Authoritative
- Tenants impactés: 15
- Zones non résolues: 450
- Queries perdues: ~50,000

## Timeline
- 14:00 - Alerte détectée: PowerDNS primary unresponsive
- 14:05 - Équipe on-call notifiée
- 14:15 - Diagnostic: corruption base PostgreSQL
- 14:30 - Décision: restauration depuis backup
- 15:45 - Backup restauré, services redémarrés
- 16:15 - Validation complète, incident clos

## Cause racine
[Explication technique détaillée]

## Résolution
[Actions prises pour résoudre]

## Actions correctives
- [ ] Court terme: [Actions immédiates]
- [ ] Moyen terme: [Améliorations process]
- [ ] Long terme: [Changements architecturaux]

## Leçons apprises
[Ce qu'on a appris, ce qu'on améliorera]

                
---

## Template: Configuration WireGuard

**Fichiers de configuration prêts à l'emploi**

```markdown
# Configuration WireGuard - Partner Example

## Génération des clés

```bash
# Sur le serveur Partner Example
cd /etc/wireguard
umask 077

# Générer paire de clés
wg genkey | tee partner-example.private | wg pubkey > partner-example.public

# Afficher clé publique (à partager avec pairs)
cat partner-example.public

Configuration tunnel vers Chezlepro

Fichier: /etc/wireguard/wg-chezlepro.conf

                [Interface]
# IP de Partner Example dans le tunnel
Address = 10.200.X.X/30
PrivateKey = <CONTENU_DE_partner-example.private>
ListenPort = 51820

# Post-up: ajouter routes vers réseau Chezlepro
PostUp = ip route add 10.100.0.0/16 via 10.200.X.Y dev %i
PostUp = iptables -A FORWARD -i %i -j ACCEPT
PostUp = iptables -A FORWARD -o %i -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Post-down: nettoyer
PostDown = ip route del 10.100.0.0/16 via 10.200.X.Y dev %i
PostDown = iptables -D FORWARD -i %i -j ACCEPT
PostDown = iptables -D FORWARD -o %i -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Chezlepro
PublicKey = <CLE_PUBLIQUE_CHEZLEPRO>
Endpoint = vpn.chezlepro.ca:51820
AllowedIPs = 10.200.X.Y/32, 10.100.0.0/16

# Keepalive toutes les 25 secondes
PersistentKeepalive = 25

Démarrage et activation

                # Démarrer le tunnel
wg-quick up wg-chezlepro

# Vérifier statut
wg show wg-chezlepro

# Activer au boot
systemctl enable wg-quick@wg-chezlepro

# Test connectivité
ping -c 3 10.200.X.Y  # IP Chezlepro dans tunnel
ping -c 3 10.100.1.1  # Gateway réseau Chezlepro

Configuration multi-tunnels

Si plusieurs tunnels vers différents pairs:

Structure recommandée:

                /etc/wireguard/
├── wg-chezlepro.conf     # Tunnel principal
├── wg-partner-a.conf     # Vers Partner A
├── wg-partner-b.conf     # Vers Partner B
└── keys/
    ├── partner-example.private
    └── partner-example.public

Activation de tous les tunnels:

                for tunnel in /etc/wireguard/wg-*.conf; do
  name=$(basename $tunnel .conf)
  wg-quick up $name
  systemctl enable wg-quick@$name
done

Troubleshooting

                # Logs WireGuard
journalctl -u wg-quick@wg-chezlepro -f

# Dump configuration active
wg showconf wg-chezlepro

# Tester avec verbose
wg-quick up wg-chezlepro 2>&1 | tee /tmp/wg-debug.log

# Vérifier handshake
wg show wg-chezlepro latest-handshakes
# Doit être < 3 minutes

# Forcer nouveau handshake
wg set wg-chezlepro peer <PEER_PUBLIC_KEY> endpoint vpn.chezlepro.ca:51820

Sécurité

                # Permissions strictes sur clés privées
chmod 600 /etc/wireguard/*.conf
chmod 600 /etc/wireguard/keys/*.private

# 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

# Bloquer accès direct aux clés
chmod 700 /etc/wireguard

                
---

## Template: Accord de Fédération

**Document légal/contractuel entre partenaires**

```markdown
# Accord de Fédération DNS
## Federation DNS Multi-Tenant

**Entre**:  
**Chezlepro Inc.** (ci-après "Chezlepro")  
123 Rue Example, Montréal, QC, Canada  

**Et**:  
**Partner Example Inc.** (ci-après "Partenaire")  
456 Avenue Test, Ville, Province/État, Pays  

**Date d'effet**: 2025-10-15

---

## Article 1 - Objet

Le présent accord définit les termes et conditions de participation du Partenaire à la fédération DNS multi-tenant opérée collaborativement entre les membres.

---

## Article 2 - Engagements du Partenaire

### 2.1 Infrastructure

Le Partenaire s'engage à :
- Maintenir une infrastructure conforme aux standards techniques (Annexe A)
- Assurer une disponibilité minimum de 99.5% (hors maintenance planifiée)
- Héberger les services DNS autoritaires pour ses propres zones
- Fournir des services DNS secondaires pour les zones des autres membres
- Maintenir au moins 2 serveurs NS publics géographiquement redondants

### 2.2 Sécurité

Le Partenaire s'engage à :
- Respecter les meilleures pratiques de sécurité (Annexe B)
- Maintenir ses systèmes à jour (patches de sécurité < 30 jours)
- Activer DNSSEC sur toutes les zones
- Utiliser TSIG/keys pour les transferts AXFR
- Chiffrer toutes les interconnexions (WireGuard, TLS)
- Notifier immédiatement toute violation de sécurité

### 2.3 Opérations

Le Partenaire s'engage à :
- Maintenir une équipe technique disponible 24/7 pour incidents P0/P1
- Participer aux appels de coordination mensuels
- Documenter ses procédures opérationnelles
- Effectuer des backups quotidiens (rétention 90 jours minimum)
- Notifier les maintenances planifiées 48h à l'avance

---

## Article 3 - Services réciproques

### 3.1 DNS Secondaire

Chaque membre s'engage à :
- Héberger les zones des autres membres en mode SLAVE (secondaire)
- Maintenir les zones secondaires synchronisées (AXFR automatique)
- Répondre aux requêtes DNS pour toutes les zones fédérées
- Assurer une latence < 50ms pour résolution DNS (p95)

### 3.2 Bande passante

- Pas de limite de bande passante entre membres pour trafic légitime
- Trafic DNS (AXFR/NOTIFY) prioritaire
- Throttling acceptable si abuse/DDoS détecté

---

## Article 4 - Allocation réseau

### 4.1 Bloc IP assigné

Le Partenaire se voit allouer le bloc:
- **IPv4**: 10.XXX.0.0/16 (65,534 IPs utilisables)
- **Interconnexions**: Voir matrice en Annexe C

### 4.2 Utilisation

- Le bloc est exclusif au Partenaire
- Aucun chevauchement avec d'autres membres
- Segmentation interne libre, structure recommandée fournie
- Pas de réallocation sans accord préalable

---

## Article 5 - Gouvernance

### 5.1 Décisions

- Décisions majeures: vote unanime requis
- Décisions opérationnelles: vote majoritaire (>50%)
- Chaque membre: 1 vote

### 5.2 Ajout nouveau membre

- Proposition par membre existant
- Évaluation technique (infra, sécurité)
- Vote unanimité requise
- Période probatoire: 3 mois

### 5.3 Exclusion d'un membre

Motifs d'exclusion:
- Violation répétée des engagements (3 incidents graves en 12 mois)
- Uptime < 95% sur 3 mois consécutifs
- Violation de sécurité majeure non corrigée sous 7 jours
- Cessation d'activité

Procédure:
- Vote à 75% des membres (excluant le membre concerné)
- Préavis de 30 jours
- Plan de migration des zones vers autres membres

---

## Article 6 - Responsabilités

### 6.1 Responsabilité individuelle

Chaque membre est responsable de :
- Ses propres zones DNS (contenu, exactitude)
- Ses tenants et clients
- Sa conformité légale (GDPR, lois locales)
- Ses coûts d'infrastructure

### 6.2 Limitation de responsabilité

- Aucun membre n'est responsable des actes des autres membres
- Responsabilité limitée aux services DNS fournis
- Exclusion: dommages indirects, perte de profits, etc.
- Assurance responsabilité civile recommandée: 5M$ minimum

---

## Article 7 - Données et confidentialité

### 7.1 Souveraineté des données

- Chaque membre conserve la propriété de ses données
- Pas de transfert de propriété par la fédération
- Données tenants = propriété du membre hébergeant

### 7.2 Confidentialité

- Informations opérationnelles partagées: non confidentielles
- Données clients/tenants: confidentielles, non partagées
- Métriques agrégées: partageables publiquement
- NDA entre membres pour infos sensibles (optionnel)

### 7.3 Conformité GDPR/Privacy

- Chaque membre responsable de sa conformité
- DPA (Data Processing Agreement) entre membre et ses tenants
- Pas de transfert de données hors juridiction sans consentement

---

## Article 8 - Résiliation

### 8.1 Résiliation volontaire

- Préavis: 90 jours minimum
- Plan de migration fourni
- Assistance technique pour transition
- Bloc IP retourné au pool

### 8.2 Résiliation pour cause

- Préavis: 30 jours si violation grave
- Immédiate si sécurité compromise
- Frais de migration à charge du membre sortant (si faute)

### 8.3 Obligations post-résiliation

- Cesser utilisation du bloc IP sous 30 jours
- Supprimer zones SLAVE des autres membres
- Retirer NS records de ses zones
- Supprimer tunnels VPN

---

## Article 9 - Aspects financiers

### 9.1 Modèle économique

- **Principe**: Réciprocité gratuite (mutual hosting)
- Chaque membre héberge gratuitement les autres
- Équilibre approximatif du nombre de zones attendu
- Si déséquilibre majeur (>3:1 ratio), renégociation possible

### 9.2 Coûts partagés (optionnel)

Si infrastructure commune future:
- Registrar pour domaine fédération
- Certificats SSL wildcard
- Monitoring centralisé
- Documentation/wiki

Répartition: parts égales ou prorata nombre zones

---

## Article 10 - Modifications

- Modifications par vote majoritaire (>50%)
- Modifications majeures: vote unanime
- Préavis: 30 jours avant application
- Version du présent accord: v1.0

---

## Article 11 - Résolution des litiges

### 11.1 Médiation

- Tentative de résolution amiable (30 jours)
- Médiation par tiers neutre si nécessaire

### 11.2 Arbitrage

- Si médiation échoue: arbitrage
- Lieu: Montréal, Québec, Canada (ou autre convenu)
- Langue: Français et/ou Anglais
- Décision arbitrale: finale et contraignante

### 11.3 Droit applicable

- Lois du Québec, Canada (ou juridiction convenue entre parties)
- Tribunaux de Montréal compétents (si arbitrage refuse)

---

## Signatures

**Pour Chezlepro Inc.**:

Nom: ____________________  
Titre: ____________________  
Date: ____________________  
Signature: ____________________

**Pour Partner Example Inc.**:

Nom: ____________________  
Titre: ____________________  
Date: ____________________  
Signature: ____________________

---

## Annexes

### Annexe A - Standards techniques

[Lien vers documentation technique détaillée]

- Proxmox VE 8.x ou équivalent
- PowerDNS 4.8+ ou BIND 9.18+
- PostgreSQL 15+ ou MariaDB 10.11+
- WireGuard pour VPN
- DNSSEC obligatoire
- IPv4 + IPv6 (recommandé)

### Annexe B - Standards de sécurité

[Lien vers security guidelines]

- Firewall actif (iptables/nftables)
- SSH: clés uniquement, pas de password
- Fail2ban ou équivalent
- Logs centralisés (syslog/journald)
- Backups chiffrés (AES-256)
- TLS 1.3 minimum pour HTTPS
- Rotation des secrets tous les 90 jours
- Audits de sécurité annuels

### Annexe C - Matrice d'interconnexion

| Partenaire       | Bloc IP         | Tunnel vers Chezlepro | Status  |
|------------------|-----------------|-----------------------|---------|
| Chezlepro        | 10.100.0.0/16   | -                     | Active  |
| Partner Example  | 10.XXX.0.0/16   | 10.200.X.X/30         | Active  |
| [Autres membres] | ...             | ...                   | ...     |

### Annexe D - SLA et métriques

**Availability SLA**: 99.5% mensuel (hors maintenance planifiée)

**Métriques clés**:
- DNS query response time: < 50ms (p95)
- AXFR transfer time: < 5 minutes pour zone 1000 records
- Incident response: < 15 minutes (P0)
- Recovery time objective (RTO): < 2 heures
- Recovery point objective (RPO): < 24 heures

**Maintenance Windows**:
- Fenêtre préférée: Mardi/Jeudi 02:00-06:00 UTC
- Notification: 48h minimum à l'avance
- Durée max: 4 heures

### Annexe E - Contacts

**Chezlepro**:
- Technique: ops@chezlepro.ca
- Admin: admin@chezlepro.ca
- Urgence: +1-XXX-XXX-XXXX

**Partner Example**:
- Technique: ops@partner-example.com
- Admin: admin@partner-example.com
- Urgence: +1-XXX-XXX-XXXX

**Canaux de communication**:
- Slack: workspace.slack.com #federation
- Email: federation@chezlepro.ca
- Status page: https://status.federation.chezlepro.ca

Template: Guide de Migration

Pour partenaires existants migrant vers la fédération

                # Guide de Migration vers la Fédération

## Pour qui ?

Ce guide s'adresse aux organisations qui :
- Ont déjà une infrastructure DNS existante
- Souhaitent rejoindre la fédération
- Veulent migrer progressivement sans interruption de service

## Prérequis

Avant de commencer, assurez-vous d'avoir :
- [ ] Infrastructure compatible (voir standards techniques)
- [ ] Bloc IP /16 alloué par la fédération
- [ ] Accès VPN configuré avec au moins un pair
- [ ] Backups complets de votre config actuelle
- [ ] Fenêtre de maintenance planifiée (4-8 heures recommandé)

## Stratégie de migration

### Option A : Big Bang (recommandé si < 50 zones)

**Timeline**: 1 journée

Migration complète en une seule fenêtre de maintenance.

**Avantages**:
- Simple et rapide
- Moins de complexité opérationnelle
- État final atteint immédiatement

**Inconvénients**:
- Fenêtre de maintenance plus longue
- Rollback plus complexe

### Option B : Progressive (recommandé si > 50 zones)

**Timeline**: 2-4 semaines

Migration zone par zone, en validant chaque étape.

**Avantages**:
- Risque réduit
- Rollback facile
- Apprentissage progressif

**Inconvénients**:
- Plus long
- Gestion de deux systèmes en parallèle

---

## Phase 1 : Préparation

### 1.1 Inventaire actuel

```bash
# Lister toutes vos zones DNS actuelles
# BIND
named-checkconf -p | grep zone

# PowerDNS
pdnsutil list-all-zones > current-zones.txt

# Compter
wc -l current-zones.txt

Créer un fichier d'inventaire :

                zone,type,records_count,tenants,priority
example.com,MASTER,150,tenant-a,high
test.com,MASTER,50,tenant-b,low
old.com,MASTER,10,legacy,archive

1.2 Analyse des dépendances

                # Identifier les zones avec NS externes
for zone in $(cat current-zones.txt); do
  dig $zone NS +short
done | sort -u

# Identifier les glue records nécessaires
# (si vos NS sont dans vos propres zones)

1.3 Backup complet

                # Backup zones BIND
tar -czf zones-backup-$(date +%Y%m%d).tar.gz /var/named/

# Backup PowerDNS (PostgreSQL)
pg_dump -U pdns pdns > pdns-backup-$(date +%Y%m%d).sql

# Backup config
tar -czf config-backup-$(date +%Y%m%d).tar.gz \
  /etc/bind/ \
  /etc/powerdns/ \
  /etc/named.conf

Phase 2 : Setup environnement fédéré

2.1 Déploiement infrastructure

                # Clone du repo fédération
git clone https://git.federation.chezlepro.ca/dns-platform.git
cd dns-platform

# Configuration
cp config/partner-example.yml config/$(hostname).yml
# Éditer avec vos paramètres

# Déploiement
ansible-playbook -i inventory/production.ini playbooks/deploy-platform.yml

2.2 Configuration parallèle

Important: Garder ancien système actif pendant migration

                Ancien système (production)     Nouveau système (staging)
├── 203.0.113.10 (ns1.old)      ├── 10.XXX.2.10 (ns1.new)
└── 203.0.113.11 (ns2.old)      └── 10.XXX.2.11 (ns2.new)

2.3 Import des zones

Méthode A : Import AXFR

                # Pour chaque zone
for zone in $(cat current-zones.txt); do
  # Transfer depuis ancien serveur
  dig @203.0.113.10 $zone AXFR > /tmp/$zone.axfr
  
  # Import dans nouveau système
  pdnsutil load-zone $zone /tmp/$zone.axfr
  
  echo "Imported: $zone"
done

Méthode B : Export/Import SQL

                # Export depuis ancien PowerDNS
pg_dump -U pdns -t domains -t records pdns > export.sql

# Modifier les account (tenant_id) si nécessaire
sed -i 's/old-tenant-id/new-tenant-uuid/g' export.sql

# Import dans nouveau système
psql -U dnsplatform -h 10.XXX.1.10 dnsplatform < export.sql

Phase 3 : Tests en parallèle

3.1 Validation des zones

                # Script de validation
#!/bin/bash
ZONES_FILE="current-zones.txt"
OLD_NS="203.0.113.10"
NEW_NS="10.XXX.2.10"

while read zone; do
  echo "Testing $zone..."
  
  # SOA comparison
  OLD_SOA=$(dig @$OLD_NS $zone SOA +short | awk '{print $3}')
  NEW_SOA=$(dig @$NEW_NS $zone SOA +short | awk '{print $3}')
  
  if [ "$OLD_SOA" == "$NEW_SOA" ]; then
    echo "✓ $zone: SOA match ($OLD_SOA)"
  else
    echo "✗ $zone: SOA mismatch (old:$OLD_SOA vs new:$NEW_SOA)"
  fi
  
  # Record count comparison
  OLD_COUNT=$(dig @$OLD_NS $zone AXFR +noall +answer | wc -l)
  NEW_COUNT=$(dig @$NEW_NS $zone AXFR +noall +answer | wc -l)
  
  if [ "$OLD_COUNT" == "$NEW_COUNT" ]; then
    echo "✓ $zone: Record count match ($OLD_COUNT)"
  else
    echo "✗ $zone: Record count mismatch (old:$OLD_COUNT vs new:$NEW_COUNT)"
  fi
  
  echo "---"
done < $ZONES_FILE

3.2 Tests de charge

                # Installer DNSPerf
apt-get install dnsperf

# Générer fichier de requêtes
cat > queries.txt <<EOF
example.com A
www.example.com A
mail.example.com MX
EOF

# Test ancien serveur
dnsperf -s 203.0.113.10 -d queries.txt -l 60

# Test nouveau serveur
dnsperf -s 10.XXX.2.10 -d queries.txt -l 60

# Comparer les résultats

Phase 4 : Cutover (bascule)

4.1 Fenêtre de maintenance

Checklist avant cutover:

[ ] Tous les tests passent
[ ] Backups à jour
[ ] Équipe disponible
[ ] Rollback plan prêt
[ ] Pairs fédération notifiés

4.2 Procédure de bascule

Étape 1 : Réduire les TTL (72h avant)

                # Réduire TTL à 300s (5 minutes) sur toutes les zones
for zone in $(cat current-zones.txt); do
  # Modifier SOA TTL
  pdnsutil set-meta $zone SOA-EDIT-API DEFAULT
  pdnsutil set-meta $zone DEFAULT-TTL 300
  pdnsutil increase-serial $zone
done

Étape 2 : Ajouter nouveaux NS (48h avant)

                # Pour chaque zone, ajouter les nouveaux NS
for zone in $(cat current-zones.txt); do
  # Garder anciens NS
  # Ajouter nouveaux NS (fédération)
  pdnsutil add-record $zone @ NS ns1.partner-example.com
  pdnsutil add-record $zone @ NS ns1.chezlepro.ca
  pdnsutil add-record $zone @ NS ns1.partner-a.com
  
  pdnsutil increase-serial $zone
done

Étape 3 : Mettre à jour glue records (au registrar)

                # Au registrar de chaque domaine
# Ajouter les nouveaux nameservers
ns1.partner-example.com → 203.0.113.50
ns2.partner-example.com → 203.0.113.51

# Garder les anciens pour l'instant
ns1.old-provider.com → 203.0.113.10
ns2.old-provider.com → 203.0.113.11

Attendre 48h pour propagation DNS

Étape 4 : Activer réplication fédérée

                # Configurer AXFR vers pairs
for zone in $(cat current-zones.txt); do
  # Autoriser transferts vers pairs
  pdnsutil set-meta $zone ALLOW-AXFR-FROM 10.200.0.0/16
  pdnsutil set-meta $zone ALSO-NOTIFY "10.200.0.2,10.200.0.6"
  
  # Notifier immédiatement
  pdnsutil notify $zone
done

# Vérifier synchronisation chez pairs
for zone in $(cat current-zones.txt); do
  dig @10.200.0.2 $zone SOA +short  # Chezlepro
  dig @10.200.0.6 $zone SOA +short  # Partner A
done

Étape 5 : Retirer anciens NS (après validation 24-48h)

                # Retirer anciens NS des zones
for zone in $(cat current-zones.txt); do
  pdnsutil delete-rrset $zone @ NS
  
  # Ajouter uniquement nouveaux NS
  pdnsutil add-record $zone @ NS ns1.partner-example.com
  pdnsutil add-record $zone @ NS ns2.partner-example.com
  pdnsutil add-record $zone @ NS ns1.chezlepro.ca
  
  pdnsutil increase-serial $zone
done

# Au registrar : retirer anciens glue records

Étape 6 : Restaurer TTL normaux

                # Remonter TTL à valeurs normales (3600s ou plus)
for zone in $(cat current-zones.txt); do
  pdnsutil set-meta $zone DEFAULT-TTL 3600
  pdnsutil increase-serial $zone
done

Phase 5 : Validation post-migration

5.1 Tests fonctionnels

                #!/bin/bash
# test-post-migration.sh

ZONES_FILE="current-zones.txt"

echo "=== Post-Migration Validation ==="
echo ""

TOTAL=0
SUCCESS=0
FAILED=0

while read zone; do
  TOTAL=$((TOTAL + 1))
  
  # Test résolution publique (depuis Internet)
  RESOLVED=$(dig @8.8.8.8 $zone A +short | wc -l)
  
  if [ "$RESOLVED" -gt 0 ]; then
    echo "✓ $zone resolves publicly"
    SUCCESS=$((SUCCESS + 1))
  else
    echo "✗ $zone FAILED to resolve"
    FAILED=$((FAILED + 1))
  fi
  
  # Vérifier que NS pointent vers nouveau système
  NS_LIST=$(dig $zone NS +short)
  if echo "$NS_LIST" | grep -q "partner-example.com"; then
    echo "✓ $zone has new NS records"
  else
    echo "⚠ $zone still has old NS records"
  fi
  
done < $ZONES_FILE

echo ""
echo "=== Summary ==="
echo "Total zones: $TOTAL"
echo "Success: $SUCCESS"
echo "Failed: $FAILED"
echo "Success rate: $(( SUCCESS * 100 / TOTAL ))%"

5.2 Monitoring 7 jours

                # Configurer alertes intensives pendant 7 jours
# Icinga checks toutes les 1 minute au lieu de 5

# Surveiller métriques clés:
# - Query rate (doit être similaire à avant)
# - Response time (< 50ms)
# - Error rate (< 0.1%)
# - AXFR success rate (100%)

Phase 6 : Décommissionnement ancien système

Attendre 30 jours après migration avant de supprimer

6.1 Checklist avant suppression

[ ] Aucun trafic vers ancien système depuis 30 jours
[ ] Tous les NS records mis à jour
[ ] Backups archivés et testés
[ ] Documentation mise à jour
[ ] Licences/abonnements anciens résiliés

6.2 Procédure de suppression

                # 1. Arrêter services
systemctl stop named  # ou pdns

# 2. Backup final
tar -czf final-backup-$(date +%Y%m%d).tar.gz \
  /var/named/ \
  /etc/bind/ \
  /var/log/named/

# 3. Archiver (garder 1 an minimum)
mv final-backup-*.tar.gz /archive/dns-migration/

# 4. Désinstaller
apt-get remove --purge bind9  # ou pdns

# 5. Libérer IPs publiques anciennes
# (contacter hébergeur/ISP)

Rollback Plan

En cas de problème majeur pendant la migration :

Rollback complet (< 2h après cutover)

                # 1. Réactiver ancien système
systemctl start named

# 2. Au registrar : remettre anciens NS
# (via interface web ou API registrar)

# 3. Notifier pairs fédération
curl -X POST https://api.chezlepro.ca/federation/v1/incident \
  -d '{"type": "rollback", "partner": "partner-example"}'

# 4. Analyser cause racine
# 5. Corriger problèmes
# 6. Replanifier migration

Rollback partiel (zone par zone)

Si seulement certaines zones problématiques :

                # Remettre NS de la zone problématique vers ancien système
pdnsutil delete-rrset problematic.com @ NS
pdnsutil add-record problematic.com @ NS ns1.old-provider.com
pdnsutil increase-serial problematic.com

# Continuer avec autres zones

Post-Migration

Documentation à mettre à jour

[ ] Runbooks opérationnels
[ ] Procédures d'incident
[ ] Architecture diagrams
[ ] Contacts et escalation
[ ] Contrats/SLA avec clients

Formation équipe

[ ] Formation PowerDNS (si changement de software)
[ ] Formation API plateforme
[ ] Formation procédures fédération
[ ] Accès outils (Slack, wiki, monitoring)

Optimisations

[ ] Fine-tuning cache DNS
[ ] Optimisation requêtes DB
[ ] Configuration Anycast (si applicable)
[ ] IPv6 (si pas encore fait)

Ressources

Outils utiles

DNSPerf: Tests de performance DNS
dig: Diagnostic DNS (inclus dans bind-utils)
pdnsutil: Gestion PowerDNS
ansible: Automatisation déploiement

Documentation

Wiki fédération: https://wiki.federation.chezlepro.ca
API docs: https://api.federation.chezlepro.ca/docs
Standards techniques: [lien]
Best practices: [lien]

Support

Slack: #migration-support
Email: migration-help@chezlepro.ca
Appels hebdomadaires: Jeudis 14h EST

Bonne migration ! 🚀

                
---

## Fichiers bonus à créer

### scripts/health-check.sh

```bash
#!/bin/bash
# Health check complet d'un nœud fédéré

echo "=== Federation Node Health Check ==="
echo ""

# 1. Services
echo "1. Services Status"
systemctl is-active postgresql && echo "✓ PostgreSQL" || echo "✗ PostgreSQL"
systemctl is-active pdns && echo "✓ PowerDNS" || echo "✗ PowerDNS"
systemctl is-active dns-platform-api && echo "✓ API" || echo "✗ API"
echo ""

# 2. VPN Tunnels
echo "2. VPN Tunnels"
for tunnel in /etc/wireguard/wg-*.conf; do
  name=$(basename $tunnel .conf)
  if wg show $name >/dev/null 2>&1; then
    handshake=$(wg show $name latest-handshakes | awk '{print $2}')
    age=$(($(date +%s) - handshake))
    if [ $age -lt 180 ]; then
      echo "✓ $name (handshake ${age}s ago)"
    else
      echo "⚠ $name (handshake ${age}s ago - stale!)"
    fi
  else
    echo "✗ $name (down)"
  fi
done
echo ""

# 3. DNS Resolution
echo "3. DNS Resolution"
dig @localhost SOA example.com +short >/dev/null && echo "✓ Local DNS" || echo "✗ Local DNS"
dig @8.8.8.8 SOA example.com +short >/dev/null && echo "✓ Public DNS" || echo "✗ Public DNS"
echo ""

# 4. Database
echo "4. Database"
ZONES=$(psql -U dnsplatform -t -c "SELECT COUNT(*) FROM domains;")
echo "Zones in DB: $ZONES"
echo ""

# 5. API
echo "5. API Endpoints"
curl -sf https://api.localhost/health >/dev/null && echo "✓ Tenant API" || echo "✗ Tenant API"
curl -sf https://admin.localhost/health >/dev/null && echo "✓ Admin API" || echo "✗ Admin API"
echo ""

# 6. Disk Space
echo "6. Disk Space"
df -h / | tail -1 | awk '{print "Root: " $5 " used"}'
df -h /var/lib/postgresql | tail -1 | awk '{print "PostgreSQL: " $5 " used"}'
echo ""

echo "=== End Health Check ==="

Fin des templates

Voilà un ensemble complet de templates pour gérer l'onboarding et les opérations des partenaires dans ta fédération !

Tu as maintenant :

✅ Diagrammes Mermaid visuels
✅ Fiche partenaire (YAML)
✅ Configuration réseau détaillée
✅ Checklist onboarding complète
✅ Runbook opérations courantes
✅ Configuration WireGuard
✅ Accord de fédération (légal)
✅ Guide de migration complet

Chaque template est prêt à l'emploi et peut être copié-collé dans ton wiki/documentation !