stonedzero
Goto Top

Windows 2003 am Netgear WGR614 v7. Datei- und Druckerfreigabe von extern ermöglichen (ging schonmal)

Ich kann von Extern nicht auf freigegebene Dateiressourcen und Drucker des Servers zugreifen, obwohl ich aber eine Verbindung per FTP und Remote Desktop bekomme. Das Kuriose ist, dass es bis vor circa einer Woche noch ging.

Ich habe im Büro einen Server mit Windows 2003 stehen. Auf ihm liegen alle relevanten Dateien, auf die alle Mitarbeiter von überall aus Zugriff haben sollten. Außerdem sind am Server Drucker angeschlossen, die ebenfalls freigegeben sind.

Der Router im Büro ist ein Netgear WGR614 v7. Der Router ist so konfiguriert, dass er alle Ports an den Server, per Port Forwarding und per DMZ Einstellung, weiterleitet bzw. weiterleiten sollte. Das ist seit über einem Jahr so gut gegangen.

Der Server hat zwei Netzwerkkarten, die per Netzwerkbrücke verbunden sind. An der ersten NIC hängt der besagte Netgear WGR614 v7, der ebenfalls das Tor ins Internet bereitstellt, und an der anderen NIC hängt ein weiterer Netgear Access Point.

Bis vor circa einer Woche konnte ich von Extern über die IP-Adresse des Büro-DSL-Anschlusses auf die Netzlaufwerke und -drucker zugreifen. Am System wurde in diese Richtung bewusst nichts geändert. Nach wie vor kann ich aber von Extern auf den Server per Remote Desktop und FTP zugreifen, was mich so verwirrt.

Die Windows-Firewall des Servers ist momentan deaktiviert. Sie war aktiv, als es noch funktionierte, zu Testzwecken hab ich sie nun aber ausgeschalten. Gibt es da noch irgendwas, was man deaktivieren/einstellen könnte?

Ich tippe fast, dass es am Router liegt, dass ich nicht auf die Freigaben zugreifen kann. Wenn ich im Büro bin, funktioniert der Zugriff über die interne und externe IP-Adresse problemlos. Wenn ich aber zum Beispiel zu Hause bin, funktioniert es nicht.

Einen Hausfrauen Reset habe ich mit Router und Server schon probiert, beides ohne Änderung am Zustand.

Hat irgendjemand eine Ahnung?
Wenn es noch unbekannte Infos gibt, die zur Einschätzung des Problems hilfreich wären, dann einfach raus damit.
Ich freue mich über jede Antwort!

Viele Grüße,
stonedzero

UPDATE 23:12
Ich habe nun zwei Portscan auf TCP gemacht. Folgendes Resultat:

Von intern auf die externe IP-Adresse:
TCP: 21-ftp
TCP: 135-epmap
TCP: 139-netbios-ssn
TCP: 445-microsoft-ds
TCP: 1025-blackjack
TCP: 3389-ms-wbt-server

Alles wie gewünscht offen.

Von extern auf die externe IP-Adresse:
TCP: 21-ftp

Angeblich ist nur FTP offen, die Remote Desktop Verbindung geht aber auch. Datei- und Druckerfreigabe kann nicht genutzt werden.

Im Router ist ein DMZ-Standardserver eingetragen, zusätzlich habe ich die Portweiterleitung von Port 1 bis 65534 auf die interne Server-IP eingestellt. Wenn man den Router intern auf der externen IP anspricht, macht er auch, was er soll, nur extern nicht.

Da Port 21 offen ist, habe ich mir das zu Nutzen gemacht und mal geloggt.

Von intern über die externe IP sieht der log so aus:
12.12.2010 23:03:54 - (not logged in) (EXTERNE_IP)

Von extern über die externe IP sieht es so aus:
12.12.2010 23:09:14 - (not logged in) (ANDERE_EXTERNE_IP)>

Anruf bei der Telekom ist schon erfolgt, ob kürzlich Ports gesperrt wurden. Grund dafür sollte es eigentlich keinen geben, aber sicher ist sicher. Mir konnte noch niemand Auskunft geben, da heute Abend die Kollegen, die das rausfinden können, nicht da sind.

UPDATE 23:57
Ich habe nun mit der Windows-Firewall rumgespielt und mal die Zugriffe protokolliert. Der Bereich für die Datei- und Druckfreigabe ist aufs komplette Internet konfiguriert, also hieran liegt es nicht. Ich komm aus dem Log nicht so ganz raus, aber es scheint, als würde irgendwas am Server ankommen. Wenn die Windows-Firewall deaktiviert ist, müsste der Server doch offen stehen wie ein Scheunentor, oder?!

