Dlaczego pętla logowania do prywatnej chmury pojawia się tylko poza siecią domową?

Pętla logowania tylko z zewnątrz zwykle oznacza, że zdalna ścieżka proxy zmienia schemat, nazwę hosta, ciasteczko, adres zwrotny lub informacje o sesji widziane przez aplikację.

W domu przeglądarka może łączyć się bezpośrednio z usługą chmury prywatnej przez jej lokalny adres, podczas gdy użytkownicy zdalni wchodzą przez publiczny DNS, zakończenie TLS, reverse proxy, warstwę forward-auth, tunel lub dostawcę tożsamości. Dane uwierzytelniające mogą być poprawnie zaakceptowane, ale następne żądanie wraca do strony logowania, ponieważ ciasteczko sesji nie jest przechowywane lub zwracane, backend myśli, że HTTPS to HTTP, adres zwrotny różni się od zarejestrowanej wartości lub aplikacja generuje przekierowania dla swojej wewnętrznej nazwy hosta.

Przechwyć dokładną pętlę przekierowań w przeglądarce

Otwórz panel sieciowy przeglądarki przed logowaniem się spoza domu. Zachowaj dziennik żądań i zanotuj każdy kod statusu, nagłówek Location, nagłówek Set-Cookie, nazwę hosta żądania oraz czy ciasteczko sesji pojawia się przy następnym żądaniu.

Przewodnik rozwiązywania problemów z Keycloak zaleca obserwowanie pełnego łańcucha przekierowań, ponieważ brakujące nagłówki forwarded, zakres ciasteczek i adresy zwrotne mogą wszystkie powodować nieskończone przekierowanie logowania, nawet gdy etap hasła się powiedzie.

Jeśli nie jest wydawane ciasteczko, zbadaj odpowiedź aplikacji i proxy. Jeśli ciasteczko jest wydawane, ale nie zwracane, sprawdź jego domenę, ścieżkę, atrybuty Secure i SameSite. Jeśli ciasteczko wraca, ale aplikacja nadal przekierowuje, kontynuuj sprawdzanie zaufania do proxy i przechowywania sesji.

Porównaj lokalne i publiczne nazwy hostów oraz schematy

Zapisz dokładny lokalny URL i publiczny URL, włączając http lub https, nazwę hosta, port i podścieżkę. Sprawdź, czy aplikacja ma skonfigurowany kanoniczny lub zewnętrzny URL bazowy.

Analiza WordPressa z reverse-proxy wyjaśnia, że gdy backend uważa, że żądanie jest HTTP, może wielokrotnie przekierowywać do HTTPS, podczas gdy proxy nadal kończy TLS. Pętla wynika z niepoprawnego wykrywania HTTPS za proxy, a nie z powodu hasła użytkownika.

Używaj jednej publicznej nazwy hosta konsekwentnie do zdalnego logowania, adresów zwrotnych i ciasteczek. Nie mieszaj publicznej domeny, prywatnego IP, wewnętrznej nazwy hosta i alternatywnych portów w jednym przepływie uwierzytelniania, chyba że aplikacja wyraźnie obsługuje wiele zaufanych źródeł.

Zweryfikuj nagłówki Forwarded Host i Protocol

Sprawdź konfigurację reverse proxy i logi backendu pod kątem X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-Port oraz oryginalnego adresu klienta. Potwierdź, że aplikacja ufa tylko znanemu proxy i rekonstruuje ten sam publiczny URL, którego używała przeglądarka.

Przypadek reverse-proxy qBittorrent zauważa, że strona logowania może się załadować i zaakceptować dane uwierzytelniające, podczas gdy niezgodny nagłówek Host lub HTTPS uniemożliwia rozpoznanie uwierzytelnionej sesji.

Jeśli proxy wysyła poprawne publiczne wartości, ale aplikacja je ignoruje, skonfiguruj ustawienia trusted-proxy i external-URL aplikacji. Jeśli proxy ich nie wysyła, dodaj tylko wąskie wymagane nagłówki zamiast przekazywać wszystkie nagłówki dostarczone przez klienta bez zmian.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Sprawdź domenę ciasteczka, ścieżkę, Secure i SameSite

Porównaj ciasteczko sesji utworzone lokalnie z tym utworzonym przez publiczną domenę. Ciasteczko ograniczone do wewnętrznej nazwy hosta, złej domeny nadrzędnej, innej podścieżki lub kontekstu nieszyfrowanego może nie towarzyszyć przekierowanemu publicznemu żądaniu.

Dostęp z zewnątrz często dodaje kolejną domenę uwierzytelniania lub adres zwrotny cross-site. Ograniczenia SameSite i wymagania Secure mogą więc wpływać na zdalny przepływ, mimo że bezpośrednie lokalne logowanie nigdy nie opuszcza jednego źródła.

Wyczyść ciasteczka tylko dla dotkniętych domen chmury prywatnej, odtwórz pętlę i sprawdź nowe atrybuty. Popraw publiczny URL aplikacji lub proxy oraz ustawienia ciasteczek; nie stosuj globalnego rozluźnienia ciasteczek w przeglądarce jako trwałego rozwiązania po stronie serwera.

Sprawdź tożsamość callback OAuth, OIDC lub Forward-Auth

Jeśli chmura prywatna korzysta z dostawcy tożsamości lub usługi forward-auth, porównaj adres zwrotny generowany przez aplikację, zarejestrowany u dostawcy i osiągany przez przeglądarkę. Schemat, nazwa hosta, port, ścieżka i końcowy ukośnik muszą się dokładnie zgadzać.

Przypadek społeczności NGINX opisuje zdalną pętlę logowania, gdzie TLS kończy się na proxy, ale backend widzi HTTP, więc aplikacja nie może utrzymać oczekiwanej bezpiecznej zewnętrznej sesji.

Przetestuj punkt końcowy callback bezpośrednio przez publiczną domenę i potwierdź, że trafia do właściwej trasy proxy i backendu. Jeśli uwierzytelnianie się powiedzie, ale callback restartuje logowanie, sprawdź stan, nonce, trwałość ciasteczek, synchronizację zegara i dokładny URI przekierowania.

Zweryfikuj pełną zdalną sesję bez omijania proxy

Po usunięciu jednej przyczyny zacznij od czystego okna prywatnego w zewnętrznej sieci. Zaloguj się, odśwież pulpit, otwórz plik, poczekaj dłużej niż krótki interwał sesji i ponownie połącz, aby potwierdzić, że sesja przetrwa zwykłą nawigację.

Przewodnik ZimaSpace dotyczący kontrolowanego zdalnego dostępu do NAS podaje otoczenie bezpieczeństwa: naprawa pętli nie powinna wymagać bezpośredniego wystawiania backendu ani wyłączania uwierzytelniania.

Problem jest rozwiązany tylko wtedy, gdy lokalni i zdalni użytkownicy docierają do zamierzonej nazwy hosta, proxy zachowuje tożsamość publicznego żądania, ciasteczko pozostaje ważne, a pełny przepływ logowania i callback powtarzalnie się udaje. Usuń tymczasowe obejścia i szczegółowe logi uwierzytelniania po weryfikacji.