Aug 26, 2014, updated at 15:18:40 (UTC)

2325

Linux Distros versuchen Gateway zu umgehen - stattdessen Paketzustellung direkt bzw. lokal?!

Ich bin bei 2 Linux Distros (Ubuntu 14.04 & Raspian) auf eine Eigenheit wie folgt gestoßen, die mir unter Windows nicht untergekommen ist.

Ich habe einen Rechner mit folgenden Einstellung:
IP: 10.100.1.1/16
Gateway: 10.100.0.1

Die ARP-Tabelle ist geflusht (also ganz leer).

Wenn ich nun auf 10.200.1.1 pingen will, sendet er nicht das Paket an das Gateway sondern will es direkt zustellen?

Wieso?
Ist hier unter Linux noch etwas einzustellen?

Wobei DstMAC: 50:e5:49:..... bereits die MAC des Clients 10.200.1.1 und nicht die von 10.100.0.1 ist?!

Please also mark the comments that contributed to the solution of the article

Content-Key: 247449

Url: https://administrator.de/contentid/247449

Printed on: April 24, 2024 at 08:04 o'clock

49 Comments

Latest comment

Zitat von @paj2000:

Ich habe einen Rechner mit folgenden Einstellung:
IP: 10.100.1.1/16
Gateway: 10.100.0.1
...
Wenn ich nun auf 10.200.1.1 pingen will, sendet er nicht das Paket an das Gateway sondern will es direkt zustellen?
...
Ist hier unter Linux noch etwas einzustellen?

moin,

Sicher? Wie stellst Du fest, daß er direkt zustellen will?
Bist Du sicher, daß Du /16 als maske hast und nicht aus versehen /8?

Poste mal die Ausgaben von ifconfig -a und netstat -r

lks

Du hast aber schon gesehen, dass alle angegebenen Adressen in unterschiedlichen Netzen hängen?

Gruß

Looser

Zitat von @Looser27:

Du hast aber schon gesehen, dass alle angegebenen Adressen in unterschiedlichen Netzen hängen?

Gateway und IP-Adresse sind im selben Netz (=10.100.0.0/16), das Ziel nicht.

Deswegen die frage, wie er es feststellt und ob er einen Tippfehler drin hat, z.B. /16 statt /26.

Klarheit darüber verschaffen die Ausgaben der obigen Befehle.

lks

Client IP 10.100.1.1
Gatew. 10.100.0.1

Schlag mich, aber wenn das kein Tippfehler ist, sind das 2 unterschiedliche Netze.....

Hallo,

Client IP 10.100.1.1
Gatew. 10.100.0.1

bei einer /16 Maske (= 255.255.0.0) ist das ein Netz....

Wohin magst du die Schläge?

brammer

Zitat von @Looser27:

Client IP 10.100.1.1
Gatew. 10.100.0.1

Schlag mich, aber wenn das kein Tippfehler ist, sind das 2 unterschiedliche Netze.....

Warum?

lks.

PS: Ohne Netzmaske kann man überhaupt nicht beurteilen, ob zwei IP-Adressen im selben Netz sind. Aber der TO hatte /16 angegeben.

PPS: Darf ich Cat9 verwenden.

Da ist der Nickname wohl Programm...?! Erst lesen, denken, dann antworten !

Zurück zum Thema...
Das Verhalten kann eigentlich nicht sein und würde dem TCP/IP Standard widersprechen. Das .200er netz ist ein anderes Netz und der Stack müsste dann sofort nach der Router IP 10.100.0.1 ARPen !
Er muss ersten den Router ARPen um das Paket an den Router zustellen zu können.
Gib also mal ein apt-get install tcpdump ein und dann ein tcpdump -v und sieh dir mal genau an was da passiert.
Es kann eigentlich nur sein das du einen Fehler in der IP Konfig hast oder der Router sowas wie Proxy ARP macht wenn das dort aktiviert ist.

Zitat von @aqui:

Es kann eigentlich nur sein das du einen Fehler in der IP Konfig hast oder der Router sowas wie Proxy ARP macht wenn das dort
aktiviert ist.

