Zum Inhalt wechseln


Foto

TCP-Portweiterleitungen in WS2012R2 einrichten

Windows Server 2012 R2

  • Bitte melde dich an um zu Antworten
19 Antworten in diesem Thema

#1 LigH

LigH

    Newbie

  • 45 Beiträge

 

Geschrieben 23. August 2016 - 09:31

Um auf spezielle Geräte in unserem Netzwerk, die einen simplen Webserver integriert haben, über das Internet zugreifen zu können, müssen TCP-Portweiterleitungen eingerichtet werden, da dieser Anbieter keinen eigenen Dienst für eine von innen vorbereitete Verbindung anbietet. Mit ein wenig Hilfe unseres Internetproviders wurde bereits eine Gruppe von Weiterleitungen in einem Mikrotik-Routerboard eingerichtet, und mit Hilfe von Wireshark auf unserem Intranet-Server (WS 2012 R2) ließ sich auch nachweisen, dass Anfragen aus dem Internet an eine Dynamic-DNS-Adresse mit Port wie gewünscht über das Routerboard geleitet werden und mit gleichem Port am Server ankommen.

http://dynamic.dns:8171 => 192.168.88.1 (Router) => 192.168.88.252:8171 (Windows-Server, "Internet"-Interface)

Was bisher jedoch nicht funktioniert, ist die fortgesetzte Weiterleitung der TCP/HTTP-Anfrage über den Server an das jeweilige Gerät im Intranet (192.168.0.[170..179]).

 

http://dynamic.dns:8171 => 192.168.88.1 => 192.168.88.252:8171 -X- 192.168.0.1 (Windows-Server, "Intranet"-Interface) => 192.168.0.171:80

 

Bisher habe ich zwei Möglichkeiten versucht. Zum einen wurde in einem Beitrag, den ich im Internet entdeckt habe, die Verwendung der NetShell empfohlen, weil dies auch ohne Neustart des Servers sofort funktionieren solle:

for /L %%a in (170,1,179) do netsh interface portproxy add v4tov4 listenport=8%%a listenaddress=192.168.88.252 connectport=80 connectaddress=192.168.0.%%a
netsh interface portproxy show all

Ergebnis an der Konsole:

Abfragen auf ipv4:             Verbinden mit ipv4:

Adresse         Anschluss   Adresse         Anschluss
--------------- ----------  --------------- ----------
192.168.88.252  8170        192.168.0.170   80
192.168.88.252  8171        192.168.0.171   80
192.168.88.252  8172        192.168.0.172   80
192.168.88.252  8173        192.168.0.173   80
192.168.88.252  8174        192.168.0.174   80
192.168.88.252  8175        192.168.0.175   80
192.168.88.252  8176        192.168.0.176   80
192.168.88.252  8177        192.168.0.177   80
192.168.88.252  8178        192.168.0.178   80
192.168.88.252  8179        192.168.0.179   80

Ergebnis im Webbrowser: Verbindung fehlgeschlagen

 

Also diese Variante zurückgenommen ("netsh interface portproxy delete v4tov4 listenport=8%%a listenaddress=192.168.88.252" in for) und noch mal in der Server-Verwaltung manuell 10 Portweiterleitungen eingetragen:

 

Routing und RAS » IPv4 » NAT » Internet » Eigenschaften » Dienste und Ports » Hinzufügen: TCP; Eingehender Port = 817#; Private Adresse = 192.168.0.17#; Ausgehender Port = 80

 

Dann auch den Server neu gestartet (waren eh gerade Updates zu installieren).

 

Ergebnis im Webbrowser: Verbindung fehlgeschlagen

 

In beiden Fällen habe ich versucht, den Traffic beider Netzwerkschnittstellen gleichzeitig mit Hilfe von Wireshark 2.0.5 zu überwachen, und dabei festgestellt, dass bei einer Anfrage am "Intranet"-Interface gar kein Traffic aufkommt. Es wird also gar keine Weiterleitung durchgeführt, der Verbindungsversuch wird anscheinend abgewiesen. Leider kenne ich mich mit Netzwerkprotokollen nicht gut genug aus, um hier etwas interpretieren zu können, aber eine pcap-Datei könnte ich bereitstellen.

 

Vielleicht hat aber schon ohne diese jemand eine Idee, was ich vielleicht vergessen oder vertauscht habe.


Bearbeitet von LigH, 23. August 2016 - 09:32.


#2 testperson

testperson

    Board Veteran

  • 4.511 Beiträge

 

Geschrieben 23. August 2016 - 09:58

Hi,

 

"spezielle" Geräte mit "simplem" Webserver aus dem Internet erreichbar machen? Werden diese Geräte auch entsprechend gepatched und die Webserver sind entsprechend gesichert? Port 80 ist ja schonmal Klartext.

Pauschal würde ich das alles für keine gute Idee halten.

 

Generell wäre es ein evtl. sinnvollerer Ansatz, den 2012 R2 Server als Reverse Proxy zu nutzen (oder eine entsprechende Appliance, die das evtl. besser kann).

 

