Seltsames Netzwerkverhalten von ICMP-, UDP- und TCP-Paketen bei zwei Netzwerkkarten

[AndreG]

Hallo zusammen,

ich habe hier ein Verhalten von Netzwerk-Devices auf einem Samba 4 (Debian
Buster). Der Server hat zwei Netzwerkkarten enp0s3 (192.168.10.26) und enp0s8
(192.168.0.25) an zwei unterschiedlichen Netzwerken.

Jetzt verhalten sich die beiden teilweise seltsam wenn ich ICMP-, TCP-, UDP-
Pakete an die jeweiligen IP-Adressen sende.
Ich mache von einem Rechner einen Ping auf enp0s8 (192.168.0.25) und beobachte
das auf dem Samba mit

Code: Alles auswählen

tcpdump -i enp0s8 -n icmp

dann schickt der Samba-Server die Antwort nicht über enp0s8 zurück, sondern
über enp0s3 mit der IP-Adresse 192.168.0.25 von enp0s8. Beim Sender zum
Beispiel ein Radius-Server passen also MAC-Adresse der Karte nicht mit der IP-
Adresse überein.
Bei UDP-Paketen antwortet zwar die richtige IP-Adresse, allerdings über das
richtige Netzwerk-Device.
Und bei TCP-Paketen antwortet die richtige IP-Adresse über das richtige
Netzwerk-Device.

Ist das ein Fehler des Samba-Servers oder generell ein Linux-Problem? Wie
lässt sich das lösen? Adrian sprach neulich einmal, das sei ein Kernel-Thema,
bei dem der entsprechende Kernelparameter gesetzt werden müsste.

Gruß

Andre

[MSfree]

Code: Alles auswählen

netstat -rn

?

[BenutzerGa4gooPh]

Zusätzlich

Code: Alles auswählen

route -n
bzw.
ip route show

Zum Verständnis Netzwerk etwas näher beschreiben, kleiner (ASCI-) Plan m. E. sinnvoll ...
http://linux-ip.net/html/tools-ip-route.html
Persönliche Meinung: 2 gleichartige (Ethernet-) NW-Adapter nur mit gutem Grund (Router) oder Teaming/Bonding/LAG (Server).

[AndreG]

Ich kann das Problem momentan nur so beschreiben, weil ich selbst derzeit keinen Zugriff auf das System habe.
Sorry

[MSfree]

Ich kann das Problem momentan nur so beschreiben, weil ich selbst derzeit keinen Zugriff auf das System habe.

Tja, ohne Zugriff wirst du das Problem wohl kaum beheben können.

Die von Jana und mir genannten Befehle liefern dir die Routingtabelle des Systems und die ist mit großer Wahrscheinlichkeit falsch konfiguriert.

[dufty2]

Linux (im default) gehorcht dem sog. "weak host model":
Die IPs werden nicht interface-spezifisch sondern quasi über alle interfaces gesehen.
Hat man zwei interfaces im gleichen netz, kann es sein, dass sich das eine
interface als das andere ausgibt und vice versa.
Es gibt da ein paar sysctl-Einstellung, musst halt mal danach suchen.

[AndreG]

Danke für Deine Informationen. Ich selbst habe mittlerweile das hier ausgemacht:
https://unix.stackexchange.com/question ... interfaces

Zu den sysctl-Einstellungen habe ich vorerst das gefunden

Code: Alles auswählen

sysctl -w net.ipv4.conf.all.arp_announce=1
sysctl -w net.ipv4.conf.all.arp_ignore=2

Ich weiß nur nicht, ob das das Wahre sein wird.

Grüße
Andre

[unitra]

Wenn IP Pakete die über ein spezifische NIC reinkommen (z.B. eth0) nur über diese beantwortet werden sollen benötigt man "source routing" oder "source based routing". Source based bezieht sich auf die Quelle die das IP Paket erhalten hat (eth0) und/oder die IP Adresse auf der Schnittstelle.
Hier die Anleitung:
http://www.tldp.org/HOWTO/Adv-Routing-H ... .rpdb.html

und hier ein spezielles Anwendungsbeispiel:
http://www.tldp.org/HOWTO/Adv-Routing-H ... tml#AEN258

[AndreG]

