2012 R2; Problem bei Remoteeinrichtung

Ryoukou

Enthusiast
Thread Starter
Mitglied seit
19.09.2004
Beiträge
4.278
Ort
Fürth
Hallo!

Ich habe folgendes Problem:

Ich wollte bei meinem Homeserver die Remoteverbindung einrichten. Alle anderen Hürden wie Portfreigabe etc. habe ich schon erfolgreich gemeistert, es scheitert jedoch an einer Kleinigkeit:

Der Einrichtungsassistent zeigt an dass keine Internetverbindung verfügbar wäre, obwohl ich mit dem Server schon fröhlich im Internet unterwegs war. Hat jemand eine Idee woran das liegen könnte? Inet Verbindung erfolgt über eine Fritzbox 7360.

Danke!
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Remote Ports weitergeleitet im Router ? Upnp aktivieren oder per Hand die Ports auf den Server weiterleiten.
 
ports habe ich manuell weitergeleitet, upnp wollte nicht klappen. er zeigt aber trotzdem noch an dass er nicht mit dem Internet verbunden ist.
 
Hmm den Mist hatte ich auch einmal. Hast du eine kostenlose domain von Microsoft genommen oder eine andere ? Ich hatte die Microsoft version, hab die dann gelöscht und irgendwann ging es dann. Allerdings auch nur über Upnp. An einem anderen Standort ging es sofort über die Fritzbox. Port 443 (TCP) und 4125 (TCP) sind weiterzuleiten. Evtl. noch den RDP Port 3389 wenn du den nicht geändert hast.

Hast du eine Firewall aktiv die evtl. die Ports blockt? Im Router die Firewall aktiv ? Ich habe lange keinen WHS mehr am laufen und weiss daher nicht mehr genau wie ich das damals zum laufen gebracht habe.
 
Zuletzt bearbeitet:
Ich hab die Domain von MS genommen (remoteaccessweb.com). Port 3389 ist noch nicht frei, das teste ich auch nochmal, danke.

Firewalls verwende ich nur die Windows-eigenen.
 
Was mir gerade einfällt, falls du eine Fritzbox hast und die Fernkonfiguration freigeschaltet hast, musst du da den Port ändern. Die nutzt den selben Port wie der remoteacess Port 443
 
Ich setzte morgen inner vm mal kurz nen 2012 r2 auf und schaue ob es geht.
 
So Test beendet. Server 2012 R2 Essentials in einer VM (VMware 10). Die DNS wurde auf meinen Router verlinkt. Evtl. ist da schon bei Dir der Fehler?? 2 DNS in einer Netzwerkgruppe gehen nicht, entweder macht der Router die DNS Anfrage oder der Server. ip.JPG

Ich habe diese Ports im Router weitergeleitet (VM hatte natürlich eine feste IP) freigaben.jpg erst wollte er nicht, dann habe ich noch die Ports 4125 und 443 in der Firewall (VM) Freigegeben (Eingehende Regel) dann ging es. Danach habe ich die Freigabe (Firewall) wieder rausgenommen einmal repariert und nun funktioniert es wie es soll.

Ich hoffe das hilft dir.





PS: Upnp im Router war aktiv hat aber den Server nicht interessiert ^^

PS:2 Als Alternative kannst du dir ja einmal TSplus anschauen. Das habe ich bei einem Kunden im Einsatz und der ist sehr zufrieden. Du hast den Vorteil das du kein Server brauchst sondern das Windows OS deiner Wahl nutzen kannst. Als Terminalserver ist das Klasse.
 
Zuletzt bearbeitet:
Danke dass du dir die Arbeit gemacht hast. Muss ich später mal in Ruhe testen. Ich brauche die Remoteverbindung hauptsächlich um die verfluchte Clientsicherung auf all meinen Rechnern installieren zu können :/
 
Gerne, sag dann bescheid. Die VM liegt noch auf der Platte falls du noch was testen willst.
 
So, hier mal mein Setup, inkl. Fehlermeldungen.

Als DNS Server ist der Homeserver eingerichtet, anders bekomme ich keine Verbindung ins Inet. Steh diesmal gewaltig auf der Leitung.
 

Anhänge

  • DNS.jpg
    DNS.jpg
    35,5 KB · Aufrufe: 37
  • HW Konfig.jpg
    HW Konfig.jpg
    11,5 KB · Aufrufe: 47
  • Ports.jpg
    Ports.jpg
    42,8 KB · Aufrufe: 55
  • Fehlermeldung.jpg
    Fehlermeldung.jpg
    55,8 KB · Aufrufe: 47
An der Friitzbox ist der DNS aus ? Gebe dem DNS mal nicht die Lokal Ip sondern die feste IP vom Server.

Vergebe dem Server eine feste IP, eine Dynamische geht glaube ich nicht.

