Keine Verbindung zum Remote Desktop

Flash2over

New Member
Hallo SSF-Gemeinde,

Ich habe einen Ubuntu 12.04 Server am laufen. Dort habe ich xRDP installiert um eine Remote Desktop Verbindung zu haben.
Funktioniert hat alles einwandfrei, alle Ports sind freigegeben und ich konnte auch schon komplett Connecten. (Ich nutze einen Win7 rechner und die darauf installierte Remote-Desktop Software)

Jetzt kommen wir zum Problem: Ich habe ein bisschen mit Virtualisierung beschäftigt via KVM und vmbuilder. Seit ich das gemacht habe, kann ich nicht mehr zu meinem Remote Desktop connecten.

Es kommt die Fehlermeldung:
(Siehe Unten)

Ich suche jetzt schon 3 Tage nach dem Fehler und finde einfach nicht. Hatt vielleicht irgendwer einen Denkanstoß oder verdacht an was es liegen könnte?

Nochma zusammengefasst:
-Verbindung funktionierte
-Port 3389 ist nicht geblockt
-Nach KVM/vmbuilder Virtualisierung kommt Fehlermeldung von oben

Danke für die Hilfe
Gruß
Flash2over
 

Attachments

  • remotedesktop.jpg
    remotedesktop.jpg
    30.1 KB · Views: 213
Last edited by a moderator:
Soviel Text für "geht nicht" liest man selten. Wie wärs denn mit den wichtigen Fakten?
Läuft der Dienst überhaupt? (Bitte ausgabe von "ps faux")
Ist der Port gebunden? (Bitte Ausgabe von "netstat -lntpu")
Welche IPTables Regeln sind gesetzt? (Bitte Ausgabe von "iptables -L -n -v")
Wie sieht die Netzconfig aus? (Bitte Ausgabe von "ip a l" und "ip r l")
 
Bitte lade den Screenshot direkt an deinem Post hoch - es gibt einen Grund warum hier externe Bilderhoster nicht so beliebt sind ;)
 

Attachments

  • eset-warnung.png
    eset-warnung.png
    13.5 KB · Views: 172
@LordGurke:
Danke für den Hinweis, ich habs geändert.

@Firewire2002:

"ps faux" zeigt folgende Zeile:
Code:
xrdp      2786  0.0  0.0  18840   520 ?        S    20:21   0:00 /usr/sbin/xrdp
root      2788  0.0  0.0  29304   744 ?        S    20:21   0:00 /usr/sbin/xrdp-

"netstat -lntpu" zeigt folgendes:
Code:
tcp        0      0 0.0.0.0:3389            0.0.0.0:*               LISTEN

"iptables -L -n -v" finde ich keine Regel, daher komplette ausgabe:
Code:
Chain INPUT (policy ACCEPT 1182 packets, 111K bytes)
 pkts bytes target     prot opt in     out     source               destination
   72  3780 fail2ban-dovecot-pop3imap  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 110,995,143,993
   54  2934 fail2ban-pureftpd  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 21
    0     0 fail2ban-ssh  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 22
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      virbr0  0.0.0.0/0            192.168.122.0/24     state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  virbr0 *       192.168.122.0/24     0.0.0.0/0
    0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0
    0     0 REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT 1176 packets, 153K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain fail2ban-dovecot-pop3imap (1 references)
 pkts bytes target     prot opt in     out     source               destination
   72  3780 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain fail2ban-pureftpd (1 references)
 pkts bytes target     prot opt in     out     source               destination
   54  2934 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain fail2ban-ssh (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

"ip a l" gibt aus:
Code:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP qlen 1000
    link/ether a0:b3:cc:e2:60:39 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::a2b3:ccff:fee2:6039/64 scope link
       valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether a0:b3:cc:e2:60:39 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 brd 192.168.1.255 scope global br0
    inet6 fe80::a2b3:ccff:fee2:6039/64 scope link
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
    link/ether d6:23:d7:56:95:a9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0

"ip r l" gibt aus:
Code:
default via 192.168.1.1 dev br0  metric 100
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1
169.254.0.0/16 dev br0  scope link  metric 1000
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.100
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1
 
Dienst mal neugestartet?
Mal mit tcpdump geschaut, ob die Pakete überhaupt ankommen? (Falls sie unterwegs irgendwo gefiltert werden)
Mal mit strace an den Prozess dran gehangen, um zu schauen, ob er überhaupt was macht, wenn Pakete eingehen?
 
Den Dienst hab ich mehrfach neugestartet.

Ich habe nie etwas mit tcpdump gemacht, wenn ich aber richtig gelesen habe kann ich mit:

"sudo tcpdump -i eth0 'port 3389'"

den Port 3389 überwachen. Wenn das richtig ist, kommt wenn ich nach dem Connect versuch mit ^c abbreche:

0 packets captured
1 packet received by filter
0 packets dropped by kernel


Mache ich das richtig? Wenn ja kommt also nichts an und wird unterwegs schon abgefangen?
 
Yep, normalerweise kannst du mit tcpdump auch Pakete sehen, die von der Firewall des Servers gefiltert würden.
Auf welchem System hast du denn mit tcpdump mitgehorcht?
 
Ich habe momentan nur 1 System wirklich am Laufen. Das 2. das ich virtuell erstellt habe ist momentan gestoppt. War ja erstma nur für Testzwecke.
 
Achso, ich meinte damit ob du auf dem Hostsystem oder innerhalb der VM mit tcpdump reingehört hast ;)
 
