Konfiguracja Sophos Email Gateway z Google Workspace

W integracji Gateway poczta przychodząca płynie Internet → Sophos Gateway → Google Workspace, a wychodząca Google Workspace → Sophos Gateway → Internet. Aby migracja była bezpieczna, skonfiguruj i przetestuj każde miejsce docelowe, bramę i trasę wewnętrzną przed zmianą produkcyjnych rekordów MX. Na każdym etapie zachowasz znaną ścieżkę dostarczania i możliwość wycofania.

Szybka ścieżka: zweryfikuj domenę w Sophos Fusion (dawniej Sophos Central), przygotuj oddzielny host dostarczania Google, dodaj skrzynki, ogranicz Google Inbound Gateway do regionalnych adresów IP Sophos i kieruj wiadomości wewnętrzne bezpośrednio do Google. Następnie wpisz Outbound Relay Host pokazany w Sophos Fusion jako bramę wychodzącą Google. Dopiero po testach w obu kierunkach zmień główne rekordy MX na wartości wyświetlane dla regionu Sophos.

Zakres i wymagania wstępne

Poradnik dotyczy Sophos Email w trybie Gateway z Google Workspace. Potrzebny jest dostęp administracyjny do Sophos Fusion, konsoli administracyjnej Google i DNS domeny pocztowej. Domena musi być skonfigurowana w Sophos Gateway, a każdy chroniony odbiorca musi istnieć w Sophos Email.

Przed rozpoczęciem zapisz w arkuszu zmiany:

domenę pocztową i objętą zmianą jednostkę organizacyjną Google Workspace;
aktualny produkcyjny zestaw MX wraz z priorytetami i TTL;
aktualny rekord SPF oraz istniejącą konfigurację DKIM i DMARC;
wartości MX, Delivery IP, relay i SPF pokazywane w Sophos Fusion dla regionu danych;
aktualne miejsca docelowe MX wskazane przez Google dla tenanta;
jednego zewnętrznego i jednego wewnętrznego nadawcę testowego oraz odbiorcę wewnętrznego i zewnętrznego;
planowane wymagania TLS oraz okno konserwacji lub wycofania.

Nie kopiuj regionalnych hostów ani adresów IP z przykładów lub starych zgłoszeń. Pobierz je z Sophos Fusion bezpośrednio przed zmianą. Miejsca docelowe Google zweryfikuj również z aktualną dokumentacją Google lub widokiem tenanta.

Granica produktu: Google Post Delivery Protection i synchronizacja Google Directory nie zmieniają ani nie zastępują tego projektu routingu SMTP. Są to osobne zadania, których ten poradnik nie obejmuje.

Bezpieczne przygotowanie zmiany

Udokumentuj aktualny przepływ za pomocą jednej przychodzącej i jednej wychodzącej wiadomości testowej. Zachowaj nagłówki i śledzenie Google oraz potwierdź, że wiadomości nie pojawiają się jeszcze w Sophos Message History.
Z odpowiednim wyprzedzeniem obniż DNS TTL produkcyjnych rekordów MX do wartości właściwej operacyjnie. Zapisz stary zestaw MX i wszystkie istniejące reguły routingu Google jako stan wycofania.
Sprawdź, czy działa już inna secure email gateway, Google Outbound Gateway albo reguła catch-all. Nie stosuj równolegle nakładających się reguł do tych samych wiadomości.
Użyj małej grupy pilotażowej lub zaplanowanego okna testowego. Zabezpieczenia takie jak Reject all mail not from gateway IPs włącz dopiero po dodaniu wszystkich regionalnych Sophos Delivery IP i przetestowaniu wewnętrznych ścieżek Google.

Najważniejszą ochroną przed pętlą jest jednoznaczne rozdzielenie miejsc docelowych: główny MX będzie wskazywał Sophos, natomiast miejsce dostarczania zapisane w Sophos wskazuje oddzielne miejsce Google i nigdy nie wskazuje z powrotem na MX Sophos. Trasa wychodząca Google wskazuje Sophos, lecz nie może być ponownie stosowana do wiadomości przychodzących już dostarczonych przez Sophos.

