Schnell und einfach zum VPN via Windows Azure Connect

Wenn man im Internet nach VPN und Windows Azure Connect sucht, wird man schnell fündig.
Es wird immer wieder angepriesen, wie schnell und einfach man mit Windows Azure Connect ein VPN erstellen kann, sodass lokale Arbeitsstationen, lokale Server und Cloud-Server-Instanzen miteinander kommunizieren können.

Diesen – noch als CTP verfügbaren – Dienst, habe ich einmal ausprobiert und berichte in diesem Post von meinen Erfolgen und Rückschlägen.

Mein Versuchsaufbau

In meinen Tests verwende ich 3 Arbeitsstationen, 2 lokale Server und eine Web Rolle (2 Instanzen).
Die Kommunikation soll von den Arbeitsstationen zu den Servern, sowie zwischen den Servern, möglich sein. Eine Kommunikation zwischen den Arbeitsstationen soll nicht möglich sein.

Folgende Systeme kamen zum Einsatz:

• Laptop mit Windows XP
• Laptop mit Windows 7 64bit
• Desktop mit Windows 7 64bit
• Server mit Windows Server 2008 R2 64bit (Domaincontroller)
• Server mit Windows Server 2008 64bit und SQL Server 2008 64bit Express

 

Installation der lokalen Endpunkte

Nachdem man sich beim Windows Azure Portal angemeldet hat, findet man unter den Modulen (links unten) den Menüpunkt Virtual Network.

Im Virtual Network Modul kann man dann u.a. den Link zum Installer für die Endpunkte in die Zwischenablage kopieren lassen.

Mit diesem Link installierte ich als erstes die Endpunkte auf den beiden lokalen Servern.
Das Ganze verlief schnell und ohne Probleme.
Nach kurzer Zeit erschien auch das Icon in der Notification Area, welches eine fehlerfreie Verbindung zu Windows Azure Connect meldete.

Die Installation beinhaltete einen lokalen Windows Dienst, einen zusätzlichen Netzwerkadapter und eine schlanke Benutzeroberfläche hinter dem Icon in der Notification Area.

Dann ging es an die Laptops …

Die Installation auf Windows XP schlug, wie vermutet, fehl.

Ein Blick in die Dokumentation bestätigte meine Vermutung. Die Verwendung von Windows Azure Connect ist erst ab Vista SP1 möglich. Allerdings ist die Fehlermeldung etwas irreführend.

Die Installation auf dem Laptop mit Windows 7 verlief auf der ersten Blick ohne Probleme.
Bei genauerem Hinsehen, bekam der lokale "Windows Azure Connect Endpoint" Dienst allerdings keine Verbindung.

• Die mitgelieferte Diagnosesoftware konnte keine Fehler finden
• Der Blick ins Log verzeichnete allerdings einen Zertifikatfehler
• Die Suche im Internet verriet den Übeltäter:
  Windows Azure Connect verträgt sich nicht mit der Firewall der Symantec Endpoint Protection.

  Windows Azure Connect verwendet den Port 443.
  Dieser wird vom installierten Azure-Connect-Netzwerkadapter als Relay-Endpunkt von Innen nach Außen geöffnet.
  Das sollte doch den meisten Firewalls kein Problem darstellen, oder!?

  Nach ein paar Stunden erfolgloser Konfigurationsarbeit an der Symantec Firewall (auf Applikations- sowie auf Portebene) und einigen Frustpausen, habe ich die SEP deinstalliert und durch Alternativprodukte ersetzt.
  Somit konnte ich eine fehlerfreie Verbindung herstellen.

Mit diesem Wissen verlief die Installation auf dem Windows 7 Desktop ohne Probleme.

 

Installation einer Web Rolle

Als nächstes habe ich ein Windows Azure Projekt mit einer ASP.NET Web Forms erstellt.
Diese soll auf den lokalen SQL Server zugreifen und die dort erhaltenen Daten anzeigen.

