Problemes amb servidor edge (perimetral) de Exchange
Els pitjors problemes als que ens enfrontem amb el servidor edge (perimetral) d’Exchange és el fet de no enviar els correus electrònics cap als servidors de la xarxa interna, cap a Internet o en ambdós sentits. Tot està funcionant correctament, aparentment tot està configurat correctament, però els correus NO surten, no s’entreguen, simplement es col·loquen a les diferents cues de treball amb diferents errors:
- 451 4.4.0 DNS Query Failed
La majoria acostumen a ser de resolució de DNS. On és l’errada? Com s’arregla aquest batibull?
Partint de la instal·lació de Microsoft Exchange 2016 amb el servidor edge (perimetral), mirem què s’ha de modificar perquè tot això funcioni correctament.
Connexions de xarxa del servidor Edge (perimetral) d’Exchange
Tot i què és obvi, el primer que s’ha de comprovar són les comunicacions dels servidors. Es depen de molts elements per obviar-ho: encaminadors, tallafocs, DNS… Les preguntes que s’han de contestar:
- El servidor edge (perimetral) es pot comunicar amb Internet? Un simple ping a una adreça pública (IP o FQDN) per sortir de dubtes.
- Pot resoldre una adreça d’Internet? Si l’anterior prova ha estat a una adreça IP, també ha de poder resoldre una adreça FQDN, per exemple www.google.com.
- Pot establir una sessió SMTP amb un servidor extern? Trobar un servidor SMTP al què poder fer un telnet pel port 25.
Esvaïts els dubtes de comunicació amb l’exterior, és el torn de comprovar les comunicacions internes.
El servidor edge (perimetral) d’Exchange requereix de comunicar-se amb servidors de la xarxa interna per entregar el correu electrònic. Comprovar que està permès el trànsit amb aquests protocols:
Protocol | Port | Connexió amb |
---|---|---|
SMTP | TCP 25 | Servidors de correu electrònic interns |
DNS | TCP 53
UDP 53 |
Servidors de DNS interns |
Per part dels servidors de correu, de la xarxa interna, que s’han de comunicar amb el servidor edge (perimetral) comprovar que es comuniquen amb aquests protocols:
Protocol | Port | Connexió amb |
---|---|---|
LDAP segur | TCP 50636 | Servidor edge (perimetral) des dels servidors de correu intern. |
SMTP | TCP 25 | Servidor edge (perimetral) des dels servidors de correu intern. |
Per la prova del LDAP segur, n’hi ha prou en forçar la sincronització de la subscripció perimetral des d’un dels servidors interns. Recordeu, des de la PowerShell d’Exchange, executar la comanda:
start-edgesynchronization -ForceFullSync
Comprovar els encaminaments des de la xarxa interna és útil tenir habilitada la resposta de PING, tant en els tallafocs del perímetre com en els dels propis equips. Ei, només per fer les comprovacions, després en producció millor deixar la regla desactivada del tallafocs.
Comprovar la resolució de DNS interna des del servidor edge (perimetral) funciona correctament. Assegurar que a les propietats de la targeta de xarxa hi ha configurats els DNS dels servidors INTERNS, no de servidors públics!.
Botó dret damunt del botó, Inici, clicar a tauler de control. Clicar a Centre de xarxes i recursos compartits i clicar de nou a la connexió de xarxa.
Clicar el botó Propietats.
Seleccionar Protocol de Internet versió 4 (TCP/IPv4) i clicar el botó Propietats.
Assegurar que els servidors DNS preferit i alternatiu corresponen als servidors DNS interns de l’organització.
No està de més clicar el botó Opcions avançades.
A la pestanya de DNS, assegurar el sufix DNS per la connexió amb el nom del domini intern on resideixen els servidors de correu electrònic intern i desmarcar el piscu de Registrar en el DNS les adreces d’aquesta connexió.
Si tot es correcte, passem a la pràctica. Des de la consola de sistema, executar:
nslookup
Validar que respon correctament el primer DNS que tenim configurat a la targeta de xarxa, retornant el seu nom. Si escrivim el nom del servidor intern, també es retorna la seva IP corresponent.
En cas que no hi hagi accés al servei de DNS el sistema retornarà errors de temps d’espera esgotat (time out) sense poder resoldre el nom correctament amb el conseqüent error de DNS intern.
L’altre punt a tenir en compte és el DNS públic cap a Internet. La seva resolució no té perquè proporcionar-se des de la xarxa interna i, en molts casos, és el principal motiu dels errors. Comprovar que des de l’equip es pot arribar i resoldre amb un DNS públic, perquè és el què configurarem en el servidor edge (perimetral), per resoldre les adreces de correu electrònic a enviar cap a l’exterior. Fem la prova amb el DNS de Google, per exemple:
nslookup server 8.8.8.8 set type=mx google.com
Si tot és correcte, s’obté el llistat de servidors on entregar els correus electrònics de Google.
Comprovar la connectivitat entre els servidors interns i el servidor edge (perimetral) es comuniquen pel port 25 i al inrevés. Es pot fer amb un simple PUTTY contra el port 25 en mode RAW. Ens contesta el propi servidor de correu electrònic o només manté la connexió si està emmascarada la contesta.
Configuració dels DNS externs en el servei de transport de correu electrònic
No està de més configurar els DNS específics per les comunicacions externes en el servei de transport de correu electrònic. Per fer-ho, iniciar la PowerShell de Exchange en el servidor edge (perimetral). Des del menú Inici, clicar a PowerShell de Exchange Management Shell.
Per obtenir un llistat detallat de la configuració del servei de transport, executar la comanda:
Get-TransportService | fl
Per ser més concret al què ens interessa, els paràmetres de DNS dels connectors, es pot concretar amb:
Get-TransportService | fl *dns*
Posar especial atenció sobre el connector External. S’hi han d’indicar, pel servidor corresponent (en l’exemple srvEDGE) els servidors DNS públics, separats per una coma, a utilitzar (ExternalDNSServers) amb la comanda:
Set-TransportService srvEdge -ExternalDNSServers 8.8.8.8,8.8.4.4
Comprovar la configuració del servei de transport, es poden veure assignats els servidors DNS públics anteriors al connector extern.
Get-TransportService | fl *dns*
Per saber què està passant quan tenim problemes és força útil en el servidor de transport (en l’exemple srvedge), habilitar el LOG en el transport (ConnectivityLogEnabled) deixant el registre a la carpeta c:\SMTP Logs, amb la comanda:
Set-TransportService srvedge -ConnectivityLogEnabled $true -ConnectivityLogPath "C:\SMTP Logs"
Agents de transport
S’ha d’anar en compte amb ells, sobretot si s’han instal·lat agents addicionals de tercers al servidor de correu com pot ser el filtre de spam, phishing, exclaimers, etc… En el supòsit que un dels agents es quedi penjat, només ell, no tot el transport, es molt probable que no es pugui veure res anormal que doni alguna pista del què passa; però tampoc entrarà ni sortirà cap correu del sistema. Entra la fase de prova-error. Aquest apartat també és vàlid pels servidors de la xarxa interna.
Per comprovar els agents de transport, des de la PowerShell de Exchange, executar:
Get-TransportAgent
S’obté el llistat dels agents instal·lats amb el seu estat.
En cas de dubte d’un dels agents es pot desactivar per comprovar el funcionament general del sistema. Per exemple, per desactivar l’agent de comprovació del Sender ID, des de la PowerShell de Exchange, executar:
Disable-TransportAgent -Identity “Sender Id Agent”
Tornant a comprovar el llistat dels agents instal·lats, s’observa que el Sender Id ha quedat desactivat.
Reiniciar el servei de transport per assegurar els canvis:
Get-Service MSExchangeTransport | Restart-Service
Per tornar a habilitar un agent de transport deshabilitat:
Enable-TransportAgent -Identity “Sender Id Agent”
I tornem a reiniciar el servei amb la instrucció que s’ha utilitzat anteriorment.
Certificats del servidor Edge (perimetral)
Aquests no tenen secret (o sí). S’han canviat els certificats dels servidors interns? Han caducat els interns? I l’extern, és el correcte pel protocol SMTP?
Pels certificats caducats cal renovar-los, com no, tant dels servidors interns com del servidor perimetral.
Un cop renovats cal tornar a crear la subscripció perimetral i tot tornarà a la normalitat. Reviseu l’entrada de instal·lació del servidor edge (perimetral). Com a recordatori ràpid:
En el servidor edge (perimetral):
new-edgesubscription -FileName C:\Subscription.xml
En el servidor intern de correu:
New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "E:\Subscripcio.xml" -encoding Byte -ReadCount 0)) -Site Default-First-Site-Name
Comprovació de l’estat de la subscripció:
start-edgesynchronization -ForceFullSync
A mesura que vagi trobant noves cosetes aniré ampliant la informació d’aquest apartat, més que res, perquè sempre en surten de noves en el nostre dia a dia i que ara potser se’m passen.
T’ha agradat l’article? El pots compartir a les xarxes socials. També pots deixar la teva opinió, comentari o suggeriment. Gràcies!
Similar Posts by The Author:
- Microsoft SQL Server con SMB3
- Microsoft SQL Server amb SMB3
- Containers en Linux
- Containers amb Linux
- Migrar el servidor de archivos a Windows Server 2019
- Migrar el servidor de fitxers a Windows Server 2019
- Puerta enlace a Azure en el Windows Admin Center
- Porta enllaç a Azure en el Windows Admin Center
- Hola mundo! WordPress 5 y Gutenberg
- Hola món! WordPress 5 i Gutenberg