Os clientes OpenVPN não se veem entre si: sub-rede ou net30?

Duas falhas sem relação produzem a mesma queixa. Na primeira, um cliente não chega a outro nem pelo endereço do túnel, porque os endereços não estão numa só sub-rede ou o servidor não encaminha tráfego entre pares. Na segunda, o ping funciona e a lista de dispositivos da aplicação fica vazia, porque a descoberta depende de broadcast que um túnel de camada 3 não consegue transportar. Um único ping separa as duas, e a correção de cada uma não se parece nada com a da outra.

Um único ping parte o problema em dois

A partir de um cliente, faça ping ao endereço de túnel do outro cliente, não ao nome e não ao endereço de LAN. Se falhar, o problema é o encaminhamento ou o endereçamento e a descoberta é irrelevante até isso ser corrigido. Se funcionar, o encaminhamento já funciona e o que falta é broadcast ou resolução de nomes.

ip addr show tun0

Leia a interface do cliente antes de tudo, porque a máscara de rede nomeia a topologia. Uma /24 ou outra máscara de sub-rede significa um pool partilhado; uma /30 com endereço de par significa o esquema antigo ponto a ponto, em que cada cliente tem exatamente um vizinho, o servidor.

net30 frente a sub-rede, lido do lado do cliente

Com net30 o servidor distribui um bloco pequeno por cliente, pelo que não existe rota para o endereço de túnel de outro cliente a menos que o servidor a encaminhe. Com sub-rede todo o pool é uma rede, cada cliente pode endereçar qualquer outro e o servidor encaminha entre eles. É por isso que uma configuração de servidor pode parecer saudável enquanto os pings entre pares falham: nada está avariado, os clientes simplesmente não estão numa só rede. O cliente vê uma ligação a funcionar e um endereço de par que não responde, o que se lê como firewall mas é um esquema de endereçamento.

Mudar a diretiva é uma edição do lado do servidor mais um reinício, e aplica-se à ligação seguinte, não às sessões já abertas. Volte a ligar os clientes antes de julgar a mudança. Se um equipamento regenera a configuração a partir de uma interface web, registe a diretiva, o ficheiro e a data, e faça a edição pela interface quando existir, porque uma reconstrução sobrescreve uma edição manual no próximo guardar.

client-to-client é uma porta à parte

Mesmo dentro de uma só sub-rede o servidor descarta os pacotes que chegam de um cliente e se destinam a outro, a menos que client-to-client esteja definido. Essa palavra-chave transforma o servidor num encaminhador do tráfego entre pares em vez de um ponto final que apenas o aceita. É a segunda condição que as pessoas esquecem depois de corrigir a topologia.

Isto não se estende ao broadcast. A definição encaminha unicast entre clientes; não transforma o túnel num segmento partilhado, e nenhuma quantidade disso entregará um pedido de descoberta multicast a todos os pares.

TUN frente a TAP, e o que cada um pode transportar

Pôr um dispositivo tap em ponte para a LAN coloca os clientes remotos no domínio de broadcast do escritório, o que resolve a descoberta por completo. O preço são as plataformas que não implementam TAP, uma ponte que tem de existir no servidor e um domínio de falha onde uma tempestade de broadcast no cabo do escritório chega a cada portátil remoto.

Para duas ou três estações de trabalho que precisam de resolução de nomes, uma entrada hosts ou um endereço unicast é muito mais barato do que uma ponte. Recorra a TAP quando um protocolo que não pode substituir depender da descoberta de camada 2, e não antes.

Clientes da mesma sub-rede sem ponte

Atribuir um endereço da faixa da LAN não põe o cliente no cabo. O servidor encaminha entre túnel e Ethernet, por isso o ARP para esse endereço para na interface do servidor e o resto da LAN nunca fica a saber onde ele mora.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP fecha essa lacuna ao fazer o servidor responder em nome do cliente. Para uma faixa, o parpd gere as entradas à medida que os clientes entram e saem, enquanto o sysctl net.ipv4.conf.eth0.proxy_arp=1 responde por tudo o que é encaminhado para outro sítio, o que é amplo o suficiente para criar as suas próprias surpresas num segmento ocupado.

Escolha o caminho que escolher, retire o NAT entre o túnel e o cabo. Uma regra MASQUERADE esconde exatamente a pergunta de endereçamento a que tenta responder. Também deixa à pessoa seguinte uma topologia sobre a qual não consegue raciocinar do lado do cliente.

Antes de mudar seja o que for, capture uma tentativa no servidor com tcpdump -ni tun0 e confirme se o pacote do par chega sequer. Chegar e ser descartado aponta para client-to-client; nunca chegar aponta para topologia ou encaminhamento. O manual do OpenVPN 2.6 documenta ambas as palavras-chave e a topologia predefinida, o que vale a pena comparar com a sua versão antes de copiar uma linha de um post de fórum.

• A interface tun mostra uma máscara de pool em vez de um par /30.
• Um ping direto ao outro endereço de túnel funciona antes de testar a descoberta.
• A configuração do servidor inclui client-to-client sempre que os pares tiverem de trocar pacotes.
• Nomeie o protocolo de descoberta que está a testar em vez de dizer que a aplicação falha.
• Use TAP apenas se todas as plataformas de cliente do grupo o suportarem.
• Mantenha o NAT fora do caminho entre túnel e LAN quando importa o alcance dentro da mesma sub-rede.