IThome

Das sind wahrscheinlich nur vorgefertigte, RDP ist nicht dabei, aber das hast Du ja selbst definiert ...

Sieht eigentlich nicht schlecht aus, wenn die 192.168.0.1 die Adresse Deines Rechners ist ...

Via externem Filehoster ...

Jein, es kommt darauf an, ob die Routerfirewall ausgehend beschränkt ist. Wenn nicht, dann musst Du nichts mehr freigeben. Du musst auf Deinem Router nur Portweiterleitungen konfigurieren, wenn von aussen jemand auf Deinen Rechner rauf soll (initiierte Verbindung). Wenn Du ZA deinstallierst, dann schalte die Windows-Firewall an und definiere eine Ausnahme für RDP (beachte den Bereich). Allerdings würde ich eine Remotedesktopverbindung auf einem Rechner, der direkt am Netz hängt und nur durch die Windowsfirewall geschützt ist, niemals erlauben ... Die Verbindung ist offen und für jedermann erreichbar ...

NEIN, KEIN PORTFORWARDING IN DEINEM ROUTER (alles gross, um es nochmal zu betonen). Du musst nur, falls notwendig, eine ausgehende Regel für TCP 3389 haben, kein Portforwarding. Oder soll der Kollege auch bei Dir via Remotedesktop rauf ? Was heisst, Du hast "alles" für RDP freigegeben ? Was ist alles ?

XP-Prof kannste via Remotedesktop ansprechen. Dein Freund muss auf seinem Router eine Portweiterleitung zur IP-Adresse seines Rechners machen. Du musst an Deinem Router/Firewall (falls Outgoing beschränkt wird) TCP 3389 in ausgehender Richtung zulassen, sonst musst Du gar nix machen. Wenn Dein Kollege keinen Router hat, also direkt am Modem hängt, dann blockiert dessen Firewall (was ist da freigeschaltet ?)

Wenn sich der Rechner Deines Freundes ausserhalb befindet, welche Adresse gibst Du denn im Remotedesktopclient ein ? Dein Freund muss die Portweiterleitungen definieren, nicht Du ... Bei einer Home Version gibt es kein Remotedesktop, nur Remoteunterstützung (oder meinst Du das ) ? Im Zweifel deinstalliere mal dieses räudige Zonealarm (welchen IP-Bereich hast Du freigeschaltet, das gesamte Internet oder Deinen privaten Bereich ? )

Die Suffixe werden wahrscheinlich über DHCP verteilt, schau da mal als erstes nach. Sie können aber auch in den Eigenschaften der WLAN-Verbindung - Internetprotokoll eingestellt sein. Gib dem Client zum Test mal ne feste IP-Adresse und einen festen DNS-Servereintrag (Gateway ist zum Test nicht unbedingt notwendig) ... Ich nehme mal an, dass der Zugriff auf den Server nach der Anmeldung reibungslos funktioniert ?! Prüfe auch mal, ob Du VOR der Anmeldung den WLAN-Rechner schon anpingen kannst (eventuell seine Firewall anpassen) ...

Du gibst im TS-Client die Dyndns-Adresse an ? Der Router leitet den TCP-Port 3389 zur entsprechenden IP-Adresse des zu steuernden Rechners weiter ? Der Rechner hat eine aktive Windows-Firewall ? Ist eine Remote Desktop Ausnahme erstellt worden (auch für den richtigen Bereich) ? Ist Remote Desktop überhaupt aktiviert worden ? Ist es mindestens XP-Professionell ? edit: fast rechtzeitig, aber nur fast :D ...

Wie einfach an Windows anschliessen ? Ein NAS hat in der Regel einen eigenen RAID-Controller, der die Ausfallsicherheit garantiert. Also Platten raus und an ein NAS gleichen Typs anschliessen z.B. oder die defekte Elektronik des NAS-Gerätes austauschen (lassen) ... edit: knapp, aber doch zu spät :D

Das graue "DE" ist eine Delegierung. Normalerweise macht man das so (wenn die Zonen wie bei Dir auf verschiedenen DNS-Servern verwaltet werden sollen): DNS ist auf den Servern DC01 und DC03 installiert. DC01 hostet die Zone CONTOSO.COM und delegiert die Zone DE.CONTOSO.COM an DC03. Dieser hostet die Zone DE.CONTOSO.COM und hat eine bedingte Weiterleitung für CONTOSO.COM erreichbar über DC01. Wenn Du DNS lernen willst, dann lasse für´s erste WINS weg, da sich sonst die Ergebnisse und damit auch das Verständnis verfälschen lassen. Baue erstmal eine funktionierende DNS-Umgebung auf und setze, nachdem Du das verstanden hast, WINS ein. Ich denke, der löst Dir den DC03 via WINS-Lookup auf. edit: oh, ich hab was übersehen ... Die Namensauflösung klappt offensichtlich von oben nach unten unter Angabe des FQDNs, klappt sie auch von unten nach oben (ohne Weiterleitung) ?

DNS-Konfig ist nicht sauber, der Router gehört da nicht rein, nirgendwo. Und was soll die 192.168.2.10 in der Suffixsuchliste und als Verbindungssuffix ? Wird das WLAN von Windows selbst gesteuert oder isteine da spezielle Software drauf ? Ist das WLAN ganz sicher schon vor der Anmeldung verfügbar ? Wenn Du die Windowssteuerung benutzt setze auf dem Notebook mal folgenden Regkey ... Group Policy application fails on a computer that is running Windows 2000, Windows XP Service Pack 1, or Windows XP Service Pack 2

