Przejdz do tresci
Avanet

Konfiguracja Sophos Email Gateway z lokalnym Exchange

W przypadku lokalnego Exchange przepływ poczty ma dwie oddzielne trasy: wiadomości przychodzące trafiają najpierw do regionalnych celów MX Sophos, a następnie do Exchange. Wiadomości wychodzące Exchange wysyła przez regionalny smart host Sophos. Oba kierunki należy skonfigurować i przetestować osobno.

Ten przewodnik nie dotyczy Microsoft 365 ani automatycznego zarządzania konektorami przez Sophos Mailflow. Lokalny serwer Exchange wymaga własnych konektorów odbiorczych i wysyłkowych; nie należy odtwarzać w tym celu konektorów Microsoft 365.

Szybka ścieżka: zapisz bieżące ustawienia i drogę wycofania, skonfiguruj domenę w Sophos Fusion (dawniej Sophos Central) jako Inbound and Outbound, ogranicz odbiór Exchange do regionalnych adresów IP dostarczania Sophos, utwórz Send Connector do skopiowanego Outbound Relay Host, prześledź oba kierunki i dopiero wtedy wyłącz stare trasy filtrowania.

Przygotowanie danych i drogi wycofania

Przed zmianą zapisz w zgłoszeniu:

  • domenę pocztową, na przykład example.org, oraz wszystkich chronionych odbiorców;
  • publicznie dostępny cel Exchange jako FQDN lub adres IP, na przykład mail.example.org, i faktycznie używany port SMTP;
  • publiczne źródłowe adresy IP lub sieci CIDR używane przez Exchange przy wysyłaniu, na przykład wymagający zastąpienia adres dokumentacyjny 192.0.2.25/32;
  • regionalne cele MX, adresy IP dostarczania, Outbound Relay Host i domenę SPF Sophos z bieżących zależności zewnętrznych tenant’a;
  • istniejące konektory odbiorcze i wysyłkowe, ich zakresy i pierwszeństwo oraz reguły zapory i NAT;
  • aktualne wartości MX i SPF wraz z TTL.

Wartości Sophos zależą od regionu. Skopiuj je z własnego tenant’a Sophos Fusion i użyj aktualnych list adresów IP dostarczania Gateway, rekordów MX, hostów relay poczty wychodzącej oraz domen SPF. Tenant pokazuje też relay w Gateway Domains > domena > Configure External Dependencies > Outbound Settings. Zachowaj stare wartości DNS i ustawienia do wycofania oraz wcześniej obniż TTL DNS. Sophos informuje, że propagacja zmian konektorów może potrwać do 24 godzin; natychmiastowy test nie potwierdza więc pełnej propagacji.

Konfiguracja domeny i trasy przychodzącej

Przygotowanie Sophos Gateway

  1. W Sophos Fusion przejdź do Global Settings > Products and Services > Email > Gateway Domains, a następnie dodaj lub otwórz domenę.
  2. Wprowadź domenę, kierunek ruchu, cel dostarczania i jego port SMTP. Pełny przepływ wymaga kierunku Inbound and Outbound.
  3. Wybierz Verify Domain Ownership, opublikuj wyświetloną wartość TXT właściwą dla domeny jako rekord TXT w katalogu głównym domeny, a następnie wybierz Verify. Użyj wyświetlonej nazwy lub @.
  4. Kontynuuj dopiero po potwierdzeniu weryfikacji przez Sophos. Błąd zwykle oznacza nieprawidłową wartość TXT albo nieukończoną propagację DNS.
  5. Dodaj lub zsynchronizuj skrzynki, które ma chronić Sophos Email.

Celem dostarczania jest publicznie dostępny endpoint Exchange, a nie nazwa MX Sophos. Jego FQDN lub adres IP i port muszą dokładnie odpowiadać opublikowanej usłudze SMTP oraz przekierowaniu zapory.

Ograniczenie odbioru Exchange

Na zaporze i ścieżce odbiorczej Exchange zezwól jako źródła trasy Sophos wyłącznie na regionalne adresy IP dostarczania Sophos. Dokładne adresy pobierz z bieżących zależności zewnętrznych tenant’a. Pominięcie adresu może zablokować dostarczanie; obca lub zbyt szeroka sieć osłabia ochronę przed obejściem.

