Varför uppstår en inloggningsloop för privat moln endast utanför hemmets nätverk?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

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

En inloggningsloop som endast uppstår utifrån betyder vanligtvis att den fjärrproxyvägen ändrar schema, värdnamn, cookie, callback eller sessionsinformation som appen ser.

Inomhus kan en webbläsare ansluta direkt till privatmolnstjänsten via dess lokala adress, medan fjärranvändare går in via offentlig DNS, TLS-terminering, en omvänd proxy, forward-auth-lager, tunnel eller identitetsleverantör. Uppgifterna kan accepteras korrekt men nästa förfrågan går tillbaka till inloggningssidan eftersom sessionscookien inte sparas eller returneras, backend tror att HTTPS är HTTP, callback-URL skiljer sig från det registrerade värdet eller applikationen genererar omdirigeringar för sitt interna värdnamn.

Fånga den Exakta Omdirigeringsloopen i Webbläsaren

Öppna webbläsarens nätverkspanel innan du loggar in utifrån hemmet. Spara förfrågningsloggen och registrera varje statuskod, Location-header, Set-Cookie-header, förfrågningsvärdnamn och om sessionscookien visas vid nästa förfrågan.

En felsökningsguide för Keycloak rekommenderar att observera hela omdirigeringskedjan eftersom saknade vidarebefordrade headers, cookie-omfång och callbacks alla kan skapa en oändlig inloggningsomdirigering även när lösenordssteget lyckas.

Om ingen cookie utfärdas, undersök applikationen och proxyresponsen. Om en cookie utfärdas men inte returneras, kontrollera dess domän, sökväg, Secure och SameSite-attribut. Om cookien returneras men appen ändå omdirigerar, fortsätt med proxytrust och sessionslagring.

Jämför Lokala och Offentliga Värdnamn och Scheman

Skriv ner den exakta lokala URL:en och den offentliga URL:en, inklusive http eller https, värdnamn, port och delväg. Testa om applikationen har en konfigurerad kanonisk eller extern bas-URL.

En analys av WordPress bakom en omvänd proxy förklarar att när backend tror att förfrågan är HTTP kan den omdirigera till HTTPS upprepade gånger medan proxyn fortsätter att terminera TLS. Loopen kommer från felaktig HTTPS-detektion bakom proxyn snarare än från användarens lösenord.

Använd ett offentligt värdnamn konsekvent för fjärrinloggning, callbacks och cookies. Blanda inte den offentliga domänen, privata IP, interna värdnamnet och alternativa portar inom ett autentiseringsflöde om inte applikationen uttryckligen stöder flera betrodda ursprung.

Verifiera Vidarebefordrade Host- och Protokollheaders

Kontrollera konfigurationen av den omvända proxyn och backendloggar för X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-Port och den ursprungliga klientadressen. Bekräfta att applikationen endast litar på den kända proxyn och rekonstruerar samma offentliga URL som webbläsaren använde.

En qBittorrent-fallstudie med omvänd proxy noterar att en inloggningssida kan laddas och acceptera uppgifter medan en felaktig Host- eller HTTPS-header förhindrar att den autentiserade sessionen känns igen.

Om proxyn skickar rätt offentliga värden men appen ignorerar dem, konfigurera applikationens trusted-proxy och external-URL-inställningar. Om proxyn utelämnar dem, lägg till de smala nödvändiga headers istället för att vidarebefordra varje klientlevererad header oförändrad.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Inspektera Cookie-domän, Sökväg, Secure och SameSite

Jämför sessionscookien som skapas lokalt med den som skapas via den offentliga domänen. En cookie som är begränsad till ett internt värdnamn, fel föräldradomän, annan delväg eller icke-säkert sammanhang kanske inte följer med den omdirigerade offentliga förfrågan.

Extern åtkomst lägger ofta till en annan autentiseringsdomän eller cross-site callback. SameSite-begränsningar och Secure-krav kan därför påverka det fjärrflödet även om en direkt lokal inloggning aldrig lämnar ett ursprung.

Rensa cookies endast för de berörda privatmolnsdomänerna, reproducera loopen och inspektera de nya attributen. Korrigera applikationens eller proxyns offentliga URL och cookie-inställningar; använd inte webbläsaromfattande cookie-avslappning som en permanent serverlösning.

Kontrollera OAuth-, OIDC- eller Forward-Auth Callback-Identitet

Om privatmolnet använder en identitetsleverantör eller forward-auth-tjänst, jämför callback-URL:en som genereras av appen, registreras hos leverantören och nås av webbläsaren. Schema, värdnamn, port, sökväg och avslutande snedstreck måste alla matcha exakt.

En NGINX-community-fallstudie beskriver en fjärrinloggningsloop där TLS termineras vid proxyn men backend ser HTTP, så applikationen kan inte upprätthålla den förväntade säkra externa sessionen.

Testa callback-endpointen direkt via den offentliga domänen och bekräfta att den når rätt proxyväg och backend. Om autentiseringen lyckas men callbacken startar om inloggningen, inspektera state, nonce, cookie-persistens, klocksynkronisering och den exakta omdirigerings-URI:n.

Verifiera Den Fullständiga Fjärrsessionen Utan Att Bypassa Proxyn

Efter att ha åtgärdat en orsak, börja med ett rent privat fönster på ett externt nätverk. Logga in, uppdatera instrumentpanelen, öppna en fil, vänta längre än den korta sessionsintervallet och anslut igen för att bekräfta att sessionen överlever vanlig navigering.

ZimaSpace-guiden för kontrollerad fjärråtkomst till NAS ger den omgivande säkerhetsgränsen: att fixa loopen bör inte kräva att backend exponeras direkt eller att autentisering inaktiveras.

Problemet är löst först när lokala och fjärranvändare når det avsedda värdnamnet, proxyn bevarar den offentliga förfrågningsidentiteten, cookien förblir giltig och hela inloggnings- och callback-flödet lyckas upprepade gånger. Ta bort tillfälliga omvägar och utförliga autentiseringsloggar efter verifiering.