DynDNS- + VPN-Zugriff auf RDS-Gateway-Webseite legt Internetverbindung lahm - kann das sein?
Hallo.
Ich betreue neben der Behörde, bei der ich angestellt bin, auch die zugehörige Grund- und Mittelschule.
Dort ist seit circa 2 Jahren ein Schulverwaltungsprogramm auf einem W2K12-RDS-Server im Einsatz. Der interne Zugriff innerhalb des Schul-LAN funktioniert per RDP-Client einwandfrei, jedoch wollten die Damen und Herren Lehrer irgendwann auch einen Zugriff von zu Hause aus.
Dies wurde per DynDNS i. V. m. zertifikatsbasierendem VPN (das VPN stellt ein Mikrotik am Kabel-Deutschland-WAN der Schule bereit) von einem Systemhaus realisiert.
Funktioniert ansich einwandfrei, selten mal gibt es Bandbreitenprobleme (Überbuchungsproblem Kabel Deutschland im Ortsgebiet, vor allem in den Abendstunden). Doch zuallermeist haut das, wie gesagt, einwandfrei hin.
Nun behauptet eine Lehrerin, daß der Aufruf der notwendigen DynDNS-URL die Internetverbindung Ihres Rechners zu Hause kappt/außer Gefecht setzt, sie müsse den Rechner danach stromlos machen (Neustart allein genügt angeblich nicht) und nach dem Windows-Start (OS unbekannt, vermutl. Win 7-10) eine Netzwerkproblemdiagnose durchführen, damit ihr Rechner überhaupt wieder ins Internet kommt.
Natürlich hat sie, kurz bevor oder seit das nicht mehr geht, nichts gemacht. Währenddessen, also während das Problem auftritt, seien andere Geräte, die mit ihrem Heim-DSL-Router verbunden sind, nicht betroffen und behielten ihre Internetverbindung, an ihrem Router läge es dann ja wohl nicht.
Meine Frage an Euch:
Kann das überhaupt sein?
Mal ganz simpel oder naiv gedacht: Wenn eine Webseite nicht erreichbar ist, dann ist sie eben, aus welchem Grund auch immer, erstmal nicht erreichbar.
Wie soll dies die Internetverbindung eines Rechners komplett lahmlegen und obendrein nach (angeblichem) Stromlos machen müssen und Neustart eine Netzwerkdiagnose und Reparatur erforderlich machen? Und danach das gleiche Verhalten, wenn die DynDNS-URL wieder aufgerufen wird? Mit dem Zertifikat kann das in diesem Schritt meines Erachtens noch gar nichts zu tun haben, das Zert. wird erst dann angefordert/abgeprüft, sobald die Remote-App aufgerufen wird, soweit kommt es hier bei dem geschilderten Problem aber gar nicht.
Also:
Kann das wirklich sein? Eine Webseite kann nicht aufgerufen werden, und dies legt die Interverbindung des Rechners lahm?
Danke Euch.
Viele Grüße
von
departure69
Ich betreue neben der Behörde, bei der ich angestellt bin, auch die zugehörige Grund- und Mittelschule.
Dort ist seit circa 2 Jahren ein Schulverwaltungsprogramm auf einem W2K12-RDS-Server im Einsatz. Der interne Zugriff innerhalb des Schul-LAN funktioniert per RDP-Client einwandfrei, jedoch wollten die Damen und Herren Lehrer irgendwann auch einen Zugriff von zu Hause aus.
Dies wurde per DynDNS i. V. m. zertifikatsbasierendem VPN (das VPN stellt ein Mikrotik am Kabel-Deutschland-WAN der Schule bereit) von einem Systemhaus realisiert.
Funktioniert ansich einwandfrei, selten mal gibt es Bandbreitenprobleme (Überbuchungsproblem Kabel Deutschland im Ortsgebiet, vor allem in den Abendstunden). Doch zuallermeist haut das, wie gesagt, einwandfrei hin.
Nun behauptet eine Lehrerin, daß der Aufruf der notwendigen DynDNS-URL die Internetverbindung Ihres Rechners zu Hause kappt/außer Gefecht setzt, sie müsse den Rechner danach stromlos machen (Neustart allein genügt angeblich nicht) und nach dem Windows-Start (OS unbekannt, vermutl. Win 7-10) eine Netzwerkproblemdiagnose durchführen, damit ihr Rechner überhaupt wieder ins Internet kommt.
Natürlich hat sie, kurz bevor oder seit das nicht mehr geht, nichts gemacht. Währenddessen, also während das Problem auftritt, seien andere Geräte, die mit ihrem Heim-DSL-Router verbunden sind, nicht betroffen und behielten ihre Internetverbindung, an ihrem Router läge es dann ja wohl nicht.
Meine Frage an Euch:
Kann das überhaupt sein?
Mal ganz simpel oder naiv gedacht: Wenn eine Webseite nicht erreichbar ist, dann ist sie eben, aus welchem Grund auch immer, erstmal nicht erreichbar.
Wie soll dies die Internetverbindung eines Rechners komplett lahmlegen und obendrein nach (angeblichem) Stromlos machen müssen und Neustart eine Netzwerkdiagnose und Reparatur erforderlich machen? Und danach das gleiche Verhalten, wenn die DynDNS-URL wieder aufgerufen wird? Mit dem Zertifikat kann das in diesem Schritt meines Erachtens noch gar nichts zu tun haben, das Zert. wird erst dann angefordert/abgeprüft, sobald die Remote-App aufgerufen wird, soweit kommt es hier bei dem geschilderten Problem aber gar nicht.
Also:
Kann das wirklich sein? Eine Webseite kann nicht aufgerufen werden, und dies legt die Interverbindung des Rechners lahm?
Danke Euch.
Viele Grüße
von
departure69
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 373251
Url: https://administrator.de/forum/dyndns-vpn-zugriff-auf-rds-gateway-webseite-legt-internetverbindung-lahm-kann-das-sein-373251.html
Ausgedruckt am: 02.04.2025 um 03:04 Uhr
12 Kommentare
Neuester Kommentar
HI,
die gute Dame könnte ja mal die NIC Treiber auf den aktuellen Stand bringen...
Dann könnte man schauen, ob die URL von ihrem PC überhaupt korrekt erreichbar ist, bzw. was mit den anderen Clients ist, wenn ihr PC nicht mag. Die könnten ja in dem Moment mal versuchen, die Verbindung aufzubauen.
Einfach ICMP-Tests oder URL aufrufen?
Gruß
die gute Dame könnte ja mal die NIC Treiber auf den aktuellen Stand bringen...
Dann könnte man schauen, ob die URL von ihrem PC überhaupt korrekt erreichbar ist, bzw. was mit den anderen Clients ist, wenn ihr PC nicht mag. Die könnten ja in dem Moment mal versuchen, die Verbindung aufzubauen.
Einfach ICMP-Tests oder URL aufrufen?
Gruß
Hi
klingt erst mal nicht plausibel. Was genau wird denn auf Anwenderseite gemacht? Die haben ein Clientzertifikat installiert und dann gehen die auf die dyndns seite worüber sie die RDP Session starten?
Oder ist da ne VPN im Spiel?
hat sie das gleiche Problem auch, wenn die RDP Verbindung ohne den Webseitenaufruf aufgebaut wird, also direkt per mstsc ?
Warum ist es bitte erlaubt, das die Leute sich mit ihrem privaten Rechner verbinden? Da bist dann nachher du für alles verantwortlich, was bei denen kaputt geht, weil das ja davor alles bestens funktioniert hat.
Und kontrolle über deine Netzwerksicherheit hast du auch nicht. Du weisst ja nicht ob deren Rechner mit nem Keylogger verseucht wurde.
klingt erst mal nicht plausibel. Was genau wird denn auf Anwenderseite gemacht? Die haben ein Clientzertifikat installiert und dann gehen die auf die dyndns seite worüber sie die RDP Session starten?
Oder ist da ne VPN im Spiel?
hat sie das gleiche Problem auch, wenn die RDP Verbindung ohne den Webseitenaufruf aufgebaut wird, also direkt per mstsc ?
Warum ist es bitte erlaubt, das die Leute sich mit ihrem privaten Rechner verbinden? Da bist dann nachher du für alles verantwortlich, was bei denen kaputt geht, weil das ja davor alles bestens funktioniert hat.
Und kontrolle über deine Netzwerksicherheit hast du auch nicht. Du weisst ja nicht ob deren Rechner mit nem Keylogger verseucht wurde.
Nur 1Cent für jedes mal wenn ich das höre.... und ich wäre schon lange in Rente.
das VPN stellt ein Mikrotik am Kabel-Deutschland-WAN der Schule bereit.
Hier wäre wichtig zu wissen WELCHES VPN Protokoll dieses "Systemhaus" auf dem Mikrotik konfiguriert hat. Bekanntlich supportet der ja mahrere VPN Protokolle (SSL, IPsec, PPTP, L2TP)Das nach dem Starten der VPN Verbindung das "Internet weg" ist kann durchaus sein wenn der VPN Client ein sog. Gateway Redirect macht, sprich das Default Gateway des Rechners auf die VPN Tunnelverbindung umschaltet.
Damit geht dann sämtlicher Traffic des Rechners ,auch der Internettraffic, in den VPN Tunnel.
Fehlt nun am anderen Ende, also des Schulstandorts, ein entsprechender Routing oder NAT Eintrag der diesen Traffic dann ins Internet weiterroutet dann ist dort Schluß und der Internettraffic blockiert.
Das Verhalten ist also mehr oder minder "normal" in Verbindung mit einer leider sehr Fehlkonfiguration des VPN Clients.
Dieses Forums Tutorial geht auf diese Problematik ein:
VPNs einrichten mit PPTP
(Thema: Standardgateway für das Remotenetzwerk !
Das man den Rechner dafür allerdings kaltstarten muss gehört wohl ins Reich der Märchen oder ist das Feedback einer wenig IT affinen Lehrerin ums politisch korrekt zu sagen.
Es reicht im allgemeinen den VPN Client zu stoppen. Damit wird das Gateway wieder auf den lokalen Router gesetzt und das Internet klappt dann wieder.
DynDNS wird übrigens ausschliesslich nur genutzt um die wechselnde Provider IP des VPN Routers mit einem festen Hostnamen zu kompensieren, denn man als Ziel IP des VPN Clients konfiguriert.
Mit dem VPN selber hat DynDNS soviel zu tun wie ein Fisch mit einem Fahrrad. Vermutlich weisst du das aber auch selber ?!
Es gibt keinen VPN-Client im regelrechten Sinne
Das kann niemals sein, den MUSS es immer geben ! Sonst ist das kein VPN und auch kein L2TP.Du meinst vermutlich das die dann einen Betriebssystem internen VPN Client nutzen, sprich also den das Betriebssystem gleich von sich aus mit an Bord hat wie z.B. hier beschrieben am Beispiel von IPsec:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Alles andere wäre ein technisches Wunder...
Der Tunnel "beginnt" somit meines Erachtens erst am DynDNS
Nein, das ist Unsinn. DynDNS ist ein DNS Dienst also rein etwas was Namen in IP Adressen umsetzt. Das hat mit VPN rein gar nichts zu tun technisch !Lesen hilft hier zum verstehen:
https://de.wikipedia.org/wiki/Dynamisches_DNS
der Tunnel ist am lokalen Rechner nirgends sichtbar.
Ein ipconfig -all sollte dir aber mindestens den virtuellen VPN Adapter zeigen und ein route print das Routing über diesen. Das schonmal ausgeführt ? Vermutlich nicht, oder ?Übrigens muss man keine 3 Antwortsthreads einzeln im 5 Minuten Rythmus tippen sondern kann sie auch mit @forumsname logisch in einer zusammenfassen
OK, das ist dann auch kein VPN !!!
Hier wird schlicht und einfach nur RDP sprich remote Desktop ungeschützt über das Internet geschickt auf einen RDP Server.
Das siehst du ja auch schon an den ganzen Microsoft Remote Desktop Symbolen. Ebenso der fehlende VPN Adapter in der Netzwerk Übersicht.
Das hat also rein gar nix mit VPN zu tun und ist nur einfaches RDP Forwarding. Ein böses Beispiel wie man es eigentlich NICHT machen sollte aber das beauftragte "Systemhaus" ist vermutlich eins mit sehr wenig Fachkompetenz um das mal vorsichtig auszudrücken und hat sich da mit minimalstem Aufwand aus der Verantwortung gestohlen.
Gut RDP benutzt eine gewisse Grundverschlüsselung ist aber wenig sicher wenn man es ohne weiteren Schutz einfach über das Internet schickt.
Hier wird schlicht und einfach nur RDP sprich remote Desktop ungeschützt über das Internet geschickt auf einen RDP Server.
Das siehst du ja auch schon an den ganzen Microsoft Remote Desktop Symbolen. Ebenso der fehlende VPN Adapter in der Netzwerk Übersicht.
Das hat also rein gar nix mit VPN zu tun und ist nur einfaches RDP Forwarding. Ein böses Beispiel wie man es eigentlich NICHT machen sollte aber das beauftragte "Systemhaus" ist vermutlich eins mit sehr wenig Fachkompetenz um das mal vorsichtig auszudrücken und hat sich da mit minimalstem Aufwand aus der Verantwortung gestohlen.
Gut RDP benutzt eine gewisse Grundverschlüsselung ist aber wenig sicher wenn man es ohne weiteren Schutz einfach über das Internet schickt.