Eben. Wenn er durch irgendeinen Automatismus /8 statt /16 als Netzmaske für das klassische Class-A-Netz hat, würde das schon passen. deswegen die frage nach ifconfig -a und netstat -r

lks

Das wäre eine denkbare Alternative. Dann hat aber an der Routerkonfig ein Dummie gesessen. Nicht nur das er dann ne falsche Subnetzmaske eingegeben hat er hat dann zusätzlich auch noch Proxy ARP aktiviert. Eigentlich ein NoGo in der Routerkonfig.
Das ist aber jetzt nur wild geraten...?!
Da das Verhalten aber bei 2 unabhängigen Distros passiert (und dann wohl auch bei Winblows und Mac OS-X ebenso...) erhärtet aber diese Vermutung.
Da wär dann mal in der Tat ein Feedback von paj2000 interessant diesbezüglich ?!

kann ich hier .pcab Files von meiner Aufzeichnung posten?

Vorab schon mal die gewünschten Daten:

root@LAPL:~# ifconfig -a
eth0 Link encap:Ethernet Hardware Adresse e4:11:5b:23:95:22
inet Adresse:10.100.1.1 Bcast:10.100.255.255 Maske:255.255.0.0
inet6-Adresse: fec0::e611:5bff:fe23:9522/64 Gültigkeitsbereich:Standort
inet6-Adresse: fec0::5c04:1843:8179:2f48/64 Gültigkeitsbereich:Standort
inet6-Adresse: fe80::e611:5bff:fe23:9522/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX-Pakete:3105 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:731 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:304455 (304.4 KB) TX-Bytes:93216 (93.2 KB)

lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:65536 Metrik:1
RX-Pakete:368 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:368 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX-Bytes:25327 (25.3 KB) TX-Bytes:25327 (25.3 KB)

wlan0 Link encap:Ethernet Hardware Adresse 68:a3:c4:61:6d:c4
BROADCAST MULTICAST MTU:1500 Metrik:1
RX-Pakete:764 Fehler:0 Verloren:68 Überläufe:0 Fenster:0
TX-Pakete:154 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:137988 (137.9 KB) TX-Bytes:24329 (24.3 KB)

wwan0 Link encap:Ethernet Hardware Adresse 02:80:37:ec:02:00
BROADCAST MULTICAST MTU:1500 Metrik:1
RX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:0 (0.0 B) TX-Bytes:0 (0.0 B)

root@LAPL:~# route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.100.0.1 0.0.0.0 UG 0 0 0 eth0
10.100.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0

Zitat von @paj2000:

Vorab schon mal die gewünschten Daten:

root@LAPL:~# ifconfig -a
eth0 Link encap:Ethernet Hardware Adresse e4:11:5b:23:95:22
inet Adresse:10.100.1.1 Bcast:10.100.255.255 Maske:255.255.0.0

o.k.

root@LAPL:~# route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.100.0.1 0.0.0.0 UG 0 0 0 eth0
10.100.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0

o.k.

Des Gatway ist ein frisch aufgesetzter Linux-Server (Ubuntu 14.04).
Ich habe nur eine NEtzwerkkarte mit 2 virutellen Interfaces

Interface p2p1
10.1.1.1/16

Interface p2p1:0
10.100.0.1/16

Interface p2p1:1
10.200.0.1/16

Habe dann das IP-Forwarding mit
echo 1 > /proc/sys/net/ipv4/ip_forward
aktiviert
und das wars

oder zumindest Bilder/Screenshots posten von den Ausgaben in Wireshark?

Zitat von @paj2000:

oder zumindest Bilder/Screenshots posten von den Ausgaben in Wireshark?

Formatting instructions in the posts

Zitat von @paj2000:

Des Gatway ist ein frisch aufgesetzter Linux-Server (Ubuntu 14.04).
Ich habe nur eine NEtzwerkkarte mit 2 virutellen Interfaces

Interface p2p1
10.1.1.1/16

