ARP Table enthält MAC aus anderem Subnet

[McAldo]

Ich habe seit heute ein seltsames Phänomen in Debian/Buster.
In der Arp-table steht eine MAC aus einem anderen Subnetz. Alle anderen Einträge sind im selben Netz wie mein Rechner. Ich weiß nun auch nicht so richtig, welche Infos zur Lösungsfindung wichtig ist. Ich hatte heute früh noch ein upgrade durchgeführt. Hier der Auszug aus dem apt-log: pastebin/?mode=view&s=40585 (Speicherdauer 1 Monat).

Vielleicht ein paar Netzwerkrelevante Ausgaben:

Code: Alles auswählen

root@pinguin:~# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1   0.0.0.0         UG    100    0        0 eno1
192.168.1.0   0.0.0.0         255.255.255.0   U     100    0        0 eno1

Code: Alles auswählen

root@pinguin:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e0:e5:4e:2d:b4:c3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.132/24 brd 192.168.1.255 scope global dynamic noprefixroute enp0s31f6
       valid_lft 20777sec preferred_lft 20777sec
    inet6 fe80::e2c5:5dff:f32c:bdb6/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Code: Alles auswählen

root@pinguin:~# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.1            ether   b0:aa:77:7f:8d:00   C                     eno1
192.168.1.19           ether   08:62:66:a1:da:07   C                     eno1
192.168.1.2            ether   08:62:66:a1:da:11   C                     eno1
192.168.1.14           ether   30:cd:a7:9b:97:04   C                     eno1
192.168.5.20            ether   ba:ae:d4:46:38:e2   C                     eno1

Die IP 192.168.5.20 gehört da nicht hin. :-O
Der Router ist einer von Cisco. Das Zielsystem ist ein virtuelles Debian/Stretch, welches mittels einer Open vSwitch Bridge ans Netz angebunden ist.
Irgendwelche Ideen dazu?

[mat6937]

In der Arp-table steht eine MAC aus einem anderen Subnetz.

Code: Alles auswählen

root@pinguin:~# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.1            ether   b0:aa:77:7f:8d:00   C                     eno1
192.168.1.19           ether   08:62:66:a1:da:07   C                     eno1
192.168.1.2            ether   08:62:66:a1:da:11   C                     eno1
192.168.1.14           ether   30:cd:a7:9b:97:04   C                     eno1
192.168.5.20            ether   ba:ae:d4:46:38:e2   C                     eno1

Die IP 192.168.5.20 gehört da nicht hin.

Ist dieser Eintrag in der arp-table, dauerhaft?
Kannst Du die IP-Adresse 192.168.5.20 per ping (icmp) oder per arping (arp) erreichen?
Gibt es in deiner Konstellation, irgendwo diese IP-Adresse oder dieses Subnetz? Wenn ja, könnte dein Debian/Buster evtl. auch nur temporär (z. B. beim booten) damit "in Berührung" kommen?

[bluestar]

Code: Alles auswählen

2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.1.132/24 brd 192.168.11.255 scope global dynamic noprefixroute enp0s31f6

Bist du dir sicher, dass dein Setup korrekt ist? Dein Broadcast sagt was anderes: brd 192.168.11.255

[McAldo]

In der Arp-table steht eine MAC aus einem anderen Subnetz.

Code: Alles auswählen

root@pinguin:~# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.1            ether   b0:aa:77:7f:8d:00   C                     eno1
192.168.1.19           ether   08:62:66:a1:da:07   C                     eno1
192.168.1.2            ether   08:62:66:a1:da:11   C                     eno1
192.168.1.14           ether   30:cd:a7:9b:97:04   C                     eno1
192.168.5.20            ether   ba:ae:d4:46:38:e2   C                     eno1

Die IP 192.168.5.20 gehört da nicht hin.

Ist dieser Eintrag in der arp-table, dauerhaft?
Kannst Du die IP-Adresse 192.168.5.20 per ping (icmp) oder per arping (arp) erreichen?
Gibt es in deiner Konstellation, irgendwo diese IP-Adresse oder dieses Subnetz? Wenn ja, könnte dein Debian/Buster evtl. auch nur temporär (z. B. beim booten) damit "in Berührung" kommen?

