Client de base de données local, RDS privé : pourquoi la connexion expire

L’ordinateur portable d’un développeur expire en se connectant au point de terminaison privé RDS, alors que les mêmes identifiants fonctionnent depuis un hôte bastion. Rien n’est en panne. Au chemin entre cet ordinateur et la base de données il manque l’une de trois choses : un nom qui se résout, une route qui transporte le trafic, ou une règle de groupe de sécurité qui admet la source que la base de données voit réellement. Déterminez laquelle manque avant de modifier les deux autres.

Lisez la défaillance à la bonne couche

Une expiration n’est pas une seule erreur. Un nom qui ne se résout pas échoue avant qu’un paquet quitte la machine. Une adresse sans route envoie les paquets dans un trou noir. Un port filtré produit une attente qui ressemble exactement à un mauvais hôte. Exécutez les étapes dans l’ordre et arrêtez-vous à la première qui échoue.

dig +short db.internal.example
nc -vz db.internal.example 5432

Si le nom renvoie une adresse publique, ou ne renvoie rien, le tunnel n’est pas encore le problème.

Si le nom se résout et que le test de port se bloque, comparez l’adresse résolue avec l’adresse que la base de données signale. Un point de terminaison géré peut se résoudre en une adresse privée à l’intérieur du VPC et en rien d’utile à l’extérieur, et une adresse copiée d’une ancienne recherche pointera vers un hôte qui ne répond plus.

Séparez le tunnel de la route

Connecter un VPN client n’achemine pas automatiquement toutes les plages privées. Le profil porte les routes que le service pousse, et le client peut n’en installer que certaines. Regardez quelles plages le client a réellement ajoutées et si l’adresse de la base de données tombe dans l’une d’elles.

ip route get 10.20.40.15
ip addr show tun0

Une route qui pointe vers l’interface du tunnel est nécessaire ; elle n’est pas suffisante, car le côté distant doit encore accepter le trafic.

Les profils de tunnel scindé sont la source habituelle de cet échec partiel. Ils fonctionnent pour l’application pour laquelle le profil a été conçu et laissent la plage de la base de données hors du tunnel, ce qui produit exactement l’expiration qu’un pare-feu produirait.

Alignez le groupe de sécurité sur la source réelle

Le groupe de sécurité RDS admet des sources, pas des personnes. Selon l’architecture, la source peut être le pool de clients VPN, l’adresse privée d’un bastion ou une adresse NAT vers laquelle le trafic est traduit. Lisez la règle et la source réelle du paquet ensemble.

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissions'

Une règle pour l’adresse personnelle d’un seul ordinateur portable est un problème de maintenance plutôt qu’une conception d’accès.

Lorsqu’un VPN client ou une passerelle NAT se trouve sur le chemin, la base de données peut voir l’adresse du traducteur au lieu de l’adresse du tunnel du développeur. C’est pourquoi une règle copiée d’une configuration bastion qui fonctionne peut échouer pour un ordinateur portable : les deux chemins arrivent de sources différentes alors que tous deux semblent internes.

Préférez un chemin étroit à un chemin large

Lorsqu’un développeur a besoin d’une base de données, le transfert basé sur une session est souvent moins coûteux à exploiter qu’un tunnel réseau complet. Le client local se connecte à un port transféré, et le composant distant établit la connexion à la base de données depuis l’intérieur du réseau.

ssh -N -L 5432:db.internal.example:5432 bastion.internal.example

Gardez la vérification TLS intacte dans cette conception. Le client doit toujours valider le certificat du serveur par rapport au nom qu’il attend ; un port transféré local n’est pas une raison de désactiver la vérification, et la désactiver masque exactement le problème d’identité qui vaut la peine d’être détecté.

Le choix entre un tunnel complet et un transfert étroit est une décision de portée, non de théâtre de sécurité.

Laissez derrière vous un chemin reproductible

Documentez le nom du point de terminaison plutôt qu’une adresse résolue, la plage de sources que le groupe de sécurité admet et le rôle de base de données que le développeur utilise. Ces trois faits expliquent la plupart des échecs futurs sans appel. Ajoutez aussi la version du profil client, car un changement de profil peut supprimer une route que l’ancien portait.

Testez ensuite le cas négatif une fois : un client hors de la source approuvée doit toujours être refusé.

Une base de données privée qui ne fonctionne que pour la personne qui l’a configurée n’est pas un accès privé ; c’est une exception non documentée qui attend d’être redécouverte. Écrivez le chemin, et le prochain développeur héritera d’une méthode au lieu d’un mystère.