Interface p2p1:0
10.100.0.1/16

Interface p2p1:1
10.200.0.1/16

Habe dann das IP-Forwarding mit
echo 1 > /proc/sys/net/ipv4/ip_forward
aktiviert
und das wars

Dann ist das klar. Sofern Du keine (offensichtlich) VLANs verwendest, laufen alle Netze auf demselben Segment. Wie sagt kollege aqui imerm so schön:

Der Betrieb mehrerer IP-netze auf demselben LAN-Segment ist nicht ein nogo (Ich sag lieber "not recommended").

Da kommt es dann zu solchen (und vielen anderen) Effekten. Warum sollte Deine Kiste das Paket ans default gateway schicken, wenn doch das Ziel doch direkt erreichbar ist. Hast Du darauf geachtet, ob entsprechende ICMP-Pakete über die Leitung gegangen sind?

lks

wenn ich es in VLANs betreiben würde, kommt der Ping gar nicht an, da er aus dem VLAN des Netzes 10.100.0.0/16 nicht auf das VLAN mit NetzID 10.200.0.0/16 kommt.

Warum ist es Dir klar das er wegen der Server-Konfiguration am Client mit IP 10.100.1.1 den ICMP-Ping nicht über 10.100.0.1 sonder direkt auf 10.200.1.1 zustellt?

Zitat von @paj2000:

wenn ich es in VLANs betreiben würde, kommt der Ping gar nicht an, da er aus dem VLAN des Netzes 10.100.0.0/16 nicht auf das
VLAN mit NetzID 10.200.0.0/16 kommt.

Dann machst Du was falsch. Er müßte dann das paket ans Gateway schicken.

Warum ist es Dir klar das er wegen der Server-Konfiguration am Client mit IP 10.100.1.1 den ICMP-Ping nicht über 10.100.0.1
sonder direkt auf 10.200.1.1 zustellt?

Weil vermutlch die Kiste über ICMP gesagt bekommen hat, daß 10.200.1.1 im selben Segment hängt.

So oder so: Zwei IP-Netze im selben Segment zu betreiben ist jedenfalls keine gute Idee, wenn man nicht weiß, wie man mit solchen unerwarteten Effekten umgeht.

lks

Bild eingefügt in Beitrag

Und wie gesagt: Wenn ich sie in getrennte VLANs packe dann funktioniert der Ping nicht mehr da er direkt zustellen will, was ja nicht geht.
So bin ich ja erst auf das ganze aufmerksam geworden!

Zitat von @paj2000:

Bild eingefügt in Beitrag

Das sieht doch in Ordnung aus:

Quelle und Ziel sind korrekt und das Paket wird an das default gateway geschickt, daß durch Deine Kostruiktion dieselbe Mac hat wie das Ziel und daher es nicht von einem Paket zu untescheiden ist, daß direkt ans ziel geschickt wird.

Wo ist das problem? Sieht doch alles in Ordnung aus.

lks

Zitat von @paj2000:

Und wie gesagt: Wenn ich sie in getrennte VLANs packe dann funktioniert der Ping nicht mehr da er direkt zustellen will, was ja
nicht geht.

Wie machst Du Deine VLANS? Und wie definierst Du dann die Interfaces in Deinem "Router".

lks

???
Paket1
SenderIP 10.100.1.1 (OK)
EmpfängerIP 10.200.1.1 (OK)
SenderMAC: e4:11:5b:23:95:22 (OK - ist MAC von meinem Laptop)
EmpfängerMAC: 50:e5:49:5b:5b:fd (NICHT OK - dies ist MAC-Adresse von 10.200.1.1 - hier müsste die MAC-Adresse des Gateways 10.100.0.1 stehen!!)

oder nicht?

auto p2p1
iface p2p1 inet static
address 10.1.1.1
netmask 255.255.0.0
gateway 10.1.9.1
dns-nameservers 10.1.9.1

auto p2p1:0
iface p2p1:0 inet static
address 10.100.0.1
netmask 255.255.0.0

