IP Konflikt bei 2 NICs

[przemy]

Ich habe auf einem Server 2 NICs, die statische IPs per DHCP von einer pfSense firewall bekommen. Ruft man

Code: Alles auswählen

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    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 00:1e:67:6a:7c:dd brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.231/24 brd 192.168.2.255 scope global eno1
       valid_lft forever preferred_lft forever
    inet6 fde2:8acd:e9d3:0:21e:67ff:fe6a:7cdd/64 scope global mngtmpaddr dynamic
       valid_lft 86387sec preferred_lft 14387sec
    inet6 fe80::21e:67ff:fe6a:7cdd/64 scope link
       valid_lft forever preferred_lft forever
3: rename3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:1e:67:6a:7c:dc brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.12/24 brd 192.168.2.255 scope global rename3
       valid_lft forever preferred_lft forever
    inet6 fde2:8acd:e9d3:0:21e:67ff:fe6a:7cdc/64 scope global mngtmpaddr dynamic
       valid_lft 86387sec preferred_lft 14387sec
    inet6 fe80::21e:67ff:fe6a:7cdc/64 scope link
       valid_lft forever preferred_lft forever

so sieht alles in Ordnung aus.
Jedoch kommt es immer wieder vor, dass manche PCs den Webserver unter der Adresse 192.168.2.12 nicht erreichen können und dass die PCs im arp cache die falsche 00:1e:67:6a:7c:dd MAC-Adresse haben. Außerdem bekomme ich durch aufrufen vom folgenden von einem anderen PC aus einen Konflikt:

Code: Alles auswählen

arping 192.168.2.12

ARPING 192.168.2.12
60 bytes from 00:1e:67:6a:7c:dc (192.168.2.12): index=0 time=15.387 msec
60 bytes from 00:1e:67:6a:7c:dd (192.168.2.12): index=1 time=15.438 msec

Dies wird auch durch folgende regelmäßig auftretenden Meldungen im pfSense System log bestätigt:

Code: Alles auswählen

...
May 23 08:41:25 	kernel 		arp: 192.168.2.12 moved from 00:1e:67:6a:7c:dd to 00:1e:67:6a:7c:dc on em0
May 23 08:54:06 	kernel 		arp: 192.168.2.231 moved from 00:1e:67:6a:7c:dd to 00:1e:67:6a:7c:dc on em0
May 23 09:51:04 	kernel 		arp: 192.168.2.231 moved from 00:1e:67:6a:7c:dd to 00:1e:67:6a:7c:dc on em0 
May 23 10:50:40 	kernel 		arp: 192.168.2.231 moved from 00:1e:67:6a:7c:dd to 00:1e:67:6a:7c:dc on em0 

Hat jemand eine Idee wie man das Problem beheben kann?

[mat6937]

Außerdem bekomme ich durch aufrufen vom folgenden von einem anderen PC aus einen Konflikt:

Poste mal von diesem anderen PC, die Ausgaben von:

Code: Alles auswählen

route -n
arp -av
ip -4 r
ip n s

[Gunman1982]

Darf man fragen was du mit 2 Netzwerkkarten im gleichen SubNetz bezwecken willst?

[przemy]

Bekomme die folgenden Ausgaben von einem Debian Stretch System:

Code: Alles auswählen

 route -n
-bash: route: Befehl nicht gefunden

arp -av
-bash: arp: Kommando nicht gefunden.

ip -4 r
default via 192.168.2.1 dev enp2s0
192.168.2.0/24 dev enp2s0 proto kernel scope link src 192.168.2.232

ip n s
192.168.2.231 dev enp2s0 lladdr 00:1e:67:6a:7c:dc STALE
192.168.2.17 dev enp2s0 lladdr fc:aa:14:81:78:b9 REACHABLE
192.168.2.3 dev enp2s0 lladdr 00:0e:1e:5c:5c:a2 REACHABLE
192.168.2.100 dev enp2s0 lladdr f0:de:f1:35:c8:e2 STALE
192.168.2.10 dev enp2s0 lladdr 94:de:80:4d:5e:2e STALE
192.168.2.1 dev enp2s0 lladdr 00:22:4d:83:13:5d STALE
fe80::baec:a3ff:fe98:9700 dev enp2s0 lladdr b8:ec:a3:98:97:00 router STALE

Darf man fragen was du mit 2 Netzwerkkarten im gleichen SubNetz bezwecken willst?