Du machst zwei verschiedene Auflösungen, einmal Forward und einmal Reverse. Existiert ein Hosteintrag DC03 in der Forward Lookupzone CONTOSO.COM ? Beschreibe, wer welche Zonen hostet, wer welche Weiterleitungen/Delegierungen konfiguriert hat. Und poste vom DC01.CONTOSO.COM und vom DC03.DE.CONTOSO.COM die Ausgabe von IPCONFIG /ALL (wie Matthias schon geschrieben hat). Und teste alles unter Angabe vom FQDN, nicht von einem unvollständigen Namen ...

Wenn es auch einen DC03.CONTOSO.COM gibt (oder zumindest einen A-Eintrag), dann ist die Ausgabe normal. Da Du einen unvollständigen Namen angibst, werden nach den Regeln der Auflösung unvollständiger Namen Suffixe angehängt, in Deinem Fall CONTOSO.COM (der primäre DNS-Suffix). Teste die DNS-Funktionalität zuerst mit FQDNs ...

Schau Dir mal diesen Thread an ... http://www.mcseboard.de/windows-forum-ms-backoffice-31/usern-starten-stoppen-dienstes-erlauben-86287.html Es gibt auch noch mehrere andere, die Du über die Suchfunktion finden kannst. Ich denke, dass Du mit SC.EXE, ausgeführt von einem Client aus mit nur Benutzerrechten, nicht weiter kommst, mit SVCUTIL allerdings schon (kannst ja mal testen) ...

Poste mal IPCONFIG /ALL des Clients und die Ausgabe von NETDIAG (ohne die KBs) des Servers. Lade Dir dazu die Support Tools herunter und installiere sie auf dem Server ... Windows Server 2003 Service Pack 1 Support Tools

Man kann einen Haken in den Eigenschaften des Startmenüs setzen (zu erreichen über Rechtsklick - Taskleiste) ...

Hehe, sind bestimmt Funktastaturen- und/oder Mäuse beteiligt ...

Abwarten ... ;)

Ja genau, deswegen die Route, die Du auf einem Client eingeben solltest. Offensichtlich funktioniert der Zugriff über die Fortigate und den RRAS ja grundsätzlich. Ich denke auch, dass es ein Routingproblem ist. Du kannst ja mal als Default Gateway auf einem Client den RRAS eintragen ...

Gib einfach CONTROL USERPASSWORDS2 ein ... :)

Nochmal zum Verständnis :D Die Fortigate ist mit dem RRAS in Standort 1 verbunden. Während dieser Verbindung kann man vom RRAS aus den DC2 anpingen. Man kann aber nicht von einem Client im Netz des RRAS den DC 2 anpingen. Verbindest Du Dich von aussen via PPTP mit dem RRAS in Standort 1 und ist die Verbindung zwischen der Fortigate und dem RRAS hergestellt, dann kannst Du DC2 vom Notebook aus anpingen. Alles richtig ?

Meiner Meinung nach liegt es an der fehlenden Unterstützung von DNAME Resource Records eines 2000 DNS Servers. Ein 2003 Server hatte dieses Problem bis zu einem gewissen Patchlevel auch, da gab es aber einen Hotfix und wurde auch mit neuem Servicepack behoben. Der DNS-Server der Uni hat mit DNAME REcords offensichtlich keine Probleme. Wenn Du die Pakete mal mitsniffst, siehst Du in den Antwortpaketen die DNAME Records. Ich habe das mal auf nem 2000er nachgestellt, gleiches Problem wie bei Dir. Auf einem 2003er SP2 (seit SP2 werden DNAME Records unterstützt) ebenfalls, aber da funktioniert es. Ob dieses Problem auch auf einem 2000er gefixed wurde, weiss ich leider nicht. Ich habe nur einen Hotfix gefunden, kannst ja mal probieren ... Event 7063 is recorded in the DNS log of Event Viewer in Windows 2000 Server

Die Fortigate verbindet sich jetzt wie mit dem DC/RRAS ? L2TP/IPSEC ? Für L2TP/IPSEC benötigst Du keine selbst konfigurierte Richtlinie. Mit dem Notebook per VPN in die Zentrale klappt der Ping ? Von wo aus verbindest Du Dich via VPN und Deinem Notebook ? Du musst das mal ein bisschen genauer beschreiben, wie und von wo nach wo ein Tunnel hergestellt wird. Warum wird kein LAN-LAN VPN zwischen der Fortigate und der Linuxdose hergestellt oder zwischen den beiden Servern via RRAS ?

Die Fortigate baut den Tunnel wohin auf ? Zum RRAS auf dem Server in der Zentrale ? Zur Linux-Firewall ? Ich nehme an, dass eine Route auf dem Client fehlt, der ja wohl die Linux-Firewall als Default Gateway hast. Probiere am Client mal eine Route zuzufügen (das soll nur ein Test sein, ob es daran liegt) ... ROUTE ADD 192.168.1.0 MASK 255.255.255.0 192.168.0.1