W Exchange Receive Connector używanym przez Sophos ustaw lokalne powiązanie na zamierzony lokalny adres IP Exchange i port nasłuchu; niezależnie ogranicz zdalne zakresy IP wyłącznie do regionalnych IP dostarczania Sophos i nie używaj 0.0.0.0/0. Zwykłe przyjmowanie dla odbiorców w accepted domains Exchange różni się od uprawnienia SMTP relay: nie wymaga ogólnego relay i ten konektor nie może go otrzymać. Jeśli Receive Connectors nakładają się, przed przełączeniem ustal, który obsłuży każdy adres źródłowy Sophos.

Najpierw sprawdź dostępność tej trasy bez usuwania starej ochrony. Następnie zastąp rekordy MX u dostawcy DNS regionalnymi celami MX Sophos. Pisownia, preferencja i region muszą dokładnie odpowiadać wartościom tenant’a.

Konfiguracja trasy wychodzącej przez Sophos

Autoryzacja źródła wychodzącego w Sophos

  1. Otwórz domenę w Gateway Domains i wybierz Edit.
  2. W Configure Domain potwierdź kierunek Inbound and Outbound.
  3. W Outbound Gateway wybierz Custom Gateway.
  4. Dodaj co najmniej jeden publiczny adres IP lub sieć CIDR, z której Sophos rzeczywiście zobaczy połączenia wychodzące, i zapisz. Prywatne adresy Exchange za NAT nie są tutaj widocznym źródłem.
  5. Otwórz Configure External Dependencies > Outbound Settings i skopiuj regionalny Outbound Relay Host.

Zakresy źródłowe powinny być jak najwęższe. Niepotrzebnie duży CIDR może autoryzować obce systemy, natomiast błędny adres NAT powoduje odrzucenie relay.

Przełączenie Exchange Send Connector

W Exchange utwórz SMTP Send Connector dla odbiorców internetowych, wybierz Route mail through smart hosts i przez Add wprowadź skopiowany Outbound Relay Host. Każda kontrolka ma osobne znaczenie: przestrzenie adresowe określają kierowane domeny odbiorców; źródłowe serwery transportu to serwery Exchange, na których konektor jest hostowany — wiadomości wybrane dla tego konektora są kierowane do jednego z nich, a ten ustanawia dostarczenie do smart hosta; koszt rozstrzyga między równie szczegółowymi pasującymi przestrzeniami; ustawienie scoped ogranicza dostępność konektora w topologii Exchange do witryny Active Directory, a nie routing odbiorców. Użyj instrukcji Microsoft dla Exchange 2019, Exchange 2016 lub Exchange 2013.

Podczas testów odbiorczych i przełączenia wyłącz każdy stary filtrujący Send Connector, którego przestrzenie adresowe nakładają się z przestrzeniami konektora Sophos, niezależnie od listy serwerów źródłowych; do wycofania zachowaj udokumentowaną konfigurację, a nie aktywną konkurencyjną trasę. Jeśli pilotaż wymaga obu aktywnych konektorów, przypisz im rzeczywiście nienakładające się przestrzenie adresowe. Rozłączne listy serwerów źródłowych nie dzielą wiadomości według serwera Exchange, z którego pochodzą, i nie zapewniają bezpiecznej izolacji. Nie polegaj tylko na koszcie: Exchange najpierw ocenia szczegółowość przestrzeni adresowej. Po teście pozostaw stary nakładający się konektor wyłączony lub usuń go.

Kontrola SPF, DKIM i obu kierunków

Gdy Sophos dostarcza pocztę wychodzącą, zaktualizuj pojedynczy rekord TXT SPF wartością regionalną z połączonej listy Sophos. Zastąpienie wyłącznie przez Sophos ma dokładnie postać v=spf1 include:<spf-domain> -all. Przy pracy równoległej zachowaj wszystkie istniejące autoryzowane mechanizmy i wstaw include:<spf-domain> przed jedynym końcowym all, na przykład v=spf1 include:old.example include:<spf-domain> -all. Zastąp <spf-domain> wartością regionalną; nigdy nie publikuj placeholdera, drugiego końcowego all ani drugiego rekordu SPF. Wybierz -all tylko przy pewności, że każdy faktyczny nadawca jest ujęty, w przeciwnym razie ~all. Decyduje pokrycie nadawców, a nie wyłączność trasy Sophos. DKIM sprawdź osobno.

