RDP aus VPN herausnehmen

[jomaster]

Hallo liebe CB-ler,

ich hoffe ihc hab das richtige Forum dafür erwischt ^^

Geht um folgendes: Ich hab daheim einen Rechner stehen, der 24/7 über eine VPN Verbindung mit der Arbeit verbunden ist. Wenn ich außerhalb bin und kurz was machen möchte, schalt ich mich via mstsc.exe auf den Rechner auf (Im Router ist ein Dyndns hinterlegt samt PortForwarding). Die Verbindung klappt wunderbar, Office arbeiten lassen sich damit wunderbar erledigen. Nur sobald ich nun irgendwas graphisch Anzeigen möchte, oder mal irgendwelche Bildreichen Seiten bei Google scrolle, fängt das an zu laggen, dass nichts mehr geht! Ich vermute, dass die Verbindung zwar über den router an den PC weitergeleitet wird, aber die Antwort über das VPN geht und dann von der Firma zu mir kommt. Zudem braucht die RemoteVerbindung meine ganze Upload Leistung daheim auf, bis zu 1200kbit/s. Da kann ich auch noch 15-Bit High Color Farbtiefe oder geringe Bandbreite bei den RDP Einstellungen wählen, die Leitung ist voll und es lagt.

Nun zur Frage, gibt es irgendeine möglichekeit den 3389 Port auf die Netzwerkkarte zu "branden"? Also, dass alle Verbindungen weiter über VPN laufen nur das RDP Protokoll direkt kommunizieren kann?
Wie verringere ich den benötigten Upload? Zu mir hat man gesagt, dass 40-100kbyte/s locker langen, in dem Rahmen lieg ich ja, aber scheinbar >.> langts ja nicht.

Genutzt wird zum Verbinden Windows 8.1, der RemoteDestkop nutzt Windows 8.1 N und das VPN wird über oVPN aufgebaut.


Vielen Dank für eure Hilfe!!!

 

[Sithys]

Naja, wenn Du die komplette Bandbreite von 1200kbits aufbrauchst entspricht das 150 byte. Wie dem auch sei, direkt auf die netzwerkkarte branden ist nicht möglich soweit ich weiß. Geht da nichts mehr über forwarding?

 

[HominiLupus]

Nein. Wenn du auf die IP des Heimrouters gehst wird nur diese verwendet, auch für die Antworten. Das VPN wird nur bei ausgehenden Verbindungen automatisch genutzt.

 

[conf_t]

Du darfst, wenn du dich in VPN Einwählst nicht die Einstellung zulassen, dass alle Anfragen an das Remote Gateway geleitet werden. So wird dann alles getunnelt. Ob das aber die VPN Einwahl der Firma zu lässt weiß ich nicht.
Du bräuchtest die Konfiguration, dass nach Einwahl erst mal nichts getunnelt wird, außer die Adressen der Firma. Dazu muss man die Netzbereiche der Firma kennen, sie dürfen sich nicht mit deinem privaten Netzbereich überschneiden, wie gesagt muss das die Einwahlsoftware zulassen und du müsstest ggf. wahrscheinlich entsprechende Routen eintragen, die einmal zu dem Tunnel-Interface für die Firma zeigen und den Rest an deinen Router als Default-Gateway weitereliten.

Bei meinem Privaten OpenVPN ist sowas kein Problem, bei meinem FritzVPN auch nicht. Bei meinerm FirmenVPN ist das aber unterbunden, da wird nach Einwahl alles über den Tunnel gezwungen - ist halt ein Sicherheits- und Datenschutzthema.

@ Über mir, es reicht nicht wenn der Router die Route zum Client kennt, der Client muss auch die Route zurück kennen. So kann zwar der Download über den Router kommen, der Upload würde aber über das VPN geroutet. Nennt sich dan Asynchrones Routing. Kommt auch auf die eingerichtete Metric in der Routingtabelle des Clients an.

@ Lags bei RDP: Bei kleiner Bandbreite lags sowas immer bei Bilder. Besser Farben weiter reduzieren oder damit leben, oder mehr Bandbreite.

 

[Switcher94]

Naja mit 1MBit Upload kannst halt nicht viel reissen, Bilder brauchen Bandbreite wenn die nicht vorhanden ist gehts nichts mehr.

Öffne die seiten die laggen mal auf nem PC mit 1MBit Download, da wird es sehr wahrscheinlich genau so aussehen wie via RDP

 

[razzy]

Da du dich ja über deine DynDNS Adresse auf deinen Rechner anmeldest, wird eine Verbindung von dir (iwo auf der Welt) und deinem Rechner direkt aufgebaut ohne VPN.
Sprich der Router bekommt in "" nichts von der VPN Einwahl deines Rechners mit.

Würde deine VPN-Verbindung über deinen Router laufen, wäre dies jetzt ein anderes Thema, aber so bist du direkt mit deinem Rechner verbunden ohne VPN

 

[HominiLupus]

