Je vous présente mon idée d'infrastructure, j'ai une ip publique avec une vm qui fait office de protection en amont du cluster et de proxy avec haproxy.

Un petit schéma de mon objectif final, dans cet article on ne parlera que de la partie laisons http/https :

Avant de commencer je préviens c'est assez long, je vous conseille en fond sonore un morceau de Dream Theater - A change of Seasons qui dure 25 minutes

 Prérequis

Les prérequis sont les suivants

• cluster kubernetes
• kubectl utilisable
• helm en place

 La configuration HaProxy

Haproxy va recevoir les requêtes sur les ports 80 et 443 et les forwardé niveau TCP à l'IP qui sera affectée par le load balancer. Voir mes articles précédents sur HaProxy.

Configuration d'exemple :

...
frontend kube-http
  bind *:80
  default_backend kube-http-backend

frontend kube-https
  bind *:443
  default_backend kube-https-backend

backend kube-api-backend
  mode tcp
  server cp01 192.168.15.11:6443 check

backend kube-https-backend
  mode tcp
  option tcp-check
  timeout check 2s
  server traefik 192.168.15.100:443 send-proxy-v2 check inter 3s fall 2 rise 2

backend kube-http-backend
    mode tcp
    option tcp-check
    timeout check 2s
    server traefik 192.168.15.100:80 send-proxy-v2 check inter 3s fall 2 rise 2

Mise en place des CRDs gateway api :

Mettre en place les CRD gateway api :

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.1/standard-install.yaml

Pour vérifier :

kubectl get crd |grep gateway

 Mise en place de MetalLB

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.9/config/manifests/metallb-native.yaml

Vérifier que ça démarre :

kubectl get pods -n metallb-system -w

Fichier metallb.yml avec l'affectation de la plage d'ips LB

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: local-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.15.100-192.168.15.110
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2adv
  namespace: metallb-system
spec:
  ipAddressPools:
    - local-pool

Déploiement et vérification

kubectl apply -f metallb.yml 
kubectl get ipaddresspool -n metallb-system

 Mise en place de Traefik

 Repos helm

helm repo add traefik https://traefik.github.io/charts
helm repo update

Configuration de Traefik

Fichier values-traefik.yaml

deployment:
  kind: Deployment
  replicas: 3

gateway:
  enabled: false

providers:
  kubernetesGateway:
    enabled: true
  kubernetesIngress:
    enabled: true

ingressClass:
  enabled: true
  isDefaultClass: true

service:
  type: LoadBalancer
  annotations:
    metallb.universe.tf/address-pool: local-pool

ports:
  traefik:
    port: 9000
    protocol: TCP
  web:
    port: 80
    exposedPort: 80
    protocol: TCP
    proxyProtocol:
      trustedIPs:
        - "192.168.15.0/24"
    forwardedHeaders:
      trustedIPs:
        - "192.168.15.0/24"
  websecure:
    port: 443
    exposedPort: 443
    protocol: TCP
    proxyProtocol:
      trustedIPs:
        - "192.168.15.0/24"
    forwardedHeaders:
      trustedIPs:
        - "192.168.15.0/24"
  metrics:
    port: 9100
    protocol: TCP

additionalArguments:
  - "--providers.kubernetesgateway.entrypoints=web,websecure"

logs:
  general:
    level: INFO
  access:
    enabled: true

Installation

helm install traefik traefik/traefik -n traefik --create-namespace -f values-traefik.yaml

 Vérification

Une ip doit être affectée pour le load balancer :

kubectl get svc -n traefik

 Mise en place cert-manager

Installation

helm repo add jetstack https://charts.jetstack.io
helm repo update

helm install cert-manager jetstack/cert-manager -n cert-manager --create-namespace --set crds.enabled=true

ClusterIssuer Let's Encrypt

Fichier clusterissuer.yaml :

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: toi@exemple.com
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
      - http01:
          ingress:
            ingressClassName: traefik

kubectl apply -f clusterissuer.yaml
kubectl get clusterissuer

 Resources gateway et gatewayclass

Mettre en place les ressources suivantes certificat par défaut, gateway et gateway class, fichier gateway.yml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: traefik-default-tls
  namespace: traefik
spec:
  secretName: placeholder-tls
  issuerRef:
    name: selfsigned
    kind: ClusterIssuer
  dnsNames:
    - mondomaine.com
---
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: traefik
spec:
  controllerName: traefik.io/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: traefik
spec:
  gatewayClassName: traefik
  listeners:
    - name: web
      port: 80
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: All
    - name: websecure
      port: 443
      protocol: HTTPS
      allowedRoutes:
        namespaces:
          from: All
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: placeholder-tls
            namespace: traefik

kubectl apply -f gateway.yaml

Vérifications :

kubectl get certificate -n traefik
kubectl get gateway main-gateway -n traefik

Les deux doivent être Ready: True et PROGRAMMED: True

 Application de test

 Déployer ghost

Fichier ghost.yml :

apiVersion: v1
kind: Namespace
metadata:
  name: ghost
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ghost
  namespace: ghost
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ghost
  template:
    metadata:
      labels:
        app: ghost
    spec:
      containers:
        - name: ghost
          image: ghost:latest
          env:
            - name: url
              value: "https://ghost.mondomaine.com"
            - name: database__client
              value: sqlite3
            - name: database__connection__filename
              value: /var/lib/ghost/content/data/ghost.db
          ports:
            - containerPort: 2368
          volumeMounts:
            - name: ghost-data
              mountPath: /var/lib/ghost/content
      volumes:
        - name: ghost-data
          emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: ghost
  namespace: ghost
spec:
  selector:
    app: ghost
  ports:
    - port: 80
      targetPort: 2368
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ghost-tls
  namespace: ghost
spec:
  secretName: ghost-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - ghost.mondomaine.com
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: traefik-tls-access
  namespace: ghost
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: Gateway
      namespace: traefik
  to:
    - group: ""
      kind: Secret
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: ghost
  namespace: ghost
spec:
  parentRefs:
    - name: main-gateway
      namespace: traefik
      sectionName: websecure
  hostnames:
    - "ghost.mondomaine.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: ghost
          port: 80

Le application-gateway.yml correspondant :

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: traefik
spec:
  controllerName: traefik.io/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: traefik
spec:
  gatewayClassName: traefik
  listeners:
    - name: web
      port: 80
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: All
    - name: websecure
      port: 443
      protocol: HTTPS
      allowedRoutes:
        namespaces:
          from: All
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: placeholder-tls
            namespace: traefik
         - kind: Secret
            name: ghost-tls  
            namespace: ghost

C'est pas simple tout ça mais ça fonctionne.

La suite sera de mettre en place Longhorn pour le stockage persistant sur cette infra.

L’article Traefik derrière HaProxy sur une infra managée est apparu en premier sur Aukfood.

Maquette Proxmox multi-cluster : retour d’expérience R&D autour de Headscale, PDM et PBS

Pendant mon stage d’Administrateur d’Infrastructures Sécurisées chez AUKFOOD, j’ai monté une maquette R&D Proxmox multi-cluster, hébergée dans le datacenter DENVR à Nantes. L’objectif n’était pas de livrer une production, mais de découvrir, tester et documenter plusieurs outils utiles dans un contexte d’infogérance Proxmox : Headscale, Proxmox Datacenter Manager et Proxmox Backup Server.

Ce projet n’avait pas vocation à produire une architecture finale clé en main. Sa valeur vient surtout de la démarche : construire un environnement de test, réaliser des validations concrètes, identifier les limites et documenter ce qui pourrait être réutilisable plus tard.

« Une maquette ne sert pas à prouver que ça marche en production — elle sert à savoir ce qui mérite d’aller plus loin. »

Pourquoi une maquette multi-cluster ?

En infogérance, gérer plusieurs clusters Proxmox devient vite pénible : interfaces multiples, sauvegardes éparpillées, visibilité partielle, accès distants à sécuriser. Pour tester des solutions sans mobiliser plusieurs serveurs physiques, j’ai utilisé la virtualisation nested — du Proxmox dans du Proxmox — afin de simuler deux clusters indépendants sur le même socle.

Le tout a été déployé dans un VLAN de test unique (le VLAN 213). C’est une contrainte de laboratoire : en production, on segmenterait proprement (administration, sauvegarde, supervision, production…). Cette contrainte a aussi un intérêt : comme toutes les machines partageaient déjà le même VLAN, il fallait prouver que Headscale transportait réellement du trafic, et pas seulement de la configuration déclarative.

L’architecture, simplement

Un cluster physique pve-denvr (Proxmox VE 9.1.9, Ceph HEALTH_OK) héberge quatre VM de service et deux clusters Proxmox imbriqués de trois nœuds chacun.

Cluster physique — pve-denvr · DENVR Nantes

Proxmox VE 9.1.9 · 3 nœuds · Ceph HEALTH_OK · stockage partagé ceph-store

Services transverses · VLAN 213 (192.168.13.0/24)

vm-NAT

bastion d’accès

vm-headscale

plan de contrôle overlay

vm-pdm

centralisation

vm-pbs

sauvegarde

cluster-A · 3 nœuds

192.168.13.101–103 · overlay 100.64.0.2–4

pve-a1

pve-a2

pve-a3

cluster-B · 3 nœuds

192.168.13.201–203 · overlay 100.64.0.5–7

pve-b1

pve-b2

pve-b3

Overlay Headscale (WireGuard) · 100.64.0.0/24 — adressage stable entre tous les nœuds

Headscale : valider le flux overlay

Headscale est un serveur de contrôle auto-hébergé compatible Tailscale/WireGuard. Son rôle n’est pas de faire transiter tout le trafic : il coordonne les nœuds et distribue les clés, puis les machines communiquent directement entre elles en WireGuard. Dans la maquette, chaque nœud reçoit une IP overlay en 100.64.0.x.

Headscale

plan de contrôle · distribue les clés

↑ coordination & échange des clés (control plane)

Cluster Proxmox A

pve-a1 / a2 / a3

Poste admin

accès via bastion

Cluster Proxmox B

pve-b1 / b2 / b3

↔ trafic direct WireGuard entre les machines (data plane)

Le point clé de la validation : prouver que l’overlay est réellement emprunté. Depuis vm-pdm (100.64.0.8), un ping vers pve-b1 (100.64.0.5) a été lancé pendant une capture tcpdump sur l’interface tailscale0.

nate@vm-pdm:~$ ping -c 4 100.64.0.5
64 bytes from 100.64.0.5: icmp_seq=1 ttl=64 time=0.917 ms
--- 100.64.0.5 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss

nate@vm-pdm:~$ tcpdump -ni tailscale0 'icmp and host 100.64.0.5'
IP 100.64.0.8 > 100.64.0.5: ICMP echo request
IP 100.64.0.5 > 100.64.0.8: ICMP echo reply
…
8 packets captured · 8 received by filter · 0 dropped by kernel

PDM : centraliser la visibilité

Proxmox Datacenter Manager (PDM 1.0.3) ne remplace pas l’administration de chaque cluster. Il apporte une vue consolidée : état des remotes, nœuds, VM, tâches, et même le serveur de sauvegarde. Dans la maquette, les remotes ont été déclarés sur les adresses overlay 100.64.0.x — ce qui reste cohérent avec la preuve réseau précédente.

Là où il fallait sinon ouvrir trois interfaces séparées, PDM voit d’un coup cluster-A, cluster-B et le serveur PBS. Pour une société d’infogérance, c’est exactement le genre de gain de temps recherché.

PBS : sauvegarder et restaurer

Proxmox Backup Server (PBS 4.2.0) est la brique la plus concrète du projet. Le datastore datastore-maquette héberge la sauvegarde de la VM de test et affiche un bon facteur de déduplication.

Le principe que je voulais surtout vérifier : une sauvegarde « OK » ne vaut rien tant qu’on n’a pas testé la restauration. La sauvegarde vm/1001 a donc été restaurée vers une nouvelle VM (1099), sans écraser l’originale.

Backup vm/1001

datastore-maquette · vérifié OK

→

Restauration

vers local-lvm, sans écrasement

→

VM 1099

visible dans cluster-A · TASK OK

La restauration s’est terminée avec succès et la VM est réapparue dans le cluster. C’est cette étape qui transforme une sauvegarde théorique en sauvegarde réellement exploitable.

Une limite de dimensionnement repérée au passage. Une première migration entre nœuds nested a échoué (No space left on device) : le stockage local du nœud cible était trop juste pour copier le disque. Rien à voir avec le réseau ou Headscale — juste un rappel que les migrations sur stockage local dépendent fortement de la capacité disponible.

Limites et trajectoire production

La maquette valide des usages, pas une production. Avant toute industrialisation, plusieurs points seraient à renforcer :

• Réseau : remplacer le VLAN unique par une vraie segmentation (administration, sauvegarde, supervision, production).
• Accès : durcir l’exposition de PDM (bastion/VPN, MFA, comptes dédiés, journalisation).
• Sauvegarde : activer le chiffrement PBS, définir rétention et réplication hors site, viser une stratégie 3-2-1 avec tests réguliers de restauration.
• Supervision : PDM donne une visibilité, mais ne remplace pas une supervision dédiée.

Conclusion

Outil	Ce qui a été validé	Pour AUKFOOD
Headscale	Flux overlay prouvé via tcpdump	Interconnexion / multi-sites
PDM	Vue centralisée multi-cluster	Visibilité, à surveiller
PBS	Sauvegarde + restauration réelle	Candidat prioritaire

Headscale s’est montré pertinent pour l’interconnexion et le réseau overlay, PDM pour la visibilité multi-cluster, et PBS pour la sauvegarde/restauration. La maquette a permis de valider ces usages dans un cadre de laboratoire, tout en identifiant les points à renforcer avant toute trajectoire de production.

L’article R&D PDM, PBS, Headscale est apparu en premier sur Aukfood.

Securite OpenSource

Par Killian Prin-Abeil - Aukfood
⭐ Wazuh Ambassador

Wazuh est au coeur de notre stack SOC open source. On l'utilise au quotidien pour surveiller nos endpoints, centraliser nos logs, gerer la conformite. Mais une question simple restait sans reponse simple : qui peut faire quoi, sur quoi, dans notre deploiement Wazuh ? WazuhHound est ne de cette question.

13 types de noeuds

21 types de relations

50 requêtes Cypher incluses

MIT open source

