Une IP VPN dédiée ne publie pas votre site web
Une adresse de sortie dédiée ne dit rien de la livraison entrante. Vérifiez le contrat de redirection, terminez le côté origine, puis publiez un port haut.
Acheter une IP dédiée chez un fournisseur VPN, c’est comme acheter une porte d’entrée. L’adresse est stable, le tunnel est monté, et le site ne se charge toujours pas pour qui que ce soit de l’extérieur. Ce que vous avez acheté, c’est une attribution, pas une règle de redirection entrante. Les deux se vendent dans la même boutique et se configurent à des endroits complètement différents.
L’adresse est une attribution, pas une règle de redirection
Notez l’adresse publique entrante ou le nom d’hôte, le transport autorisé, le port externe attribué et la destination côté client à laquelle le fournisseur livre. Confirmez ensuite que le serveur, le protocole et la fonction de compte que vous avez choisis prennent réellement en charge la redirection, et que le fournisseur autorise l’hébergement dessus.
Dédié décrit l’attribution d’adresse. Cela ne signifie pas que le trafic entrant non sollicité est autorisé, et différents modules du même opérateur peuvent avoir des capacités différentes. L’adresse dédiée et le produit serveur dédié sont les deux libellés que l’on confond le plus souvent, et les pages d’assistance précisent généralement lequel redirige.
| What you have | What it gives you | What it does not |
|---|---|---|
| Dedicated exit address | A stable source address for outbound traffic | Any inbound delivery at all |
| Port-forwarding add-on | A provider-side mapping to your session | Permanence across reconnects |
| Local DNAT rule | Handling for packets that arrive | Making packets arrive |
Un contrat illustratif ressemble à ceci : le fournisseur livre TCP 203.0.113.60:45000 au service HTTPS de votre appareil connecté sur le port 8443. C’est la description d’une correspondance configurée par quelqu’un d’autre, pas une règle que vous pouvez créer à leur périphérie en la tapant dans votre propre pare-feu.
Terminez le côté origine
Si l’application web tourne sur le client VPN lui-même, elle a besoin d’un écouteur sur le port livré et d’une autorisation d’entrée locale limitée à ce port. Si le client redirige la connexion mappée vers un autre hôte, il a besoin de la traduction de destination, de la politique de redirection et d’un chemin de retour qui survive à l’aller-retour.
Concevez les règles d’accès autour de l’adresse source que le chemin du fournisseur présente réellement. Ce n’est pas toujours le visiteur d’origine, et ce n’est pas toujours le serveur VPN non plus, ce qui compte quand vous écrivez une règle qu’une seule de ces adresses satisferait.
La traduction de port ne transforme pas non plus HTTP en HTTPS. Le port public et le port local de l’application peuvent différer librement, mais le schéma, l’identité du certificat et les redirections doivent toujours correspondre au service que les gens atteignent réellement. Si le certificat nomme l’hôte public, gardez ce nom à chaque saut. Une incohérence ici apparaît comme un avertissement de navigateur et non comme un échec de routage, ce qui envoie les gens vers les mauvais journaux pendant une heure.
Publiez le port haut honnêtement
Si les visiteurs se connectent directement et que le fournisseur a attribué un port haut, donnez-leur l’URL complète. Un enregistrement d’adresse DNS ordinaire ne peut pas ajouter de port à une requête HTTPS qui utilise 443 par défaut, et aucun réglage du TTL n’y change rien.
Un frontend web peut résoudre cela en acceptant les visiteurs sur le port habituel et en établissant sa propre connexion vers le port d’origine redirigé. Les ports proxy par défaut de Cloudflare sont toutefois une liste définie, et un port attribué arbitrairement ne devient pas un port de périphérie pris en charge parce que vous avez ajouté un enregistrement DNS proxifié.
Changer le port de destination de l’origine est une opération différente de changer le port du visiteur. Les Origin Rules de Cloudflare documentent une substitution du port de destination pour la connexion au backend, limitée à une règle, un schéma et un nom d’hôte pris en charge. Une substitution de port n’est pas un relais générique pour de l’UDP arbitraire ni pour d’autres protocoles.
Quand un frontend termine le TLS, validez les deux sauts : le certificat du navigateur vers le frontend et la connexion du frontend vers l’origine. Le saut VPN ne remplace aucun des deux contrôles, et une adresse interne qui fuit dans les redirections ou les cookies est le signe habituel qu’un seul des deux a été configuré en pensant au nom public.
Maintenez le mappage en vie
Certains fournisseurs attribuent un port différent après une reconnexion, et un mappage loué peut nécessiter un renouvellement par une action côté fournisseur. Suivez le mécanisme que votre fournisseur documente, et ne mettez à jour l’écouteur, les règles locales, le DNS ou la règle du frontend que là où le contrat actuel l’exige.
Une adresse publique statique ne rend pas le bail de port statique. Une adresse et un port encore affichés dans un tableau de bord ne prouvent pas que la session active possède le mappage, c’est pourquoi le test est une requête fraîche depuis l’extérieur plutôt qu’une capture d’écran.
Répétez ensuite les cas que vous attendez : une reconnexion normale et une perte de VPN. Si la perte doit rendre l’origine indisponible, ne laissez pas un outil de mise à jour republier discrètement un chemin ISP direct en arrière-plan. Et si le contrat de redirection ne peut pas répondre aux exigences de stabilité du site, choisissez une autre organisation de publication plutôt que d’acheter une nouvelle étiquette d’adresse en espérant qu’elle se comporte comme un serveur.