Kannst du mal aus der betroffenen VM heraus folgenden Traceroute machen?

traceroute -T --sport=3389 deine.ip.zu.hause

Damit sollte man sehen, wo gefiltert wird.
 
Die IP zum server ist zu 1000% die Richtige.

Bei der Traceroute kommt:

(Siehe 1. Beitrag Seite 2)
 
Last edited by a moderator:
Uuups vergessen: Du musst den xRDP solange dafür stoppen ;)

Hast du zu Hause bei dir ein Linux-System? Muss nichts aufwändiges sein, es muss nur Traceroutes ausführen können. Das bringt auch deutlich akkuratere Ergebnisse.
Da würde der Befehl dann so aussehen:

traceroute -T -p 3389 die.ip.deines.servers
 
Jap aufs stoppen bin ich auch gekommen. Siehe edit oben.

Einziges Linux System das ich zuhause hab is mein Raspberry Pi. Ich werf den mal an und kuck ob sich da was tut.
 
Last edited by a moderator:
Ok die Ips zu verstecken bringt nichts. Da man ja sonst den Weg nicht nachvollziehen kann.

Hier von mir zum Server
sudo traceroute -T -p 3389 ip.des.servers
Code:
traceroute to ip.des.servers (ip.des.servers), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  1.998 ms  6.151 ms  6.004 ms
 2  217.0.118.175 (217.0.118.175)  45.484 ms  47.539 ms  49.153 ms
 3  87.186.249.42 (87.186.249.42)  50.489 ms  53.192 ms  57.265 ms
 4  l-eb2-i.L.DE.NET.DTAG.DE (62.154.89.110)  65.439 ms l-eb2-i.L.DE.NET.DTAG.DE (62.154.89.46)  91.616 ms l-eb2-i.L.DE.NET.DTAG.DE (62.154.89.110)  67.265 ms
 5  80.156.160.142 (80.156.160.142)  75.620 ms  76.894 ms  79.731 ms
 6  cr-erl1-te0-0-0-7.x-win.dfn.de (188.1.144.150)  83.667 ms  61.291 ms xr-gar1-te3-4.x-win.dfn.de (188.1.146.134)  62.524 ms
 7  xr-gar1-te3-3.x-win.dfn.de (188.1.144.109)  64.741 ms xr-stu1-te2-2.x-win.dfn.de (188.1.144.226)  65.159 ms  64.749 ms
 8  xr-fzk1-te1-4.x-win.dfn.de (188.1.145.129)  69.038 ms  67.572 ms  68.346 ms
 9  xr-kai1-te1-1.x-win.dfn.de (188.1.145.102)  72.206 ms xr-fzk1-te1-4.x-win.dfn.de (188.1.145.129)  68.894 ms xr-kai1-te1-1.x-win.dfn.de (188.1.145.102)  73.283 ms
10  xr-kai1-te1-1.x-win.dfn.de (188.1.145.102)  73.414 ms  74.953 ms kr-kai5-0.x-win.dfn.de (188.1.39.18)  77.177 ms
11  * * kr-kai5-0.x-win.dfn.de (188.1.39.18)  72.815 ms
12  kr-kai5-0.x-win.dfn.de (188.1.39.18)  71.003 ms !X * *