auto p2p1:1
iface p2p1:1 inet static
address 10.200.0.1
netmask 255.255.0.0

Zitat von @paj2000:

???
Paket1
SenderIP 10.100.1.1 (OK)
EmpfängerIP 10.200.1.1 (OK)
SenderMAC: e4:11:5b:23:95:22 (OK - ist MAC von meinem Laptop)
EmpfängerMAC: 50:e5:49:5b:5b:fd (NICHT OK - dies ist MAC-Adresse von 10.200.1.1 - hier müsste die MAC-Adresse des
Gateways 10.100.0.1 stehen!!)

Das ist doch dieselbe, wenn Du gateway und ziel beide auf das interface p2p1 draufknallst.

lks

PS: Mach mal einen ifconfig -a auf deinem gateway und poste das.

Das sind keine VLANS.

Da werden einafch nur einem Interface nur mehrere IP-Adressen zugeteilt.

Lies dir mal http://manpages.ubuntu.com/manpages/trusty/man5/vlan-interfaces.5.html durch.

lks

ich habe keine vlan-specific tags bzw. konfigurationen vorgenommen, da ich ja hinter einem Untagged Port mit dem Router sitze.

Rechner 10.100.1.1/16 gehört zu VLAN2 (Sitzt hinter Port 2)
Rechner 10.200.1.1/16 gehört zu VLAN3 (Sitzt hinter Port 3)

Router/Server 10.1.1.1/16 gehört zu VLAN1 (Sitzt hinter Port 1)

Port 1 ist für VLAN1-3 berechtigt und vergibt den Tag für VLAN1 für eintreffende Pakete vom Server
Port 2 ist für VLAN1-2 berechtigt und vergibt den Tag für VLAN2 für eintreffende Pakete vom Client 10.100.1.1/16
Port 3 ist für VLAN1&3 berechtigt und vergibt den Tag für VLAN3 für eintreffende Pakete vom Client 10.200.1.1/16

Ich habe nur eine NEtzwerkkarte mit 2 virutellen Interfaces

Uuuhhh böses Faul...da geht das Drama schon los. Das ist kein supportetes Design im TCP/IP ! Sowas macht man ausschliesslich temporär für IP Migrationen aber niemals im Wirkbetrieb. Du fährst so mit mehreren IP Adressen auf einem gemeinsamen Draht ! Ein NoGo.
Kein Wunder das es da zu Problemen kommt, denn allein schon die ganze ICMP Geschichte funktioniert so nicht mehr, denn von welcher IP sollte der Host dann ICMP wohl machen ?
Vergiss den Unsinn...
Wenn überhaupt dann solltest du dort sauber mit VLANs arbeiten auf einem singulären Interface. Das garantiert ein sauberes Routing !
Wie das geht kannst du hier nachlesen:
Netzwerk Management Server mit Raspberry Pi

Alles andere ist zum Scheitern verurteilt.

lo Link encap:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:65536 Metrik:1
RX-Pakete:437 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:437 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX-Bytes:39272 (39.2 KB) TX-Bytes:39272 (39.2 KB)

p2p1 Link encap:Ethernet Hardware Adresse 74:d0:2b:90:42:72
inet Adresse:10.1.1.1 Bcast:10.1.255.255 Maske:255.255.0.0
inet6-Adresse: fe80::76d0:2bff:fe90:4272/64 Gültigkeitsbereich:Verbindung
inet6-Adresse: fec0::6d31:1285:65d9:16bd/64 Gültigkeitsbereich:Standort
inet6-Adresse: fec0::76d0:2bff:fe90:4272/64 Gültigkeitsbereich:Standort
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX-Pakete:93372 Fehler:0 Verloren:64 Überläufe:0 Fenster:0
TX-Pakete:67477 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:21417914 (21.4 MB) TX-Bytes:19296747 (19.2 MB)

p2p1:0 Link encap:Ethernet Hardware Adresse 74:d0:2b:90:42:72
inet Adresse:10.100.0.1 Bcast:10.100.255.255 Maske:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1

