A resposta ARP desaparece de br0 para tap0 usando o OpenVPN no modo de ponte

Eu configurei uma caixa linux (em um esxi5) que atua como um servidor OpenVPN. o servidor está configurado para usar a ponte para os clientes, que essencialmente funciona, com uma exceção.

Se o cliente fizer ping em alguma máquina na rede que não seja o próprio servidor, ela não funcionará. Excluí tudo o que sei (iptables, etc) e a execução do tcpdump resumia-se às seguintes coisas:

Vejo solicitações ARP em tap0 e br0
Vejo as respostas do ARP no br0
NÃO vejo as respostas do ARP na torneira0

Pergunta: por que o dispositivo br0 não encaminha respostas ARP ao dispositivo tap0?

— fen
fonte

ok - eu dei um passo adiante. Quando assisto a tabela mac da ponte usando brctl showmacs, vejo o endereço mac do meu cliente VPN no lado tap0. se eu agora começar a executar ping do cliente vpn para a sub-rede, o endereço mac será movido para a porta over bridge, que obviamente bloqueia a resposta arp da sub-rede. o mac volta quase imediatamente quando o ping pára. Então, o que eu não sei é por que o endereço mac muda para o switchport errado - todas as minhas pesquisas renderam até agora nenhum resultado.

— fen

se "se mover" para outra porta, isso seria uma pista definitiva de que o endereço MAC está presente mais de uma vez na sua rede ou você está vendo os efeitos de um loop de rede (duas portas da mesma ponte conectadas por um ativo caminho). Ambos são problemas de configuração que precisam ser corrigidos.

— the-wabbit

isole o problema usando uma entrada ARP estática primeiro no seu cliente, se os pings funcionarem bem depois disso, você poderá passar para a solução de problemas do ARP. Se não funcionar, você terá um problema de rede maior do que apenas o ARP.

— Ricardo

Como não podemos saber nada sobre o aspeto da sua rede. Tiro longo; você tem client-to-clientno arquivo de configuração openvpn do seu servidor? Se seus servidores estiverem conectados à rede VPN usando o openvpn como cliente, a sentença poderá ser verdadeira. PS. Que tipo de distro você está usando?

— Michal Sokolowski

Respostas:

Sem mais informações, estamos supondo, mas vamos tentar:

Primeiro, verifique se eth0 e tap0 estão no modo promíscuo. br0 não deve estar no modo promíscuo.

Em seguida, verifique se você tem arptables e quaisquer regras do iptables que possam estar interferindo.

Como você já recebe respostas arp, provavelmente não possui isso , mas verifique assim mesmo.

finalmente verifique as configurações do rp_filter , mas também verifique os parâmetros sysctl extras que você pode ter definido.

— higuita
fonte

... e como é o ESXi, verifique se o modo promíscuo está ativado no comutador virtual.

— Gerald Combs

^ ^ ^ ^ É essencial para activar o modo promíscuo na vSwitch se você estiver rodando ESXi. Realmente.

— roaima 6/01

Se o seu host ESXi tiver conexões redundantes à rede, existem vários problemas de ARP que podem aparecer devido à configuração padrão do Net.ReversePathFwdCheckPromisc. Os usuários do pfSense que usam o CARP foram os primeiros a depurar isso, descritos em https://doc.pfsense.org/index.php/CARP_Configuration_Trou Resolução de Problemas

Em um ambiente semelhante, temos a ponte OpenVPN configurada no FreeBSD, mas também a complicação adicional de vlans. Em um host em que Net.ReversePathFwdCheckPromisc não foi definido como 1 e onde existem vários uplinks na rede, vemos uma perda maciça de pacotes (95% +) no tráfego de entrada para o dispositivo de toque. Funciona muito bem quando definido como 1.

— JG23
fonte