Pangolin : Reverse Proxy et Tunnel Self-Hosted — Guide Complet

Pangolin s'impose comme l'une des solutions self-hosted les plus prometteuses pour le reverse proxy et le tunneling sécurisé, offrant une alternative crédible et souveraine à Cloudflare Tunnel. Dans un contexte où la maîtrise de l'infrastructure réseau constitue un enjeu stratégique majeur pour les organisations soucieuses de leur souveraineté numérique, Pangolin propose une architecture modulaire combinant Gerbil (tunneling WireGuard), Traefik (reverse proxy dynamique) et CrowdSec (protection collaborative contre les menaces). Cette stack intégrée permet d'exposer des services internes sur Internet sans ouvrir de ports entrants sur le pare-feu, tout en bénéficiant d'une gestion centralisée des certificats TLS, du routage dynamique et d'une protection proactive contre les attaques. Ce guide technique expert couvre l'ensemble de l'écosystème Pangolin : de l'architecture interne jusqu'au déploiement Docker en production, en passant par la configuration avancée, le hardening sécuritaire, les cas d'usage concrets et une comparaison détaillée avec les solutions concurrentes. Que vous soyez administrateur système, ingénieur DevOps ou consultant en sécurité des pipelines CI/CD, ce guide vous fournira les connaissances nécessaires pour évaluer, déployer et exploiter Pangolin dans votre infrastructure.

Qu'est-ce que Pangolin et pourquoi l'utiliser ?

Pangolin est une plateforme open source et self-hosted qui combine les fonctionnalités d'un reverse proxy, d'un tunnel réseau sécurisé et d'un système de protection contre les menaces dans une solution unifiée. Conçu pour les administrateurs et les organisations qui souhaitent conserver un contrôle total sur leur infrastructure de routage, Pangolin élimine la nécessité de recourir à des services cloud tiers pour exposer des applications internes sur Internet. Le projet s'articule autour de trois composants principaux : Traefik comme reverse proxy et terminaison TLS, Gerbil comme agent de tunneling basé sur WireGuard, et CrowdSec comme couche de défense collaborative. Cette combinaison permet de reproduire — et dans certains cas de surpasser — les fonctionnalités offertes par Cloudflare Tunnel, Nginx Proxy Manager ou d'autres solutions commerciales, tout en offrant une transparence totale sur le traitement du trafic.

Le besoin auquel répond Pangolin est fondamental : comment exposer de manière sécurisée des services hébergés derrière un NAT, un pare-feu restrictif ou une connexion résidentielle, sans compromettre la posture de sécurité du réseau local ? Les approches traditionnelles — ouverture de ports, VPN site-to-site, DMZ — présentent chacune des inconvénients significatifs en termes de surface d'attaque, de complexité opérationnelle ou de coûts. Pangolin résout cette équation en établissant un tunnel WireGuard sortant depuis le réseau interne vers un serveur Pangolin exposé sur Internet. Ce tunnel chiffré transporte le trafic HTTP/HTTPS de manière transparente, permettant aux utilisateurs externes d'accéder aux services internes comme s'ils étaient directement exposés, sans jamais ouvrir de port entrant sur le pare-feu local. Cette approche s'inscrit parfaitement dans une stratégie de défense en profondeur où chaque couche de l'infrastructure contribue à la posture globale de sécurité.

L'adoption de Pangolin se justifie particulièrement dans plusieurs contextes : les laboratoires de cybersécurité où les chercheurs doivent exposer temporairement des honeypots ou des outils d'analyse sans compromettre leur réseau principal ; les environnements de développement distribués où les équipes ont besoin d'accéder à des services de staging hébergés localement ; les organisations soumises à des contraintes réglementaires interdisant le transit du trafic par des serveurs tiers ; et plus généralement, tout scénario où la souveraineté sur le chiffrement TLS et le routage du trafic constitue une exigence non négociable. Le projet Pangolin, activement maintenu sur GitHub, bénéficie d'une communauté croissante et d'une documentation en constante amélioration, témoignant de la maturité progressive de l'outil.

Architecture technique de Pangolin

L'architecture de Pangolin repose sur une séparation claire des responsabilités entre ses trois composants principaux, chacun remplissant un rôle spécifique dans la chaîne de traitement du trafic. Cette modularité permet non seulement une compréhension intuitive du flux de données, mais aussi une maintenance et une évolution indépendantes de chaque composant. La conception s'inspire des principes d'architecture logicielle moderne, avec un couplage faible entre les services et une communication standardisée via des interfaces bien définies.

Traefik : le reverse proxy dynamique

Traefik constitue la couche d'entrée de Pangolin, celle qui reçoit l'ensemble du trafic provenant d'Internet. Dans l'écosystème Pangolin, Traefik remplit plusieurs fonctions critiques simultanément. La terminaison TLS gère automatiquement l'obtention et le renouvellement des certificats Let's Encrypt via le protocole ACME, éliminant toute intervention manuelle pour la gestion du chiffrement. Le routage dynamique dirige les requêtes entrantes vers les services appropriés en fonction des règles définies (nom de domaine, préfixe de chemin, en-têtes HTTP), sans nécessiter de rechargement de configuration. Le load balancing distribue la charge entre plusieurs instances d'un même service lorsque la haute disponibilité est requise. Les middlewares appliquent des transformations et des vérifications aux requêtes : authentification, limitation de débit (rate limiting), redirection HTTP vers HTTPS, ajout d'en-têtes de sécurité, compression GZIP. L'intégration de Traefik dans Pangolin est préconfigurée pour fonctionner de manière optimale avec le tunnel Gerbil, mais reste entièrement personnalisable via les fichiers de configuration YAML ou les labels Docker.

Gerbil : le tunnel WireGuard

Gerbil est le composant de tunneling de Pangolin, responsable de l'établissement et du maintien des connexions sécurisées entre le serveur Pangolin et les réseaux internes des utilisateurs. Basé sur le protocole WireGuard, Gerbil bénéficie des avantages intrinsèques de ce protocole moderne : une base de code minimale et auditable (environ 4000 lignes de code), un chiffrement de pointe utilisant Curve25519 pour l'échange de clés, ChaCha20-Poly1305 pour le chiffrement authentifié et BLAKE2s pour le hachage, des performances réseau supérieures à IPsec et OpenVPN grâce à l'intégration noyau Linux, et un établissement de connexion ultra-rapide (handshake en un seul aller-retour). Gerbil fonctionne comme un agent déployé côté client — sur le réseau où se trouvent les services à exposer. Cet agent initie une connexion WireGuard sortante vers le serveur Pangolin, créant un tunnel persistant à travers lequel le trafic HTTP/HTTPS est transporté. Ce modèle de connexion sortante est fondamental car il élimine la nécessité d'ouvrir des ports entrants sur le pare-feu du réseau interne, réduisant considérablement la surface d'attaque.

CrowdSec : la protection collaborative

CrowdSec apporte la dimension défensive à l'architecture Pangolin, fonctionnant comme un IPS (Intrusion Prevention System) comportemental et collaboratif. Contrairement aux WAF traditionnels qui s'appuient sur des signatures statiques, CrowdSec analyse les comportements du trafic en temps réel et prend des décisions de blocage basées sur des scénarios prédéfinis et sur les données partagées par la communauté mondiale d'utilisateurs. L'architecture CrowdSec au sein de Pangolin se compose du LAPI (Local API), qui stocke et gère les décisions de sécurité locales, et du bouncer Traefik, un middleware qui intercepte les requêtes entrantes et consulte le LAPI pour déterminer si l'adresse IP source est autorisée ou bloquée. Les scénarios de détection couvrent les attaques les plus courantes : brute force sur les formulaires d'authentification, scan de ports, exploitation de vulnérabilités connues (CVE), crawling agressif, et attaques DDoS de couche applicative. L'intégration dans Pangolin est transparente : CrowdSec s'active comme un middleware Traefik et protège automatiquement l'ensemble des services exposés, ce qui complète les approches de monitoring du darkweb en ajoutant une couche de prévention active.

Flux de trafic : du client au service interne

Comprendre le flux complet d'une requête à travers l'infrastructure Pangolin est essentiel pour diagnostiquer les problèmes, optimiser les performances et identifier les points de contrôle de sécurité. Le parcours d'une requête typique implique plusieurs étapes de traitement, chacune ajoutant une couche de fonctionnalité ou de protection. Voici le détail complet du flux de trafic depuis la requête initiale d'un utilisateur jusqu'à la réponse du service interne.

Lorsqu'un utilisateur accède à un service via Pangolin, la requête HTTPS est d'abord résolue par le DNS vers l'adresse IP publique du serveur Pangolin. À l'arrivée sur le serveur, le bouncer CrowdSec intégré comme middleware Traefik effectue immédiatement une vérification de l'adresse IP source contre la base de données locale de décisions (blocages, captchas) et la liste communautaire d'IP malveillantes. Si l'IP est autorisée, Traefik procède à la terminaison TLS, déchiffre la requête HTTPS et applique les middlewares configurés (authentification, rate limiting, headers de sécurité). La requête déchiffrée est ensuite transmise au composant Gerbil qui la réencapsule dans un paquet WireGuard chiffré et l'envoie via le tunnel préétabli vers l'agent Gerbil distant. Côté réseau interne, l'agent Gerbil déchiffre le paquet WireGuard et transmet la requête HTTP en clair au service local sur le port configuré. La réponse emprunte le chemin inverse, avec une latence supplémentaire typique de 3 à 12 millisecondes selon la distance géographique et la configuration des middlewares.

Un aspect technique particulièrement important est le double chiffrement qui s'opère sur la portion publique du réseau. Entre le client et Traefik, le trafic est protégé par TLS 1.3. Entre Traefik et Gerbil (puis entre les deux instances Gerbil), le trafic transite dans le tunnel WireGuard qui utilise ChaCha20-Poly1305. Ce double chiffrement, bien que redondant en apparence, offre une défense en profondeur : même si le chiffrement TLS était compromis (par un certificat mal configuré ou une vulnérabilité dans la négociation), le tunnel WireGuard maintient la confidentialité des données. De même, la compromission du tunnel WireGuard ne suffirait pas si le trafic TLS est correctement configuré.

