Hybrid e-postflyt: ruting mellom Exchange Online og lokalt miljø

Hybrid e-postflyt er SMTP-veien mellom en lokal Exchange-organisasjon og Exchange Online. Den sørger for at postbokser på begge sider kan bruke samme SMTP-domene, samtidig som meldinger kommer til riktig sted. Hybrid Configuration Wizard konfigurerer connectorer og TLS-parametere for dette (Transport routing in Exchange hybrid deployments, Hybrid Configuration Wizard).

E-postflyt er bare én del av Exchange Hybrid. Katalogsynkronisering, ledig/opptatt, OAuth og postboksflyttinger bruker andre veier. Denne artikkelen holder seg derfor bevisst til ett enkelt spørsmål: Hvilke SMTP-hopp går en konkret melding gjennom, og hvilken beslutning tas ved hvert hopp?

Protokollstakken er oversiktlig: DNS angir de offentlig tilgjengelige målene, SMTP over TCP 25 transporterer meldingen, TLS beskytter og identifiserer forbindelsen, og Exchange-connectorer fastsetter hvilken motpart som brukes for hvert domene. Mottakerobjekter leverer rutingsadressen; Message Trace og lokale sporingslogger viser deretter hva hver organisasjon gjorde med meldingen (Transport routing in Exchange hybrid deployments, Hybrid deployment prerequisites).

Grunnmodellen: to Exchange-organisasjoner, ett adresserom

Et hybridmiljø har minst to transportorganisasjoner. Den lokale Exchange-organisasjonen kjenner lokale postbokser og eksterne postboksobjekter. Exchange Online kjenner skypostbokser og synkroniserte representasjoner av lokale mottakere. Begge sider kan bruke samme primære domene som example.com (Exchange hybrid deployments).

For at en melding ikke skal ende på feil sted, trenger hver side en indikasjon på mottakerens faktiske plassering. For en skypostboks inneholder det lokale Remote Mailbox-objektet en ekstern rutingsadresse i sameksistensdomenet, vanligvis tenant.mail.onmicrosoft.com. Omvendt kjenner Exchange Online synkroniserte lokale mottakere som e-postaktiverte objekter (Enable-RemoteMailbox).

Den normale prosessen er dermed enkel:

1. Den første Exchange-organisasjonen mottar meldingen.
2. Den slår opp mottakeren i katalogen sin.
3. Mottakerobjektet viser om postboksen er lokal eller ligger på den andre siden.
4. Den riktige hybridconnectoren sender via SMTP/TLS til den andre organisasjonen.
5. Der slås mottakeren opp på nytt, og meldingen leveres.

Eksperter kontrollerer i tillegg om transportregler endrer ruten, om en gateway er satt inn, og hvilken domene- eller connectorprioritet som forklarer valgt neste hopp.

Standardruten uten sentralisert internetttransport

I den vanlige desentraliserte modellen sender hver side sin egen internett-e-post. En lokal postboks bruker den lokale Exchange-transportorganisasjonen for utgående internett-e-post. En skypostboks sender via Exchange Online Protection. Bare meldinger mellom lokale postbokser og skypostbokser går gjennom hybridconnectorene (Transport routing in Exchange hybrid deployments).

Innkommende internett-e-post følger den publiserte MX-posten. Hvis MX-posten peker til Exchange Online, mottar EOP meldingen først. For en skypostboks leverer Exchange Online lokalt; for en synkronisert lokal mottaker bruker den Hybrid Outbound Connector. Hvis MX-posten derimot peker til det lokale miljøet eller en foranstilt gateway, tas den første mottakerbeslutningen der.

Denne modellen holder internettveiene korte, men fører til flere mulige egress-IP-er og filtreringssteder. SPF, DKIM, DMARC, tillatlisting og partnerregler må ta hensyn til begge utgående veier. Dette er ikke en feil ved hybridmodellen, men en konsekvens av distribuert levering.

Sett Centralized Mail Transport i riktig sammenheng

Centralized Mail Transport, CMT, endrer nettopp denne utgående veien. Meldinger fra Exchange Online-postbokser til internett sendes først til den lokale Exchange-organisasjonen. Først der forlater de organisasjonen. Den lokale siden kan dermed fortsatt bruke sentrale transportregler, løsninger eller faste egress-IP-er (Transport routing in Exchange hybrid deployments).

Fordelen er felles kontroll med utgående trafikk. Prisen er ekstra hopp og avhengigheter. Hvis lokal transport eller internettforbindelsen svikter, påvirker det nå også utgående sky-e-post. Ventetid, plassering av køen, egress-IP og stedet for siste filtrering endres.

For avanserte administratorer er beslutningen derfor ikke «CMT på eller av», men: Hvilken konkret policy krever det lokale hoppet, hvilken kapasitet må det håndtere, og hvordan rutes det ved feil? Eksperter dokumenterer i tillegg løkkebeskyttelse, TLS-krav, connectorprioritet og beviset på at hver tiltenkte melding faktisk tar den sentrale veien.

Dermed er temaet CMT avsluttet. Autentisering av Outlook-klienter eller Hybrid Modern Authentication hører ikke hjemme her, fordi det ikke velger et SMTP-hopp.

