Plan d'Adressage IPv4 et Architecture Réseau Fédérée


Infrastructure Multi-Tenant Évolutive - Chezlepro



Version: 1.0
Date: Octobre 2025
Auteur: Chezlepro
Status: Plan directeur

Table des matières

Vue d'ensemble

Ce document définit le plan d'adressage IPv4 pour une infrastructure multi-tenant fédérée, où chaque partenaire héberge sa propre plateforme complète tout en participant à un réseau de services mutuels (DNS secondaire, services partagés, etc.).


Objectifs du plan

  • Isolation totale entre les partenaires
  • Aucun conflit d'adressage possible
  • Scalabilité jusqu'à 156 partenaires minimum
  • Simplicité d'allocation et de gestion
  • Flexibilité pour la croissance organique


Architecture cible


                Partenaire A (10.100.0.0/16)
├── Infrastructure complète
├── Multi-tenant interne
└── Services DNS, API, etc.
         ↕ VPN/Tunnels
Partenaire B (10.101.0.0/16)
├── Infrastructure complète
├── Multi-tenant interne
└── Services DNS, API, etc.
         ↕ VPN/Tunnels
Partenaire C (10.102.0.0/16)
├── Infrastructure complète
├── Multi-tenant interne
└── Services DNS, API, etc.

Principes de conception


1. Allocation séquentielle

Chaque partenaire reçoit un bloc /16 contigu dans l'espace RFC1918 10.0.0.0/8.

2. Isolation complète

  • Aucun chevauchement entre les blocs partenaires
  • Routage explicite uniquement via VPN/tunnels
  • Firewall par défaut entre tous les réseaux

3. Structure interne standardisée

Chaque partenaire peut segmenter son /16 selon ses besoins, mais une structure recommandée est proposée pour cohérence.

4. Réseau d'interconnexion dédié

Un bloc séparé (10.200.0.0/16) est réservé pour les interconnexions point-à-point entre partenaires.

Plan d'adressage IPv4 global

Allocation des blocs principaux

Plage Usage Capacité
10.100.0.0/16 Chezlepro (Partenaire 0) 65,534 IPs utilisables
10.101.0.0/16 Partenaire A 65,534 IPs utilisables
10.102.0.0/16 Partenaire B 65,534 IPs utilisables
10.103.0.0/16 Partenaire C 65,534 IPs utilisables
10.104.0.0/16 Partenaire D (futur) 65,534 IPs utilisables
... ... ...
10.255.0.0/16 Partenaire 155 (max) 65,534 IPs utilisables
10.200.0.0/16 Interconnexions VPN 65,534 IPs (tunnels /30)


Capacité totale

  • Partenaires supportés: 156 (10.100 à 10.255)
  • IPs par partenaire: 65,534 (bloc /16)
  • IPs totales disponibles: ~10.2 millions
  • Tunnels point-à-point: 16,384 interconnexions possibles

Allocation par partenaire


Chezlepro - 10.100.0.0/16

                Bloc principal: 10.100.0.0/16
├── 10.100.0.0/24    → Management (infra, monitoring, bastion)
├── 10.100.1.0/24    → Platform Services (API, DB, Dashboard)
├── 10.100.2.0/24    → Public DNS (ns1, ns2, serveurs publics)
├── 10.100.10.0/23   → Tenant Infrastructure (services internes)
├── 10.100.20.0/22   → Réservé (usage futur défini)
└── 10.100.128.0/17  → Expansion (50% du bloc réservé)

Partenaire A - 10.101.0.0/16

                Bloc principal: 10.101.0.0/16
├── 10.101.0.0/24    → Management
├── 10.101.1.0/24    → Platform Services
├── 10.101.2.0/24    → Public DNS
├── 10.101.10.0/23   → Tenant Infrastructure
├── 10.101.20.0/22   → Réservé
└── 10.101.128.0/17  → Expansion

Partenaire B - 10.102.0.0/16

                Bloc principal: 10.102.0.0/16
├── 10.102.0.0/24    → Management
├── 10.102.1.0/24    → Platform Services
├── 10.102.2.0/24    → Public DNS
├── 10.102.10.0/23   → Tenant Infrastructure
├── 10.102.20.0/22   → Réservé
└── 10.102.128.0/17  → Expansion

Partenaire C - 10.103.0.0/16

                Bloc principal: 10.103.0.0/16
├── 10.103.0.0/24    → Management
├── 10.103.1.0/24    → Platform Services
├── 10.103.2.0/24    → Public DNS
├── 10.103.10.0/23   → Tenant Infrastructure
├── 10.103.20.0/22   → Réservé
└── 10.103.128.0/17  → Expansion

Segmentation réseau type


Description des segments standards

