Eu tenho um servidor postfix funcionando atrás de um firewall configurado com lista cinza, DKIM, SFP, amavis e clamav e MX corretamente configurado, registro “A” e entrada DNS reversa. Posso enviar e receber e-mails para outros domínios na internet. O postfix está usando certificados do LetsEncrypt para o domínio. O servidor de e-mail está localizado em uma sub-rede privada, digamos 192.168.10.0/24, atrás do firewall. E para que isso funcione estou fazendo encaminhamento de porta para as seguintes portas 25.587, 465, 993, bem como 80 e 443 para o certbot. Eu configurei também um nat outband estático manual para resolver apenas para o endereço IP público reservado para o servidor de e-mail. Até aí tudo bem, tudo funciona.
O problema que tenho é que esse servidor de e-mail está localizado em uma rede 192.168.10.0/24 e o envio de e-mail não funciona para clientes localizados atrás do firewall em outra sub-rede local (192.168.20.10/24) para portas TLS, ou seja, 465 e 587, as 25 obras!!!. Se os clientes vierem de fora tudo funciona bem. Agora, toda vez que esses clientes internos tentam acessar o servidor de e-mail, eles passam pelo firewall, que neste caso também é um roteador. Esses clientes tentam resolver o servidor de e-mail, digamos mail.mySimpleMailProject.com, e veem que o certificado é inválido, pois está mapeado para o IP errado, ou seja, 192.168.10.5 e não para o IP público.
No entanto, consigo enviar e-mails desses clientes internos usando apenas a porta 25 e isso funciona. Mas meu objetivo é enviar o e-mail através de um canal seguro também na rede interna.
Eu li sobre uma possível solução, ou seja
Configurar reflexão Nat
Agora eu realmente NÃO quero fazer reflexão NAT, NAT é mau e estou tentando evitá-lo a todo custo.
Estou pensando no seguinte: existe uma maneira de dizer ao postfix para
1) aceitar conexão da rede local
para esse propósito, tenho a entrada permit_mynetworks em smtpd_recipient_restrictions, ou seja
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) quando uma conexão vem da rede interna 192.168.20.0/24 para representar outro certificado autoassinado que posso posteriormente importar nesses clientes e deixá-los felizes.
Talvez haja alguma outra solução melhor para este problema. Qualquer dica é muito apreciada.
Responder1
Solução 1
Você pode ter um DNS interno, que resolve, internamente, o mail.mySimpleMailProject.com para o endereço interno.
Solução 2
Certifique-se de que o encaminhamento de porta de redes internas para o IP público resolvido em mail.mySimpleMailProject.com seja DNAT (encaminhamento de porta).