Welche 2012 version hast du am laufen ? Nur der Essentials richtet den DNS Host gleich richtig ein, die normalen Varianten nicht.


Schau da mal rein http://www.windowspro.de/wolfgang-s...12-essentials-vpn-remotewebzugriff-einrichten und da http://www.youtube.com/watch?v=aXBiV3pQrLg


Hast du überhaupt Internetzugriff über die Virtuelle Netzwerkarte wenn du die Fritzbox den DNS machen lässt? Nicht das du am Ende nur eine falsche Konfiguration auf der Virtuellen Netzwerkkarte hast.
 
Zuletzt bearbeitet:
2012 R2 Essentials

und ja, über die virtuelle NW-Karte hab ich bisher Inetzugang.
 
Hmmmmmm dann siehste mich jetzt auch etwas ratlos schauen. Ich habe mich eine weile damit nicht mehr beschäftigt das rächt sich jetzt. Eigentlich müsste das ja so gehen.. Feste IP auf dem Server, DNS auf die feste IP gelegt, portweiterleitungen auf die feste IP vom Server gelegt.

Was du noch machen könntest..... Lösche die V Karte und lege alles auf die Physikalische NW Karte , ganz ohne eine Virtuelle ersteinmal. So könnte man evtl. Fehler ausschließen.

Schade das sich keiner von den Luxx Server spezies mal meldet, gibt doch genug hier die richtig Plan davon haben.
 
Also normalerweise mache ich bei sowas immer :

Server feste IP

DNS lokaler Server (wenn AD + DNS aktiv ist)

Im Windows DNS eine Weiterleitung auf den Router einrichten dann sollte das eigentlich gehen.
 
Nur mal so als Info nebenbei, den TCP Port 3389 einem PortForwarding von Router direkt zu Server zu unterziehen halte ich für äußerst fragwürdig!
Mit diesem PortForwarding stellt ihr euren Server OHNE jegliche Zugriffskontrolle direkt public ins INet!!! Und das nicht nur mit irgend nem IIS Dienst oder ner Freigabe, sondern mit dem RDP Protokol und somit potentiellem Vollzugriff für jeden Angreifer!!
Klar, oftmals verwendet man privat eine dynamische IP und für nen potentiellen Angreifer ist es somit schwerer. Dennoch macht dieses Feature genau nur dann Sinn, wenn ihr nen DNS Namen nutzt, der auf die eurige IP aufgelöst wird. Somit ist noch mehr Vorsicht geboten. Ist der Name einmal im Netz bekannt, dann kann da potentiell jeder mögliche Angreifer direkt versuchen, sich via RDP vollständigen Zugriff auf den Server zu beschaffen!


Der Sinn hinter dem ganzen Zeug da ist eigentlich, das das ganze via HTTPS getunnelt wird. Oder alternativ, das man eine VPN Einwahl nutzt... Ob das wirklich sinnig ist, das über eine Software von Microsoft zu machen, sei mal völlig dahingestellt und unwesentlich. Fakt ist, ohne anständige Maßnahmen zur Zugriffskontrolle steht der Server im Netz, ohne wenn und aber... Und jeder kann sich daran versuchen. -> bis es mal jemand schafft ;)


Unterm Strich -> TCP 3389 hat dort im PortForwarding NIX!! zu suchen.

PS: auch die 4125 TCP hat dort wohl nix (mehr) zu suchen, wenn ich das richtig in Erinnerung habe, ist das der "Proxy" für den Remote Workplace Web Access alter/älterer SBS Server Versionen. Was sich dann wohl nur auf den SBS 2003 beziehen kann -> da der SBS 2008 schon nur noch via HTTPS tunnelt!
HTTP und somit TCP Port 80 benötigt man ebenso nicht für das Vorhaben...

Was das Thema fehlender INet Zugriff angeht, das wird wohl zu 95% an DNS Problemen liegen.
Entweder man nutzt den DNS des Routers -> was sich weniger empfiehlt bei nem 2012 (R2) Essentials, der ein AD inkl. Userverwaltung mitbringt und damit direkt eine saubere DNS Namensauflösung vorraussetzt oder man nutzt den DNS Server des Servers. Hier ist die 127.0.0.1 nicht falsch (entgegen der obigen Anmerkung), sondern eher sogar richtig. -> nur sollte man dem DNS Server vom Server auch mitteilen, wohin er seine nicht selbst bekannten Domains forwarden soll. Oder wenigstens, das er die Root Server anfragen soll. Alle Clients sollten Netzintern den Server als DNS nutzen. Sinnvollerweise sollte dann der DHCP gleich den DNS Eintrag mit übergeben. Optimalerweise nutzt man auch gliech den DHCP des Servers -> der kommt out of the box mit dem Essentials mit. DHCP des Routers ist entsprechend zu deaktivieren!
 