Was macht man dann, wenn vor allem die Clients ständig an einer anderen Location eingeloggt werden sollen? Denn das heißt, dass in viele Laptops dieses Routing jedes Mal angepasst werden muss, sogar mehrmals am Tag. Denn jedes Mal sind andere VPNs oder Sub-Netze gegeben. Bei den Servern dürfte das die Lösung sein. Aber für die beweglichen, mengenmässigen Laptops ist das keine gute Lösung.
Gäbe da keine Lösung für die mobilen Geräte, die sich genauso authentifizieren und anmelden müssen?

Grüße

Andre

[mat6937]

Zu den sysctl-Einstellungen habe ich vorerst das gefunden

Code: Alles auswählen

sysctl -w net.ipv4.conf.all.arp_announce=1
sysctl -w net.ipv4.conf.all.arp_ignore=2

Ich weiß nur nicht, ob das das Wahre sein wird.

Versuch mal auch mit:

Code: Alles auswählen

sysctl -w net.ipv4.conf.all.arp_filter=1
sysctl -w net.ipv4.conf.default.arp_filter=1

, denn:

arp_filter - BOOLEAN
1 - Allows you to have multiple network interfaces on the same
subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from
the ARP'd IP out that interface (therefore you must use source
based routing for this to work). In other words it allows control
of which cards (usually 1) will respond to an arp request.

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

[unitra]

Wenn sich Deine Frage auf das auf "Source Routing" bezieht dann kann man hier sagen, Du hast den Artikel oder den verlinkten Beitrag auf der Website nicht gelesen, und wenn Du es doch gelesen haben solltest, dann lese es bitte noch einmal.

Was macht man dann, wenn vor allem die Clients ständig an einer anderen Location eingeloggt werden sollen? Denn das heißt, dass in viele Laptops dieses Routing jedes Mal angepasst werden muss, sogar mehrmals am Tag. Denn jedes Mal sind andere VPNs oder Sub-Netze gegeben. Bei den Servern dürfte das die Lösung sein. Aber für die beweglichen, mengenmässigen Laptops ist das keine gute Lösung.
Gäbe da keine Lösung für die mobilen Geräte, die sich genauso authentifizieren und anmelden müssen?

Grüße

Andre

[AndreG]

Okay, zunächst einmal hier die Netzwerkonfiguration des Servers:

Code: Alles auswählen

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#auto enp0s18
#iface enp0s18 inet static
auto ens18
iface ens18 inet static
    address 172.23.0.11
    netmask 255.255.240.0
    gateway 172.23.0.1
#    post-up ip route add 172.23.0.0/20 dev ens18 src 172.23.0.11 table srvnet
#    post-up ip route add default via 172.23.0.1 dev ens18 table srvnet
#    post-up ip rule add from 172.23.0.11/32 table srvnet
#    post-up ip rule add to 172.23.0.11/32 table srvnet

#auto enp0s19
#iface enp0s19 inet static
auto ens19
iface ens19 inet static
    address 172.21.0.11
    netmask 255.255.240.0
    gateway 172.21.0.1
#    post-up ip route add 172.21.0.0/20 dev ens19 src 172.21.0.11 table mgmtnet
#    post-up ip route add default via 172.21.0.1 dev ens19 table mgmtnet
#    post-up ip rule add from 172.21.0.11/32 table mgmtnet
#    post-up ip rule add to 172.21.0.11/32 table mgmtnet

Zusätzlich habe ich folgende Parameter gesetzt:

Code: Alles auswählen

sysctl -w net.ipv4.conf.all.arp_filter=1
sysctl -w net.ipv4.conf.default.arp_filter=1
sysctl -w net.ipv4.conf.all.arp_announce=1
sysctl -w net.ipv4.conf.all.arp_ignore=2

Setze ich jetzt ICMP-Pakete ab, habe ich immer noch ein unzufriedigendes Resultat:

ping -c 5 172.21.0.11 von dem Host 172.21.1.165 liefert das Gewünschte und ens18 bleibt ruhig!

Code: Alles auswählen

tcpdump -i ens19 -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens19, link-type EN10MB (Ethernet), capture size 262144 bytes
13:16:24.388212 IP 172.21.1.165 > 172.21.0.11: ICMP echo request, id 5322, seq 1, length 64
13:16:24.388256 IP 172.21.0.11 > 172.21.1.165: ICMP echo reply, id 5322, seq 1, length 64
13:16:25.406318 IP 172.21.1.165 > 172.21.0.11: ICMP echo request, id 5322, seq 2, length 64
13:16:25.406360 IP 172.21.0.11 > 172.21.1.165: ICMP echo reply, id 5322, seq 2, length 64
13:16:26.430343 IP 172.21.1.165 > 172.21.0.11: ICMP echo request, id 5322, seq 3, length 64
13:16:26.430386 IP 172.21.0.11 > 172.21.1.165: ICMP echo reply, id 5322, seq 3, length 64
13:16:27.454291 IP 172.21.1.165 > 172.21.0.11: ICMP echo request, id 5322, seq 4, length 64
13:16:27.454334 IP 172.21.0.11 > 172.21.1.165: ICMP echo reply, id 5322, seq 4, length 64
13:16:28.478225 IP 172.21.1.165 > 172.21.0.11: ICMP echo request, id 5322, seq 5, length 64
13:16:28.478268 IP 172.21.0.11 > 172.21.1.165: ICMP echo reply, id 5322, seq 5, length 64

Aber, umgekehrt, wenn ich 172.23.0.11 (ens18) anpinge, dann erhält eine KArte den Request, während die Andere den Reply raussendet.

Auf 172.23.0.165:

Code: Alles auswählen

ping -c 5 172.23.0.11
PING 172.23.0.11 (172.23.0.11) 56(84) bytes of data.
64 bytes from 172.23.0.11: icmp_seq=1 ttl=64 time=0.616 ms
64 bytes from 172.23.0.11: icmp_seq=2 ttl=64 time=0.458 ms
64 bytes from 172.23.0.11: icmp_seq=3 ttl=64 time=0.426 ms
64 bytes from 172.23.0.11: icmp_seq=4 ttl=64 time=0.343 ms
64 bytes from 172.23.0.11: icmp_seq=5 ttl=64 time=0.492 ms

--- 172.23.0.11 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4060ms
rtt min/avg/max/mdev = 0.343/0.467/0.616/0.089 ms

Auf dem Server:

Code: Alles auswählen

tcpdump -i ens18 -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens18, link-type EN10MB (Ethernet), capture size 262144 bytes
13:19:49.506050 IP 172.21.1.165 > 172.23.0.11: ICMP echo request, id 5334, seq 1, length 64
13:19:50.507093 IP 172.21.1.165 > 172.23.0.11: ICMP echo request, id 5334, seq 2, length 64
13:19:51.517942 IP 172.21.1.165 > 172.23.0.11: ICMP echo request, id 5334, seq 3, length 64
13:19:52.541840 IP 172.21.1.165 > 172.23.0.11: ICMP echo request, id 5334, seq 4, length 64
13:19:53.566047 IP 172.21.1.165 > 172.23.0.11: ICMP echo request, id 5334, seq 5, length 64

Code: Alles auswählen

tcpdump -i ens19 -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens19, link-type EN10MB (Ethernet), capture size 262144 bytes
13:19:49.506094 IP 172.23.0.11 > 172.21.1.165: ICMP echo reply, id 5334, seq 1, length 64
13:19:50.507145 IP 172.23.0.11 > 172.21.1.165: ICMP echo reply, id 5334, seq 2, length 64
13:19:51.517984 IP 172.23.0.11 > 172.21.1.165: ICMP echo reply, id 5334, seq 3, length 64
13:19:52.541903 IP 172.23.0.11 > 172.21.1.165: ICMP echo reply, id 5334, seq 4, length 64
13:19:53.566092 IP 172.23.0.11 > 172.21.1.165: ICMP echo reply, id 5334, seq 5, length 64

Es ändert sich auch an diesem Verhalten nichts, wenn ich für ens18 zusätzlich "gateway 172.21.0.1" in die /etc/interfaces setze.
Die korrekte Lösung sollte die sein, bei der auch wirklich nur die Schnittstelle antwortet, auf der die Pakete auch eingehen.

Grüße

Andre

[mat6937]

Die korrekte Lösung sollte die sein, bei der auch wirklich nur die Schnittstelle antwortet, auf der die Pakete auch eingehen.

Versuch mal:

Code: Alles auswählen

ping -c 3 -I <source-Interface> <destination-IP-Adresse>

(I ist ein großes i).

[AndreG]

Vom externen Host ausgesendet:

Code: Alles auswählen