p2p1:1 Link encap:Ethernet Hardware Adresse 74:d0:2b:90:42:72
inet Adresse:10.200.0.1 Bcast:10.200.0.255 Maske:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1

p3p1 Link encap:Ethernet Hardware Adresse 00:c0:ca:13:13:d7
BROADCAST MULTICAST MTU:1500 Metrik:1
RX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:0 (0.0 B) TX-Bytes:0 (0.0 B)

Ich habe mich an diese anleitung gehalten:
http://www.heise.de/netze/artikel/Linux-224004.html

ein Server mit einer Netzwerkkarte der zwischen den einzelnen /16-Netze (welche alle in eigene VLANS gekapselt sind) als Router vermittelt ... nichts anderes mache ich da.

Und das kann nicht funktionieren?

Die ist generell richtig nur kann das sein das du sie falsch umgesetzt hast ??
WIE bindest du dann den Switch an bzw. wie ist dessen Konfig ??
Irgendwo liegt da was im Argen...

Dieses Tutorial hat weitere Details dazu:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern

Das RasPi VLAN Tutorial oben hat aber eine aktuelle Konfig. Die von Heise ist schon älzer und stimmt ggf. nicht mehr. Beachte das !
In einem RasPi VLAN laut der Tutorial Konfig passiert das nämlich nicht was du schilderst !

ich werde die tutorials nachher beim Abendessen durchackern...
AdHoc sehe ich aber hier keinen Fehler bei mir ... in dem RaspiVLAN Tutorial sitz er halt hinter einem Tagged Port des Switches, wodurch die "vlan-fähigkeit" des Raspis von nöten ist ... ich habe ihn auch untagged hinter einem switch sitzen, sodass er die VLAN-Tags schon am Port rausfiltert, sodass sie untagged auf den Server kommen ... dass ist ja im Prinzip das selbe oder nicht?!

Zitat von @paj2000:

ich habe keine vlan-specific tags bzw. konfigurationen vorgenommen, da ich ja hinter einem Untagged Port mit dem Router sitze.

Rechner 10.100.1.1/16 gehört zu VLAN2 (Sitzt hinter Port 2)
Rechner 10.200.1.1/16 gehört zu VLAN3 (Sitzt hinter Port 3)

Router/Server 10.1.1.1/16 gehört zu VLAN1 (Sitzt hinter Port 1)

Port 1 ist für VLAN1-3 berechtigt und vergibt den Tag für VLAN1 für eintreffende Pakete vom Server
Port 2 ist für VLAN1-2 berechtigt und vergibt den Tag für VLAN2 für eintreffende Pakete vom Client 10.100.1.1/16
Port 3 ist für VLAN1&3 berechtigt und vergibt den Tag für VLAN3 für eintreffende Pakete vom Client
10.200.1.1/16

Ich glaube es wäre ganz geschickt, wenn Du uns mal ein Bild von Deinem Netz malst mit passenden IP-Adressen udn VLAN-Bezeichnungen.

Ich habe den Verdacht, daß irgendetwas an Deiner VLAN-Konfiguration faul ist udn du auch mit den IP-Adressen irgendwie durcheinander bist.

Außerdem stellt sich mir die Frage warum Du die Ports nicht einfach als tagged definierst? Mit deinem Linux kannst du das ohen weiteres einrichten und konfigurieren.

lks

Da ist de facto was mit dem VLAN Setting der Server NIC im Argen !
Ein tcpdump sollte das aber schnell zeigen.

Zitat von @aqui:

Da ist de facto was mit dem VLAN Setting der Server NIC im Argen !

Er nutzt dort überhaupt kein VLAN Um VLANs zu nutzen, müßte er Puntke statt doppelpunkte in /etc/network/interfaces nutzen. Alelrdings muß er den Potzr dazu als tagged-Port betreiben.

lks