Konfiguracja przepływu przychodzącego

Przygotowanie domeny i miejsca docelowego Google w Sophos

W Sophos Fusion otwórz Global Settings > Products and Services > Email > Gateway Domains, a następnie wybierz lub dodaj domenę.
Jako Delivery Destination użyj oddzielnej nazwy MX pod własną domeną, na przykład routing-mx.example.com, i wpisz port SMTP udokumentowany przez Sophos. Jest to dedykowana ścieżka DNS dla dostaw Sophos, nie produkcyjny MX domeny głównej.
Uruchom Verify Domain Ownership, opublikuj w DNS bez zmian wartość TXT pokazaną dla domeny i ponów weryfikację po propagacji.
Dla routing-mx.example.com utwórz rekordy MX wskazujące aktualne miejsca docelowe Google określone dla tenanta Google Workspace. Nie mogą wskazywać Sophos.
Dodaj każdą chronioną skrzynkę lub odbiorcę do Sophos Email i zapisz konfigurację domeny.

Weryfikacja kończy się powodzeniem, gdy Sophos Fusion pokazuje domenę jako zweryfikowaną, a zapytanie DNS o routing-mx.example.com zwraca wyłącznie zamierzone miejsca docelowe Google.

Jeśli dostarczanie przez ASPMX.L.GOOGLE.COM sprawia problemy, zmień wyłącznie miejsce docelowe dostarczania Google za routing-mx.example.com na SMTP.GOOGLE.COM. Jest to warunkowa alternatywa dla dostarczania z Sophos do Google, a nie uniwersalne ustawienie domyślne ani zmiana produkcyjnego MX domeny głównej, który nadal wskazuje Sophos. Przed zmianą potwierdź wartości właściwe dla środowiska Google Workspace, a następnie ponownie przetestuj przychodzący przepływ poczty. Jeśli również ten test zakończy się niepowodzeniem, przywróć wcześniej udokumentowane miejsce docelowe Google i skontaktuj się z Sophos Support.

Zabezpieczenie Google Inbound Gateway

W konsoli administracyjnej Google otwórz Apps > Google Workspace > Gmail > Spam, Phishing and Malware > Inbound gateway dla objętej zmianą organizacji najwyższego poziomu.
Włącz Inbound Gateway i dodaj wyłącznie Delivery IP wymienione w Sophos Fusion dla regionu.
Włącz Automatically detect external IP i uzgodnione wymaganie TLS.
Reject all mail not from gateway IPs włącz dopiero po teście pilotażowym. Opcja blokuje dostarczanie bezpośrednie i zapobiega pomijaniu Sophos, ale niepełna lista IP może zatrzymać również prawidłową pocztę.
Zapisz i zaczekaj do 24 godzin na zastosowanie ustawienia przychodzącego.

Jeśli ścisłe ograniczenie blokuje własne ścieżki dostarczania Google, tymczasowo wyłącz odrzucanie, przywróć przepływ i ustal wymagane aktualne adresy Google i Sophos na podstawie wskazówek producentów. Nie zezwalaj szeroko na nieznane sieci.

Sophos informuje o anomalii DMARC zaobserwowanej we własnych testach: gdy włączono Time of Click URL Protection lub ustawienia wiadomości użytkownika końcowego, Google czasami oznacza wiadomości przychodzące jako niezgodne z DMARC, mimo że dokumentacja Google mówi o pomijaniu uwierzytelniania DMARC dla wiadomości z hostów wpisanych na liście bramy i o wykonywaniu kontroli przez bramę przychodzącą. Sophos podaje, że zgłosił tę rozbieżność firmie Google. Uwzględnij ją, zanim uznasz zgłoszony błąd za dowód nieprawidłowego ustawienia Automatically detect external IP lub listy Delivery IP.

Kierowanie wiadomości wewnętrznych bezpośrednio do Google