Installation et déploiement Docker

Le déploiement de Pangolin s'effectue principalement via Docker Compose, qui orchestre l'ensemble des composants de la stack. Cette approche garantit une installation reproductible et facilite les mises à jour. Les prérequis sont un serveur Linux avec une adresse IP publique, Docker et Docker Compose installés, et un nom de domaine pointant vers cette IP. Un VPS avec 2 vCPU, 2 Go de RAM et 20 Go de stockage constitue une configuration minimale suffisante pour la plupart des déploiements.

Prérequis et préparation du serveur

Avant de commencer l'installation de Pangolin, il est nécessaire de préparer le serveur hôte avec les composants de base et les configurations système requises pour le bon fonctionnement de la stack.

# Mise à jour du système
sudo apt update && sudo apt upgrade -y

# Installation de Docker
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER

# Installation de Docker Compose v2
sudo apt install docker-compose-plugin -y

# Vérification des versions
docker --version
docker compose version

# Configuration du pare-feu (UFW)
sudo ufw allow 80/tcp    # HTTP (redirection vers HTTPS)
sudo ufw allow 443/tcp   # HTTPS
sudo ufw allow 51820/udp # WireGuard
sudo ufw enable

# Activation du forwarding IP (requis pour WireGuard)
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
echo "net.ipv6.conf.all.forwarding = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# Création du répertoire de travail
mkdir -p /opt/pangolin && cd /opt/pangolin

Configuration Docker Compose

Le fichier docker-compose.yml principal définit l'ensemble de la stack Pangolin. Chaque service est configuré avec ses volumes, ses réseaux et ses variables d'environnement spécifiques. La configuration suivante représente un déploiement de production avec l'ensemble des fonctionnalités activées.

version: "3.9"

services:
  pangolin:
    image: fosrl/pangolin:latest
    container_name: pangolin
    restart: unless-stopped
    volumes:
      - ./config:/app/config
      - ./data:/app/data
    networks:
      - pangolin-net
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3001/health"]
      interval: 30s
      timeout: 10s
      retries: 3

  gerbil:
    image: fosrl/gerbil:latest
    container_name: gerbil
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv6.conf.all.forwarding=1
    volumes:
      - ./config:/app/config
      - ./data:/app/data
    ports:
      - "51820:51820/udp"
    networks:
      - pangolin-net

  traefik:
    image: traefik:v3.1
    container_name: traefik
    restart: unless-stopped
    command:
      - "--api.dashboard=false"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.file.directory=/etc/traefik/dynamic"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.web.http.redirections.entryPoint.to=websecure"
      - "--certificatesresolvers.letsencrypt.acme.email=admin@example.com"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt
      - ./traefik/dynamic:/etc/traefik/dynamic
    networks:
      - pangolin-net

  crowdsec:
    image: crowdsecurity/crowdsec:latest
    container_name: crowdsec
    restart: unless-stopped
    environment:
      - COLLECTIONS=crowdsecurity/traefik crowdsecurity/http-cve crowdsecurity/base-http-scenarios
    volumes:
      - ./crowdsec/acquis.yaml:/etc/crowdsec/acquis.yaml
      - ./crowdsec/db:/var/lib/crowdsec/data
      - ./crowdsec/config:/etc/crowdsec
      - /var/log/traefik:/var/log/traefik:ro
    networks:
      - pangolin-net

  crowdsec-bouncer:
    image: fbonalair/traefik-crowdsec-bouncer:latest
    container_name: crowdsec-bouncer
    restart: unless-stopped
    environment:
      - CROWDSEC_BOUNCER_API_KEY=${CROWDSEC_API_KEY}
      - CROWDSEC_AGENT_HOST=crowdsec:8080
    networks:
      - pangolin-net

networks:
  pangolin-net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.28.0.0/16

Configuration de Pangolin

Le fichier de configuration principal de Pangolin est au format YAML et définit les paramètres globaux de la plateforme, incluant les domaines, les tunnels et les politiques de sécurité.

# config/config.yml
app:
  dashboard_url: "https://pangolin.example.com"
  log_level: "info"
  base_domain: "example.com"

users:
  server_admin:
    email: "admin@example.com"
    password: "$argon2id$v=19$m=65536,t=3,p=2$..."  # Hash Argon2id

gerbil:
  wireguard:
    listen_port: 51820
    subnet: "10.0.0.0/24"
    dns: "1.1.1.1, 8.8.8.8"
    mtu: 1420
    persistent_keepalive: 25

traefik:
  cert_resolver: "letsencrypt"
  default_entrypoints:
    - "websecure"
  security_headers:
    content_security_policy: "default-src 'self'"
    strict_transport_security: "max-age=63072000; includeSubDomains; preload"
    x_content_type_options: "nosniff"
    x_frame_options: "DENY"
    referrer_policy: "strict-origin-when-cross-origin"

crowdsec:
  enabled: true
  bouncer_api_key: "${CROWDSEC_API_KEY}"
  ban_duration: "4h"
  scenarios:
    - "crowdsecurity/http-bad-user-agent"
    - "crowdsecurity/http-probing"
    - "crowdsecurity/http-sensitive-files"
    - "crowdsecurity/http-xss-probing"

Démarrage et vérification

# Démarrage de la stack
cd /opt/pangolin
docker compose up -d

# Vérification du statut des conteneurs
docker compose ps

# Vérification des logs
docker compose logs -f pangolin
docker compose logs -f gerbil
docker compose logs -f traefik

# Test de connectivité WireGuard
docker exec gerbil wg show

# Vérification de CrowdSec
docker exec crowdsec cscli decisions list
docker exec crowdsec cscli metrics

# Test du certificat TLS
curl -vI https://pangolin.example.com 2>&1 | grep -E "SSL|certificate"

Configuration avancée des tunnels

La configuration des tunnels Gerbil constitue le coeur fonctionnel de Pangolin. Chaque tunnel établit une liaison WireGuard entre le serveur Pangolin et un réseau distant, permettant l'exposition de services spécifiques. La granularité de la configuration permet de contrôler finement quels services sont accessibles, sur quels domaines et avec quelles politiques de sécurité.

Ajout d'un site et d'un tunnel via le dashboard

Le dashboard Pangolin fournit une interface web pour la gestion des sites et des tunnels. Cependant, pour les déploiements à grande échelle ou l'automatisation, la configuration via fichiers YAML et l'API REST est préférable. Lors de la création d'un nouveau site dans le dashboard, Pangolin génère automatiquement les clés WireGuard, la configuration de l'agent Gerbil à déployer côté client, et les règles de routage Traefik correspondantes. Le processus se décompose en plusieurs étapes techniques : génération de la paire de clés Curve25519, attribution d'une adresse IP dans le sous-réseau WireGuard configuré, création de la configuration Traefik dynamique (router + service + middlewares), et export de la configuration client Gerbil au format YAML ou comme fichier de configuration Docker Compose autonome.

Configuration de l'agent Gerbil côté client

# docker-compose.yml côté client (réseau interne)
version: "3.9"

services:
  gerbil-client:
    image: fosrl/gerbil:latest
    container_name: gerbil-client
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    environment:
      - PANGOLIN_ENDPOINT=pangolin.example.com:51820
      - GERBIL_PRIVATE_KEY=${GERBIL_CLIENT_PRIVATE_KEY}
      - GERBIL_SERVER_PUBLIC_KEY=${GERBIL_SERVER_PUBLIC_KEY}
      - GERBIL_ADDRESS=10.0.0.2/32
    volumes:
      - ./gerbil-config:/app/config
    network_mode: host

Exposition de services multiples

Pangolin permet d'exposer plusieurs services à travers un seul tunnel WireGuard, chacun avec sa propre configuration de routage et de sécurité. Cette capacité est particulièrement utile pour les environnements comprenant de nombreux microservices.

# config/sites/homelab.yml
site:
  name: "homelab"
  tunnel:
    endpoint: "pangolin.example.com:51820"
    address: "10.0.0.2/32"
    dns: "10.0.0.1"
    persistent_keepalive: 25

  resources:
    - name: "nextcloud"
      domain: "cloud.example.com"
      target: "http://192.168.1.100:8080"
      tls: true
      middlewares:
        - "security-headers"
        - "crowdsec-bouncer"
        - "rate-limit-standard"

    - name: "gitea"
      domain: "git.example.com"
      target: "http://192.168.1.101:3000"
      tls: true
      middlewares:
        - "security-headers"
        - "crowdsec-bouncer"

    - name: "grafana"
      domain: "monitoring.example.com"
      target: "http://192.168.1.102:3000"
      tls: true
      middlewares:
        - "security-headers"
        - "crowdsec-bouncer"
        - "basic-auth-admin"

    - name: "api-interne"
      domain: "api.example.com"
      target: "http://192.168.1.103:8443"
      tls: true
      path_prefix: "/v1"
      middlewares:
        - "security-headers"
        - "crowdsec-bouncer"
        - "rate-limit-api"
        - "cors-policy"

Chaque ressource peut être configurée avec des middlewares spécifiques, permettant une personnalisation fine de la politique de sécurité par service. Un service d'API peut nécessiter un rate limiting strict et une politique CORS, tandis qu'un service de stockage comme Nextcloud peut bénéficier de limites de taille de requête plus généreuses. Cette granularité est un avantage significatif par rapport à des solutions plus monolithiques où la configuration de sécurité est globale.

Hardening sécuritaire de Pangolin

Le durcissement de l'infrastructure Pangolin est une étape cruciale qui ne doit pas être négligée, même si la stack intègre nativement des mécanismes de protection. Une approche de défense en profondeur implique de sécuriser chaque couche indépendamment, de sorte que la compromission d'un composant ne mette pas en péril l'ensemble du système. Les recommandations qui suivent couvrent les aspects réseau, système, applicatif et opérationnel du hardening.

Sécurisation de la couche réseau

La première ligne de défense est le pare-feu du serveur hôte. Seuls les ports strictement nécessaires doivent être ouverts : le port 80 (pour la redirection HTTP vers HTTPS et le challenge ACME), le port 443 (pour le trafic HTTPS) et le port 51820 UDP (pour WireGuard). Tous les autres ports doivent être fermés, y compris le port SSH si l'accès se fait via un tunnel WireGuard dédié à l'administration. La configuration du pare-feu doit également inclure des règles de rate limiting au niveau iptables/nftables pour atténuer les attaques DDoS volumétriques avant même qu'elles n'atteignent Traefik ou CrowdSec.

