Archive for 13. Dezember 2013

Schwarzer Bildschirm bei Remote Desktop

13 Dezember 2013

Schon seit Wochen nervt mich eine Besonderheit meiner ach so schönen Windowswelt. Den Taugenichtsen von MS war es mal wieder langweilig und da dachten sie sich: Hey, machen wir doch einen Bug ins neue RDP-Protokoll 8.1 rein!

Das Phänomen äußert sich folgendermaßen: Man baut ganz normal eine Remote-Desktop-Verbindung auf, man arbeitet damit, sogar über Tage hinweg. Alles läuft normal. Aber irgendwann ist das Remote-Fenster im Weg und man legt es auf die Taskleiste. Wenn man es später wieder hochhohlen will, kann es passieren, dass anstatt des Remote-Desktops nur ein schwarzer Fensterinhalt präsentiert wird. Der Witz dabei ist, wenn man das auf die Taskleiste legen und wieder hochholen mehrmals exerziert, dann ist irgendwann das Fenster da. Manchmal hilft auch die Verbindung zu trennen und neu aufzubauen aber leider nicht immer.

Abgenervt ohne Ende, weil es gefühlt, die letzten Tage immer schlimmer wurde, mal im Internet gefahndet. Siehe da, dieser Artikel: http://social.technet.microsoft.com/Forums/de-DE/31b681c5-3658-45a5-8158-a0a0f967c4a2/rdp-screen-goes-black-after-successful-remote-login. Da sind ähnliche Dinge beschrieben STRG+ALT+Ende-Tastenkombination soll helfen. OK, ausprobiert. Bingo! Es erscheint immer das Auswahlfenster, wo man den Computer sperren kann, den Taskmanager aufrufen kann usw. Klickt man nun hier abbrechen, erscheint der Desktop in alter Pracht. Laut den Eintragungen gibt es das Problem schon länger, aber ich behaupte es ist bei mir erst, seit RDP 8.1 ein Thema.

Werbeanzeigen

Fritzboxen mit FritzOS 6.x mit VPN einrichten

13 Dezember 2013

Sei es die Fritzbox 7490 oder 7390, beide beherrschen nun mittels Fritz!OS 6.x vereinfachte Mechanismen um VPN-Verbindung einrichten zu können. Leider sind noch nicht alle Beschreibungen so, dass alles reibungslos funktioniert.

Deshalb hier die Links um die Sache unter Windows mittels Shrew Soft VPN Client (www.shrew.net) einzurichten: http://rays-blog.de/2013/11/28/127/windows-7-mittels-shrew-soft-vpn-client-per-vpn-mit-fritzbox-7390-fritzos-6-verbinden/, bzw. mit Ubuntu direkt: http://linuxundich.de/ubuntu/update-auf-fritzos-6-0-macht-nun-das-einrichten-eines-fritzbox-vpns-komplett-ohne-windows-moeglich/.

Und noch der Link zum AVM-VPN-Service-Portal: http://www.avm.de/de/Service/Service-Portale/Service-Portal/index.php?portal=VPN&linkident=nav_left.

Noch die Links für die IKE-Strategien, Phase1: http://www.avm.de/de/Service/Service-Portale/Service-Portal/images/Redaktionelle_Grafiken/vpn/ike_1.pdf und Phase 2: http://www.avm.de/de/Service/Service-Portale/Service-Portal/images/Redaktionelle_Grafiken/vpn/ike_2.pdf, ob die für die Fritzbox  noch gelten, da relativ alt?

Optimal wäre nun, wenn man mittels Powershell 4.0 und den Cmdlets Set-VpnConnection sowie Set-VpnConnectionIpsecConfiguration alles direkt, ohne zusätzliche Software, hinbekommen könnte! Leider scheint XAuth aber schon mal keine Option zu sein, Auszug von http://msdn.microsoft.com/en-us/library/windows/desktop/cc983672.aspx#EZF:

Q.Why doesn’t Microsoft implement IPSec tunnel mode with XAUTH and mode config?

A. There are several key reasons for this.

XAUTH contains serious security flaws for which no known fix is available and has been rejected for IETF standardization. Given this, Microsoft believes that it would be irresponsible for us to endorse this technology, especially when IETF standards-based technology is under development.

XAUTH is incompatible with existing IETF authentication frameworks such as EAP and GSS-API. This means that developers who want to develop authentication techniques for the Windows platform would need to develop their methods using multiple, incompatible APIs. This prevents customers from using existing authentication methods within remote access scenarios. For developers, it increases the complexity and cost of developing a new authentication method. Rather than introducing another authentication framework to the detriment of customers and developers, Microsoft endorses efforts within IETF and IEEE to extend the applicability of EAP. This allows customers and developers to leverage their efforts, developing authentication methods with universal applicability, such as in wireless scenarios (via 802.1X).
Because of the poor interoperability of XAUTH and mode config, Microsoft could not implement the technology and have it work with more than one vendor.
L2TP/IPSec is already an interoperable standard that is supported in commercial products from leading networking companies and can be implemented in models similar to XAUTH with IPSec but with much stronger security, reliable accounting, and standards-based configuration.
The IETF rejected XAUTH and mode config and has a more appropriate IPSec tunnel mode-based remote access solution in development through the IPSRA working group.