Перенаправление на https через переписывание URL в IIS в балансировщике балансировки балансировки

Ответ 1

Это сложнее, чем кажется по нескольким причинам. Во-первых, балансировщик нагрузки заботится о ssl, поэтому запросы, переданные из балансира нагрузки, никогда не используют ssl. Если вы используете традиционное правило перезаписи, вы получите бесконечный цикл переадресаций. Еще одна проблема, с которой нужно бороться, заключается в том, что проверка работоспособности AWS не удастся, если она получит ответ перенаправления.

• Первым шагом в решении является создание страницы healthcheck.html и установка ее в корневой каталог. Неважно, что такое контент.
• Установите свой балансировщик нагрузки для использования файла healthcheck.html для проверки работоспособности.

• Добавьте правило перезаписи ниже в разделе web.config <system.webServer><rewrite><rules>:

  <rule name="Force Https" stopProcessing="true">
     <match url="healthcheck.html" negate="true" />
     <conditions>
         <add input="{HTTP_X_FORWARDED_PROTO}" pattern="https" negate="true" />
     </conditions>
     <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" />
  </rule>
  

Обратите внимание, что совпадение правил находится на чем угодно, кроме нашего файла healthcheck. Это гарантирует, что проверка работоспособности балансировки нагрузки будет успешной и не ошибочно отбросит наш сервер от нагрузки.

Балансировщик нагрузки передает значение X-Forwarded-Proto в заголовке, что позволяет нам знать, был ли запрос передан через https или нет. Наше правило запускает, если это значение не является https и возвращает постоянную переадресацию с использованием https.

Ответ 2

Во-первых, я хочу поблагодарить Росса за его оригинальный ответ, он поставил меня на пути к созданию правила перезаписи URL-адреса IIS, который работал у меня, используя мое существующее правило перенаправления HTTP-HTTPS, которое я использовал до того, как мой сайт был за Балансировка эластичной нагрузки AWS.

<rule name="Redirect to HTTPS" enabled="true" stopProcessing="true">
    <match url="(.*)" />
    <conditions>
        <add input="{HTTP_X_FORWARDED_PROTO}" pattern="https" negate="true" />
        <add input="{REMOTE_HOST}" pattern="localhost" negate="true" />
        <add input="{REMOTE_ADDR}" pattern="127.0.0.1" negate="true" />
        <add input="{HTTP_HOST}" pattern="localhost" negate="true" />
    </conditions>
    <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
</rule>

Это правило позволяет вам получить доступ к вашему сайту локально в Visual Studio или на сервере на порту 80 без необходимости доступа к HTTPS, поэтому вам нужно иметь привязку для порта 80 на сервере. Он не страдает от вещей, о которых говорили другие (дублированные запросы и т.д.).

У меня лично не было проблем с проверкой работоспособности, мне не нужно было создавать файл на сервере для балансировки эластичной нагрузки для ping. У меня есть балансировка нагрузки, установленная на проверку работоспособности TCP:80, и она работает.

Ответ 3

Ответ на Luke отлично работает, если вы используете ELB, но не будете работать с ALB. Ответ ALB Ross Pace правильный. Но вы также можете объединить эти два так, чтобы вы могли получить доступ к сайту локально, не перенаправляясь на HTTPS.

<rule name="Redirect to HTTPS" enabled="true" stopProcessing="true">
    <match url="healthcheck.html" negate="true" />
        <conditions>
            <add input="{HTTP_X_FORWARDED_PROTO}" pattern="https" negate="true"/>
            <add input="{REMOTE_HOST}" pattern="localhost" negate="true"/>
            <add input="{REMOTE_ADDR}" pattern="127.0.0.1" negate="true"/>
            <add input="{HTTP_HOST}" pattern="localhost" negate="true"/>
        </conditions>
    <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/>
</rule>