Wiadomości wewnętrzne nie powinny przechodzić przez produkcyjny MX do Sophos, a następnie wracać do Google. W Apps > Google Workspace > Gmail > Hosts utwórz trasę z aktualnymi miejscami docelowymi Google dla tenanta. W Apps > Google Workspace > Gmail > Routing zastosuj ją tylko do Internal - Sending i ogranicz do własnej domeny filtrem nadawcy kopertowego. Włącz TLS i walidację certyfikatu podpisanego przez CA zgodnie z wytycznymi Google i Sophos.

Nadaj trasie wewnętrznej i regule bramy wychodzącej nienakładające się zakresy i warunki dopasowania. Zapisz zmianę routingu i zaczekaj do 24 godzin na jej zastosowanie; zmiany możesz śledzić w dzienniku kontrolnym administratora Google Workspace. Nie rozpoczynaj walidacji wiadomości wewnętrznych ani pilota i nie przełączaj produkcyjnego MX, dopóki zmiana nie zacznie obowiązywać. Następnie wyślij wiadomość wewnętrzną do odbiorcy w tej samej domenie: musi pozostać w Google i nie może dodatkowo pojawić się jako skan przychodzący i wychodzący w Sophos.

Konfiguracja przepływu wychodzącego

Otwórz domenę w Gateway Domains i wybierz Inbound and Outbound w Configure Domain.
Wybierz Google Apps Gmail jako Outbound Gateway, zapisz, a następnie skopiuj Outbound Relay Host pokazany dla tenanta w Configure External Dependencies > Outbound Settings. Ta etykieta oznacza Google Workspace w Sophos Fusion.
W konsoli Google otwórz konfigurację bramy wychodzącej objętej zmianą organizacji najwyższego poziomu i wpisz dokładnie ten Relay Host. Aktualny interfejs Google może inaczej rozmieszczać sekcję routingu; nie wyprowadzaj nazw hostów z przykładów.
Nadaj regule kryteria nadawcy i wiadomości, które nie nakładają się na trasę wewnętrzną. Wyłącz drugą regułę catch-all lub gateway w tym samym zakresie albo usuń ją z zakresu.
Zapisz, zaczekaj kilka minut na zastosowanie ustawienia wychodzącego i najpierw wyślij wiadomość od nadawcy pilotażowego na zewnętrzny adres testowy.

Dopasowanie SPF i DKIM do rzeczywistej ścieżki wysyłania

Rekord SPF musi obejmować każdą ścieżkę faktycznie wysyłającą autoryzowaną pocztę, ale nie powinien zachowywać nieużywanych ścieżek. Podczas kontrolowanego przejścia można autoryzować jednocześnie Google Workspace i Sophos. Gdy cała poczta wychodząca przechodzi wyłącznie przez Sophos, usuń nieaktualną bezpośrednią ścieżkę Google tylko wtedy, gdy nie korzysta z niej żadna aplikacja, przekierowanie ani platforma zewnętrzna.

Regionalną wartość include SPF Sophos pobierz z Sophos Fusion; wartość przykładowa byłaby tu niebezpieczna. Przed zapisaniem potwierdź, że domena nadal ma dokładnie jeden rekord TXT SPF i że wybrana strategia -all lub ~all odpowiada migracji. Pozostaw aktywne podpisy DKIM, a osobno pozostaw aktywny DMARC; sprawdź oba mechanizmy po zmianie na wiadomości odebranej zewnętrznie.

Walidacja pilota, a następnie zmiana produkcyjnego MX

Przed przełączeniem produkcyjnego MX użyj zakresu pilotażowego lub okna testowego, aby zweryfikować dostarczanie wychodzące przez Sophos oraz wiadomość wewnętrzną, która pozostaje w Google. Potwierdź oczekiwane nagłówki, śledzenie Google i Sophos Message History oraz sprawdź, czy przygotowany rekord SPF obejmuje rzeczywistą ścieżkę wysyłania pilota.

Dopiero gdy miejsce docelowe, odbiorcy, Inbound Gateway, trasa wewnętrzna, brama wychodząca, przygotowanie SPF i testy pilotażowe działają, zastąp produkcyjny zestaw MX domeny głównej wartościami i priorytetami pokazanymi w Sophos Fusion dla regionu. Podczas propagacji DNS zachowaj dokumentację poprzedniego stanu, właściciela i decyzji o wycofaniu. W razie awarii przywróć zapisany zestaw MX zamiast dodawać kolejne niesprawdzone trasy.

