Jak reverse proxy obsługuje TLS dla kontenerów serwera domowego?

Reverse proxy obsługuje TLS dla kontenerów serwera domowego, akceptując zaszyfrowane połączenie przeglądarki, prezentując certyfikat dla żądanej nazwy hosta, odszyfrowując żądanie HTTP, wybierając pasujący kontener i tworząc osobne połączenie upstream do tej usługi.

Połączenia przeglądarka-proxy i proxy-kontener to różne granice bezpieczeństwa. Pierwsze zwykle używa publicznie lub prywatnie zaufanego certyfikatu; drugie może korzystać z izolowanej sieci HTTP, osobnego połączenia HTTPS lub TLS passthrough, gdy backend musi zachować prywatny klucz.

Gdzie kończy się połączenie TLS przeglądarki?

Przy terminacji TLS reverse proxy kończy połączenie TLS klienta. Przeglądarka uwierzytelnia punkt końcowy proxy i negocjuje z nim szyfrowanie, a nie bezpośrednio z kontenerem aplikacji.

Proxy zatem posiada prywatny klucz certyfikatu i może odczytać odszyfrowaną metodę HTTP, nazwę hosta, ścieżkę, nagłówki, ciasteczka i ciało. Ta widoczność pozwala na trasowanie, uwierzytelnianie, filtrowanie, kompresję, buforowanie lub dodawanie nagłówków bezpieczeństwa.

Terminacja nie oznacza, że backend posiada publiczny certyfikat. Z perspektywy przeglądarki reverse proxy jest serwerem HTTPS; z perspektywy kontenera proxy jest nowym klientem wysyłającym osobne żądanie.

Jak jeden port HTTPS obsługuje kilka kontenerów?

Publiczna nazwa DNS kieruje klientów do reverse proxy, a nazwy hostów wybierają pasującą trasę kontenera. Każda nazwa hosta może mieć własny certyfikat i docelowy serwer upstream, dzieląc port 443.

Podczas negocjacji TLS klient zazwyczaj podaje zamierzoną nazwę serwera, aby proxy mogło wybrać pasujący certyfikat. Po odszyfrowaniu nagłówek HTTP Host i skonfigurowana trasa decydują, czy żądanie trafi do Jellyfin, Home Assistant, Vaultwarden czy innego kontenera.

Domyślna trasa powinna odrzucać nieznane nazwy hostów, zamiast przekazywać je do dowolnego panelu. Centralizacja wejścia nie wymaga, aby każda usługa wewnętrzna była dostępna przez publiczny proxy.

Jak są wydawane i odnawiane certyfikaty?

Reverse proxy może działać jako klient ACME, a wyzwania DNS automatyzują odnawianie certyfikatów przez tworzenie tymczasowego rekordu DNS potwierdzającego kontrolę nad żądaną domeną.

Wyzwanie HTTP potwierdza kontrolę przez punkt końcowy WWW, podczas gdy wyzwanie DNS może wydawać certyfikaty dla usług wewnętrznych lub nazw wieloznacznych bez publikowania każdego kontenera bezpośrednio. Metoda walidacji zmienia ekspozycję i wymagania dotyczące poświadczeń.

Automatyzacja przenosi wygasanie certyfikatów z ręcznego zadania kalendarzowego do stanu infrastruktury. Sprawia też, że token API DNS proxy, dane konta ACME i magazyn certyfikatów stają się wrażliwymi zasobami wymagającymi ograniczonych uprawnień i kopii zapasowych.

Czy ruch jest szyfrowany między proxy a kontenerem?

Upstream jest konfigurowany niezależnie, więc łącza upstream mogą używać HTTP lub HTTPS. Zakończenie publicznego TLS nie decyduje automatycznie, czy połączenie wewnętrzne jest szyfrowane.

Prosty HTTP może być rozsądny w prywatnej sieci kontenerów ograniczonej do jednego zaufanego hosta, ale proxy może odczytywać i modyfikować ten ruch. Jeśli upstream przekracza hosty, niezaufane sieci lub silniejsze granice zaufania, osobne zweryfikowane połączenie HTTPS zmniejsza ryzyko.