Der Eintrag verschwindet nach einer Weile wieder, wenn kein Zugriff mehr auf diesen Host erfolgt.
Ping funktioniert durchgehend, auch während man per ssh oder http nicht mehr den Server kommt. Bei arping kommt ein "Timeout".

Die Adresse, bzw. das Subnetz gibt es nur innerhalb der Virtualisierung. Ein Routing wurde auf dem Cisco-Router eingerichtet.

Was mir aber gerade aufgefallen ist, mein Rechner befindet sich physisch im selben Netz wie der Server (192.168.1.19) auf dem die Virtualisierung läuft. Dadurch kommt die MAC vom virtuellen System wohl direkt bei meinem Rechner an. Kann das sein? Wenn ja, wie verhindere ich das? Wird ja sicher in OPEN vSwitch irgendwie gehen?
Als Virtualisierungsplattform läuft Proxmox 5.x.

@bluestar: Das war ein copy&paste Fehler.

[mat6937]

Der Eintrag verschwindet nach einer Weile wieder, wenn kein Zugriff mehr auf diesen Host erfolgt.
Ping funktioniert durchgehend, auch während man per ssh oder http nicht mehr den Server kommt. Bei arping kommt ein "Timeout".

Wenn der Ping geht sollte arping auch möglich sein. Aber OK, wenn Du es verhindern willst ist eh egal und muss nicht weiter verfolgt werden.

Kann das sein? Wenn ja, wie verhindere ich das?

Ja, das kann sein. Das Problem wird sein, dass die MAC-Adresse evtl. zufällig ist bzw. immer neu generiert wird. Evtl. kannst Du das so konfigurieren, dass die MAC-Adresse konstant ist. Wenn das geht dann kannst Du z. B. iptables und oder arptables verwenden:

Code: Alles auswählen

iptables -I INPUT 1 -t security -i eno1 -s 192.168.5.20 -m mac --mac-source <MAC-Adresse> -j DROP

Code: Alles auswählen

arptables -I INPUT 1 --proto-type 0x800  --h-type 1 --opcode 2 -i eno1  --source-mac <MAC-Adresse> -s 192.168.5.20 -j DROP

Wenn es nicht geht, dann könntest Du mit iptables nur die IP-Adresse blocken, aber damit werden evtl. arp-requests bzw. arp-replys nicht verhindert. Evtl. auch eine abweisende Route für 192.168.5.20 (oder dessen Subnetz) konfigurieren.

[McAldo]

Die MAC-Adresse ist statisch.

Neue Erkenntnis. Die Hosts befinden sich alle im selben physischen Netz (also auf dem selben layer). Dadurch landet die tatsächliche MAC vom virtuellen Host direkt in der arp table auf meinem Rechner und es wird wohl dann versucht den virtuellen Host direkt zu erreichen. Das sieht man gut mit traceroute:

Code: Alles auswählen

root@pinguin:~# traceroute 192.168.5.20
traceroute to 192.168.5.20 (192.168.5.20), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.485 ms  0.601 ms  0.761 ms
 2  192.168.5.20 (192.168.5.20)  4.176 ms  4.164 ms  4.217 ms
root@pinguin:~# traceroute 192.168.5.20
traceroute to 192.168.5.20 (192.168.5.20), 30 hops max, 60 byte packets
 1  192.168.5.20 (192.168.5.20)  0.609 ms  0.572 ms  0.620 ms

Code: Alles auswählen

root@pinguin:~# arp
192.168.5.20            ether   ba:ae:d4:46:38:e2   C                     eno1

Ich habe auf meinem Rechner also mal ein Alias-Interface mit einer IP aus dem Subnet 192.168.5.0/24 aktiviert. Danach funktioniert alles.

Was ich dabei noch nicht verstehe ist, warum passiert das unter Windows nicht. Der Windows-Host befindet sich ebenfalls in 192.168.1.0/24 und kann das System 192.168.5.20 ohne Probleme erreichen. In der arp table steht die IP/MAC nicht drin und tracert zeigt immer den hop über das Gateway. Was ist anders unter Windows? Warum verhält sich Debian/Buster so wie geschildert?