@ Über mir, es reicht nicht wenn der Router die Route zum Client kennt, der Client muss auch die Route zurück kennen. So kann zwar der Download über den Router kommen, der Upload würde aber über das VPN geroutet. Nennt sich dan Asynchrones Routing. Kommt auch auf die eingerichtete Metric in der Routingtabelle des Clients an.

Wenn eine Verbindung an 1.2.3.4:3389 ankommt dann wird die Antwort auch auch Interface 1.2.3.4 gesendet und NICHT an die VPN 10.1.2.3 Verbindung. Sonst wäre das ja eine neue Verbindung und wie sollte der RDP Client sowas wissen oder auch nur annehmen können.
Das VPN hat mit seiner RDP Verbindung nichts, aber auch gar nichts zu tun ausser die VPN Verbindung braucht auch grade Upload: der wird ja zwischen VPN und RDP geteilt.

 

[jomaster]

Naja, wenn Du die komplette Bandbreite von 1200kbits aufbrauchst entspricht das 150 byte.

Wenn aber nur 100byte theoretisch gebraucht werden hätte ich ja die 1,5 fache Kapazität.

@ Über mir, es reicht nicht wenn der Router die Route zum Client kennt, der Client muss auch die Route zurück kennen. So kann zwar der Download über den Router kommen, der Upload würde aber über das VPN geroutet. Nennt sich dan Asynchrones Routing. Kommt auch auf die eingerichtete Metric in der Routingtabelle des Clients an.

Das war eben mein Gedanke, dass er zwar den Weg hinkennt, aber der weg zurück über das VPN und dadurch die Probleme verschlimmert werden.
Wie kann ich herausfinden, welchen Weg RDP nimmt?

Wenn eine Verbindung an 1.2.3.4:3389 ankommt dann wird die Antwort auch auch Interface 1.2.3.4 gesendet und NICHT an die VPN 10.1.2.3 Verbindung. Sonst wäre das ja eine neue Verbindung und wie sollte der RDP Client sowas wissen oder auch nur annehmen können.

Das ist ja die große Frage ^^ Wird es eben asynchron geroutet oder nicht? Ich kenn das RD-Protocol nicht, aber dem dürfte es doch egal sein, ob auf dem weg hin und zurück eine andere Route genommen wird, solange die Packages vom Absender richtig ankommen. Ansonsten müsste es ja sowas wie z.B. RSVP unterstützen? Aber da kenn ich mich eben nicht aus

Wieviel Bandbreite bräuchte ich, dass es einigermasen geht? Bzw. ich kann beim mstsc nur 15Bit TrueColour als niedrigste Eingeben, gibts ne möglichkeit das ganze auf 8 oder 6 Bit zu reduzieren?

 

[conf_t]

Schau erst mal wenn du eingewählt bis in die Routingtable des Clients
CMD -> route print
es kleiner die Metric desto besser, schaust mal, welche metric für das Netz des Clients von wo aus du RDP ausführst da steht. Sollte es nicht explizit aufgeführt sein, wird es die default route nehmen (0.0.0.0) die zeigt dann ein Gateway.

Du kannst das auch mit einem Tracert von dem Rechner, der auch im VPN ist nachvollziehen.

Dem RDP ist egal, ob asynchron oder nicht, da es auf TCP basiert und TCP kann asynchrones Routing mitmachen.
Wir bewegen uns hier eine Schicht tiefer auf IP Ebene.

Ob das Routing synchron ist und nur der Upload Bottleneck das Problem ist oder auch noch zusätzlich ein (mögliches) asynchrones Routing vorliegt muss man klären.

PS: Ein Festeinstellen der TCP Ports hilft in keinem Fall, weder bei zu wenig Bandbreite, noch bei asynchronem Routing, da wie gesagt, es dem TCP Protokol wurscht ist welche Route es nimmt, solange es ankommt.

 

[razzy]

@ Nicht ich: es ist egal welche routen er hat.

Die Default Route dient nur dazu, das der Rechner alles dahin routet, wo er nicht weiß woher.

Da er aber über der DynDNS adresse geht, wird er über den Router kommen (ÖffentlicheAufgelösteIP:3389) die wiederum vom Router an den Rechner weitergeleitet wird (192.168.1.25:3389).

Und da es sich hier um TCP handelt, schickt der Rechner auch die Antwort auf diesem Wege wieder zurück.

Auch auf IP Ebene wird es so erklärt, da in der Routingtabelle neben der Default Route auch noch die lokalen Routen vorhanden sind, und da diese eher passen als die Default Route, wird diese auch genommen

Sprich das VPN ist wie oft schon gesagt egal, ob es aktiviert ist oder nicht.

Wenn das VPN über den Router aufgebaut wäre, dann wäre es eine komplett andere Hausnummer aber so nicht.

 

[conf_t]

Die Default Route dient nur dazu, das der Rechner alles dahin routet, wo er nicht weiß woher.

Korrekt​

Da er aber über der DynDNS adresse geht, wird er über den Router kommen (ÖffentlicheAufgelösteIP:3389) die wiederum vom Router an den Rechner weitergeleitet wird (192.168.1.25:3389).

