Как вы можете перенаправить с HTTP на HTTPS, где IAP настроен с помощью балансировщиков нагрузки GCP?

В настоящее время у меня есть веб-сайт, размещенный на Google Compute Engine, который аутентифицирован с помощью Identity-Aware-Proxy, который находится за балансировщиком нагрузки. Все это отлично работает по https, но я хотел убедиться, что http перенаправляет на https, поскольку в настоящее время он просто отвечает 404.

Итак, я последовал за https://cloud.google.com/load- балансировка / документы / https / настройка-http-https-redirect , который сообщает вам настроить второй балансировщик нагрузки для перенаправления HTTP-трафика на https.

Проблема, однако, заключается в том, что после выполнения этих инструкций, когда я перехожу на http: // my-website. com Я получаю следующую ошибку:

Ошибка 403 (Запрещено) !! 1

  1. Это ошибка.

У вашего клиента нет разрешения на получение URL / с этого сервера. Это все, что мы знаем.

Хотя балансировщик нагрузки http настроен с перенаправлением 301 - перемещен постоянно полный путь, на вкладке сети инструментов разработчика браузера перенаправления не происходит. Он сразу же отвечает 403. URL также остается со схемой http: //.


Подводя итог, вот как выглядит моя настройка:

Внешний балансировщик нагрузки HTTPS

  • Внешний интерфейс - HTTPS, статический IP , Только HTTPS
  • Backend - Identity-Aware-Proxy (аутентификация электронной почты через Identity Platform) -> Группа экземпляров Compute Engine

External HTTP Load Balancer

  • Frontend - HTTP, статический IP (такой же, как HTTPS Load Balancer выше)
  • Серверная часть - Нет
  • Правила хоста и пути:
    • Режим: Расширенное правило хоста и пути (перенаправление URL, перезапись URL)
    • Действие: Перенаправить клиента на другой хост / путь
    • Перенаправление хоста: https: // my -website.com
    • Значение пути: *
    • Код ответа перенаправления: 301 - Перемещено навсегда
    • Перенаправление HTTPS: Включено

Есть идеи, как это исправить, а не получить 403 будет очень признательно!

0
задан 2 December 2020 в 06:29
1 ответ

То, как вы описали , похоже, что у вас проблема с url-map, поскольку вы можете получить доступ к http версии вашего сайта.

Чтобы быть абсолютно уверенным, дважды проверьте (или создайте новую) карту URL-адресов с помощью команды gcloud:

gcloud compute url-maps describe web-map-http

creationTimestamp: '2020-12-02T03:18:27.053-08:00'
defaultUrlRedirect:
  httpsRedirect: true
  redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
fingerprint: KU2hPu1ao=
id: '50586028237895404'
kind: compute#urlMap
name: web-map-http
selfLink: https://www.googleapis.com/compute/v1/projects/xxxxx/global/urlMaps/web-map-http

Когда у вас будет готова карта URL-адресов, создайте целевой прокси-сервер. :

gcloud compute target-http-proxies create http-lb-proxy \
   --url-map=web-map-http \
   --global

результат:

gcloud compute target-http-proxies describe http-lb-proxy
creationTimestamp: '2020-12-02T03:19:39.090-08:00'
fingerprint: lgJkIY8E=
id: '3781119498457764'
kind: compute#targetHttpProxy
name: http-lb-proxy
selfLink: https://www.googleapis.com/compute/v1/projects/xxxx/global/targetHttpProxies/http-lb-proxy
urlMap: https://www.googleapis.com/compute/v1/projects/xxxx/global/urlMaps/web-map-http

и правило переадресации:

gcloud compute forwarding-rules create http-content-rule \
   --address=lb-ipv4-1 \ # Same IP address used for HTTPS load balancer
   --global \
   --target-http-proxy=http-lb-proxy \
   --ports=80

которое должно выглядеть так:

gcloud compute forwarding-rules describe http-content-rule --global
IPAddress: 34.107.123.141
IPProtocol: TCP
creationTimestamp: '2020-12-02T03:22:38.132-08:00'
description: ''
fingerprint: L1vA0Ik9Y=
id: '888330202637841'
kind: compute#forwardingRule
loadBalancingScheme: EXTERNAL
name: http-content-rule
networkTier: PREMIUM
portRange: 80-80
selfLink: https://www.googleapis.com/compute/v1/projects/xxxx/global/forwardingRules/http-content-rule
target: https://www.googleapis.com/compute/v1/projects/xxxx/global/targetHttpProxies/http-lb-proxy

Убедитесь, что вы используете один и тот же общедоступный IP-адрес для HTTP и HTTPS LB. Проверьте правила брандмауэра, если входящий трафик не блокируется.

Если вы все сделаете правильно, вы должны получить тот же результат curl, что и в примере.

1
ответ дан 2 December 2020 в 11:35

Теги

Похожие вопросы