Documente le double pare-feu a traverser pour l'ingestion media

Ouvrir 1935/8890/8189 dans ufw ne suffit pas : le projet Hetzner Cloud
a son propre pare-feu en amont de la machine. tcpdump sur l'hote ne voit
aucun paquet sur 1935 alors que 2222, autorise des deux cotes, apparait
normalement - le trafic est jete avant d'atteindre le serveur.

Piege particulier sur 8189/udp : sans lui, la signalisation WebRTC
aboutit (elle passe par Caddy en 443) mais aucun media ne circule. La
console bascule en HLS sans rien signaler, et la panne se deguise en
simple latence.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Adam Belkacemi 2026-09-12 18:18:08 +02:00
parent d70892dce0
commit 5e4dfee665

View file

@ -391,6 +391,28 @@ services.
obtient et renouvelle les certificats Let's Encrypt automatiquement.
Y démarrer un second frontal les aurait mis en conflit et coupé les services
existants. Le bloc à ajouter est dans [`deploy/Caddyfile.snippet`](deploy/Caddyfile.snippet).
- **Deux pare-feux à traverser, pas un** — le serveur a `ufw`, et le projet
Hetzner Cloud a son propre pare-feu *en amont de la machine*. Ouvrir un port
dans `ufw` ne suffit pas : le paquet n'arrive jamais jusqu'à `ufw`.
Diagnostic sans ambiguïté — `tcpdump` sur l'hôte ne voit **aucun paquet**
alors qu'un port autorisé, lui, apparaît. Les trois ports d'ingestion média
(1935/tcp, 8890/udp, 8189/udp) doivent être ouverts **des deux côtés** :
```bash
# Sur la machine
ufw allow 1935/tcp && ufw allow 8890/udp && ufw allow 8189/udp
# Puis dans la console Hetzner Cloud > Firewalls > règles entrantes,
# ou via l'API :
hcloud firewall add-rule <nom> --direction in --protocol tcp --port 1935 --source-ips 0.0.0.0/0
hcloud firewall add-rule <nom> --direction in --protocol udp --port 8890 --source-ips 0.0.0.0/0
hcloud firewall add-rule <nom> --direction in --protocol udp --port 8189 --source-ips 0.0.0.0/0
```
Sans 8189/udp, la signalisation WebRTC aboutit mais aucun média ne circule :
la console bascule silencieusement en HLS. Panne d'autant plus trompeuse que
l'interface continue d'afficher une image.
- **Isolation réseau** — Kafka et PostgreSQL vivent sur un réseau Docker privé
sans aucun port publié sur l'hôte. Seule l'application rejoint le réseau
partagé du reverse proxy.