Unabhängig von dem hier gelagerten Fall. In den meisten Fällen ja, u.U. insbesondere bei mehreren logischen WAN(Internet Verbindung stimmt es wieder nicht zwingend.​

Und da es sich hier um TCP handelt, schickt der Rechner auch die Antwort auf diesem Wege wieder zurück.

Größter Unsinn den ich je gehört habe. TCP ist egal ob synchron oder asynchron, aber muss nicht zwingen den gleichenweg zurück nehmen. Weil die Route in Routingprotokollen entschieden wird und nicht im TCP-Handshake.​

Auch auf IP Ebene wird es so erklärt, da in der Routingtabelle neben der Default Route auch noch die lokalen Routen vorhanden sind, und da diese eher passen als die Default Route, wird diese auch genommen

Hier widerpsrichst du der Intension deines Posts und folgst meiner Argumentation. Ist eine lokale Route vorhanden wird diese bevorzugt, abhängig von der VPN-Konfiguration kann das der Fall sein, sofern er über auch über das FrimenVPN zugriff auf das Internet hat. Durch die EInwahl in ein VPN werden zusätzliche lokale Routen hinzugefügt. Entsprechende Anfragen werden dann garnicht mehr zum lokalen physikalische Gateway geleitet.​

Wenn das VPN über den Router aufgebaut wäre, dann wäre es eine komplett andere Hausnummer aber so nicht.

Aha, ein PC kann also nicht routen? Sehr interessant. Wenn ich meine Routingtable im PC anpassen macht er nicht mehr das, was man im allgemeinen glaubt -> siehe wieder VPN Konfig. Ich kenne das bei unserem VPN in der Firma so, dass alle Verbindungen durch das VPN gezwungen werden. Da kann man nicht mal mehr auf ein Share im gleichen LAN zugreifen. Alles geht über das Tunnelinterface. Bei meiner privaten VPN Konfig, sehe ich davon ab und lasse beides "parallel" laufen. Der Unterschied zwischen einem VPN über Router oder per SW am PC ist doch nur der, dass ich beim Router, da er im Heimnetz auch GW ist, keine Routen an den Endgeräten hinzufügen muss, sondern das eben das Gateway übernimmt. Somit ist es egal ob das VPN am Router oder am PC aufgespannt wird.​

PS: Muss man mit den Zertifikaten in der Signatur angeben? Ich weiß selbst aus genügend Kursen, dass gerade die Cisco Zertifikate absolut nichts über die persönliche Fähigkeiten sagen. Zwischen Auswendiglernen und Verstehen gibt es halt Unterschiede. Gerade CCNA ist doch Mumpitz und sowieso Vorraussetzung für CCNP.

 

[razzy]

jomaster: Kannst du mal bitte einen Screenshot von dem CMD Befehl route print machen ? Interessant wäre der IPv4 Teil, sofern du kein IPv6 verwendest.

 

[Raijin]

Hier kann noch lange über Routing und dergleichen diskutiert werden, ich schlage einen simplen Test vor: VPN abschalten und dann von außen per RDP einloggen. Ist es dann immer noch so lahm hat das VPN nichts damit zu tun.

Ich weiß nicht wie performant RDP ist, aber evtl. könnte man mal andere Tools ausprobieren, zB VNC. Evtl. geht es damit etwas besser.

 

[jomaster]

Ich habs jetzt ausprobiert, scheint wirklich asynchron gerouted wird.
Mit aktiver VPN Upload am Anschlag mit Lags, Leitungsauslastung über 1MBit/s
Mit deaktiveren VPN Upload bei 250 ohne lags, Leitungsauslastung über 250kbit/s

route draw -p ohne VPN

route draw -p mit VPN

 

[conf_t]

Also wenn du im VPN eingewählt bist scheint alles durch das VPN zu gehen, was von dir aus weg geht.
Folgende Einträge:
0.0.0.0 bis 127.255.255 ==> Netzmaske /1 ==>> Wegen /1 ist es keine Nullroute mehr, daher als "besser" angesehen, trotz schlechterer Interfacemetrik
und ein paar Zeilen tiefer folgt der Rest
128.0.0.0 bis 255.255.255.255 das gleichen Spiel. Für beide Netzbereiche, die im Prinzip zusammengenommen, das gesamte Internet und alles andere Abbilden wirde durch das 172er VPN Interface als "erreichbar" markiert.

Im Prinzip auch ähnlich wie eine Nullroute, da aber die Netzmaske nicht /0, sondern /1 ist, eben stärker als eine Nullroute.

Da dann also dein gesamter Traffic vom PC aus über das VPN geleitet wird. hast du selbst ohne asynchrone Routing eine schlechtere Performance.

Ob es wirklich asynchron ist, kann man erst sagen, wenn man die Routen der Gegenstelle kennt. Anhand der Bitrate lässt sich dass an deinem Messpunkt nicht feststellen.

Du könntest dass durch ändern / löschen der Einträge überigens manipulieren, ob das vom VPN Betreiber aber gewollt ist, steht auf einem andere Blatt.