Management Network (x.x.0.0/24)

Usage: Infrastructure de gestion et monitoring

                10.X.0.1      → Gateway/Router
10.X.0.10     → Monitoring (Icinga, Prometheus, etc.)
10.X.0.20     → Bastion/Jump host
10.X.0.30     → Backup server
10.X.0.40-99  → Infrastructure management
10.X.0.100+   → Reserved

Services typiques:

  • Icinga/Nagios
  • Grafana
  • Jump servers
  • Ansible control node
  • Backup systems

Platform Services (x.x.1.0/24)

Usage: Services de plateforme DNS multi-tenant

                10.X.1.1      → Gateway
10.X.1.10     → PostgreSQL primary
10.X.1.11     → PostgreSQL standby
10.X.1.20     → API Platform (FastAPI)
10.X.1.30     → Dashboard Web (Nginx + React)
10.X.1.40     → PowerDNS Authoritative primary
10.X.1.41     → PowerDNS Authoritative standby
10.X.1.50+    → Reserved for platform growth

Services typiques:

  • PostgreSQL cluster
  • FastAPI (Admin API + Tenant API)
  • Dashboard web
  • PowerDNS Authoritative
  • Redis/cache layers

Public DNS (x.x.2.0/24)

Usage: Serveurs DNS publics (répondent aux requêtes Internet)

                10.X.2.1      → Gateway
10.X.2.10     → ns1.partenaire.com (public)
10.X.2.11     → ns2.partenaire.com (public)
10.X.2.20     → PowerDNS Recursor 1
10.X.2.21     → PowerDNS Recursor 2
10.X.2.30+    → Reserved

Notes importantes:

  • Ces IPs sont NATées vers des IPs publiques
  • Doivent être déclarées au registrar
  • Haute disponibilité obligatoire

Tenant Infrastructure (x.x.10.0/23)

Usage: Services internes du tenant propriétaire du bloc

                10.X.10.0/23  → 512 IPs utilisables
├── VMs
├── Containers
├── Services applicatifs
└── Autres ressources tenant

Expansion / Reserved (x.x.128.0/17)

Usage: 50% du bloc réservé pour croissance future

                10.X.128.0/17 → 32,766 IPs
└── Allocation future selon besoins

Interconnexions VPN



Réseau dédié: 10.200.0.0/16

Ce bloc est exclusivement réservé aux tunnels VPN point-à-point entre partenaires.

Allocation des tunnels (/30)

Chaque tunnel utilise un bloc /30 (2 IPs utilisables + 1 réseau + 1 broadcast).

Matrice d'interconnexion

Tunnel Réseau IP Endpoint A IP Endpoint B Usage
Chezlepro ↔ Partenaire A 10.200.0.0/30 10.200.0.1 10.200.0.2 AXFR/NOTIFY DNS
Chezlepro ↔ Partenaire B 10.200.0.4/30 10.200.0.5 10.200.0.6 AXFR/NOTIFY DNS
Chezlepro ↔ Partenaire C 10.200.0.8/30 10.200.0.9 10.200.0.10 AXFR/NOTIFY DNS
Partenaire A ↔ B 10.200.1.0/30 10.200.1.1 10.200.1.2 Optionnel
Partenaire A ↔ C 10.200.1.4/30 10.200.1.5 10.200.1.6 Optionnel
Partenaire B ↔ C 10.200.1.8/30 10.200.1.9 10.200.1.10 Optionnel


Calcul de capacité

6,384 tunnels possibles avec 10.200.0.0/16

Supporte un maillage complet de 180+ partenaires

formule: n(n-1)/2 avec n=180 ≈ 16,000 tunnels


Configuration WireGuard type

                # Chezlepro → Partenaire A
[Interface]
Address = 10.200.0.1/30
PrivateKey = <private_key_chezlepro>
ListenPort = 51820

[Peer]
PublicKey = <public_key_partner_a>
AllowedIPs = 10.200.0.2/32, 10.101.0.0/16
Endpoint = partner-a.example.com:51820
PersistentKeepalive = 25


Architecture SDN Proxmox


Configuration des VNets

Chaque partenaire utilise Proxmox SDN pour isoler ses réseaux.

Création des zones et VNets

                # Zone VXLAN pour isolation
pvesh create /cluster/sdn/zones \
  --zone vxlan-overlay \
  --type vxlan \
  --peers proxmox1.local,proxmox2.local

# VNet pour Chezlepro
pvesh create /cluster/sdn/vnets \
  --vnet tenant-chezlepro \
  --zone vxlan-overlay \
  --tag 100

pvesh create /cluster/sdn/subnets \
  --vnet tenant-chezlepro \
  --subnet 10.100.0.0/16 \
  --gateway 10.100.0.1 \
  --snat 1