ping -c 3 -I eth0 172.21.0.11
PING 172.21.0.11 (172.21.0.11) from 172.21.1.165 eth0: 56(84) bytes of data.
64 bytes from 172.21.0.11: icmp_seq=1 ttl=64 time=0.374 ms
64 bytes from 172.21.0.11: icmp_seq=2 ttl=64 time=0.251 ms
64 bytes from 172.21.0.11: icmp_seq=3 ttl=64 time=0.317 ms

Code: Alles auswählen

tcpdump -i ens19 -n icmp and host 172.21.1.165
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens19, link-type EN10MB (Ethernet), capture size 262144 bytes
15:00:07.651179 IP 172.21.1.165 > 172.21.0.11: ICMP echo request, id 5846, seq 1, length 64
15:00:07.651201 IP 172.21.0.11 > 172.21.1.165: ICMP echo reply, id 5846, seq 1, length 64
15:00:08.666091 IP 172.21.1.165 > 172.21.0.11: ICMP echo request, id 5846, seq 2, length 64
15:00:08.666111 IP 172.21.0.11 > 172.21.1.165: ICMP echo reply, id 5846, seq 2, length 64
15:00:09.689968 IP 172.21.1.165 > 172.21.0.11: ICMP echo request, id 5846, seq 3, length 64
15:00:09.689994 IP 172.21.0.11 > 172.21.1.165: ICMP echo reply, id 5846, seq 3, length 64

und

Code: Alles auswählen

ping -c 3 -I eth0 172.23.0.11
PING 172.23.0.11 (172.23.0.11) from 172.21.1.165 eth0: 56(84) bytes of data.
64 bytes from 172.23.0.11: icmp_seq=1 ttl=64 time=0.493 ms
64 bytes from 172.23.0.11: icmp_seq=2 ttl=64 time=0.360 ms
64 bytes from 172.23.0.11: icmp_seq=3 ttl=64 time=0.384 ms

--- 172.23.0.11 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2053ms
rtt min/avg/max/mdev = 0.360/0.412/0.493/0.060 ms

Dann kommt es unverändert hier

Code: Alles auswählen

tcpdump -i ens18 -n icmp and host 172.21.1.165
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens18, link-type EN10MB (Ethernet), capture size 262144 bytes
15:01:58.483985 IP 172.21.1.165 > 172.23.0.11: ICMP echo request, id 5856, seq 1, length 64
15:01:59.513928 IP 172.21.1.165 > 172.23.0.11: ICMP echo request, id 5856, seq 2, length 64
15:02:00.537785 IP 172.21.1.165 > 172.23.0.11: ICMP echo request, id 5856, seq 3, length 64

rein un dgeht da wieder raus:

Code: Alles auswählen

tcpdump -i ens19 -n icmp and host 172.21.1.165
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens19, link-type EN10MB (Ethernet), capture size 262144 bytes
15:01:58.484019 IP 172.23.0.11 > 172.21.1.165: ICMP echo reply, id 5856, seq 1, length 64
15:01:59.513972 IP 172.23.0.11 > 172.21.1.165: ICMP echo reply, id 5856, seq 2, length 64
15:02:00.537824 IP 172.23.0.11 > 172.21.1.165: ICMP echo reply, id 5856, seq 3, length 64

[AndreG]

Richtig zuverlässig verhält es sich nur mit dieser Netzwerkkonfiguration:

Code: Alles auswählen

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#auto enp0s18
#iface enp0s18 inet static
auto ens18
iface ens18 inet static
    address 172.23.0.11
    netmask 255.255.240.0
    gateway 172.23.0.1
    post-up ip route add 172.23.0.0/20 dev ens18 src 172.23.0.11 table srvnet
    post-up ip route add default via 172.23.0.1 dev ens18 table srvnet
    post-up ip rule add from 172.23.0.11/32 table srvnet
    post-up ip rule add to 172.23.0.11/32 table srvnet

#auto enp0s19
#iface enp0s19 inet static
auto ens19
iface ens19 inet static
    address 172.21.0.11
    netmask 255.255.240.0
    post-up ip route add 172.21.0.0/20 dev ens19 src 172.21.0.11 table mgmtnet
    post-up ip route add default via 172.21.0.1 dev ens19 table mgmtnet
    post-up ip rule add from 172.21.0.11/32 table mgmtnet
    post-up ip rule add to 172.21.0.11/32 table mgmtnet

