☰

Проверка сертификата Postifx TLS от клиентов в локальной подсети за брандмауэром

tag-icon • tag-icon ssl postfix certificate
Проверка сертификата Postifx TLS от клиентов в локальной подсети за брандмауэром

У меня есть рабочий сервер postfix за брандмауэром, настроенный с серыми списками, DKIM, SFP, amavis и clamav и правильно настроенные MX, запись «A» и обратная запись DNS. Я могу отправлять и получать почту на другие домены в Интернете. Postfix использует сертификаты от LetsEncrypt для домена. Почтовый сервер находится в частной подсети, скажем, 192.168.10.0/24 за брандмауэром. И для того, чтобы это работало, я делаю переадресацию портов для следующих портов 25,587, 465, 993, а также 80 и 443 для certbot. Я также настроил вручную статический внешний nat для разрешения только публичного IP-адреса, который зарезервирован для почтового сервера. Пока все хорошо, все работает.

Проблема в том, что почтовый сервер находится в сети 192.168.10.0/24, и отправка почты не работает для клиентов, находящихся за брандмауэром в другой локальной подсети (192.168.20.10/24) для портов TLS, то есть 465 и 587, 25 работает!!!. Если клиенты приходят извне, все работает хорошо. Теперь каждый раз, когда эти внутренние клиенты пытаются добраться до почтового сервера, они проходят через брандмауэр, который в этом случае также является маршрутизатором. Эти клиенты пытаются разрешить почтовый сервер, скажем, mail.mySimpleMailProject.com, и видят, что сертификат недействителен, так как он сопоставляется с неправильным IP, то есть 192.168.10.5, а не с публичным IP.

Однако я могу отправлять почту с этих внутренних клиентов только через порт 25, и это работает. Но моя цель — отправлять почту через безопасный канал также и во внутренней сети.

Я прочитал о возможном решении, т.е.

Настроить Nat Reflection

Теперь я действительно НЕ хочу заниматься рефлексией NAT, NAT — это зло, и я пытаюсь избежать его любой ценой.

Я думаю о следующем: есть ли способ сказать postfix

1) принять соединение из локальной сети

для этой цели у меня есть запись permit_mynetworks в smtpd_recipient_restrictions, т.е.

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) когда соединение, которое исходит из внутренней сети 192.168.20.0/24, представляет собой другой самоподписанный сертификат, который я позже могу импортировать в этих клиентов и сделать их счастливыми.

Может быть, есть какое-то другое, лучшее решение этой проблемы. Любые подсказки будут высоко оценены.

решение1

Решение 1
У вас может быть внутренний DNS, который преобразует mail.mySimpleMailProject.com во внутренний адрес.

Решение 2
Убедитесь, что переадресация портов из внутренних сетей на публичный IP-адрес, разрешенный с mail.mySimpleMailProject.com, выполняется с помощью DNAT (переадресация портов).

Связанный контент