12
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 373251
Url: https://administrator.de/contentid/373251
Printed on: April 24, 2024 at 13:04 o'clock
12 Comments
Latest comment
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.
Hallo.
die gute Dame könnte ja mal die NIC Treiber auf den aktuellen Stand bringen...
Wird schwierig sein, Ihr das nahezubringen. Denn schließlich funktionierte es ja bisher, und sie hat ja "nichts gemacht"
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.
Andere Clients? ich nutze, um darauf zuzugreifen, die gleiche Methode - keine Probleme, heute früh, nachdem die Mail hereinkam, sogleich an 3 Rechnern getestet - keine Probleme.
Einfach ICMP-Tests oder URL aufrufen?
Der Beschreibung nach tritt das Problem sofort auf, nach dem die DynDNS-URL aufgerufen wird.
Gruß
Viele Grüße
von
departure69
HI,
ich meine mit gleichen Rechnern / Clients ihrem Ihrem Netz.
Hat sie evtl. Malware auf der Kiste?
Soll sie doch den PC mal mit bringen und von einem anderen Anschluss testen.
@ sie hat "nichts gemacht" -> Das kennen wir IT'ler doch zu gute ;)
Gruß
ich meine mit gleichen Rechnern / Clients ihrem Ihrem Netz.
Hat sie evtl. Malware auf der Kiste?
Soll sie doch den PC mal mit bringen und von einem anderen Anschluss testen.
@ sie hat "nichts gemacht" -> Das kennen wir IT'ler doch zu gute ;)
Gruß
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 ?!
Hallo.
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?
So isses.
Oder ist da ne VPN im Spiel?
Ja, der Internetzugang der Schule bei KD mußte dazu extra gebrickt werden, seither hängt ein Mikrotik am KD-Router, hat das Systemhaus eingerichtet.
hat sie das gleiche Problem auch, wenn die RDP Verbindung ohne den Webseitenaufruf aufgebaut wird, also direkt per mstsc ?
Der KD-Zugang der Schule hat keine feste IP, deshalb geht es (von zu Hause) gar nicht ohne die DynDNS-Webseite davor. RDP im internen LAN war damit noch nie ein Problem.
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.
Genau dies wird mir da anscheinend gerade versucht, unterzuschieben. War allerdings nicht meine Entscheidung, sondern eine Weisung der Schulleitung und meines Chefs. Ich hatte protestiert und vorgeschlagen, den Lehrern zu Hause (von mir bereitgestellte) ThinClients hinzustellen. War nicht genehm, weil die Mobilität gefehlt hätte, wenn, dann hätten es Notebooks sein sollen/müssen, und das wurde aus Kostengründen abgelehnt.
Und kontrolle über deine Netzwerksicherheit hast du auch nicht. Du weisst ja nicht ob deren Rechner mit nem Keylogger verseucht wurde.
Möglich, aber ohne Zugriff auf's Zielsystem sind die keygeloggten Daten meines Erachtens ziemlich wertlos. Und, sh. vorherigen Absatz, das war zum Glück nicht meine Entscheidung.
Viele Grüße
von
departure69
Die meisten der Lehrer hatten genügend Schwierigkeiten, meine genaustens beschriebene und mit Screenshots bebilderte Anleitung nur für einen Rechner zu befolgen, Du glaubst nicht, was das für ein Eiertanz war, bis das mal überall lief. Im vorliegenden Fall wüßte ich nicht mal, ob die Dame noch ein weiteren Rechner hat, an dem sie bereit wäre, dies nochmal auszuprobieren.
Hat sie evtl. Malware auf der Kiste?
Unbekannt. Nichts ist unmöglich.
Soll sie doch den PC mal mit bringen und von einem anderen Anschluss testen.
Hab' ich ihr soeben per Mail vorgeschlagen - hab' noch keine Antwort zurück.
Gruß
Viele Grüße
von
departure69
@aqui:
Hallo und Danke für Deine Antwort.
L2TP, wenn ich mich richtig erinnere.
Es gibt keinen VPN-Client im regelrechten Sinne, nicht am lokalen Rechner. Die DynDNS-URL wird aufgerufen, diese stellt die Remote-App bereit, beim Aufruf der Remote-App (Mausklick) wird RDP aufgerufen, und der RDP-Client verlangt nach dem Zertifikat. Der Tunnel "beginnt" somit meines Erachtens erst am DynDNS (der von dem vorgenannten Systemhaus gestellt wird). Ich kann das ja hier an meinem Bürorechner nachvollziehen, an den Netzwerkeigenschaften des lokalen Rechners ändert sich nach Verbindungsherstellung absolut gar nichts, der Tunnel ist am lokalen Rechner nirgends sichtbar.
Insbesondere deshalb fällt es mir ja auch schwer, der Dame das Geschilderte zu glauben.
Viele Grüße
von
departure69
Hallo und Danke für Deine Antwort.
WELCHES VPN
L2TP, wenn ich mich richtig erinnere.
VPN Client
Es gibt keinen VPN-Client im regelrechten Sinne, nicht am lokalen Rechner. Die DynDNS-URL wird aufgerufen, diese stellt die Remote-App bereit, beim Aufruf der Remote-App (Mausklick) wird RDP aufgerufen, und der RDP-Client verlangt nach dem Zertifikat. Der Tunnel "beginnt" somit meines Erachtens erst am DynDNS (der von dem vorgenannten Systemhaus gestellt wird). Ich kann das ja hier an meinem Bürorechner nachvollziehen, an den Netzwerkeigenschaften des lokalen Rechners ändert sich nach Verbindungsherstellung absolut gar nichts, der Tunnel ist am lokalen Rechner nirgends sichtbar.
Insbesondere deshalb fällt es mir ja auch schwer, der Dame das Geschilderte zu glauben.
Viele Grüße
von
departure69
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
@aqui:
Ich habe ehrlich gesagt nicht damit gerechnet, daß Du mir auch nur ein Wort glaubst, Du bist da meistens, und das auch zurecht, sehr genau und sehr kritisch.
Deshalb hab' ich das ganze jetzt mal mit Screenshots illustriert:
Verknüpfung:
Über DynDNS verbundene RDS-Webseite (dies ist der Punkt, an dem die Lehrerin schon die Probleme hat) mit den RDS-Remote-App-Verknüpfungen:
Angebotene Remote-App:
Verbindungsaufbau:
Anmeldemaske der RDS-Remote-App:
Fertig angemeldet:
ipconfig /all, nachdem die Anwendung verbunden ist und läuft:
Der VPN-Tunnel scheint lokal beim zugreifenden Client nicht auf. Nirgendwo. Der VPN-"Beginn" scheint woanders zu sein, wo auch immer. Ich glaube auch nicht, daß das für das Problem der Lehrerin von Bedeutung ist, sie scheitert ja angeblich bereits an der DynDNS-Webseite, mit den geschilderten Folgen.
Weiß vielleicht noch jemand etwas dazu?
Vielen Dank.
Viele Grüße
von
departure69
Ich habe ehrlich gesagt nicht damit gerechnet, daß Du mir auch nur ein Wort glaubst, Du bist da meistens, und das auch zurecht, sehr genau und sehr kritisch.
Deshalb hab' ich das ganze jetzt mal mit Screenshots illustriert:
Verknüpfung:
Über DynDNS verbundene RDS-Webseite (dies ist der Punkt, an dem die Lehrerin schon die Probleme hat) mit den RDS-Remote-App-Verknüpfungen:
Angebotene Remote-App:
Verbindungsaufbau:
Anmeldemaske der RDS-Remote-App:
Fertig angemeldet:
ipconfig /all, nachdem die Anwendung verbunden ist und läuft:
Microsoft Windows [Version 10.0.17134.5]
(c) 2018 Microsoft Corporation. Alle Rechte vorbehalten.
C:\WINDOWS\system32>ipconfig /all
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : PC-MUSTER
Primäres DNS-Suffix . . . . . . . : domaene.local
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : domaene.local
Ethernet-Adapter Ethernet:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection
Physische Adresse . . . . . . . . : 00-19-99-D0-4E-3E
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::34c7:903a:81ef:8bc2%13(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 10.12.23.53(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 10.12.23.230
DHCPv6-IAID . . . . . . . . . . . : 50338201
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1E-8B-C6-B0-00-19-99-D0-4E-3E
DNS-Server . . . . . . . . . . . : 10.12.23.6
10.12.23.45
NetBIOS über TCP/IP . . . . . . . : Aktiviert
C:\WINDOWS\system32>Der VPN-Tunnel scheint lokal beim zugreifenden Client nicht auf. Nirgendwo. Der VPN-"Beginn" scheint woanders zu sein, wo auch immer. Ich glaube auch nicht, daß das für das Problem der Lehrerin von Bedeutung ist, sie scheitert ja angeblich bereits an der DynDNS-Webseite, mit den geschilderten Folgen.
Weiß vielleicht noch jemand etwas dazu?
Vielen Dank.
Viele Grüße
von
departure69
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.