# Configuration nftables avancée
sudo nft add table inet pangolin_filter
sudo nft add chain inet pangolin_filter input { type filter hook input priority 0 \; policy drop \; }

# Autoriser le loopback
sudo nft add rule inet pangolin_filter input iif "lo" accept

# Autoriser les connexions établies
sudo nft add rule inet pangolin_filter input ct state established,related accept

# Rate limiting SSH (si activé)
sudo nft add rule inet pangolin_filter input tcp dport 22 ct state new limit rate 3/minute accept

# Ports Pangolin
sudo nft add rule inet pangolin_filter input tcp dport { 80, 443 } accept
sudo nft add rule inet pangolin_filter input udp dport 51820 accept

# Protection anti-DDoS SYN flood
sudo nft add rule inet pangolin_filter input tcp flags syn limit rate 100/second accept

# Log et drop du reste
sudo nft add rule inet pangolin_filter input log prefix "PANGOLIN_DROP: " drop

Sécurisation de Traefik

Traefik doit être configuré avec des paramètres TLS stricts pour maximiser la sécurité des connexions. La désactivation des protocoles TLS obsolètes (TLS 1.0 et 1.1), la restriction aux suites cryptographiques modernes et la configuration des en-têtes de sécurité HTTP sont des mesures fondamentales.

# traefik/dynamic/tls.yml
tls:
  options:
    default:
      minVersion: "VersionTLS12"
      cipherSuites:
        - "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
        - "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
        - "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256"
        - "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256"
      curvePreferences:
        - "X25519"
        - "CurveP384"
      sniStrict: true
    modern:
      minVersion: "VersionTLS13"

# traefik/dynamic/middlewares.yml
http:
  middlewares:
    security-headers:
      headers:
        browserXssFilter: true
        contentTypeNosniff: true
        frameDeny: true
        stsIncludeSubdomains: true
        stsPreload: true
        stsSeconds: 63072000
        customResponseHeaders:
          X-Robots-Tag: "noindex, nofollow"
          Permissions-Policy: "camera=(), microphone=(), geolocation=()"

    rate-limit-standard:
      rateLimit:
        average: 100
        burst: 50
        period: "1m"

    rate-limit-api:
      rateLimit:
        average: 30
        burst: 10
        period: "1m"

Sécurisation de WireGuard et de Gerbil

Le tunnel WireGuard doit être configuré avec des paramètres optimaux pour la sécurité. Les clés WireGuard doivent être générées avec suffisamment d'entropie, le sous-réseau WireGuard doit être isolé du réseau Docker, et les adresses IP autorisées (AllowedIPs) doivent être restreintes au minimum nécessaire pour respecter le principe du moindre privilège. Le paramètre persistent_keepalive doit être ajusté en fonction de la stabilité de la connexion et des exigences de NAT traversal, une valeur de 25 secondes étant généralement suffisante. La rotation périodique des clés WireGuard (tous les 90 jours pour les déploiements sensibles) ajoute une couche de protection supplémentaire, même si WireGuard effectue déjà une rotation automatique des clés de session via son mécanisme de handshake.

Configuration avancée de CrowdSec

L'optimisation de CrowdSec pour un déploiement Pangolin implique l'ajout de scénarios de détection supplémentaires adaptés aux types de services exposés, la configuration des whitelists pour éviter les faux positifs sur les IP légitimes, et l'ajustement des durées de bannissement en fonction de la sévérité des infractions.

# crowdsec/acquis.yaml
filenames:
  - /var/log/traefik/access.log
labels:
  type: traefik

---
# Ajout de scénarios personnalisés
# crowdsec/scenarios/pangolin-api-abuse.yaml
type: leaky
name: pangolin/api-abuse
description: "Détection d'abus d'API via Pangolin"
filter: "evt.Meta.log_type == 'traefik' && evt.Parsed.request contains '/api/'"
groupby: "evt.Meta.source_ip"
capacity: 50
leakspeed: "10s"
blackhole: "5m"
labels:
  remediation: true

Cas d'usage concrets de Pangolin

L'utilité de Pangolin se manifeste pleinement dans des scénarios réels où les solutions traditionnelles d'exposition de services atteignent leurs limites. Les cas d'usage suivants illustrent la polyvalence de la plateforme et les configurations adaptées à chaque contexte.

Laboratoire de cybersécurité

Les chercheurs en sécurité ont régulièrement besoin d'exposer des services sur Internet pour des tests de pénétration, le déploiement de honeypots ou la mise en place d'infrastructures de command and control (C2) à des fins de recherche. Pangolin permet d'exposer ces services sans compromettre le réseau du laboratoire, avec la possibilité de couper instantanément l'accès en détruisant le tunnel. L'intégration de CrowdSec permet également de collecter des données sur les attaques reçues, enrichissant la recherche en threat intelligence. Un chercheur peut ainsi déployer un honeypot SSH exposé via Pangolin, analyser les tentatives de brute force capturées par CrowdSec, et corréler ces données avec les indicateurs de compromission identifiés dans son activité de gestion d'IOC.

Homelab et auto-hébergement

Le cas d'usage le plus courant de Pangolin concerne les utilisateurs qui souhaitent exposer des services auto-hébergés (Nextcloud, Gitea, Home Assistant, Jellyfin) depuis une connexion résidentielle sans adresse IP publique fixe ou derrière un NAT de l'opérateur (CGNAT). Pangolin résout élégamment ce problème en utilisant un VPS bon marché comme point d'entrée public, le tunnel WireGuard assurant la liaison avec le serveur domestique. Comparé à l'utilisation de Cloudflare Tunnel pour le même scénario, Pangolin offre l'avantage de ne pas faire transiter le trafic déchiffré par les serveurs d'un tiers, ce qui est particulièrement important pour les services manipulant des données personnelles sensibles.

Infrastructure multi-sites en entreprise

Pour les entreprises disposant de plusieurs sites physiques, Pangolin peut servir de solution de connectivité légère pour exposer des applications internes spécifiques sans déployer un VPN site-to-site complet. Chaque site déploie un agent Gerbil qui établit un tunnel vers le serveur Pangolin central, permettant l'exposition sélective de services métier. Cette approche est complémentaire — et non concurrente — avec les solutions VPN traditionnelles : le VPN assure la connectivité réseau complète entre les sites, tandis que Pangolin gère l'exposition publique de services spécifiques avec une granularité de contrôle supérieure.

Environnements de développement distribués

Dans les équipes de développement distribuées, il est fréquent de devoir partager un environnement de staging ou de démonstration avec des parties prenantes externes (clients, partenaires, testeurs). Pangolin permet d'exposer instantanément un environnement de développement local sur Internet, avec un certificat TLS valide et une URL propre. Le développeur démarre son application localement, lance l'agent Gerbil, et l'application devient accessible via un sous-domaine dédié. Cette fonctionnalité est comparable au cloudflared tunnel de Cloudflare mais avec un contrôle total sur l'infrastructure intermédiaire.

Comparaison avec les solutions concurrentes

Le positionnement de Pangolin dans l'écosystème des solutions de reverse proxy et de tunneling se comprend mieux à travers une comparaison détaillée avec les alternatives les plus populaires. Chaque solution présente des compromis différents entre facilité d'utilisation, contrôle, performance et coût.

Critère	Pangolin	Cloudflare Tunnel	Nginx Proxy Manager	Traefik Standalone	frp
Self-hosted	Oui (100%)	Non (SaaS)	Oui	Oui	Oui
Tunneling intégré	Oui (WireGuard)	Oui (QUIC)	Non	Non	Oui (TCP/UDP)
Reverse proxy	Oui (Traefik)	Oui	Oui (Nginx)	Oui	Basique
WAF / IPS intégré	Oui (CrowdSec)	Oui (WAF Cloudflare)	Non	Non natif	Non
Certificats TLS auto	Let's Encrypt	Cloudflare	Let's Encrypt	Let's Encrypt	Non natif
Dashboard web	Oui	Oui	Oui	Optionnel	Oui (basique)
Protocole tunnel	WireGuard	QUIC / HTTP/2	N/A	N/A	TCP / KCP / QUIC
Performance tunnel	Excellente	Bonne	N/A	N/A	Bonne
Souveraineté données	Totale	Aucune	Totale	Totale	Totale
Complexité setup	Moyenne	Faible	Faible	Moyenne-haute	Moyenne
Coût	VPS (~5€/mois)	Gratuit (limité)	Gratuit	Gratuit	VPS (~5€/mois)
Communauté	Croissante	Large	Large	Large	Large

Pangolin vs Cloudflare Tunnel : analyse détaillée

La comparaison entre Pangolin et Cloudflare Tunnel est la plus pertinente car ces deux solutions répondent au même besoin fondamental : exposer des services internes sur Internet via un tunnel sortant. Cloudflare Tunnel utilise le protocole QUIC (ou HTTP/2 en fallback) pour établir une connexion persistante entre un démon cloudflared et le réseau Cloudflare. Le trafic est routé via le CDN mondial de Cloudflare, bénéficiant d'une protection DDoS de classe mondiale et d'un WAF sophistiqué. Cependant, cette architecture implique que Cloudflare déchiffre et rechiffre le trafic TLS à chaque passage par son infrastructure — un aspect qui pose des questions fondamentales en matière de confidentialité et de conformité réglementaire. Pangolin, en revanche, maintient un contrôle total sur la chaîne de chiffrement : le certificat TLS est géré localement, et le trafic déchiffré ne transite jamais par un serveur tiers. Pour les organisations soumises au RGPD ou à des réglementations sectorielles strictes, cette différence peut être décisive.

Du point de vue des performances, Pangolin bénéficie de l'efficacité du protocole WireGuard, qui opère au niveau du noyau Linux et offre un throughput supérieur au QUIC utilisé par Cloudflare Tunnel dans la plupart des benchmarks. Cependant, Cloudflare compense cette différence par son réseau Anycast mondial, qui réduit la latence pour les utilisateurs géographiquement distants du serveur d'origine. Pour un service destiné à un public local ou régional, Pangolin offre des performances comparables ou supérieures. Pour un service à audience mondiale, Cloudflare Tunnel peut offrir une meilleure expérience utilisateur grâce à son CDN, à moins de déployer des instances Pangolin dans plusieurs régions géographiques.

