VPN imitiert das lokale Netzwerk oder nicht?
Hallo,
folgende Sache. Ich habe eine dedizierten Server bei Strato, weil ich damit meinen lokalen Server abstellen kann. Lange Rede, kurzer Sinn: Der Server wurde erfolgreich vom lokalen auf den Strato Server übertragen und alles funktioniert auch und man kann über Remotedesktop alles sehr gut benutzen eigentlich.
Jetzt wollte ich ein VPN einrichten, damit ich per Inet und mit Windows 10 Pro auf die Domain zugreifen kann als wäre ich beim Server direkt im Netzwerk angemeldet.
Ich habe es auch geschafft per Ipsec die VPN-Verbindung aufzustellen und zu verbinden. Ich kann im Windows Explorer die statische IP eingeben oder direkt SERVER eingeben und dann erscheinen die freigegebenen Ordner und man kann auf die Dateien zugreifen. Und wenn man nicht mit VPN verbunden ist, sondern die statische IP eingibt, dann fragt Windows nach Benutzername und Password und dann kann man auch auf die Dateien im Server zugreifen.
Jedoch kommen zwei Probleme zustande:
1.) Die Interverbindung bricht ab, man kann nur Server zugreifen, sobald man VPN aktiviert. Es gibt einen Workaround, der funktioniert, indem man bei IP4 in den Adapteroptionen "Standardgateway für das Remotenetzwerk verwenden" das Haken entfernt.
2.) Die Programme, die wir verwenden müssen im Netzwerk des Servers funktionieren, ansonsten funktionieren sie nicht. Sie senden keine Pakete. Nach mehreren Versuchen hat ein Programm eine Interessante Meldung gegeben "Sie sind nicht im gleichen Netzwerk wie der Server".
Das Problem ist, dass irgendwie der Routing and Ras Server den Client nicht so behandelt als wäre im gleichen Netzwerk, was ja soweit ich verstanden hatte, was VPN tun soll.
Meine erste Frage ist einmal folgendes:
1.) Wenn ich mich als Client einwähle per VPN, bin ich dann nicht im gleichen Netzwerk oder habe ich VPN völlig falsch verstanden? Also imitiert nicht der Windows Server dem Client vor, als wäre lokal in Strato Hauptzentrale im Netzwerk, wo der Server ist?
Beste grüße
Jens Draht
folgende Sache. Ich habe eine dedizierten Server bei Strato, weil ich damit meinen lokalen Server abstellen kann. Lange Rede, kurzer Sinn: Der Server wurde erfolgreich vom lokalen auf den Strato Server übertragen und alles funktioniert auch und man kann über Remotedesktop alles sehr gut benutzen eigentlich.
Jetzt wollte ich ein VPN einrichten, damit ich per Inet und mit Windows 10 Pro auf die Domain zugreifen kann als wäre ich beim Server direkt im Netzwerk angemeldet.
Ich habe es auch geschafft per Ipsec die VPN-Verbindung aufzustellen und zu verbinden. Ich kann im Windows Explorer die statische IP eingeben oder direkt SERVER eingeben und dann erscheinen die freigegebenen Ordner und man kann auf die Dateien zugreifen. Und wenn man nicht mit VPN verbunden ist, sondern die statische IP eingibt, dann fragt Windows nach Benutzername und Password und dann kann man auch auf die Dateien im Server zugreifen.
Jedoch kommen zwei Probleme zustande:
1.) Die Interverbindung bricht ab, man kann nur Server zugreifen, sobald man VPN aktiviert. Es gibt einen Workaround, der funktioniert, indem man bei IP4 in den Adapteroptionen "Standardgateway für das Remotenetzwerk verwenden" das Haken entfernt.
2.) Die Programme, die wir verwenden müssen im Netzwerk des Servers funktionieren, ansonsten funktionieren sie nicht. Sie senden keine Pakete. Nach mehreren Versuchen hat ein Programm eine Interessante Meldung gegeben "Sie sind nicht im gleichen Netzwerk wie der Server".
Das Problem ist, dass irgendwie der Routing and Ras Server den Client nicht so behandelt als wäre im gleichen Netzwerk, was ja soweit ich verstanden hatte, was VPN tun soll.
Meine erste Frage ist einmal folgendes:
1.) Wenn ich mich als Client einwähle per VPN, bin ich dann nicht im gleichen Netzwerk oder habe ich VPN völlig falsch verstanden? Also imitiert nicht der Windows Server dem Client vor, als wäre lokal in Strato Hauptzentrale im Netzwerk, wo der Server ist?
Beste grüße
Jens Draht
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4690987118
Url: https://administrator.de/forum/vpn-imitiert-das-lokale-netzwerk-oder-nicht-4690987118.html
Ausgedruckt am: 15.04.2025 um 18:04 Uhr
33 Kommentare
Neuester Kommentar
Moin,
bzgl. im selben Netzwerk sein:
Nö, du bist erst mal nicht im selben Netz.
Deine Konfig hört sich stark nach OpenVPN an, dieser installiert wie alle anderen VPN-Anbieter einen neuen Netzwerkadapter und dieser wiederum hat eine IP aus deinem VPN- bzw. Zielnetz.
Rufst Du nun eine IP-Adresse aus dem Zielnetz auf, sieht dein Rechner "oh mein Interface XYZ ist in diesem Netz, ich route diese Pakete also einfach über diesen Adapter.
Jetzt achtung: Wenn das VPN-Zielnetz sich mit einem Adressraum überschneidet, welchen du auch lokal (ohne VPN) hast, musst du natten (Bei Split Tunneling). Sonst weiß dein PC schlicht und einfach nicht, welches Interface dafür zuständig ist.
Bzgl. Internetabbruch:
Du hast kein Splitunneling aktiv. Du hast via der VPN-Config deinem Rechner die Firewall als Standard-GW mitgegeben, und diese hat vermutlich keine Regeln welche den Traffic aus dem VPN-Netz richtung Internet steuert.
Mit Split-Tunneling bewirkst Du, dass dein Rechner die VPN-Verbindung nur dann nutzt, wenn Ziele erreicht werden, welche in der Range der Zielnetze liegen. Sämtlicher anderer Traffic wird dann lokal abgehandelt, wie z.B. Internet.
bzgl. im selben Netzwerk sein:
Nö, du bist erst mal nicht im selben Netz.
Deine Konfig hört sich stark nach OpenVPN an, dieser installiert wie alle anderen VPN-Anbieter einen neuen Netzwerkadapter und dieser wiederum hat eine IP aus deinem VPN- bzw. Zielnetz.
Rufst Du nun eine IP-Adresse aus dem Zielnetz auf, sieht dein Rechner "oh mein Interface XYZ ist in diesem Netz, ich route diese Pakete also einfach über diesen Adapter.
Jetzt achtung: Wenn das VPN-Zielnetz sich mit einem Adressraum überschneidet, welchen du auch lokal (ohne VPN) hast, musst du natten (Bei Split Tunneling). Sonst weiß dein PC schlicht und einfach nicht, welches Interface dafür zuständig ist.
Bzgl. Internetabbruch:
Du hast kein Splitunneling aktiv. Du hast via der VPN-Config deinem Rechner die Firewall als Standard-GW mitgegeben, und diese hat vermutlich keine Regeln welche den Traffic aus dem VPN-Netz richtung Internet steuert.
Mit Split-Tunneling bewirkst Du, dass dein Rechner die VPN-Verbindung nur dann nutzt, wenn Ziele erreicht werden, welche in der Range der Zielnetze liegen. Sämtlicher anderer Traffic wird dann lokal abgehandelt, wie z.B. Internet.
Moin,
schreib den Gedanken mit dem "selben" Netz ab. Dafür gibt es keine Lösung auf IP Basis.
NAT ist ja nur eine Übersetzung und bedingt trotzdem zwei unterschiedliche IP Kreise.
Außerdem hast du keine Vorteile wenn du nur ein Netz nutzt. Einfacher wird es für dich eine Firewall als VPN Endpunkt zu betreiben.
Gruß
Spirit
schreib den Gedanken mit dem "selben" Netz ab. Dafür gibt es keine Lösung auf IP Basis.
NAT ist ja nur eine Übersetzung und bedingt trotzdem zwei unterschiedliche IP Kreise.
Außerdem hast du keine Vorteile wenn du nur ein Netz nutzt. Einfacher wird es für dich eine Firewall als VPN Endpunkt zu betreiben.
Gruß
Spirit
Moin,
welche Rollen sind denn auf der Kiste bei Strato installiert? Hört sich für mich so an, als würde jetzt alles inkl. RRAS auf einer Kiste laufen. Ist das gleichzeitig auch Dein AD für das lokale Netz oder ist das ein Standalone Server ohne AD?
I.d.R. kann bzw. sollte man einen lokalen Server nicht 1:1 in die Cloud schieben. Da kommen neben den Routingproblemen auch ganz schnell ungebetene Gäste hinzu.
Insbesondere die RRAS Rolle sollte auf einer separaten Maschine laufen.
Um welche Programme handelt es sich denn "die ihr verwenden müsst"?
Sinnvoller ist es i.d.R. einen Hypervisor (Hyper-V oder VMWare ESXi) auf dem ded. Server laufen zu lassen, darauf eine Firewall als VM (bspw. pfSense o.ä.) vorzuschalten, die auch die VPN Verbindungen zur Verfügung stellt und dann die Server-VM(s) hinter diese Firewall-VM zu setzen.
Damit kann man dann ein site2site VPN zwischen eurem lokalen Netzwerk und dem Server herstellen und die Ressourcen dem lokalen Netzwerk abgesichert zur Verfügung stellen.
Dieser Aufbau ist natürlich um Längen komplexer, als alles auf eine Kiste zu packen. Solltest Du aber ungebetene Gäste bekommen, sind Deine Daten ganz schnell weg und der Schaden um ein vielfaches größer.
Gruß
cykes
welche Rollen sind denn auf der Kiste bei Strato installiert? Hört sich für mich so an, als würde jetzt alles inkl. RRAS auf einer Kiste laufen. Ist das gleichzeitig auch Dein AD für das lokale Netz oder ist das ein Standalone Server ohne AD?
I.d.R. kann bzw. sollte man einen lokalen Server nicht 1:1 in die Cloud schieben. Da kommen neben den Routingproblemen auch ganz schnell ungebetene Gäste hinzu.
Insbesondere die RRAS Rolle sollte auf einer separaten Maschine laufen.
Um welche Programme handelt es sich denn "die ihr verwenden müsst"?
Sinnvoller ist es i.d.R. einen Hypervisor (Hyper-V oder VMWare ESXi) auf dem ded. Server laufen zu lassen, darauf eine Firewall als VM (bspw. pfSense o.ä.) vorzuschalten, die auch die VPN Verbindungen zur Verfügung stellt und dann die Server-VM(s) hinter diese Firewall-VM zu setzen.
Damit kann man dann ein site2site VPN zwischen eurem lokalen Netzwerk und dem Server herstellen und die Ressourcen dem lokalen Netzwerk abgesichert zur Verfügung stellen.
Dieser Aufbau ist natürlich um Längen komplexer, als alles auf eine Kiste zu packen. Solltest Du aber ungebetene Gäste bekommen, sind Deine Daten ganz schnell weg und der Schaden um ein vielfaches größer.
Gruß
cykes
Moin...
Frank
Und wenn man nicht mit VPN verbunden ist, sondern die statische IP eingibt, dann fragt Windows nach Benutzername und Password und dann kann man auch auf die Dateien im Server zugreifen.
bedeutet, dein Server steht mit dem nakten arsch im Internet! ich kann mir schlecht vorstellen, das du das wirklich so möchtest!Frank
1.)
Split Tunneling versus Gateway Redirect. Das ist nirmales Verhalten weil beim GR aller Traffic in den Tunnel geschickt wird und bei ST eben nur der Relevante für das jeweilige Subnetz.
Wenn du Gateway Redirect machst musst du dafür sorgen das dein Server nicht relevanten VPN Traffic NAT also per Adress Translation ins Internet bringt. Dann klappt auch Gateway Redirect problemlos.
Dieses Foren Tutorial beschreibt dir im Kapitel "Client VPN und NAT" wie das einfach und schnell zu lösen ist auf einem vServer wie du ihn hast!
Lesen und verstehen... 😉
2.)
Das ist normal, denn das Client VPN wird in der Regel immer in einem eigenen IP Netz betrieben. Der vServer muss also zwingend IPv4 Forwarding aktiviert haben sonst scheitert der Zugriff.
Bei Apple Mac und Linux ist das ip a oder ifconfig.
Zu den anderen gruseligen Setups deines "VPNs" ist oben und von @Vision2015 ja schon alles gesagt worden...
Split Tunneling versus Gateway Redirect. Das ist nirmales Verhalten weil beim GR aller Traffic in den Tunnel geschickt wird und bei ST eben nur der Relevante für das jeweilige Subnetz.
Wenn du Gateway Redirect machst musst du dafür sorgen das dein Server nicht relevanten VPN Traffic NAT also per Adress Translation ins Internet bringt. Dann klappt auch Gateway Redirect problemlos.
Dieses Foren Tutorial beschreibt dir im Kapitel "Client VPN und NAT" wie das einfach und schnell zu lösen ist auf einem vServer wie du ihn hast!
Lesen und verstehen... 😉
2.)
Das ist normal, denn das Client VPN wird in der Regel immer in einem eigenen IP Netz betrieben. Der vServer muss also zwingend IPv4 Forwarding aktiviert haben sonst scheitert der Zugriff.
bin ich dann nicht im gleichen Netzwerk
Nein normalerweise nicht. Warum warst du nicht so intelligent das einmal selber zu prüfen?! Du musst beim Windows Client bei aktivem VPN nur einmal ipconfig eingeben und dir die IP Adresse am viruellen VPN Netzwerkadapter ansehen, dann weisst du es doch selber?!Bei Apple Mac und Linux ist das ip a oder ifconfig.
Zu den anderen gruseligen Setups deines "VPNs" ist oben und von @Vision2015 ja schon alles gesagt worden...
Zitat von @jensdraht1999:
Hallo,
es ist mit nacktem A... im Inet und das ist auch erstmal OK so. Ich sehe im Eventlog von Windows Server jede Sekunde 4 verschiedene Benutzer, die sich versuchen anzumelden, man nimmt klassische Benutzernamen wie Administrator, Test, Print, Printer, Mark, Matthew usw. und sofort. Aber die Hacker können sich gerne bemühen, denn die haben beim anderen Server, den ich auch eingestellt hatte und dieser hatte diese Einträge im Serverlog auch, aber reingekommen sind die bist heute nicht.
Außerdem ist das kein V-Server, es ist ein dedizierter Server, der wirklich läuft und nicht emuliert wird.
Hallo,
es ist mit nacktem A... im Inet und das ist auch erstmal OK so. Ich sehe im Eventlog von Windows Server jede Sekunde 4 verschiedene Benutzer, die sich versuchen anzumelden, man nimmt klassische Benutzernamen wie Administrator, Test, Print, Printer, Mark, Matthew usw. und sofort. Aber die Hacker können sich gerne bemühen, denn die haben beim anderen Server, den ich auch eingestellt hatte und dieser hatte diese Einträge im Serverlog auch, aber reingekommen sind die bist heute nicht.
Außerdem ist das kein V-Server, es ist ein dedizierter Server, der wirklich läuft und nicht emuliert wird.
Wenn Du es eh besser weißt, brauchst Du doch gar nicht erst hier fragen :D
Sollte es keine VM sein, sondern ein Rootserver, warum zur Hölle installierst Du dann dein Zielsystem direkt auf diesem Server?
IdR arbeitet man hier mit irgendeinem Hypervisor und baut sich seine VMs (u.A. auch eine PfSense, OpnSense what ever)
Bisher konntest Du nicht nachvollziehen, ob und wie dein VPN funktioniert. Ob aber ein Angreifer Zugriff auf dein System hat, weißt Du also ...
Keine Ahnung, ich kenne mich mit RAS nicht aus.
Ich sehe auch ehrlich gesagt keinen Use-case dafür und verstehe nicht, warum Du nicht einfach ein OpenVPN fixt.
Grundsätzlich:
Das was Du "Hauptadresse" nennst, ist eine Public-IP, welche im Internet rout- wie auch erreichbar ist.
Das alleine spricht schon stark dafür, dass Du eine VM angemietet hast und keinen Rootserver, da die Public IP direkt an der VM hängt.
Egal was Du hier mit einem Client-2-Client VPN aufbaust: Es ist unsicher. Die Public IP gehört an eine Firewall und nicht an das Zielsystem. Über diese IP handelst Du dann auch dein VPN mit Site-2-Site ab.
Wenn Du wirklich einen Tipp willst:
Deine Firewall wird dann dein zentraler Router für die internen Hosts, sowie dein VPN nach außen.
Das Grundproblem an deinem Setup ist, dass der Server wie beschrieben aus dem Internet erreichbar ist. Da hilft auch keine Windows-Firewall, schon gar nicht, wenn das System produktiv eingesetzt wird.
Wenn du auf dem System nur basteln willst, oder einen Minecraft-Server what ever laufen möchtest, dann go for it, ändere vielleicht den Listeing Port für RDP, dass macht es noch lange nicht sicher, aber immerhin schützt sich das vor den simpelsten Portscans. Wohlgemerkt gibt es aber auch Portscans die RDP hinter anderen Ports entdecken, das nur zur Info.
Wenn hier aber Unternehmensdaten bzw. Informationen draufliegen, oder verarbeitet werden, bau den Mist wieder ab und bau es auf wie von mir beschrieben. Die anderen Kollegen haben hier ebenfalls drauf hingewiesen.
Nachtrag:
Um dir das Problem vielleicht mal selbst zu verbildchen:
Geh mal auf deiner VM in die CMD und gibt "netstat -an" ein.
Alle Ports mit der Adresse 0.0.0.0 dürfen theoretisch von überall (somit auch Internet) aufgerufen werden. Hier sind per Default in Windows einige offen.
Das sollte dir klar machen, wieso man sowas anders löst.
Ich sehe auch ehrlich gesagt keinen Use-case dafür und verstehe nicht, warum Du nicht einfach ein OpenVPN fixt.
Grundsätzlich:
Das was Du "Hauptadresse" nennst, ist eine Public-IP, welche im Internet rout- wie auch erreichbar ist.
Das alleine spricht schon stark dafür, dass Du eine VM angemietet hast und keinen Rootserver, da die Public IP direkt an der VM hängt.
Egal was Du hier mit einem Client-2-Client VPN aufbaust: Es ist unsicher. Die Public IP gehört an eine Firewall und nicht an das Zielsystem. Über diese IP handelst Du dann auch dein VPN mit Site-2-Site ab.
Wenn Du wirklich einen Tipp willst:
- Kündige deine VM-Instanz
- Miete einen Rootserver mit vorinstallieren Hypervisior (Promox z.B. ist Opensource und auf Augenhöhe mit Enterprise-Anbietern)
- Installiere eine Firewall in einer VM (PFSense, OpnSense, oder meinetwegen auch Enterprise-Payware)
- Public-IP kommt an das WAN-Interface dieser Firewall
- OpenVPN oder vergleichbar über Firewall aufbauen / konfigurieren
- Endsysteme in private, nicht internet routbare Netze, hinter der Firewall packen.
Deine Firewall wird dann dein zentraler Router für die internen Hosts, sowie dein VPN nach außen.
Das Grundproblem an deinem Setup ist, dass der Server wie beschrieben aus dem Internet erreichbar ist. Da hilft auch keine Windows-Firewall, schon gar nicht, wenn das System produktiv eingesetzt wird.
Wenn du auf dem System nur basteln willst, oder einen Minecraft-Server what ever laufen möchtest, dann go for it, ändere vielleicht den Listeing Port für RDP, dass macht es noch lange nicht sicher, aber immerhin schützt sich das vor den simpelsten Portscans. Wohlgemerkt gibt es aber auch Portscans die RDP hinter anderen Ports entdecken, das nur zur Info.
Wenn hier aber Unternehmensdaten bzw. Informationen draufliegen, oder verarbeitet werden, bau den Mist wieder ab und bau es auf wie von mir beschrieben. Die anderen Kollegen haben hier ebenfalls drauf hingewiesen.
Nachtrag:
Um dir das Problem vielleicht mal selbst zu verbildchen:
Geh mal auf deiner VM in die CMD und gibt "netstat -an" ein.
Alle Ports mit der Adresse 0.0.0.0 dürfen theoretisch von überall (somit auch Internet) aufgerufen werden. Hier sind per Default in Windows einige offen.
Das sollte dir klar machen, wieso man sowas anders löst.
Die Software meint mit selbes Netzwerk wahrscheinlich selbe Broadcast Domäne, weil sie schlecht programmiert ist und wahrscheinlich über Broad-/Multicast arbeitet. Und das ist bei VPN einfach nur sehr eingeschränkt möglich bzw nicht sinnvoll.
Naja, auf das nächste Botnet. Wie kann man nur so uneinsichtig sein. Grade Windows mit SMB und RDP direkt ins Internet zu stellen ist grob fahrlässig, es gibt viele unbekannte sicherheitslücken, und die siehst du auch nicht im Evenrlog.
Latenz per RDP ist hier ein Problem? Was für ne Software ist das denn?
Naja, auf das nächste Botnet. Wie kann man nur so uneinsichtig sein. Grade Windows mit SMB und RDP direkt ins Internet zu stellen ist grob fahrlässig, es gibt viele unbekannte sicherheitslücken, und die siehst du auch nicht im Evenrlog.
Latenz per RDP ist hier ein Problem? Was für ne Software ist das denn?
Guten Morgen,
lieber @jensdraht1999, du bist ein gutes Beispiel, wie man es nicht macht!
wenn es Lizenztechnisch ist, bleib beim server im büro!
wenn dein RDP Server latenzen hat, liegt das in der regel am Server Setup, oder an den anbindungen!
wenn dein setup eine all in one lösung ist, also AD, DC RDP, SQL und File auf einem Server ohne virtualisierung, kannst du eh gleich alles neu machen! das gehört so nicht, und bringt nur probleme!
und natürlich kannst du mit RDP wunderbar lokal drucken, wo soll das problem sein?
bleib bei RDP, und mach das ordentlich....
dein Server muss natürlich die entsprechende leistung haben, sprich genug CPU und RAM, und natürlich SSD / NVme...
wie soll deine Backup Lösung sein?
wie lange darf dein Betrieb still stehen?
sicher ist, du kannst es nicht, du bist mit deinem latein am ende!
dir fehlt jegliches netzwerk grundverständnis, und mit deiner leichtsinnigkeit sind deine daten in gefahr!
am besten wäre, dich von einer Fachfirma beraten zu lassen, und bei der installation zu lernen!
sicher kostet das viel geld, ich hoffe dir war das vorher klar....
so geht das nicht!
Frank
lieber @jensdraht1999, du bist ein gutes Beispiel, wie man es nicht macht!
es ist mit nacktem A... im Inet und das ist auch erstmal OK so.
ist es nicht!Ich sehe im Eventlog von Windows Server jede Sekunde 4 verschiedene Benutzer, die sich versuchen anzumelden, man nimmt klassische Benutzernamen wie Administrator, Test, Print, Printer, Mark, Matthew usw. und sofort. Aber die Hacker können sich gerne bemühen, denn die haben beim anderen Server, den ich auch eingestellt hatte und dieser hatte diese Einträge im Serverlog auch, aber reingekommen sind die bist heute nicht.
oha... du würdest es nicht mal merken, wenn ich deinen root server entern würde, und in deinen Logs bekommst du zu lesen, was ich möchte, also was du lesen darfst!Außerdem ist das kein V-Server, es ist ein dedizierter Server, der wirklich läuft und nicht emuliert wird.
was ja nix an der sache ändert!Ich weiß es nicht besser. Habe ich auch nicht gesagt. Hier ist eine Auflistung des Problems:
dein problem fängt schon am anfang an... beim root server!Der Grund ist, weil ich gleichen Netzwerk sein muss und dann auf die MSSQL Software, die im Server läuft zugreifen kann als wäre ich gleichen Netz.
also, aus SQL sicht, ist das erstmal blödsinn!wenn es Lizenztechnisch ist, bleib beim server im büro!
Was ich quasi möchte ist, ich hatte ein Büro und einen Server und Client PC. Lokal, in echt.
Dort war eine Domain, man hat sich eingeloggt und alles hat 100% funktioniert.
warum bist du nicht mit dem Server im Büro geblieben?Dort war eine Domain, man hat sich eingeloggt und alles hat 100% funktioniert.
Jetzt ist man auf Strato umgezogen und der Server wird dort von Remotedesktop betrieben, aber aufgrund der Latenz vom Remotedesktop, möchte ich das anders lösen. Und außerdem möchte ich auch lokalen Drucker benutzen, wenn ich ein Dokument ausdrucken will.
aha "Man" ist auf Strato umgezogen! wer ist auf die idee gekommen? und wer hat das so ausgeführt?wenn dein RDP Server latenzen hat, liegt das in der regel am Server Setup, oder an den anbindungen!
wenn dein setup eine all in one lösung ist, also AD, DC RDP, SQL und File auf einem Server ohne virtualisierung, kannst du eh gleich alles neu machen! das gehört so nicht, und bringt nur probleme!
und natürlich kannst du mit RDP wunderbar lokal drucken, wo soll das problem sein?
Deshalb ist Remotedesktop für mich keine alternative. Stattdessen möchte ich das gleiche Setup, halt als wäre ich im gleichen Netzwerk wie mein Server, dann würden alle Probleme behoben werden.
wenn du das so machen möchtest, hast du probleme mit den Latenzen... nur so nebenbei....bleib bei RDP, und mach das ordentlich....
dein Server muss natürlich die entsprechende leistung haben, sprich genug CPU und RAM, und natürlich SSD / NVme...
wie soll deine Backup Lösung sein?
wie lange darf dein Betrieb still stehen?
Genau, warum geht das nicht.
weil dein setup falsch ist!Ist das nicht, wofür VPN existiert?
doch, wenn es richtig gemacht wird!sicher ist, du kannst es nicht, du bist mit deinem latein am ende!
dir fehlt jegliches netzwerk grundverständnis, und mit deiner leichtsinnigkeit sind deine daten in gefahr!
am besten wäre, dich von einer Fachfirma beraten zu lassen, und bei der installation zu lernen!
sicher kostet das viel geld, ich hoffe dir war das vorher klar....
Wenn nicht, dann sag das und ich kann das als Antwort annehmen.
du hast die richtige antwort mehrfach bekommen, was das thema netzwerk und vpn betrifft.so geht das nicht!
Frank
Die Ports für sämtliche VPN sind frei jeweils TCP/UDP.
Das reicht nicht für IPsec. Was ist mit ESP? TCP kommt übrigens bei IPsec gar nicht vor. Und Broadcast Adressen im internen PPP Netz des VPNs zu verwenden ist auch nicht gerade intelligent.Somit verstehe ich den ganze Ding mit interner IP nicht
Das solltest du aber schon wenn du mit VPNs arbeitest. Wie willst du das VPN denn sonst sicher und funktionstüchtig einrichten?!was Strato sagt, was man jeweils eintragen soll:
Die Konfig dort ist doch völliger Quatsch und sollte auch einem Laien sofort auffallen. Die Server IP ist eine öffentliche 85.x.y.z IP. Das Gateway liegt dann aber in einem ungerouteten RFC1918 10er IP Netz?? Tolles Konstrukt!Mit einem Server der im Internet hängt spielst du da fahrlässig mit dem Feuer! Ganz besonders wenn es einer mit Winblows OS ist.
Soviel mal zu den Latein Kenntnissen...
Wie Kollege @Vision2015 schon richtig sagt: Du solltest dir besser dringenst Hilfe an die Hand holen von jemanden der weiss was er da macht!
Zitat von @jensdraht1999:
Ich möchte kein Klugs*** spielen, aber laut Wiki:
IKE basiert auf UDP und nutzt standardmäßig den Port 500 als Quell- und Ziel-Port. Wird IKE und IPsec jedoch hinter einer Masquerading-Firewall betrieben, wird von den meisten IPsec-Implementierungen in diesem Fall UDP-Port 4500 verwendet.
Also meinst du, dass das Strato mit ca. 500 Mitarbeitern, also eine riesen große Firma, trägt bei sich einfach Quatsch ein?
Das reicht nicht für IPsec. Was ist mit ESP? TCP kommt übrigens bei IPsec gar nicht vor. Und Broadcast Adressen im internen PPP Netz des VPNs zu verwenden ist auch nicht gerade intelligent.
Ich möchte kein Klugs*** spielen, aber laut Wiki:
IKE basiert auf UDP und nutzt standardmäßig den Port 500 als Quell- und Ziel-Port. Wird IKE und IPsec jedoch hinter einer Masquerading-Firewall betrieben, wird von den meisten IPsec-Implementierungen in diesem Fall UDP-Port 4500 verwendet.
Die Konfig dort ist doch völliger Quatsch und sollte auch einem Laien sofort auffallen.
Also meinst du, dass das Strato mit ca. 500 Mitarbeitern, also eine riesen große Firma, trägt bei sich einfach Quatsch ein?
Die Ports sind ja auch korrekt. Dennoch muss das "Protokoll" ESP erlaubt sein.
Das ist keine Portfreigabe als solches.
Zitat von @jensdraht1999:
Warum soll es quatsch sein. Es bekommen nur Leute, die in der Domain sind, Zugriff auf den Server.
das glaubst aber nur du!Zitat von @Vision2015:
Guten Morgen,
lieber @jensdraht1999, du bist ein gutes Beispiel, wie man es nicht macht!
wenn es Lizenztechnisch ist, bleib beim server im büro!
wenn dein RDP Server latenzen hat, liegt das in der regel am Server Setup, oder an den anbindungen!
wenn dein setup eine all in one lösung ist, also AD, DC RDP, SQL und File auf einem Server ohne virtualisierung, kannst du eh gleich alles neu machen! das gehört so nicht, und bringt nur probleme!
und natürlich kannst du mit RDP wunderbar lokal drucken, wo soll das problem sein?
bleib bei RDP, und mach das ordentlich....
dein Server muss natürlich die entsprechende leistung haben, sprich genug CPU und RAM, und natürlich SSD / NVme...
wie soll deine Backup Lösung sein?
wie lange darf dein Betrieb still stehen?
sicher ist, du kannst es nicht, du bist mit deinem latein am ende!
dir fehlt jegliches netzwerk grundverständnis, und mit deiner leichtsinnigkeit sind deine daten in gefahr!
am besten wäre, dich von einer Fachfirma beraten zu lassen, und bei der installation zu lernen!
sicher kostet das viel geld, ich hoffe dir war das vorher klar....
so geht das nicht!
Frank
Guten Morgen,
lieber @jensdraht1999, du bist ein gutes Beispiel, wie man es nicht macht!
es ist mit nacktem A... im Inet und das ist auch erstmal OK so.
ist es nicht!Ich sehe im Eventlog von Windows Server jede Sekunde 4 verschiedene Benutzer, die sich versuchen anzumelden, man nimmt klassische Benutzernamen wie Administrator, Test, Print, Printer, Mark, Matthew usw. und sofort. Aber die Hacker können sich gerne bemühen, denn die haben beim anderen Server, den ich auch eingestellt hatte und dieser hatte diese Einträge im Serverlog auch, aber reingekommen sind die bist heute nicht.
oha... du würdest es nicht mal merken, wenn ich deinen root server entern würde, und in deinen Logs bekommst du zu lesen, was ich möchte, also was du lesen darfst!Außerdem ist das kein V-Server, es ist ein dedizierter Server, der wirklich läuft und nicht emuliert wird.
was ja nix an der sache ändert!Ich weiß es nicht besser. Habe ich auch nicht gesagt. Hier ist eine Auflistung des Problems:
dein problem fängt schon am anfang an... beim root server!Der Grund ist, weil ich gleichen Netzwerk sein muss und dann auf die MSSQL Software, die im Server läuft zugreifen kann als wäre ich gleichen Netz.
also, aus SQL sicht, ist das erstmal blödsinn!wenn es Lizenztechnisch ist, bleib beim server im büro!
Was ich quasi möchte ist, ich hatte ein Büro und einen Server und Client PC. Lokal, in echt.
Dort war eine Domain, man hat sich eingeloggt und alles hat 100% funktioniert.
warum bist du nicht mit dem Server im Büro geblieben?Dort war eine Domain, man hat sich eingeloggt und alles hat 100% funktioniert.
Jetzt ist man auf Strato umgezogen und der Server wird dort von Remotedesktop betrieben, aber aufgrund der Latenz vom Remotedesktop, möchte ich das anders lösen. Und außerdem möchte ich auch lokalen Drucker benutzen, wenn ich ein Dokument ausdrucken will.
aha "Man" ist auf Strato umgezogen! wer ist auf die idee gekommen? und wer hat das so ausgeführt?wenn dein RDP Server latenzen hat, liegt das in der regel am Server Setup, oder an den anbindungen!
wenn dein setup eine all in one lösung ist, also AD, DC RDP, SQL und File auf einem Server ohne virtualisierung, kannst du eh gleich alles neu machen! das gehört so nicht, und bringt nur probleme!
und natürlich kannst du mit RDP wunderbar lokal drucken, wo soll das problem sein?
Deshalb ist Remotedesktop für mich keine alternative. Stattdessen möchte ich das gleiche Setup, halt als wäre ich im gleichen Netzwerk wie mein Server, dann würden alle Probleme behoben werden.
wenn du das so machen möchtest, hast du probleme mit den Latenzen... nur so nebenbei....bleib bei RDP, und mach das ordentlich....
dein Server muss natürlich die entsprechende leistung haben, sprich genug CPU und RAM, und natürlich SSD / NVme...
wie soll deine Backup Lösung sein?
wie lange darf dein Betrieb still stehen?
Genau, warum geht das nicht.
weil dein setup falsch ist!Ist das nicht, wofür VPN existiert?
doch, wenn es richtig gemacht wird!sicher ist, du kannst es nicht, du bist mit deinem latein am ende!
dir fehlt jegliches netzwerk grundverständnis, und mit deiner leichtsinnigkeit sind deine daten in gefahr!
am besten wäre, dich von einer Fachfirma beraten zu lassen, und bei der installation zu lernen!
sicher kostet das viel geld, ich hoffe dir war das vorher klar....
Wenn nicht, dann sag das und ich kann das als Antwort annehmen.
du hast die richtige antwort mehrfach bekommen, was das thema netzwerk und vpn betrifft.so geht das nicht!
Frank
Warum soll es quatsch sein. Es bekommen nur Leute, die in der Domain sind, Zugriff auf den Server.
gut, du bist der meinung, das ist alles richtg so, obwohl dir einige Administratoren mit langjähriger erfahrung
etwas anderes sagen- überhaubt scheinst du alles besser zu wissen- deswgen stelle ich mir die frage, was fragst du eigentlich noch in diesem Forum? Netzwerk und Sicherheit ist doch genau dein Ding, hattest eben nur beim kleinen Netzwerk 1 X 1 Ferien!
Also meinst du, dass das Strato mit ca. 500 Mitarbeitern, also eine riesen große Firma, trägt bei sich einfach Quatsch ein?
ja... das wissen diverse admins und user aus Erfahrung von den 500 Mitarbeitern wird dir sicher jemand bei deinem VPN helfen können.... sei aber nicht böse, wenn dir gesagt wird, das geht so nicht!
ich hoffe nur, das du selber dein boss bist... dann trägtst du zu 100% die verantwortung!
Frank
Ich kann mich meinen Vorrednern nur anschließen, aber das wird dir bei deinem Problem nicht weiter helfen. Ich möchte dir auch nicht die Lösung vorkauen, denn du hast noch so einiges zu lernen. Ich möchte aber versuchen dich in die richtige Richtung zu weisen. Es ist auch keine ideale Lösung, aber eine Möglichkeit mit wenig Mitteln dein Ziel zu erreichen.
Gehen wir mal davon aus, dass du nur eine Windows-Maschine hast auf dem z.B. ein Windows-Server 2019 Std. läuft. Windows Server ermöglicht es dir bereits von Hause aus 2 RDP-Verbindungen (zu administrativen Zwecken) gleichzeitig aufzubauen. D.h. wenn du nicht mehr als zwei RDP-Sitzungen brauchts ist das perfekt, wenn du mehr brauchst wird es komplizierter, da du einen lizensierten RDP-Server benötigen würdest. Wir gehen mal weiterhin vom einfacheren Fall aus.
Auf die Einrichtung eines AD würde ich bei einem so keinen Netzt verzichten. Auch weil Microsoft davon abrät u.a. einem SQL Server auf einem DC zu betreiben.
Du richtest dir deinen Server ein als ob es dein Server und Client wäre. Natürlich immer schön auf die Lizensierung achten. Also VPN-Server drauf, SQL-Server drauf, Office Standard drauf, Browser rauf, Client-Software etc. und fertig.
Und wie arbeitet man jetzt damit? Na du baust eine VPN-Verbindung zu deinem Server auf und verbindest dich anschließend per RDP mit deinem Server. Über RDP sagst du noch, dass die lokale Drucker genutzt werden sollen.
Diese Lösung ist überhaupt nicht schön und Lizenztechnisch schwierig, aber 100x besser als deine seltsame Lösung. Und noch ein kleiner Tipp am Rande: Mal dir einen Plan bzw. Netzplan, denn dann würdest du mit etwas Verständnis von Layer2 und 3 verstehen, das VPN nicht heißt im selben Netz. Das wäre nämlich MPLS oder ähnliches das dir so etwas ermöglicht.
Aber grundsätzlich würde ich dir abraten mit deinem Kenntnisstand von Netzwerksicherheit einen Server in der Cloud zu betreiben. Wenn es nur deine Daten wären würde ich sagen egal, aber vermutlich willst du damit Kundendaten etc. verwalten und diese Kunden tun mir jetzt schon leid.
Viel Erfolg und höre nicht auf dich fortzubilden.
Gehen wir mal davon aus, dass du nur eine Windows-Maschine hast auf dem z.B. ein Windows-Server 2019 Std. läuft. Windows Server ermöglicht es dir bereits von Hause aus 2 RDP-Verbindungen (zu administrativen Zwecken) gleichzeitig aufzubauen. D.h. wenn du nicht mehr als zwei RDP-Sitzungen brauchts ist das perfekt, wenn du mehr brauchst wird es komplizierter, da du einen lizensierten RDP-Server benötigen würdest. Wir gehen mal weiterhin vom einfacheren Fall aus.
Auf die Einrichtung eines AD würde ich bei einem so keinen Netzt verzichten. Auch weil Microsoft davon abrät u.a. einem SQL Server auf einem DC zu betreiben.
Du richtest dir deinen Server ein als ob es dein Server und Client wäre. Natürlich immer schön auf die Lizensierung achten. Also VPN-Server drauf, SQL-Server drauf, Office Standard drauf, Browser rauf, Client-Software etc. und fertig.
Und wie arbeitet man jetzt damit? Na du baust eine VPN-Verbindung zu deinem Server auf und verbindest dich anschließend per RDP mit deinem Server. Über RDP sagst du noch, dass die lokale Drucker genutzt werden sollen.
Diese Lösung ist überhaupt nicht schön und Lizenztechnisch schwierig, aber 100x besser als deine seltsame Lösung. Und noch ein kleiner Tipp am Rande: Mal dir einen Plan bzw. Netzplan, denn dann würdest du mit etwas Verständnis von Layer2 und 3 verstehen, das VPN nicht heißt im selben Netz. Das wäre nämlich MPLS oder ähnliches das dir so etwas ermöglicht.
Aber grundsätzlich würde ich dir abraten mit deinem Kenntnisstand von Netzwerksicherheit einen Server in der Cloud zu betreiben. Wenn es nur deine Daten wären würde ich sagen egal, aber vermutlich willst du damit Kundendaten etc. verwalten und diese Kunden tun mir jetzt schon leid.
Viel Erfolg und höre nicht auf dich fortzubilden.
Zitat von @Uhli90:
Gehen wir mal davon aus, dass du nur eine Windows-Maschine hast auf dem z.B. ein Windows-Server 2019 Std. läuft. Windows Server ermöglicht es dir bereits von Hause aus 2 RDP-Verbindungen (zu administrativen Zwecken) gleichzeitig aufzubauen. D.h. wenn du nicht mehr als zwei RDP-Sitzungen brauchts ist das perfekt, wenn du mehr brauchst wird es komplizierter, da du einen lizensierten RDP-Server benötigen würdest. Wir gehen mal weiterhin vom einfacheren Fall aus.
Gehen wir mal davon aus, dass du nur eine Windows-Maschine hast auf dem z.B. ein Windows-Server 2019 Std. läuft. Windows Server ermöglicht es dir bereits von Hause aus 2 RDP-Verbindungen (zu administrativen Zwecken) gleichzeitig aufzubauen. D.h. wenn du nicht mehr als zwei RDP-Sitzungen brauchts ist das perfekt, wenn du mehr brauchst wird es komplizierter, da du einen lizensierten RDP-Server benötigen würdest. Wir gehen mal weiterhin vom einfacheren Fall aus.
Das ist ein Lizenzverstoß. MS mag das gar nicht, wenn Du nicht zwischen Administration und Produktivbetrieb unterscheidest.
lks
Zitat von @aqui:
Mal abgesehen davon das RDP nicht verschlüsselt ist. Das wäre dann umso fahrlässiger mit ungeschütztem RDP zu arbeiten.
Mal abgesehen davon das RDP nicht verschlüsselt ist. Das wäre dann umso fahrlässiger mit ungeschütztem RDP zu arbeiten.
Da hast du nicht zu Ende gelesen, denn ich erwähne auch den VPN-Server. Wie gesagt, es ist immer noch eine richtig schlechte Lösung, aber besser als einen offenen AD Server im Internet zu betreiben.
Sorry, sollte deinen natürlich richtigen und auch wichtigen Beitrag keineswegs schmälern sondern war rein nur auf das ungeschützte RDP bezogen womit der TO ja auch rumwurschtelt.
Ggf. noch sinnvoller wäre es auf dem Host zu virtualisieren und eine Firewall VM (OPNsense, pfSense etc.) dort vor dem WinServer laufen zu lassen und eine VM mit dem MS Server geschützt von der FW.
VPN fackelt komplett die FW ab mit einer Site-to-Site Kopplung und Client VPN. Das ermöglicht einen wasserdichten und sicheren Betrieb des Windows Servers und erleichtert seine Backup Sicherung deutlich. Aber wie oben schon richtig gesagt...der TO hat noch so einiges zu lernen!
Ggf. noch sinnvoller wäre es auf dem Host zu virtualisieren und eine Firewall VM (OPNsense, pfSense etc.) dort vor dem WinServer laufen zu lassen und eine VM mit dem MS Server geschützt von der FW.
VPN fackelt komplett die FW ab mit einer Site-to-Site Kopplung und Client VPN. Das ermöglicht einen wasserdichten und sicheren Betrieb des Windows Servers und erleichtert seine Backup Sicherung deutlich. Aber wie oben schon richtig gesagt...der TO hat noch so einiges zu lernen!
Zitat von @Lochkartenstanzer:
Das ist ein Lizenzverstoß. MS mag das gar nicht, wenn Du nicht zwischen Administration und Produktivbetrieb unterscheidest.
lks
Zitat von @Uhli90:
Gehen wir mal davon aus, dass du nur eine Windows-Maschine hast auf dem z.B. ein Windows-Server 2019 Std. läuft. Windows Server ermöglicht es dir bereits von Hause aus 2 RDP-Verbindungen (zu administrativen Zwecken) gleichzeitig aufzubauen. D.h. wenn du nicht mehr als zwei RDP-Sitzungen brauchts ist das perfekt, wenn du mehr brauchst wird es komplizierter, da du einen lizensierten RDP-Server benötigen würdest. Wir gehen mal weiterhin vom einfacheren Fall aus.
Gehen wir mal davon aus, dass du nur eine Windows-Maschine hast auf dem z.B. ein Windows-Server 2019 Std. läuft. Windows Server ermöglicht es dir bereits von Hause aus 2 RDP-Verbindungen (zu administrativen Zwecken) gleichzeitig aufzubauen. D.h. wenn du nicht mehr als zwei RDP-Sitzungen brauchts ist das perfekt, wenn du mehr brauchst wird es komplizierter, da du einen lizensierten RDP-Server benötigen würdest. Wir gehen mal weiterhin vom einfacheren Fall aus.
Das ist ein Lizenzverstoß. MS mag das gar nicht, wenn Du nicht zwischen Administration und Produktivbetrieb unterscheidest.
lks
Was du nicht sagst :D Microsoft hat diesbezüglich eh einen an der Waffel. Da hat man ein lizensiertes Office Home and Business auf einer lokalen Maschine, sobald man aber diese Maschine per RDP aufruft und anspricht begeht man schon direkt mehrere Lizenzverstöße. Einmal das von dir erwähnte Problem das man Administration und Produktbetrieb nicht untersiedet und mindestens noch, dass Home and Business nicht als RDP/VM/etc. Anwendung lizensiert ist. Daher mache ich es jetzt wie der Microsoft-Berater und sage: "Auf die richtige Lizensierung müssen Sie selber achten" ....
Hier wird nur immer wieder ein Root-Server erwähnt, weil nur damit kannst du die Empfehlung umsetzten und mehrere VMs hosten - z.B eine VM für OpenSense (für die Firewall und VPN-Server), AD-Server und einen Terminal-Server. Das geht mit einem vServer nicht, da dieser bereits in einer virtualisierten Umgebung läuft. Mehr will man dir damit nicht sagen.
Ich habe mir nicht die Mühe gemacht mir diene IP-Konfiguration im Detail anzusehen, da das gesamte Konstrukt mit einem Denkfehler deinerseits entstanden ist. Diesen versuche ich dir jetzt einmal auszutreiben.
Wir brechen VPN mal auf zwei Varianten herunter:
1. Variante: Site-to-Site
Du verbindest zwei Netzwerke miteinander und es wird sozusagen von einem Netz in das andere Netz geroutet wenn das entsprechende Netzwerk auf der anderen Seite angesprochen wird.
Besonderheit: Beide Netzte können uneingeschränkt miteinander kommunizieren, solange man die Hosts bei beiden Seiten direkt mit IP anspricht, da NetBios etc. standardmäßig nicht durchgeroutet werden und die lokalen DNS-Server die Hosts der Gegenstelle nicht kennen.
2. Variante: Client-to-Site
Dein Client-PC wählt sich mit einer VPN-Software in ein VPN ein und erhält sozusagen eine virtuelle IP im eingewählten Netzwerk. Alles was in dem entfernen Netzwerk an diene virtuelle IP geht wird an deinen Client zurück geroutet.
Besonderheit: Du kannst mit deinem Client alle Hosts im deinem Zielnetz ansprechen, jedoch kann in deinem lokalen Netzt nur dein Client erreicht werden.
Daraus kann man schließen, dass wenn du Netzwerkdrucker im entfernten Netzwerk ansprechen willst und umgekehrt, eine Site-to-Site Verbindung benötigst. Bei einer Client-to-Site Verbindung geht es in der Regel nur über das Drucker-Umleiten in der RDP-Verbindung, was bei einer Site-to-Site-Verbindung natürlich auch möglich ist.
Und jetzt sage mir, wo würdest du deine seltsame Konstellation einordnen? Du musst erst einmal herausfinden welche dieser beiden Methoden für dich umsetzbar und geeignet ist, dann kann man dir bei deiner Netzwerkkonfiguration helfen und ins Detail gehen.
Ich habe mir nicht die Mühe gemacht mir diene IP-Konfiguration im Detail anzusehen, da das gesamte Konstrukt mit einem Denkfehler deinerseits entstanden ist. Diesen versuche ich dir jetzt einmal auszutreiben.
Wir brechen VPN mal auf zwei Varianten herunter:
1. Variante: Site-to-Site
Du verbindest zwei Netzwerke miteinander und es wird sozusagen von einem Netz in das andere Netz geroutet wenn das entsprechende Netzwerk auf der anderen Seite angesprochen wird.
Besonderheit: Beide Netzte können uneingeschränkt miteinander kommunizieren, solange man die Hosts bei beiden Seiten direkt mit IP anspricht, da NetBios etc. standardmäßig nicht durchgeroutet werden und die lokalen DNS-Server die Hosts der Gegenstelle nicht kennen.
2. Variante: Client-to-Site
Dein Client-PC wählt sich mit einer VPN-Software in ein VPN ein und erhält sozusagen eine virtuelle IP im eingewählten Netzwerk. Alles was in dem entfernen Netzwerk an diene virtuelle IP geht wird an deinen Client zurück geroutet.
Besonderheit: Du kannst mit deinem Client alle Hosts im deinem Zielnetz ansprechen, jedoch kann in deinem lokalen Netzt nur dein Client erreicht werden.
Daraus kann man schließen, dass wenn du Netzwerkdrucker im entfernten Netzwerk ansprechen willst und umgekehrt, eine Site-to-Site Verbindung benötigst. Bei einer Client-to-Site Verbindung geht es in der Regel nur über das Drucker-Umleiten in der RDP-Verbindung, was bei einer Site-to-Site-Verbindung natürlich auch möglich ist.
Und jetzt sage mir, wo würdest du deine seltsame Konstellation einordnen? Du musst erst einmal herausfinden welche dieser beiden Methoden für dich umsetzbar und geeignet ist, dann kann man dir bei deiner Netzwerkkonfiguration helfen und ins Detail gehen.