W testach używaj unikalnych tematów oraz zapisuj nadawcę, odbiorcę i czas:

  1. Przychodząca: wyślij z domeny zewnętrznej do chronionej skrzynki. W Sophos Fusion wiadomość musi pojawić się w Reports > Message History, a następnie w śledzeniu Exchange i skrzynce docelowej.
  2. Wychodząca: wyślij z chronionej skrzynki do domeny zewnętrznej. Ustaw kierunek Message History na outbound, sprawdź wpis, potwierdź przyjęcie zewnętrzne i śledzenie Exchange.
  3. Obejście i relay: bezpośrednie dostarczenie do Exchange z nieautoryzowanego źródła oraz próba relay do obcej domeny nie mogą zostać przyjęte przez ograniczoną ścieżkę Sophos.

Wpis tylko w jednym systemie nie oznacza sukcesu end-to-end. Powiąż śledzenie Exchange, historię Sophos i wynik u odbiorcy za pomocą znaczników czasu i Message-ID.

Metodyczne rozwiązywanie problemów

  • Wiadomości przychodzącej nie ma w Sophos: sprawdź cele MX, preferencję, propagację DNS i region. Stary MX może nadal omijać bramę.
  • Wiadomość jest w Sophos, ale nie w Exchange: sprawdź cel i port, zaporę/NAT, regionalne IP dostarczania Sophos, zakres Receive Connector i kolejki Exchange. Wyklucz też brak skrzynki w Sophos.
  • Wiadomość wychodząca pozostaje w Exchange: sprawdź rozwiązywanie DNS i dostępność Outbound Relay Host, wybrany Send Connector, jego serwery źródłowe i kolejki Exchange.
  • Relay jest odrzucany: ustal publiczny źródłowy IP widziany przez Sophos i porównaj z wartościami IP/CIDR w Custom Gateway. Nie rozszerzaj zakresu bez analizy.
  • TLS nie działa: sprawdź nazwy smart hosta i celu, łańcuch, ważność i zgodność nazwy certyfikatu oraz negocjację TLS po obu stronach. Nie wyłączaj TLS na stałe, aby ukryć problem.
  • Część wiadomości używa starej trasy lub wpada w pętlę: sprawdź nakładające się przestrzenie Send Connectors, koszty/pierwszeństwo i stare konektory filtrowania. Stare cele MX i wcześniejsze relay’e również mogą utworzyć pętlę.

Po każdej korekcie powtórz test danego kierunku i porównaj nowe znaczniki czasu. Jeśli przepływu nadal brak, zbierz Message-ID, przedział czasu, stan konektora, błąd kolejki i zgodny wpis Sophos Message History do eskalacji.

Bezpieczne wycofanie zmian

Wycofaj tylko niesprawny kierunek. Przy problemach przychodzących przywróć zapisane poprzednie wartości MX i pozostaw starą ścieżkę odbiorczą aktywną do propagacji DNS. Przy problemach wychodzących najpierw przywróć zapisane wcześniejsze mechanizmy nadawców, łącząc je w pojedynczym rekordzie SPF domeny, tymczasowo zachowaj include:<spf-domain> i uwzględnij propagację DNS zgodnie z planem zmiany. Następnie włącz znany poprzedni Send Connector i jednoznacznie wyłącz nowy Sophos Send Connector, aby uniknąć konkurencyjnych tras.

Zmiany zapory i Receive Connector usuń dopiero, gdy przywrócona trasa przychodząca działa w sposób potwierdzony. Usuń include:<spf-domain> z pojedynczego rekordu SPF domeny dopiero po zweryfikowaniu przywróconej trasy wychodzącej, zachowując przywrócone mechanizmy nadawców. Następnie ponownie przetestuj oba kierunki, sprawdź obie kolejki i udokumentuj pozostałe cache DNS. Dzięki temu częściowy rollback nie stanie się open relay ani drugą niekontrolowaną trasą wysyłkową.