ASP.Net Anbieter von Web-Server in DMZ

Question

Wir haben eine Intranet asp.net Web-Anwendung, die die OOTB ASP.net Mitgliedschaft und Rollenanbieter verwendet.

Jetzt planen wir die Anwendung Internet aussetzen, indem Sie den Web-Server der DMZ zu bewegen, wie im folgenden (crappy) Text-Diagramm dargestellt

             External                    Internal     
internet --- Firewall --- Web server --- Firewall --- App Server --- Database

                             DMZ                              Intranet

Das Problem ist jetzt, dass die asp.net Mitgliedschaft und Rollenanbieter auf dem Webserver auf den SQL-Server aufgrund des internen Firewall verbinden können nicht.

Haben Sie schon einmal ein solches Szenario vor konfrontiert? Werden Sie in der internen Firewall eröffnen Ports empfehlen, so dass der Webserver direkt mit dem SQL-Server herstellen kann? Welche anderen Alternativen muss ich (otherthan wring ein benutzerdefinierten Anbieter selbst)?

Answer 1

Ändern Sie Ihre DMZ Politik und Öffnen von Ports ist in der Regel schwer, wirklich. Vielleicht haben Sie mehr Erfolg haben zu tun, was ich habe. Einen WCF-Dienst innerhalb des Netzwerks belichten und 80 mit ihm über HTTP auf Port kommunizieren

Null Reibung mit den LAN-Leute, und ich imitieren nur exakt das gleiche (wenn auch beschissen) API, die .NET gibt uns:)

Edit: zu klären, dies bedeutet, dass ich ein RemoteRoleProvider haben, die wie folgt konfiguriert ist:

<roleManager enabled="true" defaultProvider="RemoteRoleProvider">
   <providers>
      <add name="RemoteRoleProvider" type="MyCorp.RemoteRoleProvider, MyCorp" serviceUrl="http://some_internal_url/RoleProviderService.svc" />
   </providers>
</roleManager>

Answer 2

Wir haben ein paar Internet verbundenen Webserver in einer DMZ und hatten Tunnel in unserer Firewall auf den SQL-Server in unserem privaten Netzwerk zurück zu öffnen, die sie mit interagieren müssen. Ich denke, dass wir etwas anderes als Port 1433 für die SQL-Verbindungen verwendet. Bis jetzt ist es ziemlich gut funktioniert, das heißt keine Sicherheitslücken.