8
Gibt es einen Unterschied in Datenpaketen, die mit bzw. ohne Port-Forwarding bzw. Umsetzung beim Client ankommen?
dieses Problem konnte mit drei verschiedenen Routern nachgestellt werden:
Der Router soll Datenpakete mit Port 8088 auf eine bestimmte LAN-Adresse mit Port 80 weiterleiten. Also eine einfache Übung, sollte man meinen. Die LAN-Adresse ist ein Heizungs-Controller, der auf Port 80 horcht.
Was passiert?
a.. die URL http://193.x.x.x:8088 kommt an der WAN-Schnittstelle des Routers an, dort wird 8088 auf 80 umgesetzt und an 192.168.0.200 (Heizung) weitergeleitet. Die Heizung antwortet NICHT.
b.. wenn man aber http://193.x.x.x:8088/index.htm eingibt, bekommt man Antwort vom Controller
c.. wenn man die Port-Umsetzung rausnimmt und Port 80 auf Port 80 weiterleitet, dann funktioniert http://193.x.x.x ohne /index.htm
Nun frage ich mich, wo für den Heizungs-Controller der Unterschied ist, wenn ich ihn über http://193.x.x.x:8088 mit Port-Umsetzung oder über http://193.x.x.x ohne Port-Umsetzung anspreche. ?????
Anscheinend gibt's einen Unterschied, denn ich MUSS bei Verwendung der Port-Umsetzung "/index.htm" bei der URL ergänzen.
Kann mir das bitte jemand erklären? Ich bin seit 25 Jahren in der IT tätig, aber so was ist mir schleierhaft. Wenn der Port vom Router von 8088 auf 80 umgesetzt wird, dann kriegt das der Controller doch nicht mit, oder?
Der Router soll Datenpakete mit Port 8088 auf eine bestimmte LAN-Adresse mit Port 80 weiterleiten. Also eine einfache Übung, sollte man meinen. Die LAN-Adresse ist ein Heizungs-Controller, der auf Port 80 horcht.
Was passiert?
a.. die URL http://193.x.x.x:8088 kommt an der WAN-Schnittstelle des Routers an, dort wird 8088 auf 80 umgesetzt und an 192.168.0.200 (Heizung) weitergeleitet. Die Heizung antwortet NICHT.
b.. wenn man aber http://193.x.x.x:8088/index.htm eingibt, bekommt man Antwort vom Controller
c.. wenn man die Port-Umsetzung rausnimmt und Port 80 auf Port 80 weiterleitet, dann funktioniert http://193.x.x.x ohne /index.htm
Nun frage ich mich, wo für den Heizungs-Controller der Unterschied ist, wenn ich ihn über http://193.x.x.x:8088 mit Port-Umsetzung oder über http://193.x.x.x ohne Port-Umsetzung anspreche. ?????
Anscheinend gibt's einen Unterschied, denn ich MUSS bei Verwendung der Port-Umsetzung "/index.htm" bei der URL ergänzen.
Kann mir das bitte jemand erklären? Ich bin seit 25 Jahren in der IT tätig, aber so was ist mir schleierhaft. Wenn der Port vom Router von 8088 auf 80 umgesetzt wird, dann kriegt das der Controller doch nicht mit, oder?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 309923
Url: https://administrator.de/contentid/309923
Printed on: April 19, 2024 at 21:04 o'clock
8 Comments
Latest comment
Moin ...
Na so verwunderlich ist das jetzt nicht wirklich.
Egal wie du die Ports intern umleitest verändert sich ja die url nicht mit welcher der Webserver angesprochen wird (Edit: Der dort mehr oder weniger zufällig lauscht).
Der Webserver schaut also in seiner Config nach port 8088 und findet dort keinen Hinweis welchen Dateityp er als Default öffnen soll.
Auf Port 80 findet er diese Defaulteinstellung und öffnet diesen Dateityp entsprechend.
Ergo müsstest du für port 8088 (Vorgabe aus der URL) dem Webserver einen entsprechenden Default mitgeben, sofern möglich.
VG
Na so verwunderlich ist das jetzt nicht wirklich.
Egal wie du die Ports intern umleitest verändert sich ja die url nicht mit welcher der Webserver angesprochen wird (Edit: Der dort mehr oder weniger zufällig lauscht).
Der Webserver schaut also in seiner Config nach port 8088 und findet dort keinen Hinweis welchen Dateityp er als Default öffnen soll.
Auf Port 80 findet er diese Defaulteinstellung und öffnet diesen Dateityp entsprechend.
Ergo müsstest du für port 8088 (Vorgabe aus der URL) dem Webserver einen entsprechenden Default mitgeben, sofern möglich.
VG
Nein, der Webserver schaut nicht nach Port 8088, denn den kriegt er ja gar nicht mit, der Router, der davor sitzt, ändert den Port 8088 auf 80.
Der Webserver läuft auf dem Heizungs-Controller und horcht ausschließlich auf Port 80. Daher muss die Portumsetzung von 8088 auf 80 im Router stattfinden. Dort ist ja auch ein "Virtueller Server" eingerichtet, der weiß, was zu tun ist und der macht das auch korrekt.
Wenn nun der Router ein Datenpaket von 8088 auf 80 umsetzt und an den Webserver des Controllers weiterleitet, ist das für den Controller doch g`hupft wie g`hatscht (egal), ob das Paket aus einer "Umsetzung des Routers" stammt oder direkt mit Port 80 gesendet wurde.
Es gibt aber anscheinend doch einen Unterschied.
Der Webserver läuft auf dem Heizungs-Controller und horcht ausschließlich auf Port 80. Daher muss die Portumsetzung von 8088 auf 80 im Router stattfinden. Dort ist ja auch ein "Virtueller Server" eingerichtet, der weiß, was zu tun ist und der macht das auch korrekt.
Wenn nun der Router ein Datenpaket von 8088 auf 80 umsetzt und an den Webserver des Controllers weiterleitet, ist das für den Controller doch g`hupft wie g`hatscht (egal), ob das Paket aus einer "Umsetzung des Routers" stammt oder direkt mit Port 80 gesendet wurde.
Es gibt aber anscheinend doch einen Unterschied.
Hallo,
wohin geht den ein tracert auf die IP Adresse des Heinzungscontrollers?
IP Adressen die mit 193 anfangen sind nämlich öffentlich...
http://www.utrace.de/?query=193.0.0.1
brammer
wohin geht den ein tracert auf die IP Adresse des Heinzungscontrollers?
IP Adressen die mit 193 anfangen sind nämlich öffentlich...
http://www.utrace.de/?query=193.0.0.1
brammer
Ahoi ....
Musst ja meine Meinung nicht teilen, aber ich denke du vergisst die URL die der Webserver schon mitgeteilt bekommt in der Form: http://irgendeinWebserver:aufPortxyz soll die Abfrage beantworten. Egal was und wie du intern die Ports weiterleitest tauscht der router die URL ja nicht aus. Mit dem Standardport 80 klappt das besser weil der nicht in der URL steht. Also Port 80 kann man recht problemlos an 8080 etc. weiterleiten.
Das Ergebnis dürfte auch sehr unterschiedlich sein je nach Verwendung und Konfiguration des verwendeten Webservers.
Vg
Hallo,
das könnte auch ein Problem vom Browser her sein.
Möglicherweise schreibt der Browser http://ip in http://ip/index.html um.
Wenn der Port kein Standardport ist, macht er das vieleicht nicht.
Auch möglich, was VG wohl meint, wenn Du eine URL in einem Browser eintippst, wird dieser String parallel mit einem HTTP GET übertragen.
Ich weiß aber nicht ob die Portnummer dort noch enthalten ist.
Versuch mal von extern diese Abfrage mit CURL oder WGET.
Da sieht man vieles was der Browser nicht zeigt.
Und sniffe auf der Zielseite mit WireShark mal mit was genau als Anfrage ankommt.
Stefan
das könnte auch ein Problem vom Browser her sein.
Möglicherweise schreibt der Browser http://ip in http://ip/index.html um.
Wenn der Port kein Standardport ist, macht er das vieleicht nicht.
Auch möglich, was VG wohl meint, wenn Du eine URL in einem Browser eintippst, wird dieser String parallel mit einem HTTP GET übertragen.
Ich weiß aber nicht ob die Portnummer dort noch enthalten ist.
Versuch mal von extern diese Abfrage mit CURL oder WGET.
Da sieht man vieles was der Browser nicht zeigt.
Und sniffe auf der Zielseite mit WireShark mal mit was genau als Anfrage ankommt.
Stefan
Vielen Dank an alle, die hier zur Problemlösung beitragen.....
Es scheint wohl so zu sein, dass der HTTP GET Request mit dem Transport über TCP und somit mit der Umsetzung von 8088 auf 80 nichts zu tun hat. Das wusste ich nicht.
Der Webserver in diesem Controller wertet anscheinend die URL aus, die über HTTP GET geschickt wird, obwohl die dort enthaltene Port-Angabe nur dem Transport durch die Firewalls dient und schlussendlich auf TCP Port 80 endet.
Wenn man nun nicht /index.htm in die URL schreibt, weiß der blöde Server nicht mehr, was zu tun ist.
VG hatte schon Recht, ich habe seine Antwort aber nicht ganz verstanden. Hatte jetzt Kontakt mit einem anderen Spezialisten und jetzt weiß ich, warum es nicht funktioniert hat. Mit war wichtig, darzulegen, dass der Heizungs-Controller das Problem verursacht und nicht meine Konfiguration der Firewalls und des Routers.
Danke und liebe Grüße aus Österreich
Walter
Es scheint wohl so zu sein, dass der HTTP GET Request mit dem Transport über TCP und somit mit der Umsetzung von 8088 auf 80 nichts zu tun hat. Das wusste ich nicht.
Der Webserver in diesem Controller wertet anscheinend die URL aus, die über HTTP GET geschickt wird, obwohl die dort enthaltene Port-Angabe nur dem Transport durch die Firewalls dient und schlussendlich auf TCP Port 80 endet.
Wenn man nun nicht /index.htm in die URL schreibt, weiß der blöde Server nicht mehr, was zu tun ist.
VG hatte schon Recht, ich habe seine Antwort aber nicht ganz verstanden. Hatte jetzt Kontakt mit einem anderen Spezialisten und jetzt weiß ich, warum es nicht funktioniert hat. Mit war wichtig, darzulegen, dass der Heizungs-Controller das Problem verursacht und nicht meine Konfiguration der Firewalls und des Routers.
Danke und liebe Grüße aus Österreich
Walter
Hi,
Wenn er ein Standarddokument konfiguriert hat und dieses anstandlos liefert, wenn in der URL kein Dokument genannt wird, dann funktioniert das mit solchen Port-Umsetzungen auch. Für den Client sieht es dann so aus, als ob unter der URL_ohne_Dokument ein Dokument geliefert wird.
Wenn der Webserver aber damit reagiert, dass er dem Client eine Umleitung auf eine URL mit diesem Standarddokument sendet, dann liefert er dem Client insofern eine falsche URL, dass dort nicht der externe Port drin ist. Und damit sendet der Client die neue URL an den Standard-Port 80 und die Firewall blockt folgerichtig. Bei internen Clients funktioniert das aber.
Lösung wäre, den Port des Webservers auf der Heizung auch auf 8080 umzustellen und dann auch intern mit 8080 zu arbeiten.
E.
VG hatte schon Recht, ich habe seine Antwort aber nicht ganz verstanden. Hatte jetzt Kontakt mit einem anderen Spezialisten und jetzt weiß ich, warum es nicht funktioniert hat. Mit war wichtig, darzulegen, dass der Heizungs-Controller das Problem verursacht und nicht meine Konfiguration der Firewalls und des Routers.
Das ist ein ganz normales Webserver-Verhalten, wenn die Implementierung des Standarddokuments als Umleitung programmiert ist.Wenn er ein Standarddokument konfiguriert hat und dieses anstandlos liefert, wenn in der URL kein Dokument genannt wird, dann funktioniert das mit solchen Port-Umsetzungen auch. Für den Client sieht es dann so aus, als ob unter der URL_ohne_Dokument ein Dokument geliefert wird.
Wenn der Webserver aber damit reagiert, dass er dem Client eine Umleitung auf eine URL mit diesem Standarddokument sendet, dann liefert er dem Client insofern eine falsche URL, dass dort nicht der externe Port drin ist. Und damit sendet der Client die neue URL an den Standard-Port 80 und die Firewall blockt folgerichtig. Bei internen Clients funktioniert das aber.
Lösung wäre, den Port des Webservers auf der Heizung auch auf 8080 umzustellen und dann auch intern mit 8080 zu arbeiten.
E.
Vielen Dank noch einmal an alle.
wir können den Webserver nicht umstellen, ist ein embedded System eines Fremdherstellers. Wir lassen es so und wissen in Zukunft, wie die Dinger reagieren werden.
Die Ursache der Problematik ist jetzt klar.
wir können den Webserver nicht umstellen, ist ein embedded System eines Fremdherstellers. Wir lassen es so und wissen in Zukunft, wie die Dinger reagieren werden.
Die Ursache der Problematik ist jetzt klar.
