[gelöst]debian-router kann client nicht anpingen

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
wum
Beiträge: 241
Registriert: 15.10.2004 14:24:27

[gelöst]debian-router kann client nicht anpingen

Beitrag von wum » 09.02.2007 01:25:10

Setze gerade einen etch-router auf. Der router kommt ins Netz, aber er kann die clients nicht anpingen (und umgekehrt).

Ein route ergibt
Ziel Router Genmask Flags Metric Ref Use Iface
lo1.brun-04.de- * 255.255.255.255 UH 0 0 0 ppp0
192.168.2.0 * 255.255.255.0 U 0 0 0 eth1
default * 0.0.0.0 U 0 0 0 ppp0
Sollte hier nicht in der dritten Zeile unter "Router" nochmal
lo1.brun-04.de- stehen statt bloss ein *?


Die /etc/network/interfaces auf dem router enthält folgendes:

Code: Alles auswählen

auto lo eth1
iface lo inet loopback
iface eth1 inet static
address 192.168.2.1
netmask 255.255.255.0
network 192.168.2.0
eth1 ist die Netzwerkkarte zum internen Netzwerk, das interne Netwerk liegt in 192.168.2.*.
Zuletzt geändert von wum am 13.02.2007 21:22:52, insgesamt 1-mal geändert.

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 09.02.2007 10:21:24

wum hat geschrieben: Ein route ergibt
Ziel Router Genmask Flags Metric Ref Use Iface
lo1.brun-04.de- * 255.255.255.255 UH 0 0 0 ppp0
192.168.2.0 * 255.255.255.0 U 0 0 0 eth1
default * 0.0.0.0 U 0 0 0 ppp0
Sollte hier nicht in der dritten Zeile unter "Router" nochmal
lo1.brun-04.de- stehen statt bloss ein *?
Du hast zwar kein Default-Gateway eingetragen, aber das ist nicht der Grund, warum du die Clients nicht pingen kannst. Die Clients sind ja alle (vermutlich) im gleichen 192.168.2.0/255.255.255.0 Subnetz, dort werden daher die IP Adressen über das ARP-Protokoll in MAC Adressen aufgelöst, welche dann zur Kommunikation ( Ethernet, Schicht 2 ) verwendet werden.
Überprüfe einmal nach einem mißglückten Ping-Versuch, ob sich der Client im ARP-Cache befindet

Code: Alles auswählen

arp -i eth1 CLIENTIP
mit

Code: Alles auswählen

arp -i eth1 
erhälst du alle Einträge im ARP Cache für das eth1 Interface

Wenn die CLIENTIP nicht zu einer MAC Adresse aufgelöst werden konnte, hast du wahrscheinlich ein physisches oder ein Treiberproblem
Wenn die CLIENTIP aufgelöste wurde, werden die Pings wahrscheinlich irgendwo geblockt


Gruß
gms

wum
Beiträge: 241
Registriert: 15.10.2004 14:24:27

Beitrag von wum » 09.02.2007 13:42:37

Hi gms,
ein physisches Problem kann ich ausschliessen, weil ich auf dem gleichen router ein sarge zu laufen habe, das (ebenfalls als router) funktioniert. Das System wurde allerdings gehackt, deshalb setze ich jetzt auf einer anderen Partition ein etch auf. Insofern halte ich auch ein Treiberproblem für unwahrscheinlich, weil das heissen würde, dass vom kernel 2.4.27 (sarge) zum 2.6.18 (etch, daily build) der Treiber weggefallen wäre.

Werde aber heute abend nochmal neu booten und das testen.

Grüße,
wum

wum
Beiträge: 241
Registriert: 15.10.2004 14:24:27

Beitrag von wum » 09.02.2007 15:55:45

Hmm,
ein

Code: Alles auswählen

arp -i eth1 
ergibt
# arp -i eth1
Address HWtype HWaddress Flags Mask Iface
192.168.2.2 (unvollständig) eth1
client 192.168.2.2 hatte ich zuvor versucht anzupingen. Demnach könnte das tatsächlich ein Treiberproblem sein? Obwohl es eine uralte Netzwerkkarte ist, die unter dem alten Kernel läuft?

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 09.02.2007 16:09:00

