Um servidor TAP ou vários? Clientes OpenVPN numa ponte

Vários clientes TAP não exigem um processo de servidor, uma porta UDP e um dispositivo TAP do anfitrião para cada um. Um servidor OpenVPN em modo Ethernet pode admitir muitos clientes autenticados e ligá-los a uma única ponte, e essa é a forma documentada de estender um segmento de camada 2. O desenho de um só processo é o que o manual documenta, e é normalmente o valor predefinido correto.

A verdadeira questão é se esses clientes devem partilhar esse segmento. O número de processos não responde a isso, porque as propriedades de isolamento vêm da topologia e não de quantos daemons estão a correr. O resto desta comparação trata das duas topologias e do que cada uma facilita.

Duas arquiteturas, não dois ajustes

Uma implantação TUN encaminhada dá a cada cliente uma ligação ponto a ponto para o domínio de encaminhamento do servidor. As difusões param no servidor, os clientes não vêem as tramas uns dos outros, e o tráfego entre clientes, se existir, tem de ser encaminhado e filtrado explicitamente.

Uma implantação TAP em ponte torna os clientes membros de um único segmento Ethernet. Vêem as difusões, podem resolver-se uns aos outros com ARP e dependem da política da ponte e da firewall em vez do encaminhamento para se manterem separados. Isso é útil quando os clientes têm de aparecer como se estivessem ligados ao mesmo comutador.

A comparação é, portanto, sobre aquilo a que os clientes têm de chegar, não sobre desempenho. Escolha primeiro a camada e depois decida quantos processos a servem.

O que faz o assistente server-bridge

O assistente server-bridge configura o modo Ethernet multi-cliente. A sua forma de conjunto de endereços recebe o gateway, a máscara de rede e um intervalo dedicado dentro da sub-rede em ponte, por exemplo um gateway em 192.168.50.1 com um conjunto de 192.168.50.160 a 192.168.50.199.

Reserve esse intervalo fora de qualquer outra atribuição DHCP ou estática. O assistente atribui endereços a partir dele, mas não se coordena com outro atribuidor no mesmo segmento, e dois conjuntos sobrepostos produzem endereços duplicados que parecem falhas de conectividade aleatórias. Escreva o intervalo reservado no plano de endereços do local para que a próxima pessoa não o reutilize. Um comentário na configuração do servidor é um substituto pobre desse registo.

Existe uma forma com proxy DHCP para implantações em que um servidor externo distribui endereços. Tem os seus próprios pré-requisitos, e misturar as duas formas produz exatamente o conflito que a documentação avisa. Escolha um único atribuidor para a sub-rede em ponte.

O isolamento não vem do número de processos

Oito processos OpenVPN ligados à mesma ponte sem restrições continuam a partilhar um único domínio de difusão. Os clientes podem enviar ARP uns aos outros através da ponte, e o número de ouvintes não mudou nada nisso.

Se o requisito é que grupos de clientes não se vejam na camada 2, o desenho precisa de pontes separadas ou ligações VLAN, com as regras de acesso correspondentes. É uma decisão de desenho de rede, e é a mesma quer esteja envolvido um processo de servidor quer oito. A filtragem da ponte pode restringir parte do tráfego, mas não cria domínios de difusão separados. Trate-a como um complemento da segmentação, não como um substituto.

Se o requisito for apenas que os clientes cheguem a determinados serviços IP, um desenho TUN encaminhado é geralmente mais simples do que pôr em ponte com filtragem. Cada cliente obtém a sua própria ligação, e a política vive nas regras de encaminhamento e da firewall em vez de dentro da ponte.

Quando vários processos continuam corretos

Processos separados podem justificar-se por necessidades operacionais: backends de autenticação diferentes, autoridades de certificação diferentes, ciclos de atualização separados ou conjuntos de opções incompatíveis. São razões reais e são independentes do número de clientes.

Se usar vários, dê a cada um o seu próprio ouvinte e a propriedade do dispositivo, e coordene os intervalos de endereços. Dois servidores que ambos acreditam possuir o mesmo conjunto na mesma ponte acabarão por distribuir o mesmo endereço.

Depois verifique o desenho com vários clientes ao mesmo tempo. Verifique que os endereços são únicos, que o tráfego previsto entre clientes funciona e que um par que não deve comunicar não consegue. Um ping bem-sucedido de um único cliente não testa nada do desenho multi-cliente.

Leia a ponte e o modo do servidor a partir do anfitrião em execução antes de confiar no diagrama. A configuração que importa é a que o núcleo e o daemon carregaram efetivamente, e é também a que um revisor pode verificar.