# VNet pour Partenaire A
pvesh create /cluster/sdn/vnets \
  --vnet tenant-partner-a \
  --zone vxlan-overlay \
  --tag 101

pvesh create /cluster/sdn/subnets \
  --vnet tenant-partner-a \
  --subnet 10.101.0.0/16 \
  --gateway 10.101.0.1 \
  --snat 1

# etc. pour chaque partenaire

Firewall Proxmox

                # Isolation par défaut entre VNets
# Fichier: /etc/pve/firewall/cluster.fw

[OPTIONS]
enable: 1

[RULES]
# Bloquer tout trafic inter-VNet par défaut
DROP -source +vnet/tenant-chezlepro -dest +vnet/tenant-partner-a
DROP -source +vnet/tenant-partner-a -dest +vnet/tenant-chezlepro

# Autoriser uniquement via tunnels VPN explicites
ACCEPT -source 10.200.0.0/16 -dest 10.200.0.0/16 -p tcp -dport 53
ACCEPT -source 10.200.0.0/16 -dest 10.200.0.0/16 -p udp -dport 53

Routage et isolation


Principes de routage

  1. Isolation par défaut: Aucune route entre les blocs partenaires
  2. Routage explicite: Routes statiques uniquement via tunnels VPN
  3. Pas de route par défaut: Chaque partenaire contrôle son routage

Table de routage type (Chezlepro)

                # Routes locales (automatiques)
10.100.0.0/16 via 10.100.0.1 dev vmbr0

# Routes vers partenaires (via tunnels WireGuard)
10.101.0.0/16 via 10.200.0.2 dev wg0  # Partenaire A
10.102.0.0/16 via 10.200.0.6 dev wg1  # Partenaire B
10.103.0.0/16 via 10.200.0.10 dev wg2 # Partenaire C

# Réseau d'interconnexion
10.200.0.0/16 dev wg*  # Multiple interfaces WireGuard

Filtrage de trafic

Autoriser uniquement:

  • DNS (port 53 TCP/UDP) pour AXFR/NOTIFY
  • ICMP pour diagnostics
  • Ports spécifiques selon services partagés

Bloquer par défaut:

  • Tout autre trafic entre partenaires
  • Accès direct aux réseaux management des autres

Expansion future

Ajout d'un nouveau partenaire

Étape 1: Allocation du bloc

                Prochain bloc disponible: 10.104.0.0/16 (Partenaire D)

Étape 2: Configuration initiale

                # config/partner-d.yml
partner:
  id: partner-d
  name: "Partenaire D"
  ip_block: "10.104.0.0/16"
  
  segments:
    management: "10.104.0.0/24"
    platform: "10.104.1.0/24"
    public_dns: "10.104.2.0/24"
    tenant_infra: "10.104.10.0/23"
    reserved: "10.104.128.0/17"
  
  vpn_tunnels:
    - peer: chezlepro
      network: "10.200.0.12/30"
      local_ip: "10.200.0.14"
      remote_ip: "10.200.0.13"

Étape 3: Mise à jour de la base IPAM

                -- Table des allocations
INSERT INTO ipam_allocations (tenant_id, cidr, description)
VALUES 
  ('partner-d-uuid', '10.104.0.0/16', 'Bloc principal Partenaire D'),
  ('partner-d-uuid', '10.104.0.0/24', 'Management'),
  ('partner-d-uuid', '10.104.1.0/24', 'Platform Services'),
  ('partner-d-uuid', '10.104.2.0/24', 'Public DNS');

Étape 4: Provisioning automatique

                # Via Ansible ou Terraform
ansible-playbook playbooks/provision-new-partner.yml \
  --extra-vars "partner_id=partner-d ip_block=10.104.0.0/16"

Croissance organisée par région

