web-dev-qa-db-fra.com

IIS Réécriture HTTP / S avec déchargement SSL du port local non standard

J'ai posté ceci dans un forum différent et je n'ai rien eu, alors je suis un peu désespéré.

Voici mon scénario:

  • Sites d'exécution IIS sur 80 et 443 - external.foo.com et https://external.foo.com

  • Sur le même nœud, un service Web distinct exécute une application (ASP) sur le port 801 - " web app3 ".

J'ai besoin que tout le trafic arrivant à http (s): //external.foo.com/app3 soit routé vers le port local 801 avec déchargement SSL - La connexion du client à IIS est donc SSL, mais la connexion d'IIS au service local est http via le port 801.


J'ai ARR configuré avec une configuration de proxy sur localhost: 801 qui a créé une règle de réécriture par défaut. J'ai tous les IIS sites et demandes à external.foo.com/app3 redirigés vers app3 maintenant via HTTPS et il apparaît le déchargement fonctionne bien en utilisant la règle par défaut ARR. La règle globale est ci-dessous.

<proxy enabled="true" />
        <rewrite>
            <globalRules>
                <clear />
                <rule name="ARR_App3Proxy_loadbalance" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
                    <match url="*" />
                    <action type="Rewrite" url="http://App3Proxy/{R:0}" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                    </conditions>
                </rule>
            </globalRules>
        </rewrite>

Maintenant, j'ai juste besoin de cibler external.foo.com/app3 spécifiquement pour que mes autres IIS sites soient exclus de cette .. Si je laisse la règle seule, il redirige chaque demande de site vers app 3 via https avec déchargement très bien, mais dès que j'essaie de définir les sites IIS reviennent à leur valeur par défaut, mais je ne parviens pas à charger app3 en ouvrant http (s): //external.foo.com/app3 .

Honnêtement, je pense qu'il y a 2 choses qui ne vont pas, je ne vise pas external.foo.com/app3 correctement et que le port 80 ou 443 est également impliqué pour une raison lorsque je modifie la règle par défaut. J'ai essayé 100 fois de faire ce travail, mais je manque de Steam.

Tout conseil ou assistance sera grandement apprécié!

2
Charlie Echo

Changez votre motif match pour qu’il corresponde uniquement au chemin qui vous intéresse:

<rule name="ARR_App3Proxy_loadbalance" enabled="true" stopProcessing="true">
  <match url="^app3(.*)$" />
  <action type="Rewrite" url="http://App3Proxy:801{R:1}" />
</rule>

Ici, j'ai changé la règle en une correspondance regex plutôt qu'une correspondance avec caractère générique, puis j'ai défini le modèle de correspondance sur:

  • ^ début de chemin - dans les règles c'est tout après la première barre oblique finale après le domaine.
  • app3 ne correspond que si le chemin est app3 - devrait ignorer les autres dossiers et chemins - cela devrait suffire
  • (.*)$ capture tout le reste à la fin de l'URL - cela devrait inclure les barres obliques de fin, les chaînes de requête, etc.

Ensuite, l'action est configurée pour réécrire sur le serveur dans le protocole et le port correct (http://app3proxy:801) avec la capture de la règle {R:1} (car R:0 est la chaîne complète correspondante (dans ce cas, app3/somepath)).

Enfin, cela suppose que vous avez configuré la résolution de noms en interne pour app3proxy sur votre site - le moyen le plus simple de confirmer que vous le demandez dans un navigateur sur le serveur. Si vous ne disposez pas d'un serveur DNS local auquel vous pouvez ajouter l'entrée, vous pouvez soit ajouter une entrée au fichier hôtes du serveur, soit simplement utiliser l'adresse IP interne (s'il s'agit du même serveur, alors http://127.0.0.1:801 devrait fonctionner).

Notes sur les démarches entreprises localement pour confirmer:

  1. Application Application Routing 3.0 installée à partir du programme d'installation de Web Platform.
  2. Dans IIS Manager, au niveau du serveur, ARR activé avec le paramètre "Activer le proxy" - laissait toutes les autres options sur leur valeur par défaut, notamment en laissant "Type de proxy | Utiliser la réécriture d'URL pour inspecter les demandes entrantes" Le déchargement SSL est coché) - cela entraîne la note informative "Les règles de routage du serveur n'ont pas été créées".
  3. Assurez-vous que je peux résoudre correctement les sous-sites sur le serveur (y compris un sur le port 801.
  4. Sur le site Web IIS, les règles de réécriture ont été ajoutées à l'application.

Exemple de règles:

<rules>
  <rule name="Brickjax Reverse Proxy" stopProcessing="true">
    <match url="^brickjax(.*)$" />
    <action type="Rewrite" url="http://local.brickjax.doodle.co.uk{R:1}"  />
  </rule>
  <rule name="LapTimes Rewrite">
    <match url="^laptimes(.*)$" />
    <action type="Rewrite" url="http://local.laptimes.doodle.co.uk:801{R:1}" />
  </rule>
</rules>

Puis, lorsque je demande https://localhost/, je reçois le site Web par défaut IIS, tandis que https://localhost/brickjax m'emmène à l'instance de développement de mon site BrickJax et https://localhost/laptimes m'amène à l'instance de dev. de mon application LapTimes:

Secure primary with SSL offload onto the insecure local sites

Autres choses à vérifier

Vos applications vérifient-elles ou traitent-elles le chemin de demande entrant? Si tel est le cas, vous devez vous assurer que vous recherchez l'URL et le chemin corrects. Par exemple, j'ai essayé de configurer une règle de réécriture d'URL pour mon site de production principal, qui a émis une redirection 301 car j'avais mal configuré le domaine. - cette réponse a été transmise à mon serveur IIS local, qui l'a transmise au navigateur, ce qui a donné un résultat différent de celui attendu.

Là encore, le suivi des demandes ayant échoué est d’une aide précieuse. Recherchez RewriteModule et ApplicationRequestRouting, ils devraient vous donner quelques idées sur ce qui se passe.

1
Zhaph - Ben Duguid