Falsch ! Die oben zitierte ct' Anleitung bezieht sich ja auf eine tagged VLAN Konfig an einem Linux Host, denn es behandelt ja VLAN Tagging und eben keine Subinterface Konfig !
Die zitierte Debian Konfig (RasPi) ist aber aktueller und benutzt auch aktuelle Pakete und funktioniert (getestet !) auch fehlerfrei.
Letztere ist IP technisch ja auch nicht zu empfehlen wegen der gravierenden Nachteile.

Zitat von @aqui:

Falsch ! Die oben zitierte ct' Anleitung bezieht sich ja auf eine tagged VLAN Konfig an einem Linux Host, denn es behandelt
ja VLAN Tagging und eben keine Subinterface Konfig !

schon.

Aber laut dem Auszug aus seinen /etc/network/interfaces hat er immer nur subinterfaces benuzt und nie vlans

p2p1 Link encap:Ethernet Hardware Adresse 74:d0:2b:90:42:72
...
p2p1:0 Link encap:Ethernet Hardware Adresse 74:d0:2b:90:42:72
...
p2p1:1 Link encap:Ethernet Hardware Adresse 74:d0:2b:90:42:72

Das sieht für mich nicht nach getaggeden VLANs aus.

Oder er hat schlicht und einfach statt p2p1 . 1 p2p : 1 genommen.

lks

Vielen Dank vorab für Eure Geduld ... habe heute mir mal das ganze nochmals zu gemüte geführt ... vergesst mal das VLAN ... ich mache das morgen so wie in der RaspiDoku ... doch eines geht mir noch immer nicht ein.
Wenn ich einen Rechner habe mit
IP: 10.120.1.1/16
Gateway 10.120.0.1
und danach einen Host pingen will mit 10.100.1.1 dann muss doch das Paket an das Gateway gesandt werden?!? oder nicht?!
Und er versucht bei mir immer per ARP zuerst die MAC von 10.100.1.1 zu erfragen und dann das Paket direkt zustellen an 10.100.1.1 anstatt es an 10.120.0.1 zu senden?!

Der Vollständigkeit halber die Ausgabe von "route -n":
root@LAPL:~# route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.120.0.1 0.0.0.0 UG 0 0 0 eth0
10.120.0.0 0.0.0.0 255.255.0.0 U 1 0 0 eth0

Kann ich hier einen Mitschnitt von tcpdump bzw. Wireshark hier als Datei posten?

Antwort gefunden!!!!
Check this out: http://serverfault.com/questions/331561/linux-routing-bug

Es war so dass ich vom Gateway eine ICMP-Redirect (Code 5) Anforderung bekommen habe Pakete an 10.100.1.1 direkt zuzustellen ...
die Frage ist nun aber noch: Warum sendet mein Router/Server dies?
Redirect Messages werden doch nur gesandt, wenn es im gleichem Netzsegment eine direktere Verbindung gibt wie hier erklärt:
http://kb.pocnet.net/wiki/ICMP-Redirects
Dies ist jedoch bei meinem Setup nicht der Fall ... da werde ich wohl noch etwas suchen müssen ... oder mir helfen lassen müssen ;)

Zitat von @paj2000:

Dies ist jedoch bei meinem Setup nicht der Fall ... da werde ich wohl noch etwas suchen müssen ... oder mir helfen lassen
müssen ;)

Doch. Dein "Router" hat beide "Beine" im selben Segment, weil Du beide Netze auf dasselbe Interface gelegt hast.

lks

Dann verstehe ich es ... vielen Dank für das Licht der Erkenntnis - es ist schön aus dem Dunklen hervorzukriechen ;)

Dann ist dies wie in diesem Artikel (http://www.heise.de/netze/artikel/Linux-224004.html) beschrieben eigentlich wie folgt zu ergänzen:
Da die Vermittlung(Routing) zwischen den VLANs(und den dazugehörigen IP-Netzen) ein Server mit nur einer physischen Karte und mehreren logischen Interfaces durchführt, müssen ICMP-Redirect-Messages am Server ausgeschalten werden (da der Routers durch die logischen Interfaces den Zugang in jedes Netz mit nur einer physikalischen Netzwerkkarte hat und so immer Redirect Messages ausgibt):
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

Bitte nochmals um kurze Bestätigung ob ich das so richtig verstanden und beschrieben habe ;)