Pour faciliter la gestion à grande échelle, possibilité d'allouer par région:

                10.100.0.0/13 → Amérique du Nord (8 x /16 = jusqu'à 8 partenaires)
├── 10.100.0.0/16 → Chezlepro (Canada)
├── 10.101.0.0/16 → Partner US-East
├── 10.102.0.0/16 → Partner US-West
└── ...

10.108.0.0/13 → Europe (8 x /16)
├── 10.108.0.0/16 → Partner France
├── 10.109.0.0/16 → Partner Allemagne
└── ...

10.116.0.0/13 → Asie (8 x /16)
└── ...

Exemples de configuration


Fichier de configuration réseau VM type

                # /etc/netplan/01-network.yaml (Ubuntu)
network:
  version: 2
  ethernets:
    ens18:
      addresses:
        - 10.100.1.10/24  # PostgreSQL primary dans Platform Services
      gateway4: 10.100.1.1
      nameservers:
        addresses:
          - 10.100.2.10   # Local DNS
          - 10.100.2.11
        search:
          - chezlepro.internal
      routes:
        - to: 10.101.0.0/16
          via: 10.200.0.2
          metric: 100
        - to: 10.102.0.0/16
          via: 10.200.0.6
          metric: 100

Configuration PowerDNS pour AXFR

                # /etc/powerdns/pdns.conf

# API
webserver=yes
api=yes
api-key=<secret>

# Backend
launch=gpgsql
gpgsql-host=10.100.1.10
gpgsql-dbname=dnsplatform
gpgsql-user=pdns
gpgsql-password=<secret>

# Master/Slave
master=yes
slave=yes

# Transferts autorisés (via tunnels VPN)
allow-axfr-ips=10.200.0.2,10.200.0.6,10.200.0.10
also-notify=10.200.0.2:53,10.200.0.6:53,10.200.0.10:53

# TSIG pour sécurité (optionnel mais recommandé)
# Configuré via API ou directement en DB

Script d'initialisation nouveau partenaire

                #!/bin/bash
# scripts/init-partner.sh

PARTNER_ID=$1
IP_BLOCK=$2

echo "Initializing new partner: $PARTNER_ID with block $IP_BLOCK"

# 1. Créer les VNets Proxmox
pvesh create /cluster/sdn/vnets \
  --vnet "tenant-${PARTNER_ID}" \
  --zone vxlan-overlay \
  --tag $((100 + PARTNER_NUM))

pvesh create /cluster/sdn/subnets \
  --vnet "tenant-${PARTNER_ID}" \
  --subnet "${IP_BLOCK}" \
  --gateway "${IP_BLOCK%.*}.1"

# 2. Créer entrée IPAM
psql -h 10.100.1.10 -U dnsplatform -d dnsplatform <<EOF
INSERT INTO tenants (name, sdn_cidr, status)
VALUES ('${PARTNER_ID}', '${IP_BLOCK}', 'active');
EOF

# 3. Générer clés WireGuard
wg genkey | tee "${PARTNER_ID}.private" | wg pubkey > "${PARTNER_ID}.public"

echo "Partner ${PARTNER_ID} initialized successfully"
echo "Public key: $(cat ${PARTNER_ID}.public)"

Résumé du plan


Points clés à retenir

  1. Simplicité: Allocation séquentielle des blocs /16 (10.100, 10.101, 10.102...)
  2. Isolation: Aucun chevauchement, routage explicite uniquement
  3. Scalabilité: Support de 156+ partenaires sans refonte
  4. Flexibilité: Chaque partenaire segmente son /16 selon ses besoins
  5. Interconnexion: Réseau dédié 10.200.0.0/16 pour les tunnels VPN
  6. Standard: Structure recommandée mais non imposée

Checklist déploiement nouveau partenaire

  • [ ] Allouer le prochain bloc /16 disponible
  • [ ] Créer les VNets/subnets dans Proxmox SDN
  • [ ] Configurer les tunnels WireGuard vers partenaires existants
  • [ ] Mettre à jour les tables de routage
  • [ ] Configurer PowerDNS pour AXFR
  • [ ] Enregistrer dans la base IPAM
  • [ ] Documenter l'allocation
  • [ ] Tester la connectivité

Outils de gestion

  • IPAM: NetBox ou base PostgreSQL custom
  • Monitoring: Icinga pour surveiller les tunnels et connectivité
  • Automation: Ansible pour provisioning
  • Documentation: Wiki interne avec plan à jour

Annexes 


Annexe A: Calcul de subnets  

                

                /16 = 65,536 IPs (65,534 utilisables)
/17 = 32,768 IPs
/20 = 4,096 IPs
/22 = 1,024 IPs
/23 = 512 IPs
/24 = 256 IPs (254 utilisables)
/30 = 4 IPs (2 utilisables) - pour tunnels point-à-point

Annexe B: Commandes utiles 

                
                  

                
                # Vérifier routes
ip route show

# Tester connectivité tunnel
ping -c 3 10.200.0.2

# Vérifier état WireGuard
wg show

# Lister les VNets Proxmox
pvesh get /cluster/sdn/vnets

# Test AXFR DNS
dig @10.200.0.2 example.com AXFR

Annexe C: Ressources

  • RFC 1918: Private Address Space
  • PowerDNS Documentation: https://doc.powerdns.com/
  • WireGuard: https://www.wireguard.com/
  • Proxmox SDN: https://pve.proxmox.com/wiki/Software_Defined_Network

Fin du document

Ce plan d'adressage est évolutif et peut être adapté selon les besoins spécifiques de chaque déploiement. Il fournit une base solide pour une croissance organique et contrôlée de la fédération.