Um IP VPN dedicado não publica o seu site
Um endereço de saída dedicado não diz nada sobre a entrega de entrada. Verifique o contrato de encaminhamento, conclua o lado da origem e só então publique uma porta alta.
Comprar um IP dedicado a um fornecedor de VPN parece comprar uma porta de entrada. O endereço é estável, o túnel está de pé, e o site continua sem carregar para ninguém de fora. O que comprou foi uma atribuição, não uma regra de encaminhamento de entrada. As duas vendem-se na mesma loja e configuram-se em locais completamente diferentes.
O endereço é uma atribuição, não uma regra de encaminhamento
Registe o endereço público de entrada ou o nome do anfitrião, o transporte permitido, a porta externa atribuída e o destino do lado do cliente para onde o fornecedor entrega. Depois confirme que o servidor, o protocolo e a funcionalidade da conta que escolheu realmente suportam encaminhamento, e que o fornecedor permite alojamento nele.
Dedicado descreve a atribuição do endereço. Não significa que o tráfego de entrada não solicitado seja permitido, e complementos diferentes do mesmo operador podem ter capacidades diferentes. O endereço dedicado e o produto de servidor dedicado são os dois rótulos que mais se confundem, e as páginas de apoio costumam esclarecer qual dos dois encaminha.
| 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 |
Um contrato ilustrativo é assim: o fornecedor entrega TCP 203.0.113.60:45000 ao serviço HTTPS do seu dispositivo ligado na porta 8443. Isso descreve um mapeamento que outra pessoa configurou, não uma regra que possa criar na margem deles escrevendo-a na sua própria firewall.
Conclua o lado da origem
Se a aplicação web corre no próprio cliente VPN, precisa de um ouvinte na porta entregue e de uma permissão de entrada local limitada para essa porta. Se o cliente encaminha a ligação mapeada para outro anfitrião, precisa da tradução de destino, da política de encaminhamento e de um caminho de resposta que resista à ida e volta.
Desenhe as regras de acesso em torno do endereço de origem que o caminho do fornecedor realmente apresenta. Não é sempre o visitante original, e também não é sempre o servidor VPN, o que importa quando escreve uma regra a que só um desses endereços corresponderia.
A tradução de portas também não converte HTTP em HTTPS. A porta pública e a porta local da aplicação podem diferir livremente, mas o esquema, a identidade do certificado e os redirecionamentos continuam a ter de corresponder ao serviço que as pessoas realmente alcançam. Se o certificado nomeia o anfitrião público, mantenha esse nome em cada salto. Uma incoerência aqui aparece como aviso do navegador e não como falha de encaminhamento, o que manda as pessoas para os registos errados durante uma hora.
Publique a porta alta com honestidade
Se os visitantes se ligam diretamente e o fornecedor atribuiu uma porta alta, dê-lhes o URL completo. Um registo de endereço DNS comum não pode acrescentar uma porta a um pedido HTTPS que usa 443 por omissão, e nenhum ajuste do TTL muda isso.
Um frontend web pode resolver isto aceitando visitantes na porta habitual e fazendo a sua própria ligação à porta de origem encaminhada. No entanto, as portas de proxy predefinidas da Cloudflare são uma lista definida, e uma porta atribuída arbitrariamente não passa a ser uma porta de borda suportada só porque acrescentou um registo DNS com proxy.
Mudar a porta de destino da origem é uma operação diferente de mudar a porta do visitante. As Origin Rules da Cloudflare documentam uma substituição da porta de destino para a ligação ao backend, limitada a uma regra, um esquema e um nome de anfitrião suportados. Uma substituição de porta não é um relay genérico para UDP arbitrário nem para outros protocolos.
Quando um frontend termina o TLS, valide ambos os saltos: o certificado do navegador para o frontend e a ligação do frontend para a origem. O salto VPN não substitui nenhuma das duas verificações, e uma fuga de endereço interno para redirecionamentos ou cookies é o sinal habitual de que só uma das duas foi configurada a pensar no nome público.
Mantenha o mapeamento vivo
Alguns fornecedores atribuem uma porta diferente após uma religação, e um mapeamento alugado pode exigir renovação através de uma ação do lado do fornecedor. Siga o mecanismo que o seu fornecedor documenta e atualize o ouvinte, as regras locais, o DNS ou a regra do frontend apenas onde o contrato atual o exigir.
Um endereço público estático não torna a locação da porta estática. Um endereço e uma porta ainda mostrados num painel não provam que a sessão ativa detém o mapeamento, por isso o teste é um pedido novo de fora e não uma captura de ecrã.
Depois repita os casos que espera: uma religação normal e uma perda de VPN. Se a perda deve tornar a origem inacessível, não deixe que um atualizador volte a publicar em silêncio um caminho ISP direto em segundo plano. E se o contrato de encaminhamento não conseguir cumprir os requisitos de estabilidade do site, escolha outra disposição de publicação em vez de comprar outro rótulo de endereço e esperar que se comporte como um servidor.