alle IPs pingbar

[Shortie19]

Hallo zusammen,

ich habe hier einen Rechner mit 2 verschiedenen physikalischen Interfaces.
Diese haben je eine statische IP-Adresse welche sich in verschiedenen Subnetzen befinden.

eth0 = 192.168.10.254/24
eth1 = 192.168.178.254/24

Wenn ich nun von einem Rechner mit der IP 192.168.10.200 ( Default Gateway 192.168.10.254) einen ping auf 192.168.178.254 durchführe bekomme ich zu meiner Verwunderung eine Antwort.
Das wäre logisch wenn routing auf dem Server aktiviert wäre, was jedoch nicht der Fall ist.

Code: Alles auswählen

    root@FileTux:~# sysctl -a | grep ip_forward
net.ipv4.ip_forward = 0

Auch die routing Tabelle sagt, dass das jeweilige Netz auf dem jeweiligen Interface geroutet werden soll.

Code: Alles auswählen

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.10.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.178.0   0.0.0.0         255.255.255.0   U         0 0          0 eth1

Interessant wird es wenn ich nun während einem Ping einen tcpdump auf eth1 laufen lasse. Dort sehe ich kein einziges ICMP Packet. Stattdessen sehe ich auf Interface eth0, das dieses meine requests beantwortet und so tut als hätte es die IP von eth1.

Code: Alles auswählen

root@FileTux:~# tcpdump -i eth0 | grep ICMP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:43:53.432698 IP 192.168.10.200 > 192.168.178.254: ICMP echo request, id 512, seq 21257, length 40
15:43:53.432769 IP 192.168.178.254 > 192.168.10.200: ICMP echo reply, id 512, seq 21257, length 40
15:43:54.417782 IP 192.168.10.200 > 192.168.178.254: ICMP echo request, id 512, seq 21513, length 40
15:43:54.417823 IP 192.168.178.254 > 192.168.10.200: ICMP echo reply, id 512, seq 21513, length 40

Zum Testen habe ich auch sämtlichen Traffic auf eth1 mittels iptables verboten. Dennoch antwortet mir die IP 192.168.178.254 weiterhin über eth0.

Kann mir eventuell jemand helfen zu verstehen warum das Verhalten an dieser Stelle so ist? Und zu guter Letzt wie ich dieses Verhalten abstellen kann.

Danke Viele Grüße
Shortie

[dufty2]

Wilkommen im Forum

Stichwort(e) lauten hierzu: Linux = weak host model
vgl. z. B. https://en.wikipedia.org/wiki/Host_model

Kannst mal

Code: Alles auswählen

#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

in /etc/sysctl.d/99-sysctl.conf auskommentieren.
Vielleicht hilfts

[Shortie19]

Hallo,

erstmal vielen dank für die neue Spur.
Leider führt diess aber auch nicht zum Erfolg.

Nach dem was ich aus der Doku herausgefunden habe sind nun folgende Werte gesetzt:

Code: Alles auswählen

root@FileTux:~# sysctl -a | grep "\.ip_forward"
net.ipv4.ip_forward = 0
net.ipv4.ip_forward_use_pmtu = 0
root@FileTux:~# sysctl -a | grep "\.rp_filter"
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 0
root@FileTux:~# sysctl -a | grep "\.arp_ignore"
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.default.arp_ignore = 1
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth1.arp_ignore = 1
net.ipv4.conf.lo.arp_ignore = 0
root@FileTux:~# sysctl -a | grep "\.arp_an"
net.ipv4.conf.all.arp_announce = 1
net.ipv4.conf.default.arp_announce = 1
net.ipv4.conf.eth0.arp_announce = 1
net.ipv4.conf.eth1.arp_announce = 1
net.ipv4.conf.lo.arp_announce = 0

Vorausgesetzt ich habe alles so weit richtig verstanden müssten es diese Werte sein, die das System zwingen requestst immer nur auf dem Interface zu beantworten auf dem sie auch gestellt wurden.
Ich kann die IP von eth1 aber noch immer erreichen und eth0 sended immer brav antworten als wäre es eth1.

