25
Routingproblem in Homerouter-Kaskade mit Raspi
Hallo liebe Netzwerkspezialisten,
Ich habe in unserem Netzwerk einen Standardfall der gefühlt mehrere Tausend Mal in diesem Forum geschildert worden ist. Und obwohl ich diese Beiträge und auch die HowTos mehrmals rauf und runter gelesen habe, finde ich den Fehler bei uns im Netzwerk einfach nicht.
Hier kurz eine vereinfachte Darstellung meiner Problemstelle im Netzwerk:
Es sind also zwei private Netze (ich nenne sie einfach mal anhand der IP-Adressierung 44er und 55er Netz). Das 44er Netz hat eine Verbindung zum Internet. Ein Raspi 3B verbindet die beiden privaten Class C Netze.
Das 55er Netz soll nun auch Zugriff zum Internet bekommen und auch auf die Ressourcen im 44er Netz zugreifen können (Drucker, Intranet). Auf dem Webserver mit dem Intranet läuft noch ein dnsmasq, der Anfragen an die http-Adresse des Intranets zur lokalen IP 192.168.44.253 umleitet. Alle anderen Anfragen gehen an 8.8.8.8.
Weiterhin habe ich auf dem Raspi noch folgendes konfiguriert, um die Netzwerke miteinander zu verbinden:
• IP-Forwarding aktiviert (net.ipv4.ip_forward=1)
• Statische Route auf dem Raspi (Zielnetz: 192.168.44.0, Gateway 192.168.55.1)
Nun habe ich folgende Situation:
Es funktioniert:
• Ein Ping vom 55er Netz auf die IP 192.168.44.254 (eth0 vom Raspi)
• Ein Ping vom 55er Netz auf die IP 192.168.44.1 (Internet Gateway)
• Ein Ping vom 55er Netz auf die IP 8.8.8.8
Es funktioniert nicht:
• Ein Ping vom 55er Netz auf 192.168.44.252 (Drucker) = “Zeitüberschreitung der Anforderung“
• Ein Ping vom 55er Netz auf 192.168.44.253 (Intranet Webserver) = “Zeitüberschreitung der Anforderung“
• Ein Ping auf http-Adressen des Internets
Ich habe auch schon getestet, NAT auf dem Raspi zu aktivieren (iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE)
Es machte für mich zwar keinen Sinn, weil NAT für mein Verständnis schon vom Internet-Gateway im 44er Netz erledigt wird, aber in der Verzweiflung klammert man sich ja an jeden Strohhalm. Es brachte dann auch wie erwartet keine Abhilfe.
Sobald ich im 55er Netz den DNS ändere von 192.168.44.253 auf 8.8.8.8, dann geht zumindest der Zugriff auf http-Adressen (logisch). Dann fehlt mir aber der Zugriff auf die Geräte im 44er Netz.
Kann mir hier bitte jemand helfen, meinen Fehler zu finden? Ich bin ratlos…
Schöne Grüsse,
Oldschool
Ich habe in unserem Netzwerk einen Standardfall der gefühlt mehrere Tausend Mal in diesem Forum geschildert worden ist. Und obwohl ich diese Beiträge und auch die HowTos mehrmals rauf und runter gelesen habe, finde ich den Fehler bei uns im Netzwerk einfach nicht.
Hier kurz eine vereinfachte Darstellung meiner Problemstelle im Netzwerk:
Es sind also zwei private Netze (ich nenne sie einfach mal anhand der IP-Adressierung 44er und 55er Netz). Das 44er Netz hat eine Verbindung zum Internet. Ein Raspi 3B verbindet die beiden privaten Class C Netze.
Das 55er Netz soll nun auch Zugriff zum Internet bekommen und auch auf die Ressourcen im 44er Netz zugreifen können (Drucker, Intranet). Auf dem Webserver mit dem Intranet läuft noch ein dnsmasq, der Anfragen an die http-Adresse des Intranets zur lokalen IP 192.168.44.253 umleitet. Alle anderen Anfragen gehen an 8.8.8.8.
Weiterhin habe ich auf dem Raspi noch folgendes konfiguriert, um die Netzwerke miteinander zu verbinden:
• IP-Forwarding aktiviert (net.ipv4.ip_forward=1)
• Statische Route auf dem Raspi (Zielnetz: 192.168.44.0, Gateway 192.168.55.1)
Nun habe ich folgende Situation:
Es funktioniert:
• Ein Ping vom 55er Netz auf die IP 192.168.44.254 (eth0 vom Raspi)
• Ein Ping vom 55er Netz auf die IP 192.168.44.1 (Internet Gateway)
• Ein Ping vom 55er Netz auf die IP 8.8.8.8
Es funktioniert nicht:
• Ein Ping vom 55er Netz auf 192.168.44.252 (Drucker) = “Zeitüberschreitung der Anforderung“
• Ein Ping vom 55er Netz auf 192.168.44.253 (Intranet Webserver) = “Zeitüberschreitung der Anforderung“
• Ein Ping auf http-Adressen des Internets
Ich habe auch schon getestet, NAT auf dem Raspi zu aktivieren (iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE)
Es machte für mich zwar keinen Sinn, weil NAT für mein Verständnis schon vom Internet-Gateway im 44er Netz erledigt wird, aber in der Verzweiflung klammert man sich ja an jeden Strohhalm. Es brachte dann auch wie erwartet keine Abhilfe.
Sobald ich im 55er Netz den DNS ändere von 192.168.44.253 auf 8.8.8.8, dann geht zumindest der Zugriff auf http-Adressen (logisch). Dann fehlt mir aber der Zugriff auf die Geräte im 44er Netz.
Kann mir hier bitte jemand helfen, meinen Fehler zu finden? Ich bin ratlos…
Schöne Grüsse,
Oldschool
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 333170
Url: https://administrator.de/contentid/333170
Ausgedruckt am: 04.11.2024 um 18:11 Uhr
25 Kommentare
Neuester Kommentar
Moin,
Das ist Blödsinn. Der Raspi braucht hängt doch direkt an beiden netzen dran. Diese Route schickt verhindert, daß er die Pakete auf das richtige Interface schickt.
Und was sagen die traceroutes?
hast Du mal auf dem raspi mal mit tcpdump oder wireshark geschaut, wie die Pakete laufen?
Ich habe auch schon getestet, NAT auf dem Raspi zu aktivieren (iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE)
Es machte für mich zwar keinen Sinn, weil NAT für mein Verständnis schon vom Internet-Gateway im 44er Netz erledigt wird, aber in der Verzweiflung klammert man sich ja an jeden Strohhalm. Es brachte dann auch wie erwartet keine Abhilfe.
Wenn Du aus dem 44er netz ins 55 zugreifen willst, ist NAT kontraproduktiv.
Da ist dann häöchstens die namensauflösung weg. Aber per IP solltest Du schon drauf kommen.
Als erstes solltest Du mal die Routingtabelle und die interface-konfiguration auf dem RasPi posten:
Und die oben erwähnte statische Route solltest Du löschen.
Vorallem mal mit tcpdump/wireshark schauen, wie die Pakete auf dem rasPi laufen.
lks
PS: Was ist das Ziel der obigen Aktion? Könnte man nciht einfach alle Geräte in das gkleiche Netz hängen oder soll der Raspberry was besonderes machen außer dem Routen?
Das ist Blödsinn. Der Raspi braucht hängt doch direkt an beiden netzen dran. Diese Route schickt verhindert, daß er die Pakete auf das richtige Interface schickt.
Es funktioniert:
• Ein Ping vom 55er Netz auf die IP 192.168.44.254 (eth0 vom Raspi)
• Ein Ping vom 55er Netz auf die IP 192.168.44.1 (Internet Gateway)
• Ein Ping vom 55er Netz auf die IP 8.8.8.8
Es funktioniert nicht:
• Ein Ping vom 55er Netz auf 192.168.44.252 (Drucker) = “Zeitüberschreitung der Anforderung“
• Ein Ping vom 55er Netz auf 192.168.44.253 (Intranet Webserver) = “Zeitüberschreitung der Anforderung“
• Ein Ping auf http-Adressen des Internets
• Ein Ping vom 55er Netz auf die IP 192.168.44.254 (eth0 vom Raspi)
• Ein Ping vom 55er Netz auf die IP 192.168.44.1 (Internet Gateway)
• Ein Ping vom 55er Netz auf die IP 8.8.8.8
Es funktioniert nicht:
• Ein Ping vom 55er Netz auf 192.168.44.252 (Drucker) = “Zeitüberschreitung der Anforderung“
• Ein Ping vom 55er Netz auf 192.168.44.253 (Intranet Webserver) = “Zeitüberschreitung der Anforderung“
• Ein Ping auf http-Adressen des Internets
Und was sagen die traceroutes?
hast Du mal auf dem raspi mal mit tcpdump oder wireshark geschaut, wie die Pakete laufen?
Ich habe auch schon getestet, NAT auf dem Raspi zu aktivieren (iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE)
Es machte für mich zwar keinen Sinn, weil NAT für mein Verständnis schon vom Internet-Gateway im 44er Netz erledigt wird, aber in der Verzweiflung klammert man sich ja an jeden Strohhalm. Es brachte dann auch wie erwartet keine Abhilfe.
Wenn Du aus dem 44er netz ins 55 zugreifen willst, ist NAT kontraproduktiv.
Sobald ich im 55er Netz den DNS ändere von 192.168.44.253 auf 8.8.8.8, dann geht zumindest der Zugriff auf http-Adressen (logisch). Dann fehlt mir aber der Zugriff auf die Geräte im 44er Netz.
Da ist dann häöchstens die namensauflösung weg. Aber per IP solltest Du schon drauf kommen.
Kann mir hier bitte jemand helfen, meinen Fehler zu finden? Ich bin ratlos…
Als erstes solltest Du mal die Routingtabelle und die interface-konfiguration auf dem RasPi posten:
- netstat -rn
- ifconfig -a
- cat /etc/resolv.conf
Und die oben erwähnte statische Route solltest Du löschen.
Vorallem mal mit tcpdump/wireshark schauen, wie die Pakete auf dem rasPi laufen.
lks
PS: Was ist das Ziel der obigen Aktion? Könnte man nciht einfach alle Geräte in das gkleiche Netz hängen oder soll der Raspberry was besonderes machen außer dem Routen?
einen Standardfall der gefühlt mehrere Tausend Mal in diesem Forum geschildert worden ist.
Weise und wahre Worte.... 
Du hast die Tutorials dennoch nicht genau gelesen, denn es sind wieder einige schlimme Anfänger Fehler enthalten die zu diesem Fehlverhalten bzw. der Nichtfunktion führen:
Statische Route auf dem RasPi (Zielnetz: 192.168.44.0, Gateway 192.168.55.1)
Diese Route ist wie immer Schwachsinn. Sorry für die harten Worte aber der RasPi "kennt" doch sowohl das .44er als auch das .55er Netz da sie beide DIREKT an ihm angeschlossen sind !Wozu also noch diese Netzwerke dem RasPi mit einer Route bekannt machen? Das ist Blödsinn und wird immer und immer wieder in den Routing Tutorials hier gepredigt:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Lösche also diese vollkommen unsinnige Route wieder !
Das Einzige was der RasPi benötigt ist eine Default Route bzw. Default Gateway auf die 192.168.44.1 (Internet Router). Mehr nicht!
Grundlegende Infos zum PasPi Networking auch hier:
Netzwerk Management Server mit Raspberry Pi
Der Internet Router braucht aber natürlich zwingend eine statische Route ! Genau DIE hast du leider vergessen !
Klar, denn der Internet Router "kennt" das .55er Netz hinter dem RasPi nicht, woher auch? Das musst du ihm also mit einer statischen Route beibringen. Also kommt hier dann rein:
Zielnetz: 192.168.55.0, Maske: 255.255.255.0, Gateway: 192.168.44.254
Fertisch !
Das wars schon !
Fazit:
2 Kardinalsfehler !
- Routing auf dem RasPi vollkommen falsch eingestellt !
- Statische Route auf dem Internet Router vergessen !
Du hast wie hier leider so oft das o.a. Routing_Tutorial de facto NICHT gelesen. Erwischt !!!
Änder diese beiden Punkte, dann kommt das auch alles sofort problemlos zum Fliegen. Ansonsten ist dein Design absolut richtig. Und....
das nächste Mal wirklich die Tutorials lesen !
Hallo Lochkartenstanzer!
Auf dem Raspberry Pi 3B soll zukünftig noch squid & squidguard laufen. Ich habe zwar noch zwei TP-Link-Router in der Schublade, die ich mit DD-WRT oder OpenWRT bespielen könnte, habe mich aber aus Performancegründen für die Anschaffung eines Raspberry Pi 3B entschieden. Zudem bin ich zukünftig flexibler und kann auf dem raspi noch weitere Dienste installieren. Beispielsweise könnte der Webserver für das Intranet auch noch auf dem raspi laufen und ich hätte damit ein Gerät gespart.
Zur Problemanalyse:
Die statische Route auf dem Raspi habe ich nun gelöscht
Auf dem Windows-Client im 55er Netz ergibt tracert nun:
Der Raspi ist folgendermassen konfiguriert:
Also der raspi selbst hat Zugriff auf meinen internen DNS. Logisch, denn er ist ja mit eth0 im selben Netz. Aber die Clients im 55er Netz sehen den internen DNS einfach nicht. Sie können IP-Adressen im Internet anpingen, aber die Namensauflösung erfolgt eben nicht. Der raspi scheint nicht zu routen. Ich verstehe nicht, woran es liegt.
Grüsse,
Oldschool
Auf dem Raspberry Pi 3B soll zukünftig noch squid & squidguard laufen. Ich habe zwar noch zwei TP-Link-Router in der Schublade, die ich mit DD-WRT oder OpenWRT bespielen könnte, habe mich aber aus Performancegründen für die Anschaffung eines Raspberry Pi 3B entschieden. Zudem bin ich zukünftig flexibler und kann auf dem raspi noch weitere Dienste installieren. Beispielsweise könnte der Webserver für das Intranet auch noch auf dem raspi laufen und ich hätte damit ein Gerät gespart.
Zur Problemanalyse:
Die statische Route auf dem Raspi habe ich nun gelöscht
Auf dem Windows-Client im 55er Netz ergibt tracert nun:
tracert 192.168.44.253
Routenverfolgung zu 192.168.44.253 über maximal 30 Hops
1 5 ms 6 ms 5 ms 192.168.55.1
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.
6 * * * Zeitüberschreitung der Anforderung.
7 ^Ctracert www.google.de
Der Zielname www.google.de konnte nicht aufgelöst werden.Der Raspi ist folgendermassen konfiguriert:
nestat -rn:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.44.1 0.0.0.0 UG 0 0 0 eth0
192.168.44.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.55.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1ifconfig -a
eth0 Link encap:Ethernet HWaddr b8:27:eb:59:5e:18
inet addr:192.168.44.254 Bcast:192.168.44.255 Mask:255.255.255.0
inet6 addr: fe80::9b74:69fd:a99:8544/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:469902 errors:0 dropped:44 overruns:0 frame:0
TX packets:191049 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:72413274 (69.0 MiB) TX bytes:17261802 (16.4 MiB)
eth1 Link encap:Ethernet HWaddr 18:d6:c7:14:f6:f8
inet addr:192.168.55.1 Bcast:192.168.55.255 Mask:255.255.255.0
inet6 addr: fe80::561b:8ad6:5ce9:a8e5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:629233 errors:0 dropped:47 overruns:0 frame:0
TX packets:219485 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:231915317 (221.1 MiB) TX bytes:30220412 (28.8 MiB)
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:1038 errors:0 dropped:0 overruns:0 frame:0
TX packets:1038 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:96228 (93.9 KiB) TX bytes:96228 (93.9 KiB)
wlan0 Link encap:Ethernet HWaddr b8:27:eb:0c:0b:4d
inet6 addr: fe80::3b91:c83:fe3d:e979/64 Scope:Link
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)cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.168.44.253traceroute www.google.de
traceroute to www.google.de (172.217.19.99), 30 hops max, 60 byte packets
1 192.168.44.1 (192.168.44.1) 13.123 ms 12.991 ms 12.983 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 217.5.104.17 (217.5.104.17) 87.201 ms 87.197 ms 217.5.104.13 (217.5.104.13) 90.254 ms
13 217.239.52.10 (217.239.52.10) 94.634 ms 217.239.52.62 (217.239.52.62) 94.661 ms 217.239.52.10 (217.239.52.10) 94.576 ms
14 72.14.194.156 (72.14.194.156) 105.255 ms 105.233 ms 72.14.195.222 (72.14.195.222) 114.498 ms
15 108.170.241.131 (108.170.241.131) 104.999 ms 108.170.241.163 (108.170.241.163) 104.793 ms^Crouter@raspberrypi:~ $ cat /proc/sys/net/ipv4/ip_forward
1
router@raspberrypi:~ $Also der raspi selbst hat Zugriff auf meinen internen DNS. Logisch, denn er ist ja mit eth0 im selben Netz. Aber die Clients im 55er Netz sehen den internen DNS einfach nicht. Sie können IP-Adressen im Internet anpingen, aber die Namensauflösung erfolgt eben nicht. Der raspi scheint nicht zu routen. Ich verstehe nicht, woran es liegt.
Grüsse,
Oldschool
Hallo aqui,
das Tutorial bezüglich routing mit 2 Netzwerkkarten habe ich schon gelesen. Das hat mich auch dazu gebracht, die statische Route auf dem Internet-Gateway anzulegen, wie von Dir empfohlen. Es ist auf meiner obigen Zeichnung dokumentiert; vielleicht hast du es übersehen.
Nur das mit der statischen Route auf dem Raspi ist tatsächlich ein dummer Fehler von mir. Vielleicht habe ich trotzdem nicht alles im Tutorial verstanden *rotwerd*
Das Tutorial zum grundlegenden Raspi-Networking ziehe ich mir jetzt noch rein und hoffe auf neue Erkenntnisse. Man kann ja nur dazulernen...
Die unsinnige Route auf dem raspi ist ja nun gelöscht...
Grüsse,
Oldschool
das Tutorial bezüglich routing mit 2 Netzwerkkarten habe ich schon gelesen. Das hat mich auch dazu gebracht, die statische Route auf dem Internet-Gateway anzulegen, wie von Dir empfohlen. Es ist auf meiner obigen Zeichnung dokumentiert; vielleicht hast du es übersehen.
Nur das mit der statischen Route auf dem Raspi ist tatsächlich ein dummer Fehler von mir. Vielleicht habe ich trotzdem nicht alles im Tutorial verstanden *rotwerd*
Das Tutorial zum grundlegenden Raspi-Networking ziehe ich mir jetzt noch rein und hoffe auf neue Erkenntnisse. Man kann ja nur dazulernen...
Die unsinnige Route auf dem raspi ist ja nun gelöscht...
Grüsse,
Oldschool
o.k. Das erklärt den Aufbau, auch wenn das natürlich auch mit einem Pi im gleichen Netz ohne die kaskade funktionieren würde.
Die statische Route auf dem Raspi habe ich nun gelöscht
brav.
Auf dem Windows-Client im 55er Netz ergibt tracert nun:
tracert 192.168.44.253
>
> Routenverfolgung zu 192.168.44.253 über maximal 30 Hops
>
> 1 5 ms 6 ms 5 ms 192.168.55.1
> 2 * * * Zeitüberschreitung der Anforderung.
> 3 * * * Zeitüberschreitung der Anforderung.
> 4 * * * Zeitüberschreitung der Anforderung.
> 5 * * * Zeitüberschreitung der Anforderung.
> 6 * * * Zeitüberschreitung der Anforderung.
> 7 ^CKann der Pi denn 192.168.44.253 anpingen? Hat 192.168.44.253 denn eine default route zum Internet gateway oder eine statische zum Pi?
Sieht mir ganz nach einem routing-Problem aus. Mach mal einen tcpdump auf dem Pi während due pingst.
tracert www.google.de
>
> Der Zielname www.google.de konnte nicht aufgelöst werden.Wenn das routing ncht funktioniert, funktioniert natürlich auch dns nicht, weil die Antwortpakete nciht zurückkommen.
Der Raspi ist folgendermassen konfiguriert:
nestat -rn:
>
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window irtt Iface
> 0.0.0.0 192.168.44.1 0.0.0.0 UG 0 0 0 eth0
> 192.168.44.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 192.168.55.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
> sieht gut aus.
ifconfig -a
> > ...
> sieht auch gut aus.
cat /etc/resolv.conf
>
> # Generated by resolvconf
> nameserver 192.168.44.253
> auch o.k.
Also der raspi selbst hat Zugriff auf meinen internen DNS. Logisch, denn er ist ja mit eth0 im selben Netz. Aber die Clients im 55er Netz sehen den internen DNS einfach nicht. Sie können IP-Adressen im Internet anpingen, aber die Namensauflösung erfolgt eben nicht. Der raspi scheint nicht zu routen. Ich verstehe nicht, woran es liegt.
Due solltest als erstes mal mit tcpdump prüfen, ob der rasPi wirklich der schuldige ist. Ich vermute imemr nochn eine falsche Route beim gateway oder deinem internen DNS.
lks
Auf dem Windows-Client im 55er Netz ergibt tracert nun:
Ist das ein Winblows Server den du da antraceroutest ??Bedenke das der eine lokale Firewall hat die gnadenlos alles was Absender IPs hat aus fremden Netzen blockt !
Außerdem ist bei allen Windows Versionen ab Win7 und höher ICMP geblockt ! Ping und Traceroute nutzen ICMP !
Hast du das beachtet ??
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
https://technet.microsoft.com/de-de/library/cc771915(v=ws.11).aspx
Das gilt natürlich auch für den 55er Client wenn man den aus dem 44er Netz erreichen will und das Winblows ist.
Sinnvollerweise traceroutet man zum Test immer ein Endgerät was kein Windows oder eine Firewall hat wie z.B den Drucker mit der 44..252 oder RasPi mit 44.254 oder den Router mit 44.1 um so der Falle lokale Firewall zu entgehen !!
tracert www.google.de
Ist natürlich Blödsinn wenn schon das Tracerouten im anderen lokalen Netzwerk fehlschlägt 
Außerdem um erstmal DNS Problemen aus dem Wege zu gehen solltest du die nackte IP bei Google tracerouten mit traceroute 8.8.8.8 (tracert bei Winblows)
RasPi Konfig sieht gut aus ! Ein ip route show wär nochmal interessant. Und wichtig...
was ergibt ein ping 192.168.44.1 -c 5 -I 192.168.55.1 ??
Das pingt den Router vom RasPi mit dessen Absender IP aus dem 55er Netz und zeigt dann ob die statische Route am Internet Router greift.
Kannst du vom Client aus dem dem .55er Netz die beiden RasPi interfaces anpingen ?? Auch das muss fehlerlos klappen und zeigt sofort ob auf dem RasPi wirklich das IPv4 Forwarding aktiviert wurde !
Aber die Clients im 55er Netz sehen den internen DNS einfach nicht.
Hast du denen das denn statisch konfiguriert ?? Der Client müsste wenn statisch die folgenden IPs haben: IP Adresse: 192.168.55.111
Maske: 255.255.255.0
Gateway: 192.168.55.1
DNS: 192.168.44.253
Also so wie im Bild ist das richtig. Der DNS Server, wenn Winblows, muss natürlich in seiner lokalen Firewall eingehende DNS Requests aus dem 192.168.55er Netz zulassen. Das musst du, sofern Winblows, in der lokalen Firewall customizen !
WAS ist mit der erforderlichen statischen Route ins 55er Netz auf dem Internet Router ???
Dazu wieder keinerlei Auskunft von dir ??
Es ist auf meiner obigen Zeichnung dokumentiert; vielleicht hast du es übersehen.
OK dann glauben wir dir das mal Kannst du vom 55er Client dann die Router LAN IP .44.1 oder die RasPi IP .44.254 anpingen ???
Sieht so aus als ob routingtechnsich alles dann OK ist bei dir und du lediglich ein Firewall Problem hast.
Nimm zum Ping Test immer Geräte die keine lokale Firewall haben also Drucker IP oder Router LAN IP oder die beiden RasPi Interfaces !
Zitat von @aqui:
Das gilt natürlich auch für den 55er Client wenn man den aus dem 44er Netz erreichen will und das Winblows ist.
Sinnvollerweise traceroutet man zum Test immer ein Endgerät was kein Windows oder eine Firewall hat wie z.B den Drucker mit der 44..252 oder RasPi mit 44.254 oder den Router mit 44.1 um so der Falle lokale Firewall zu entgehen !!
...
Sieht so aus als ob routingtechnsich alles dann OK ist bei dir und du lediglich ein Firewall Problem hast.
Nimm zum Ping Test immer Geräte die keine lokale Firewall haben also Drucker IP oder Router LAN IP oder die beiden RasPi Interfaces !
Das gilt natürlich auch für den 55er Client wenn man den aus dem 44er Netz erreichen will und das Winblows ist.
Sinnvollerweise traceroutet man zum Test immer ein Endgerät was kein Windows oder eine Firewall hat wie z.B den Drucker mit der 44..252 oder RasPi mit 44.254 oder den Router mit 44.1 um so der Falle lokale Firewall zu entgehen !!
...
Sieht so aus als ob routingtechnsich alles dann OK ist bei dir und du lediglich ein Firewall Problem hast.
Nimm zum Ping Test immer Geräte die keine lokale Firewall haben also Drucker IP oder Router LAN IP oder die beiden RasPi Interfaces !
Naja,. wenn er endlich mal auf dem 44-er Interface mitsniffen würde, wie ich ihn schon ein paar Male aufgefordert habe, würde man sofort sehen, ob der pi oder die Windows-Kisten das Problem sind.
lks
Da hast du Recht. Der Output von...
tcpdump -i eth0 icmp
wäre mal recht interessant wenn der Client im .55er Netz Pingtests ins .44er Netz macht.
(Vorher natürlich sudo apt-get install tcpdump nicht zu vergessen )
Man fragt sich aber wirklich was der TO da macht. Ein Testaufbau hier mit einem ollen RasPi 2 und aktuellstem Jessie kam in 10 Minuten mit dem Design zum Fliegen.
Was da wohl wieder verschlimmbessert wurde..?? Ich vermute aber eher Firewall statt Routing Infrastruktur.
Wir nehmen noch Wetten an...
tcpdump -i eth0 icmp
wäre mal recht interessant wenn der Client im .55er Netz Pingtests ins .44er Netz macht.
(Vorher natürlich sudo apt-get install tcpdump nicht zu vergessen
)Man fragt sich aber wirklich was der TO da macht. Ein Testaufbau hier mit einem ollen RasPi 2 und aktuellstem Jessie kam in 10 Minuten mit dem Design zum Fliegen.
Was da wohl wieder verschlimmbessert wurde..?? Ich vermute aber eher Firewall statt Routing Infrastruktur.
Wir nehmen noch Wetten an...
Wir nehmen noch Wetten an...
Na dann, der DNS Server ist falsch konfiguriert.Gruß
Dobby
Zitat von @108012:
Wir nehmen noch Wetten an...
Na dann, der DNS Server ist falsch konfiguriert.Nachdem pings auf 8.8.8.8 funktionieren, nehme ich mal an, daß das Routing im Groben o.k ist.
Wenn der 192.168.55.253 nicht angepingt werden kann, so kann das nur daran liegen, daß entweder die Firewall das schon blockt oder die Kiste weder default route noch statische routen hat.
Da aber das ding DNS für das 55er-netz macht, gehe ich mal davon aus, daß die default-route korretk ist, sonst könnten 55er geräte nicht Internet-namen auflösen. Bleibt also nur die Firewall
Und das DNS im 44er-netz ist nur ein Folgefehler der Nichterreichbarkeit von 192.168.55.253
Ich tippe also, wie aqui auch, inwischen auf einen firewall-Fehler.
lks
Das sollte er ja schnellstens verifizieren können wenn er nackte IPs pingt wie 8.8.8.8 (Google) oder 82.149.225.21 (www.administrator.de) oder 193.99.144.8 (www.heise.de) usw. Tcpdump idealerweise an...
Aber Wette ist vermerkt...
Die Spannung steigt....
Aber Wette ist vermerkt...
Nachdem pings auf 8.8.8.8 funktionieren
WO steht das ? Hat der TO ja noch nicht gesagt das das klappt, oder ? Wäre aber ein Durchbruch der den Verdacht dann auf Fehlkonfiguration des .253er DNS Servers erhärtet.Die Spannung steigt....
Der TO sagte direkt in der frage.
Nun habe ich folgende Situation:
Es funktioniert:
• Ein Ping vom 55er Netz auf die IP 192.168.44.254 (eth0 vom Raspi)
• Ein Ping vom 55er Netz auf die IP 192.168.44.1 (Internet Gateway)
• Ein Ping vom 55er Netz auf die IP 8.8.8.8
Es funktioniert nicht:
• Ein Ping vom 55er Netz auf 192.168.44.252 (Drucker) = “Zeitüberschreitung der Anforderung“
• Ein Ping vom 55er Netz auf 192.168.44.253 (Intranet Webserver) = “Zeitüberschreitung der Anforderung“
• Ein Ping auf http-Adressen des Internets
Es funktioniert:
• Ein Ping vom 55er Netz auf die IP 192.168.44.254 (eth0 vom Raspi)
• Ein Ping vom 55er Netz auf die IP 192.168.44.1 (Internet Gateway)
• Ein Ping vom 55er Netz auf die IP 8.8.8.8
Es funktioniert nicht:
• Ein Ping vom 55er Netz auf 192.168.44.252 (Drucker) = “Zeitüberschreitung der Anforderung“
• Ein Ping vom 55er Netz auf 192.168.44.253 (Intranet Webserver) = “Zeitüberschreitung der Anforderung“
• Ein Ping auf http-Adressen des Internets
Hervorhebung von mir.
lks
Sorry, überlesen im Eifer des Gefechts....
Das sieht dann aber gut aus und man kann davon ausgehen das das IP Routing dann grundsätzlich funktioniert und die Restfehler Winblows Firewall und DNS Server sind.
Mögliche Fehler des Rests:
Ganz sicher pingen lassen sich aber z.B. www.heise.de, www.spiegel.de und natürlich www.administrator.de.
Wenn die generell nicht pingbar sind, dann hat der DNS wie immer keine DNS Weiterleitung auf den Proxy DNS des Internet Routers .44.1 eingetragen.
Es bleibt also weiter spannend....
Das sieht dann aber gut aus und man kann davon ausgehen das das IP Routing dann grundsätzlich funktioniert und die Restfehler Winblows Firewall und DNS Server sind.
Mögliche Fehler des Rests:
• Ein Ping vom 55er Netz auf 192.168.44.252 (Drucker) = “Zeitüberschreitung der Anforderung“
Hier fehlt wie immer garantiert das Default Gateway 192.168.44.1 im Drucker !• Ein Ping vom 55er Netz auf 192.168.44.253 (Intranet Webserver) = “Zeitüberschreitung der Anforderung“
Vermutlich auch fehlender Default Gateway .44.1 Eintrag des Servers. Oder...wenn das Winblows ist wieder die lokale Firewall HTTP Zugriff geblockt aus Fremdnetzen und ICMP Block.• Ein Ping auf http-Adressen des Internets
Da muss man auch vorsichtig sein. Sehr viele Adressen haben ICMP geblockt um Ping Attacken zu unterdrücken.Ganz sicher pingen lassen sich aber z.B. www.heise.de, www.spiegel.de und natürlich www.administrator.de.
Wenn die generell nicht pingbar sind, dann hat der DNS wie immer keine DNS Weiterleitung auf den Proxy DNS des Internet Routers .44.1 eingetragen.
Es bleibt also weiter spannend....
Im WebGUI des Internet-Gateways sehe ich folgendes:
Der raspi kann quasi alles; außer Kaffee kochen. Will heißen, er pingt und tracert fleissig alle Geräte im 44er und 55er Netz sowie im Internet.
Ich habe auch schon versucht, andere Geräte im 44er Netz anzupingen (vom 55er Netz aus); aber ohne Erfolg.
Mein Test-Client im 55er Netz hat Windows 10, dies nur als Randinformation.
Der DNS-Server ist eine Linux-VM auf einem Windows 10 PC und tut zumindest im 44er Netz das was er soll. Die Geräte im 44er Netz haben nur diesen DNS eingetragen (über DHCP vom Internetgateway).
Im 55er Netz befindet sich noch ein WLAN-Access-Point mit DHCP-Server. Von dort beziehen alle Clients im 55er Netz auch Ihre DNS Einstellungen (192.168.44.253 als DNS) und Gateway Einstellungen (192.168.55.1).
Nun nochmal die Pings in ausführlicher Form auf dem 55er Client (192.168.55.11):
Der heiss ersehnte tcpdump dazu:
Ok. Jetzt wäre es vermutlich an der Zeit, sich die Konfiguration des DNS mal genauer anzuschauen, richtig?
Static Routing
ID Destination Network Subnet Mask Default Gateway Status
1 192.168.55.0 255.255.255.0 192.168.44.254 EnabledDer raspi kann quasi alles; außer Kaffee kochen. Will heißen, er pingt und tracert fleissig alle Geräte im 44er und 55er Netz sowie im Internet.
Ich habe auch schon versucht, andere Geräte im 44er Netz anzupingen (vom 55er Netz aus); aber ohne Erfolg.
Mein Test-Client im 55er Netz hat Windows 10, dies nur als Randinformation.
Der DNS-Server ist eine Linux-VM auf einem Windows 10 PC und tut zumindest im 44er Netz das was er soll. Die Geräte im 44er Netz haben nur diesen DNS eingetragen (über DHCP vom Internetgateway).
Im 55er Netz befindet sich noch ein WLAN-Access-Point mit DHCP-Server. Von dort beziehen alle Clients im 55er Netz auch Ihre DNS Einstellungen (192.168.44.253 als DNS) und Gateway Einstellungen (192.168.55.1).
Nun nochmal die Pings in ausführlicher Form auf dem 55er Client (192.168.55.11):
C:\Users\>ping 192.168.44.1
Ping wird ausgeführt für 192.168.44.1 mit 32 Bytes Daten:
Antwort von 192.168.44.1: Bytes=32 Zeit=11ms TTL=63
Antwort von 192.168.44.1: Bytes=32 Zeit=11ms TTL=63
Antwort von 192.168.44.1: Bytes=32 Zeit=12ms TTL=63
Antwort von 192.168.44.1: Bytes=32 Zeit=45ms TTL=63
Ping-Statistik für 192.168.44.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 11ms, Maximum = 45ms, Mittelwert = 19ms
C:\Users\>ping 192.168.44.253
Ping wird ausgeführt für 192.168.44.253 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Ping-Statistik für 192.168.44.253:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust),Der heiss ersehnte tcpdump dazu:
18:00:03.781110 IP 192.168.55.11 > 192.168.44.1: ICMP echo request, id 1, seq 141, length 40
18:00:03.787337 IP 192.168.44.1 > 192.168.55.11: ICMP echo reply, id 1, seq 141, length 40
18:00:04.805162 IP 192.168.55.11 > 192.168.44.1: ICMP echo request, id 1, seq 142, length 40
18:00:04.810299 IP 192.168.44.1 > 192.168.55.11: ICMP echo reply, id 1, seq 142, length 40
18:00:05.834226 IP 192.168.55.11 > 192.168.44.1: ICMP echo request, id 1, seq 143, length 40
18:00:05.839450 IP 192.168.44.1 > 192.168.55.11: ICMP echo reply, id 1, seq 143, length 40
18:00:06.869634 IP 192.168.55.11 > 192.168.44.1: ICMP echo request, id 1, seq 144, length 40
18:00:24.056075 IP 192.168.55.11 > intranet.domain.net: ICMP echo request, id 1, seq 145, length 40
18:00:28.604001 IP 192.168.55.11 > intranet.domain.net: ICMP echo request, id 1, seq 146, length 40
18:00:33.603664 IP 192.168.55.11 > intranet.domain.net: ICMP echo request, id 1, seq 147, length 40
18:00:38.607645 IP 192.168.55.11 > intranet.domain.net: ICMP echo request, id 1, seq 148, length 40Ok. Jetzt wäre es vermutlich an der Zeit, sich die Konfiguration des DNS mal genauer anzuschauen, richtig?
Moin
Entweder ein Firewall-Problem oder ein fehlendes/ falsches Gateway dort eingetragen.
Wie sieht das Ergebnis aus, wenn du auf deiner DNS-VM mal ein
eingibst?
Korrekt!
Gruß
em-pie
Zitat von @Oldschool:
Im WebGUI des Internet-Gateways sehe ich folgendes:
Sieht gut aus, damit sollten die Pakete des 44er Netzes grundsätzlich auch den Weg zurück ins 55er findenIm WebGUI des Internet-Gateways sehe ich folgendes:
Static Routing
>
> ID Destination Network Subnet Mask Default Gateway Status
> 1 192.168.55.0 255.255.255.0 192.168.44.254 EnabledDer raspi kann quasi alles; außer Kaffee kochen. Will heißen, er pingt und tracert fleissig alle Geräte im 44er und 55er Netz sowie im Internet.
Dass der alles anpingen/ auflösen kann, liegt daran, dass er mit einem bein im 55er Netz steht und über dieses auch alle Devices dort anspricht und mit dem anderen Bein im 44er Netz und darüber alle Geräte im dortigen Netz kontaktiert.Ich habe auch schon versucht, andere Geräte im 44er Netz anzupingen (vom 55er Netz aus); aber ohne Erfolg.
Was sind diese anderen Geräte? alles Windows-Kisten?Mein Test-Client im 55er Netz hat Windows 10, dies nur als Randinformation.
Der DNS-Server ist eine Linux-VM auf einem Windows 10 PC und tut zumindest im 44er Netz das was er soll. Die Geräte im 44er Netz haben nur diesen DNS eingetragen (über DHCP vom Internetgateway).
Im 55er Netz befindet sich noch ein WLAN-Access-Point mit DHCP-Server. Von dort beziehen alle Clients im 55er Netz auch Ihre DNS Einstellungen (192.168.44.253 als DNS) und Gateway Einstellungen (192.168.55.1).
Nun nochmal die Pings in ausführlicher Form auf dem 55er Client (192.168.55.11):
Im 55er Netz befindet sich noch ein WLAN-Access-Point mit DHCP-Server. Von dort beziehen alle Clients im 55er Netz auch Ihre DNS Einstellungen (192.168.44.253 als DNS) und Gateway Einstellungen (192.168.55.1).
Nun nochmal die Pings in ausführlicher Form auf dem 55er Client (192.168.55.11):
C:\Users\>ping 192.168.44.1
>
> Ping wird ausgeführt für 192.168.44.1 mit 32 Bytes Daten:
> Antwort von 192.168.44.1: Bytes=32 Zeit=11ms TTL=63
> Antwort von 192.168.44.1: Bytes=32 Zeit=11ms TTL=63
> Antwort von 192.168.44.1: Bytes=32 Zeit=12ms TTL=63
> Antwort von 192.168.44.1: Bytes=32 Zeit=45ms TTL=63
>
> Ping-Statistik für 192.168.44.1:
> Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
> (0% Verlust),
> Ca. Zeitangaben in Millisek.:
> Minimum = 11ms, Maximum = 45ms, Mittelwert = 19ms
Folglich routet der Pi und dein Gateway alle Pakete richtig. Das klappt dann also schon mal :-)
> C:\Users\>ping 192.168.44.253
>
> Ping wird ausgeführt für 192.168.44.253 mit 32 Bytes Daten:
> Zeitüberschreitung der Anforderung.
> Zeitüberschreitung der Anforderung.
> Zeitüberschreitung der Anforderung.
> Zeitüberschreitung der Anforderung.
>
> Ping-Statistik für 192.168.44.253:
> Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
> (100% Verlust),Entweder ein Firewall-Problem oder ein fehlendes/ falsches Gateway dort eingetragen.
Wie sieht das Ergebnis aus, wenn du auf deiner DNS-VM mal ein
routeOk. Jetzt wäre es vermutlich an der Zeit, sich die Konfiguration des DNS mal genauer anzuschauen, richtig?
Korrekt!
Gruß
em-pie
Im WebGUI des Internet-Gateways sehe ich folgendes:
Das ist richtig und korrekt. Siehst du auch daran das der Ping ins Internet zu 8.8.8.8 klappt, sonst wäre das unmöglich.Der raspi kann quasi alles; außer Kaffee kochen.
Das stimmt !! Und gut, zeigt das das IP Routing da sauber funktioniert.Kollege em-pie hat aber Recht.
Du solltest beim Ping vom RasPi mit -I <ip_adresse> immer mal die Quell IP Adresse an geben. Es macht also Sinn wenn du vom RasPi mal ins 44er Netz pingst das mit seiner 55er Absender IP zu machen. Also sowas wie:
ping -c 5 -I 192.168.55.1 www.heise.de
auch geht
ping -c 5 -I eth1 www.heise.de
ping -c 5 -I 192.168.55.1 8.8.8.8
ping -c 5 -I eth1 193.99.144.8
Auch hier gilt: Um DNS Probleme deines vermurksten Servers sicher auszuschliessen einfach testweise mal den Internet Router 44.1 als DNS Server auf dem RasPi konfigurieren.
Ich habe auch schon versucht, andere Geräte im 44er Netz anzupingen (vom 55er Netz aus); aber ohne Erfolg.
Komisch ? Du hast doch oben gerade geschrieben das du den Internet Router mit der 44.1 aus dem 66er Netz anpingen kannst, oder ??Der Drucker muss auch anpingbar sein. Der hat keine lokale Firewall. Allerdings MUSS er zwingend den Internet Router als Default Gateway konfiguriert haben, ansonsten findet er die Rückroute ins 55er Netz nicht...logisch !
Hast du das im Drucker Setup geprüft ?? Drucker und Server sollten IMMER eine statische IP Adresse haben und klar das diese NICHT im DHCP Pool liegen dürfen. Also querchecken mit dem 44er DHCP Server im Router.
Das gilt ebenso für ALLE anderen Geräte im 44er Netz was das Gateway anbetrifft.
Bei allen Windows Kisten da wie gesagt lokale Firewall immer beachten !
Mein Test-Client im 55er Netz hat Windows 10, dies nur als Randinformation.
Sollte erstmal kein Hinderungsgrund sein.Der DNS-Server ist eine Linux-VM auf einem Windows 10 PC
Hier ist es essentiell wichtig in welchem Modus die virtuellen NICs des Hypervisor Hosts eingestellt sind !Die müssen alle im Bridging Mode sein !
Das bedeutet das alles VMs auch IP Adressen im .44.0 /24er IP Netz haben müssen.
Keinesfalls dürfen diese Interfaces im Host oder NAT Mode sein !
Im 55er Netz befindet sich noch ein WLAN-Access-Point mit DHCP-Server.
Wäre netztechnsich besser das auf dem RasPi zu machen aber ertsmal ist das egal, denn es geht natürlich auch so.Was hier wichtig ist das die statischen IP Adressen des RasPi NICHT im DHCP Pool sind !
Ein ipconfig -all Check (Winblows) im 55er Netz sollte dann die richtigen IP Adressen anzeigen.
Achte darauf das ein Client im 55er LAN Segment nicht auch gleichzeitig im WLAN mit einer 55er IP ist. Hier darf nur entweder WLAN oder LAN aktiv sein !!
Und....
Hast du mal den Test gemacht und diesen Accesspoint und seine 55er IP mal von Geräten und VMs aus dem 44er Netz anzupingen ?? Klappt das ??
Um ggf. DNS Problemen im 55er Netz mal aus dem Wege zu gehen setze dort bei den Endgeräten doch testweise einfach mal den Internet Router .44.1 als DNS ein und teste mal ob du dann z.B. www.heise.de pingen kannst.
Das würde dann tatsächlich einen Fehler im DNS Server verifizieren sollte das klappen.
IP 192.168.55.11 > intranet.domain.net:
Ooops... intranet.domain.net (.net) ??? Das kann doch niemals sein !!!Der DNS Server macht ein reverse Lookup auf eine öffentliche Root Domain ?? Da stimmt wirklich was nicht mit dem DNS. Aber das ist erstmal egal...kommt später bzw. hat mit dem IP Routing im Netz nichts zu tun.
Es bleibt mal wieder die Frage warum du den Drucker nicht pingst ?? Vorausgesetzt der hat eine gültige Default Gateway Adresse 44.1 MUSS das klappen aus dem 55er Netz.
Am Drucker besteht wenigstens nicht die Gefahr falscher virtueller NIC Modi oder lokaler Firewalls die nicht angepasst sind.
Jetzt wäre es vermutlich an der Zeit, sich die Konfiguration des DNS mal genauer anzuschauen, richtig?
Bingo !!!C:\Users\>ping 192.168.44.253
>
> Ping wird ausgeführt für 192.168.44.253 mit 32 Bytes Daten:
> Zeitüberschreitung der Anforderung.
> Zeitüberschreitung der Anforderung.
> Zeitüberschreitung der Anforderung.
> Zeitüberschreitung der Anforderung.
>
> Ping-Statistik für 192.168.44.253:
> Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
> (100% Verlust)Was hat denn Dein interner DNS Server (im LAN) für eine IP Adresse zu einem externen DNS Server?
- Die IP des Speedport Routers (funktioniert)
- Googles DNS IP Adressen (funktioniert)
- Die DNS IPs Deines ISP (funktioniert)
- Seine eigene IP (funktioniert nicht)
- Gar keine IP (funktioniert nicht)
- Loopback (127.0.0.0) (funktioniert nicht)
Gruß
Dobby
Die IP des Speedport Routers (funktioniert)
Das kann man ganz sicher ausschliessen Dobby, denn ein Speedport supportet KEINE statischen Routen Da er die aber konfiguriert hat, hat er im Umkehrschluss glücklicherweise keinen Speedport.
Hallo zusammen,
hier noch mal kurz zusammengefasst die weiteren Infos:
Andere Geräte im 44er Netz sind neben weiteren Windows 10 Büchsen auch noch ein AppleTV, ein weiterer WLAN-Acess-Point (nicht zu verwechseln mit einem WLAN-Repeater), ein weiterer Raspi B3 mit openElec als Mediastreamer, und etliche Smartphones, eBooks, etc.
Der DNS- und Webserver läuft auf Oracle Virtualbox mit NIC als Netzwerkbrücke und dementsprechend mit eigener IP.
Die DHCP-Server im 44er sowie im 55er Netz sind mit einer DHCP-Range von 192.168.x.10 bis 192.168.x.100 ausgestattet und sollten somit nicht mit den statisch vergebenen IPs kollidieren.
In meinem ersten Beitrag schrieb ich ja bereits, dass der Internetzugriff vom 55er Netz tadellos funktioniert, wenn ich beispielsweise 8.8.8.8 als DNS eintrage. Wenn ich nun 192.168.44.1 (Internet-Gateway) als DNS eintrage funktioniert das auflösen von Internet-Adressen ebenso.
Ein Ping aus dem 44er Netz auf meinen Test-Client im 55er Netz resultiert in „Zeitüberschreitung der Anforderung.“
Zu intranet.domain.net : Dort stand vorher die originale Adresse unseres Intranets. Habe ich dann entsprechend anonymisiert.
Ich brauch jetzt ma 'ne Pause und widme mich morgen noch mal der Analyse bezüglich der Default Gateways. Gerade sehe ich nur noch Zahlen und Buchstaben auf meiner Netzhaut.
Schöne Grüsse,
Oldschool
hier noch mal kurz zusammengefasst die weiteren Infos:
Andere Geräte im 44er Netz sind neben weiteren Windows 10 Büchsen auch noch ein AppleTV, ein weiterer WLAN-Acess-Point (nicht zu verwechseln mit einem WLAN-Repeater), ein weiterer Raspi B3 mit openElec als Mediastreamer, und etliche Smartphones, eBooks, etc.
Der DNS- und Webserver läuft auf Oracle Virtualbox mit NIC als Netzwerkbrücke und dementsprechend mit eigener IP.
Die DHCP-Server im 44er sowie im 55er Netz sind mit einer DHCP-Range von 192.168.x.10 bis 192.168.x.100 ausgestattet und sollten somit nicht mit den statisch vergebenen IPs kollidieren.
In meinem ersten Beitrag schrieb ich ja bereits, dass der Internetzugriff vom 55er Netz tadellos funktioniert, wenn ich beispielsweise 8.8.8.8 als DNS eintrage. Wenn ich nun 192.168.44.1 (Internet-Gateway) als DNS eintrage funktioniert das auflösen von Internet-Adressen ebenso.
Ein Ping aus dem 44er Netz auf meinen Test-Client im 55er Netz resultiert in „Zeitüberschreitung der Anforderung.“
Zu intranet.domain.net : Dort stand vorher die originale Adresse unseres Intranets. Habe ich dann entsprechend anonymisiert.
Ich brauch jetzt ma 'ne Pause und widme mich morgen noch mal der Analyse bezüglich der Default Gateways. Gerade sehe ich nur noch Zahlen und Buchstaben auf meiner Netzhaut.
Schöne Grüsse,
Oldschool
Ein Ping aus dem 44er Netz auf meinen Test-Client im 55er Netz resultiert in „Zeitüberschreitung der Anforderung.“
Klar und zu erwarten, denn das ist wieder die alte Leier das die lokale Windows Firewall alles mit fremden Absender IPs im Default blockt UND auch das sie generell das ICMP Protokoll blockt wie oben schon mehrfach beschrieben.Solange du DAS nicht beides in den lokalen Firewalls deiner Windows Rechner anpasst wirst du weiter diese Probleme haben Windows Maschinen zu pingen:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Sinnvoll wäre hier wieder gewesen wenn du mal geschrieben hättest ob der wenigstens die .55.1 am RasPi hat pingen können
Deshalb auch der wiederkehrende Appell hier zum Ping Test erstmal einem RasPi, Drucker oder was auch immer zu nehmen was keine lokale Firewall hat um nicht in diese Falle zu tappen.
Hier auch wieder der wichtige Tip: Auf dem .55er Client mal einen Wireshark installieren und checken ob du die eingehenden ICMP Ping Pakete (Echo) aus dem 44er Netz sehen kannst.
Grundproblem bei Windows ist und bleibt aber die nicht angepasste Firewall mit dem Blocking von ICMP.
Der DNS- und Webserver läuft auf Oracle Virtualbox mit NIC als Netzwerkbrücke und dementsprechend mit eigener IP.
Das ist auch OK solange das eine .44.x IP ist und das Default Gateway der Rechner auf die 44.1 eingestellt ist und die frei ins 44er und 55er Netz pingen können z.B. die 55.1 am RasPi.Wenn ich nun 192.168.44.1 (Internet-Gateway) als DNS eintrage funktioniert das auflösen von Internet-Adressen ebenso.
Zeigt eigentlich das das Routing dann sauber funktioniert und das DNS auch wenn es denn richtig gemacht wird.Gerade sehe ich nur noch Zahlen und Buchstaben auf meiner Netzhaut.
Das ist richtig. Beim Schlafen kommen einem meistens auch noch Ideen in den Sinn.Dann warten wir mal ab was der Sonntag bringt... Hier die wichtigstens ToDos:
- Ping aus dem 44er Netz auf die RasPi IP .55.1. Insbesondere solltest du das mit den VMs auch testen
- Lokale Firewall der Winblows Rechner anpassen und ICMP hier generell erlauben.
- Ggf. DHCP Server vom 55er netz auf den RasPi migrieren: Netzwerk Management Server mit Raspberry Pi
# Sample configuration file for ISC dhcpd for Debian
#
ddns-update-style none;
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;
# Ping the IP address that is being offered to make sure it isn't
# configured on another node. This has some potential repercussions
# for clients that don't like delays.
ping-check true;
# option definitions common to all supported networks...
option domain-name "oldschool.intern";
option domain-name-servers 192.168.44.1, 192.168.44.253 ;
default-lease-time 600;
max-lease-time 7200;
# Use this to send dhcp log messages.
log-facility local7;
# DHCP Ranges for different Subnets
subnet 192.168.55.0 netmask 255.255.255.0 {
range 192.168.55.10 192.168.55.100;
option routers 192.168.55.1;
}
# Fixed IP addresses can also be specified for hosts.
host drucker {
hardware ethernet 08:00:08:26:c0:c3;
fixed-address 192.168.55.222;
} ACHTUNG!: Da du den DHCP Server im RasPi nur auf das eth1 Segment einschränken willst (eth0 darf keine IPs vergeben, das macht der Internet Router) musst du dem Server das noch in der /etc/default/isc-dhcp-server Datei sagen unter:
# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
# Separate multiple interfaces with spaces, e.g. "eth0 eth1".
# INTERFACES=""
INTERFACES="eth1" So, jetzt hast du was zu basteln für den Sonntag...
Also,
habe dann heute morgen festgestellt, dass ich Einiges dank diesem Forum dazugelernt habe. Danke dafür.
Heute morgen ging es trotz Zeitumstellung früh ans Werk. Ich habe den privaten DNS erst einmal runtergefahren und im 55er Netz den DNS neu auf 192.168.11.1 konfiguriert.
Danach funktionierte auch der Ping von zB 192.168.55.11 (Windows-PC) auf 192.168.44.252 (Netzwerkdrucker). Die Testseite, die ich dann gedruckt habe, rahme ich mir ein. Auch das pingen auf www.heise.de funktionierte.
Ich habe die Standard-Gateway-Einstellungen alle überprüft und es waren bereits überall Einträge drin auf 192.168.44.1. Auch das Routing auf dem Raspi scheint ja jetzt nach kleinen Änderungen sauber zu sein. Im Grossen und Ganzen muss ich sagen, dass ich ordentlich und konsequent gearbeitet habe - um mich mal an dieser Stelle selbst zu loben
Ich habe jetzt auch dank Euren Beiträgen verstanden, dass ich nicht einfach irgendwelche Windows-Rechner aus fremden Netzen anpingen kann, ohne das in der PC-eigenen Firewall entsprechend freizugeben. Man ist es ja so gewohnt dass man Rechner einfach anpingen kann, wenn man sich nur in einem Netz befindet und nimmt an, dass es auch geht wenn man die Netze mit einem Router verbindet... Grosser Fehler meinerseits.
Gestern Abend noch war ich schier am Verzweifeln und habe immer wieder die statische Route im InternetGateway hinterfragt. Ich war schon fast soweit ein neues Gerät anzuschaffen, weil es nach meiner Ansicht kaputt sein musste.
Natürlich habe ich auch schon von beiden Netzen aus auf den jeweils anderen NIC des Raspis gepingt. Also aus dem 44er Netz auf 192.168.55.1 und vom 55er Netz auf 192.168.44.254. Das funktionierte immer. Aber alle Adressen dahinter gingen dann nicht. Auch tracert, traceroute und pathping starben hinter dem NIC des Raspis. Nun weiss ich, dass es in den meisten Fällen an der ICMP-Freigabe der PC-Firewalls lag.
Um den privaten DNS und den Webserver mit dem Intranet wieder zu aktivieren, schaue ich mir im Laufe der Woche mal die Konfig der VM an. Eine Frage dazu hätte ich noch: Der virtuelle NIC steht ja auf Bridged und hat eine eigene IP. Muss ich dennoch auf dem Windows-Host, wo sich ja der physische NIC befindet, Zugriffe vom 55er Netz zulassen?
Ansonsten würde ich meine Ursprungsfrage zum Routingproblem als gelöst markieren, wenn niemand einer anderen Ansicht ist. Meine nächste Grossbaustelle ist dann der private DNS. Dazu würde ich dann aber besser eine neue Frage eröffnen. Aber erst einmal sollte ich mit dem neu erlangten Wissen selber klar kommen.
Schöne Grüsse und grossen Dank an alle Beteiligten.
habe dann heute morgen festgestellt, dass ich Einiges dank diesem Forum dazugelernt habe. Danke dafür.
Heute morgen ging es trotz Zeitumstellung früh ans Werk. Ich habe den privaten DNS erst einmal runtergefahren und im 55er Netz den DNS neu auf 192.168.11.1 konfiguriert.
Danach funktionierte auch der Ping von zB 192.168.55.11 (Windows-PC) auf 192.168.44.252 (Netzwerkdrucker). Die Testseite, die ich dann gedruckt habe, rahme ich mir ein.
Auch das pingen auf www.heise.de funktionierte.Ich habe die Standard-Gateway-Einstellungen alle überprüft und es waren bereits überall Einträge drin auf 192.168.44.1. Auch das Routing auf dem Raspi scheint ja jetzt nach kleinen Änderungen sauber zu sein. Im Grossen und Ganzen muss ich sagen, dass ich ordentlich und konsequent gearbeitet habe - um mich mal an dieser Stelle selbst zu loben
Ich habe jetzt auch dank Euren Beiträgen verstanden, dass ich nicht einfach irgendwelche Windows-Rechner aus fremden Netzen anpingen kann, ohne das in der PC-eigenen Firewall entsprechend freizugeben. Man ist es ja so gewohnt dass man Rechner einfach anpingen kann, wenn man sich nur in einem Netz befindet und nimmt an, dass es auch geht wenn man die Netze mit einem Router verbindet... Grosser Fehler meinerseits.
Gestern Abend noch war ich schier am Verzweifeln und habe immer wieder die statische Route im InternetGateway hinterfragt. Ich war schon fast soweit ein neues Gerät anzuschaffen, weil es nach meiner Ansicht kaputt sein musste.
Natürlich habe ich auch schon von beiden Netzen aus auf den jeweils anderen NIC des Raspis gepingt. Also aus dem 44er Netz auf 192.168.55.1 und vom 55er Netz auf 192.168.44.254. Das funktionierte immer. Aber alle Adressen dahinter gingen dann nicht. Auch tracert, traceroute und pathping starben hinter dem NIC des Raspis. Nun weiss ich, dass es in den meisten Fällen an der ICMP-Freigabe der PC-Firewalls lag.
Um den privaten DNS und den Webserver mit dem Intranet wieder zu aktivieren, schaue ich mir im Laufe der Woche mal die Konfig der VM an. Eine Frage dazu hätte ich noch: Der virtuelle NIC steht ja auf Bridged und hat eine eigene IP. Muss ich dennoch auf dem Windows-Host, wo sich ja der physische NIC befindet, Zugriffe vom 55er Netz zulassen?
Ansonsten würde ich meine Ursprungsfrage zum Routingproblem als gelöst markieren, wenn niemand einer anderen Ansicht ist. Meine nächste Grossbaustelle ist dann der private DNS. Dazu würde ich dann aber besser eine neue Frage eröffnen. Aber erst einmal sollte ich mit dem neu erlangten Wissen selber klar kommen.
Schöne Grüsse und grossen Dank an alle Beteiligten.
Zitat von @Oldschool:
Ansonsten würde ich meine Ursprungsfrage zum Routingproblem als gelöst markieren, wenn niemand einer anderen Ansicht ist.
Ansonsten würde ich meine Ursprungsfrage zum Routingproblem als gelöst markieren, wenn niemand einer anderen Ansicht ist.
Du mußt es selbst wissen, ob Dein Probem damit gelöst ist oder nicht.
Dann bleibt also nur noch Wie kann ich einen Beitrag als gelöst markieren?
Schönen Restsonntag noch.
lks
und im 55er Netz den DNS neu auf 192.168.11.1 konfiguriert.
Huch ??? Was hat diese IP denn da nun wieder zu suchen ?? Du hast doch weit und breit gar kein .11.0er Netzwerk.Was ist das denn nun schon wieder ??
Danach funktionierte auch der Ping von zB 192.168.55.11 .....
Wie erwartet. So sollte es sein !dass ich ordentlich und konsequent gearbeitet habe - um mich mal an dieser Stelle selbst zu loben
Riecht zwar ziemlich stark nach Eichenlaub aber wo du Recht hast hast du Recht....Man ist es ja so gewohnt dass man Rechner einfach anpingen kann
Generell stimmt das auch aber Winblows ist wie immer etwas spezieller.... Das liegt aber daran das das OS weltweit Angriffsziel Nummer 1 ist und MS hier den Spagat zwischen Sicherheit und User Bequemlichkeit machen muss. Nicht imemr ganz einfach muss man denen fairerweise zugestehen.
und habe immer wieder die statische Route im InternetGateway hinterfragt.
Ooops, warum ???Die ist essentiell wichtig, Ohne sie würde das Routing in deinen beiden Netzen nicht klappen. Hier hat der Administrator.de Erklärbärmal so einen IP Paket Flow durch Router genau beschrieben:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Da sollte auch dir dann klar sein wie wichtig diese Route ist.
Nun weiss ich, dass es in den meisten Fällen an der ICMP-Freigabe der PC-Firewalls lag.
Ja, immer wenn diese Winblows Gurken sind... Um den privaten DNS und den Webserver mit dem Intranet wieder zu aktivieren, schaue ich mir im Laufe der Woche mal die Konfig der VM an.
Nicht nur das sondern auch die des DNS Servers selber:http://www.raspberry-pi-geek.de/Magazin/2014/03/RasPi-als-DHCP-und-DNS- ...
https://www.blogging-it.com/bind-dns-server-unter-raspbian-installieren- ...
https://it-lehre.de/2013/02/dns-server-unter-debian-installieren-und-kon ...
usw.
Meine nächste Grossbaustelle ist dann der private DNS.
Weise Worte und Dr. Google hat da für dich Tausende Dokumente parat Dann bleibt in der Tat nur Wie kann ich einen Beitrag als gelöst markieren?
Und...ebenso viel Erfolg !
Zitat von @aqui:
Was ist das denn nun schon wieder ??
und im 55er Netz den DNS neu auf 192.168.11.1 konfiguriert.
Huch ??? Was hat diese IP denn da nun wieder zu suchen ?? Du hast doch weit und breit gar kein .11.0er Netzwerk.Was ist das denn nun schon wieder ??
Danach funktionierte auch der Ping von zB 192.168.55.11 .....
Das war ein Verschreiber. Solle 192.168.44.1 heissen. Ich war aber gedanklich schon bei der Client IP mit der 11 am Ende…
So, kurz die Zusammenfassung der Lösung:
Zur Lösung beigetragen hat die Erkenntnis, dass es auf einen ping-request auf WindowsClients in anderen Netzen keinen ping-response gibt, wenn man die Firewall nicht für ICMP aus anderen Netzen freischaltet.
Desweiteren habe ich nun verstanden, dass es in meinem oben geschilderten Fall keine statische Route auf dem Raspi braucht, denn er steht ja mit jeweils einem NIC in beide Netze und kennt sie somit auch. Es braucht nur die statische Route ins 55er Netz auf dem Standard-Gateway des 44er Netzes.
Klug###modus = on
Wenn man beispielsweise neben einem bestehenden Netz (mit DNS- und Intranet-Server) eine Art Gästenetzwerk bereitstellen möchte, dann ist es sehr sinnvoll in diesen Server eine zweite Netzwerkkarte einzubauen und Ihn auch als Router zwischen beide Netze zu verwenden. Macht man es so wie ich und schafft sich ein Gerät für das Routing neu an, sollte man eventuell bestehende Dienste auf dieses Gerät umziehen, insofern man die Dienste auch für beide Netze nutzen möchte. Das reduziert Fehlerquellen und spart Ressourcen und Wartungsaufwand.
Klug###modus = off
Nahezu jede Antwort hat hier dazu beigetragen, dass ich mein Eingangs-Problem lösen konnte.
Unbedingt lesenswert sind die weiterführenden Links von aqui für die Einrichtung des DNS und megaklasse die für meinen speziellen Fall angepasste Config des DHCP. Danke dafür.
Bis neulich
wenn man die Firewall nicht für ICMP aus anderen Netzen freischaltet.
Unser reden oben...! dass es in meinem oben geschilderten Fall keine statische Route auf dem Raspi braucht,
Auch nicht ganz richtig, denn es braucht wenigstens eine auf dem RasPi, nämlich die statische Default Route. Aber wir wollen ja nicht spitzfindig sein...eine Art Gästenetzwerk bereitstellen möchte, dann ist es sehr sinnvoll in diesen Server eine zweite Netzwerkkarte einzubauen und Ihn auch als Router zwischen beide Netze zu verwenden.
Nein !Das ist vollkommen falsch, denn so hättest du einen parallelen Backdoor Router. Aus Sicherheitssicht wäre das tödlich, denn ein Gästenetz ist IMMER vollkommen separiert vom eigenen, privaten Netz. Oder sollte es wenigstens sein wenn man es richtig macht.
In so fern schaltet man immer einen Router oder eine Firewall mit 3 Interfaces dazu. Hier findest du Konzepte wie man es richtig macht um die Netze zu trennen:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Dein Konzept ein Gastnetz quasi "durchzuschleifen" ist die grundlegende Fehlerquelle, denn das Netzwerk Design ist vollkommen falsch. Leuchtet dir vermutlich auch selber ein jetzt. Kein Netzwerker würde das so lösen.
Nahezu jede Antwort hat hier dazu beigetragen, dass ich mein Eingangs-Problem lösen konnte.
Das ist doch die Hauptsache ! Wenn jetzt noch die Design Erkenntnis kommt hat das Forum ja was bewirkt Danke dafür.
Immer gerne wieder 
