Tengo un servidor Postfix en funcionamiento detrás de un firewall configurado con listas grises, DKIM, SFP, amavis y clamav y MX, registro "A" y entrada DNS inversa configurados correctamente. Puedo enviar y recibir correos a otros dominios en Internet. El postfix utiliza certificados de LetsEncrypt para el dominio. El servidor de correo está ubicado en una subred privada, digamos 192.168.10.0/24 detrás del firewall. Y para que eso funcione, estoy realizando el reenvío de puertos para los siguientes puertos 25,587, 465, 993, así como 80 y 443 para el certbot. También configuré una red nacional de banda externa estática manual para resolver solo en la dirección IP pública reservada para el servidor de correo. Hasta ahora todo bien, todo funciona.
El problema que tengo es que ese servidor de correo está ubicado en una red 192.168.10.0/24 y el envío de correo no funciona para clientes ubicados detrás del firewall en otra subred local (192.168.20.10/24) para los puertos TLS, es decir, 465 y 587. las 25 obras!!!. Si los clientes vienen de fuera todo funciona bien. Ahora, cada vez que esos clientes internos intentan llegar al servidor de correo, pasan por el firewall, que en este caso también es un enrutador. Esos clientes intentan resolver el servidor de correo, digamos mail.mySimpleMailProject.com y ven que el certificado no es válido porque está asignado a la IP incorrecta, es decir, 192.168.10.5 y no a la IP pública.
Sin embargo, puedo enviar correo desde esos clientes internos solo usando el puerto 25 y eso funciona. Pero mi objetivo es enviar el correo a través de un canal seguro también en la red interna.
He leído sobre una posible solución, es decir.
Configurar la reflexión natural
Ahora realmente NO quiero hacer una reflexión NAT, NAT es mala y estoy tratando de evitarla a toda costa.
Estoy pensando en lo siguiente: ¿hay alguna manera de decirle a postfix que
1) aceptar conexión desde la red local
para ello tengo la entrada permit_mynetworks en smtpd_recipient_restrictions, es decir
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_non_fqdn_helo_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_invalid_helo_hostname,
reject_unknown_helo_hostname,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_rbl_client zen.spamhaus.org,
check_policy_service unix:postgrey/socket,
permit
2) cuando una conexión que proviene de la red interna 192.168.20.0/24 representa otro certificado autofirmado que luego puedo importar en esos clientes y hacerlos felices.
Quizás haya alguna otra solución mejor a este problema. Cualquier sugerencia es muy apreciada.
Respuesta1
Solución 1
Puedes tener un DNS interno, es decir resuelve, internamente, el mail.mySimpleMailProject.com a la dirección interna.
Solución 2
Asegúrese de que el reenvío de puertos desde las redes internas hacia la IP pública resuelta desde mail.mySimpleMailProject.com esté editado por DNAT (reenvío de puerto).