Pangolin vs frp (Fast Reverse Proxy)

frp est une autre solution open source populaire pour le tunneling et le reverse proxy, souvent comparée à Pangolin. Développé principalement par la communauté chinoise, frp offre une grande flexibilité avec le support de multiples protocoles de tunnel (TCP, UDP, KCP, QUIC, WebSocket) et une configuration relativement simple. Cependant, frp ne fournit pas de reverse proxy avancé ni de protection contre les menaces en standard — ces fonctionnalités doivent être ajoutées manuellement (par exemple, en plaçant un Nginx ou un Traefik devant frp). Pangolin se distingue par son approche intégrée qui combine tunnel, reverse proxy et protection dans une seule stack cohérente. Le compromis est une complexité initiale légèrement supérieure en échange d'une solution plus complète et plus sécurisée. Pour les utilisateurs qui ont besoin uniquement de tunneling basique sans reverse proxy avancé, frp reste une alternative valide et plus légère.

Monitoring et observabilité

La mise en place d'un système de monitoring robuste est indispensable pour garantir la fiabilité et la sécurité d'un déploiement Pangolin en production. L'observabilité de la stack couvre trois dimensions : les métriques de performance, les logs d'accès et de sécurité, et les alertes en temps réel. Chaque composant de Pangolin expose des données qui peuvent être collectées et agrégées dans un système de monitoring centralisé.

Métriques Traefik et Prometheus

Traefik expose nativement des métriques au format Prometheus, couvrant les compteurs de requêtes, les latences, les codes de réponse, les connexions TLS et les états des backends. L'activation de ces métriques se fait via la configuration Traefik, et un service Prometheus peut les scraper à intervalle régulier pour alimenter des dashboards Grafana.

# Ajout des métriques Prometheus à Traefik
# docker-compose.yml - section traefik command
- "--metrics.prometheus=true"
- "--metrics.prometheus.addEntryPointsLabels=true"
- "--metrics.prometheus.addServicesLabels=true"
- "--metrics.prometheus.buckets=0.1,0.3,1.2,5.0"

# prometheus.yml
scrape_configs:
  - job_name: 'traefik'
    static_configs:
      - targets: ['traefik:8082']
    metrics_path: /metrics
    scrape_interval: 15s

  - job_name: 'crowdsec'
    static_configs:
      - targets: ['crowdsec:6060']
    metrics_path: /metrics
    scrape_interval: 30s

Alerting et notification

Les alertes critiques doivent être configurées pour les événements suivants : perte de connectivité d'un tunnel WireGuard, augmentation anormale du taux d'erreurs HTTP (5xx), bannissement massif d'IP par CrowdSec (indicateur potentiel d'attaque en cours), expiration imminente d'un certificat TLS, et saturation des ressources système (CPU, RAM, stockage). L'utilisation d'Alertmanager avec Prometheus permet de configurer des règles d'alerte granulaires et de les router vers différents canaux de notification (email, Slack, PagerDuty, webhook).

Automatisation et Infrastructure as Code

Pour les déploiements à grande échelle ou dans des environnements nécessitant une reproductibilité totale, l'approche Infrastructure as Code (IaC) s'applique parfaitement à Pangolin. L'ensemble de la configuration peut être versionnée dans un dépôt Git, et le déploiement peut être automatisé via des outils comme Ansible, Terraform ou des pipelines CI/CD. Cette approche est cohérente avec les pratiques de sécurisation des pipelines CI/CD que toute organisation devrait adopter.

# ansible/roles/pangolin/tasks/main.yml
---
- name: Créer le répertoire Pangolin
  file:
    path: /opt/pangolin
    state: directory
    owner: root
    group: docker
    mode: '0750'

- name: Copier docker-compose.yml
  template:
    src: docker-compose.yml.j2
    dest: /opt/pangolin/docker-compose.yml
    owner: root
    group: docker
    mode: '0640'

- name: Copier la configuration Pangolin
  template:
    src: config.yml.j2
    dest: /opt/pangolin/config/config.yml
    owner: root
    group: docker
    mode: '0640'
  notify: restart pangolin

- name: Démarrer la stack Pangolin
  community.docker.docker_compose_v2:
    project_src: /opt/pangolin
    state: present
    pull: policy

- name: Configurer le bouncer CrowdSec
  command: >
    docker exec crowdsec cscli bouncers add traefik-bouncer
    --key {{ crowdsec_bouncer_key }}
  register: bouncer_result
  changed_when: bouncer_result.rc == 0
  failed_when: false

Troubleshooting et problèmes courants

Le diagnostic des problèmes dans une stack Pangolin requiert une compréhension du flux de trafic et des interactions entre les composants. Les problèmes les plus fréquemment rencontrés concernent la connectivité WireGuard, la résolution DNS, la gestion des certificats TLS et les conflits de ports réseau. Une approche méthodique de troubleshooting consiste à vérifier chaque composant dans l'ordre du flux de trafic, en commençant par la résolution DNS, puis la connectivité Traefik, le routage vers Gerbil, et enfin la connectivité tunnel vers le service interne.

Problèmes de tunnel WireGuard

Le problème le plus fréquent est l'impossibilité d'établir le tunnel WireGuard. Les causes courantes incluent : le port UDP 51820 bloqué par le pare-feu du serveur ou par l'ISP du client, une incompatibilité de clés (clé publique du serveur incorrectement configurée côté client), une configuration NAT traversal défaillante (résolu en ajustant le persistent_keepalive), ou un conflit d'adresses IP dans le sous-réseau WireGuard. La commande wg show exécutée dans le conteneur Gerbil fournit des informations essentielles : les peers connectés, le dernier handshake, les données transférées et les adresses IP attribuées. L'absence de latest handshake pour un peer indique que la connexion n'a jamais été établie, tandis qu'un handshake datant de plus de 2 minutes suggère une perte de connectivité.

Problèmes de certificats TLS

Les erreurs de certificat TLS sont généralement liées à la configuration du resolver ACME dans Traefik. Les causes les plus courantes sont : un enregistrement DNS inexistant ou incorrect pour le domaine demandé, le port 80 bloqué (nécessaire pour le challenge HTTP-01), une limite de taux atteinte chez Let's Encrypt (5 certificats par domaine par semaine), ou des permissions incorrectes sur le fichier acme.json. Les logs de Traefik contiennent les détails des erreurs ACME et permettent un diagnostic précis. Pour les environnements multi-domaines, le passage au challenge DNS-01 via un fournisseur DNS supporté (Cloudflare, Route53, OVH) élimine la dépendance au port 80 et permet l'obtention de certificats wildcard.

Problèmes de performance

Une dégradation des performances peut être causée par plusieurs facteurs : un MTU WireGuard trop élevé provoquant une fragmentation des paquets (réduire à 1280 si nécessaire), une saturation de la bande passante du tunnel, un nombre excessif de middlewares Traefik créant un overhead par requête, ou une saturation des ressources système du serveur. L'analyse des métriques Prometheus et des logs d'accès Traefik permet d'identifier le goulot d'étranglement. Pour les problèmes de throughput WireGuard, le test avec iperf3 à travers le tunnel fournit une mesure objective de la bande passante disponible.

Évolutions futures et feuille de route

Le projet Pangolin est en développement actif et sa feuille de route inclut plusieurs améliorations significatives. L'ajout d'un support natif pour le load balancing multi-tunnels permettra de distribuer le trafic entre plusieurs agents Gerbil pour la haute disponibilité et la répartition de charge géographique. L'intégration d'un système d'authentification SSO via OIDC/SAML ajoutera une couche d'authentification centralisée devant les services exposés, comparable à ce que propose Authelia ou Authentik. Le support des protocoles TCP et UDP bruts (au-delà du HTTP/HTTPS) étendra les cas d'usage à des services comme les bases de données, les serveurs de jeux ou les services de voix sur IP. Enfin, l'amélioration du dashboard avec des fonctionnalités de monitoring en temps réel, de gestion des alertes et de visualisation du trafic réduira la dépendance aux outils de monitoring externes.

La communauté Pangolin travaille également sur l'amélioration de la documentation, la création de guides de migration depuis d'autres solutions (notamment Cloudflare Tunnel et frp), et le développement de plugins pour étendre les fonctionnalités de la plateforme. L'objectif à terme est de proposer une solution de tunneling et de reverse proxy qui rivalise en facilité d'utilisation avec les solutions cloud tout en maintenant les avantages du self-hosting en termes de souveraineté et de contrôle.

Intégration dans une architecture Zero Trust

Pangolin s'inscrit naturellement dans une architecture Zero Trust où aucun réseau n'est considéré comme sûr par défaut. Le tunnel WireGuard assure l'authentification cryptographique mutuelle entre le serveur et les agents, les middlewares Traefik permettent d'ajouter des couches d'authentification supplémentaires (OAuth2, mTLS, API keys) devant chaque service, et CrowdSec fournit une évaluation continue de la réputation des clients. Cette combinaison implémente les trois piliers du Zero Trust : vérification explicite de chaque accès, application du moindre privilège via des middlewares granulaires, et hypothèse de compromission via la protection proactive de CrowdSec. Pour les organisations engagées dans une démarche Zero Trust, Pangolin constitue une brique d'infrastructure complémentaire aux solutions de gestion des identités (IAM) et de contrôle d'accès réseau (NAC), permettant de sécuriser les flux applicatifs avec une granularité que les solutions réseau traditionnelles ne peuvent atteindre. Cette approche complète les stratégies de protection contre les attaques supply chain en ajoutant des contrôles d'accès stricts aux services exposés.

Bonnes pratiques de production

Le passage d'un déploiement de test à un déploiement de production Pangolin implique l'application de plusieurs bonnes pratiques qui garantissent la résilience, la sécurité et la maintenabilité de l'infrastructure à long terme. Ces recommandations sont le fruit de retours d'expérience de la communauté et des meilleures pratiques de l'industrie en matière d'exploitation d'infrastructure containerisée.

