Balasan ARP menghilang dari br0 ke tap0 menggunakan OpenVPN dalam mode bridging

Saya telah menyiapkan kotak linux (pada esxi5) yang bertindak sebagai server OpenVPN. server dikonfigurasikan untuk menggunakan bridging untuk klien, yang pada dasarnya berfungsi, dengan satu pengecualian.

Jika klien ping beberapa mesin di jaringan yang bukan server itu sendiri tidak berfungsi. Saya mengesampingkan semua yang saya tahu (iptables, dll) dan menjalankan tcpdump membuatnya menjadi beberapa hal berikut:

Saya melihat permintaan ARP pada tap0 dan br0
Saya melihat balasan ARP pada br0
Saya TIDAK melihat balasan ARP pada tap0

Pertanyaan: mengapa perangkat br0 tidak meneruskan balasan ARP ke perangkat tap0?

— rawa
sumber

ok - saya selangkah lebih maju. ketika saya menonton tabel mac jembatan menggunakan brctl showmacs saya melihat alamat mac klien vpn saya di sisi tap0. jika saya sekarang mulai melakukan ping dari klien vpn ke subnet, alamat mac berpindah ke port over bridge yang tentu saja memblokir arp reply dari subnet. mac segera kembali ketika ping berhenti. jadi apa yang saya tidak tahu adalah mengapa alamat mac beralih ke switchport yang salah - semua pencarian saya menghasilkan hasil sejauh ini.

— fen

jika "berpindah" ke port lain, itu akan menjadi petunjuk yang pasti bahwa alamat MAC ada lebih dari satu kali di jaringan Anda atau Anda melihat efek dari loop jaringan (dua port dari jembatan yang sama dihubungkan oleh aktif) jalan). Keduanya adalah masalah konfigurasi yang perlu diperbaiki.

— the-wabbit

mengisolasi masalah dengan menggunakan entri ARP statis terlebih dahulu di klien Anda, jika ping bekerja dengan baik setelah itu maka Anda dapat pindah ke pemecahan masalah ARP. Jika tidak berhasil maka Anda memiliki masalah jaringan yang lebih besar dari sekadar ARP.

— Ricardo

Karena kita tidak bisa tahu apa - apa tentang bagaimana jaringan Anda terlihat. Tembakan panjang; apa yang Anda miliki client-to-clientdi file konfigurasi openvpn server Anda? Jika server Anda terhubung ke jaringan VPN menggunakan openvpn sebagai klien, maka kalimatnya mungkin benar. PS. Distro macam apa yang Anda gunakan?

— Michal Sokolowski

Jawaban:

Tanpa info lebih lanjut, kami menebak, tetapi mari kita coba:

Pertama-tama pastikan bahwa keduanya eth0 dan tap0 berada dalam mode promiscuous. br0 tidak boleh dalam mode promiscuous.

Selanjutnya periksa apakah Anda memiliki arptables dan aturan iptables yang mungkin mengganggu.

Karena Anda sudah mendapatkan balasan arp, Anda mungkin tidak memiliki ini , tetapi periksa juga.

akhirnya periksa pengaturan rp_filter , tetapi juga periksa parameter sysctl tambahan yang mungkin telah Anda tetapkan.

— higuita
sumber

... dan karena itu ESXi pastikan mode promiscuous diaktifkan di sakelar virtual.

— Gerald Combs

^ ^ ^ ^ Sangat penting untuk mengaktifkan mode promiscuous pada vSwitch jika Anda menjalankan ESXi. Betulkah.

— roaima

Jika host ESXi Anda memiliki koneksi yang berlebihan ke jaringan, ada berbagai masalah ARP yang dapat muncul karena pengaturan default Net.ReversePathFwdCheckPromisc. Pengguna pfSense menggunakan CARP adalah di antara yang paling awal untuk men-debug ini, dijelaskan di https://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting

Dalam lingkungan yang sama, kami memiliki OpenVPN bridging yang diatur di FreeBSD, tetapi juga komplikasi tambahan dari vlan. Pada host di mana Net.ReversePathFwdCheckPromisc belum diatur ke 1, dan di mana banyak uplink ke jaringan ada, kami melihat hilangnya paket besar-besaran (95% +) pada lalu lintas masuk ke perangkat keran. Ini berfungsi dengan baik ketika diatur ke 1.

— JG23
sumber