Redirecione todo o tráfego HTTP para HTTPS ao usar o HTTP (S) Load Balancer no Google Compute Engine

Eu tenho o Balanceamento de carga HTTP / HTTPS configurado no Google Compute Engine com duas regras de encaminhamento global (HTTP e HTTPS). Cada regra aponta para um serviço de back-end com um protocolo HTTP.

Quero que todos os pedidos http://*sejam acessados https://*.

Enquanto o balanceador de carga se comunica com os serviços de back-end por HTTP, acho que não consigo obter o nginx no serviço de back-end para enviar de volta a 301.

Eu tentei uma dúzia de pequenos ajustes no cálculo do google e todos acabam com o cálculo do google retornando um 502.

Tenho certeza que alguém já configurou isso antes. Todas as dicas ou sugestões na direção certa são muito apreciadas.

load-balancing google-compute-engine

— Ryan Leckey
fonte

Atualmente, o redirecionamento HTTP para HTTPS (usando SSL) não é suportado pelo balanceador de carga HTTP / HTTPS. O redirecionamento precisa ser configurado no seu servidor web (apache, nginx etc). Com isso dito, não hesite em registrar uma solicitação de recurso no rastreador público de problemas do Compute Engine ( code.google.com/p/google-compute-engine/issues/list ).

— Faizan

Obrigado; abriu um problema: code.google.com/p/google-compute-engine/issues/…

— Ryan Leckey 04/11/2015

Ok, perfeito, encaminhei a solicitação de recurso para a engenharia.

— Faizan

@Faizan - existe uma linha do tempo quando esse recurso estará disponível? Faz cerca de 2 anos desde que o recurso foi solicitado. A solução alternativa é desajeitada.

— Talonx

O novo link para esta solicitação é issuetracker.google.com/issues/35904733 (embora o antigo ainda redirecione).

— Daniel Compton

Respostas:

Temos uma configuração semelhante usando o balanceador de carga HTTP / HTTPS e conseguimos forçar o HTTPS. Não é possível diretamente no balanceador de carga, mas você pode configurá-lo no seu serviço de back-end. O balanceador de carga do Google Cloud definirá o cabeçalho http X-Forwarded-Proto com o valor http ou https. Você verifica esse cabeçalho no serviço de back-end (no nosso caso, verniz, mas isso também pode ser feito no Nginx) e, se o valor for http, você envia um 301 de volta.

— Lennert Kuijpers
fonte

Obrigado! Por uma questão de posteridade: if ($http_x_forwarded_proto = "http") { return 301 https://$host$request_uri; }

— Ryan Leckey 13/11/2015

Você deve usar HTTP 426atualizar cabeçalho em vez de 301. Leia mais: stackoverflow.com/questions/17873247/...

— Vikram Tiwari

Não concordo com Vikram, você deve usar um 301 para fins de SEO. Se você retornar um código de família 4xx, o seu pagerank não passará dos links que apontam para o antigo http para https. 301 é o código esperado, pelo menos se você se preocupa com o SEO no seu site.

— Cyrrill 5/07

@VikramTiwari, a resposta da postagem na verdade afirma: "Não se trata nem mesmo de atualizar de http: // para https: //" "

— Rambatino

Eu enfrentei esse problema hoje e consegui resolvê-lo usando o balanceamento de carga TCP. Se você não precisar das opções específicas do balanceador de carga HTTP / HTTPS, talvez seja possível usar o balanceador de carga TCP (sem SSL) para receber tráfego nas portas 80 e 443. Para o tráfego da porta 80, é possível enviar de volta 301.

— gselva
fonte

o balanceamento de carga TCP não é permitido para a porta 80 doc > O TCP Proxy Load Balancing suporta as seguintes portas: 25, 43, 110, 143, 195, 443, 465, 585, 700, 993, 995, 1883, 5222

— Giovanni Toraldo,