Gestion multi-utilisateurs et RBAC

Dans les environnements où plusieurs équipes ou utilisateurs partagent une instance Pangolin, la gestion fine des accès devient essentielle. Pangolin propose un système de gestion des utilisateurs via son dashboard et son API, permettant de définir des rôles et des permissions par site et par ressource. Un administrateur global dispose d'un accès complet à la configuration de la stack, tandis qu'un utilisateur standard peut être limité à la gestion de ses propres tunnels et services. Cette séparation des privilèges est particulièrement importante dans les contextes d'hébergement partagé ou les MSP (Managed Service Providers) qui gèrent l'infrastructure de plusieurs clients sur une même instance Pangolin. La configuration RBAC s'effectue via le fichier de configuration YAML ou via l'API REST, avec une granularité suffisante pour implémenter le principe du moindre privilège à chaque niveau.

Migration depuis Cloudflare Tunnel

La migration depuis Cloudflare Tunnel vers Pangolin est un scénario de plus en plus fréquent, motivé par des préoccupations de souveraineté des données, de coûts (Cloudflare Tunnel gratuit impose des limitations croissantes) ou de besoin de personnalisation avancée. Le processus de migration se décompose en plusieurs étapes : inventaire des tunnels et des services exposés via Cloudflare, déploiement de la stack Pangolin sur un VPS, recréation des tunnels et des règles de routage, test de chaque service via Pangolin en parallèle de Cloudflare Tunnel, basculement du DNS et désactivation de Cloudflare Tunnel. La migration peut être réalisée sans interruption de service en utilisant une approche de basculement DNS progressif, où le TTL DNS est d'abord réduit à une valeur minimale, puis les enregistrements sont modifiés pour pointer vers le serveur Pangolin, et enfin le TTL est restauré à sa valeur normale après validation du bon fonctionnement.

Questions fréquentes sur Pangolin

Pangolin est-il adapté à un usage en production pour des services critiques ?

Pangolin est parfaitement adapté à un usage en production, à condition de suivre les bonnes pratiques de déploiement : haute disponibilité du serveur VPS, monitoring actif, sauvegardes automatisées et plan de reprise documenté. La fiabilité de la stack repose sur des composants éprouvés individuellement — Traefik, WireGuard et CrowdSec sont chacun utilisés en production par des milliers d'organisations. Le principal risque est le point de défaillance unique que représente le serveur Pangolin lui-même, qui peut être mitigé par un déploiement multi-instances avec basculement DNS automatique. Pour les services véritablement critiques nécessitant un SLA de 99,99%, un déploiement en cluster avec load balancing est recommandé.

Quelle est la différence entre Pangolin et un VPN traditionnel ?

Un VPN traditionnel (OpenVPN, IPsec) crée une connectivité réseau complète entre deux sites, permettant à tout appareil sur l'un des réseaux d'accéder à n'importe quel service sur l'autre réseau. Pangolin, en revanche, adopte une approche plus granulaire en exposant des services spécifiques via un tunnel, avec un contrôle fin du routage et de l'authentification par service. Un VPN est adapté quand une connectivité réseau complète est nécessaire (accès distant aux postes de travail, partage de fichiers), tandis que Pangolin est préférable quand l'objectif est d'exposer des services web spécifiques avec un contrôle de sécurité avancé. Les deux approches sont complémentaires et peuvent coexister dans la même infrastructure.

Comment Pangolin gère-t-il les mises à jour et la maintenance ?

Les mises à jour de Pangolin s'effectuent via Docker Compose en tirant les nouvelles images des conteneurs. La procédure recommandée est de sauvegarder les données et la configuration, de modifier les tags de version dans le fichier docker-compose.yml, de tirer les nouvelles images avec docker compose pull, puis de redémarrer la stack avec docker compose up -d. Les données persistantes (configuration, base CrowdSec, certificats TLS) sont conservées dans des volumes montés, garantissant la continuité après la mise à jour. Il est fortement recommandé de tester les mises à jour dans un environnement de staging avant le déploiement en production, et de consulter les notes de version pour identifier les éventuels changements incompatibles.

Pangolin supporte-t-il le trafic TCP et UDP brut ?

Dans sa version actuelle, Pangolin est principalement conçu pour le trafic HTTP et HTTPS, car Traefik est optimisé pour le reverse proxy de couche applicative (L7). Cependant, le tunnel WireGuard sous-jacent (Gerbil) transporte n'importe quel type de trafic IP. Pour les services TCP/UDP non-HTTP (bases de données, serveurs de jeux, services SSH), il est possible de configurer Traefik en mode TCP passthrough ou d'utiliser directement le tunnel WireGuard avec des règles de routage manuelles via iptables/nftables côté serveur. Cette limitation devrait être levée dans les futures versions de Pangolin avec le support natif du proxy TCP/UDP via le dashboard.

Quelle bande passante peut-on atteindre via un tunnel Pangolin ?

La bande passante maximale à travers un tunnel Pangolin dépend principalement de trois facteurs : la bande passante Internet disponible aux deux extrémités du tunnel, la puissance de calcul du processeur pour le chiffrement WireGuard (négligeable sur les CPU modernes grâce aux instructions AES-NI et aux optimisations noyau), et la latence réseau entre le serveur Pangolin et le réseau client. En pratique, WireGuard atteint des throughputs de 800 à 900 Mbps sur des connexions gigabit avec un CPU moderne, ce qui est largement suffisant pour la majorité des cas d'usage web. La latence ajoutée par le tunnel est typiquement de 2 à 8 millisecondes, principalement due à l'encapsulation et au chiffrement WireGuard.

Comment sécuriser le dashboard Pangolin ?

Le dashboard Pangolin doit être protégé par plusieurs mesures de sécurité : un mot de passe fort avec hachage Argon2id, une restriction d'accès par IP source (via un middleware Traefik ipWhiteList), l'activation de l'authentification à deux facteurs (2FA) si disponible, et idéalement, l'accès au dashboard exclusivement via le tunnel WireGuard (sans exposition publique). Pour les déploiements les plus sensibles, il est recommandé de désactiver complètement le dashboard web et de gérer la configuration exclusivement via les fichiers YAML et l'API REST, cette dernière étant protégée par une authentification par token.

Pangolin peut-il remplacer entièrement Cloudflare ?

Pangolin peut remplacer les fonctionnalités de tunneling et de reverse proxy de Cloudflare, mais ne remplace pas l'ensemble des services Cloudflare. Le CDN mondial, la protection DDoS volumétrique de couche 3/4, le WAF avancé avec règles managées, et les services DNS de Cloudflare ne sont pas directement répliqués par Pangolin. Pour la protection DDoS volumétrique, un service spécialisé en amont (OVH Anti-DDoS, Voxility, Path.net) peut être nécessaire. Pour le WAF, CrowdSec fournit une protection solide mais moins exhaustive que le WAF Cloudflare. La décision de migrer doit prendre en compte l'ensemble des services Cloudflare utilisés et identifier les alternatives pour chacun.

Comment gérer la haute disponibilité avec Pangolin ?

La haute disponibilité de Pangolin peut être atteinte par plusieurs approches complémentaires. Au niveau le plus simple, un DNS failover (via des services comme UptimeRobot ou Healthchecks.io) peut basculer automatiquement le trafic vers une instance Pangolin de secours en cas de défaillance de l'instance principale. Pour une approche plus sophistiquée, deux instances Pangolin peuvent être déployées derrière un load balancer externe (HAProxy, keepalived avec IP flottante), avec une synchronisation de la configuration via un dépôt Git partagé et une réplication de la base CrowdSec. Côté client, plusieurs agents Gerbil peuvent être configurés pour se connecter à différentes instances Pangolin, avec un basculement automatique en cas de perte du tunnel principal.

Conclusion et recommandations

Pangolin représente une évolution significative dans le paysage des solutions de reverse proxy et de tunneling self-hosted. En combinant la puissance de Traefik, la sécurité de WireGuard via Gerbil et la protection collaborative de CrowdSec, Pangolin offre une alternative crédible aux services cloud pour l'exposition sécurisée de services internes. La plateforme s'adresse aux administrateurs et aux organisations qui valorisent la souveraineté numérique, le contrôle total sur le chiffrement et le routage du trafic, et la transparence du traitement des données. Si la complexité initiale de déploiement est supérieure à celle de solutions cloud comme Cloudflare Tunnel, les bénéfices en termes de contrôle, de personnalisation et d'indépendance justifient largement l'investissement pour les cas d'usage appropriés. L'écosystème Pangolin est en pleine expansion, et les améliorations prévues — notamment le support TCP/UDP natif, l'authentification SSO intégrée et le load balancing multi-tunnels — devraient renforcer sa position comme solution de référence pour le tunneling et le reverse proxy self-hosted. Pour les professionnels de la cybersécurité, la maîtrise de Pangolin constitue une compétence précieuse, complémentaire aux connaissances en scanning de vulnérabilités et en gestion d'infrastructure sécurisée.

Comprendre le protocole WireGuard dans le contexte de Pangolin

