Odpowiedź ARP znika z br0 do tap0 przy użyciu OpenVPN w trybie pomostowym

Mam skonfigurowane pole Linuksa (na esxi5), które działa jak serwer OpenVPN. serwer jest skonfigurowany do używania mostkowania dla klientów, co zasadniczo działa, z jednym wyjątkiem.

Jeśli klient wysyła polecenie ping do komputera w sieci, który nie jest samym serwerem, nie działa. Wykluczyłem wszystko, co wiem (iptables itp.), A uruchomienie tcpdump sprowadziło to do następujących rzeczy:

Widzę żądania ARP na tap0 i br0
Widzę odpowiedzi ARP na br0
NIE widzę odpowiedzi ARP na tap0

Pytanie: dlaczego urządzenie br0 nie przesyła odpowiedzi ARP do urządzenia tap0?

— bagnisko
źródło

ok - mam krok dalej. kiedy oglądam tabelę mac mostu za pomocą showmacs brctl, widzę adres mac mojego klienta VPN po stronie tap0. jeśli teraz zacznę pingować od klienta VPN do podsieci, adres MAC przeniesie się do portu mostu, który oczywiście blokuje odpowiedź arp podsieci. Mac przełącza się niemal natychmiast po zatrzymaniu polecenia ping. więc nie wiem, dlaczego adres mac przełącza się na zły port przełączania - wszystkie moje wyszukiwania nie przyniosły jak dotąd żadnych wyników.

— fen

jeśli „przeniesie się” do innego portu, byłoby to wyraźną wskazówką, że adres MAC jest obecny w sieci więcej niż jeden raz lub widać efekty pętli sieciowej (dwa porty tego samego mostu połączone aktywnym ścieżka). Oba są problemami z konfiguracją, które wymagają naprawy.

— the-wabbit

wyizoluj problem, używając najpierw statycznego wpisu ARP w swoim kliencie, jeśli pingi działają dobrze, możesz przejść do rozwiązywania problemów z ARP. Jeśli to nie działa, masz większy problem z siecią niż tylko ARP.

— Ricardo

Ponieważ nie wiemy nic o tym, jak wygląda twoja sieć. Długi strzał; czy masz client-to-clientw pliku konfiguracyjnym openvpn serwera? Jeśli twoje serwery są podłączone do sieci VPN za pomocą openvpn jako klienta, to zdanie może być prawdziwe. PS. Jakiego rodzaju dystrybucji używasz?

— Michał Sokołowski

Odpowiedzi:

Bez dodatkowych informacji zgadujemy, ale spróbujmy:

Najpierw upewnij się, że zarówno eth0, jak i tap0 są w trybie rozwiązłym. br0 nie powinien być w trybie rozwiązłym.

Następnie sprawdź, czy masz arptables i wszelkie reguły iptables, które mogą przeszkadzać.

Ponieważ już otrzymujesz odpowiedzi na arp, prawdopodobnie nie masz tego , ale i tak sprawdź.

na koniec sprawdź ustawienia rp_filter , ale także sprawdź dodatkowe parametry sysctl, które mogłeś ustawić.

— higuita
źródło

... a ponieważ jest to ESXi, upewnij się, że tryb wirtualny jest włączony na przełączniku wirtualnym.

— Gerald Combs,

^ ^ ^ ^ Jeśli korzystasz z ESXi, musisz koniecznie włączyć tryb rozłączny na vSwitchu . Naprawdę.

— roaima,

Jeśli Twój host ESXi ma nadmiarowe połączenia z siecią, może wystąpić szereg problemów ARP, które mogą wystąpić z powodu domyślnego ustawienia Net.ReversePathFwdCheckPromisc. Użytkownicy pfSense korzystający z CARP byli jednymi z najwcześniejszych do debugowania tego, opisanymi na https://doc.pfsense.org/index.php/CARP_Configuration_Trou Rozwiązywanie problemów

W podobnym środowisku mamy skonfigurowane mostkowanie OpenVPN na FreeBSD, ale także dodatkową komplikację vlans. Na hoście, na którym Net.ReversePathFwdCheckPromisc nie został ustawiony na 1, i gdzie istnieje wiele łączy w górę do sieci, widzimy ogromną utratę pakietów (95% +) w ruchu przychodzącym do urządzenia z kranem. Działa dobrze, gdy jest ustawiony na 1.

— JG23
źródło