Die NICs waren im Server bereits verbaut, also hab ich sie drin gelassen. Wollte dann, dass Zugriff zu einem Datenserver über die andere Karte wie der Webserver läuft, aber dies hat nur Probleme gemacht. Jetzt ist auf einem interface ssh und datenbank, auf auf dem anderen ein Webserver.

[mat6937]

Code: Alles auswählen

ip -4 r
default via 192.168.2.1 dev enp2s0
192.168.2.0/24 dev enp2s0 proto kernel scope link src 192.168.2.232

Code: Alles auswählen

ip n s
192.168.2.231 dev enp2s0 lladdr 00:1e:67:6a:7c:dc STALE

192.168.2.1 dev enp2s0 lladdr 00:22:4d:83:13:5d STALE

Konfiguriere statische arp-cache-Einträge für beide NICs und je eine definierte route pro NIC, mit unterschiedlicher metric.

[Gunman1982]

Darf man fragen was du mit 2 Netzwerkkarten im gleichen SubNetz bezwecken willst?

Die NICs waren im Server bereits verbaut, also hab ich sie drin gelassen. Wollte dann, dass Zugriff zu einem Datenserver über die andere Karte wie der Webserver läuft, aber dies hat nur Probleme gemacht. Jetzt ist auf einem interface ssh und datenbank, auf auf dem anderen ein Webserver.

Hast du dabei schon mal an "bonding" gedacht? Load-balancing bzw. backup, wäre vielleicht eine Überlegung wert. Dann wäre per DHCP allerdings nur 1 IP auf der Kiste, statisch gingen natürlich mehrere virtuelle Adressen.

[przemy]

Hast du dabei schon mal an "bonding" gedacht? Load-balancing bzw. backup, wäre vielleicht eine Überlegung wert. Dann wäre per DHCP allerdings nur 1 IP auf der Kiste, statisch gingen natürlich mehrere virtuelle Adressen.

Nein, aber dies klingt perfekt eigentlich, also werde ich es mir aufjedenfall anschauen.
Wie zuverlässig ist dieses Verfahren? Leider kann ich hauptsächlich nur über ssh (stressfrei) auf den Server zugreifen und in der Anleitung (https://wiki.debian.org/Bonding) die ich gerade überflogen habe steht, dass ich die Interfaces deaktivieren muss, aber dies würde zum Verlust meiner ssh-Verbindung führen? Würde es auch "risikofrei" klappen, wenn ich nur /etc/network/interfaces konfiguriere und dann neustarte ohne die Interfaces davor zu deaktivieren?

Konfiguriere statische arp-cache-Einträge für beide NICs und je eine definierte route pro NIC, mit unterschiedlicher metric.

Ich habe bereits versucht statische arp-cache Einträge auf einer Windows 7 Maschine zu setzen, da ich bislang immer nur von Windows PCs den Webserver nicht erreichen konnte, jedoch hat dies nicht zum Ziel geführt. Die Debian PCs erreichen den Webserver immer problemos trotz falscher Einträge im arp-cache.
Könntest du den Vorschlag mit den Routen ein wenig ausführlicher vorstellen?
Lässt sich das Problem auch direkt auf dem Server mit den 2 NICs beheben? Würde es das Problem beheben, wenn man ein Interface deaktiviert?

[Gunman1982]

Hast du dabei schon mal an "bonding" gedacht? Load-balancing bzw. backup, wäre vielleicht eine Überlegung wert. Dann wäre per DHCP allerdings nur 1 IP auf der Kiste, statisch gingen natürlich mehrere virtuelle Adressen.

Nein, aber dies klingt perfekt eigentlich, also werde ich es mir aufjedenfall anschauen.
Wie zuverlässig ist dieses Verfahren? Leider kann ich hauptsächlich nur über ssh (stressfrei) auf den Server zugreifen und in der Anleitung (https://wiki.debian.org/Bonding) die ich gerade überflogen habe steht, dass ich die Interfaces deaktivieren muss, aber dies würde zum Verlust meiner ssh-Verbindung führen? Würde es auch "risikofrei" klappen, wenn ich nur /etc/network/interfaces konfiguriere und dann neustarte ohne die Interfaces davor zu deaktivieren?

Sofern dein Netzwerk über "/etc/network/interfaces" konfiguriert ist würde ein "/etc/init.d/networking restart", wäre aber wahrscheinlich sinnvoll das erst mal mit einer virtuellen Maschine auszuprobieren bevor du dich aussperrst.

[bluestar]

Wenn du zwei NICs im gleichen Subnetz betreiben willst, dann musst du arp_filter auf 1 setzen.

https://www.kernel.org/doc/Documentatio ... sysctl.txt