06.09.2011

Популярный пакет Zimbra легко настраивается для работы с IPv6, мы запускали его под Ubuntu Server 10.4. Настройка IPv6 в самой ОС не вызывает трудностей. Поскольку почтой в Zimbra «заведует» Postfix, то его нужно немножко доконфигурировать, в файл main.cf добавляется следующее: (предположим, что у нас на интерфейсе задан адрес 2001:0db8::100:1

Данная настройка универсальна: она разрешает работу как и «автономного» Postfix-a, так и в составе Zimbra.

1. Разрешаем работу IPv6
inet_protocols all

2. На всякий случай прописываем
smtp_bind_address6 = 2001:0db8::100:1

3. Корректируем свои сети
Было
mynetworks = 192.168.0.0/24, 127.0.0.0/8
Стало
mynetworks = 192.168.0.0/24, 127.0.0.0/8, [2001:0db8::100:1]/64, [::1]/128

4. И перезапускаем Postfix
postfix restart

Или традиционным путем для Zimbra:
su zimbra
zmcontrol stop
zmcontrol start

С Postfix, работающим в составе Zimbra, можно поступить и так:
Отредактировать файл /opt/zimbra/conf/zmmta.cf : в конце секции SECTION mta DEPENDS amavis (перед строкой RESTART mta) добавляем
POSTCONF inet_protocols all
POSTCONF smtp_bind_address6 = 2001:0db8::100:1

а доверенные IPv6-сети можно отредактировать (добавить) из админского веб-интерфейса.

Вот так выглядит прием письма, отправленного от Zimbra (у получателя тоже Postfix с SpamAsassin, письмо отправлено из «доверенной» сети):

Sep  5 15:07:22 beta postfix/smtpd[20829]: connect from unknown[2001:0db8::100:1]
Sep  5 15:07:22 beta postfix/smtpd[20829]: 0565E1041C5: client=unknown[2001:0db8::100:1]
Sep  5 15:07:22 beta postfix/cleanup[3933]: 0565E1041C5: message-id=<a4f899db-4821-4875-988b-ca738e89d46b@ubuntu>
Sep  5 15:07:22 beta postfix/smtpd[20829]: disconnect from unknown[2001:0db8::100:1]
Sep  5 15:07:22 beta postfix/qmgr[683]: 0565E1041C5: from=<admin@ubuntu.domain1.ru>, size=1237, nrcpt=1 (queue active)
Sep  5 15:07:22 beta spamd[11040]: spamd: connection from localhost.domain1.ru [127.0.0.1] at port 40209
Sep  5 15:07:22 beta spamd[11040]: spamd: processing message <a4f899db-4821-4875-988b-ca738e89d46b@ubuntu> for _spamdaemon:506
Sep  5 15:07:27 beta spamd[11040]: spamd: clean message (2.3/8.0) for _spamdaemon:506 in 5.1 seconds, 1211 bytes.
Sep  5 15:07:27 beta spamd[11040]: spamd: result: . 2 - AWL,BAYES_00,FH_DATE_PAST_20XX,TVD_SPACE_RATIO scantime=5.1,size=1211,user=_spamdaemon,uid=506,required_score=8.0,rhost=localhost.domain2.ru,raddr=127.0.0.1,rport=40209,mid=<a4f899db-4821-4875-988b-ca738e89d46b@ubuntu>,bayes=0.000378,autolearn=no
Sep  5 15:07:27 beta postfix/pipe[30716]: 0565E1041C5: to=<op@domain2.ru>, relay=spamassassin, delay=5.7, delays=0/0/0/5.7, dsn=2.0.0, status=sent (delivered via spamassassin service)
Sep  5 15:07:27 beta postfix/qmgr[683]: 0565E1041C5: removed
Sep  5 15:07:27 beta postfix/pickup[31138]: B1E621041C9: uid=506 from=<admin@ubuntu.вщьфшт1.ru>
Sep  5 15:07:27 beta postfix/cleanup[350]: B1E621041C9: message-id=<a4f899db-4821-4875-988b-ca738e89d46b@ubuntu>
Sep  5 15:07:27 beta postfix/qmgr[683]: B1E621041C9: from=<admin@ubuntu.domain1.ru>, size=1572, nrcpt=1 (queue active)
Sep  5 15:07:27 beta postfix/smtp[1868]: B1E621041C9: to=<op@domain2.ru>, relay=mail.domain2.ru[192.168.100.10]:25, delay=0.08, delays=0.04/0/0.01/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as B4CE251C068)
Sep  5 15:07:27 beta postfix/qmgr[683]: B1E621041C9: removed