Code: Alles auswählen

root@FileTux:~# tcpdump -i eth0 -v | grep ICMP
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:26:43.023775 IP (tos 0x0, ttl 128, id 63406, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.10.200 > 192.168.178.254: ICMP echo request, id 512, seq 2572, length 40
19:26:43.023811 IP (tos 0x0, ttl 64, id 29, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.178.254 > 192.168.10.200: ICMP echo reply, id 512, seq 2572, length 40

Die interfaces sehen so aus:

Code: Alles auswählen

eth0      Link encap:Ethernet  HWaddr 00:01:02:b0:5d:95
          inet addr:192.168.10.254  Bcast:192.168.10.255  Mask:255.255.255.0
          inet6 addr: fe80::201:2ff:feb0:5d95/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2232 errors:0 dropped:0 overruns:1 frame:0
          TX packets:1470 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:178997 (174.8 KiB)  TX bytes:207885 (203.0 KiB)
          Interrupt:16 Base address:0xc000

eth1      Link encap:Ethernet  HWaddr 00:0f:ea:c8:0b:4d
          inet addr:192.168.178.254  Bcast:192.168.178.255  Mask:255.255.255.0
          inet6 addr: fe80::20f:eaff:fec8:b4d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:834 errors:0 dropped:0 overruns:0 frame:0
          TX packets:208 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:65562 (64.0 KiB)  TX bytes:17580 (17.1 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:480 (480.0 B)  TX bytes:480 (480.0 B)

Ein traceroute auf dem client ( 192.168.10.200) behauptet ich könnte die IP direct erreichen:

Code: Alles auswählen

C:\>tracert 192.168.178.254

Routenverfolgung zu 192.168.178.254 über maximal 30 Abschnitte

  1    <1 ms    <1 ms    <1 ms  192.168.178.254

Ablaufverfolgung beendet.

Wie funktioniert das und welchen Sinn erfüllt es? Ich kann die Packete ja nicht mal per iptables filtern, da diese an keiner Chain für das Interface eth1 vorbei kommen sondern einfach direkt von eth0 abgearbeitet werden.

Irgendwie muss man dem System doch beibringen können das es dies unterläst.

Viele Grüße
Shortie

[dufty2]

Yo, ich schrieb ja auch "Vielleicht hilfts"
Was Du noch versuchen könntest:
Die Interfaces in getrennte routing-tables zu stecken, ähnlich wie man es macht,
wenn man "zwei Defaultgateways" anlegen will: http://lartc.org/howto/lartc.rpdb.multiple-links.html

So ähnlich implementiert Android auch das strong host model:
http://netdevconf.org/1.1/proceedings/s ... evices.pdf
Wenn ich das richtig verstanden habe

[BenutzerGa4gooPh]

Jedes Interface in eine von 2 Routing-Instanzen, VRF (Virtual Routing and Forwarding)?
https://docs.cumulusnetworks.com/displa ... ding+-+VRF
Dann dürften die Interfaces wirklich getrennt sein. Auf Routern nutzt man das z. B. um doppelte, private IP-Adressraueme getrennt routen zu können, beispielsweise ein Anbieter für Remote Management hat mehrere Kunden mit gleichem, privaten IP-Adressraum an einem phys. Router.

Es ist allerdings unklar, was du insgesamt beabsichtigst. Man koennte.anderenfalls ueber zweckmaessigiere Technologien nachdenken. Dein Problem hat ja Seltenheitswert.

[dufty2]

Wie funktioniert das und welchen Sinn erfüllt es? Ich kann die Packete ja nicht mal per iptables filtern, da diese an keiner Chain für das Interface eth1 vorbei kommen sondern einfach direkt von eth0 abgearbeitet werden.

Ja was Du aber machen könntest, eine iptables-DROP-Rule zubauen auf dem eth0-Interface für destination <eth1-IP>.