Wir entwickeln gerade an einer Anwendung mit Cloud Komponenten. Wichtig… wir sind HIP… oder heißt das heute anders? In der Cloud hat den Vorteil, fast alles über HTTP(S) machen zu können. Das Arbeiten in der Cloud hat aber auch Nachteile… zum Beispiel, das es fast nur HTTP(S) gibt :-) Mir geht es hier nicht um Probleme anderer Leute, alternative Ansätze stehe nicht zur Diskussion… ich erzähle, das hier, weil ich damit gerade ein Problem hatte. Also zu den Details.

Wir haben ein Server im Internet (sucht euch ein Hoster aus und stellt euch da ein Server vor). Dieser Server wird auch zu Entwicklungszwecken genutzt, da wir die Probleme des Web 2.0 von Anfang an benötigen (DNS, Cross-Site-Access, SSL Validation, etc). Der Server hat als Betriebssystem Windows Server 2008. Ein IIS7 bietet die Cloud-Dienste an und ein SQL Server 2008 steht hinter unserer Cloud für das Persistieren der Daten bereit. Mit Hilfe von Astoria (aka ADO.NET Data Services) gibt es Zugriff auf die Daten. Für das Erstellen der Zugriffsschicht (EDMX) benötigt das Visual Studio direkten Zugriff auf die SQL Datenbank. Hier liegt nun das Problem: Für Browsing ins Internet nutzten wir eine schnelle DSL Leitung mit wechselnden IP Adressen. Ich kann dern Windows Server also nicht einfach eine IP Eintragen und fertig. Für den Quickstart (und für den Quasi-Securitytest) wurde der gepatchte Server einfach auf 1433 (SQL Standard TCP Port) geöffnet. Schon nach einem Tag zeige das EventLog massiv viele Einträge über fehlerhafte SA Loginversuche. Slammer lässt also noch 2008 grüßen :-)

Welche Optionen gibt es in solchen Fällen?

* Die Clients benötigen eine Statische IP Adresse                 * Für die Servernetze ist das ok, aber fürs Browsen muss das nicht sein               * Den Server ins Clientnetz holen                 * Einfach aber nicht realitätsnah               * Eine VPN Lösung einsetzen                 * Administrativer Aufwand ist zu hoch und am Client muss man immer schauen das die VPN oben ist               * Die dynamische IP Adresse am Server bekannt machen                 * Bingo… aber wie? Einfach weiter lesen.           

Wir mache ich also eine dynamisch DSL IP, die täglich einmal wechselt, auf dem Server bekannt? Für die ersten zwei Tage habe ich unsere IP bei http://www.wasistmeineip.de nachgeschlagen und in der Firewall des SQL Server eingetragen. Funktioniert… aber ist auf dauer langweilig. Jetzt kommen die Tools aus dem Titel zum Einsatz:image

1. [Windows Server 2008 Advanced Firewall](http://www.microsoft.com/windowsserver2008/en/us/security-policy.aspx)         

Eine Inbound-Rule anlegen, die 1433 erlaubt. 2. NETSH
Eine CommandLine, die in der Lage ist, Rules der Advanced Firewall zu modifizieren. 3. PowerShell
Die Script-Umgebung für den Zugriff auf .NET Objekte wir zum Beispiel: System.Net.DNS 4. DynDNS
Ein Dienst, der auf vielen Routern genutzt werden kann, um sein “privates” DSL Netz mit einer dynamischen IP im Netz auffindbar zu machen. 5. Windows Task Scheduler 2.0
Kurze Zeit nach dem IP Wechsel (der ja in der Regel immer zur selben Zeit ist) wird das PowerShell los getreten, um die Firewall zu modifizieren.

Und so sieht das ganze aus:

<span style="color:#606060;">   1:</span> ipconfig /flushdns




<span style="color:#606060;">   2:</span> $ip = [System.Net.Dns]::GetHostAddresses(<span style="color:#006080;">"meindynamischesnetz.dyndns.org"</span>)[0].ToString()




<span style="color:#606060;">   3:</span> $ip = $ip + <span style="color:#006080;">"/255.255.255.255,192.168.1.1/255.255.255.255"</span>




<span style="color:#606060;">   4:</span> netsh advfirewall firewall set rule name=<span style="color:#006080;">"SQL-Server"</span> <span style="color:#0000ff;">new</span> remoteip=$ip

1: FLUSHDNS für einen frischen DNS Cache

2: Ermitteln der ersten IP Adresse des DYNDNS Eintrags

3: Hinzufügen der IP mit SubNetMask zu weiteren statischen IP Adressen

4: Die REMOTEIP auf die Rule mit dem Namen “SQL-Server” setzen

Die Lösung ist beliebig erweiterbar. Zum Beispiel, die aktuelle Konfig auszulesen und die IP zu ersetzen. Für mich hat es so erst mal gereicht… und vielleicht reicht es auch für andere mit einem selben Problem. Wichtig: Die SQL-Verbindung ist da durch nicht geschützt! Eine Lösung hierfür: Encypt=yes

Ciao Marco

UPDATED: 2008-09-25 – FlushDNS ins Script mit aufgenommen