Weryfikacja obu kierunków

Po każdej zmianie zaczekaj na propagację i wykonaj cztery ukierunkowane testy:

zewnętrzny → chroniony odbiorca wewnętrzny;
użytkownik wewnętrzny → odbiorca zewnętrzny;
użytkownik wewnętrzny → użytkownik wewnętrzny w tej samej domenie;
próba bezpośredniego dostarczenia z pominięciem Sophos, jeśli jest autoryzowana i bezpieczna.

Dla testów 1 i 2 w Sophos Fusion w Reports > Message History musi pojawić się dokładnie jeden pasujący wpis z prawidłowym kierunkiem, nadawcą, odbiorcą, czasem i wynikiem. Równolegle sprawdź śledzenie Google i pełne nagłówki dostarczonej wiadomości. Łańcuch Received musi przedstawiać oczekiwaną ścieżkę we właściwej kolejności; sprawdź SPF, DKIM i DMARC w miejscu zewnętrznym.

Test 3 nie może niepotrzebnie przejść przez Sophos dwukrotnie. Test 4 musi zostać odrzucony po włączeniu ścisłego ograniczenia Inbound Gateway. Wiele wpisów Sophos dla tego samego Message-ID, powtarzające się hosty w łańcuchu Received lub znacznie rosnący czas dostawy wskazują na podwójne przetwarzanie albo pętlę.

Systematyczne rozwiązywanie problemów

Brakuje zewnętrznej poczty przychodzącej: najpierw sprawdź produkcyjny MX i region, potem Sophos Message History. Bez wpisu problem występuje przed Sophos. Jeśli wpis jest, lecz brak dostawy do Google, sprawdź routing-mx.example.com, miejsca Google, odbiorców, ograniczenie Delivery IP i TLS.
Poczta wychodząca nie pojawia się w Sophos: sprawdź zakres i warunki dopasowania reguł Google oraz wpisany Outbound Relay Host. Jeśli pojawia się w Sophos, ale nie u odbiorcy, zbadaj status dostawy, SPF/DKIM/DMARC i błąd systemu docelowego.
Poczta wewnętrzna pojawia się dwukrotnie w Sophos: potwierdź, że Internal - Sending obejmuje tylko własną domenę i żadna reguła ogólna nie obejmuje tych samych wiadomości. Usuń nakładające się reguły wychodzące lub catch-all zamiast dodawać kolejne obejście.
Błąd TLS: porównaj host źródłowy i docelowy, nazwę certyfikatu, zaufanie CA i wymaganą po obu stronach opcję TLS. Nie wyłączaj wymagania na stałe; złagodź je do testu tylko po udokumentowanej decyzji o ryzyku, a potem przywróć.
Poczta krąży między Google i Sophos: zatrzymaj zmianę. Porównaj główny MX, routing-mx.example.com, trasę wychodzącą Google i przeskoki nagłówków. Miejscem docelowym Sophos musi być Google, nie Sophos; reguła wychodząca Google nie może ponownie przejmować poczty dostarczonej przez Sophos.
Nie działają tylko pojedynczy odbiorcy: sprawdź istnienie i identyczną pisownię odbiorcy w Sophos Email i Google Workspace, w tym rozpoznawanie aliasów i grup. Nie obchodź błędów domeny lub odbiorcy szerokim zezwoleniem relay.

Jeśli DNS, zakres tras, hosty, dopasowanie domeny, TLS i odbiorcy są prawidłowe, ale udokumentowany błąd nadal da się odtworzyć, przekaż Sophos Support Message-ID, znacznik czasu, nadawcę, odbiorcę, odpowiednie nagłówki oraz wpisy z Sophos Message History i śledzenia Google. Pozwoli to zbadać konkretny etap bez zmieniania kolejnych reguł produkcyjnych na chybił trafił.