Pour saisir pleinement les avantages de Pangolin, il est indispensable de comprendre les mécanismes internes du protocole WireGuard qui constitue la fondation de la couche de tunneling Gerbil. Contrairement à IPsec qui implémente un ensemble complexe de protocoles (IKEv2 pour la négociation, ESP pour le transport, AH pour l'authentification), WireGuard adopte une approche radicalement minimaliste. Le protocole utilise le Noise Protocol Framework, spécifiquement le pattern IK (Initiator Knows), pour l'établissement de la connexion. Ce pattern suppose que l'initiateur connaît déjà la clé publique du répondeur, ce qui élimine la nécessité d'un mécanisme de découverte de clés ou d'une infrastructure PKI. Dans le contexte de Pangolin, cette distribution de clés est gérée par le composant Gerbil qui s'occupe automatiquement de la configuration des peers lors de la création d'un nouveau tunnel via le dashboard.

Le handshake WireGuard s'effectue en un seul aller-retour (1-RTT), ce qui est significativement plus rapide que les 2 à 4 allers-retours nécessaires pour un handshake IKEv2 typique. Pendant ce handshake, les deux parties établissent un secret partagé via un échange Diffie-Hellman sur Curve25519, authentifient mutuellement leurs identités via leurs clés statiques, et dérivent les clés de session symétriques utilisées pour le chiffrement des données. Les clés de session sont automatiquement renouvelées toutes les deux minutes ou après le transfert de 2^64 - 1 paquets, garantissant la perfect forward secrecy — la compromission de la clé privée statique d'un nœud ne permet pas de déchiffrer les communications passées. Cette propriété est fondamentale pour la sécurité à long terme des tunnels Pangolin, car elle protège contre les attaques de type « store now, decrypt later » qui visent à collecter du trafic chiffré en attendant de disposer de la puissance de calcul nécessaire pour casser le chiffrement.

Un aspect technique souvent méconnu de WireGuard dans le contexte de Pangolin est la gestion des roaming et des changements d'adresse IP. WireGuard identifie les peers par leur clé publique, pas par leur adresse IP. Cela signifie qu'un agent Gerbil client peut changer d'adresse IP (passage du Wi-Fi au 4G, changement de réseau, redémarrage du routeur) sans interrompre le tunnel. Le serveur Pangolin met automatiquement à jour l'endpoint du peer lors de la réception du prochain paquet valide, assurant une continuité de service transparente. Cette résilience au changement d'adresse est particulièrement précieuse pour les cas d'usage nomades, comme les équipes de développement qui travaillent depuis différents emplacements ou les services déployés sur des machines avec des IP dynamiques.

La performance de WireGuard dans Pangolin bénéficie de l'implémentation kernel-space disponible sur Linux. Contrairement à OpenVPN qui opère en userspace et nécessite des copies de paquets entre le noyau et l'espace utilisateur (context switching), WireGuard traite les paquets directement dans le noyau Linux, éliminant les coûts de copie et de commutation de contexte. Les benchmarks montrent des throughputs de 800 à 950 Mbps sur des connexions gigabit avec un processeur moderne, avec une utilisation CPU inférieure à 5%. Sur les architectures ARM (Raspberry Pi 4, serveurs ARM cloud comme les instances AWS Graviton), WireGuard maintient des performances excellentes grâce à l'optimisation de ChaCha20-Poly1305 pour les processeurs sans accélération matérielle AES. Cette efficacité signifie que même un VPS d'entrée de gamme (2 vCPU, 2 Go RAM) peut servir de serveur Pangolin pour plusieurs dizaines de tunnels simultanés sans dégradation de performance notable.

Gestion des certificats TLS et ACME dans Pangolin

La gestion automatisée des certificats TLS est l'une des fonctionnalités les plus appréciées de Pangolin, éliminant la charge opérationnelle liée au renouvellement manuel des certificats. Pangolin s'appuie sur le reverse proxy Traefik et le protocole ACME (Automatic Certificate Management Environment) pour interagir avec Let's Encrypt et obtenir des certificats TLS valides automatiquement. Le processus se déroule en plusieurs étapes : lorsqu'un nouveau service est exposé via Pangolin avec un nom de domaine, Traefik détecte la demande de certificat, soumet un challenge ACME au serveur Let's Encrypt, prouve la propriété du domaine via le challenge HTTP-01 (en servant un token sur le port 80) ou le challenge DNS-01 (en créant un enregistrement TXT dans la zone DNS), et stocke le certificat obtenu dans le fichier acme.json. Le renouvellement s'effectue automatiquement 30 jours avant l'expiration du certificat, sans intervention manuelle.

Pour les déploiements nécessitant des certificats wildcard (par exemple, *.example.com), le challenge DNS-01 est obligatoire. Traefik supporte de nombreux fournisseurs DNS via ses providers ACME : Cloudflare, Amazon Route 53, Google Cloud DNS, OVH, DigitalOcean, Hetzner, Gandi, et bien d'autres. La configuration du challenge DNS-01 nécessite de fournir des credentials API du fournisseur DNS, qui doivent être stockées de manière sécurisée (variables d'environnement ou secrets Docker). Un avantage significatif du challenge DNS-01 est qu'il ne nécessite pas que le port 80 soit accessible depuis Internet, ce qui permet d'obtenir des certificats même dans les configurations où seul le port 443 est ouvert. Cette flexibilité est particulièrement utile pour les déploiements Pangolin où la réduction de la surface d'attaque impose de fermer le port 80 après l'obtention initiale des certificats.

# Configuration du challenge DNS-01 avec Cloudflare
# docker-compose.yml - section traefik environment
environment:
  - CF_DNS_API_TOKEN=your-cloudflare-api-token
  - CF_ZONE_API_TOKEN=your-cloudflare-zone-token

# traefik command additions
- "--certificatesresolvers.letsencrypt.acme.dnschallenge=true"
- "--certificatesresolvers.letsencrypt.acme.dnschallenge.provider=cloudflare"
- "--certificatesresolvers.letsencrypt.acme.dnschallenge.resolvers=1.1.1.1:53,8.8.8.8:53"

# Pour les certificats wildcard
# traefik/dynamic/wildcard.yml
tls:
  certificates:
    - certFile: /letsencrypt/wildcard.crt
      keyFile: /letsencrypt/wildcard.key
  stores:
    default:
      defaultCertificate:
        certFile: /letsencrypt/wildcard.crt
        keyFile: /letsencrypt/wildcard.key

Un point de sécurité important concerne le fichier acme.json qui contient les clés privées de tous les certificats gérés par Traefik. Ce fichier doit être protégé avec des permissions strictes (chmod 600) et ne doit jamais être exposé publiquement ou commité dans un dépôt de code. Pour les déploiements en cluster ou en haute disponibilité, le stockage des certificats doit être partagé entre les instances Traefik via un backend distribué (Consul, etcd, Redis) ou un système de fichiers partagé (NFS, EFS). La sauvegarde régulière de ce fichier est également importante : en cas de perte, Traefik devra réobtenir tous les certificats, ce qui peut être bloqué par les limites de taux de Let's Encrypt (5 certificats par domaine par semaine en production).

CrowdSec en profondeur : scénarios et bouncers

L'intégration de CrowdSec dans Pangolin mérite une attention approfondie car elle constitue la principale ligne de défense applicative de la stack. CrowdSec adopte un modèle de sécurité comportemental et collaboratif qui se distingue fondamentalement des WAF basés sur des signatures. Le moteur d'analyse de CrowdSec (le « local API » ou LAPI) ingère des sources de logs (Traefik access logs, syslogs, auth logs) et les analyse via des parsers (qui structurent les logs bruts) et des scénarios (qui définissent les comportements malveillants à détecter). Lorsqu'un scénario est déclenché, une décision est créée (ban, captcha, throttle) et appliquée par les bouncers déployés devant les services protégés.

La dimension collaborative de CrowdSec est son différenciateur principal. Lorsqu'une IP est identifiée comme malveillante par une instance CrowdSec, cette information est partagée (de manière anonymisée) avec la Central API (CAPI) gérée par CrowdSec. Les décisions validées par plusieurs instances indépendantes sont agrégées dans une liste de réputation communautaire qui est redistribuée à l'ensemble des participants. Un déploiement Pangolin avec CrowdSec activé bénéficie ainsi de l'intelligence collective de dizaines de milliers d'installations, recevant des décisions de blocage pour des IP malveillantes avant même qu'elles n'aient ciblé l'infrastructure protégée. Ce modèle est analogue aux systèmes de réputation email (Spamhaus, SpamCop) mais appliqué à la couche HTTP/HTTPS.

# Installation de scénarios CrowdSec supplémentaires pour Pangolin
docker exec crowdsec cscli collections install crowdsecurity/traefik
docker exec crowdsec cscli collections install crowdsecurity/http-cve
docker exec crowdsec cscli collections install crowdsecurity/base-http-scenarios
docker exec crowdsec cscli collections install crowdsecurity/whitelist-good-actors
docker exec crowdsec cscli collections install crowdsecurity/sshd  # Si SSH exposé

# Vérification des scénarios installés
docker exec crowdsec cscli scenarios list

# Consultation des décisions actives
docker exec crowdsec cscli decisions list

# Ajout manuel d'une décision (ban d'une IP)
docker exec crowdsec cscli decisions add --ip 192.0.2.1 --duration 24h --reason "Manual ban"

# Consultation des métriques
docker exec crowdsec cscli metrics

# Whitelist d'une IP (éviter les faux positifs)
docker exec crowdsec cscli parsers install crowdsecurity/whitelists
# Éditer /etc/crowdsec/parsers/s02-enrich/whitelist.yaml

Les scénarios de détection les plus pertinents pour un déploiement Pangolin incluent : crowdsecurity/http-bad-user-agent qui détecte les scanners automatisés et les bots malveillants par leur User-Agent ; crowdsecurity/http-probing qui identifie les tentatives de découverte de fichiers sensibles (.env, .git, wp-admin) ; crowdsecurity/http-sensitive-files qui bloque l'accès aux fichiers de configuration exposés accidentellement ; crowdsecurity/http-xss-probing qui détecte les tentatives d'injection XSS ; crowdsecurity/http-path-traversal-probing qui bloque les tentatives de traversée de répertoire ; et les scénarios CVE spécifiques qui détectent l'exploitation de vulnérabilités connues (Log4Shell, Spring4Shell, etc.). La création de scénarios personnalisés est également possible pour détecter des comportements spécifiques aux services exposés via Pangolin.