Hvordan connectorer gjenkjenner motparten

Når ruten er valgt, må hver side kunne stole på motparten. Hybrid Configuration Wizard oppretter lokale Send-/Receive-connectorer og passende Inbound-/Outbound-connectorer i Exchange Online. Transporten går via SMTP på TCP 25 og bruker TLS (Hybrid deployment prerequisites, Hybrid mail flow).

Den lokale Send Connector fastsetter mål og TLS-krav for sameksistensdomenet. Cloud Outbound Connector beskriver den lokale organisasjonen som mål. I motsatt retning aksepterer Receive- eller Inbound Connector trafikken basert på dokumenterte betingelser, blant annet sertifikatidentitet og opprinnelse.

Sertifikatet har her en konkret oppgave: Det identifiserer SMTP-endepunktet i TLS-håndtrykket. Subject eller Subject Alternative Name, connectorparametere, presentert sertifikatkjede og faktisk vertsnavn må samsvare. Et gyldig sertifikat i sertifikatlageret er ikke tilstrekkelig dersom transporttjenesten presenterer et annet.

Eksperter kontrollerer derfor begge retninger hver for seg. Retning A kan fungere, mens retning B mislykkes på grunn av en annen connector, et annet DNS-mål eller sertifikatnavn.

Mottakerruting og delte domener

En fungerende connector sier ennå ikke hvilke meldinger som bruker den. Denne beslutningen begynner med mottakerobjektet. En lokal Remote Mailbox peker til skyen. Et synkronisert lokalt postboksobjekt i Exchange Online peker tilbake til den lokale organisasjonen.

Accepted Domains fastsetter i tillegg om en organisasjon er ansvarlig for alle mottakere i et domene, eller kan videresende ukjente mottakere. I delte domener er en Internal Relay-konfigurasjon bare sikker når neste hopp kjenner eller avviser ukjente mottakere korrekt (Accepted domains in Exchange Online, Accepted domains in Exchange Server).

Et utdatert Remote Mailbox-objekt kan derfor føre til feilruting til tross for sunn TLS. Omvendt hjelper ikke en korrekt Target Address dersom cloudconnectoren er deaktivert. Diagnosen knytter objekt og transport sammen, i stedet for å se på bare én side.

For eksperter blir videresendinger, e-postkontakter, distribusjonsgruppeutvidelse og transportregler viktige. De kan endre den opprinnelige mottakeradressen eller opprette flere mottakere. Hver resulterende melding får sin egen rutingsbeslutning.

E-postgatewayer foran eller bak Exchange Online

Mange organisasjoner utvider hybrid med en Secure Email Gateway eller en skybasert filtreringsplattform. Dette legger til minst ett SMTP-hopp. Veien må tegnes separat for innkommende og utgående meldinger (Manage mail flow using a third-party cloud service).

Hvis gatewayen står foran Exchange Online, peker MX-posten til gatewayen. EOP ser da først kilde-IP-en dens. Enhanced Filtering for Connectors kan inkludere den opprinnelige avsenderinformasjonen i Microsofts filtervurdering når connector og hoppede over IP-er er riktig konfigurert (Enhanced Filtering for Connectors).

For utgående e-post må det være fastsatt om Exchange Online sender direkte, via gatewayen eller ved CMT først lokalt og deretter via gatewayen. Flere tillatte veier kan omgå policyer og skape ulike DKIM-signaturer, egress-IP-er og logger.

Ekspertkontrollen er en graf over tillatte veier: Hver pil angir initiativtaker, mål, port, TLS-kontroll, tillatte domener, filtreringsoppgave, køeier og loggkilde. Et gatewaynavn uten disse opplysningene er ennå ikke en arkitektur.

Spor en melding ende til ende

Feilsøkingen begynner med en testmelding med kjent avsender, mottaker og tidspunkt. Først kontrolleres den offentlige veien, deretter hendelsene på hver involverte Exchange-side.

Resolve-DnsName -Type MX example.com
Test-NetConnection mail.example.com -Port 25

dig MX example.com
nc -vz mail.example.com 25

Resolve-DnsName og dig viser det publiserte MX-målet. Test-NetConnection og nc kontrollerer om TCP 25 er tilgjengelig fra målepunktet. Det beviser ennå ikke at TLS- eller connectorkontrollen lykkes.

Deretter følger SMTP-håndtrykket. OpenSSL kan brukes på begge administratorplattformene.