Die ist aber nicht gewünscht. Ziel soll ein "Strong Hostmodel" sein ohne diese Interimslösung.

[AndreG]

An diiesem Verhalten ändert sich auch nichts, wenn ich das Defaultgateway wechsle:

Code: Alles auswählen

route del default gw 172.23.0.1 ens18
route add default gw 172.21.0.1 ens19

Auch wenn ich das Defaultgateway ganz entferne, ändert sich das Verhalten nicht:

Code: Alles auswählen

netstat -ran
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface
172.21.0.0      0.0.0.0         255.255.240.0   U         0 0          0 ens19
172.23.0.0      0.0.0.0         255.255.240.0   U         0 0          0 ens18

Es wird in immer ens19, wenn positives Verhalten, bevorzugt. ens18 kommt niemals in den Status zu empfangen und zu antworten.

[mat6937]

ens18 kommt niemals in den Status zu empfangen und zu antworten.

Auch dann nicht, wenn Du für die route via ens18, eine bessere/günstigere metric konfigurierst?

[AndreG]

Das ist ja bereits in der "gehackten" Variante mit

Code: Alles auswählen

post-up ip route add 172.23.0.0/20 dev ens18 src 172.23.0.11 table srvnet

gelöst. Hier funktioniert es ja einwandfrei. Nur, und deshalb suche ich nach einer besseren Lösung, ist diese Vorgehensweise unpraktikabel bei Laptops, die wechselnde IP-Adressen haben.
Gerade bei den Laptops mit LAN- und WLAN-Schnittstellen wird dieses Verhalten unangenehm, wenn man sowohl LAN als auch WLAN angeschlossen hat. Wenn ich häufig als Anwender mit meinem Laptop den Platz wechsele (andere Abteilungen etc.) und nicht die nicht benötigte Schnittstelle deaktiviere, dann habe ich dieses Problem. Teilweise funktioniert die Authentifizierung am Netzwerk nicht mehr oder eine bestehende Session mit einer Applikation bricht zusammen.

[BenutzerGa4gooPh]

Die resultierende Routing-Tabelle einschließlich der Metriken?

Code: Alles auswählen

ip route show
default via 10.65.20.1 dev enp2s0 proto static metric 100 
default via 10.65.10.1 dev wlp1s0 proto static metric 600 
10.65.10.0/24 dev wlp1s0 proto kernel scope link src 10.65.10.50 metric 600 
10.65.20.0/24 dev enp2s0 proto kernel scope link src 10.65.20.50 metric 100 
169.254.0.0/16 dev enp2s0 scope link metric 1000 

Teilweise funktioniert die Authentifizierung am Netzwerk nicht mehr oder eine bestehende Session mit einer Applikation bricht zusammen.

Über RADIUS lösen? 802.1X-Authenticator gibt es für professionelle WLAN-APs und professionelle Ethernet-Switches. Mittels RADIUS ist neuerdings auch die Zuweisung gewünschter (unterschiedlicher) VLANs und damit IP-Adressen/Subnets (per DHCP) je nach Authentifizierung (WLAN vs Ethernet) möglich.
https://de.wikipedia.org/wiki/IEEE_802.1X

Gerade bei den Laptops mit LAN- und WLAN-Schnittstellen wird dieses Verhalten unangenehm, wenn man sowohl LAN als auch WLAN angeschlossen hat.

War da auch schon mal verwundert, nachdem ich auf einem Server nur Management per Ethernet-Subnetz zuließ. War der irrigen Ansicht, dass bei aktivem WLAN und Ethernet letzteres priorisiert wird. Nur mit deaktiviertem WLAN des Laptops klappt der Managementzugang zum Server. Die WLAN-Deaktivierung per Applet des DE stört mich nicht. Kann man auch per Terminal tun. 2 Starter für entsprechende (nmcli-) Kommandos? Umgekehrt eben RJ45-Stecker ziehen.
nmcli: https://developer.gnome.org/NetworkMana ... nmcli.html

Edit:
Idee, ungetestet: Ethernet und WLAN bridgen - mit Spanning Tree Protocol. STP dürfte automatisch nur 1 Link in Betrieb halten.
(Könnte im Netz was durcheinander bringen, Brückennummer entsprechend.)
https://en.wikipedia.org/wiki/Spanning_Tree_Protocol