Відповідь ARP зникає з br0 до tap0, використовуючи OpenVPN в режимі мостів

У мене встановлено вікно Linux (на esxi5), яке діє як сервер OpenVPN. сервер налаштований на використання мостів для клієнтів, що по суті працює, за одним винятком.

Якщо клієнт пінгує якусь машину в мережі, яка не є самим сервером, вона не працює. Я виключав усе, що мені відомо (iptables тощо), і запуск tcpdump зводив його до таких речей:

Я бачу запити ARP на tap0 та br0
Я бачу відповіді ARP на br0
Я не бачу відповідей ARP на tap0

Питання: чому пристрій br0 не пересилає ARP-відповіді на пристрій tap0?

— фен
джерело

добре - я зробив крок далі. коли я переглядаю таблицю mac мосту, використовуючи brctl showmacs, я бачу адресу mac свого клієнта vpn на стороні tap0. якщо я зараз почну pinging від клієнта vpn до підмережі, mac-адреса переходить на порт over bridge, який, звичайно, блокує відповідь arp підмережі. mac перемикається назад майже відразу, коли пінг припиняється. тому я не знаю, чому mac-адреса переходить на неправильний комутаційний порт - всі мої пошуки не дали результатів поки що.

— Фен

якщо він "переходить" на інший порт, це було б певною підказкою, що MAC-адреса або присутня не раз у вашій мережі, або ви бачите ефекти мережевого циклу (два порти того ж мосту, з'єднані активним шлях). Обидва - це проблеми з конфігурацією, які необхідно виправити.

— Вабіт

Вирішіть проблему, застосувавши спочатку статичний запис ARP у своєму клієнті, якщо пінг працює добре після цього, тоді ви можете перейти до усунення несправностей ARP. Якщо це не працює, то у вас виникає більша проблема з мережею, ніж просто ARP.

— Рікардо

Оскільки ми нічого не можемо знати про те, як виглядає ваша мережа. Ризиковане підприємство; чи є client-to-clientу вас конфігураційний файл openvpn вашого сервера? Якщо ваші сервери підключені до мережі VPN, використовуючи openvpn як клієнт, то вирок може бути істинним. PS. Який дистрибутив ви використовуєте?

— Міхал Соколовський

Відповіді:

Без додаткової інформації ми здогадуємось, але давайте спробуємо:

Спочатку переконайтеся, що і eth0, і tap0 знаходяться в безладному режимі. br0 не повинен перебувати в безладному режимі.

Далі перевірте, чи є у вас аргументи та правила iptables, які можуть заважати.

Як ви вже отримуєте Arp відповіді, ваш , ймовірно , НЕ це , але перевірити це в будь-якому випадку.

нарешті перевірити параметри rp_filter , а також перевірити будь-які додаткові параметри sysctl, які ви могли встановити.

— х'югіта
джерело

... а оскільки це ESXi, переконайтеся, що у віртуальному комутаторі включений безладний режим.

— Джеральд Гребінь

^ ^ ^ ^ Важливо ввімкнути розрядний режим на vSwitch, якщо ви працюєте з ESXi. Дійсно.

— roaima

Якщо ваш хост ESXi має надлишкові з'єднання з мережею, існують різноманітні проблеми ARP, які можуть з'являтися через налаштування Net.ReversePathFwdCheckPromisc за замовчуванням. Користувачі pfSense, які використовують CARP, були одними з найдавніших налагодження, описані на сторінці https://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting

У подібному середовищі у нас є встановлення мостів OpenVPN на FreeBSD, але також додаткове ускладнення vlans. На хості, де Net.ReversePathFwdCheckPromisc не встановлено значення 1, і де існує декілька посилань на мережу, ми бачимо великі втрати пакетів (95% +) на вхідному трафіку до пристрою, що перебуває в крані. Він працює чудово, коли встановлено 1.

— JG23
джерело