openssl s_client -starttls smtp -connect mail.example.com:25 `
  -servername mail.example.com -showcerts

openssl s_client -starttls smtp -connect mail.example.com:25 \
  -servername mail.example.com -showcerts

openssl s_client viser sertifikatkjede, navn og TLS-forhandling. For en fullstendig autorisert testdialog egner swaks seg. Produksjonsmeldinger testes ikke med fritt oppdiktede avsendere; testidentitet og forventet rute fastsettes på forhånd.

I Exchange Online leverer Get-MessageTraceV2 skyhendelsene. Lokalt viser Get-MessageTrackingLog behandlingen på Exchange-servere, og Get-Queue viser ventende neste hopp. Tidsstempler bringes til en felles tidssone; Internet Message ID og Network Message ID hjelper med å koble sammen delene (Message Trace FAQ, Message tracking).

Typiske feilbilder uten temahopp

En TLS-feil behandles først som et transportproblem: Hvilken vert ble koblet til, hvilket sertifikat presenterte den, og hvilken connectorbetingelse forventet motparten? Mottakersynkronisering er først relevant når meldingen rutes feil etter vellykket mottak.

En NDR for ukjent mottaker leder derimot først til mottakerobjektet og typen Accepted Domain. Først når objektet er korrekt, kontrolleres det om valgt rute transporterer det til riktig side.

En ventende kø krever neste hopp, tidspunkt for nytt forsøk og LastError. Den åpne porten til målverten er bare neste test. En sløyfe vises i gjentatte Received-headere, hopp eller sporingshendelser og oppstår som regel når begge sider videresender ukjente mottakere til hverandre (RFC 5321: Trace information and loop detection).

En forbindelse som bare fungerer i én retning er ingen selvmotsigelse. Motretningene bruker ulike avsendere, connectorer og sertifikatkontroller. De registreres og testes separat.

Sikkerhet, drift og endringer

Hybrid-SMTP åpner en bevisst tillatt transportvei. Denne veien bør begrenses til dokumenterte kilde- og målsystemer, sertifikater og domener. Åpne reléer, for brede IP-områder eller connectorer som klassifiserer enhver melding som pålitelig, strider mot denne modellen.

Sertifikatbytter planlegges som rutingsendringer. Før utløp kontrolleres nytt sertifikat, tjenestetilordning, presentert kjede og connectorforventning på begge sider. Deretter følger testmeldinger i begge retninger og en kontrollert tilbakeføringsplan.

For løpende drift overvåkes minst hybridconnectorer, sertifikatutløp, vekst i køer, Message Trace-feil, DNS-mål og gatewaytilstand. Ved Centralized Mail Transport kommer kapasiteten til den lokale utgående veien i tillegg.

Sikkerhetskopi og gjenoppbygging av e-postveien

SMTP-meldinger ligger under en driftsforstyrrelse i køer på systemene som til enhver tid er ansvarlige. En konfigurasjonssikkerhetskopi gjenoppretter ikke disse ventende meldingene. Derfor vurderes konfigurasjon og transporttilstand separat.

Gjenoppbyggingen omfatter connectorparametere på begge sider, Accepted og Remote Domains, transportregler, offentlige DNS-oppføringer, sertifikater med private nøkler, gatewaykonfigurasjon og HCW-valg. Hemmeligheter lagres beskyttet; lesbare eksporter dokumenterer struktur og avhengigheter.

Etter gjenoppbygging testes ikke bare en port. En merket melding går gjennom den forventede veien i hver retning. Message Trace, lokale sporingslogger, gatewaylogger og målpostboksen bekrefter hvert hopp. Først denne ende-til-ende-godkjenningen viser at ruting og filtrering igjen er korrekt.

Teknisk utvikling og avveininger

Hybrid Configuration Wizard automatiserte forbindelsen til Exchange Online gjennom flere Exchange-generasjoner. Transporten forble SMTP/TLS, mens cloudconnectorer, støttede sertifikater og rutingsalternativer ble videreutviklet (Hybrid Configuration Wizard).

Direkte internetttransport holder veiene korte og bruker den aktuelle plattformen der postboksen befinner seg. Centralized Mail Transport samler kontrollen, men gjør sky-e-post avhengig av den lokale utgående veien. En tredjepartsgateway tilfører spesialisert filtrering eller kryptering, men øker antallet hopp og loggkilder. Riktig valg følger av et dokumenterbart krav, ikke av ønsket om at alt i diagrammet skal gå gjennom samme boks.

Kilder

• Microsoft Learn – Transport routing in Exchange hybrid deployments
• Microsoft Learn – Exchange hybrid deployments
• Microsoft Learn – Hybrid Configuration Wizard
• Microsoft Learn – Hybrid deployment prerequisites
• Microsoft Learn – Hybrid mail flow
• Microsoft Learn – Enable-RemoteMailbox
• Microsoft Learn – Set up connectors to route mail
• Microsoft Learn – Connectors on Exchange servers
• Microsoft Learn – Accepted domains in Exchange Online
• Microsoft Learn – Accepted domains in Exchange Server
• Microsoft Learn – Manage mail flow using a third-party cloud service
• Microsoft Learn – Enhanced Filtering for Connectors
• Microsoft Learn – Trace an email message
• Microsoft Learn – Message Trace FAQ
• Microsoft Learn – Message tracking
• Microsoft Learn – Queues in Exchange Server
• Microsoft Learn – Get-MessageTraceV2
• Microsoft Learn – Get-MessageTrackingLog
• Microsoft Learn – Get-Queue
• Microsoft Learn – Resolve-DnsName
• BIND 9 – dig manual
• Microsoft Learn – Test-NetConnection
• OpenBSD – nc(1)
• OpenSSL – s_client
• Swaks – SMTP test tool
• RFC 5321 – Trace information and loop detection