L'application n'atteint plus la base après une migration de sous-réseau
```text psycopg.OperationalError: connection to server at "10.0.4.30", port 5432 failed: Connection timed out FATAL: no pg_hba.conf entry for host "10.0.13.21", user "app", database "orders" ```
Détecter
Après le déplacement des serveurs applicatifs dans un nouveau sous-réseau, l'application ne démarre plus : délai d'attente vers la base de données.
Symptômes
Après le déplacement des serveurs applicatifs dans un nouveau sous-réseau, l'application ne démarre plus : délai d'attente vers la base de données.
Environnement
Serveurs applicatifs passés de 10.0.3.0/24 à 10.0.13.0/24, base PostgreSQL protégée par un pare-feu hôte (nftables) et pg_hba.conf.
Cause racine
La matrice de flux et les règles référencent encore l'ancien sous-réseau : le pare-feu de la base rejette silencieusement (timeout), puis, une fois corrigé, pg_hba.conf refuse la nouvelle source.
Diagnostic
- Depuis l'application :
nc -vz 10.0.4.30 5432(timeout = filtrage ; refused = service). - Sur la base : journal des refus (
journalctl -k | grep nft-drop),tcpdump -ni any port 5432. - Contrôler chaque couche : routage, pare-feu hôte, écoute (
listen_addresses),pg_hba.conf.
Solution
Mettre à jour la matrice (flux F03 : nouvelle source), puis les règles nftables et pg_hba.conf, recharger, tester de bout en bout.
Commandes
nft add element inet filtre app_servers { 10.0.13.0/24 }
echo "host orders app 10.0.13.0/24 scram-sha-256" >> /etc/postgresql/16/main/pg_hba.conf
psql -c "SELECT pg_reload_conf();"
nc -vz 10.0.4.30 5432
Prévention
Groupes d'objets nommés plutôt que des adresses, matrice de flux comme source de vérité du plan de migration, tests de flux automatisés avant/après changement.