Servidor e cliente OpenVPN no mesmo host: por que os clientes caem

Adicione um perfil de cliente a uma máquina que já executa um servidor VPN e o serviço original será a primeira vítima. O novo túnel pode nunca se estabelecer, ou pode subir enquanto os clientes existentes do servidor param silenciosamente de receber respostas. Duas colisões produzem os dois resultados: um pool de túneis já em uso e uma rota padrão instalada pela metade cliente nova que cobre toda a tabela. Nenhuma das duas gera uma mensagem de erro do OpenVPN, e é por isso que a falha é lida como problema do servidor.

Uma máquina, dois papéis e duas respostas incompatíveis sobre para onde as respostas devem ir.

Mesmo pool, dois servidores: qual vence

Cada instância de servidor precisa da sua própria sub-rede de túnel. Copiar uma linha como server 10.8.0.0 255.255.255.0 para a segunda configuração dá às duas instâncias o mesmo prefixo, e o resultado é ou uma recusa em iniciar ou uma disputa silenciosa em que clientes de um servidor recebem endereços que o outro também considera seus. Portas UDP diferentes e nomes de dispositivo diferentes não ajudam, porque nenhum dos dois toca o espaço de endereços. Mude o segundo pool e mude-o em todos os lugares onde as rotas o mencionam.

Enumere o que está ativo antes de editar: ip -4 addr show lista os dispositivos de túnel, ss -lunp lista os ouvintes e systemctl list-units nomeia as unidades. Uma olhada nos endereços do túnel decide se os pools colidem.

O que o perfil de cliente acrescenta à tabela

A metade cliente grava rotas assim que se conecta. redirect-gateway def1 divide a rota padrão em 0.0.0.0/1 mais 128.0.0.0/1, ambas roteadas pelo novo dispositivo, junto com uma rota de host para o servidor remoto deliberadamente fixada na interface física. Essa fixação existe para que o túnel mantenha um caminho para o seu próprio transporte. Todo o resto, incluindo as respostas que o servidor local deve aos seus próprios clientes, agora segue a nova rota padrão e sai pelo enlace remoto.

Então a segunda colisão não é um túnel quebrado. É um túnel funcionando no lugar errado da tabela.

Três maneiras de manter os papéis separados

A correção menos invasiva mantém a rota padrão fora do perfil de cliente: route-nopull mais linhas route explícitas para os prefixos remotos, de modo que a tabela local só mude onde você pediu. O passo seguinte é uma regra de política que isenta a sub-rede de túnel local, deixando as respostas aos clientes locais saírem pela interface por onde chegaram mesmo quando existe uma rota padrão. A mais completa é um espaço de nomes de rede separado para o papel de cliente, que remove por completo a tabela compartilhada e custa um segundo contexto de roteamento para manter.

Seja qual for o caminho escolhido, a exceção deve nomear a sub-rede de túnel local e não a LAN. A resposta enviada pelo servidor local tem como destino um endereço de túnel, então uma exceção em forma de LAN nunca se aplica a ela.

Qual das duas instâncias é a culpada

Pare a instância cliente e teste novamente os clientes originais. Recuperação imediata significa roteamento, não servidor. Traga o cliente de volta e rastreie uma única resposta com ip route get ao qual se fornece tanto um endereço de origem quanto de destino, o que mostra o caminho que o kernel escolheria, e depois observe a interface que os pacotes realmente usam com tcpdump -ni any port 1194. O arquivo de status do servidor, escrito a cada poucos segundos pela diretiva status, contém a lista de clientes conectados e contadores de bytes nos dois sentidos.

Leia esses contadores um contra o outro. O tráfego que sai e nunca volta é uma resposta de roteamento, não um problema de handshake.