Quelle adresse un pare-feu cloud voit une fois votre VPN activé
Un tunnel complet change l’adresse source que voit votre base de données. Déplacez la liste d’autorisation, le chemin privé ou le tunnel divisé, pas l’identifiant.
Une base de données qui fonctionne avant la connexion du VPN et échoue après relève rarement d’un problème d’identifiants. Les pare-feux cloud comparent des adresses source, et un tunnel complet remplace celle qu’ils comparaient. L’écart entre ce que vous croyez que votre ordinateur portable envoie et ce que le serveur reçoit constitue tout le défaut, et il se mesure en une étape.
Ce que devient l’adresse source
Dans un tunnel complet, chaque paquet sort par la passerelle VPN, si bien que le serveur voit l’adresse de sortie de la passerelle plutôt que votre connexion domestique. Si un proxy direct se trouve sur le chemin, c’est son adresse qui arrive. Toutes deux sont des sources légitimes, et aucune n’est l’adresse de votre règle d’origine.
Les règles de pare-feu d’Azure SQL au niveau du serveur et de la base de données comparent l’adresse du client qui atteint le serveur logique, laquelle, après un tunnel complet, est l’adresse de sortie. Un groupe de sécurité AWS qui autorise une seule adresse se comporte de la même façon. Le paquet est abandonné avant l’authentification, si bien que l’erreur renvoyée ressemble à une panne réseau plutôt qu’à un problème de permissions. C’est exactement pour cela que les gens commencent à réinitialiser des mots de passe.
Où la liste d’autorisation se décide
Lisez la règle qui correspond au chemin en échec, pas celle dont vous vous souvenez l’avoir créée. Notez sa portée, son port, son protocole et si elle est évaluée avant tout contrôle d’identité.
Décidez ensuite quelle couche possède légitimement la décision. Une règle d’adresse répond d’où vient le trafic. Un point de terminaison privé répond si le service est accessible par un chemin privé. Une exception de tunnel divisé répond quelles destinations contournent le tunnel. Elles ne sont pas interchangeables, et chacune échoue différemment lorsque le tunnel change.
Trois réparations, trois couches
Chaque option ci-dessous corrige le flux pour une raison différente, et choisir la mauvaise produit une connexion qui fonctionne jusqu’au prochain changement de passerelle.
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
Ajouter l’adresse de sortie est le plus petit changement et le plus fragile, car une nouvelle passerelle ou une autre région l’invalide silencieusement. Documentez l’adresse à côté de la définition du tunnel pour que les deux évoluent ensemble. Une plage large temporaire est un diagnostic, pas une réparation ; la laisser en place est la façon dont des services internes finissent exposés.
Pourquoi une plateforme gérée ne peut pas rejoindre le tunnel
Des plateformes applicatives comme Heroku, AppHarbor ou CloudBees exécutent votre code dans un environnement dépourvu de périphérique tun ou tap et sans privilèges pour en créer un. Leur modèle d’entrée est HTTP et non une socket d’écoute arbitraire. Un buildpack qui embarque un binaire VPN n’a toujours nulle part où placer l’interface. Les schémas viables sont une adresse de sortie statique que la base de données peut autoriser, un produit de connexion privée proposé par la plateforme ou un proxy dans une DMZ joignable en HTTPS.
Ce proxy est un chemin d’accès doté de sa propre authentification et de sa journalisation. Il ne fait pas de la plateforme un membre de votre VPN, et le décrire ainsi produit des règles que personne ne peut auditer.
Vérifiez depuis le client qui a échoué
Reconnectez-vous et répétez le chemin exact du client. Vérifiez l’adresse source que le service journalise, la route que le client choisit pour le nom de la base de données et le résultat de la requête réelle, dans cet ordre. Un test depuis la passerelle prouve que la passerelle fonctionne, ce qui n’a jamais fait de doute. Si la connexion s’authentifie désormais et que la requête échoue encore, le problème restant est l’autorisation de la base de données.
Revoyez ces règles chaque fois que le tunnel change. Une passerelle remplacée ou une nouvelle plage de sortie casse le chemin sans aucune modification de la configuration de l’application.