Czy dwa odwrotne serwery proxy mogą współdzielić porty 80 i 443 na jednym serwerze domowym?

Nie na tym samym adresie IP i protokole jednocześnie, chyba że jeden serwer proxy jest jedynym punktem wejścia i przekazuje wybrany ruch do drugiego albo każdy z nich nasłuchuje na innym adresie IP.

Staje się to rzeczywistym problemem zgodności, gdy dwa kontenery proxy publikują porty hosta 80 i 443 dla oddzielnych stosów aplikacji na jednej maszynie. Zacznij od ścieżki lub konta przeznaczonych do testów, zachowaj dostęp do poprzedniego działającego stanu i oceniaj projekt na podstawie pierwotnego obciążenia, a nie jednorazowego testu połączenia.

Ustal, kto posiada współdzielony zasób

Obsługiwana gałąź to jeden nasłuchujący proces na każdą parę adres IP-port, z routingiem za nim. Konkurencyjna gałąź to dwa niezależne procesy nasłuchujące, które rywalizują o ten sam gniazdko. Zapisz wersje, tożsamości, adresy, ścieżki montowania, uprawnienia i bieżący obserwowalny stan przed zmianą którejkolwiek gałęzi.

Odpowiednie reguły wiązania gniazd definiują pierwszą granicę zgodności. Wykorzystaj je do ograniczenia twierdzenia, a następnie zweryfikuj to samo zachowanie na dokładnie tym serwerze domowym, zamiast uznawać udokumentowaną funkcję za dowód, że cały projekt działa.

Zapisz regułę decyzyjną przed testowaniem: sukces musi oznaczać, że tylko zamierzony główny serwer proxy posiada każde publiczne gniazdko, a każda nazwa hosta trafia do właściwego serwera nadrzędnego z oczekiwanym certyfikatem; porażka obejmuje zgłoszenie przez uruchamianie błędu „adres jest już używany”, trafienie ruchu do niewłaściwego proxy lub zakończenie TLS certyfikatem innej witryny. Zapobiega to błędnej interpretacji częściowego połączenia lub poprawnego zakończenia polecenia jako zgodności od końca do końca.

Zmieniaj jeden proces nasłuchujący lub trasę naraz

Użyj jednego kontrolowanego czynnika rozróżniającego: wyświetl bieżące procesy nasłuchujące, przypisz każde proxy do osobnego testowego adresu IP albo umieść jedno za drugim, a następnie przetestuj routing na podstawie Host, SNI, WebSocket i certyfikatu. Zachowaj niezmienione klienta, obciążenie, zestaw plików, konto i czas, aby zmieniony komponent był jedynym prawdopodobnym wyjaśnieniem.

Wykorzystaj zachowanie publikowanych portów, aby wybrać drugą obserwację istotną dla tej ścieżki. Zarejestruj obie strony transakcji: resolver lub trasę, wynegocjowany protokół, tożsamość procesu, kod zakończenia, opóźnienie, przesłane bajty i każde zdarzenie odzyskiwania.

Powtórz test po zdarzeniu cyklu życia wymienionym w tytule - odtworzeniu, ponownym połączeniu, ponownym zamontowaniu, ponownym uruchomieniu, przełączeniu awaryjnym lub zmianie klienta. Projekt, który działa tylko wtedy, gdy stare gniazda, pamięci podręczne lub dane uwierzytelniające pozostają aktywne, nie przeszedł testu.

ss -ltnp '( sport = :80 or sport = :443 )'
docker ps --format '{{.Names}} {{.Ports}}'

Decyduj na podstawie obserwowalnych dowodów routingu

WYNIK POZYTYWNY: tylko zamierzony główny serwer proxy posiada każde publiczne gniazdko, a każda nazwa hosta trafia do właściwego serwera nadrzędnego z oczekiwanym certyfikatem. Zapisz dokładne wersje i topologię, które doprowadziły do tego stanu, ponieważ wniosek dotyczy tych warunków, a nie każdej implementacji protokołu.

WYNIK NEGATYWNY: uruchamianie zgłasza, że adres jest już używany, ruch trafia do niewłaściwego proxy lub TLS kończy się certyfikatem innej witryny. Sprawdź współdzielone zależności, takie jak DNS, MTU, tożsamość, stan zapory, opóźnienia pamięci masowej i buforowane sesje, zanim przypiszesz odpowiedzialność którejkolwiek z głównych gałęzi.

WYJĄTEK: zatrzymaj drugie publiczne wiązanie, przywróć ostatni działający proces nasłuchujący i wybierz jeden punkt wejścia albo oddzielne adresy hostów. Nie rozszerzaj uprawnień, nie usuwaj danych źródłowych, nie osłabiaj bezpieczeństwa transportu ani nie wymieniaj działającej pamięci masowej, dopóki powtarzalna obserwacja nie wskaże, która granica zawiodła.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Ponownie sprawdź izolację przed powrotem ruchu produkcyjnego

Zastosuj wyłącznie działanie dopasowane do zaobserwowanej gałęzi, a następnie ponownie uruchom pierwotne obciążenie. Zachowaj projekt tylko wtedy, gdy tylko zamierzony główny serwer proxy posiada każde publiczne gniazdko, a każda nazwa hosta trafia do właściwego serwera nadrzędnego z oczekiwanym certyfikatem podczas dwóch odpowiednich cykli życia i przy oczekiwanym równoczesnym obciążeniu.

Użyj dedykowanych sieci proxy, aby zweryfikować najbliższy zależny przepływ pracy. Jego zachowanie dotyczące dostępu, czasu i odzyskiwania musi pozostać niezmienione, gdy nowy projekt jest aktywny.

Zatrzymaj się i wróć do zapisanego stanu, jeśli uruchamianie zgłasza, że adres jest już używany, ruch trafia do niewłaściwego proxy lub TLS kończy się certyfikatem innej witryny. Eskaluj problem, podając znaczniki czasu, dokładne wersje, dowody dotyczące tras lub montowań oraz najmniejszy przypadek odtwarzający błąd, zamiast dodawać kolejne obejście.

Porównaj wynik z przesłonięciami DNS dla odwrotnych serwerów proxy, aby ryzyko nie zostało jedynie przeniesione do innej warstwy sieci, tożsamości, kopii zapasowych lub pamięci masowej.

W przypadku współdzielenia własności portów przez dwa odwrotne serwery proxy kwalifikowana odpowiedź brzmi zatem tak, jak w początkowej ocenie - a nie bezwarunkowo „tak”. Obserwowalny stan pozytywny jest linią akceptacji; stan negatywny jest linią wycofania zmian.

FAQ

Czy SO_REUSEPORT pozwala niezależnym serwerom proxy współdzielić port 443?

Nie jest to bezpieczny projekt routingu na podstawie nazw hostów dla niezależnych serwerów proxy; użyj jednego punktu wejścia TLS albo oddzielnych adresów IP.

Czy jeden serwer proxy może przekazywać TLS do drugiego?

Tak, gdy routing odbywa się na podstawie SNI, a certyfikaty dla danej nazwy hosta są kończone przez podrzędny serwer proxy.

Czy procesy nasłuchujące IPv4 i IPv6 kolidują ze sobą?

Mogą, zależnie od zachowania gniazda w trybie dual-stack i adresów wiązania; sprawdź jawnie obie rodziny protokołów.