Un VPN commercial bloque-t-il le port 5432 ? Comparez vos options

L'application parlait à sa base de données depuis le bureau chaque jour. Puis quelqu'un a activé le client VPN commercial sur le même ordinateur portable, et la connexion a commencé à se réinitialiser après la poignée de main. Rien dans l'application n'a changé, le tunnel se déclare sain, et le pare-feu que vous contrôlez n'a aucune règle de blocage. Ce qui a changé, c'est le chemin de sortie : les serveurs du fournisseur sont des points de sortie partagés à fort volume, et les fournisseurs filtrent les ports sortants pour réduire les abus. Les ports de base de données et de soumission de courrier en prennent la plus grande part, car ce sont eux qui attirent l'analyse et le spam depuis un pool d'adresses anonyme.

Le test de cinq minutes qui sépare le filtrage de tout le reste

Depuis la même machine, sondez un port qui doit être ouvert et le port qui échoue, sur le même hôte, tunnel actif puis coupé. Utilisez la même commande les deux fois pour que la seule variable soit le tunnel :

Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432

Quatre résultats couvrent presque tous les cas. Si le 443 fonctionne et que le 5432 échoue seulement avec le tunnel actif, vous observez un filtrage de ports sur le chemin de sortie. Si les deux échouent avec le tunnel actif et que les deux fonctionnent sans lui, le problème vient du routage ou du DNS, pas de la politique de ports. Si les deux ports se connectent mais que l'application échoue encore, la faute est à l'authentification ou à TLS, pas à la joignabilité. Et si un seul emplacement de serveur du fournisseur échoue, c'est une politique par serveur : essayez un autre emplacement avant de toucher à une quelconque configuration.

Option un : tunnel séparé pour le sous-réseau de la base de données

Si l'ordinateur portable n'a besoin du VPN commercial que pour d'autres usages, excluez la plage d'adresses de la base de données du tunnel afin que le trafic n'entre jamais dans la sortie partagée. C'est l'option la plus propre lorsque les deux chemins n'ont vraiment pas besoin de se rejoindre, et elle ne coûte rien de plus qu'une règle de routage que vous pouvez documenter. Le compromis est que le tunnel séparé introduit une seconde surface de politique : ce qui est exclu du tunnel doit être délibéré, pas un effet secondaire d'un sous-réseau ajouté plus tard par quelqu'un.

Il cesse de fonctionner dès que la base de données vit à l'intérieur du réseau que le VPN est censé atteindre, alors vérifiez-le avant de vous engager.

Option deux : votre propre point de sortie, votre propre sortie

Faire tourner un petit point de sortie VPN sur un VPS vous donne le contrôle de la politique de sortie, et aucun pool partagé n'est impliqué. C'est l'option qui mérite une comparaison honnête avec le client commercial : vous gagnez une adresse source prévisible et vous perdez l'empreinte mondiale et la commodité du fournisseur. Pour une équipe qui a besoin des ports de base de données et de courrier toute la journée, le compromis penche généralement en faveur de la possession du point de sortie, car le mode de défaillance devient votre propre mauvaise configuration plutôt que la politique anti-abus de quelqu'un d'autre.

Comparez les deux sur la stabilité de l'adresse source, sur qui peut lire votre trafic et sur ce qui se passe le jour où le fournisseur du point de sortie change son propre filtrage.

Option trois : sortez l'ordinateur portable du chemin

Une tâche CI, un conteneur planifié ou un hôte bastion à l'intérieur du réseau autorisé ne dépend pas de l'état du tunnel d'une personne. Atteignez la base de données par tunnel SSH depuis un hôte déjà autorisé, et l'ordinateur portable ne parle jamais directement au port. C'est l'option qui passe à l'échelle quand plusieurs personnes rencontrent la même restriction, et c'est aussi celle qui supprime le problème au lieu de le contourner.

Elle demande plus de travail en amont qu'une règle de tunnel séparé, et elle n'aide pas la personne qui a besoin d'une session interactive tout de suite.

Pourquoi ajouter l'adresse du fournisseur à une liste d'autorisation est la mauvaise comparaison

Ajouter l'adresse de sortie du fournisseur à une liste d'autorisation de base de données fonctionne, et accorde aussi l'accès à tous les autres abonnés qui partagent cette adresse à ce moment-là. Pour une réplique en lecture seule derrière un compte applicatif accordé de façon étroite, l'exposition peut être tolérable pendant un jour. Pour tout ce qui est inscriptible, ce n'est pas un compromis qui mérite d'être nommé, et les adresses de sortie rotatives l'aggravent : chaque changement de serveur casse la règle, et la maintenance invite des entrées CIDR larges qui anéantissent l'intérêt d'une liste d'autorisation.

Les adresses dédiées ou statiques, là où le fournisseur les vend, sont la seule version de cela qui passe à l'échelle. Liez la liste d'autorisation à une adresse qui n'est qu'à vous, ou ne la liez pas du tout.

Quoi que vous choisissiez, notez le chemin et la raison. La personne suivante rencontrera la même connexion réinitialisée et commencera par accuser l'application.