lordgurke
Sep 06, 2010
view5148
view2
1
Goto Top

Debian mit 3 NICs antwortet mit falscher MAC-Adresse

GermansolvedQuestionDebianLinux
Hallo zusammen,

hier steht ein Debian Lenny-System welches als normaler Internetrouter (PPPoE) und OpenVPN-Router dient.
Es sind insgesamt drei Netzwerkkarten verbaut: Eine zum DSL-Modem (eth1), eine zum LAN (eth0) und eine für den Zugriff auf per OpenVPN angebundene Netzwerke (eth2).

Hier die Ausgabe von ifconfig:
// NIC fürs lokale Netzwerk
eth0      Link encap:Ethernet  Hardware Adresse 00:22:2d:27:76:d5
          inet Adresse:192.168.0.3  Bcast:192.168.0.255  Maske:255.255.255.0
          inet6-Adresse: fe80::222:2dff:fe27:76d5/64 Gültigkeitsbereich:Verbindung
          inet6-Adresse: 2a02:a00:e000:b:8000::1/65 Gültigkeitsbereich:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:9661352 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18079304 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:2584968946 (2.4 GiB)  TX bytes:4167620802 (3.8 GiB)
          Interrupt:12 Basisadresse:0xc100

// NIC zum DSL-Modem
eth1      Link encap:Ethernet  Hardware Adresse 00:22:2d:27:76:55
          inet Adresse:192.168.1.2  Bcast:192.168.1.255  Maske:255.255.255.0
          inet6-Adresse: fe80::222:2dff:fe27:7655/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:12263334 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8669838 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:2207394862 (2.0 GiB)  TX bytes:2272130910 (2.1 GiB)
          Interrupt:11 Basisadresse:0xe100

// OpenVPN-Routing
eth2      Link encap:Ethernet  Hardware Adresse 00:50:bf:a6:24:a3
          inet Adresse:172.19.25.1  Bcast:172.19.25.255  Maske:255.255.255.0
          inet6-Adresse: fe80::250:bfff:fea6:24a3/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:7945658 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3594960 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:1125099109 (1.0 GiB)  TX bytes:474325583 (452.3 MiB)
          Interrupt:10 Basisadresse:0xe400

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:16436  Metrik:1
          RX packets:1889 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1889 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:117975 (115.2 KiB)  TX bytes:117975 (115.2 KiB)

// DSL-Verbindung
ppp0      Link encap:Punkt-zu-Punkt-Verbindung
          inet Adresse:92.226.125.***  P-z-P:213.191.89.30  Maske:255.255.255.255
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1492  Metrik:1
          RX packets:120628 errors:0 dropped:0 overruns:0 frame:0
          TX packets:105958 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:3
          RX bytes:83454955 (79.5 MiB)  TX bytes:23541156 (22.4 MiB)

eth0 und eth2 sind am selben Switch angeschlossen. Auch wenn ich dabei etwas Bauchschmerzen hatte, ging das bisher erstaunlich gut.
Früher war es mal so, dass da nur zwei Netzwerkkarten drin waren und die OpenVPN-Routeradresse mit an eth0 gebunden wurde. Aufgrund der Tatsache, dass man dann nicht mehr so toll ermitteln konnte, ob der Traffic auf dem Interface nun ins Internet oder ins VPN ging, wurde das auf eine weitere Netzwerkkarte verlegt. Einzelne Rechner sollen direkt von der anderen Seite des VPN-Tunnels über eine 172.19.25er-Adresse erreichbar sein, deshalb auch dieses merkwürdige Konstrukt.


Folgendes nerviges Problem tritt nun in letzter Zeit immer wieder auf:
Einige Rechner - auch solche, die garkeine 172er-Adresse haben - bekommen auf einmal keine Verbindung mehr ins Internet. Wenn man dann in den ARP-Cache sieht, stellt man fest, dass für die IP-Adresse 192.168.0.3 die MAC-Adresse von eth2 auftaucht.
Löscht man den Eintrag dann, hat man meistens Glück, dass daraufhin wieder die richtige MAC-Adresse drinsteht und die Verbindung zum Internet wieder funktioniert - manchmal muss man die Adresse auch ein paar Mal löschen.

Ich weiß ehrlich gesagt nicht wirklich, was da schiefläuft. Vermutlich ist das ein Fehler, den Debian verursacht - aber wie kann ich diesen so gut es geht beheben? Bin für jeden Tipp dankbar!


Vielen Dank im Voraus!
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 150446

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

Printed on: April 25, 2024 at 23:04 o'clock

2 Comments
Latest comment
Goto Top
Member: aqui
aqui Sep 06, 2010 at 17:56:07 (UTC)
Goto Top
"...eth0 und eth2 sind am selben Switch angeschlossen. " Das geht schonmal gar nicht. Damit setzt du zwei Layer 3 IP Netze über einen Layer 2 Switch in einer Broadcast Domain zusammen.
Ein absolutes No Go in einem Netzwerkdesign wie jeder IP Erstklässler in der Grundschule lernt ! Letztlich der Quell der Probleme...
Wenn, dann hätte es ein simpler VLAN fähiger Switch gelöst den es auch für kleines Geld beim Blödmarkt auf dem Grabbeltisch gibt und der dir die IP Segmente trennt. Oder noch einfacher zwei separate popelige 8 Euro Switches wie diese_hier oder diese.
Bevor du das nicht fixt ist hier sämtliche Hilfestellung mehr oder weniger sinnfrei !
Was da schiefläuft kannst du ganz einfach sehen wenn du mal einen Wireshark_Sniffer in dein vermurkstes 2 IP Netzwerk hängst. Beschreiben muss man das dann hier nicht mehr...
Mitglied: 6890
6890 Sep 20, 2010 at 13:28:14 (UTC)
Goto Top
@aqui - warum denn gleich so böse?!

Wie aqui schon sagt ist das nicht sehr optimal gelöst, dein problem sollte man allerdings umgehen können. Das Problem ist, dass per default alle interfaces für alle lokal konfigurierten ip addressen auf allen netzwerkinterfacen antworten dürfen. Um das zu umgehen könntest du zb via

echo 1 > /proc/sys/net/ipv4/conf/{eth0,eth2}/arp_ignore

dieses verhalten deaktivieren. Du könntest anstatt 1 auch 2 nehmen (1 = antwortet auf arp-requests wenn ziel adresse gleich lokale adresse des interfaces, 2 = antwortet auf arp-requests wenn ziel adresse gleich lokale adresse des interfaces und sender im selben subnetz). Siehe dazu auch (setzt installierte Kernel-Quellen voraus) /usr/src/linux/Documentation/networking/ip-sysctl.txt (arp_*).

Das sollte das Problem eigentlich beheben.

MfG
GermansolvedQuestionDebianLinux
Hotly discussed
gleixnerdCheck of ZFW Firewallgleixnerd - 5 Comments