Le problème : Wazuh répond aux questions, pas aux relations

On utilise Wazuh depuis un moment. On connaît bien l'API, on sait chercher un agent, lister des groupes, inspecter des permissions. Mais à un moment, face à une question d'audit interne - qui a réellement accès à quoi dans notre déploiement ? - on a réalisé que l'API ne répondait pas à ce type de question. Pas parce qu'elle manque de données, mais parce qu'elle ne pense pas en termes de relations entre ces données.

Un utilisateur a des rôles. Un rôle a des politiques. Une politique a des actions sur des ressources. Des agents sont dans des groupes, gérés par un cluster, connectés à un noeud. Tout ça existe dans l'API - mais éparpillé sur des dizaines d'endpoints, sans vue d'ensemble. Pour comprendre le chemin complet, il fallait croiser les réponses à la main. Pas scalable, pas auditabie, pas visualisable.

La question qu'on s'est posée : et si on traitait l'infrastructure Wazuh comme un graphe ?

BloodHound CE comme moteur de cartographie

BloodHound est un outil bien connu dans la communaute securite - initialement concu pour cartographier les relations dans Active Directory. Mais son moteur - un graphe Neo4j requetable en Cypher, avec une interface visuelle - est exactement ce dont on avait besoin pour Wazuh.

BloodHound CE (Community Edition) supporte les extensions OpenGraph : des schemas personnalises qui permettent de definir ses propres types de noeuds et de relations, completement independants d'Active Directory. On a concu WazuhHound comme une extension native de cette architecture.

Le principe : collecter l'ensemble des donnees Wazuh via l'API, les transformer en graphe OpenGraph, et les injecter dans BloodHound CE pour les explorer visuellement et les interroger en Cypher.

Ce que WazuhHound cartographie

WazuhHound definit 12 types de noeuds qui couvrent l'integralite d'un deploiement Wazuh :

Infrastructure WZ_Cluster WZ_ClusterNode WZ_IndexerCluster WZ_IndexerNode

Agents et reseau WZ_Agent WZ_AgentGroup WZ_NetworkSegment

Securite RBAC + Indexer WZ_User WZ_Role WZ_Policy WZ_IndexerUser WZ_IndexerRole WZ_RoleMapping

Chaque noeud est enrichi avec les proprietes collectees depuis l'API : statut, version, IP, configuration RBAC, scores de vulnerabilite, ports en ecoute, nombre de packages installes. Les 19 types de relations permettent d'interroger le graphe avec precision - et les 48 requetes Cypher pre-integrees couvrent les cas d'usage les plus courants.

Les permissions RBAC visualisees comme un graphe

La partie la plus utile au quotidien, c'est la cartographie RBAC. Wazuh utilise un modele Utilisateurs -> Roles -> Politiques. Chaque politique definit des actions et des ressources. WazuhHound traduit ce modele en edges traversables dans BloodHound CE - ce qui permet de visualiser d'un coup d'oeil qui a acces a quoi, et via quel chemin.

Une requete simple pour voir le chemin complet de permissions depuis les utilisateurs :

-- Chemin complet : utilisateur -> role -> politique -> ressource
MATCH p=(u:WZ_User)
  -[:WZ_HasRole]->(:WZ_Role)
  -[:WZ_HasPolicy]->(:WZ_Policy)
  -[:WZ_CanControlAgent|WZ_CanManageSecurity]->()
RETURN p ORDER BY u.name

L'indexer OpenSearch aussi est cartographie

WazuhHound ne se limite pas au manager Wazuh. Avec le parametre --indexer-url, il interroge directement l'API OpenSearch Security pour collecter les utilisateurs internes, les roles, et leurs mappings. Les droits de lecture et d'ecriture sur les index de logs sont modelises comme des edges traversables dans le graphe.

Enrichissement des agents

Chaque agent est enrichi en parallele avec les donnees syscollector :

• Vulnerabilites : comptages critical/high/medium depuis l'index OpenSearch wazuh-states-vulnerabilities-* ou l'API legacy Wazuh <= 4.7
• Score de risque 0-10 : calcule automatiquement a partir des CVE, du statut de l'agent, et d'heuristiques de version OS
• Ports en ecoute : services exposes sur chaque agent via syscollector/ports
• Packages installes : nombre de packages pour evaluer la surface exposee
• Segments reseau : sous-reseaux derives depuis syscollector/netaddr, avec identification des agents multi-homes

-- Agents avec les scores de risque les plus eleves
MATCH (a:WZ_Agent)
WHERE a.risk_score >= 5
RETURN a.name, a.vuln_critical, a.vuln_high, a.risk_score
ORDER BY a.risk_score DESC

name             vuln_critical   vuln_high   risk_score
srv-prod-02      4               7           8.7
desktop-rh-01    2               3           6.1
laptop-dev-03    1               2           5.3

Installation en 3 etapes

# 1. Cloner et installer
$ git clone https://github.com/0xbbuddha/WazuhHound.git
cd WazuhHound && pip install -e .

# 2. Uploader le schema dans BloodHound CE (une seule fois)
$ python3 helper-scripts/upload_schema.py \
  --url http://localhost:8080 \
  --username admin --secret "$BH_SECRET"
python3 helper-scripts/upload_custom_icons.py \
  --url http://localhost:8080 \
  --username admin --secret "$BH_SECRET"
python3 helper-scripts/upload_saved_queries.py \
  --url http://localhost:8080 \
  --username admin --secret "$BH_SECRET"

# 3. Lancer la collecte
$ wazuhhound \
  --wazuh-url https://wazuh:55000 \
  --wazuh-user admin --wazuh-password secret \
  --indexer-url https://wazuh:9200 \
  --output ./output --insecure

[+] Collected:
    Agents   : 29
    Groups   : 13
    Cluster  : wazuh-manager (1 node(s), standalone)
    Indexer  : wazuh-cluster (2 node(s))
    Users    : 6 (manager API)
    Segments : 4 network segment(s)
    Vulns    : 8 agent(s) with vulnerabilities
[+] OpenGraph exported:
    Nodes : 87
    Edges : 214
    File  : ./output/wazuhhound_20260529143201.json

Pourquoi Python ?

🐍 Ecosysteme Wazuh Python est le langage de l'ecosysteme Wazuh. Les outils, les scripts d'integration, les exemples de documentation - tout est en Python.

📦 bhopengraph La librairie BloodHound OpenGraph est disponible en Python et gere nativement le format d'export compatible BloodHound CE.

🔧 Extensible Ajouter un nouveau type de noeud ou une nouvelle source d'enrichissement prend quelques lignes. Pas de compilation, pas de toolchain.

Compatibilite : WazuhHound fonctionne avec Wazuh 4.x. Il s'appuie sur l'API Manager (port 55000) et optionnellement sur l'API OpenSearch Security (port 9200) pour les utilisateurs internes, les roles indexer, et les donnees de vulnerabilite Wazuh 4.8+.

Et maintenant ?

WazuhHound tourne en production chez nous. On l'utilise concrètement pour auditer les permissions RBAC, vérifier la topologie de nos déploiements, et identifier rapidement les agents mal configurés ou exposés. C'est devenu un réflexe avant chaque revue de sécurité.