Ein weiteres Indiz dafür, dass irgendwas ankommt. Wenn ich per Windows 7 den Zugriff versuche, kommt nach der Diagnose folgende Meldung:
"Datei- und Druckerfreigaberessource (EXTERNE_IP) ist online, antwortet jedoch nicht auf Verbindungsversuche."

Klingt gut, nur wie ändern?

Bis vor einer Woche hat das Alles noch tadellos funktioniert. Wie gesagt, ich habe seit dem keine bewussten Änderungen am Netzwerk vorgenommen. Das gleiche Problem hatte ich vor einem Jahr schonmal, meine ich. Ich habe den Server neuinstalliert, weiß aber nicht mehr, ob es das Problem gelöst hat.

Content-Key: 156835

Url: https://administrator.de/contentid/156835

Ausgedruckt am: 29.03.2024 um 00:03 Uhr

Mitglied: aqui
aqui 13.12.2010, aktualisiert am 18.10.2012 um 18:44:23 Uhr
Goto Top
"Der Router ist so konfiguriert, dass er alle Ports an den Server, per Port Forwarding und per DMZ Einstellung, weiterleitet bzw. weiterleiten sollte. Das ist seit über einem Jahr so gut gegangen."
Sehr gefährlich und eigentlich ein absolutes No Go in so einem Szenario. Damit exponierst du den Server direkt im Internet. Nur komplette Laien machen sowas mit einem MS Betriebssystem. Man kann dir nur dringenst davon abraten und wirklich nur die Ports am Router per Port Forwarding freizugeben die du auch wirklich benutzt !

..."Der Server hat zwei Netzwerkkarten, die per Netzwerkbrücke verbunden sind. "
Auch kein gutes Netzdesign was man besser vermeiden sollte ! Bridging belastet den Server mit Broad- und Multicasts aus beiden Segmenten und führt zu Performanceeinbußen. Auch bei Netzwerkdiensten muss man hier genau aufpassen immer das Promärinterface zu benutzen m nicht Schiffbruch zu erleiden.
Besser ist man löst es mit einem sauber segmentierten Setup wie es hier beschrieben ist:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router

Der Router muss lediglich Port UDP 1194 per Port Forwarding auf die interne IP Adresse des Servers forwarden...mehr nicht. Das reicht vollständig bei OpenVPN wenn OpenVPN auf dem Server rennt. Deine DMZ Konfig beim NetGear ist hier eher kontraproduktiv.
Wenn der OpenVPN Tunnel zustandekommt dann ist das auch absolut korrekt und fehlerfrei.
Es sollte dir klar sein das der Server IMMER eine statische IP Adresse im lokalen Netzwerk haben muss in so eine Konstellation (und auch generell haben Server statische IPs !) damit ggf. die Dynamik von DHCP das Port Forwarding nicht ins Leere laufen lassen kann !!
Ein Router kann logischerweise NICHT in einen verschlüsselten VPN Tunnel sehen (OpenVPN) der durch ihn hindurchgeht. Folglich kann er auch NICHT den Traffic irgendwie beeinflussen der im Tunnel transportiert wird !!
Deine Annahme das der Router da was filtert ist also Unsinn. Wenn...dann kann nur die Firewall filtern die auf dem Server liegt sofern dein OpenVPN Server auf dem Server selber betrieben wird.
Leider sagst du in diesem Followup Thread rein gar nix über das verwendete VPN Protokoll und Setup was eine qualifizierte Antwort auf dein Problem noch schwieriger macht und eher an Kristallkugel schauen rankommt. face-sad Die OpenVPN Annahme ist also nur geraten aus deinen vorherigen Äußerungen...
Verbindung per OpenVPN. Internet, FTP etc. klappt, Netzlaufwerke nicht

Direkt über das Internet auf freigegebene Datei und Druckerfreigaben zuzugreifen zu wollen ist völliger Blödsinn es sei denn dir sind deine Daten gar nichts wert. Damit existiert keinerlei Sicherheit mehr im Zugriff. Mal ganz abgesehen von der Tatsache das Windows CIFS/SMB gar nicht für den Internet Zugriff gemacht sind und funktionieren.
Ports wie
TCP: 135-epmap
TCP: 139-netbios-ssn
TCP: 445-microsoft-ds

