Zarządzanie zaporą sieciową wykracza poza same hosty wirtualne. Zarówno zapory sieciowe maszyn wirtualnych, jak i hostów fizycznych muszą zezwalać na ruch na portach wymaganych przez komponenty do komunikacji ze sobą.
Diagramy portów
Poniższe obrazy przedstawiają wymagania dotyczące portów w konfiguracji z jednym centrum danych i z wieloma centrami danych:
Jedno centrum danych
Ilustracja poniżej przedstawia wymagania dotyczące portów dla każdego komponentu Edge w konfiguracji pojedynczego centrum danych:
Uwagi dotyczące tego diagramu:
- Porty z prefixem „M” służą do zarządzania komponentem i muszą być otwarte na tym komponencie, aby serwer zarządzający miał do nich dostęp.
- Interfejs Edge wymaga dostępu do routera na portach udostępnianych przez serwery proxy interfejsu API, aby obsługiwać przycisk Wyślij w narzędziu śledzenia.
- Dostęp do portów JMX można skonfigurować tak, aby wymagał podania nazwy użytkownika i hasła. Więcej informacji znajdziesz w sekcji Jak monitorować.
- Opcjonalnie możesz skonfigurować dostęp TLS/SSL dla niektórych połączeń, które mogą korzystać z różnych portów. Więcej informacji znajdziesz w artykule TLS/SSL.
- Możesz skonfigurować serwer zarządzania i interfejs Edge, aby wysyłać e-maile przez zewnętrzny serwer SMTP. Jeśli tak zrobisz, musisz się upewnić, że serwer zarządzający i interfejs użytkownika mają dostęp do odpowiedniego portu na serwerze SMTP (nie jest widoczny). W przypadku protokołu SMTP bez TLS numer portu to zwykle 25. W przypadku SMTP z obsługą TLS jest to zwykle 465, ale sprawdź to u dostawcy SMTP.
Wiele centrów danych
Jeśli instalujesz konfigurację klastra z 12 węzłami i 2 centrami danych, upewnij się, że węzły w obu centrach danych mogą komunikować się za pomocą portów podanych poniżej:
Uwaga:
- Wszystkie serwery zarządzania muszą mieć dostęp do wszystkich węzłów Cassandry we wszystkich innych centrach danych.
- Wszystkie procesory wiadomości we wszystkich centrach danych muszą mieć możliwość wzajemnego dostępu przez port 4528.
- Serwer zarządzający musi mieć dostęp do wszystkich procesorów wiadomości przez port 8082.
- Wszystkie serwery zarządzające i wszystkie węzły Qpid muszą mieć dostęp do Postgres we wszystkich innych centrach danych.
- Ze względów bezpieczeństwa między centrami danych nie powinny być otwarte żadne inne porty poza tymi, które są wymienione powyżej i które są wymagane przez Twoją sieć.
Domyślnie komunikacja między komponentami nie jest szyfrowana. Szyfrowanie możesz dodać, instalując Apigee mTLS. Więcej informacji znajdziesz w artykule Wprowadzenie do mTLS w Apigee.
Szczegóły przeniesienia
W tabeli poniżej znajdziesz opis portów, które należy otworzyć w zaporach sieciowych w przypadku poszczególnych komponentów Edge:
| Komponent | Port | Opis |
|---|---|---|
| Standardowe porty HTTP | 80, 443 | HTTP i inne porty używane przez hosty wirtualne |
| Logowanie jednokrotne Apigee | 9099 | Połączenia z zewnętrznych dostawców tożsamości, serwera zarządzającego i przeglądarek na potrzeby uwierzytelniania. |
| Cassandra | 7000, 9042 | Porty Apache Cassandra do komunikacji między węzłami Cassandra i dostępu innych komponentów Edge. |
| 7199 | Port JMX. Musi być otwarty dla serwera zarządzającego. | |
| LDAP | 10389 | SymasLDAP |
| Serwer zarządzania | 1099 | Port JMX |
| 4526 | Port dla rozproszonej pamięci podręcznej i połączeń zarządzających. Ten port można skonfigurować. | |
| 5636 | Port powiadomień o zobowiązaniach dotyczących zarabiania. | |
| 8080 | Port wywołań interfejsu Edge Management API. Te komponenty wymagają dostępu do portu 8080 na serwerze zarządzania: router, procesor wiadomości, interfejs, Postgres, Apigee SSO (jeśli jest włączony) i Qpid. | |
| Interfejs zarządzania | 9000 | Port dostępu przeglądarki do interfejsu zarządzania |
| procesor komunikatów | 1101 | Port JMX |
| 4528 | W przypadku wywołań rozproszonej pamięci podręcznej i zarządzania między procesorami wiadomości oraz komunikacji z routera i serwera zarządzania.
Procesor wiadomości musi otworzyć port 4528 jako port zarządzania. Jeśli masz kilka procesorów wiadomości, wszystkie muszą mieć dostęp do siebie nawzajem przez port 4528 (wskazuje to strzałka pętli na diagramie powyżej dla portu 4528 na procesorze wiadomości). Jeśli masz kilka centrów danych, port musi być dostępny ze wszystkich procesorów wiadomości we wszystkich centrach danych. |
|
| 8082 |
Domyślny port zarządzania dla procesora wiadomości, który musi być otwarty w komponencie, aby serwer zarządzania miał do niego dostęp. Jeśli skonfigurujesz TLS/SSL między routerem a procesorem wiadomości, router będzie używać tego połączenia do sprawdzania stanu procesora wiadomości. Port 8082 na procesorze wiadomości musi być otwarty tylko w przypadku dostępu przez router, gdy skonfigurujesz protokół TLS/SSL między routerem a procesorem wiadomości. Jeśli nie skonfigurujesz protokołu TLS/SSL między routerem a procesorem wiadomości, domyślna konfiguracja, czyli port 8082, musi być nadal otwarta na procesorze wiadomości, aby zarządzać komponentem, ale router nie wymaga do niej dostępu. |
|
| 8443 | Jeśli protokół TLS jest włączony między routerem a procesorem wiadomości, musisz otworzyć port 8443 na procesorze wiadomości, aby router mógł uzyskać do niego dostęp. | |
| 8998 | Port procesora wiadomości do komunikacji z routerem | |
| Postgres | 22 | Jeśli konfigurujesz 2 węzły Postgres do korzystania z replikacji typu master-standby, musisz otworzyć port 22 na każdym węźle, aby umożliwić dostęp SSH. |
| 1103 | Port JMX | |
| 4530 | W przypadku wywołań rozproszonej pamięci podręcznej i zarządzania | |
| 5432 | Używany do komunikacji z serwera Qpid/zarządzania z Postgresem | |
| 8084 | Domyślny port zarządzania na serwerze Postgres. Musi być otwarty w komponencie, aby serwer zarządzania miał do niego dostęp. | |
| Qpid | 1102 | Port JMX |
| 4529 | W przypadku wywołań rozproszonej pamięci podręcznej i zarządzania | |
| 5672 |
Używany również do komunikacji między serwerem Qpid a komponentami brokera na tym samym węźle. W topologiach z wieloma węzłami Qpid serwer musi mieć możliwość łączenia się ze wszystkimi brokerami na porcie 5672. |
|
| 8083 | Domyślny port zarządzania na serwerze Qpid, który musi być otwarty w komponencie, aby serwer zarządzania miał do niego dostęp. | |
| 8090 | Domyślny port brokera Qpid. Musi być otwarty, aby można było uzyskać dostęp do konsoli zarządzania lub interfejsów API zarządzania brokera na potrzeby monitorowania. | |
| Router | 4527 | W przypadku wywołań rozproszonej pamięci podręcznej i zarządzania.
Router musi otworzyć port 4527 jako port zarządzania. Jeśli masz kilka routerów, wszystkie muszą mieć możliwość komunikowania się ze sobą przez port 4527 (wskazuje to strzałka w kształcie pętli na powyższym diagramie). Nie jest to wymagane, ale możesz otworzyć port 4527 na routerze, aby umożliwić dostęp dowolnemu procesorowi wiadomości. W przeciwnym razie w plikach dziennika procesora wiadomości mogą pojawić się komunikaty o błędach. |
| 8081 | Domyślny port zarządzania routerem, który musi być otwarty w komponencie, aby serwer zarządzania miał do niego dostęp. | |
| 15999 |
Port kontroli stanu. System równoważenia obciążenia używa tego portu, aby określić, czy router jest dostępny. Aby uzyskać stan routera, system równoważenia obciążenia wysyła żądanie do portu 15999 na routerze: curl -v http://routerIP:15999/v1/servers/self/reachable Jeśli router jest osiągalny, żądanie zwraca kod HTTP 200. |
|
| 59001 | Port używany do testowania instalacji Edge przez narzędzie apigee-validate.
To narzędzie wymaga dostępu do portu 59001 na routerze. Więcej informacji o porcie 59001 znajdziesz w artykule Testowanie instalacji. |
|
| SmartDocs | 59002 | Port na routerze brzegowym, na który są wysyłane żądania stron SmartDocs. |
| ZooKeeper | 2181 | Używane przez inne komponenty, takie jak serwer zarządzania, router, procesor wiadomości itp. |
| 2888, 3888 | Używane wewnętrznie przez ZooKeepera do komunikacji z klastrem ZooKeepera (zwanym zespołem ZooKeepera). |
W tabeli poniżej znajdziesz te same porty, ale w kolejności numerycznej, z podziałem na komponenty źródłowe i docelowe:
| Numer portu | Cel | Komponent źródłowy | Komponent miejsca docelowego |
|---|---|---|---|
| virtual_host_port | HTTP i inne porty używane przez Ciebie do przesyłania ruchu wywołań interfejsu API hosta wirtualnego. Najczęściej używane są porty 80 i 443. Router wiadomości może zamykać połączenia TLS/SSL. | Klient zewnętrzny (lub system równoważenia obciążenia) | Odbiornik w routerze wiadomości |
| 1099–1103 | Zarządzanie JMX | Klient JMX | Serwer zarządzający (1099) Procesor wiadomości (1101) Serwer Qpid (1102) Serwer Postgres (1103) |
| 2181 | Komunikacja klienta Zookeeper | Serwer zarządzający Router Procesor wiadomości Serwer Qpid Serwer Postgres |
Opiekun zwierząt |
| 2888 i 3888 | Zarządzanie węzłami Zookeeper | Opiekun zwierząt | Opiekun zwierząt |
| 4526 | Port zarządzania RPC | Serwer zarządzania | Serwer zarządzania |
| 4527 | Port zarządzania RPC dla rozproszonej pamięci podręcznej i wywołań zarządzania oraz do komunikacji między routerami | Serwer zarządzania Router |
Router |
| 4528 | W przypadku wywołań rozproszonej pamięci podręcznej między procesorami wiadomości i komunikacji z routerem | Serwer zarządzający Router Procesor komunikatów |
procesor komunikatów |
| 4529 | Port zarządzania RPC dla rozproszonej pamięci podręcznej i wywołań zarządzania | Serwer zarządzania | Serwer Qpid |
| 4530 | Port zarządzania RPC dla rozproszonej pamięci podręcznej i wywołań zarządzania | Serwer zarządzania | Serwer Postgres |
| 5432 | Klient Postgres | Serwer Qpid | Postgres |
| 5636 | Zarabianie | Zewnętrzny komponent JMS | Serwer zarządzania |
| 5672 |
Używany również do komunikacji między serwerem Qpid a komponentami brokera na tym samym węźle. W topologiach z wieloma węzłami Qpid serwer musi mieć możliwość łączenia się ze wszystkimi brokerami na porcie 5672. |
Serwer Qpid | Serwer Qpid |
| 7000 | Komunikacja między węzłami Cassandra | Cassandra | Inny węzeł Cassandra |
| 7199 | Zarządzanie JMX. Musi być otwarty na węźle Cassandra dla serwera zarządzania. | klient JMX, | Cassandra |
| 8080 | Port interfejsu API zarządzania | Klienty interfejsu Management API | Serwer zarządzania |
| 8081–8084 |
Porty interfejsu API komponentów, które służą do wysyłania żądań API bezpośrednio do poszczególnych komponentów. Każdy komponent otwiera inny port. Dokładny port zależy od konfiguracji, ale musi być otwarty w komponencie, aby serwer zarządzający miał do niego dostęp. |
Klienty interfejsu Management API | Router (8081) Message Processor (8082) Qpid Server (8083) Postgres Server (8084) |
| 8090 | Domyślny port zarządzania dla brokera Qpid, który służy do zarządzania kolejkami i ich monitorowania. | Przeglądarka lub klient interfejsu API | Broker Qpid (apigee-qpidd) |
| 8443 | Komunikacja między routerem a procesorem wiadomości, gdy włączony jest protokół TLS | Router | procesor komunikatów |
| 8998 | Komunikacja między routerem a procesorem wiadomości | Router | procesor komunikatów |
| 9000 | Domyślny port interfejsu zarządzania Edge | Przeglądarka | Serwer interfejsu zarządzania |
| 9042 | Natywny transport CQL | Router Procesor komunikatów Serwer zarządzający |
Cassandra |
| 9099 | Uwierzytelnianie za pomocą zewnętrznego dostawcy tożsamości | Dostawca tożsamości, przeglądarka i serwer zarządzania | Logowanie jednokrotne Apigee |
| 10389 | Port LDAP | Serwer zarządzania | SymasLDAP |
| 15999 | Port kontroli stanu. System równoważenia obciążenia używa tego portu, aby określić, czy router jest dostępny. | System równoważenia obciążenia | Router |
| 59001 | Port używany przez narzędzie apigee-validate do testowania instalacji Edge |
apigee-validate | Router |
| 59002 | Port routera, na który są wysyłane żądania stron SmartDocs. | SmartDocs | Router |
Procesor wiadomości utrzymuje otwartą pulę połączeń z Cassandrą, która jest skonfigurowana tak, aby nigdy nie przekraczać limitu czasu. Jeśli między procesorem wiadomości a serwerem Cassandra znajduje się zapora sieciowa, może ona spowodować przekroczenie limitu czasu połączenia. Procesor wiadomości nie jest jednak przeznaczony do ponownego nawiązywania połączeń z Cassandrą.
Aby temu zapobiec, Apigee zaleca, aby serwer Cassandra, procesor wiadomości i routery znajdowały się w tej samej podsieci, dzięki czemu zapora sieciowa nie będzie brać udziału we wdrażaniu tych komponentów.
Jeśli między routerem a procesorami wiadomości znajduje się zapora sieciowa z ustawionym czasem oczekiwania na nieaktywne połączenie TCP, zalecamy wykonanie tych czynności:
- Ustaw wartość
net.ipv4.tcp_keepalive_time = 1800w ustawieniach sysctl w systemie operacyjnym Linux, gdzie 1800 powinno być mniejsze niż czas oczekiwania zapory sieciowej na nieaktywne połączenie TCP. To ustawienie powinno utrzymywać połączenie w stanie nawiązanym, aby zapora sieciowa nie rozłączała połączenia. - Na wszystkich procesorach wiadomości zmień
/opt/apigee/customer/application/message-processor.properties, aby dodać tę właściwość. Jeśli plik nie istnieje, utwórz go.conf_system_cassandra.maxconnecttimeinmillis=-1
- Uruchom ponownie procesor wiadomości:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- Na wszystkich routerach zmień element
/opt/apigee/customer/application/router.properties, aby dodać tę właściwość. Jeśli plik nie istnieje, utwórz go.conf_system_cassandra.maxconnecttimeinmillis=-1
- Ponownie uruchom router:
/opt/apigee/apigee-service/bin/apigee-service edge-router restart