Por que é que o ciclo de login numa nuvem privada só aparece fora da rede doméstica?

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Why Does a Private Cloud Login Loop Appear Only Outside the Home Network? - Zima Store Online

Um ciclo de login apenas externo geralmente significa que o caminho do proxy remoto altera o esquema, nome do host, cookie, callback ou informações de sessão vistas pela aplicação.

Dentro de casa, um navegador pode conectar-se diretamente ao serviço de nuvem privada através do seu endereço local, enquanto os utilizadores remotos entram através do DNS público, terminação TLS, um proxy reverso, camada forward-auth, túnel ou fornecedor de identidade. As credenciais podem ser aceites corretamente, mas o pedido seguinte retorna à página de login porque o cookie de sessão não é armazenado ou devolvido, o backend pensa que HTTPS é HTTP, a URL de callback difere do valor registado, ou a aplicação gera redirecionamentos para o seu nome de host interno.

Capture o Ciclo Exato de Redirecionamento no Navegador

Abra o painel de rede do navegador antes de iniciar sessão fora de casa. Preserve o registo de pedidos e registe cada código de estado, cabeçalho Location, cabeçalho Set-Cookie, nome do host do pedido e se o cookie de sessão aparece no pedido seguinte.

Um guia de resolução de problemas do Keycloak recomenda observar toda a cadeia de redirecionamentos porque cabeçalhos encaminhados em falta, âmbito do cookie e callbacks podem criar um redirecionamento infinito de login mesmo quando a etapa da palavra-passe é bem-sucedida.

Se nenhum cookie for emitido, investigue a resposta da aplicação e do proxy. Se um cookie for emitido mas não devolvido, inspecione o seu domínio, caminho, atributos Secure e SameSite. Se o cookie for devolvido mas a aplicação continuar a redirecionar, continue com a confiança no proxy e armazenamento da sessão.

Compare os Nomes de Host e Esquemas Locais e Públicos

Anote a URL local e a URL pública exatas, incluindo http ou https, nome do host, porta e subcaminho. Teste se a aplicação tem uma URL base canónica ou externa configurada.

Uma análise do WordPress com proxy reverso explica que quando o backend acredita que o pedido é HTTP, pode redirecionar para HTTPS repetidamente enquanto o proxy continua a terminar o TLS. O ciclo resulta de deteção incorreta de HTTPS atrás do proxy e não da palavra-passe do utilizador.

Use um nome de host público consistentemente para login remoto, callbacks e cookies. Não misture o domínio público, IP privado, nome do host interno e portas alternativas numa única sequência de autenticação, a menos que a aplicação suporte explicitamente múltiplas origens confiáveis.

Verifique os Cabeçalhos Forwarded Host e Protocol

Verifique a configuração do proxy reverso e os registos do backend para X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-Port e o endereço original do cliente. Confirme que a aplicação confia apenas no proxy conhecido e reconstrói a mesma URL pública usada pelo navegador.

Um caso de proxy reverso do qBittorrent nota que uma página de login pode carregar e aceitar credenciais enquanto um cabeçalho Host ou HTTPS incompatível impede que a sessão autenticada seja reconhecida.

Se o proxy enviar os valores públicos corretos mas a aplicação os ignorar, configure as definições de proxy confiável e URL externa da aplicação. Se o proxy os omitir, adicione apenas os cabeçalhos estritamente necessários em vez de encaminhar todos os cabeçalhos fornecidos pelo cliente sem alterações.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

Inspecione o Domínio, Caminho, Secure e SameSite do Cookie

Compare o cookie de sessão criado localmente com o criado através do domínio público. Um cookie com âmbito num nome de host interno, domínio pai errado, subcaminho diferente ou contexto não seguro pode não acompanhar o pedido público redirecionado.

O acesso externo frequentemente adiciona outro domínio de autenticação ou callback cross-site. Restrições SameSite e requisitos Secure podem, portanto, afetar o fluxo remoto mesmo que um login local direto nunca saia de uma origem.

Limpe cookies apenas para os domínios de nuvem privada afetados, reproduza o ciclo e inspecione os novos atributos. Corrija as definições de URL pública e cookies da aplicação ou proxy; não use relaxamento de cookies a nível de navegador como solução permanente do lado do servidor.

Verifique a Identidade do Callback OAuth, OIDC ou Forward-Auth

Se a nuvem privada usar um fornecedor de identidade ou serviço forward-auth, compare a URL de callback gerada pela aplicação, registada no fornecedor e alcançada pelo navegador. Esquema, nome do host, porta, caminho e barra final podem precisar de coincidir exatamente.

Um caso da comunidade NGINX descreve um ciclo de login remoto onde o TLS termina no proxy mas o backend vê HTTP, pelo que a aplicação não consegue manter a sessão externa segura esperada.

Teste o endpoint de callback diretamente através do domínio público e confirme que alcança a rota correta do proxy e o backend. Se a autenticação for bem-sucedida mas o callback reiniciar o login, inspecione estado, nonce, persistência do cookie, sincronização do relógio e a URI de redirecionamento exata.

Valide a Sessão Remota Completa Sem Contornar o Proxy

Após corrigir uma causa, comece com uma janela privada limpa numa rede externa. Inicie sessão, atualize o painel, abra um ficheiro, espere além do intervalo curto da sessão e reconecte para confirmar que a sessão sobrevive à navegação normal.

O guia ZimaSpace para acesso remoto controlado a NAS fornece o limite de segurança envolvente: corrigir o ciclo não deve exigir expor o backend diretamente ou desativar a autenticação.

O problema só está resolvido quando utilizadores locais e remotos alcançam o nome do host pretendido, o proxy preserva a identidade do pedido público, o cookie permanece válido e o fluxo completo de login e callback tem sucesso repetidamente. Remova contornos temporários e registos detalhados de autenticação após a verificação.