Encaminhar clientes OpenVPN pelo Cloudflare? Verifique primeiro a função

Você tem um servidor OpenVPN funcional e um host que também executa o software de dispositivo do Cloudflare, e o próximo passo óbvio parece ser direcionar o tráfego dos clientes para ele. Duas conexões funcionais em uma máquina não formam um gateway de trânsito. O que falta é uma função documentada para encaminhar pacotes que pertencem a outra pessoa, e uma política que classifique esses pacotes quando chegam.

Antes de qualquer regra vêm quatro perguntas: que tráfego entra, para onde ele vai em seguida, como as respostas encontram o caminho de volta e o que o projeto faz quando esse segundo caminho falha. As duas primeiras são perguntas de capacidade.

Dois serviços num único host não são um caminho de trânsito

Um cliente de dispositivo é feito para lidar com tráfego que se origina na máquina onde ele é executado. Ele intercepta a resolução de nomes, ou tráfego de aplicação selecionado, e o envia pelo próprio túnel, e sua política é escrita para o usuário desse dispositivo e os processos desse dispositivo. Um pacote encaminhado de um cliente OpenVPN não é saída local, então as mesmas regras não o classificam. Isso não é um detalhe de configuração que possa ser coberto com uma regra mais ampla, porque ele decide se o software vê o pacote.

Por isso a pergunta de projeto é uma pergunta de capacidade. Ou o produto instalado tem uma função documentada que encaminha tráfego para outras redes, ou a função de trânsito pertence a outro lugar por completo.

Qual função do Cloudflare pode encaminhar

O cliente de dispositivo do Cloudflare oferece modos que diferem em escopo: apenas resolução de nomes, tráfego do dispositivo e às vezes ambos. Nenhum desses modos transforma o host num roteador para uma faixa privada que chega por outro túnel. A função de roteamento dedicada é um produto separado com seu próprio conector, registro e modelo de rede.

Verifique a função instalada antes de projetar rotas em torno dela. Leia qual interface o conector cria, se ele anuncia prefixos específicos ou uma rota padrão, e se a política local se aplica aos pacotes encaminhados bem como aos locais. Se apenas o tráfego local for tratado, o servidor OpenVPN não pode ser o ponto de trânsito, não importa como a regra de tradução seja escrita.

Aqui também o requisito de saída pública deve ser formulado com precisão. Uma saída fornecida pelo Cloudflare para o tráfego de clientes encaminhado é um caso de uso específico, e precisa ser confirmada contra o serviço que você realmente tem.

Mantenha o túnel externo independente da nova rota

No momento em que você adiciona uma rota padrão para a nova interface, o tráfego de saída do próprio servidor começa a competir por ela, e isso inclui as respostas aos clientes OpenVPN e a sua sessão SSH para a máquina. O sintoma habitual é um túnel que se estabelece e depois morre, ou um administrador trancado fora enquanto a mudança parece ter funcionado. Compare ip route get para o endpoint antes e depois, e use roteamento por política ou uma rota de host para manter o transporte do próprio servidor onde estava. Execute essa comparação a partir da própria máquina, porque é a visão do servidor sobre a sua própria rota que importa.

Uma exceção para o endereço público do servidor não basta por si só, porque o caminho de volta de cada administrador remoto é um fluxo diferente. Decida quais desses fluxos precisam sobreviver à mudança e depois verifique cada um, em vez de presumir que o primeiro cobre o resto.

Limite o encaminhamento e a tradução a um único fluxo

Os pacotes recebidos seguem o caminho de encaminhamento, não o de saída local, então a regra que importa vive no hook forward. Onde a interface seguinte precisa de tradução, limite a origem ao pool de clientes, o destino ao que é permitido e a saída a essa única interface. Uma regra masquerade ligada apenas a uma interface não escolhe rota sozinha e não permite o encaminhamento além de qualquer outro filtro.

Decida o comportamento de fechamento em caso de falha antecipadamente e depois teste-o. Pare o caminho seguinte e confirme que os clientes perdem a saída pretendida em vez de voltar silenciosamente ao uplink comum, porque esse é o resultado que ninguém nota até o tráfego sair pela porta errada. Repita a verificação para a resolução de nomes e para IPv6, porque um conjunto de regras apenas para v4 deixa um caminho v6 aberto.

Anote as quatro respostas com que ficou e a observação que demonstra cada uma. Um caminho de trânsito que você consegue descrever é um que você consegue defender na próxima revisão de incidentes.