Hier vom Server zu mir:
sudo traceroute -T --sport=3389 meine.ip.addresse
Code:
traceroute to meine.ip.addresse (meine.ip.addresse), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  2.556 ms  1.431 ms  1.322 ms
 2  ciscoforelle-forelle.rhrk.uni-kl.de (131.246.228.254)  1.993 ms  1.780 ms  1.924 ms
 3  rauterx-ciscoforelle.rhrk.uni-kl.de (131.246.239.45)  1.673 ms  1.723 ms  1.673 ms
 4  atlas-rauterx.rhrk.uni-kl.de (131.246.2.81)  1.703 ms  1.774 ms  1.689 ms
 5  rauter-atlas.rhrk.uni-kl.de (131.246.2.84)  1.723 ms  1.738 ms  1.613 ms
 6  xr-kai1-ge5-1-200.x-win.dfn.de (188.1.39.17)  2.134 ms  1.976 ms  1.752 ms
 7  xr-fzk1-te2-4.x-win.dfn.de (188.1.145.101)  3.501 ms  3.517 ms  3.517 ms
 8  xr-stu1-te1-1.x-win.dfn.de (188.1.145.82)  6.401 ms  6.399 ms  6.325 ms
 9  xr-gar1-te4-4.x-win.dfn.de (188.1.144.229)  9.859 ms  9.586 ms  9.402 ms
10  cr-erl1-te0-7-0-4.x-win.dfn.de (188.1.146.133)  14.769 ms  14.750 ms  15.028 ms
11  80.156.160.141 (80.156.160.141)  19.436 ms  18.064 ms  17.951 ms
12  ma-ea2-i.MA.DE.NET.DTAG.DE (62.154.37.86)  26.163 ms  26.319 ms  26.111 ms
13  87.186.249.33 (87.186.249.33)  26.903 ms  27.030 ms  26.669 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
 
Im oberen Traceroute, der letzte Hop:

Das !X bedeutet laut Manpage "!X (communication administratively prohibited)", sprich irgendwas oder irgendwer filtert.

Mache nochmal einen Traceroute von deinem Raspberry aus, aber diesmal mit einem Port der definitiv offen und erreichbar ist (z.B. SSH), dann hat man was zum Vergleichen.
Die Meldung "administratively prohibited" kann auch von deinem System aus kommen - da es aber bereits beim DFN abbricht spricht vieles dafür dass der Router direkt danach das Paket nicht weiterleiten will.
 
Hier die Ausgabe zum Vergleich mit SSH Port

sudo traceroute -T -p sshport ip.meines.servers
Code:
traceroute to ip.meines.servers (ip.meines.servers), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  5.499 ms  5.028 ms  4.568 ms
 2  217.0.118.175 (217.0.118.175)  45.186 ms  46.582 ms  48.321 ms
 3  87.186.249.42 (87.186.249.42)  52.190 ms  52.363 ms  54.405 ms
 4  l-eb2-i.L.DE.NET.DTAG.DE (62.154.89.110)  64.012 ms l-eb2-i.L.DE.NET.DTAG.DE (62.154.89.46)  64.591 ms l-eb2-i.L.DE.NET.DTAG.DE (62.154.89.110)  68.350 ms
 5  80.156.160.142 (80.156.160.142)  76.127 ms  77.092 ms  78.980 ms
 6  xr-gar1-te3-4.x-win.dfn.de (188.1.146.134)  100.750 ms cr-erl1-te0-0-0-7.x-win.dfn.de (188.1.144.150)  61.793 ms xr-gar1-te4-1.x-win.dfn.de (188.1.146.138)  63.962 ms
 7  xr-stu1-te2-2.x-win.dfn.de (188.1.144.226)  75.055 ms xr-gar1-te3-3.x-win.dfn.de (188.1.144.109)  65.803 ms  68.364 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * rauterx-atlas.rhrk.uni-kl.de (131.246.2.80)  72.726 ms
13  ciscoforelle-rauterx.rhrk.uni-kl.de (131.246.239.44)  72.075 ms  73.727 ms rauterx-atlas.rhrk.uni-kl.de (131.246.2.80)  74.175 ms
14  forelle-server.wohnheim.uni-kl.de (131.246.228.185)  76.714 ms ciscoforelle-rauterx.rhrk.uni-kl.de (131.246.239.44)  87.174 ms hostname.meines.servers (ip.meines.servers)  80.502 ms
15  hostname.meines.servers (ip.meines.servers)  84.730 ms  86.196 ms  87.599 ms
 
Das sieht wirklich schwer danach aus, als wenn ein Router direkt nach dem DFN diese Pakete filtert. Da müsstest du mal wen nach dem tieferen Sinn fragen, der da fürs Netzwerk zuständig ist.
 
Back
Top