Was ich für mich noch checken muss ist, warum der Ping vom Windowsclient auf eine Netzwerkkomponente in einem anderem Netz sauber geroutet wurde und funktioniert hat, hingegen zum Linuxlaptop (der wiederum in einem anderem Netz war) nicht?!

noch ein kurzer Nachtrag:
statt
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
habe ich nun die NIC direkt angegeben ... dann funktionierts:
echo 0 > /proc/sys/net/ipv4/conf/p2p1/send_redirects

Ist ja eine interessante Lösung ! An einen Kernel Bug denkt man ja immer zuletzt. Gut wenns nun klappt obwohl es doch dann wieder Fragen aufwirft, denn in einer sauberen VLAN Konfiguration der NIC sollte das (getestet) NICHT passieren !

Bitte nochmals um kurze Bestätigung ob ich das so richtig verstanden und beschrieben habe ;)

Nein, deine Schlussfolgerung ist falsch von oben...!
Man muss das schon sehr genau betrachten. Es gilt folgendes:

1.) Wenn du mit Secondary IP Adressen fährst also EIN physisches Interface hast auf dem du mehrere unterschiedliche IP Adapter Adressen hast dann bekommst du logischerweise ein Problem mit ICMP Redirects. Der Router weiss ja nicht von welcher IP er die ICMP Pakete senden soll. Meist macht er es von der Promäradresse, was dann aber bewirkt das alle anderen Secondary IPs an diesem Interface ausgespart werden. Dadurch kommt es eben zu dem ICMP Chaos.
Genau DAS ist einer der vielen Gründe warum Secondary IPs auf einer physischen NIC kein besonders gutes Design ist.
Es lässt sich manchmal nicht vermeiden wenn man IP Adressen migriert in einem Segment. Allein dafür ist es auch gedacht, denn für eine temporäre Migration kann man das machen.
Niemals aber für den Produktivbetrieb !!

2.) Ganz anders sieht die Sache aus wenn du auf dem Router oder in deinem Falle Host VLAN Interfaces anlegst. Immer unter der Voraussetzung das das richtig gemacht wird wie z.B. im o.a. Raspberry_Tutorial unterm Kabitel VLAN Installation beschrieben.
Die ct' Anleitung beschreibt das ebenso aber mit etwas älteren Kommandos und Paketet die dann nicht immer richtig funktionieren.
Generell ist es aber so das diese Konfiguration auf der NIC 2 virtuelle und völlig getrennte Interfaces kreiert, die der Rechner auch so behandelt.
Zwar gehen sie physisch über eine NIC sind intern im Kernel aber 2 vollkommen getrennte NICs wenn man so will. Damit schickt der Rechner auch getrennt ICMP und alle anderen Kontrol Pakete über diesen Link sauber pro Interface getrennt.
Sie tauchen zwar wieder physisch an der gleichen NIC auf aber die Pakete haben ja immer eine eindeutige VLAN ID im 802.1q VLAN Header des Pakets.
An diesen NICs kann man dann auch nur Switches anschliessen oder Endgeräte die Pakete mit 802.1q VLAN Tagging verstehen, also tagged Uplinks.
Diese Komponenten trennen diesen Traffic ja auch immer wieder in völlig getrennte Segmente, eben VLANs.
Rein funktionell betrachtet verhält sich diese Konfiguration der NIC exakt so wie 2 separat getrennte NICs im Rechner. Nichts anderes emulieren ja die virtuellen internen NICs mit dem Tagging.

In so fern hast du hier also 2 völlig unterschiedliche Designs und Szenarien die du auch so betrachten musst.
Vereinfacht gesagt:
Secondary IPs = Mehrere IP Netze auf einem Draht ==> technisch kein TCP/IP Support = Probleme = NoGo
VLAN Separation der NIC = saubere Trennung ==> problemlos da TCP/IP technsich sauber = richtige Konfig = erfordert aber VLAN Switch