Ponowne szyfrowanie tworzy dwie sesje TLS i dwie decyzje dotyczące certyfikatów. Proxy musi zweryfikować certyfikat backendu i oczekiwaną nazwę; samo włączenie HTTPS bez weryfikacji zastępuje szyfrowanie tunelem bez uwierzytelnienia.

Jak kontener poznaje oryginalny kontekst klienta?

Połączenie TCP upstream pochodzi z proxy, więc połączenia proxy ukrywają oryginalny adres klienta. Przekazywane nagłówki zawierają IP klienta, oryginalny schemat, nazwę hosta i port potrzebne aplikacji.

Bez oryginalnego schematu HTTPS aplikacja może generować przekierowania HTTP, błędnie oznaczać bezpieczne ciasteczka lub tworzyć nieprawidłowy adres URL zwrotny. Bez wiarygodnego adresu klienta, logi, limity szybkości i polityki dostępu mogą identyfikować tylko proxy.

Proxy musi konsekwentnie ustawiać te wartości, a framework kontenera musi być skonfigurowany tak, aby ufać odpowiedniej liczbie przeskoków lub sieci proxy. Przekazywanie nagłówka i jego bezpieczna interpretacja to odrębne zadania.

Jaką nową granicę zaufania tworzy zakończenie TLS?

Klienci mogą sami wysyłać sfałszowane nagłówki przekazywania, dlatego zaufane proxy muszą oczyszczać przekazywane nagłówki zanim backend użyje ich do decyzji bezpieczeństwa.

Bezpośredni dostęp do kontenera powinien być zablokowany, gdy aplikacja ufa tożsamości dostarczanej przez proxy. W przeciwnym razie klient może ominąć proxy, przesłać własne wartości X-Forwarded-For lub schematu i podszyć się pod kontekst, który aplikacja zakłada jako pochodzący z zaufanego ingress.

ingress kontenera przepisuje widoczną ścieżkę klienta. Chroń prywatne klucze proxy, ogranicz interfejs zarządzania, udostępniaj tylko zamierzone trasy i monitoruj odnawianie certyfikatów oraz stan upstream, ponieważ proxy jest teraz wspólnym elementem bezpieczeństwa.

FAQ

Czy każdy kontener potrzebuje własnego publicznego certyfikatu TLS?

Nie, gdy reverse proxy kończy TLS. Proxy może posiadać certyfikaty dla kilku nazw hostów i przekazywać odszyfrowane żądania do oddzielnych wewnętrznych kontenerów.

Czy HTTP od proxy do kontenera jest zawsze niebezpieczny?

To zależy od granicy zaufania. Izolowana sieć na tym samym hoście ma inne ryzyko niż sieć trasowana lub współdzielona. HTTPS z weryfikacją certyfikatu zapewnia silniejszą ochronę na nieufnych segmentach.

Czy reverse proxy może kierować HTTPS bez jego odszyfrowania?

Tak. Przekazywanie TLS może kierować ruchem na podstawie informacji z handshake, takich jak SNI, podczas gdy backend kończy TLS, ale proxy traci normalną widoczność i filtrowanie na warstwie HTTP.

Dlaczego kontenery powinny odrzucać bezpośredni dostęp z zewnątrz?

Gdy aplikacja ufa przekazywanym nagłówkom, bezpośredni dostęp pozwala klientom ominąć sanitację proxy i przesłać sfałszowane wartości tożsamości, schematu lub nazwy hosta.

Ostateczne wnioski

Reverse proxy obsługuje TLS, stając się publicznym punktem końcowym kryptografii i tworząc drugie, osobno zarządzane połączenie do każdego kontenera. Niezawodne bezpieczeństwo zależy od poprawnego routingu nazw hostów, automatycznego, ale chronionego odnawiania certyfikatów, świadomego szyfrowania upstream, oczyszczonych nagłówków przekazywania oraz blokowania ścieżek omijających zaufany proxy.