Kannst du den Client überprüfen ? Unter Windows gibts das gleiche Kommando mit anderen Optionen
"arp -a " funktioniert aber unter Linux und Windows gleich.
Bridge oder ARP-Proxy gibt es ja keinen dazwischen, oder ?
Hast du vielleicht noch ein zusätzliches netzwerkfähiges Gerät (z.B. Firewire ) in dem Router ? In diesem Fall könnte es möglich sein, daß die Interfaces vertauscht wurden und du jetzt in Wirklichkeit versuchst über Firewire mit den Clients zu kommunizieren.
Ansonsten mit "tcpdump -i eth1" kannst du am Server (und eventuell auch am Client) den Verkehr mittracen, dort solltest du auch die ARP Anfragen und Antworten sehen können.

Gruß
gms

wum
Beiträge: 241
Registriert: 15.10.2004 14:24:27

Beitrag von wum » 09.02.2007 23:14:28

Mir scheint, dass da tatsächlich was vertauscht ist.
Ein

Code: Alles auswählen

tcpdump -i eth1
wirft jede Menge Zeug aus wie
22:45:03.678569 PPPoE [ses 0xfdc] IP e178208117.adsl.alicedsl.de.microsoft-ds > e178097138.adsl.alicedsl.de.4605: R 0:0(0) ack 1010530920 win 0
22:45:03.629952 PPPoE [ses 0xfdc] IP e178208117.adsl.alicedsl.de.32788 > name4.hansenet.de.domain: 29407+ PTR? 117.208.178.85.in-addr.arpa. (45)
Ich weiss nicht, was das bedeutet, aber das sieht doch schwer so als, als stamme das aus der Verbindung zum Internet.

Ein

Code: Alles auswählen

tcpdump -i eth0
dagegen liefert immer wieder
22:45:24.600940 arp who-has 192.168.2.1 tell 192.168.2.2
192.168.2.2 ist der debian-client im internen Netz, den ich vergeblich anzupingen versuche.

ifconfig liefert auf dem Router:
eth0 Protokoll:Ethernet Hardware Adresse 00:0B:6A:78:04:89
inet6 Adresse: fe80::20b:6aff:fe78:489/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:823 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:50916 (49.7 KiB) TX bytes:540 (540.0 b)
Interrupt:185 Basisadresse:0xd000

eth1 Protokoll:Ethernet Hardware Adresse 00:04:75:CE:93:6F
inet Adresse:192.168.2.1 Bcast:192.168.2.255 Maske:255.255.255.0
inet6 Adresse: fe80::204:75ff:fece:936f/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10471 errors:0 dropped:0 overruns:0 frame:0
TX packets:7762 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:13268880 (12.6 MiB) TX bytes:672799 (657.0 KiB)
Interrupt:169 Basisadresse:0xcf80

lo Protokoll: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 Metric:1
RX packets:1965 errors:0 dropped:0 overruns:0 frame:0
TX packets:1965 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:872190 (851.7 KiB) TX bytes:872190 (851.7 KiB)

ppp0 Protokoll:Punkt-zu-Punkt Verbindung
inet Adresse:85.178.208.XXX P-z-P:213.191.89.4 Maske:255.255.255.255
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:10074 errors:0 dropped:0 overruns:0 frame:0
TX packets:7325 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:3
RX bytes:13000642 (12.3 MiB) TX bytes:484909 (473.5 KiB)
Das klingt ja wiederum sehr wohl so, dass eth1 am internen Netz und eth0 am Internet hängt. Ideen?

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 09.02.2007 23:47:04

wenn die arp Requests am eth0 Interface daher kommen, spricht schon sehr viel für LAN auf eth0.
Dann müßtest du aber ppp0 über eth1 eingerichtet haben ( /etc/ppp/pppoe.conf oder /etc/ppp/ppp.conf o.ä )

wenn du eth0 mit eth1 vertauschen möchtest, geht das in Etch über die Datei /etc/udev/rules.d/z25_persistent-net.rules

Gruß
gms

wum
Beiträge: 241
Registriert: 15.10.2004 14:24:27

Beitrag von wum » 13.02.2007 21:22:34

wenn du eth0 mit eth1 vertauschen möchtest, geht das in Etch über die Datei /etc/udev/rules.d/z25_persistent-net.rules
Das habe ich getan und nun funktioniert alles. Herzlichen dank.

Antworten