Por que o proxy de Cloudflare non pode transportar OpenVPN cun só nome

Unha soa máquina executa o sitio web e o servidor OpenVPN, e a tentación é apuntar un único nome de host cara a ela e deixar que a nube laranxa ordene o tráfico. O proxy ordena HTTP e HTTPS. Non ordena unha sesión de OpenVPN, sexa cal sexa o porto que use esa sesión. Dous nomes, un directo e outro con proxy, non custan nada e eliminan toda a clase de confusión.

Dous nomes, dous transportes

Dálle ao sitio web un rexistro con proxy para que o seu tráfico HTTP e HTTPS pase por Cloudflare. Dálle á VPN un rexistro só DNS que resolva directamente á entrada pública da VPN, e deixa que o cliente use o porto UDP ou TCP para o que está configurado.

Ambos os nomes poden acabar na mesma máquina de orixe. A diferenza é o que ocorre entre o cliente e esa máquina, e esa diferenza é o sentido da separación.

A referencia de portos de rede de Cloudflare enumera que portos acepta o proxy web ordinario. Esa lista trata de HTTP e HTTPS neses portos, non de protocolos arbitrarios que casualmente comparten un número.

O porto non é o protocolo

Mover OpenVPN a TCP 443 non o converte en HTTPS. O proxy segue esperando unha petición HTTP ao comezo da conexión, e un cliente OpenVPN envía no seu lugar unha mensaxe de control binaria. A conexión falla dun xeito que parece un bloqueo de rede porque nada útil chega a un rexistro.

Se o requisito é de verdade pór un produto de Cloudflare na ruta de datos da VPN, avalía un que documente compatibilidade co protocolo que necesitas. Non supoñas que a nube laranxa é un túnel TCP ou UDP xeral, porque é un proxy inverso para tráfico web cunha tarefa concreta.

Un rexistro só DNS é a resposta aburrida que funciona, e é a primeira á que hai que recorrer.

Unha máquina segue necesitando dous oíntes

Os nomes separados non permiten que dous procesos liguen o mesmo enderezo, porto e transporte ao mesmo tempo. Se o servidor web xa ocupa TCP 443 en todos os enderezos, unha instancia de OpenVPN non pode tomalo tamén sen un acordo deliberado.

Liga o oínte da VPN a un porto distinto, ou a un enderezo distinto, ou pon diante un multiplexor documentado e acepta o custo operativo que conleva. Cada unha desas decisións debe verse nas regras da devasa, porque un oínte que ninguén documentou é o que se pasa por alto durante un incidente. Escribe a ligazón escolleita no mesmo runbook que describe o túnel. Así a seguinte persoa non o redescobre ás dúas da madrugada.

Os certificados seguen a conexión que protexen

A conexión TLS do navegador con Cloudflare e a conexión de Cloudflare coa túa orixe son dúas relacións separadas con dous certificados separados. O navegador ve un certificado de bordo. A orixe presenta o seu propio certificado a Cloudflare, e un certificado Cloudflare Origin CA está pensado exactamente para esa segunda relación.

Ese certificado de orixe é de confianza para Cloudflare no modo Full (strict) e non é un certificado de navegador de confianza xeral. Se alguén visita directamente o nome de host só DNS e recibe un aviso, é a consecuencia esperada dunha ruta de confianza cambiada, non a proba de que o cifrado se detivese.

Por iso un sitio web visitado directamente necesita unha cadea de certificados na que confíen os seus navegadores. Iso pode convivir cun sitio con proxy cuxa orixe non está pensada para visitarse en absoluto.

OpenVPN leva a súa propia identidade de servidor e autenticación de cliente, coa súa propia autoridade de certificación e a súa propia protección da canle de control. Un candado no sitio web non achega nada diso, e os dous procesos de aprovisionamento deben permanecer separados.

A exposición segue o nome

Un rexistro VPN só DNS publica o enderezo ao que apunta. Se ese enderezo é tamén a orixe web, a orixe non queda oculta, e describilo como oculto porque o outro nome usa proxy é un erro que dura ata que alguén o escanea.

Decide que peticións web poden chegar directamente á orixe e aplícao na orixe, e despois permite o oínte da VPN nos seus propios termos. As páxinas de administración, as descargas de perfís e o oínte de datos poden ter tres requisitos de exposición distintos mesmo cando un só paquete fornece os tres.

Mantén as ligazóns xeradas no nome web público e no esquema HTTPS, e mantén os perfís de cliente no nome da VPN co protocolo e o porto reais. Ningún dos dous servizos debería depender de cambiar o axuste de proxy do outro durante o funcionamento normal.

Orde de traballo: nome con proxy para o sitio, nome só DNS para a VPN, oíntes distintos, certificado por relación e despois unha proba que demostre que cada nome só chega ao servizo que debe.