несколько MX, указывающих на один и тот же сервер
Мне нужна помощь в настройке почтового сервера. Я хотел бы знать, возможно ли иметь несколько MX с разными IP-адресами паба, указывающих на один и тот же локальный сервер. это связано с тем, что в моей среде существует 2 шлюза (несколько поставщиков услуг), сторожевое устройство t30 (локальное 10.0.0.254), которое управляет 12.12.12.5, и сторожевое устройство t35 (локальное 10.0.0.253), которое управляет 12.12.12.6, для целей аварийного переключения. они используют один и тот же маршрутизатор isp, имеет зону 12.12.12.0/28.[1223 sizeswatchguard t35 - loc 10.0.0.254 - pub 12.12.12.5
watchguard t30 - loc 10.0.0.253 - pub 12.12.12.6
зона mycompany. com:
mycompany.com. MX 5 mail.mycompany.com
mycompany.com. MX 15 samemail.mycompany.com
mycompany.com. TXT "v=sfp1 a mx ip4:12.12.12.5 ip4:12.12.12.6 ~all"
mail.mycompany.com. A 12.12.12.5
samemail.mycompany.com A 12.12.12.6
зона 12.12.12.in-addr.apra:
5.12.12.12.in-addr.arpa. PTR mail.mycompany.com.
6.12.12.12.in-addr.arpa. PTR samemail.mycompany.com.
на firewall1: nat 12.12.12.5 - 10.0.0.1 общие почтовые порты
на firewall2: nat 12.12.12.6 - 10.0.0.1 общие почтовые порты
MAILSERVER nic config
ip: 10.0.0.1
subnet mask: 255.0.0.0
gw 10.0.0.254 metric 2
gw 10.0.0.253 metric 50
Таким образом, когда первый шлюз выходит из строя, все запросы начинаются (и уходят) с 10.0.0.253 (12.12.12.6) на общие порты (25..443 ..) вместо шлюза с метрикой 2.
или, может быть, я мог бы назначить другой сетевой адаптер почтовому серверу и изменить все правила на брандмауэрах, а затем работать с метриками ИНТЕРФЕЙСА, как в примере:
ПОЧТОВЫЙ СЕРВЕР NIC1
10.0.0.1
255.0.0.0
10.0.0.254
nic metric 2
NIC2
10.0.0.2
255.0.0.0
10.0.0.253
nic metric 50
Я хотел бы знать, есть ли противопоказания к использованию этого метода или есть ли альтернативы .. другая информация, почтовый сервер - Mdaemon. каждая помощь заметна!
править: Если я использую конфигурацию с двумя шлюзами и разными метриками, мой сервер всегда будет использовать тот, у которого самая низкая метрика 10.0.0.254 (12.12.12.5), пока он не найдет его в сети. Если я не установлю какой-то конкретный маршрут, сервер не сможет использовать вторичный 10.0.0.253 (12.12.12.6), даже порт 25, а другие общие порты не будут прослушивать. Я провел тест, я запустил непрерывный запрос на порт 25 12.12.12.5 и 12.12.12.6, в то время как этот тест я отключил брандмауэр 10.0.0.254 (12.12.12.5), поэтому сервер перестал слушать это, и начал слушать на вторичном брандмауэре в метрике. Существуют ли сценарии, при которых мой сервер может начать обмен данными, не используя 10.0.0.254, когда он находится в сети? test fw1 down
Привет, эта конфигурация не будет делать то, что вы предполагаете :-(. В основном записи DNS будут для домена (скорее всего, у вас это правильно, но у читателей есть он виден правильно) ...
зона mycompany.com:[12126 providedzone 12.12.12.in-addr.apra:
5.12.12.12.in-addr.arpa. PTR mail.mycompany.com.
6.12.12.12.in-addr.arpa. PTR samemail.mycompany.com.
С точки зрения DNS это правильно, но проблема может заключаться в маршрутизации на сервере Сторона. В зависимости от сетевых настроек, которые у вас есть, он не ведет себя внутренне как два независимых сетевых соединения на стороне сервера, но все время предпочтительнее использовать 10.0.0.254 / 12.12.12.5, даже если связь была начата с использованием 10.0 .0.253 / 12.12.12.6 (по любой причине). В некоторых случаях это может работать, но в других случаях не будет работать (например, в случае, если другая сторона использовала, например, Cisco ASA - в этот момент это не будет распознано как связанное общение и он будет завершен).
Чтобы он работал, было бы лучше использовать некоторые параметры HA на стороне шлюза и - например, Virtual IP, St и-by gateway, ... А на стороне dns использовать одну MX-запись. Поскольку он "заканчивается" на том же маршрутизаторе провайдера, это не будет проблемой. В этот момент почтовый сервер будет иметь только один интерфейс.
Если вы настаиваете на двух интерфейсах на почтовом сервере, это возможно, но вам нужно убедиться, что ответ будет отправляться через тот же шлюз, который будет использоваться для установил соединение. Самый простой способ - использовать sNAT на шлюзе / брандмауэре, но в случае почтового сервера это не лучшая идея, поскольку вы теряете отслеживание исходного IP-адреса (например, проверка спама на основе исходного IP-адреса), поэтому будет выбран другой (более сложный подход) .