Gruß

Jan

 

P.S.: Und generell würde ich es auch immer vermeiden wollen, einen Windows Server als Router zu nutzen.


  • NorbertFe gefällt das
Good morning, that's a nice TNETENNBA!

#3 DocData

DocData

    Board Veteran

  • 1.272 Beiträge

 

Geschrieben 23. August 2016 - 10:16

Haben diese Geräte ein Default Gateway gesetzt und kommen sie ins Internet?

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#4 LigH

LigH

    Newbie

  • 45 Beiträge

 

Geschrieben 23. August 2016 - 10:59

Darüber streiten, ob das eine gute Idee ist, kann man ja mit der Firmenleitung... letztendlich muss man als Angestellter aber deren Wünsche erfüllen.

 

Die Geräte sind korrekt konfiguriert, soweit ich beurteilen kann, haben NTP-Verbindung zum Stellen der Uhr und Zugriff auf Firmware-Updates, Gateway sollte also stimmen (192.168.0.1). Von innen nach außen klappt es also.

 

Im Intranet funktioniert der Zugriff per Webbrowser mit HTTP-Auth; ob HTTPS möglich ist, lässt sich immer noch klären, wenn erstmal das Routing klappt. Vielleicht brauche ich zusätzlich zur Portweiterleitung auch noch Firewall-Ausnahmen?


Bearbeitet von LigH, 23. August 2016 - 11:01.


#5 LigH

LigH

    Newbie

  • 45 Beiträge

 

Geschrieben 24. August 2016 - 06:24

Firewall-Ausnahmen wurden hinzugefügt. Nützte aber auch nichts.



#6 LigH

LigH

    Newbie

  • 45 Beiträge

 

Geschrieben 25. August 2016 - 07:07

Der IP-Hilfsdienst läuft auch (älterer Hinweis).



#7 LigH

LigH

    Newbie

  • 45 Beiträge

 

Geschrieben 29. August 2016 - 07:25

Auch das Lauschen von beliebiger Adresse (netsh ... listenaddress=0.0.0.0 ...) half nicht.



#8 LigH

LigH

    Newbie

  • 45 Beiträge

 

Geschrieben 11. Oktober 2016 - 09:07

Immer noch keine Lösung in Sicht...

 

Mittlerweile hat jemand den Verdacht geäußert, dass vielleicht der Windows Server explizit nicht auf interne Ports 80 weiterleiten mag, aus Sicherheitsgründen. Also habe ich mal in den Geräten den HTTP-Port auf 8080 konfiguriert.

 

Auch damit keine Durchleitung.

 

Bleibt mir nur weiter zu hoffen, dass jemandem ein wirklich grundsätzlicher Fehler auffällt. Wie schon geschrieben, Netzwerkprotokolle aus WireShark kann ich gern bereitstellen.



#9 DocData

DocData

    Board Veteran

  • 1.272 Beiträge

 

Geschrieben 11. Oktober 2016 - 09:13   Lösung

Kauf doch bitte Dienstleistung ein. Ein Forum ist nicht dazu da, Dienstleistern Arbeit abzunehmen.

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#10 testperson

testperson

    Board Veteran

  • 4.511 Beiträge

 

Geschrieben 11. Oktober 2016 - 09:25

Nunja, ich versuche es nochmal mit: https://technet.micr...4(v=ws.11).aspx oder ggfs. einfach einen Netscaler VPX Express (oder sonstige Appliance / Reverse Proxy) als Content Switch davor.

Oder einfach X-Monate weiter basteln..


Good morning, that's a nice TNETENNBA!

#11 LigH

LigH

    Newbie

  • 45 Beiträge

 

Geschrieben 11. Oktober 2016 - 09:25

@ DocData: In der Altmark ist die Auswahl an ebensolchen Spezialisten aber arg dünn. Und der eine, den ich mittelbar finden konnte, "muss sich erstmal darüber schlau machen" ... Darfst mir aber gern jemanden in dieser Region empfehlen.

 

@ testperson: Nun ja, les ich mal, danke...


Bearbeitet von LigH, 11. Oktober 2016 - 09:27.


#12 DocData

DocData

    Board Veteran

  • 1.272 Beiträge

 

Geschrieben 11. Oktober 2016 - 11:05

Warum muss der denn aus der Altmark kommen?!

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#13 LigH

LigH

    Newbie

  • 45 Beiträge

 

Geschrieben 11. Oktober 2016 - 11:12

Die Anfahrtspreise steigen sicher auch mit der Entfernung, oder?



#14 mba

mba

    Board Veteran

  • 862 Beiträge

 

Geschrieben 11. Oktober 2016 - 11:21

Vor allem bei Fernzugriff ;-)


  • DocData gefällt das

#15 DocData

DocData

    Board Veteran

  • 1.272 Beiträge

 

Geschrieben 11. Oktober 2016 - 11:56

Die Anfahrtspreise steigen sicher auch mit der Entfernung, oder?


Ja willst du das dein Problem gelöst wird, oder willst du sparen?
  • NorbertFe gefällt das

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...