Unha IP VPN dedicada non publica o teu sitio web
Unha dirección de saída dedicada non di nada sobre a entrega entrante. Comproba o contrato de reenvío, completa o lado da orixe e logo publica un porto alto.
Comprar unha IP dedicada a un provedor de VPN parece comprar unha porta de entrada. A dirección é estable, o túnel está levantado e, aínda así, o sitio non carga para ninguén de fóra. O que compraches é unha asignación, non unha regra de reenvío entrante. As dúas cousas véndense na mesma tenda e configúranse en lugares completamente distintos.
A dirección é unha asignación, non unha regra de reenvío
Anota a dirección pública entrante ou o nome de host, o transporte permitido, o porto externo asignado e o destino do lado do cliente ao que entrega o provedor. Despois confirma que o servidor, o protocolo e a función de conta que escolliches admiten realmente o reenvío, e que o provedor permite aloxar nel.
Dedicada describe a asignación de dirección. Non significa que se permita tráfico entrante non solicitado, e distintos complementos do mesmo operador poden ter capacidades diferentes. A dirección dedicada e o produto de servidor dedicado son as dúas etiquetas que máis se confunden, e as páxinas de asistencia adoitan aclarar cal das dúas reenvía.
| 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 contrato ilustrativo vese así: o provedor entrega TCP 203.0.113.60:45000 ao servizo HTTPS do teu dispositivo conectado no porto 8443. Iso describe unha asignación que configurou outra persoa, non unha regra que poidas crear no seu bordo escribíndoa no teu propio cortalumes.
Completa o lado da orixe
Se a aplicación web se executa no propio cliente de VPN, necesita un oínte no porto entregado e un permiso de entrada local acoutado para ese porto. Se o cliente reenvía a conexión asignada a outro host, necesita a tradución de destino, a política de reenvío e unha ruta de resposta que sobreviva á ida e volta.
Desena as regras de acceso arredor da dirección de orixe que a ruta do provedor presenta realmente. Non sempre é o visitante orixinal, e tampouco sempre é o servidor de VPN, o que importa cando escribes unha regra que só coincidiría cunha desas direccións.
A tradución de portos tampouco converte HTTP en HTTPS. O porto público e o porto local da aplicación poden diferir libremente, pero o esquema, a identidade do certificado e as redireccións seguen tendo que coincidir co servizo que a xente alcanza de verdade. Se o certificado nomea o host público, mantén ese nome en cada salto. Unha discrepancia aquí aparece como un aviso do navegador e non como un fallo de encamiñamento, o que manda a xente aos rexistros equivocados durante unha hora.
Publica o porto alto con honestidade
Se os visitantes se conectan directamente e o provedor asignou un porto alto, dálles a URL completa. Un rexistro de dirección DNS normal non pode engadir un porto a unha petición HTTPS que por defecto usa 443, e ningún axuste do TTL o cambia.
Un frontend web pode resolvelo aceptando visitantes no porto habitual e facendo a súa propia conexión ao porto de orixe reenviado. Porén, os portos proxy por defecto de Cloudflare son unha lista definida, e un porto asignado arbitrario non se converte nun porto de bordo admitido só porque engadiches un rexistro DNS proxyficado.
Cambiar o porto de destino da orixe é unha operación distinta de cambiar o porto do visitante. As Origin Rules de Cloudflare documentan unha substitución do porto de destino para a conexión co backend, limitada a unha regra, un esquema e un nome de host admitidos. Unha substitución de porto non é un relé xenérico para UDP arbitrario nin para outros protocolos.
Cando un frontend remata TLS, valida ambos saltos: o certificado do navegador ao frontend e a conexión do frontend á orixe. O salto VPN non substitúe ningunha das dúas comprobacións, e que unha dirección interna se filtre en redireccións ou cookies é o sinal habitual de que só unha das dúas se configurou pensando no nome público.
Mantén viva a asignación
Algúns provedores asignan un porto distinto tras unha reconexión, e unha asignación alugada pode requirir renovación mediante unha acción do provedor. Segue o mecanismo que documenta o teu provedor e actualiza o oínte, as regras locais, o DNS ou a regra do frontend só onde o contrato actual o esixa.
Unha dirección pública estática non fai estático o alugueiro do porto. Unha dirección e un porto que aínda se mostran nun panel non son proba de que a sesión activa posúa a asignación, por iso a proba é unha petición nova desde fóra e non unha captura de pantalla.
Logo repite os casos que esperas: unha reconexión normal e unha perda de VPN. Se a perda debe deixar a orixe inaccesible, non deixes que un actualizador volva publicar en silencio unha ruta directa do ISP en segundo plano. E se o contrato de reenvío non pode cumprir os requisitos de estabilidade do sitio, escolle outra disposición de publicación en lugar de comprar outra etiqueta de dirección e esperar que se comporte como un servidor.