Auf einem Router per PFW freizugeben ist eine sicherheitstechnische Katastrophe und ein absolutes NoGo ! Mal abgesehen das sie die NAT FW gar nicht richtig überwinden können und Broadcasts am Provider Router so oder so gelöscht werden.
Zudem verwirrt es das ganze Szenario, denn nun ist noch weniger klar was du eigentlich willst ?? VPN Zugang oder simples Fummeln mit Port Forwrading ?!
Eine Kombination von beidem ist NICHT möglich !
Auch ein testen des Zugangs über das DSL Interface von intern ist nicht möglich und scheitert sofort, da der NetGear (wie bei NetGear leider üblich) kein DNS Hairpinning oder generell Hairpinnig supportet. Vergiss diesen test also gleich....
Schmeiss also am besten den NetGear raus, ersetz ihn durch einen Draytek und richte dir dort auf dem Router ein PPTP_VPN ein wenn du was von der Stange willst.
Ansonsten gibt es zuhauf Anleitungen hier zum sauberen Aufsetzen von VPNs:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
VPNs mit DD-WRT, pFsense oder OPNsense auf Basis von PPTP
usw. usw.
Empfehlenswert ist auch das Lesen von den minimalen Anforderungen an ein sauberes VPN IP Design:
VPNs einrichten mit PPTP
das essentiall wichtig ist für die Funktion eines VPN !!
Wenn du wirklich OpenVPN nutzt wie im Ursprungsthread beschrieben macht es Sinn hier einmal die Server Konfig Datei zu posten um ggf. Probleme aufdecken zu können.
Deine Anforderung ist eine billige und einfache Standardanforderung für einen VPN Zugang die mit dem richtigen Netzwerkdesign und korrekter IP Adressierung in 20 Minuten sauber und stabil zum Fliegen kommt....
Dein Design per Port Forwarding alles erledigen zu wollen ist von vorn herein zum Scheitern verurteilt, da es aus protokolltechnischen Gründen schon gar nicht geht.
Von den katastrophalen Auswirkungen auf die Server- und Daten Sicherheit mal ganz abgesehen !
Zeugt eher davon als ob ein völliger Laie mit Trial and Error und Klicki Bunti versucht sich einen remoten Zugang zusammenzufrickeln...sorry !
Mitglied: stonedzero
stonedzero 13.12.2010 um 13:09:15 Uhr
Goto Top
Zitat von @aqui:
Sehr gefährlich und eigentlich ein absolutes No Go in so einem Szenario. Damit exponierst du den Server direkt im Internet.
Nur komplette Laien machen sowas mit einem MS Betriebssystem. Man kann dir nur dringenst davon abraten und wirklich nur die Ports
am Router per Port Forwarding freizugeben die du auch wirklich benutzt !
Klar ist das ein großes Sicherheitsrisiko. Ich war die Nacht nochmal im Büro und habe die Konfig diesbezüglich komplett umgestellt. Jetzt sind nur noch die Ports offen, die ich auch wirklich brauche. Keine DMZ-Einstellungen mehr.

Zitat von @aqui:
Auch kein gutes Netzdesign was man besser vermeiden sollte ! Bridging belastet den Server mit Broad- und Multicasts aus beiden
Segmenten und führt zu Performanceeinbußen. Auch bei Netzwerkdiensten muss man hier genau aufpassen immer das
Promärinterface zu benutzen m nicht Schiffbruch zu erleiden.
Die Bridge habe ich gestern Nacht auch entfernt und den Access Point anderweitig verbaut.

Zitat von @aqui:
Der Router muss lediglich Port UDP 1194 per Port Forwarding auf die interne IP Adresse des Servers forwarden...mehr nicht. Das
reicht vollständig bei OpenVPN wenn OpenVPN auf dem Server rennt. Deine DMZ Konfig beim NetGear ist hier eher
kontraproduktiv.
Auf dem Server läuft der VPN-Server nicht. Der läuft auf einem Server im Rechenzentrum. Auf die Ressourcen im Büro sollte ich auch zugreifen können, wenn ich mit dem VPN im Rechenzentrum verbunden bin, weswegen ein weiterer VPN-Server im Büro nicht geht.

Zitat von @aqui:
Es sollte dir klar sein das der Server IMMER eine statische IP Adresse im lokalen Netzwerk haben muss in so eine Konstellation
(und auch generell haben Server statische IPs !) damit ggf. die Dynamik von DHCP das Port Forwarding nicht ins Leere laufen lassen
kann !!
Der Server hat eine statische interne IP-Adresse für jede NIC. Also davon habe ich schon Ahnung.

