Por que o proxy da Cloudflare não pode transportar o OpenVPN num único nome

Uma só máquina executa o site e o servidor OpenVPN, e a tentação é apontar um único nome de anfitrião para ela e deixar a nuvem laranja tratar do tráfego. O proxy trata de HTTP e HTTPS. Não trata de uma sessão OpenVPN, seja qual for a porta que essa sessão use. Dois nomes, um direto e outro pelo proxy, não custam nada e eliminam toda essa classe de confusão.

Dois nomes, dois transportes

Dê ao site um registro com proxy para que o tráfego HTTP e HTTPS passe pela Cloudflare. Dê à VPN um registro só de DNS que resolva diretamente para a entrada pública da VPN, e deixe o cliente usar a porta UDP ou TCP para a qual está configurado.

Ambos os nomes podem acabar na mesma máquina de origem. A diferença está no que acontece entre o cliente e essa máquina, e essa diferença é o sentido da separação.

A referência de portas de rede da Cloudflare lista as portas que o proxy web comum aceita. Essa lista trata de HTTP e HTTPS nessas portas, não de protocolos arbitrários que por acaso partilham um número.

A porta não é o protocolo

Mover o OpenVPN para TCP 443 não o transforma em HTTPS. O proxy continua à espera de um pedido HTTP no início da conexão, e um cliente OpenVPN envia antes uma mensagem de controlo binária. A conexão falha de uma forma que parece um bloqueio de rede porque nada de útil chega a um registo.

Se o requisito é mesmo colocar um produto da Cloudflare no caminho de dados da VPN, avalie um que documente suporte para o protocolo de que precisa. Não assuma que a nuvem laranja é um túnel TCP ou UDP genérico, porque é um proxy inverso para tráfego web com uma tarefa específica.

Um registro só de DNS é a resposta aborrecida que funciona, e é a primeira a que se deve recorrer.

Uma máquina continua a precisar de dois ouvintes

Nomes separados não permitem que dois processos liguem o mesmo endereço, porta e transporte ao mesmo tempo. Se o servidor web já ocupa o TCP 443 em todos os endereços, uma instância do OpenVPN não o pode também ocupar sem um acordo deliberado.

Ligue o ouvinte da VPN a uma porta diferente, ou a um endereço diferente, ou coloque à frente um multiplexador documentado e aceite o custo operacional que isso traz. Cada uma dessas escolhas deve ser visível nas regras da firewall, porque um ouvinte que ninguém documentou é o que passa despercebido durante um incidente. Escreva a ligação escolhida no mesmo runbook que descreve o túnel. Assim a pessoa seguinte não o redescobre às duas da manhã.

Os certificados seguem a conexão que protegem

A conexão TLS do navegador para a Cloudflare e a conexão da Cloudflare para a sua origem são duas relações separadas com dois certificados separados. O navegador vê um certificado de extremidade. A origem apresenta o seu próprio certificado à Cloudflare, e um certificado Cloudflare Origin CA destina-se exatamente a essa segunda relação.

Esse certificado de origem é fidedigno para a Cloudflare no modo Full (strict) e não é um certificado de navegador fidedigno em geral. Se alguém visitar diretamente o nome de anfitrião só de DNS e receber um aviso, é a consequência esperada de um caminho de confiança alterado, não a prova de que a cifra parou.

Por isso um site visitado diretamente precisa de uma cadeia de certificados em que os seus navegadores confiem. Isso pode coexistir com um site com proxy cuja origem não se destina de todo a ser visitada.

O OpenVPN transporta a sua própria identidade de servidor e autenticação de cliente, com a sua própria autoridade de certificação e a sua própria proteção do canal de controlo. Um cadeado no site não fornece nada disso, e os dois processos de aprovisionamento devem ficar separados.

A exposição segue o nome

Um registro VPN só de DNS publica o endereço para onde aponta. Se esse endereço for também a origem web, a origem não está escondida, e descrevê-la como escondida porque o outro nome está com proxy é um erro que dura até alguém a procurar.

Decida que pedidos web podem chegar diretamente à origem e aplique isso na origem, depois permita o ouvinte da VPN nos seus próprios termos. Páginas de gestão, transferências de perfis e o ouvinte de dados podem ter três requisitos de exposição diferentes mesmo quando um só pacote fornece os três.

Mantenha as ligações geradas no nome web público e no esquema HTTPS, e mantenha os perfis de cliente no nome da VPN com o protocolo e a porta reais. Nenhum dos serviços deve depender de inverter a definição de proxy do outro durante o funcionamento normal.

Ordem de trabalho: nome com proxy para o site, nome só de DNS para a VPN, ouvintes distintos, certificado por relação, e depois um teste que prove que cada nome só chega ao serviço a que deve.