14
öffentliche IP auf lokal umrouten
Hallo,
wir entwickeln Anwendungen, die Webdienste nutzen, die auf einem lokalen IIS laufen.
Diese Anwendungen hinterlegen in einer .config die lokale IP.
Eine statische öffentliche IP haben wir z.B 217.xxx.xxx.xxx.
Nun soll, wenn lokal getestet wird, die öffentliche IP Adresse verwendet werden und nicht die IP des Webservers im lokalen Netz: 192.168.1.100
Also angesprochen werden soll die 217.xxx.xxx.xxx und die Anfrage soll an 192.168.1.100 geleitet werden.
Wir finden im Router (Linksys WRT54G3G) keine Einstellungen, die dies ermöglichen.
Was kann man tun?
wir entwickeln Anwendungen, die Webdienste nutzen, die auf einem lokalen IIS laufen.
Diese Anwendungen hinterlegen in einer .config die lokale IP.
Eine statische öffentliche IP haben wir z.B 217.xxx.xxx.xxx.
Nun soll, wenn lokal getestet wird, die öffentliche IP Adresse verwendet werden und nicht die IP des Webservers im lokalen Netz: 192.168.1.100
Also angesprochen werden soll die 217.xxx.xxx.xxx und die Anfrage soll an 192.168.1.100 geleitet werden.
Wir finden im Router (Linksys WRT54G3G) keine Einstellungen, die dies ermöglichen.
Was kann man tun?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 165317
Url: https://administrator.de/forum/oeffentliche-ip-auf-lokal-umrouten-165317.html
Ausgedruckt am: 22.04.2025 um 17:04 Uhr
14 Kommentare
Neuester Kommentar
Normalerweise macht man das mit sog. Port Forwarding oder Port Weiterleitung was auch jeder 20 Euro Baumarkt Billigrouter supportet und der o.a. Linksys natürlich allemal auch.
Leider ist nicht ganz klar WIE genau du auf diese IP zugreifen willst, denn da ist deine Aussage etwas schwammig bzw. unpräzise.
Beachte das du NICHT von intern (loklaes LAN) auf diese externe IP zu greifen kannst, denn dann müsste der Router sog. Hairpin NAT supporten was die meisten Consumer Billigrouter nicht können !
http://wiki.mikrotik.com/wiki/Hairpin_NAT
Du kannst also ausschliesslich nur von remote dann auf diese IP zugreifen ! Wenn du das so machst...OK dann funktioniert das problemlos.
Von intern nicht, es sei denn dein Linksys supportet Hairpin NAT. Das sollte ein Blick ins Handbuch oder das Datenblatt dann im Handumdrehen klären !
Leider ist nicht ganz klar WIE genau du auf diese IP zugreifen willst, denn da ist deine Aussage etwas schwammig bzw. unpräzise.
Beachte das du NICHT von intern (loklaes LAN) auf diese externe IP zu greifen kannst, denn dann müsste der Router sog. Hairpin NAT supporten was die meisten Consumer Billigrouter nicht können !
http://wiki.mikrotik.com/wiki/Hairpin_NAT
Du kannst also ausschliesslich nur von remote dann auf diese IP zugreifen ! Wenn du das so machst...OK dann funktioniert das problemlos.
Von intern nicht, es sei denn dein Linksys supportet Hairpin NAT. Das sollte ein Blick ins Handbuch oder das Datenblatt dann im Handumdrehen klären !
Könnte man nicht mittels statischer Route (Host, evt. Router) die IP-Pakete nicht zwingen über das Internet zu gehen.......?!?
Gruß
Carsten
Gruß
Carsten
Klare Antwort: NEIN ! (Mit Routing hat das nix zu tun !)
moin,
ich würde mir eher vorstellen, dass er einen WAN Emulator wie z.B Nist net sucht...
Gruß
ich würde mir eher vorstellen, dass er einen WAN Emulator wie z.B Nist net sucht...
Gruß
OK das wäre was anderes. Die Beschreibung ist auch etwas diffus...leider 
Damit klappt das natürlich. WANEM ist auch so ein Vertreter...
http://wanem.sourceforge.net/
Damit klappt das natürlich. WANEM ist auch so ein Vertreter...http://wanem.sourceforge.net/
Zur Erläuterung:
Eine auszuliefernde Client-Software die .Net Technologie verwendet schreibt zu der Anwendung eine config-datei mit diesem Inhalt:
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="Service1Soap" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384"/>
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None" realm=""/>
<message clientCredentialType="UserName" algorithmSuite="Default"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://192.168.100.1:80/dta/uploader1.asmx" binding="basicHttpBinding" bindingConfiguration="Service1Soap" contract="UploadServiceHorst.Service1Soap" name="Service1Soap"/>
</client>
</system.serviceModel>
<startup><supportedRuntime version="v2.0.50727"/></startup></configuration>
wenn die anwendung, die in diesem Fall den uploader dienst benutzt ausgeliefert wird, müssen wir also manuell die IP 192.168.100.1 durch unsere externe ersetzen.
Es wäre also für uns eleganter, wir könnten den webdienst über seine öffentliche ip ansprechen und die config würde sofort richtig geschrieben.
Das Problem betrifft auch Handys, die sich via wlan in unserem Netzwerk anmelden und dann die Webanwendungen verwenden wollen die sonst öffentlich zu erreichen sind.
Man muss im Handy also dann die Adressen manuell auf lokal umstellen, was noch umständlicher ist.
Eine auszuliefernde Client-Software die .Net Technologie verwendet schreibt zu der Anwendung eine config-datei mit diesem Inhalt:
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="Service1Soap" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384"/>
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None" realm=""/>
<message clientCredentialType="UserName" algorithmSuite="Default"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://192.168.100.1:80/dta/uploader1.asmx" binding="basicHttpBinding" bindingConfiguration="Service1Soap" contract="UploadServiceHorst.Service1Soap" name="Service1Soap"/>
</client>
</system.serviceModel>
<startup><supportedRuntime version="v2.0.50727"/></startup></configuration>
wenn die anwendung, die in diesem Fall den uploader dienst benutzt ausgeliefert wird, müssen wir also manuell die IP 192.168.100.1 durch unsere externe ersetzen.
Es wäre also für uns eleganter, wir könnten den webdienst über seine öffentliche ip ansprechen und die config würde sofort richtig geschrieben.
Das Problem betrifft auch Handys, die sich via wlan in unserem Netzwerk anmelden und dann die Webanwendungen verwenden wollen die sonst öffentlich zu erreichen sind.
Man muss im Handy also dann die Adressen manuell auf lokal umstellen, was noch umständlicher ist.
@aqui - siehte mal...
[OT]
"wanem" auf den Namen muß man auch erstmal kommen - der ist viel zu einfach - obwohl ich den mittlerweile benutze fiel mir spontan trotzdem nur der ungepflegte Nistnet ein.....
Ich werd alt....
[/OT]
Gruß
[OT]
"wanem" auf den Namen muß man auch erstmal kommen - der ist viel zu einfach - obwohl ich den mittlerweile benutze fiel mir spontan trotzdem nur der ungepflegte Nistnet ein.....
Ich werd alt....
[/OT]
Gruß
?
Hoffentlich werd ich nicht so alt, wie ich mich gerade fühle....
Man muss im Handy also dann die Adressen manuell auf lokal umstellen, was noch umständlicher ist.
- noch umständlicher als deinen unformatierten quellcode zu lesen?
- Wer heute Werkzeuge baut, die feste Pfade - komplette URis schreibt - der hat was verpasst....
- und dann auch noch die IP - für was gibt es DNS?
Hoffentlich werd ich nicht so alt, wie ich mich gerade fühle....
Vergiss das... damit rennst du in das o.a. geschichlderte Hairpin NAT Problem !
Wie bereits mehrfach gesagt...es sei denn dein Linksys supportet Hairpin NAT ?!
Check das und dann weisst du sofort ob es klappt oder nicht ! Ansonsten gilt was Kollege Timo bereits gesagt hat.
Wie bereits mehrfach gesagt...es sei denn dein Linksys supportet Hairpin NAT ?!
Check das und dann weisst du sofort ob es klappt oder nicht ! Ansonsten gilt was Kollege Timo bereits gesagt hat.
Zitat von @boehme123:
<endpoint address="http://192.168.100.1:80/dta/uploader1.asmx" binding="basicHttpBinding"
<endpoint address="http://192.168.100.1:80/dta/uploader1.asmx" binding="basicHttpBinding"
Was hindert Euch daran, hier einen Namen anstatt eienr Ip zu benutzen?
Vielen Dank erstmal für die Anregungen und Tipps.
Momentan versuchen mit DynDNS und einer Hostdatei das Problem zu lösen. Wir werden euch dann nochmal genau mitteilen, wie wir vorgegangen sind und ob wir Erfolg hatten.
@timobeil sorry für die schlechte Formatierung und wie gesagt, es handelt sich um automatisch von VS2008 erstellte config Dateien, die beim Verweis auf Webservices erstellt werden.
Haben uns noch nicht allzuviel mit webservices und der Einbindung in Clientanwendungen beschäftigt, es ging im konkreten Beispiel darum, eine schnelle und funktionale Lösung für uploads zu schaffen. FTP funktionierte nicht überall (Firewall / Portsperren) und erschien uns auch nicht zeitgemäß.
Momentan versuchen mit DynDNS und einer Hostdatei das Problem zu lösen. Wir werden euch dann nochmal genau mitteilen, wie wir vorgegangen sind und ob wir Erfolg hatten.
@timobeil sorry für die schlechte Formatierung und wie gesagt, es handelt sich um automatisch von VS2008 erstellte config Dateien, die beim Verweis auf Webservices erstellt werden.
Haben uns noch nicht allzuviel mit webservices und der Einbindung in Clientanwendungen beschäftigt, es ging im konkreten Beispiel darum, eine schnelle und funktionale Lösung für uploads zu schaffen. FTP funktionierte nicht überall (Firewall / Portsperren) und erschien uns auch nicht zeitgemäß.
Haben bei uns quick@dirty gelöst - ohne Rücksicht auf Handys, die zwischen öffentl. und privaten Netzen wechseln:
- DynDNS Adresse eingerichtet, gefolgt von der Einrichtung im Router
- Ändern der Hostdatei %windir%/system32/drivers/etc/hosts
Dort Eintrag hinzugefügt: private IP des Webservers gefolgt von dyndns-hostnamen ( 192.168.1.100 x-x-x.dyndns.org)
dann ipconfig /flushdns in Konsole.
Das muss natürlich auf jedem Entwicklungsrechner wo getestet werden soll passieren, also wie gesagt erstmal nicht die endgültige Lösung.....
- DynDNS Adresse eingerichtet, gefolgt von der Einrichtung im Router
- Ändern der Hostdatei %windir%/system32/drivers/etc/hosts
Dort Eintrag hinzugefügt: private IP des Webservers gefolgt von dyndns-hostnamen ( 192.168.1.100 x-x-x.dyndns.org)
dann ipconfig /flushdns in Konsole.
Das muss natürlich auf jedem Entwicklungsrechner wo getestet werden soll passieren, also wie gesagt erstmal nicht die endgültige Lösung.....
Die Idee zählt so zu den dümmsten, die man in der Entwicklung haben kann, glaub mir.
Das endet immer damit, dass irgendwan eure Testsoftware mal auf die Produktionsdaten zugreift und die schön platt macht.
Alles schon gehabt.
Das endet immer damit, dass irgendwan eure Testsoftware mal auf die Produktionsdaten zugreift und die schön platt macht.
Alles schon gehabt.