[dufty2]

Die MAC-Adresse ist statisch.

Mmmh, mit der Bezeichnung bin ich nicht ganz glücklich, denn "C" sagt soviel beim arp-cache,
dass der Eintrag komplett gelernt wurde (also dynamisch) und "M" würde sagen, dass er statisch vergeben wurde.

Wie auch immer, ich _vermute_ mal, dass Linux auf den arp-Eintrag (aus dem "falschen" subnet) reagiert,
weil es dem "weak host model" gehorcht, getreu dem Motto "Auf alles antworten, wo und wie auch immer
der frame auf irgendein Interface angekommen ist". Windows streng nach "strong host model" geht brav über das default-gateway.
Wie gesagt, reine Spekulation meinerseits.

[McAldo]

Ah..., du meinst den Eintrag im ARP-Cache. Ja, der ändert sich natürlich. Der Host selber hat aber eine statische MAC.

Hm..., Windows akzeptiert also eine unsaubere Konfiguration des Netzes. Naja, macht ja einiges unsauberes.

Das Problem lässt sich, nach meinem aktuellen Kenntnisstand, damit lösen:

1. Es wird ein VLAN für das andere Subnetz konfiguriert und damit die Netze logisch getrennt.
2. Hosts werden in den selben IP-Bereich genommen wie alle anderen in dem physischen Lavyer.
3. Client-Rechner bekommt ein Alias-Interface mit IP aus dem zusätzlichen Subnetz. Sehr unsaubere Lösung und bei größerer Client-Anzahl nicht praktikabel

[r4pt0r]

Der linux-Netzwerkstack antwortet noch immer per default auf _allen_ interfaces auf arp requests!! Warum dieser hirnrissige und massiv sicherheitskritische default noch immer gesetzt ist weiß der Geier, aber das beißt immer wieder wenn man linux-hosts (auch embedded, appilances etc) mit mehreren Interfaces in _eigentlich_ voneinander isolierten netzen betreibt, die dann ARP replies ins falsche Netz leaken. Auch bei kollidierenden subnetzen (z.b. in test- und production netz) führen das gerne zu problemen die extrem schwer zu debuggen sind...

sysctl arp_announce muss auf 1; arp_ignore auf 2 gesetzt werden, dann erhält man ein normales und vorhersagbares verhalten; nämlich dass die Kiste auch NUR auf dem interface antwortet die in das jeweiligen Netz gehört. Damit hat man oft schon die meisten Probleme durch/mit ARP-poisoning gelöst...


Embedded geräte/appliances bei denen die sysctls nicht geändert werden können, müssen/können dann nur in einem einzelnen subnet betrieben werden, speziell wenn an den switches port-security akitv ist; sonst wird der port (zurecht) deaktiviert da ARP-replies mit falscher MAC an diesem port ankommen...

[mat6937]

sysctl arp_announce muss auf 1; arp_ignore auf 2 gesetzt werden, dann erhält man ein normales und vorhersagbares verhalten; nämlich dass die Kiste auch NUR auf dem interface antwortet die in das jeweiligen Netz gehört. Damit hat man oft schon die meisten Probleme durch/mit ARP-poisoning gelöst...

Ist es nicht auch arp_filter, das auf 1 gesetzt sein soll?

[dufty2]

Hier gibt es eine kleine Übersicht:
https://docs.cumulusnetworks.com/displa ... ocol+-+ARP

Cumulus verwendet für seine Linux-Switche:

cumulus@switch:~$ cat /etc/sysctl.d/arp.conf
net.ipv4.conf.default.arp_announce = 2
net.ipv4.conf.default.arp_notify = 1
net.ipv4.conf.default.arp_ignore=1
cumulus@switch:~$

[McAldo]

Noch ein Thread zu dem Thema: viewtopic.php?t=170133

Das könnte eventuell helfen: http://kb.linuxvirtualserver.org/wiki/U ... isable_ARP

Code: Alles auswählen

echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce

Code: Alles auswählen

vi /etc/sysctl.conf

net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 2