Um die Web Rolle mit Windows Azure Connect zu verbinden, benötigt man einen Activation Token.
Dieser kann über das Windows Azure Portal im Modul Virtual Network in die Zwischenablage kopiert werden.

Anschließend kann dieser Token in Windows Azure Projekten benutzt werden, um Rollen mit dem VPN zu verbinden. Hierzu konfiguriert man das Virtual Network Tab in den Rolleneinstellungen.

Anschließend habe das Projekt in der Windows Azure Plattform installiert und gestartet.

 

Konfiguration des Virtuellen Netzwerks

Um meine gewünschten Ziele (siehe "Mein Versuchsaufbau") umzusetzen, benötige ich zwei Endpunktgruppen.
Diese können über das Windows Azure Portal im Modul Virtual Network erstellt, geändert und gelöscht werden.

Die erste Gruppe wird für die Arbeitsstationen benötigt.
Nach der Vergabe eines Gruppennamens, werden die beiden Arbeitsstationen mittels Add Button in die Liste der Connect From Endpunkte hinzugefügt, um sie zum Mitglied dieser Gruppe zu machen.
Da eine Kommunikation untereinander nicht erwünscht ist, wird die Interconnected Checkbox nicht angehakt.

Die zweite Gruppe wird für die Server benötigt.
Nach der Vergabe eines Gruppennamens, werden die beiden Server mittels Add Button in die Liste der Connect From Endpunkte hinzugefügt, um sie zum Mitglied dieser Gruppe zu machen.
Im Bereich Connect To kann die neue Gruppe mit Azure Rollen und / oder anderen Endpunktgruppen verbunden werden. Hier werden die "Arbeitsstationen" Endpunktgruppe, sowie die "WebRole1" Azure Rolle, hinzugefügt.
Da eine Kommunikation untereinander erwünscht ist, wird die Interconnected Checkbox angehakt.

In der Gesamtübersicht sieht das Ganze dann wie folgt aus:

 

Tests

Nachdem alles aufgesetzt war, startete ich mit einigen Tests außerhalb meines Netzwerks:

• Mein erster Test war ein einfacher Ping vom frisch gestarteten Laptop zum Domaincontroller.
  Dieser schlug vorerst fehl…
  Ein Blick in die Anleitung ergab, dass der Aufbau der Verbindung zu Windows Azure Connect ca. 2-5 Minuten benötigt.
  Nach dieser Wartezeit konnte der Ping erfolgreich durchgeführt werden.
• Auch eine RDP Verbindung vom Laptop zum Domaincontroller war ohne Probleme möglich.
• Eine Verbindung vom Laptop zum Desktop war, wie gewünscht, nicht möglich.
• Die Azure Serverinstanzen, der WebRole1, sollen eine Tabelle des lokalen SQL Servers anzeigen.
  Auch das funktionierte einwandfrei.

Zurück im eigenen Netzwerk, musste ich feststellen, dass die lokalen Server nicht mehr direkt angesprochen werden, sondern immer Windows Azure Connect verwendet wird. Deshalb habe ich den lokalen "Windows Azure Connect Endpoint" Dienst der Arbeitsstationen auf Manuell umgestellt und starte ihn nur bei Bedarf.

Ein weiteres Problem stellte ich in einem Netzwerk mit Proxy-Servern fest.
Hier mussten die Proxyeinstellungen für den LocalSystem Benutzer angepasst werden.
Dies kann über das Kommandozeilentool BITSAdmin durchgeführt werden:

bitsadmin /util /setieproxy localsystem MANUAL_PROXY proxysrv:8080 ";*.consoto.com"

 

Fazit

Auch wenn meine bisherigen Erfahrungen mit Windows Azure Connect nicht vollständig ohne Probleme verlaufen sind, bin ich mit diesem Windows Azure Plattform Dienst sehr zufrieden. Man darf auch nicht vergessen, dass es sich derzeit noch um eine CTP Version handelt. Ein VPN kann schnell und einfach aufgebaut werden und die Geschwindigkeit ist im annehmbaren Bereich.