Zitat von @aqui:
Leider sagst du in diesem Followup Thread rein gar nix über das verwendete VPN Protokoll und Setup was eine qualifizierte
Antwort auf dein Problem noch schwieriger macht und eher an Kristallkugel schauen rankommt. face-sad Die OpenVPN Annahme ist also nur
geraten aus deinen vorherigen Äußerungen...
Wie gesagt, um den VPN geht es hier gar nicht.

Zitat von @aqui:
Direkt über das Internet auf freigegebene Datei und Druckerfreigaben zuzugreifen zu wollen ist völliger Blödsinn es
sei denn dir sind deine Daten gar nichts wert. Damit existiert keinerlei Sicherheit mehr im Zugriff. Mal ganz abgesehen von der
Tatsache das Windows CIFS/SMB gar nicht für den Internet Zugriff gemacht sind und funktionieren.
Also funktioniert hat es bis circa vor einer Woche. Ich konnte von extern über einen freigegebenen Drucker drucken und auf freigebene Ordner zugreifen. Alles ohne VPN, sondern nur nach Eingabe des Pfads \\BÖROIP\Freigabe und Benutzerkennung. (Mehr dazu siehe weiter unten.) Nun die Frage: Warum hat es denn funktioniert?

Zitat von @aqui:
Deine Anforderung ist eine billige und einfache Standardanforderung für einen VPN Zugang die mit dem richtigen Netzwerkdesign
und korrekter IP Adressierung in 20 Minuten sauber und stabil zum Fliegen kommt....
Dein Design per Port Forwarding alles erledigen zu wollen ist von vorn herein zum Scheitern verurteilt, da es aus
protokolltechnischen Gründen schon gar nicht geht.
siehe oben, es hat definitiv funktioniert. Über den Sinn und Unsinn kann man allerdings streiten. Wohl war mir bei der Sache auch nie, sondern diese Konfig hat eher einen Schmerz im Po verursacht, aber ich muss halt um die VPN-Server Geschichte auf dem Büro-Server drumherrum kommen, weil ich zu einem anderen VPN verbinden muss.

Zitat von @aqui:
Von den katastrophalen Auswirkungen auf die Server- und Daten Sicherheit mal ganz abgesehen !
Um die Sicherheit mache ich mir natürlich auch Sorgen. Die Freigabeberechtigungen sind sehr streng gesetzt. Zudem werden keine kritischen Daten auf dem Server gespeichert. In wie weit kann ich auf die Anmeldeverfahren und deren Sicherheit im SMB Bereich zählen?

Eine Idee wäre, dass ich auf die Datei- und Druckerfreigabe aus dem ungesicherten Internet verzichte; einen einfachen VPN-Server mit IP-Sec auf dem Büro-Server einrichte, sodass ich eben nur im Notfall mit dem VPN verbinde, und per SMB auf die Dateien zugreifen kann. Ansonsten bleibt mir ja noch der FTP-Server.

Oder eine andere Idee gäbe es auch noch. Auf dem Büro-Server ist ebenfalls ein VPN-Client in das VPN des Rechenzentrums eingerichtet, läuft aber nicht eben wegen des damit verbundenen Sicherheitsrisiko (sollte jemand den Server knacken, könnte er auch ins interne Netz des Rechenzentrums). Ich müsste den Client nur konfigurieren, wie die anderen. Wenn man nun die Sicherheit des Servers wieder herstellt (Port-Forward, DMZ aus etc.), sodass man diese kritische Anwendung starten kann, könnte man über die Client-to-Client Funktion auf den Server im Büro zugreifen, sobald man im VPN des Rechenzentrums ist, dann eben über die statische virtuelle Client-IP, die ich dem OpenVPN-Server im Rechenzentrum beigebracht habe.

Zitat von @aqui:
Zeugt eher davon als ob ein völliger Laie mit Trial and Error und Klicki Bunti versucht sich einen remoten Zugang
zusammenzufrickeln...sorry !
Der hat gesessen, aber es kommt sicherlich so rüber, da hast du recht. Ich sag hier lieber nicht, dass ich ein sehr informatiklastiges Studium neben meiner Arbeit betreibe, und im aktuellen Semester Vertiefung für Netzwerk-Topologie habe. Es klingt sicher seltsam, aber eigentlich weiß ich und hab Ahnung von dem, was ich mache. face-wink

Danke für die Antwort. Vielleicht kannst du nochmal auf meine Ansätze eingehen.