OpenVPN e HTTPS na porta 443: de quem é o listener?

Dois serviços podem ambos responder na porta 443 sem nunca competir, porque um listener é definido pelo transporte, pelo endereço e pela porta em conjunto, não apenas pelo número. Coloque um servidor web e o OpenVPN na mesma máquina, e a única pergunta que merece resposta primeiro é qual socket cada processo pede ao núcleo. Anote essa lista antes de editar uma configuração, e a maioria dos erros «endereço já em uso» se explica sozinha. Tudo depois da lista é uma escolha entre um listener UDP, um socket TCP compartilhado ou um front-end que encaminha por protocolo.

Comece pelo socket que cada processo pede

Um bind tem êxito ou falha nessa tríade, então dois daemons só colidem quando as três partes coincidem. É por isso que um site em TCP 443 coexiste indefinidamente com um listener OpenVPN em UDP 443, e por isso mover um deles para um segundo endereço local no mesmo host também encerra a discussão. Leia os listeners vivos em vez dos arquivos que deveriam tê-los criado, porque um include obsoleto ou um arquivo unit esquecido sobrevive à edição que você lembra de ter feito.

Execute ss -lntup como root e leia cada linha que mencione 443, incluindo as entradas IPv6. Um listener v6 curinga normalmente também aceita tráfego v4, e é assim que um listener esquecido mantém a porta ocupada depois que você altera o arquivo que julgava responsável. Se um nome de processo o surpreender, restrinja a saída com ss -lntup 'sport = :443' antes de tocar em qualquer coisa.

Mude o túnel para UDP quando a rede permitir

Um listener UDP contorna a colisão por completo e costuma ser o conserto mais curto, já que nenhum socket é compartilhado e nenhum produto extra entra no caminho. Mas não é gratuito. Algumas redes de clientes descartam UDP 443 sem enviar um reset, então o túnel deixa de se estabelecer em vez de falhar no bind, e o usuário relata a VPN fora do ar sem nenhum erro para ler. Um listener UDP também sobrevive a uma reinicialização da camada web, o que conta numa máquina cujo site é reimplantado com frequência. Teste a partir da rede onde os usuários estão, porque um shell no servidor só prova que o servidor alcança a si mesmo.

Mude o transporte na configuração do servidor e no perfil do cliente ao mesmo tempo. Um perfil que ainda pede TCP vai girar em ciclos de reconexão contra um listener só UDP, e isso parece uma falha de rede até você comparar os dois arquivos.

Deixe o processo da VPN possuir TCP 443 e encaminhe o resto

O Community OpenVPN em modo servidor TCP lê os primeiros bytes de uma conexão de entrada e encaminha tudo o que não é o seu próprio protocolo para um backend HTTPS, e é para isso que serve a diretiva port-share. O backend é um servidor web comum com TLS habilitado, nomeado por host e porta nessa diretiva em vez de por uma URL.

port-share 10.0.0.5 8080

Numa máquina onde o site tem um segundo endereço privado, essa linha envia o tráfego que não é VPN para 10.0.0.5:8080, então o host virtual HTTPS precisa estar vinculado ali e o firewall precisa permitir o salto local. O servidor web precisa terminar o TLS por conta própria, porque os bytes que chegam são o handshake original do navegador e nada no meio os decifrou. Aponte a diretiva para um listener HTTP simples e o navegador recebe um erro de método inválido, que se lê como um site quebrado em vez de um backend mal colocado. A diretiva só existe no modo servidor TCP, e um listener UDP não tem fluxo para inspecionar.

Como o processo da VPN aceita cada conexão, a aplicação web vê a requisição encaminhada chegando de um dos próprios endereços do host em vez do visitante. Tudo o que precisa do endereço real do cliente depende do suporte ao protocolo PROXY no backend ou de um front-end que o acrescente. Mover o backend para outro endereço local não traz de volta o endereço do visitante; apenas muda qual dos endereços do host o site registra. Anote essa limitação nas notas de implantação antes que um relatório de análise levante a questão.

Um proxy reverso é a ferramenta errada; um roteador de camada quatro não

Um proxy reverso HTTP termina o TLS para poder ler requisições, o que significa que não pode deixar passar um fluxo OpenVPN intacto. Um roteador de camada quatro que encaminha por SNI ou por inspeção do primeiro pacote pode ficar na frente dos dois, desde que não encerre a sessão da qual a VPN depende. Os dois dispositivos parecem iguais num diagrama e se comportam de forma completamente diferente no socket.

O Access Server comercial traz suas próprias configurações de compartilhamento de porta, e elas não correspondem uma a uma à diretiva da comunidade. Identifique o produto e a versão antes de adaptar um guia escrito para o outro. Uma configuração copiada e silenciosamente ignorada é pior do que nenhuma configuração, porque a lista de listeners continua parecendo plausível depois.

Teste o site e o túnel como dois caminhos separados

Carregue o site e conecte o túnel, depois leia a lista de listeners de novo para ver qual processo possui 443 agora. Uma página que carrega não prova nada sobre a VPN, e um túnel que conecta não prova nada sobre o site, embora ambos usem o mesmo número. Os três comandos abaixo verificam o socket compartilhado, o caminho web e o serviço de VPN nessa ordem.

ss -lntup 'sport = :443'
curl -sI https://vpn.example.com/ | head -n 1
journalctl -u openvpn-server@server -n 20

Compare o endereço do cliente no log de acesso do backend com o do log da VPN no mesmo instante. Se o site registra cada visitante como o próprio host, o encaminhamento funciona e o tratamento do endereço não. Se ambos os logs ficam em silêncio, o front-end nunca entregou a conexão. De qualquer forma, a lista de listeners decide quem aceita o socket, e esse é o fato a confirmar antes de mudar outro arquivo.

Deixe esse mapa de listeners ao lado da configuração para que a próxima pessoa que tocar em 443 saiba qual processo aceita e para onde foi o outro protocolo. Confirme a propriedade depois da mudança em vez de confiar no que a edição pretendia fazer.