La risposta ARP scompare da br0 a tap0 usando OpenVPN in modalità ponte

Ho installato un box Linux (su un esxi5) che funge da server OpenVPN. il server è configurato per utilizzare il bridging per i client, che essenzialmente funziona, con una sola eccezione.

Se il client esegue il ping di una macchina sulla rete che non è il server stesso, non funziona. Ho escluso tutto ciò che so (iptables, ecc.) E l'esecuzione di tcpdump lo ha ridotto alle seguenti cose:

Vedo le richieste ARP su tap0 e br0
Vedo le risposte ARP su br0
Non vedo le risposte ARP su tap0

Domanda: perché il dispositivo br0 non inoltra le risposte ARP al dispositivo tap0?

— palude
fonte

ok - ho fatto un ulteriore passo avanti. quando guardo la tabella mac del bridge usando brctl showmacs vedo l'indirizzo mac del mio client VPN sul lato tap0. se ora comincio a eseguire il ping dal client VPN alla sottorete, l'indirizzo mac si sposta sulla porta over bridge che ovviamente blocca la risposta arp della sottorete. il mac ritorna quasi immediatamente quando il ping si ferma. quindi quello che non so è perché l'indirizzo mac passa allo switchport sbagliato - tutte le mie ricerche non hanno prodotto risultati finora.

— fen

se "si sposta" su un'altra porta, sarebbe un chiaro indizio che l'indirizzo MAC è presente più di una volta nella tua rete o stai vedendo gli effetti di un loop di rete (due porte dello stesso bridge collegate da un attivo sentiero). Entrambi sono problemi di configurazione che devono essere corretti.

— the-wabbit il

isolare il problema utilizzando prima una voce ARP statica nel client, se i ping funzionano bene dopo di ciò, è possibile passare alla risoluzione dei problemi ARP. Se non funziona, allora hai un problema di rete più grande di un semplice ARP.

— Ricardo,

Dato che non possiamo sapere nulla di ciò su come appare la tua rete. Tiro lungo; hai client-to-clientnel file di configurazione openvpn del tuo server? Se i tuoi server sono connessi alla rete VPN usando openvpn come client, la frase potrebbe essere vera. PS. Che tipo di distro stai usando?

— Michal Sokolowski

Risposte:

Senza ulteriori informazioni, stiamo indovinando, ma proviamo:

Per prima cosa assicurati che sia eth0 che tap0 siano in modalità promiscua. br0 non dovrebbe essere in modalità promiscua.

Quindi controlla che hai arptables e tutte le regole di iptables che potrebbero interferire.

Dato che ricevi già risposte ARP, probabilmente non hai questo , ma controlla comunque.

infine controlla le impostazioni di rp_filter , ma controlla anche eventuali parametri di sysctl extra che potresti aver impostato.

— Higuita
fonte

... e poiché è ESXi, assicurati che la modalità promiscua sia abilitata sullo switch virtuale.

— Gerald Combs,

^ ^ ^ ^ È essenziale abilitare la modalità promiscua su vSwitch se si esegue ESXi. Veramente.

— roaima,

Se il tuo host ESXi ha connessioni ridondanti alla rete, ci sono una varietà di problemi ARP che possono apparire a causa dell'impostazione predefinita di Net.ReversePathFwdCheckPromisc. Gli utenti di pfSense che utilizzano CARP sono stati tra i primi a eseguire il debug di questo, descritti su https://doc.pfsense.org/index.php/CARP_Configuration_Tro troubleshooting

In un ambiente simile, abbiamo il ponte OpenVPN impostato su FreeBSD, ma anche l'ulteriore complicazione dei vlans. Su un host in cui Net.ReversePathFwdCheckPromisc non è stato impostato su 1 e in cui sono presenti più uplink alla rete, vediamo una perdita di pacchetti enorme (95% +) sul traffico in entrata verso il dispositivo di tocco. Funziona bene se impostato su 1.

— JG23
fonte