En tant qu'ambassadeur Wazuh, je vois ce projet comme une brique complémentaire à l'écosystème - pas un fork, pas un concurrent, juste un outil qui exploite ce que Wazuh expose déjà via son API et le rend visible d'une façon différente. Si vous administrez un déploiement Wazuh et que vous n'avez jamais eu une vue graphe de votre infrastructure, c'est le bon moment pour essayer.

WazuhHound est open source

Libre, sous licence MIT. Schema BloodHound CE, icones personnalisees, 48 requetes Cypher pre-integrees
et scripts helper pour l'upload - tout est inclus. Si vous utilisez Wazuh et qu'il vous manque
un type de noeud ou une relation, ouvrez une issue ou une PR -
c'est exactement comme ca que le logiciel libre avance.

Voir sur GitHub
Ambassadors Program

• Wazuh
• BloodHound CE
• Ambassadors Program

L’article WazuhHound – Cartographier votre infrastructure Wazuh avec BloodHound CE est apparu en premier sur Aukfood.

Bon premier réflexe, redémarrer, et bien sûr même cause, même conséquence ...

Et donc il faut matter ce grub ...

Avec un peu de musique : Lordi Le Papa Pinguin

Dis moi papa pinguin c'est quoi GRUB ?

GRUB (Grand Unified Bootloader) est le chargeur d'amorçage le plus utilisé sur les systèmes Linux. C'est le premier programme qui s'exécute au démarrage de l'ordinateur, juste après le BIOS/UEFI. Son rôle est de localiser le noyau Linux (ou un autre système d'exploitation) et de le charger en mémoire pour démarrer la machine.

Il permet notamment de :

• Choisir entre plusieurs systèmes d'exploitation au démarrage (dual boot)
• Passer des paramètres au noyau Linux
• Démarrer en mode de récupération en cas de problème

Passage en mode rescue

La première étape, le boot de l’instance/vm/serveur en mode rescue.

Analyse des disques

Une fois démarré, on analyse les disques pour reprendre le montage du système :

fdisk -l
lsblk -f

Identifier :

• le disque système (/dev/sda, /dev/vda, /dev/xvda, etc.)
• la partition root.

Montage du système

On monte ensuite le disque système (et si besoins les autres disques pour reconstituer le système de fichiers) :

mount /dev/sdXN /mnt/tmp1

Exemple :

mount /dev/sda1 /mnt/tmp1

Préparation du chroot

Eh oui même en 2026 il faut savoir faire un chroot.

Dis moi papa pinguin c'est quoi un chroot ?

Un chroot (change root) est une opération Unix qui modifie le répertoire racine apparent d'un processus. Tout processus lancé dans un chroot ne peut accéder qu'aux fichiers situés sous ce nouveau répertoire racine, ce qui l'isole du reste du système.

mount --bind /proc /mnt/tmp1/proc
mount --bind /sys /mnt/tmp1/sys
mount --bind /dev /mnt/tmp1/dev
mount --bind /run /mnt/tmp1/run

Puis :

chroot /mnt/tmp1 /bin/bash

Vérification du disque de boot

Une fois dans le chroot on va vérifier le nom du disque :

lsblk

Confirmer le disque système complet :

• /dev/sda
• /dev/vda
• /dev/xvda

Réinstallation GRUB

On réinstalle Grub sur le bon disque :

grub-install /dev/sdX

Exemple :

grub-install /dev/sda

Régénération initramfs

On regénère l'initramfs :

Dis moi papa pinguin c'est quoi initramfs ?

initramfs (Initial RAM File System) est un système de fichiers temporaire chargé en mémoire vive au démarrage, juste après GRUB. Il contient un mini-environnement Linux minimal qui permet au noyau de préparer le vrai démarrage du système.

Il sert notamment à :

• Charger les pilotes (drivers) nécessaires pour accéder au disque dur
• Déverrouiller un disque chiffré (LUKS) avant de monter la partition racine
• Assembler un RAID ou un volume LVM avant le montage
• Monter la vraie partition / et passer la main au système définitif

Une fois son travail terminé, initramfs disparaît de la mémoire et le système démarre normalement.

update-initramfs -u -k all

Mise à jour du menu GRUB

On fini en mettant à jour le menu de démarrage :

update-grub

Vérifications importantes

Quelques petites vérifications :

ls -lh /boot

Présence obligatoire :

• vmlinuz-*
• initrd.img-*

Vérifier aussi l’espace disque :

df -h /boot

Redémarrage

On reboot en mode normal :

exit
reboot

L’article Le travail de papa pinguin : comment matter un grub qui redémarre pas est apparu en premier sur Aukfood.

# 1. Récupérer un token
curl -u wazuh-wui:secret \
  -k -X GET \
  "https://wazuh:55000
  /security/user/authenticate"
  | jq -r '.data.token'
eyJhbGciOiJFUzUxMiIsInR5...

# 2. Lister les déconnectés
curl -k \
  -H "Authorization: Bearer ..." \
  "https://wazuh:55000/agents
  ?status=disconnected" \
  | jq '.data.affected_items[]
  | {id,name,status}'

wazuh > agent list \
  --status disconnected

ID    NAME           STATUS
002   srv-prod-02    disconnected
007   desktop-rh-01  disconnected
011   laptop-dev-03  disconnected

Showing 3 of 3 agents

wazuh > status

Manager
  Version              : Wazuh 4.9.0
  Type                 : master

Agents
  Active               : 42
  Disconnected         : 3
  Never connected      : 1

Daemons
  wazuh-analysisd      : running
  wazuh-remoted        : running
  wazuh-modulesd       : running

• Wazuh
• Ambassadors Program

L’article Wazuh-cli : on a ressuscité un outil open source abandonné depuis 6 ans est apparu en premier sur Aukfood.

.wp-art .schema-img{ margin:34px 0 38px; text-align:center; }

.wp-art .schema-img img{ width:100%; max-width:860px; height:auto; border-radius:14px; border:1px solid #dde3f0; box-shadow:0 8px 28px rgba(26,36,86,0.12); display:block; }

.wp-art .schema-img figcaption{ font-size:13px; color:#6b7390; margin-top:10px; line-height:1.5; font-style:italic; }

@media(max-width:680px){ .wp-art .deux-col{grid-template-columns:1fr;} }

Dans le cadre d'un projet de maquette multi-sites sur Proxmox, j'ai eu besoin de choisir une solution pour interconnecter deux clusters à distance. En cherchant, deux outils revenaient régulièrement : Headscale et Pangolin. Les deux reposent sur WireGuard, les deux sont open source et auto-hébergés. Mais en creusant un peu, on réalise qu'ils ne répondent pas du tout au même besoin.

Cet article présente les deux solutions, leurs différences techniques, et aide à comprendre dans quel contexte l'un est plus adapté que l'autre.

« Le bon outil, ce n'est pas forcément le plus connu — c'est celui qui correspond au besoin. »

La base commune — WireGuard

Avant tout, il faut comprendre ce qu'est WireGuard. C'est un protocole VPN moderne, intégré directement dans le noyau Linux depuis la version 5.6. Par rapport aux anciennes solutions comme OpenVPN ou IPsec, WireGuard est beaucoup plus simple, plus léger et surtout beaucoup plus rapide.

Le principe est simple : chaque machine génère une paire de clés (publique/privée), échange sa clé publique avec ses pairs, et le trafic entre eux est chiffré de bout en bout. Pas besoin de gestion complexe de certificats ou de PKI — c'est sa grande force.

Headscale et Pangolin utilisent tous les deux WireGuard pour le chiffrement. Là où ils diffèrent, c'est dans la façon dont ils orchestrent ces tunnels et dans le modèle réseau qu'ils créent.

Un point important sur les performances

WireGuard intégré au noyau Linux est très performant — on parle de plusieurs centaines de Mbit/s avec une latence minimale. WireGuard implémenté en dehors du noyau (userspace) est bien plus lent, autour de 1 à 10 MB/s en pratique. Cette distinction est au coeur de la différence de performances entre les deux outils.

Deux outils, deux approches

C'est la distinction fondamentale à comprendre dès le départ. Beaucoup de gens les comparent comme s'ils étaient interchangeables — c'est une erreur. Ils ne font pas la même chose.

Headscale

VPN Mesh — Machine à machine

Version open source du serveur de contrôle Tailscale. Crée un réseau privé entre toutes les machines enregistrées. Chaque serveur obtient une IP dans ce réseau et communique directement avec les autres, comme s'ils étaient sur le même réseau local.

Pangolin

Tunnel + Reverse Proxy — Exposition de services

Regroupe reverse proxy, tunnels WireGuard et gestion des accès en un seul outil. L'objectif : exposer des services web depuis un réseau privé, sans ouvrir de port, via un VPS public comme point d'entrée.

La distinction clé : Headscale connecte des machines entre elles. Pangolin expose des services à des utilisateurs. Ce ne sont pas des concurrents directs — dans beaucoup de cas, les deux peuvent coexister sur la même infrastructure.

---

Headscale

Headscale est né d'un besoin simple : profiter de l'expérience Tailscale sans dépendre de leur infrastructure cloud. On utilise les clients officiels Tailscale sur toutes les machines — Linux, Windows, macOS, iOS, Android — et Headscale se contente de remplacer le serveur de coordination. On garde le contrôle total sur l'infrastructure.

Le serveur Headscale joue un seul rôle : distribuer les clés WireGuard entre les machines et gérer les politiques d'accès. Une fois les clés échangées, le trafic passe directement de machine à machine en WireGuard natif, sans repasser par le serveur. C'est ce qui rend les performances excellentes — le serveur Headscale n'est jamais un goulot d'étranglement.

Quand deux machines ne peuvent pas se connecter directement (NAT restrictif, CGNAT), un relais chiffré prend le relais automatiquement, de façon transparente.

Le routage de sous-réseau

C'est la fonctionnalité la plus utile pour les architectures multi-sites. Une machine peut annoncer tout un LAN dans le réseau Headscale — les autres machines peuvent alors accéder à l'ensemble de ce réseau sans que chaque serveur ait besoin d'un client installé. Concrètement : un seul LXC par site fait office de passerelle pour tout le réseau local.

Gestion des acces

Les accès se configurent via une politique ACL en JSON : tags, groupes d'utilisateurs, règles par port et protocole. Le système est très granulaire. Headscale supporte aussi l'authentification SSO/OIDC — Google, GitHub, Authentik, Keycloak — pour que les utilisateurs se connectent avec leur compte existant.

Headscale intègre aussi un système DNS automatique appelé MagicDNS : chaque machine enregistrée devient accessible par son nom dans le réseau, sans configuration manuelle. Très pratique dès qu'on a plusieurs dizaines de serveurs à gérer.

Points forts

• WireGuard natif — performances maximales
• Trafic direct entre machines, aucun intermédiaire
• Clients Tailscale officiels sur toutes les plateformes
• Routage de sous-réseau — expose un LAN entier
• DNS automatique — machines accessibles par nom
• Règles d'accès très fines (tags, groupes, ports)
• Projet stable et mature (~5 ans en production)
• Licence BSD-3 — aucune contrainte d'utilisation

Limites

• Pas d'accès web sans client installé
• Pas d'interface web officielle
• Un seul réseau par instance Headscale
• Pas de reverse proxy ni SSL automatique intégré
• Mises à jour strictes — pas de saut de version

---

Pangolin

Pangolin est développé par Fossorial et se positionne comme une alternative auto-hébergée à Cloudflare Tunnel. L'ambition est de regrouper en un seul outil ce qui nécessite habituellement plusieurs solutions : tunnel WireGuard, reverse proxy, gestion des accès et certificats SSL.

L'architecture repose sur quatre composants qui fonctionnent ensemble. Pangolin gère le plan de contrôle et l'authentification. Gerbil gère les tunnels WireGuard côté serveur. Traefik s'occupe du reverse proxy et des certificats SSL via Let's Encrypt. Newt est le client léger déployé sur les sites distants — il initie le tunnel vers le VPS, aucun port à ouvrir côté réseau local.

Le modèle est fondamentalement différent de Headscale : un VPS public fait office de point d'entrée unique pour tout le trafic entrant. Les serveurs distants sortent vers le VPS, jamais l'inverse. L'adresse IP réelle des serveurs n'est donc jamais exposée.

L'acces web sans client

C'est la vraie force de Pangolin. Un utilisateur peut accéder à une application interne directement depuis un navigateur — après authentification via SSO, 2FA ou un simple passcode temporaire — sans avoir installé quoi que ce soit sur sa machine. C'est ce qui le différencie d'un VPN classique où tout le monde doit installer un client.

CrowdSec intégré

Pangolin intègre CrowdSec directement dans la stack Traefik. CrowdSec analyse les logs en temps réel et bloque automatiquement les IPs malveillantes connues à l'échelle mondiale. C'est une couche de protection significative sans aucune configuration supplémentaire.

Newt implémente WireGuard en dehors du noyau système, ce qui lui permet de fonctionner sans droits root dans des environnements très restrictifs. En contrepartie, les performances sont limitées — environ 1 à 10 MB/s dans les tests réels. Suffisant pour du web, pas adapté à du stockage réseau ou des migrations de machines virtuelles.

Points forts

• Accès web sans client — juste un navigateur
• SSL automatique via Let's Encrypt
• Fonctionne derrière CGNAT sans IP publique
• Dashboard complet intégré dès l'installation
• CrowdSec intégré — protection sans effort
• Multi-organisation — plusieurs clients indépendants
• Meilleure alternative auto-hébergée à Cloudflare Tunnel

Limites

• Débit limité (1 à 10 MB/s en pratique)
• Tout le trafic transite par le VPS
• Nécessite un VPS public et un nom de domaine
• 4 composants Docker à maintenir
• Projet récent (~1 an) — encore quelques instabilités
• Licence AGPL-3 avec contraintes si usage commercial

---

Comparatif

Critère	Headscale	Pangolin
Modèle réseau	VPN mesh — toutes machines connectées	Point d'entrée central via VPS
Transport WireGuard	Noyau Linux — natif	Hors noyau (Newt)
Performances	Excellentes (100+ Mbit/s)	Limitées (1–10 MB/s)
Accès web sans client	Non	Oui
SSL automatique	Non intégré	Oui (Let's Encrypt)
Trafic inter-sites	Direct entre machines	Passe par le VPS
NFS / iSCSI / stockage	Adapté	Déconseillé
Derrière CGNAT	Oui (relais de secours)	Oui (tunnel sortant)
Interface web native	Non officielle (Headplane)	Oui, complète
Multi-organisation	Non	Oui
Protection IDS intégrée	Non	Oui (CrowdSec)
Clients mobiles	Tailscale officiel	En développement
Maturité	~5 ans, stable	~1 an, en croissance
Licence	BSD-3 (libre)	AGPL-3 / Commercial

Quand utiliser quoi

Headscale est adapté dès qu'on a besoin de faire communiquer des réseaux entre eux — deux clusters Proxmox qui doivent se parler, de la réplication de données, du stockage réseau (NFS, iSCSI), ou simplement de l'accès SSH depuis n'importe quel appareil. Les clients Tailscale officiels couvrent toutes les plateformes sans exception.

Pangolin est plus adapté pour exposer des applications web à des utilisateurs qui n'ont pas de client VPN — dashboards, outils internes, interfaces d'administration. L'authentification SSO et le SSL automatique sont intégrés. C'est aussi la solution idéale quand le réseau est derrière un CGNAT sans IP publique disponible, puisque le tunnel est sortant et ne nécessite aucune ouverture de port.

Les deux peuvent tout à fait coexister. Headscale pour la connectivité infra, Pangolin en complément pour l'exposition de services — c'est souvent la combinaison la plus efficace.

Conclusion

Après avoir comparé les deux solutions, le constat est clair : ce sont deux outils complémentaires, pas des concurrents. Ils répondent à des problématiques différentes et il est tout à fait possible de les déployer en parallèle.

Headscale est le bon choix dès qu'on a besoin de faire communiquer des réseaux entre eux avec de bonnes performances. WireGuard natif fait vraiment la différence dès qu'on sort du simple accès web — réplication, migrations, stockage réseau. Le projet est mature, la licence est libre et l'écosystème client Tailscale est excellent.

Pangolin brille sur l'exposition de services web à des utilisateurs sans client VPN. La stack intégrée (SSL automatique, authentification, CrowdSec) représente un gain de temps réel. C'est aujourd'hui la meilleure alternative auto-hébergée à Cloudflare Tunnel.

Pour un projet d'interconnexion d'infrastructure multi-sites, Headscale est le choix le plus adapté. Pour exposer des applications internes à des équipes ou clients sans infrastructure VPN, Pangolin prend clairement l'avantage.

L’article Comparatif Headscale – Pangolin est apparu en premier sur Aukfood.

Par défaut, le bouncer CrowdSec (crowdsec-firewall-bouncer) injecte sa propre chaîne dans iptables. Shorewall étant maître des règles firewall, il efface cette chaîne à chaque shorewall safe-restart. Les IPs bannies par CrowdSec ne sont plus bloquées.

La solution

Deux petites modifications suffisent.

1. Bouncer CrowdSec — /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml

Passer le mode de iptables à ipset, et commenter les chaînes iptables :

mode: ipset

#iptables_chains:
#  - INPUT
#  - FORWARD
#  - DOCKER-USER

Redémarre le bouncer :

systemctl restart crowdsec-firewall-bouncer

2. Shorewall — /etc/shorewall/shorewall.conf

Ajouter ces deux directives :

# Crowdsec
DYNAMIC_BLACKLIST=ipset-only:crowdsec-blacklists
SAVE_IPSETS=Yes

DYNAMIC_BLACKLIST indique à Shorewall de déléguer le blocage dynamique à l'ipset crowdsec-blacklists (alimenté par le bouncer), et SAVE_IPSETS=Yes assure la persistance au reboot.

Recharge Shorewall :

shorewall safe-restart

Vérification

# L'ipset est bien peuplé par CrowdSec
ipset list crowdsec-blacklists

#output
198.244.240.165 timeout 12880 packets 0 bytes 0
39.101.94.83 timeout 11880 packets 15 bytes 900
87.3.25.245 timeout 9865 packets 0 bytes 0
198.244.168.192 timeout 8927 packets 0 bytes 0
89.200.229.42 timeout 10302 packets 0 bytes 0
176.31.139.6 timeout 9534 packets 0 bytes 0
39.101.93.209 timeout 11861 packets 0 bytes 0
198.244.168.182 timeout 12904 packets 0 bytes 0
198.244.183.121 timeout 9057 packets 0 bytes 0
86.97.49.220 timeout 11702 packets 0 bytes 0
39.101.93.55 timeout 13020 packets 0 bytes 0
45.146.8.36 timeout 12929 packets 0 bytes 0

C'est tout, Shorewall et CrowdSec cohabitent sans se marcher dessus.

L’article CrowdSec + Shorewall : Comment les faire cohabiter est apparu en premier sur Aukfood.

Je vous renvoi vers les articles sur Alloy pour les concepts, par exemple https://www.aukfood.fr/remonter-les-metriques-vers-prometheus-avec-grafana-alloy/

Installation

Pour l'installation rien de mystérieux, j'ai pris la documentation officielle.

Remonter des métriques.

Pour les métriques j'ai repris un peu la même configuration que l'articles Linux en adaptant pour Windows.

logging {
    level = "warn"
}

// Export metrics
prometheus.exporter.windows "default" {
  enabled_collectors = ["cpu","cs","logical_disk","net","os","service","system", "memory", "scheduled_task", "tcp"]
}

prometheus.scrape "windows_metrics" {
  targets    = prometheus.exporter.windows.default.targets
  forward_to = [prometheus.remote_write.metrics_service.receiver]
}

// Write metrics to prometheus
prometheus.remote_write "metrics_service" {
endpoint {
        url = "https://url-prom/api/v1/write"

        basic_auth {
           username = "identifiant"
           password = "password"
        }
    }

    external_labels = {
           "client" = "nomclient",
           "serveur" = "nomserveur",
    }
}

// Open dashboard Alloy
prometheus.scrape "default" {
  targets = array.concat(
    prometheus.exporter.windows.default.targets,
    [{
      // Self-collect metrics
      job         = "alloy",
      __address__ = "0.0.0.0:12345",
    }],
  )

  forward_to = [prometheus.remote_write.metrics_service.receiver]

}

On obtiens donc ceci dans la visualisation Alloy :

Pour Grafana j'ai utilisé ce dashboard.

Remonter les logs

Pour la remontée des logs vers Alloy :

// Export des logs Windows vers Loki
loki.source.windowsevent "application"  {
    eventlog_name = "Application"
    use_incoming_timestamp = true
    exclude_event_data = true
    forward_to = [loki.write.endpoint.receiver]
    labels = {
       job = "windows_eventlog",
       instance = constants.hostname,
    }
}

loki.source.windowsevent "security"  {
    eventlog_name = "Security"
    use_incoming_timestamp = true
    forward_to = [loki.write.endpoint.receiver]
    labels = {
       job = "windows_eventlog",
       instance = constants.hostname,
    }
}

loki.source.windowsevent "system"  {
    eventlog_name = "System"
    use_incoming_timestamp = true
    forward_to = [loki.write.endpoint.receiver]
    labels = {
       job = "windows_eventlog",
       instance = constants.hostname,
    }
}

loki.source.windowsevent "setup"  {
    eventlog_name = "Setup"
    use_incoming_timestamp = true
    forward_to = [loki.write.endpoint.receiver]
    labels = {
       job = "windows_eventlog",
       instance = constants.hostname,
    }
}

// Loki Endpoint
loki.write "endpoint" {
    endpoint {
        url ="http://10.87.200.43:3100/loki/api/v1/push"
        }
}

Ce qui va donner ceci dans la visualisation Alloy.

On à donc maintenant notre remontée de métriques et de logs depuis Windows.

L’article Grafana Alloy sur Windows est apparu en premier sur Aukfood.

 Le HPB

Le High Performance Backend (HPB) nécessite un service de signalisation et se compose de trois éléments fonctionnant en synergie :

• un service STUN (Session Traversal Utilities for NAT) pour découvrir les adresses IP externes NATées/protégées par un pare-feu. Nextcloud fournit un serveur STUN par défaut, mais vous pouvez le remplacer par le vôtre.
  Exemples : stun.nextcloud.com:443 ou stun.votredomaine.tld:3478 ou les deux
• Service TURN (Traversal Using Relays around NAT) tel que « coturn » ou « eturnal » pour connecter des adresses IP externes NATées/protégées par un pare-feu et contrôler les flux WebRTC. Son rôle principal est d'aider les clients WebRTC derrière des routeurs à communiquer et de relayer les données audio et vidéo à travers les pare-feu et les restrictions de port.
  Exemples : turn.votredomaine.tld:3478 ou votredomaine.tld:3478.
  Le chiffrement est facultatif pour TURN et STUN et sera géré par Nextcloud chiffré.
• Un service de signalisation WebRTC tel que « Janus WebRTC server » ou « Spreed WebRTC server » est nécessaire pour les appels et les conversations avec plusieurs participants. Le serveur de signalisation est utilisé pour établir une connexion WebSocket entre les participants à l'appel. Sans lui, tous les participants devraient télécharger individuellement leurs propres fichiers audio/vidéo pour chaque autre participant, ce qui entraînerait des problèmes de connectivité.
  Exemple : https://signal.yourdomain.tld

Allons un peu plus loin sur le fonctionnement théorique

Nextcloud Talk repose entièrement sur WebRTC. Il faut distinguer clairement trois couches :

Client (navigateur / app)
        │
        │ HTTPS / WebSocket
        ▼
Nextcloud Server (logique métier)
        │
        │ WebSocket (signaling)
        ▼
Signaling Server (HPB)
        │
        │ WebRTC (ICE / RTP)
        ▼
P2P direct ou TURN

J'ai demandé à une IA de me générer une image plus claire (ou pas) :

SDP — Décrire un appel

SDP (Session Description Protocol) est un document texte qui décrit une session, mais ne transporte aucun média.

Il contient notamment :

• codecs (opus, VP8, H264…)
• types de médias (audio / vidéo / data)
• ports et protocoles
• directions (sendrecv, recvonly…)

Exemple simplifié :

m=audio 9 UDP/TLS/RTP/SAVPF 111
a=rtpmap:111 opus/48000/2
a=sendrecv

Dans Nextcloud Talk :

• le client génère le SDP
• le serveur de signaling l’échange
• Nextcloud ne l’interprète pas

SDP incorrect = appel impossible avant même ICE.

ICE — Trouver un chemin réseau

ICE (Interactive Connectivity Establishment) a pour objectif de trouver le meilleur chemin réseau possible entre deux pairs.

Types de candidats ICE

ICE teste les candidats dans cet ordre :

1. host
2. srflx
3. relay

Le premier chemin fonctionnel est utilisé.

STUN — Découverte d’adresse publique

STUN permet à un client de découvrir comment il est vu depuis Internet.

Principe :

Client → STUN
STUN → "Tu es 91.x.x.x:port"

Le client crée alors un candidat srflx.

Limites fondamentales de STUN

STUN échoue avec :

• NAT symétrique
• firewalls stricts
• réseaux mobiles complexes

STUN est une aide, pas une solution.

TURN — Relais média

TURN (Traversal Using Relays around NAT) est utilisé quand toute communication directe échoue.

Fonctionnement théorique :

Client A → TURN → Client B

TURN :

• relaie les paquets RTP chiffrés
• ne décode pas le média
• consomme beaucoup de bande passante

En pratique, TURN est presque toujours utilisé.

Signaling — La pièce manquante de WebRTC

WebRTC n’inclut volontairement aucun mécanisme de signaling.

Le signaling sert à :

• échanger SDP
• échanger ICE candidates
• gérer l’état des participants

Dans Nextcloud Talk :

• assuré par le High Performance Backend (HPB)
• via WebSocket
• totalement séparé du média

P2P vs TURN (théorie)

P2P direct

Client ↔ Client

faible latence
fragile, rare en entreprise

TURN relay

Client → TURN → Client

fiable
compatible enregistrement
coûteux en ressources
En production, TURN est la norme.

 De la théorie à la pratique

On va voir maintenant comment mettre en place tout ça pour Nextcloud Talk. Il y à plusieurs possibilités pour faire cette mise en place, je vais choisir ici une installation conteneurisée avec des conteneurs, un premier pour le signaling et un second pour le recording. Il est possible que plus tard je refasse un article avec un autre modèle d'installation.

 HPB Signaling

On va avoir besoins de tokens pour cette configuration pour les générer voici la commande

openssl rand --hex 16

Les tokens seront les suivants :

• TURN_SECRET : le token pour accéder au serveur turn
• SIGNALING_SECRET : le token entre Nextcloud et le HPB
• INTERNAL_SECRET : le token pour la communication entre les composants

 Le déploiement

On va créer un docker-compose pour déployer la partie signaling en un seul conteneur :

name: 'hpb'

services:

  nc-talk:
    container_name: talk_hpb
    image: ghcr.io/nextcloud-releases/aio-talk:latest
    init: true
    ports:
      - 3478:3478/tcp
      - 3478:3478/udp
      - 127.0.0.1:8081:8081/tcp
    environment:
      - NC_DOMAIN=url-nextcloud
      - TALK_HOST=url-hpb
      - TURN_SECRET=******
      - SIGNALING_SECRET=****
      - TZ=Europe/Paris
      - TALK_PORT=3478
      - INTERNAL_SECRET=****
    restart: unless-stopped

 Le proxy

Pour accéder à ce service on va mettre en place un proxy apache2 :

<VirtualHost *:80>
  ServerName url-hpb
  Redirect Permanent / https://url-hpb
</VirtualHost>
<VirtualHost *:443>
  ServerName hpb-rocks.aukfood.ovh

    LogLevel warn
    ErrorLog "|/usr/bin/rotatelogs -lc /var/log/apache2/signaling_error.%Y.%m.%d 86400"
    CustomLog "|/usr/bin/rotatelogs -lc /var/log/apache2/signaling_access.%Y.%m.%d 86400" combined

    # SSL configuration, you may want to take the easy route instead and use Lets Encrypt!
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/https://hpb-rocks.aukfood.ovh/standalone-signaling/cert.pem
    SSLCertificateChainFile /etc/letsencrypt/live/url-hpb/chain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/url-hpb/privkey.pem

    # HSTS (mod_headers is required) (15768000 seconds = 6 months)
    Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

    # Activate http/2
    Protocols h2 h2c http/1.1

    H2Push          on
    H2PushPriority  *                       after
    H2PushPriority  text/css                before
    H2PushPriority  image/jpeg              after   32
    H2PushPriority  image/png               after   32
    H2PushPriority  application/javascript  interleaved

    # Encoded slashes need to be allowed
    AllowEncodedSlashes NoDecode

    # Container uses a unique non-signed certificate
    SSLProxyEngine On
    SSLProxyVerify None
    SSLProxyCheckPeerCN Off
    SSLProxyCheckPeerName Off

    # keep the host
    ProxyPreserveHost On

    # Preserve host
    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
    RequestHeader set X-Real-IP expr=%{REMOTE_ADDR}

        ProxyPass "/standalone-signaling/" "ws://127.0.0.1:8081/"

        RequestHeader set X-Real-IP %{REMOTE_ADDR}s
        RewriteEngine On
        RewriteRule ^/standalone-signaling/spreed/$ - [L]
        RewriteRule ^/standalone-signaling/api/(.*) http://127.0.0.1:8081/api/$1 [L,P]
</VirtualHost>

 Configuration Nextcloud

Dans la partie Talk il faut configurer :

• Infrastructure Haute Performance
• STUN
• TURN

L'url est de la forme https://url-hpb/standalone-signaling

 HPB Recording

Une fonction intéressante est de pouvoir enregistrer des réunions, webnaires etc à partir de la visio. C'est pour cela qu'on va rajouter un conteneur hpb recording, l'avantage c'est que les vidéos seront enregistrées directement dans Nextcloud (dans le répertoire Talk de l'initiateur de la visio).

 Déploiement

On crée le docker-compose suivant :

services:
  nc-recording:
    image: nextcloud/aio-talk-recording:latest
    container_name: nc-recording
    restart: unless-stopped
    shm_size: '4gb'
    ports:
      - "127.0.0.1:1234:1234"
    environment:
      - TZ=Europe/Berlin
      - NC_DOMAIN=url-nextcloud
      - HPB_DOMAIN=url-hpb
      - RECORDING_SECRET=******
      - INTERNAL_SECRET=******
      - TZ=Europe/Paris

 Le proxy https

<VirtualHost *:80>
  ServerName url-record
  Redirect Permanent / https://url-record
</VirtualHost>
<VirtualHost *:443>
  ServerName url-record

    LogLevel warn
    ErrorLog "|/usr/bin/rotatelogs -lc /var/log/apache2/recording_error.%Y.%m.%d 86400"
    CustomLog "|/usr/bin/rotatelogs -lc /var/log/apache2/recording_access.%Y.%m.%d 86400" combined

    # SSL configuration, you may want to take the easy route instead and use Lets Encrypt!
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/url-record/cert.pem
    SSLCertificateChainFile /etc/letsencrypt/live/url-record/chain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/url-recordprivkey.pem

    # HSTS (mod_headers is required) (15768000 seconds = 6 months)
    Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

    # Activate http/2
    Protocols h2 h2c http/1.1

    H2Push          on
    H2PushPriority  *                       after
    H2PushPriority  text/css                before
    H2PushPriority  image/jpeg              after   32
    H2PushPriority  image/png               after   32
    H2PushPriority  application/javascript  interleaved

    # Encoded slashes need to be allowed
    AllowEncodedSlashes NoDecode

    # Container uses a unique non-signed certificate
    SSLProxyEngine On
    SSLProxyVerify None
    SSLProxyCheckPeerCN Off
    SSLProxyCheckPeerName Off

    # keep the host
    ProxyPreserveHost On

    # Preserve host
    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
    RequestHeader set X-Real-IP expr=%{REMOTE_ADDR}

    ProxyPass / http://127.0.0.1:1234/ 

</VirtualHost>

 Reste plus qu'à rajouter la configuration dans Nextcloud

Conclusion

C'est une façon de faire l'installation elle peut être discutée mais elle fonctionne assez bien, par exemple nos webinairs sont faits directement dans Nextcloud Talk et enregistrés en live.

Je vous invite à consulter nos vidéos ici : https://peertube.aukfood.net/

Un merci à Arno Wezel pour m'avoir partagé son article qui m'a permis de corriger ma configuration : https://arnowelzel.de/en/nextcloud-talk-high-performance-backend-with-docker

L’article Mise en place de services HPB pour Nextcloud Talk est apparu en premier sur Aukfood.

En analysant les IPs (99500 en 1/2 journée) on remarque qu'il y a quand même que 1% d'IPS Française, 10% d'US et le reste, beaucoup d'Afrique, d'Inde etc ... Je pourrais faire un schéma par Pays par exemple.

Un petit script sympa : https://github.com/christophetd/geolocate-ips/blob/master/geolocate.py

L'idée est donc de diminuer le nombre de requêtes en interdisant les Pays chez qui le client ne vend pas. J'ai donc l'idée de bloquer les pays depuis Apache.

 Mise en place du module Apache geoip

Ajout du module geoip pour Apache :

apt install libapache2-mod-geoip

Le module est automatiquement chargé, plus qu'à redémarrer Apache :

systemctl restart apache2

La base de données des pays se trouve ici /usr/share/GeoIP/GeoIP.dat

 Configuration Apache

Deux possibilités pour cette configuration, soit dans /etc/apache2/apache2.conf soit dans un vhost, comme pour cet exemple :

  DocumentRoot /var/www/www.monsite.fr/www/public
  <Directory /var/www/www.monsite.fr/www/public>

  <IfModule mod_geoip.c>  
    GeoIPEnable On  

     SetEnvIf GEOIP_COUNTRY_CODE FR AllowCountry
     SetEnvIf GEOIP_COUNTRY_CODE JP AllowCountry
     SetEnvIf GEOIP_COUNTRY_CODE ES AllowCountry

     SetEnvIfNoCase User-Agent "Googlebot|Storebot-Google|AdsBot-Google|Mediapartners-Google" AllowGoogle
     SetEnvIfNoCase User-Agent "Mediapartners-Google|bingbot|BingPreview" AllowOtherSEO

     <RequireAny>
      Require env AllowCountry
      Require env AllowGoogle
      Require env AllowOtherSEO
     </RequireAny>

    # Optional: Return a custom message  
    ErrorDocument 403 "Access denied: This site is not available in your country."  
  </IfModule>

  ...

 Pour tester

En curl :

curl -A "Googlebot" https://ton-site.tld/

En browser en allant sur https://www.locabrowser.com/ qui permet de simuler des navigateurs depuis des IPs étrangères.

 Rajouter le code Pays dans les logs Apache

Cela peut être sympa en plus de rajouter le code pays dans les logs. Dans /etc/apache2/apache2.conf rajouter :

# Add %{GEOIP_COUNTRY_CODE}e to log country codes  
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{GEOIP_COUNTRY_CODE}e" combined_geoip 

Et dans la configuration des vhosts :

  LogLevel warn
  ErrorLog "|/usr/bin/rotatelogs -l -L error.log -c /var/www/www.monsite.fr/var/log/apache2/error.%Y.%m.%d 86400"
  CustomLog "|/usr/bin/rotatelogs -l -L access.log -c /var/www/www.monsite.fr/var/log/apache2/access.%Y.%m.%d 86400" combined_geoip

L’article Apache bloquer certains pays est apparu en premier sur Aukfood.