Как видно, внутренние процессы работают по IPv4, а почта получена по IPv6.
А вот часть заголовков полученного письма:

Received: from ubuntu.domain1.ru (unknown [IPv6:2001:0db8:100::1])
by beta.domain2.ru (Postfix) with ESMTP id 0565E1041C5
for <op@domain2.ru>; Mon,  5 Sep 2011 15:07:22 +0400 (MSD)

Дополнено 18.02.2014:

В Zimbra версии 7 и 8 конфигурационный файл Postfix редактировать не нужно (точнее — бесполезно), поскольку он создается автоматически и обновляется при перезапуске — то есть изменения, внесенные в него вручную, могут быть потеряны. Файл zmmta.cf в версиях 7 и 8 отсутствует, в этих версиях ему соответствует файл zmconfigd.cf. Вот его и нужно редактировать — точно так же, как описано выше для версии 6.

После редактирования нужно перезапустить сервис mta или всю Зимбру полностью, поскольку перезапуск mta фактически это и делает.

Вместо прямого редактирования можно ипользовать утилиту zmprov  и с ее помощью присвоить параметру zimbraIPMode значение both. Доверенные сети можно сконфигурировать из админской панели веб-интерфейса. Это требуется только для отправки почты с использованием почтовых клиентов, то есть веб-интерфейсу эта настройка не требуется.


  *** Via IPv4 ***  

06.09.2011: 6 комментариев

  1. александр
    а рсскажите, как вы решили проблемы выдачи сеток клиентам? если давать /64 на клиента, то как настраивать интерфейс, скажем, на cisco, и как сделать так, что бы клиенты не присваивали себе чужие префиксы.
      *** Via IPv4 ***  
    1. admin Автор записи
      Здравствуйте Александр. Мы пока только экспериментируем, и назначаем параметры статически. Делегирование префикса не пробовали по той причине, что никак не можем получить (хотя бы для тестов) клиентское оборудование, поддерживающее IPv6. Насчет присвоения чужих префиксов: как вы уже наверняка заметили, IPv6 сильно ориентирован на автоматическое назначение параметров, и DHCP в нем не особо и нужен. То есть у разработчиков, судя по всему, был сильный расчет на то, что у всех будут безлимитные тарифы, а проблемы безопасности (в том числе и требования нашего законодательства) будут решаться каким-то другим, непровайдерским путем. К примеру, в кафе или аэропорту, где есть бесплатный WiFi, никто ваших документов не спрашивает. И — остается только надеяться, что к моменту массового внедрения IPv6 уже станет ненужным «привязывать» трафик к клиенту. А так — наверное, можно применять унаследованные методы, типа accsss-list, arp access-list. То есть вопрос интересный…
        *** Via IPv4 ***  
      1. александр
        действительно хотелось бы полностью автоматизировать получение настроек клиентом, проблема только с dns, т.к сейчас NDP это не рализует, предпологается использовать DHCP. есть еще много интересных моментов, т.к занимаюсь внедрением ipv6 у isp, видимо, у вас схожая задача.
          *** Via IPv4 ***  
        1. admin Автор записи
          По поводу DNS: есть любопытный документ, RFC5006, где предлагается анонсирование адреса DNS-сервера через RA. Может, это пойдет в жизнь. Ведь получается, что если в каком-то сегменте «гуляют» RA, то DHCP нужен там только для узнавания адреса DNS-сервера. То есть нужность DHCP резко падает. Да, мы активно экспериментируем, пока есть время и возможности. зато потом будет легче, «в бою».
            *** Via IPv4 ***  
      2. александр
        а еще интересно, как решать проблему ограничения скорости клиентам, уже тестировали что-либо в этом направлении?
          *** Via IPv4 ***  
        1. admin Автор записи
          Самое простое — на порту свитча, сейчас многие свитчи умеют это делать. Поскольку это Level 2, то на версии IP никак не отражается. А строить «классический» QoS на IPv6 пока не пробовали.
            *** Via IPv4 ***  

Комментарии запрещены.