So sieht die Situation aus. Ich bin technisch versiert, aber nicht so versiert in Netzwerktechnik. Ich versuche, per Remote Desktop eine Verbindung von meinem MacBook Pro zu meinem Desktop-PC herzustellen. Es funktioniert, wenn ich die Verbindung über die interne, statische IP meines Desktops herstelle, aber ich kann keine Verbindung über das Internet herstellen. Der Hauptgrund, warum ich eine Remote-Verbindung herstellen möchte, ist, dass ich unterwegs einfach per Remote auf meinen Heimcomputer zugreifen und mit den Ressourcen meines Desktops arbeiten kann.
Ich kann mit meinem Internetdienst keine statischen IP-Adressen erhalten, daher verwende ich noip.org, um eine benutzerdefinierte Domäne in meine aktuelle dynamische IP aufzulösen.
Ich habe einen 4G LTE-Internetdienst für zu Hause von AT&T. Zuvor war ich bei Verizon (derselbe 4G-Dienst). Bei Verizon hat alles gut funktioniert. Seit dem Wechsel zu AT&T funktioniert es nicht mehr und es gibt ein paar rätselhafte Fakten.
Hier sind einige der Dinge, die Sie wissen müssen:
- Ich habe meinem Desktop eine statische interne IP-Adresse zugewiesen (192.168.0.11).
- Ich habe Port 3389 (TCP + UDP) an 192.168.0.11 auf meinem AT&T-Router weitergeleitet.
Das sollte alles sein, was ich tun muss. Ich weiß, dass mein Desktop richtig eingerichtet ist, da er mit Verizon funktioniert hat und mit internen IP-Adressen funktioniert. Mein MacBook ist so eingerichtet, dass es eine Verbindung zu „mysubdomain.noip.org“ herstellt. Auch das hat mit Verizon funktioniert. Da es nicht funktioniert, nehme ich das aus der Mischung und versuche einfach, meine öffentliche IP dort einzufügen.
Ich habe jedoch Probleme, überhaupt herauszufinden, wie meine öffentliche IP lauten sollte. Überall, wo ich nachschaue, heißt es, dass meine öffentliche IP anders ist. Hier ist ein Beispiel dafür, was verschiedene Quellen derzeit sagen (ich habe die letzte Zahlenreihe aus Datenschutzgründen geändert).
- NO-IP: 166.176.59.201
- whatismyip.org: 166.170.14.69
- checkip.dyndns.org: 166.170.14.69
- Google: 166.176.59.216
166.170.14.69 ist der einzige, der auf einen Ping antwortet.
Ich bin mir nicht sicher, warum ich bei allen ein anderes Ergebnis bekomme (außer bei den beiden in der Mitte). Der erste Schritt besteht meiner Meinung nach darin, herauszufinden, was meine tatsächliche öffentliche IP ist, und zu versuchen, eine Verbindung damit herzustellen.
Der zweite Schritt wäre herauszufinden, warum no-ip.org nicht die „richtige“ IP-Adresse auflöst. Ich muss dafür sorgen, dass sie die richtige IP-Adresse auflösen können, damit ich von entfernten Standorten aus zuverlässig eine Verbindung zu meinem Heimrouter herstellen kann.
Irgendwelche Vorschläge?
BEARBEITEN: Trace-Info zu 8.8.8.8:
C:\Users\scott>tracert 8.8.8.8
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms 192.168.0.1
2 48 ms 39 ms 40 ms 172.26.96.169
3 220 ms 48 ms 41 ms 172.26.96.9
4 42 ms 37 ms 40 ms 107.72.231.164
5 71 ms 38 ms 41 ms 12.83.188.161
6 94 ms 44 ms 52 ms 12.83.179.49
7 99 ms 52 ms 43 ms 12.123.132.173
8 * 48 ms 49 ms 12.91.217.158
9 * * * Request timed out.
10 112 ms 43 ms 44 ms 64.233.174.190
11 69 ms 68 ms 79 ms 72.14.239.160
12 66 ms 74 ms 63 ms 216.239.46.171
13 * * * Request timed out.
14 75 ms 68 ms 69 ms google-public-dns-a.google.com [8.8.8.8]
Trace complete.
Antwort1
Ich vermute, dass NATing auf der ISP-Seite stattfindet. Dies kann schwierig zu umgehen sein, da Sie auf dieser Ebene der Konfiguration keine Kontrolle haben. Ich habe zwei Lösungen, die Sie ausprobieren könnten:
1) Richten Sie Chrome Remote Desktop über den Chrome-Browser ein. Ich glaube, das funktioniert, indem es von den Google-Servern abprallt und somit ein NAT durchschlägt, da es von beiden „Clients“, Ihrem MacBook und Ihrem Heim-Desktop, eingerichtet wird.
https://chrome.google.com/webstore/detail/chrome-remote-desktop/gbchcmhmhahfdphkhkmpfmihenigjmpp
2) Richten Sie ein VPN ein, mit dem Sie sich verbinden, und verwenden Sie dann Ihr lokales RDP, da Sie sich im selben (virtuellen) privaten Netzwerk befinden. Ihr Computer wird den Unterschied nicht bemerken, außer vielleicht ein bisschen mehr Verzögerung. So etwas sollte helfen: https://secure.logmein.com/products/hamachi/download.aspx
Antwort2
Ich habe genau dieses Problem vor ein oder zwei Tagen gelöst ... habe jede Variante von NAT-Loopback und UPNP auf meinem Router ausprobiert, ohne dass sich etwas geändert hätte. Pixel 2 hat entweder eine Zeitüberschreitung oder es wurde ein einzelner Desktop-Frame angezeigt, konnte aber nicht interagieren und hat kurz darauf eine Zeitüberschreitung. Unter 4G funktioniert es perfekt.
Für mich hat es das Problem gelöst, indem ich auf dem Host die Option „Einige Geräte können ohne PIN eine Verbindung herstellen“ deaktiviert habe. Solange ich bei jeder Verbindung meine PIN eingebe, funktioniert es jedes Mal im selben Netzwerk. Wenn ich sie speichere, funktioniert es bei der ersten Verbindung, aber nie wieder.
Sagen Sie mir Bescheid, ob dies auch Ihr Problem ist. Ich war sprachlos, als es funktionierte, aber ich hatte keine Möglichkeit, es jemals herauszufinden, denn sobald Sie das Kontrollkästchen zum Verbinden ohne PIN aktivieren, wird Ihnen die Option nie wieder angezeigt, ohne die App-Daten zu löschen oder sie auf dem Host zu deaktivieren.