Servir OpenVPN por TCP e UDP a partir de um único host
Um processo liga um único transporte antes da 2.7. Compare um par TAP em bridge, duas sub-redes TUN e um pool partilhado, e depois associe cada perfil ao seu listener.
Redes que só permitem TCP 443 coexistem com redes que deixam passar UDP sem problemas, e um servidor tem de servir as duas. Um perfil com proto udp responde ao segundo grupo e falha no primeiro, e editar a mesma configuração para dizer proto tcp não cria um segundo listener. A diretiva escolhe um único transporte para um processo. Tudo o resto decorre dessa restrição.
Ou executa mais do que um processo, ou executa uma versão que consegue ligar vários sockets ao mesmo tempo.
Um processo liga um único transporte antes da 2.7
O OpenVPN da comunidade liga o socket que proto descreve, e essa diretiva escolhe um único transporte para a instância. TCP e UDP são pilhas separadas, por isso o mesmo número de porta pode ser ocupado pelos dois ao mesmo tempo, mas não por um processo. A linha 2.6 dá-lhe, portanto, um transporte por daemon. O OpenVPN 2.7 removeu essa limitação para servidores, que podem ligar vários sockets através de várias instruções --local num único processo.
Verifique a versão antes de desenhar em torno de qualquer das respostas, porque a disposição 2.7 é um modelo operacional diferente com a sua própria sintaxe de configuração. Um guia escrito para a 2.6 descreve dois processos mesmo quando não o diz.
Três formas de executar duas instâncias
Com interfaces TAP, execute uma instância por transporte e una os dois dispositivos tap numa bridge no host. Os dois conjuntos de clientes ficam no mesmo domínio de broadcast, o que permite que um único pool de endereços os cubra e mantém a funcionar os protocolos que dependem de broadcast. Com TUN, a bridge não está disponível, por isso a divisão mais simples dá a cada instância a sua própria sub-rede e deixa o encaminhamento manter os dois conjuntos de clientes separados. Uma terceira opção mantém um único pool ao fazer cada instância chamar um script learn-address que instala uma rota /32 para o cliente através do dispositivo dessa instância.
Essa terceira disposição é a que as pessoas pedem e a que exige mais cuidado, porque o script passa a fazer parte do caminho dos dados e tem de tratar corretamente os eventos de adição, atualização e remoção.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Mantenha as duas instâncias separadas
Cada instância também precisa de uma porta ou endereço separado, de um ficheiro de estado separado e de um destino de log separado. Dois daemons a escrever no mesmo ficheiro de estado produzem saída que não se consegue ler durante um incidente, e é exatamente aí que precisa dela. Se uma segunda instância liga um endereço específico, esse endereço tem de existir no host quando o processo arranca; caso contrário, sai com uma falha de ligação antes de dizer nada sobre chaves.
Nomeie as unidades e os perfis de modo a que o transporte seja óbvio pelo nome do ficheiro. O próximo operador não devia ter de abrir uma configuração para saber qual é TCP.
Associe o perfil ao listener
Um servidor que executa proto tcp espera um perfil de cliente com proto tcp-client, e um perfil que ainda traz proto udp contra esse listener esgota o tempo sem um erro sobre o qual o utilizador possa agir. Mantenha dois perfis se a implementação oferece os dois transportes, e etiquete-os para que o suporte saiba qual foi tentado. O número da porta, por si só, não descreve o transporte.
As regras de firewall seguem a mesma divisão: uma regra para UDP 1194 não diz nada sobre TCP 1194, e uma regra para um endereço não cobre o outro listener.
Leia primeiro a visão do servidor
Comece com ss -lntup no servidor e confirme que aparecem tanto um listener TCP como um UDP. Depois ligue um cliente de cada tipo e verifique a saída de estado à procura de duas entradas com endereços distintos. Se os sockets existem e não chega nenhum cliente, o caminho ou a firewall estão a rejeitar pacotes antes de o daemon os ver.
Um socket que nunca aparece é um problema de configuração ou de ligação, e um socket que aparece mas nunca regista uma ligação é um problema de filtragem. Os dois parecem idênticos do lado do cliente, e é por isso que a visão do próprio servidor vem primeiro. Tenha em conta que o TCP transporta bloqueio de cabeça de fila, por isso oferecê-lo é uma medida de alcançabilidade e não uma melhoria para clientes com um caminho UDP limpo.