Le bouncer Traefik de CrowdSec s'intègre comme un middleware HTTP dans la chaîne de traitement de Traefik. Pour chaque requête entrante, le bouncer consulte le LAPI pour vérifier si l'adresse IP source fait l'objet d'une décision active. Cette consultation est optimisée par un mécanisme de cache local qui évite de requêter le LAPI pour chaque requête, réduisant l'overhead à moins d'une milliseconde par requête. Les décisions supportées par le bouncer incluent le ban (réponse 403 Forbidden), le captcha (redirection vers une page de validation CAPTCHA avant d'autoriser l'accès) et le throttle (limitation du débit de requêtes pour l'IP concernée). Le mode captcha est particulièrement utile pour les faux positifs potentiels : plutôt que de bloquer complètement un utilisateur légitime, le captcha permet de distinguer les humains des bots automatisés.

Stratégies de logging et de rétention des données

Un déploiement Pangolin en production génère un volume significatif de logs provenant de multiples sources : les access logs de Traefik (chaque requête HTTP/HTTPS), les logs d'erreur de Traefik (problèmes de configuration, erreurs de backend), les logs CrowdSec (détections, décisions, métriques), les logs WireGuard de Gerbil (établissement et perte de tunnels, handshakes), et les logs du dashboard Pangolin (authentification, modifications de configuration). La gestion efficace de ces logs est cruciale tant pour le diagnostic opérationnel que pour la conformité réglementaire et l'investigation de sécurité.

La configuration de la rotation des logs Docker est la première étape pour éviter la saturation du stockage. Par défaut, Docker ne limite pas la taille des logs de conteneurs, ce qui peut rapidement consommer des dizaines de gigaoctets sur un serveur actif. La configuration du pilote de log JSON avec rotation automatique doit être appliquée globalement dans la configuration Docker daemon ou spécifiquement pour chaque conteneur dans le fichier docker-compose.yml.

# /etc/docker/daemon.json — Configuration globale des logs Docker
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "5",
    "compress": "true"
  }
}

# OU par conteneur dans docker-compose.yml
services:
  traefik:
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "10"
        compress: "true"

Pour les environnements nécessitant une rétention à long terme des logs d'accès (conformité PCI-DSS : 1 an, certaines réglementations sectorielles : 3 à 5 ans), l'export vers un système de log management externe est indispensable. Les solutions couramment utilisées incluent la stack ELK (Elasticsearch, Logstash, Kibana), Loki (solution de log management native cloud de Grafana Labs), Graylog, ou des services SaaS comme Datadog, Splunk Cloud ou Grafana Cloud. L'intégration avec Loki est particulièrement adaptée aux déploiements Pangolin car Loki consomme peu de ressources et s'intègre nativement avec Grafana pour la visualisation et l'alerting.

Optimisation des performances réseau

L'optimisation des performances d'un déploiement Pangolin nécessite une attention particulière à plusieurs paramètres réseau et système qui peuvent avoir un impact significatif sur le throughput et la latence. Le paramètre le plus critique est le MTU (Maximum Transmission Unit) du tunnel WireGuard. Par défaut, WireGuard utilise un MTU de 1420 octets (1500 octets Ethernet standard moins 80 octets d'overhead WireGuard). Si le chemin réseau entre le serveur Pangolin et l'agent Gerbil client a un MTU inférieur à 1500 (ce qui est courant avec PPPoE, certains VPS et les connexions 4G/5G), les paquets WireGuard seront fragmentés, entraînant une dégradation significative des performances. La détection et la correction du MTU optimal s'effectuent via un test de fragmentation.

# Détection du MTU optimal entre le client et le serveur
# Depuis le client, tester avec ping et l'option "don't fragment"
ping -M do -s 1392 server-pangolin-ip   # MTU WireGuard = 1392 + 28 (IP+ICMP) = 1420
ping -M do -s 1372 server-pangolin-ip   # Si 1392 échoue, essayer 1372 (MTU 1400)
ping -M do -s 1252 server-pangolin-ip   # Pour PPPoE (MTU 1280)

# Ajuster le MTU dans la configuration Gerbil
# config/config.yml
gerbil:
  wireguard:
    mtu: 1380  # Valeur réduite pour compatibilité maximale

# Optimisations réseau au niveau du système hôte
# Augmenter les buffers réseau
echo "net.core.rmem_max = 16777216" | sudo tee -a /etc/sysctl.conf
echo "net.core.wmem_max = 16777216" | sudo tee -a /etc/sysctl.conf
echo "net.core.rmem_default = 1048576" | sudo tee -a /etc/sysctl.conf
echo "net.core.wmem_default = 1048576" | sudo tee -a /etc/sysctl.conf

# Optimiser le stack TCP
echo "net.ipv4.tcp_rmem = 4096 1048576 16777216" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_wmem = 4096 1048576 16777216" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control = bbr" | sudo tee -a /etc/sysctl.conf

# Appliquer
sudo sysctl -p

Au-delà du MTU, plusieurs paramètres système influencent les performances de Pangolin. L'activation de l'algorithme de congestion TCP BBR (Bottleneck Bandwidth and Round-trip propagation time) améliore significativement les performances sur les connexions à haute latence ou à perte de paquets, ce qui est courant pour le trafic transitant via le tunnel WireGuard. L'augmentation des buffers réseau du noyau permet d'absorber les pics de trafic sans perte de paquets. La désactivation de la fragmentation IP au niveau du tunnel (via l'ajustement du MTU) évite le coût de la réassemblage des paquets. Enfin, pour les serveurs Pangolin qui gèrent un grand nombre de tunnels simultanés, l'augmentation des limites de descripteurs de fichiers (ulimit -n) et des connexions suivies par le conntrack (nf_conntrack_max) peut être nécessaire pour éviter les drops de connexion sous charge.

La compression du trafic est un autre levier d'optimisation, particulièrement pour les services qui transmettent des données compressibles (HTML, JSON, texte). La configuration de la compression GZIP au niveau du middleware Traefik réduit la quantité de données transitant par le tunnel WireGuard, améliorant à la fois la latence perçue et le throughput effectif. Cependant, la compression doit être désactivée pour les contenus déjà compressés (images, vidéos, archives) pour éviter un overhead CPU inutile. La configuration Traefik permet un contrôle granulaire des types de contenu compressés et du niveau de compression.

Sécurité des conteneurs Docker dans Pangolin

La sécurité des conteneurs Docker constitue un aspect souvent négligé du hardening d'un déploiement Pangolin. Le montage du socket Docker (/var/run/docker.sock) dans le conteneur Traefik représente un risque de sécurité significatif : un attaquant qui compromettrait le conteneur Traefik pourrait potentiellement prendre le contrôle de l'ensemble de l'hôte Docker via le socket. Plusieurs mesures atténuent ce risque. Le montage en lecture seule (:ro) limite les opérations possibles via le socket. L'utilisation d'un socket proxy comme tecnativa/docker-socket-proxy restreint les API Docker accessibles au strict nécessaire (seules les API de lecture des labels et des conteneurs sont nécessaires pour Traefik). L'exécution des conteneurs avec des utilisateurs non-root (directive user: dans docker-compose.yml) limite l'impact d'une évasion de conteneur. L'application de seccomp profiles et d'AppArmor profiles restreint les appels système disponibles dans chaque conteneur.

# Utilisation d'un socket proxy Docker pour Traefik
services:
  docker-socket-proxy:
    image: tecnativa/docker-socket-proxy
    container_name: docker-socket-proxy
    restart: unless-stopped
    environment:
      - CONTAINERS=1      # Autoriser la lecture des conteneurs
      - SERVICES=0
      - TASKS=0
      - NETWORKS=0
      - VOLUMES=0
      - POST=0            # Interdire les opérations d'écriture
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - docker-proxy

  traefik:
    # ... configuration existante ...
    # Remplacer le montage direct du socket par le proxy
    # volumes:
    #   - /var/run/docker.sock:/var/run/docker.sock:ro  # SUPPRIMER
    environment:
      - DOCKER_HOST=tcp://docker-socket-proxy:2375
    depends_on:
      - docker-socket-proxy
    networks:
      - pangolin-net
      - docker-proxy

networks:
  docker-proxy:
    driver: bridge
    internal: true  # Réseau isolé, pas d'accès Internet

L'analyse de vulnérabilités des images Docker utilisées par Pangolin est une pratique de sécurité essentielle. Des outils comme Trivy (d'Aqua Security), Grype (d'Anchore), ou Docker Scout permettent de scanner les images pour détecter des vulnérabilités connues dans les packages système et les dépendances. Un scan régulier (hebdomadaire) des images Pangolin avec alerte sur les vulnérabilités critiques (CVSS >= 9.0) doit être intégré dans le cycle de maintenance. La mise à jour des images vers les dernières versions de correctifs est la méthode la plus fiable pour remédier aux vulnérabilités détectées.

Déploiement multi-régions et géo-distribution

Pour les organisations nécessitant une faible latence pour des utilisateurs répartis géographiquement, un déploiement multi-régions de Pangolin offre une solution performante. L'architecture consiste à déployer une instance Pangolin complète dans chaque région cible (par exemple, Europe, Amérique du Nord, Asie-Pacifique), chacune avec son propre serveur Traefik, Gerbil et CrowdSec. Un système de DNS géographique (comme Route 53 Geolocation Routing d'AWS, ou le routage géographique de Cloudflare DNS) dirige les utilisateurs vers l'instance Pangolin la plus proche. Les agents Gerbil des services internes peuvent se connecter à plusieurs instances Pangolin simultanément ou à l'instance la plus proche pour optimiser la latence du tunnel.

La synchronisation de la configuration entre les instances multi-régions peut être gérée via un dépôt Git centralisé contenant l'ensemble des fichiers de configuration (docker-compose.yml, configuration Traefik, règles CrowdSec, politique ACL) et un pipeline CI/CD qui déploie automatiquement les modifications sur toutes les instances. Cette approche Infrastructure as Code garantit la cohérence de la configuration entre les régions et facilite le rollback en cas de problème. La base de données CrowdSec n'a pas besoin d'être synchronisée entre les régions car la Central API assure la distribution des décisions communautaires, et les décisions locales sont spécifiques au trafic reçu par chaque instance.

Intégration avec les solutions de monitoring existantes

L'intégration de Pangolin dans un écosystème de monitoring existant nécessite la collecte et la corrélation de métriques, de logs et de traces provenant de chaque composant de la stack. Au-delà des métriques Prometheus de Traefik déjà mentionnées, CrowdSec expose des métriques détaillées sur les détections, les décisions et les performances du moteur d'analyse. Gerbil fournit des métriques WireGuard sur l'état des tunnels, le volume de données transféré et les handshakes. L'agrégation de ces métriques dans un dashboard Grafana unifié offre une visibilité complète sur la santé et les performances de l'infrastructure Pangolin.

# Dashboard Grafana — Panels recommandés pour Pangolin
# 1. Traefik
# - Requêtes par seconde (total et par service)
# - Latence P50/P95/P99 par service
# - Taux d'erreurs (4xx, 5xx) par service
# - Certificats TLS : jours restants avant expiration
# - Connexions actives

# 2. CrowdSec
# - Détections par scénario (timeline)
# - Top 10 IP bloquées
# - Décisions actives (ban, captcha, throttle)
# - Trafic bloqué vs autorisé (ratio)
# - Origine géographique des attaques (carte)

# 3. WireGuard / Gerbil
# - Tunnels actifs vs configurés
# - Dernier handshake par tunnel
# - Données transférées par tunnel (in/out)
# - Latence par tunnel (RTT)

# 4. Système
# - CPU, RAM, disque, réseau de l'hôte
# - Ressources Docker par conteneur
# - Nombre de connexions réseau (conntrack)

# Exemple de requête PromQL pour le taux d'erreurs Traefik
# rate(traefik_service_requests_total{code=~"5.."}[5m])
# / rate(traefik_service_requests_total[5m]) * 100

Les alertes critiques doivent être configurées pour les événements suivants avec des seuils adaptés à chaque déploiement : taux d'erreurs HTTP 5xx supérieur à 5% sur une fenêtre de 5 minutes (indicateur de défaillance d'un backend), latence P99 supérieure à 5 secondes (dégradation de performance), perte de connectivité d'un tunnel WireGuard pendant plus de 2 minutes (panne de service potentielle), certificat TLS expirant dans moins de 14 jours (risque d'indisponibilité), nombre de décisions CrowdSec dépassant un seuil anormal (attaque en cours), et utilisation des ressources système approchant les limites (CPU > 80%, RAM > 85%, disque > 90%). L'intégration de ces alertes avec des canaux de notification adaptés (Slack pour les alertes opérationnelles, PagerDuty pour les alertes critiques hors heures) garantit une réactivité optimale de l'équipe d'exploitation.

