Post #316
967
Долгое время мне приходилось по-разному изворачиваться, чтобы настроить автоматический redirect с HTTP на HTTPS на балансировщике AWS.
Официальная документация, равно как и разные бложики, советовали следующее: поставить балансировщик прослушивать 80 и 443 порт (HTTP и HTTPS соответственно), а на backend сервере настроить redirect таким образом, чтобы он перенаправлял входящий трафик с 80 порта и на 443-ий.
У такого подхода был один жирный и неприятный недостаток. Допустим у вас есть веб-сервер, на котором вы настроили redirect на HTTPS. На балансировщике стоит “прослушка” на 443 порт с последующим переводом трафика на 80 порт на target group’е. Поскольку SSL терминируется на балансировщике, после него идет самый обычный HTTP трафик. Поскольку ALB так же меняет header’ы, вы рискуете поймать следующую ситуацию: трафик приходит на балансер на 80 порт - балансер пропускает трафик на backend - backend видит, что трафик пришел на http и редиректит на https - трафик снова приходит на балансер на 443 порт - балансер пропускает трафик на 80 порт на бэкенде, терминируя SSL - backend видит, что трафик пришел на http и редиректит на http - трафик снова приходит на балансер на 443 порт… Догадались, что вы увидите в браузере?
Это очень геморойная тема, поэтому 25 июля Амазон наконец-то анонсил адекватное решение (https://aws.amazon.com/about-aws/whats-new/2018/07/elastic-load-balancing-announces-support-for-redirects-and-fixed-responses-for-application-load-balancer/). Теперь на правиле прослушивания на 80 порту можно просто поставить правило Redirect. Подробнее можно узнать здесь: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#listener-rules
Соответственно помним, что балансировщик должен также слушать HTTPS с правильно установленными сертификатами.
Amazon Elastic Load Balancing Announces Support for Redirects and Fixed Responses for Application Load Balancer Официальная документация, равно как и разные бложики, советовали следующее: поставить балансировщик прослушивать 80 и 443 порт (HTTP и HTTPS соответственно), а на backend сервере настроить redirect таким образом, чтобы он перенаправлял входящий трафик с 80 порта и на 443-ий.
У такого подхода был один жирный и неприятный недостаток. Допустим у вас есть веб-сервер, на котором вы настроили redirect на HTTPS. На балансировщике стоит “прослушка” на 443 порт с последующим переводом трафика на 80 порт на target group’е. Поскольку SSL терминируется на балансировщике, после него идет самый обычный HTTP трафик. Поскольку ALB так же меняет header’ы, вы рискуете поймать следующую ситуацию: трафик приходит на балансер на 80 порт - балансер пропускает трафик на backend - backend видит, что трафик пришел на http и редиректит на https - трафик снова приходит на балансер на 443 порт - балансер пропускает трафик на 80 порт на бэкенде, терминируя SSL - backend видит, что трафик пришел на http и редиректит на http - трафик снова приходит на балансер на 443 порт… Догадались, что вы увидите в браузере?
Это очень геморойная тема, поэтому 25 июля Амазон наконец-то анонсил адекватное решение (https://aws.amazon.com/about-aws/whats-new/2018/07/elastic-load-balancing-announces-support-for-redirects-and-fixed-responses-for-application-load-balancer/). Теперь на правиле прослушивания на 80 порту можно просто поставить правило Redirect. Подробнее можно узнать здесь: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#listener-rules
Соответственно помним, что балансировщик должен также слушать HTTPS с правильно установленными сертификатами.
- ❤ 1