Pourquoi votre URL a besoin d’une entrée sur le port 80 ou 443, et non 45000

Tapez un nom d’hôte dans un navigateur et le schéma décide du port de destination : 80 pour http, 443 pour https. Rien dans une réponse DNS ne le supplante, et aucune règle de redirection sur votre machine ne peut inventer un écouteur en bordure de votre fournisseur. Quand un fournisseur VPN vous attribue un port public élevé comme 45000, une URL explicite fonctionne et une URL propre non. L’écart se situe au point d’entrée, pas à l’intérieur de l’application.

Parcourez une fois le chemin du navigateur au processus, et les trois options de publication cessent de paraître mystérieuses.

Regardez où va réellement la requête

Le navigateur résout le nom en une adresse, puis se connecte à cette adresse sur le port par défaut du schéma, sauf si l’URL en nomme un autre. La bordure de votre fournisseur décide de ce qui arrive à la connexion entrante. Si sa table de redirection n’associe que 45000 à votre adresse interne, une connexion au 80 n’a nulle part où aller et est refusée ou abandonnée avant même que votre machine n’intervienne.

Ce refus se produit en bordure, c’est pourquoi les journaux de votre application ne montrent rien du tout. L’absence de journaux est une preuve de l’endroit où le paquet s’est arrêté, pas une preuve que l’application est cassée.

Pourquoi une règle locale ne peut pas réparer la bordure

Une redirection ou une règle DNAT sur l’hôte de l’application agit sur des paquets déjà arrivés. Les paquets envoyés au port 80 chez le fournisseur n’arrivent jamais, donc la règle n’est jamais évaluée. C’est l’heure la plus souvent perdue de tout le problème.

DNS ne peut pas non plus porter le port. spécification HTTP définit les valeurs par défaut du schéma, et un enregistrement A ou AAAA renvoie une adresse tandis qu’un CNAME renvoie un autre nom. Le navigateur concatène toujours le port du schéma, donc seul un port explicite dans l’URL change la destination.

Première option : garder le port explicite

Souvent, la bonne réponse est la moins spectaculaire. Publiez l’URL complète avec le port, terminez TLS sur une entrée qui le prend en charge, et assurez-vous que chaque lien généré conserve la même origine. Pour un public restreint et contrôlé, c’est complet, et cela ne coûte rien au-delà d’un numéro de port visible.

Vérifiez les redirections et la portée des cookies pendant que vous y êtes, car un backend qui écrit son propre nom d’hôte dans un en-tête Location annule l’arrangement.

Deuxième option : obtenir une vraie entrée sur le port par défaut

Certains fournisseurs et solutions d’hébergement redirigent 80 et 443 sur une adresse partagée ou dédiée en tant que service documenté. Demandez ce qui est réellement inclus au lieu de supposer qu’une adresse de sortie publique implique des ports entrants arbitraires. Une adresse sortante dédiée ne dit rien du transfert entrant.

Confirmez la propriété et la disponibilité par écrit, y compris ce qui arrive à l’entrée lorsque le tunnel se reconnecte avec une adresse différente. Une entrée qui se déplace avec le tunnel produit des pannes qui ressemblent à des défaillances DNS.

Troisième option : placer un frontend devant

Un proxy inverse sur une adresse accessible peut écouter sur 443 et terminer TLS et ouvrir une connexion séparée vers le backend via le VPN. Les visiteurs voient le nom et le port par défaut du frontend, tandis que le frontend parle au port élevé du backend en votre nom. Cela fonctionne parce que cela change l’architecture au lieu de lutter contre le point d’entrée. Le backend n’a alors plus du tout besoin de port entrant sur l’internet public.

Cela change aussi ce que vous exploitez. Le frontend possède le TLS public, la politique d’accès, les journaux et la disponibilité, et il doit limiter la sélection du backend au service prévu. Si le saut du frontend au backend utilise HTTPS, conservez la validation du certificat sur ce saut.

Gardez une seule origine

Le nom d’hôte public, le schéma et le port du frontend forment l’origine utilisée par les visiteurs, alors configurez l’URL externe de l’application, les redirections et les cookies pour cette origine. Envoyez l’hôte d’origine et le schéma transmis si l’application construit des liens absolus. Une réponse qui renvoie les utilisateurs vers un nom privé ou un port élevé annule l’entrée propre que vous venez de construire.

Décidez ensuite en pensant au public. Une URL courte peut justifier un frontend géré, et cela ne vaut pas la peine de transformer accidentellement un service privé réservé au VPN en service public.