Gestion des mises à jour et cycle de maintenance

La maintenance régulière d'un déploiement Pangolin est essentielle pour la sécurité et la fiabilité à long terme. Le cycle de maintenance recommandé comprend des mises à jour hebdomadaires des images Docker pour les correctifs de sécurité, des mises à jour mensuelles pour les nouvelles fonctionnalités mineures, et des mises à jour trimestrielles pour les versions majeures nécessitant potentiellement des changements de configuration. Chaque mise à jour doit suivre un processus structuré : sauvegarde de la configuration et des données, test dans un environnement de staging, mise à jour en production avec monitoring actif, et validation du bon fonctionnement de chaque composant.

# Procédure de mise à jour Pangolin
# 1. Sauvegarde
tar czf /backup/pangolin-$(date +%Y%m%d).tar.gz /opt/pangolin/config /opt/pangolin/data /opt/pangolin/letsencrypt

# 2. Pull des nouvelles images
cd /opt/pangolin
docker compose pull

# 3. Vérification des changements incompatibles
docker compose config --quiet  # Valide la syntaxe

# 4. Mise à jour avec redémarrage graceful
docker compose up -d --remove-orphans

# 5. Vérification post-mise à jour
docker compose ps                        # Tous les conteneurs UP
docker compose logs --tail=50 traefik    # Pas d'erreurs
docker compose logs --tail=50 gerbil     # Tunnels reconnectés
docker compose logs --tail=50 crowdsec   # Scénarios chargés
curl -sI https://service.example.com     # Service accessible

# 6. Rollback si nécessaire
docker compose down
docker compose -f docker-compose.yml.bak up -d

La veille sur les vulnérabilités affectant les composants de Pangolin (Traefik, WireGuard, CrowdSec, images Docker de base) doit être intégrée dans le processus de maintenance. L'abonnement aux listes de diffusion de sécurité de chaque projet, le suivi des CVE via des outils comme Trivy et la consultation régulière des release notes permettent de réagir rapidement aux vulnérabilités critiques. Pour les vulnérabilités de sévérité critique (CVSS >= 9.0) affectant un composant exposé sur Internet, le déploiement d'un correctif dans les 24 heures est recommandé, conformément aux bonnes pratiques de gestion des vulnérabilités documentées dans notre guide sur les scanners de vulnérabilités.

Pangolin et les architectures microservices

L'utilisation de Pangolin dans le contexte des architectures microservices présente des avantages spécifiques qui méritent une analyse approfondie. Dans un environnement de microservices typique, des dizaines voire des centaines de services communiquent entre eux via des API REST ou gRPC. L'exposition de ces services pour le développement, le staging et la production nécessite une gestion fine du routage, de l'authentification et du monitoring. Pangolin excelle dans ce contexte grâce à la flexibilité de Traefik en tant que reverse proxy : chaque microservice peut être exposé sur un sous-domaine ou un chemin spécifique, avec des middlewares personnalisés par service (rate limiting adapté au profil de trafic, authentification spécifique, politique CORS).

La combinaison de Pangolin avec un service mesh comme Istio ou Linkerd est un pattern architectural avancé. Le service mesh gère la communication intra-cluster entre les microservices (mTLS, circuit breaking, observabilité), tandis que Pangolin gère l'exposition externe de services spécifiques via le tunnel WireGuard. Cette séparation des responsabilités permet une défense en profondeur où le service mesh protège les communications est-ouest (entre services) et Pangolin protège les communications nord-sud (Internet vers services internes). L'intégration CrowdSec dans Pangolin ajoute une couche de protection contre les attaques applicatives qui complète les mécanismes de sécurité du service mesh.

Pour les équipes pratiquant le GitOps, la configuration de Pangolin peut être entièrement versionnée et déployée via des pipelines CI/CD. Les fichiers de configuration YAML des sites, des ressources et des middlewares sont stockés dans un dépôt Git, et un pipeline applique les modifications à la stack Pangolin lors de chaque merge sur la branche principale. Cette approche garantit la traçabilité des changements de configuration, le contrôle par revue de code des modifications de routage et de sécurité, et la possibilité de rollback instantané en cas de problème. Les modifications de configuration Traefik sont appliquées sans redémarrage grâce au rechargement dynamique, assurant un déploiement sans interruption de service.

Un cas d'usage particulièrement pertinent est l'exposition de feature environments (environnements éphémères de feature branch). Lorsqu'un développeur crée une pull request, un pipeline CI/CD déploie automatiquement l'ensemble de la stack de microservices dans un environnement éphémère, expose cet environnement via Pangolin avec un sous-domaine dédié (par exemple, pr-123.staging.example.com), et supprime l'environnement et le tunnel lorsque la pull request est fermée. Cette automatisation accélère le cycle de revue de code en permettant aux reviewers et aux testeurs d'accéder directement à l'environnement de la feature branch sans configuration manuelle.

Tests de charge et benchmarking de Pangolin

La validation des performances d'un déploiement Pangolin avant la mise en production est une étape souvent négligée mais cruciale pour garantir que l'infrastructure peut supporter la charge attendue. Les tests de charge doivent couvrir trois dimensions : le throughput du tunnel WireGuard (bande passante maximale entre le serveur Pangolin et l'agent Gerbil client), la capacité de traitement de Traefik (nombre de requêtes par seconde que le reverse proxy peut gérer), et l'overhead de CrowdSec (impact de la vérification des décisions sur la latence des requêtes). Chaque dimension doit être testée indépendamment puis en combinaison pour identifier les goulots d'étranglement potentiels.

# Test de throughput WireGuard
# Sur le serveur Pangolin (côté Gerbil serveur)
iperf3 -s -p 5201

# Depuis l'agent Gerbil client (à travers le tunnel)
iperf3 -c 10.0.0.1 -p 5201 -t 60 -P 4
# Résultat attendu : 800-950 Mbps sur connexion 1 Gbps

# Test de performance Traefik avec wrk
# Depuis une machine externe
wrk -t 12 -c 400 -d 30s https://service.example.com/
# Résultat attendu : 10,000-50,000 req/s selon la configuration

# Test avec vegeta pour un profil de charge contrôlé
echo "GET https://service.example.com/" | vegeta attack -duration=60s -rate=1000 | vegeta report
# Vérifie que le P99 reste sous 100ms à 1000 req/s

# Test de latence CrowdSec avec et sans le bouncer
# 1. Test sans CrowdSec (désactiver temporairement le middleware)
wrk -t 4 -c 100 -d 30s https://service.example.com/ --latency
# 2. Test avec CrowdSec actif
wrk -t 4 -c 100 -d 30s https://service.example.com/ --latency
# Overhead attendu : < 1ms par requête

# Stress test combiné
# Simuler un pic de trafic réaliste avec différents profils
k6 run --vus 200 --duration 5m load-test.js
# Vérifier les métriques Traefik et CrowdSec pendant le test

Les résultats des tests de charge doivent être documentés et servir de baseline pour le monitoring en production. Un dépassement significatif de la baseline (par exemple, une latence P99 doublée) peut indiquer un problème de performance qui nécessite une investigation. Pour les services à fort trafic, les tests de charge doivent inclure des scénarios de dégradation gracieuse : que se passe-t-il lorsque le service backend est lent ? Comment Traefik gère-t-il les timeouts ? CrowdSec détecte-t-il et bloque-t-il correctement les requêtes malveillantes sous charge ? Les réponses à ces questions déterminent la résilience globale de l'infrastructure Pangolin en conditions adverses.

La capacité de scaling vertical et horizontal de Pangolin doit également être évaluée. Le scaling vertical consiste à augmenter les ressources du serveur Pangolin (CPU, RAM, bande passante réseau), ce qui est la méthode la plus simple mais limitée par les capacités maximales de l'instance. Le scaling horizontal implique le déploiement de plusieurs instances Pangolin derrière un load balancer, avec une synchronisation de la configuration via un dépôt Git partagé. Traefik supporte nativement le déploiement en cluster avec synchronisation de l'état via Consul, Redis ou etcd, permettant un load balancing transparent. CrowdSec peut également fonctionner en mode distribué avec un LAPI centralisé et des agents déployés sur chaque instance Traefik. Cette architecture de scaling horizontal est recommandée pour les déploiements traitant plus de 10 000 requêtes par seconde ou gérant plus de 50 tunnels WireGuard simultanés.