@fdsonne Danke für deinen ausführlichen Text. Ich hatte früher einmal einen WHS 2011 (Später dann beim 2012 mit übernommen) am laufen und da ging es wie beim Te nicht. Dah hatte ich mir einen Bericht im Internet gesucht, und da wurden diese Ports zum weiterleiten angegeben. Letztendlich ging es dann auch nur mit der Weiterleitung, daher schrieb ich dem Te was ich gemacht hatte. Beim RDP schrieb ich ja dazu, falls er den Port nicht geändert hat.
Das damit natürlich Haus und Hof offen ist, sollte ja allen klar sein.

Hier ist die 127.0.0.1 nicht falsch (entgegen der obigen Anmerkung), sondern eher sogar richtig
Laut dem Bericht damals hatte der Ersteller öfters Probleme mit dem Lokal Port worauf hin er den eigenen Festen genommen hat. Ich sagt ja nicht das der Lokal Port falsch wäre, es geht halt auch der festgelegte.

Ich bin in diesem Bereich allerdings auch eher der Privatuser der sich mal kurz mit beschäftigt hat, und dann nie mehr wieder mangels Gebrauch. Da übernimmt man leider öfters mal was man früher gehört hat auch in aktuelle Szenarien.

Das es beim TE rein am DNS (Zuweisung) liegt würde ich auch sagen.
 
Zuletzt bearbeitet:
Ich kenn den WHS 2011 nicht... Keine Ahnung, was MS dort also für Ports benötigt für einen "Fernzugriff". Aber ich halte alle neben dem default HTTPS Port für Fragwürdig an der Geschichte ;)
Klar, es lässt sich potentiell alles umverbiegen (irgendwie), aber oftmals ist das eher größerer Aufwand, gerade bei so "fertig" OSen wie dem WHS oder dem Essentials. Ja selbst beim SBS/EBS ist das so ne Sache.

Wenn da was nicht geht/ging, dann liegt zu 99,9% eine Fehlkonfiguration vor.
Man kann das ganze halt (bevor man die Ports am Router weiterleitet) einfach intern testen... Zur Not mit ner Firewall dazwischen und wenn es die lokale Windows Client Firewall ist, die alles (temporär und somit für Testzwecke) intern einfach mal zum Server blockt -> außer HTTPS. Wenn es geht, dann ist die Konfig richtig, wenn nicht, dann ist sie falsch. In letzterem Fall macht das weiterleiten von irgendwelchen anderen Protokollen/Ports wenig Sinn. Sicher kommt man bei gewissen Sachen an sein Endziel -> nur ist das dann eben oftmals nicht das, was eigentlich bei der Funktion bei rumkommen soll. Gerade wenn es um solche Sachen wie Fernzugriff geht.

PS: bei mir läuft das übrigens vollständig über HTTPS. Ich hab zwar weder den WHS noch den 2012 (R2) Essentials, sondern nur einen SBS 2011 inkl. Exchange, aber der bietet auch so nen Webarbeitsplatz. Ebenso mit Remote Desktop Gateway zur Nutzung von RDP auf lokale Geräte im Netz. -> das wird vollständig über HTTPS getunnelt. Und es ist einzig und allein ein Forwarding der TCP 443 auf den Server notwendig. Oder eben EINEM anderen Port, wenn man nicht default HTTPS nutzen kann/will. Mehr wird nicht benötigt und mehr ist auch nicht sinnvoll (zumindest nicht für diese Funktion). -> das ganze sollte man dann aber trotzdem noch irgendwie absichern. Und sei es durch irgendwelche Zugriffsmaßnahmen ala Firewallfreischaltungen oder ähnliches... Denn sonst kann halt potentiell jeder sich versuchen, der da irgendwie die IP oder den DNS Eintrag kennt. Ich hab dazu nen "Hardware VPN Router" davor stehen. Der bietet ne FWUA (Firewall User Authentication) -> sprich nur mit User/Kennworteingabe kann man seine IP, mit der man beim Server gesehen wird, überhaupt erstmal freischießen... Für alle anderen ist erstmal Ende am Router angesagt. Außer er knackt die Firewallfreischaltung irgendwie. Aber selbst dann kann man sich weiter absichern. Mechanismen zur Abwehr von zu vielen Fehlversuchen und somit (temporären) Block der IP des Angreifers gibts ebenso noch.

Es gibt zwar keine 100% Sicherheit in den Weiten des Internets, aber deswegen muss man sich halt auch nicht der Öffentlichkeit völlig offen präsentieren ;) -> und wenn es nur so viele Steine im Weg des Angreifers sind, wie nur irgend möglich.
 
Danke für den ausführlichen Text. Da muss ich wohl einiges umstellen. Leider kann ich das erst am 8.8 machen, bin so lange geschäftlich unterwegs :/. Die Ports habe ich aber gleich noch geschlossen, sicher ist sicher. :)
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh