Por que o seu URL precisa de uma entrada na porta 80 ou 443, e não na 45000

Digite um nome de host num navegador e o esquema decide a porta de destino: 80 para http, 443 para https. Nada numa resposta DNS anula isso, e nenhuma regra de encaminhamento na sua máquina pode inventar um ouvinte na borda do provedor. Quando um provedor de VPN lhe dá uma porta pública alta como 45000, um URL explícito funciona e um limpo não. A lacuna está no ponto de entrada, não dentro da aplicação.

Percorra o caminho do navegador até o processo uma vez, e as três opções de publicação deixam de parecer misteriosas.

Veja para onde o pedido realmente vai

O navegador resolve o nome para um endereço e depois se conecta a esse endereço na porta padrão do esquema, a menos que o URL indique outra. A borda do seu provedor decide o que acontece com a conexão entrante. Se a tabela de encaminhamento dela só mapeia 45000 para o seu endereço interno, uma conexão para 80 não tem para onde ir e é recusada ou descartada antes de a sua máquina ser envolvida.

Essa recusa acontece na borda, por isso os registos da sua aplicação não mostram nada. A ausência de registos é prova de onde o pacote parou, não prova de que a aplicação está avariada.

Por que uma regra local não consegue corrigir a borda

Um redirecionamento ou uma regra DNAT no host da aplicação atua sobre pacotes que já chegaram. Os pacotes enviados para a porta 80 no provedor nunca chegam, portanto a regra nunca é avaliada. Esta é a hora mais desperdiçada de todo o problema.

O DNS também não consegue transportar a porta. especificação HTTP define os valores padrão do esquema, e um registo A ou AAAA devolve um endereço enquanto um CNAME devolve outro nome. O navegador continua a concatenar a porta do esquema, portanto só uma porta explícita no URL muda o destino.

Opção um: manter a porta explícita

Muitas vezes a resposta correta é a pouco glamorosa. Publique o URL completo com a porta, termine TLS numa entrada que o suporte e garanta que cada ligação gerada mantém a mesma origem. Para um público pequeno e controlado isto é completo, e não custa nada além de um número de porta visível.

Verifique os redirecionamentos e o âmbito dos cookies enquanto está aí, porque um backend que escreve o seu próprio nome de host num cabeçalho Location desfaz o arranjo.

Opção dois: obter uma entrada real na porta padrão

Alguns provedores e soluções de alojamento encaminham 80 e 443 num endereço partilhado ou dedicado como serviço documentado. Pergunte o que está realmente incluído em vez de assumir que um endereço de saída público implica portas de entrada arbitrárias. Um endereço de saída dedicado não diz nada sobre o encaminhamento de entrada.

Confirme a propriedade e a disponibilidade por escrito, incluindo o que acontece à entrada quando o túnel se reconecta com um endereço diferente. Uma entrada que se desloca com o túnel produz falhas que parecem avarias de DNS.

Opção três: colocar um frontend à frente

Um proxy inverso num endereço acessível pode escutar na 443 e terminar TLS e abrir uma ligação separada ao backend através da VPN. Os visitantes veem o nome e a porta padrão do frontend, enquanto o frontend fala com a porta alta do backend em seu nome. Isto funciona porque muda a arquitetura em vez de lutar contra o ponto de entrada. O backend passa então a não precisar de qualquer porta de entrada na internet pública.

Também muda o que opera. O frontend detém o TLS público, a política de acesso, os registos e a disponibilidade, e tem de limitar a seleção do backend ao serviço previsto. Se o salto do frontend para o backend usar HTTPS, mantenha a validação do certificado nesse salto.

Mantenha uma só origem

O nome de host público, o esquema e a porta do frontend formam a origem que os visitantes usam, por isso configure o URL externo da aplicação, os redirecionamentos e os cookies para essa origem. Envie o host original e o esquema reencaminhado se a aplicação constrói ligações absolutas. Uma resposta que devolve os utilizadores a um nome privado ou a uma porta alta desfaz a entrada limpa que acabou de construir.

Depois decida pensando no público. Um URL curto pode justificar um frontend gerido, e não vale a pena transformar por acidente um serviço privado só para VPN num público.