[EDIT] Isso parece ser um bug do OpenVPN - a ponte com o lado do servidor do túnel de torneira openvpn resulta em pacotes ARP perdidos, mas a ponte com o lado do cliente (de qualquer cliente conectado à vpn) funciona perfeitamente. Contornei o bug fazendo a ponte com um cliente em vez do servidor. O processo de relatório de erros é bastante trabalhoso, então levará algum tempo até que eu possa escrever tudo para enviar ao projeto Openvpn.
Estou observando o Openvpn descartando consistentemente certos pacotes ...
Cenário:
Eu configurei uma rede de camada 2 de área ampla (usando OpenVPN) para oferecer suporte a jogadores de edição de bolso do Minecraft (MCPE) (apenas família) para ver uns aos outros na lista de amigos da rede e jogar juntos. Existem três endpoints remotos, todos em locais diferentes, e um servidor openvpn central. Cada ponto de extremidade remoto transmite Wi-Fi em ponte para a interface tap Openvpn. Isso funciona muito bem e os jogadores podem se ver.
Recentemente, eu queria adicionar um ponto de extremidade Wi-Fi adicional localmente, aqui no local do servidor. Então, adicionei uma porta ethernet à ponte e conectei uma ponte Wi-Fi para obter conectividade de camada 2 com a ponte openvpn existente. À primeira vista, isso parece funcionar bem; os clientes podem acessar a internet e o tráfego L2 parece normal.
No entanto, quando os jogadores em um endpoint de cliente remoto tentam jogar contra aqueles conectados à ponte wi-fi local, os jogadores não podem ver uns aos outros.
As pontes Wi-Fi locais para a extremidade SERVER do túnel openvpn, e isso parece ser um fator, mas isso é inesperado.
Após muitas horas de solução de problemas, reduzi o problema a um fato peculiar - o Wi-Fi em ponte para a interface openvpn tap do servidor (chamada tapmc) não é capaz de jogar contra jogadores do outro lado da VPN.
Em outras palavras, se quaisquer dois jogadores estiverem no mesmo Wi-Fi ou em um ponto de extremidade Wi-Fi openvpn do cliente, eles poderão se ver, independentemente da distância. MAS os jogadores conectados ao Wi-Fi conectado à interface openvpn tap do lado do SERVIDOR enfrentam problemas - eles não podem ver os jogadores no lado do cliente do túnel e os jogadores remotos não podem vê-los.
Para ver um ao outro, o jogo envia um pacote de transmissão UDP a cada 1-2 segundos para a porta 19132 (ipv4). Todos os jogadores na rede recebem essas transmissões e, se o jogo for o servidor, o jogo responderá com um pacote unicast ao solicitante. Este pacote de resposta unicast contém informações do jogo, então o jogador que está procurando por jogos ativos na rede os verá aparecer em sua lista de amigos para que possam entrar no jogo.
Segue em anexo uma análise de um pequeno período de tempo em que os pacotes estão sendo perdidos. Os pacotes entram por um lado do túnel de derivação e não saem pelo outro lado. Eu capturei os pacotes executando o tcpdump em cada lado do túnel, na própria interface openvpn tap, para que não haja pontes no caminho, embora as interfaces sejam membros de uma ponte.
O que vejo é que o PLAYER2, enquanto procura por jogos na rede, envia o broadcast de busca, que é recebido pelo jogo do PLAYER1, que quer responder com um pacote unicast de informações do jogo, mas primeiro precisa resolver o endereço MAC do PLAYER2, então ele envia um ARP quem tem. o pacote who-has, e todas as retransmissões subseqüentes dele, são recebidos e respondidos por PLAYER1, mas essas respostas NÃO são transmitidas através do túnel Openvpn para PLAYER1. Assim, a resolução L2 ARP nunca é bem-sucedida, o pacote unicast de informações do jogo nunca é enviado e o PLAYER2 nunca vê o PLAYER1.
Também perdida no túnel está a segunda cópia do pacote de transmissão de pesquisa do jogo, no entanto, isso não é tão prejudicial para o processo porque a primeira das duas cópias é transmitida com sucesso. Mas por que apenas um?
Configuração do servidor Openvpn
server 192.168.251.0 255.255.255.0
verb 3
key ***
ca ***
cert ***
dh ***
tls-auth ***
key-direction 0
keepalive 10 60
persist-key
persist-tun
client-to-client
proto udp
port ***
dev tapmc
status ***
ifconfig-pool-persist ***
user nobody
group nobody
Configuração do cliente Openvpn
client
nobind
dev tapmc
remote-cert-tls server
remote ***
<key>
***
</key>
<cert>
***
</cert>
<ca>
***
</ca>
<tls-auth>
***
</tls-auth>
key-direction 1
#redirect-gateway def1
Versões OpenVPN: servidor: 2.4.8-1, clientes: 2.4.7-1
Isso acabou sendo um bug no OpenVPN