ARP yanıtı, köprüleme modunda OpenVPN kullanarak br0'dan tap0'a kaybolur

OpenVPN sunucusu gibi davranan bir linux kutusu (bir esxi5 üzerinde) kurduk. sunucu, temelde çalışan istemciler için bir istisna dışında köprüleme kullanacak şekilde yapılandırılmıştır.

İstemci, ağ üzerinde sunucunun kendisi olmayan bazı makinelere ping atıyorsa, çalışmaz. Bildiğim her şeyi (iptables, vb.) Dışladım ve çalışan tcpdump aşağıdaki şeyleri kaynattı:

Tap0 ve br0'da ARP isteklerini görüyorum
BR0'da ARP cevaplarını görüyorum
Tap0'da ARP cevaplarını görmüyorum

Soru: br0 cihazı neden ARP cevaplarını tap0 cihazına iletmiyor?

— bataklık
kaynak

tamam - bir adım daha ileri gidiyorum. i brctl showmacs kullanarak köprünün mac tabloyu izlerken tap0 tarafında benim vpn istemcinizin mac adresini görmek. Şimdi vpn istemcisinden alt ağa ping atmaya başlarsanız, mac adresi, alt ağın arp yanıtını bloke eden üst köprü bağlantı noktasına taşınır. ping durduğunda mac neredeyse hemen geri döner. ne bilmiyorum neden mac adresi yanlış switchport geçer - tüm aramalar şimdiye kadar hiçbir sonuç verdi.

— fen

başka bir bağlantı noktasına "geçerse", MAC adresinin ağınızda birden çok kez var olduğunu veya bir ağ döngüsünün (bir etkin tarafından bağlanan aynı köprünün iki bağlantı noktası) etkilerini gördüğünüze dair kesin bir ipucu olacaktır. yolu). Her ikisi de düzeltilmesi gereken yapılandırma sorunlarıdır.

— wabbit

istemcinizde ilk önce statik bir ARP girişi kullanarak sorunu izole edin, pingler bundan sonra iyi çalışırsa, ARP sorun giderme adımlarına geçebilirsiniz. Eğer işe yaramazsa, sadece ARP'den daha büyük bir ağ sorununuz var.

— Ricardo

Ağınız nasıl göründüğü hakkında hiçbir şey bilemediğimiz için. Uzun atış; Eğer var client-to-clientsunucunuzun openvpn yapılandırma dosyasında? Sunucularınız istemci olarak openvpn kullanılarak VPN ağına bağlıysa, cümle doğru olabilir. PS. Ne tür bir dağıtım kullanıyorsunuz?

— Michal Sokolowski

Yanıtlar:

Daha fazla bilgi olmadan tahmin ediyoruz, ancak deneyelim:

Öncelikle hem eth0 hem de tap0'ın karışık modda olduğundan emin olun. br0 karışık modda olmamalıdır.

Daha sonra, arptables ve müdahale edebilecek herhangi bir iptables kuralınız olduğunu kontrol edin.

Zaten arp cevap almak üzere, senin muhtemelen yok bu ama yine de bir kontrol.

son olarak rp_filter ayarlarını kontrol edin , fakat ayarlamış olabileceğiniz ekstra sysctl parametrelerini de kontrol edin.

— Higuita
kaynak

... ve ESXi olduğu için sanal anahtarda karışık modun etkinleştirildiğinden emin olun.

— Gerald Combs

^ ^ ^ ^ ESXi kullanıyorsanız vSwitch üzerinde karışık modu etkinleştirmek önemlidir . Gerçekten mi.

— roaima

ESXi ana makinenizde ağa yedek bağlantılar varsa, Net.ReversePathFwdCheckPromisc'in varsayılan ayarı nedeniyle ortaya çıkabilecek çeşitli ARP sorunları vardır. CARP kullanan pfSense kullanıcıları, https://doc.pfsense.org/index.php/CARP_Configuration_Tro Sorun Giderme bölümünde açıklandığı gibi, bu hata ayıklamanın ilk zamanları arasındaydı.

Benzer bir ortamda, FreeBSD'de OpenVPN köprülemenin yanı sıra vlans'ın ek komplikasyonunu da kurduk. Net.ReversePathFwdCheckPromisc'in 1 olarak ayarlanmadığı ve ağda birden fazla bağlantı bulunduğu bir ana bilgisayarda, musluk cihazına gelen trafikte büyük paket kaybı (% 95 +) görüyoruz. 1 olarak ayarlandığında iyi çalışır.

— JG23
kaynak