Hallo,
ich habe einen Ubuntu Server aufgesetzt, um unter anderem einen Fileserver zuhause zu realisieren. Auf diesem Server habe ich "dhcp3-server" installiert. Der Server hat 2 Gigabit LAN Karten (10.10.10.1 und 10.10.10.2) sowie eine WLAN Karte (192...). Über das WLAN ist ein Internet Zugang realisiert, über LAN wird ein PC ständig verbunden und die 2. Gigabit LAN Karte soll einen schnellen Zugang für "Gäste" realisieren. Das Problem ist jetzt: Unabhängig vom PC (Vista, 7, Ubuntu) wird dem PC an eth1 (10.10.10.2) zwar eine IP zugewiesen, danach ist aber auch schon Schluss: Nicht mal auf ein ping wird reagiert.
Wenn Infos gewünscht sind einfach fragen, hier schon mal auf Verdacht ein paar Ausgaben. VG Hypernia
PS: Beim ersten Ping kommt als Ergebnis Zielnetz nicht erreichbar, danach nur noch Zeitüberschreitung. Der Server antwortet an eth0 auch auf 10.10.10.2, was ich auch schon merkwürdig finde... Wenn ich die Kabel umstöpsel, bekommt der Gast problemlosen Zugang. Wenn die Kommunikation nur bis zur IP Vergabe klappt, steht in der "Verbindungsspezifischen DNS Suffix" "mshome.net", was beim funktionierend verbundenen PC nicht der Fall ist (dort ist es leer).
ifconfig:
eth0 Link encap:Ethernet HWaddr 00:16:17:ef:0e:9e
inet addr:10.10.10.1 Bcast:10.10.10.255 Mask:255.255.255.0
inet6 addr: fe80::216:17ff:feef:e9e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:59 errors:0 dropped:0 overruns:0 frame:0
TX packets:125 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8708 (8.7 KB) TX bytes:18115 (18.1 KB)
Interrupt:21 Base address:0x6000
eth1 Link encap:Ethernet HWaddr 00:e0:4c:69:12:7f
inet addr:10.10.10.2 Bcast:10.10.10.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:18 Base address:0x2000
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:16436 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)
virbr0 Link encap:Ethernet HWaddr 5e:46:d5:f2:4a:bb
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
inet6 addr: fe80::5c46:d5ff:fef2:4abb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:744 (744.0 B)
wlan0 Link encap:Ethernet HWaddr 00:18:4d:71:35:e9
inet addr:192.168.178.49 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: fe80::218:4dff:fe71:35e9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:27 errors:0 dropped:0 overruns:0 frame:0
TX packets:29 errors:0 dropped:1 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5313 (5.3 KB) TX bytes:3686 (3.6 KB)
Interrupt:16 Memory:fdcd0000-fdce0000
dhcpd.conf
ddns-update-style none;
default-lease-time 604800;
max-lease-time 604800;
log-facility local7;
subnet 10.10.10.0 netmask 255.255.255.0 {
range 10.10.10.10 10.10.10.250;
option broadcast-address 10.10.10.255;
default-lease-time 600;
max-lease-time 7200;
}/etc/network/interfaces
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.10.10.1
netmask 255.255.255.0
auto eth1
iface eth1 inet static
address 10.10.10.2
netmask 255.255.255.0
auto wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
Du müsstest schon ein paar mehr Infos rausrücken. Z.B. von wo nach wo du pingst, inkl. Ziel und QuellIP. Dann stellt sich die Frage, hast du auf dem Server das IP Forwarding aktiviert? Gibt es Firewallregeln die den Traffic blockieren und hast du auch DNS richtig eingerichtet (dein DHCP Server gibt z.B. keinen DNS Server bekannt)? Und weiß der WLAN Router der den Internetzugang macht auch von den Netzen hinter dem Server (sprich hast du NAT/Masquerading eingerichtet oder das Routing passend gesetzt)?
nbkr schrieb:
Du müsstest schon ein paar mehr Infos rausrücken. Z.B. von wo nach wo du pingst, inkl. Ziel und QuellIP. Dann stellt sich die Frage, hast du auf dem Server das IP Forwarding aktiviert? Gibt es Firewallregeln die den Traffic blockieren und hast du auch DNS richtig eingerichtet (dein DHCP Server gibt z.B. keinen DNS Server bekannt)? Und weiß der WLAN Router der den Internetzugang macht auch von den Netzen hinter dem Server (sprich hast du NAT/Masquerading eingerichtet oder das Routing passend gesetzt)?
Ping ging z.B. heute von 10.10.10.13 nach 10.10.10.1.
Das mit dem IP Forwarding weiß ich gerade nicht genau, was gemeint ist (ich lerne noch 
)
Firewallregeln (iptables?) waren keine speziell auf eine Karte ausgerichtet.
DNS brauche ich nicht, da über das Netz nur Zugriff auf den Server gewünscht ist, der stellt keinen Router dar.
Der Router weiß nichts von dem Netz, kann aber prinzipiell über die WLAN IP zugreifen. Bislang ist es auch so geplant, dass es nur per LAN und nicht über Internet Zugriff auf den Server geben soll.
Wenn mir jemand den Forwarding Befehl geben könnte, poste ich dann direkt auch noch die IPTables Ausgabe dazu.
VG Hypernia
Hypernia schrieb:
Der Server hat 2 Gigabit LAN Karten (10.10.10.1 und 10.10.10.2) ...
Zwei Netzwerkkarten im gleichen Subnetz können Probleme bereiten, wenn man nicht weiß was man tut.
mickydoutza schrieb:
Hypernia schrieb:
Der Server hat 2 Gigabit LAN Karten (10.10.10.1 und 10.10.10.2) ...
Zwei Netzwerkkarten im gleichen Subnetz können Probleme bereiten, wenn man nicht weiß was man tut.
Ich HABE ein Problem. Vielleicht hängt es zusammen? Worauf müsste man genau achten?
Alternativ: Wie lasse ich DHCP für 2 Karten in 2 Bereichen laufen? Wäre eine momentan akzeptable Notlösung.
Hypernia schrieb:
Alternativ: Wie lasse ich DHCP für 2 Karten in 2 Bereichen laufen? Wäre eine momentan akzeptable Notlösung.
Warum müssen deine 2 Karten, ihre IP-Adressen von einem DHCP-Server bekommen?
Hypernia schrieb:
Wenn mir jemand den Forwarding ...
Wie ist die Ausgabe von:
sudo sysctl net.ipv4.ip_forward
?
mickydoutza schrieb:
Hypernia schrieb:
Alternativ: Wie lasse ich DHCP für 2 Karten in 2 Bereichen laufen? Wäre eine momentan akzeptable Notlösung.
Warum müssen deine 2 Karten, ihre IP-Adressen von einem DHCP-Server bekommen?
Müssen und sollen und tun sie nicht. Die Karten haben feste IPs und angeschlossene PCs an diesen Server sollen über DHCP eine IP bekommen. Also: Wer sich an den Server anschließt, bekommt eine IP und nutzt nur über das LAN die Dienste (z.B. Samba) auf dem Server.
mickydoutza schrieb:
Wie ist die Ausgabe von:
sudo sysctl net.ipv4.ip_forward
?
root@server:~# sudo sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
Und hier noch die IPTables --list
root@server:~# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.122.0/24 state RELATED,ESTAB LISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-po rt-unreachable
REJECT all -- anywhere anywhere reject-with icmp-po rt-unreachable
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Poste mal die Ausgabe von:
sudo iptables -L -n -v -x
mickydoutza schrieb:
Poste mal die Ausgabe von:
sudo iptables -L -n -v -x
Chain INPUT (policy ACCEPT 140 packets, 18987 bytes)
pkts bytes target prot opt in out source dest ination
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0. 0/0 udp dpt:53
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:53
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0. 0/0 udp dpt:67
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:67
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source dest ination
0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.16 8.122.0/24 state RELATED,ESTABLISHED
0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0. 0/0
0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0. 0/0
0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0. 0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0. 0/0 reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT 110 packets, 14481 bytes)
pkts bytes target prot opt in out source dest ination
Die virbr0 Schnittstelle kommt meines Wissens daher, dass ich den Server in VMWare eingerichtet und dann in den Server eingebaut habe.
Könnte noch einmal kurz die Problematik mit den 2 IPs erklären? Eventuell kenne ich da Eigenheiten von Linux nicht genau. Meine Planung war, dass in dem Subnet die 2 IPs zum Server gehören und ab .10 an die Clients vergeben wird.
VG Hypernia
Hypernia schrieb:
Chain INPUT (policy ACCEPT 140 packets, 18987 bytes)
pkts bytes target prot opt in out source dest ination
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0. 0/0 udp dpt:53
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:53
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0. 0/0 udp dpt:67
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:67
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source dest ination
0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.16 8.122.0/24 state RELATED,ESTABLISHED
0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0. 0/0
0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0. 0/0
0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0. 0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0. 0/0 reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT 110 packets, 14481 bytes)
pkts bytes target prot opt in out source dest ination
Warum brauchst Du Regeln mit dem target ACCEPT, wenn die default policy der INPUT chain ACCEPT ist und bleibt?
mickydoutza schrieb:
Warum brauchst Du Regeln mit dem target ACCEPT, wenn die default policy der INPUT chain ACCEPT ist und bleibt?
Ehrlich gesagt habe ich die iptables gar nicht angefasst. Die Regeln kommen meines Wissens nach wie gesagt von VMWare. Ist evtl. nicht ganz logisch aufgebaut in dem Fall, aber da steckt doch keine Logik hinter, dass ich deswegen über eth0 eine normal funktionierende Verbindung habe und über eth1 eben nicht? Schön machen kann ich alles, wenn es problemlos läuft
Gerade mal das hier gefunden:
Jun 6 10:42:02 server kernel: [ 1066.470140] r8169: eth1: link up
Jun 6 10:42:17 server dhcpd: DHCPDISCOVER from 10:1f:74:1a:35:06 via eth1
Jun 6 10:42:18 server dhcpd: DHCPOFFER on 10.10.10.11 to 10:1f:74:1a:35:06 (Notebook) via eth1
Jun 6 10:42:18 server dhcpd: DHCPREQUEST for 10.10.10.11 (10.10.10.2) from 10:1f:74:1a:35:06 (Notebook) via eth1
Jun 6 10:42:18 server dhcpd: DHCPACK on 10.10.10.11 to 10:1f:74:1a:35:06 (Notebook) via eth1
Jun 6 10:42:50 server dhcpd: DHCPINFORM from 10.10.10.11 via eth1: not authoritative for subnet 10.10.10.0
Jun 6 10:42:50 server dhcpd: If this DHCP server is authoritative for that subnet,
Jun 6 10:42:50 server dhcpd: please write an `authoritative;' directive either in the
Jun 6 10:42:50 server dhcpd: subnet declaration or in some scope that encloses the
Jun 6 10:42:50 server dhcpd: subnet declaration - for example, write it at the top
Jun 6 10:42:50 server dhcpd: of the dhcpd.conf file.
Jun 6 10:42:53 server dhcpd: DHCPINFORM from 10.10.10.11 via eth1: not authoritative for subnet 10.10.10.0
Nachdem ich jetzt das "#" vor dem authorative in der dhcpd.conf entfernt habe, sieht ein Auszug aus dem Log so aus:
Jun 6 10:52:47 server kernel: [ 1711.812740] r8169: eth1: link up
Jun 6 10:53:01 server dhcpd: DHCPREQUEST for 10.10.10.11 from 10:1f:74:1a:35:06 (Notebook) via eth1
Jun 6 10:53:01 server dhcpd: DHCPACK on 10.10.10.11 to 10:1f:74:1a:35:06 (Notebook) via eth1
Jun 6 10:53:44 server dhcpd: DHCPINFORM from 10.10.10.11 via eth1
Jun 6 10:53:44 server dhcpd: DHCPACK to 10.10.10.11 (10:1f:74:1a:35:06) via eth1
Jun 6 10:53:47 server dhcpd: DHCPINFORM from 10.10.10.11 via eth1
Jun 6 10:53:47 server dhcpd: DHCPACK to 10.10.10.11 (10:1f:74:1a:35:06) via eth1
Jun 6 10:56:30 server kernel: [ 1934.082698] r8169: eth1: link down
Jun 6 10:56:39 server dhcpd: DHCPREQUEST for 10.10.10.10 from 00:22:f7:31:8d:f8 (PC) via eth0
Jun 6 10:56:39 server dhcpd: DHCPACK on 10.10.10.10 to 00:22:f7:31:8d:f8 (PC) via eth0
Dazwischen erneuert mein PC sein lease. Was mich wundert ist, dass es das Inform/Ack doppelt gibt. Einen Ping etc. zum Server bekomme ich so immer noch nicht hin :-/
VG Hypernia
Und noch eine Information: Wenn ich nicht die NICs vertausche sondern die Reihenfolge (sonst war mein PC schon immer an, danach erst der Laptop), dann kriegt auf einmal der Laptop die Verbindung und der PC nicht. Es ist also so, dass nur das erste Gerät eine vernünftige Verbindung hat, das zweite bekommt jedoch nur noch eine IP.
Damit kann man denke ich jetzt Geschichten wie Firewall Regeln definitiv ausschließen. Könnte es sein, dass es durch die 2 LAN Karten dazu kommt, dass ein festes Routing zu 10.10.10.0/24 über eth0 festgelegt wird und der Server nicht mehr auf die Idee kommt, auch IPs über eth1 zu bedienen? Oder sind sonst irgendwelche Locks denkbar? Nochmal die Frage: Wie könnte ich alternativ 2 Subnets per DHCP erstellen?
VG Hypernia
PS: Wenn jemand sehr fit mit den ganzen Paket(rahmen) ist, auf meinem nicht verbundenen Gerät werden immer exakt 342 Pakete emfangen.
Hier mal ein Aufruf der Routing Tabelle, so sollte es mMn mit dem Subnet aussehen?
root@server:~# sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
0.0.0.0 192.168.178.1 0.0.0.0 UG 100 0 0 wlan0
