Серия «Инструкции по сетевому администрированию»

Автобэкапы сетевого оборудования Huawei

Ну или привет импортозамещение?

Сегодня в большей степени технический пост про автобэкапы Huawei (AR6120 и S5735). Но я буду разбавлять текст художественными вставками.

Почему не rancid? Все, мне кажется, задают этот вопрос в любом посте про автобэкапы. Во-первых, что-то я быстрым поиском не нашла там поддержку Huawei нужных моделей, во-вторых я хочу прям классический файл бэкапа, который можно раскатать (а rancid снимает вывод консоли, что не одно и то же), в-третьих я хочу гибкий инструмент, которым я смогу позже, например, раскатать всем правило в access-list или выполнить любую команду.
Ну и вообще, я хочу понимать как оно работает, а не использовать сторонний софт, но это уже мои загоны.

Итак, нужно логиниться на Huawei, желательно, по ssh ключу (чтоб не палить пароли в скриптах), выполнять сохранение конфигурации с определенным именем, потом заливать по tftp на сервер тоже с определенным именем, анализировать что слилось, а что нет, коммитить в git и отсылать отчет на почту.

Надо сказать, что энтерпрайзные huawei умеют, как циски, при сохранении конфигурации автоматом отсылать на ftp конфиг. Теоретически, младшие модели это тоже умеют, но практически это нихрена не работает во-первых, а во-вторых оно сливает только zip архив, что просто адски неудобно (про это будет подробнее ниже).

Единственное, что я пропущу - это настройка git. Я подняла gitea чудесно по родной инструкции, справится любой. Да и система контроля версий тут не строго обязательна в принципе.

Первое - логин на Huawei по ssh ключу. И сразу это ввергло меня в поиск. То есть, в документации такая фича есть, но ключ он принимает только в HEX виде и никакие популярные команды преобразования, которые на раз гуглятся, не привели ключ в тот вид, чтобы его сожрал Huawei.

Сначала генерируем ключ на сервере (у меня хуавей принял только 1024 бита, но поскольку ssh открыт только с белого списка адресов, я сочла это приемлемым. вы же можете поэкспериментировать с битностью). На вопрос о парольной фразе просто нажмите enter.

ssh-keygen -f ~/.ssh/id_rsa -t rsa -b 1024

А теперь делаем магию. Я нашла нужную команду в самом конце комментов под заплюсованным ответом на stackoverflow. Команда из заплючованного ответа не работала и кто-то скромно написал, что не работает, но вот для моего хуавея делаю вот так и работает, тысяча плюсов в карму этому господину.

ssh-keygen -e -m pem -f ~/.ssh/id_rsa.pub | sed '1d;$d' | tr -d '\n' | base64 -d | xxd -c 24 -g 4 -u | sed -e "s/^.*: //" -e "s/.\{25\}$//g"

на выводе вы получите примерно вот такую простыню, нужно будет сохранить (не переживайте за меня, это тестовый ключ)

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Дальше заводим ключ на Huawei. Ключ надо будет копировать в команды прямо так, как он вам вывелся на предыдущем этапе. На Huawei AR6120 команды следующие (если у вас белый список на логин по ssh не забудьте также разрешить ip вашего сервера логиниться):

Внимание, вот ссылка на весь код и команды текстом, я не изверг, просто пикабу не позволяет нормально вставлять код. В конце продублирую ссылку.

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

На коммутатор Huawei S5735 команда чуть-чуть отличается, есть по ссылке в конце.

Для обращения к устройствам из скрипта я завела БД на sqlite, но вы можете брать информацию из текстовых файлов или ещё откуда. Поле пароля в базе будет пустым, оно оставлено для устройств, которые не поддерживают логин по ключу (вдруг такие будут)

Структура базы:

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Вставка происходит примерно так:

`insert into netdev (hostname,ip,login,pass,tag,model) values ( 'ufa-ar6120-2', '10.2.100.2','backuper','','huawei','AR6120');`

Теперь про скрипт. И на цисках, и на микротиках, и на D-Link прекрасно работала следующая схема:

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

На хуавее же логин при такой схеме происходит, в логах это видно, но никакие команды, переданные таким способом, не выполняются. Никакие манипуляции c -i -T -t не работают. Я закопалась в процессе в логи ssh, в переменные окружения и прочее. Примерно понятно, что открытый терминал не считается терминалом и это даже нормально, но никакие опции, которые туда должны впихать команды, не работают. Моего скилла победить эту конструкцию не хватило. Пришлось использовать expect.
Кстати, если кто может нормально описать почему оно не работает и как это побеждать - будет здорово. А то я как собачка - вроде частично понимаю, а нормально написать не могу.

Всего использоваться будут 5 скриптов (напомню, код текстом по ссылке в конце).

Первый скрипт разбирает базу и запускает бэкап для каждого устройства в параллель.

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Сначала у меня был один скрипт expect на все устройства (команды то одинаковые), но на коммутаторах он в 20% случаев не успевал с первой командой, так как на них очень-очень долгая загрузка после логина. А на роутерах наоборот, он завершался, не успев получить вывод от tftp и завершал сессию. Пришлось расставить костыли в виде sleep и разделить на два скрипта.

Для роутеров вот, для коммутаторов по ссылке в конце.

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

У Huawei и cisco немного по-разному сделан текущий конфиг.

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Текущий конфиг (аналог running-config) по команде save сохраняется на Huawei в vrpcfg.zip. Как уже писалось выше, при попытке сохранять это по tftp/ftp это падает всегда zip архивом и при распаковке у конфига внутри архива всегда одно и тоже имя. То есть, на такие автоматические бэкапы всё равно надо накручивать скрипт распаковки и переименования. НО! Конфиг можно сохранить в текстовом виде с любым именем .cfg и уже его сливать.

Если вам нужно добавить дату - можно добавить её в имя конфига, который будет падать по tftp (чтоб на роутере память не занимать - там всегда сохраняем с одинаковым именем). Я не добавляю дату, так как всё падает в git, там версионность поддерживается и так.

Далее идет скрипт для оценки того, что у нас накопировалось - хочется понимать, что успешно, что нет. А также коммит, пуш и отсылка отчета на почту.

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Зачем каждый раз выбирать ключ ssh? Huawei сожрал только 1024 бита, а gitea хотела минимум 2048. Так что пришлось завести два и менять - один для логина, другой для коммитов.

Теперь сам анализатор логов analyse_result. Он простой как валенок, тут ваша фантазия может разгуляться. Я просто смотрю что написано success на сохранении и на копировании. Заметьте, у роутеров и коммутаторов строчки вывода разные.

Я в таких вспомогательных скриптах придерживаюсь понятного стиля написания, не гоняясь за умещением всего в одну строчку (чтоб потом вспомнить, что там вообще было), так что стиль такой не просто так)

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Ну и пихаем в cron чтоб выполнялся каждый день:

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Изменения в Gitea выглядят примерно вот так

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

Сколько времени на это ушло? Ну вот столько:

Автобэкапы сетевого оборудования Huawei IT, Huawei, Сетевое оборудование, Резервное копирование, Системное администрирование, Длиннопост

9 дней работы от 30 минут до 3х часов в день или 19 коммитов. Больше всего я боролась с логином по ключу и с удаленным выполнением команд.

Весь код текстом тут.

Осталось раскатать это на 260 устройств :) Потом можно что угодно раскатывать сразу на все, используя эти наработки. Например, в планах составить рамочный access-list (он как бы есть, но слишком пошли различия от филиала к филиалу, хочется причесать). Ну а пока - залогиниться на каждое устройство ручками и вписать пользователя с ключом.

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

Понятное дело, сейчас Huawei такого типа (малый офис, скажем так) не очень распространены в РФ. Уже не домашний роутер, ещё не энтерпрайз. Однако, он завозится активно, а материалов хрен да нихрена. Надеюсь, кому-то когда-то пригодится.

Показать полностью 12

Пример маленькой автоматизации zabbix-Mikrotik-ELK

Итак, в прошлом посте читатель узнал, что у меня завелось 55 микротиков. За прошедшее время, по заветам комментаторов, был развернут ELK Stack. Это такая штука для сбора логов со всего, что может эти логи слать. ELK = Elasticsearch + Logstash + Kibana.

Настраивала вот по этим двум статьям, в принципе там всё понятно. Раз и два.


Но помним, что микротиков сильно больше пары штук – это раз. Второе, если прописывать все их в фильтры сборщика логов, то появляется ещё одно место, куда надо что-то писать руками при вводе микротика в эксплуатацию, что не есть хорошо. Да и лень мне было прописывать их все. Короче, во мне стал зарождаться DevOps.


Задача - чтобы в заббиксе мы микротик завели – а логи с него автоматом бы полились и уже с меткой mikrotik.


Я слегка погружусь в теорию, чтобы было понятнее, что мы делаем. Итак, развернут ELK – изначально логи попадают в logstash, где с ними можно что-то сделать. Например, мы отбираем по некоторым критериям логи микротиков и вешаем на них метку «Mikrotik». Этим критерием у меня является IP – то есть «если ip из вот этого перечисления, то это микротик». Если бы у нас был ELK только для микротиков – мы бы просто вешали метку на весь трафик или обошлись без неё, но мы потом хотим добавлять еще логи всякого, например, виндовых серверов. После обработки логи попадают в elasticsearch, где мы их просматриваем с помощью Kibana (это типа веб-морда).


Для начала нам надо получить список микротиков из zabbix. Я использую для этого скриптик на питоне, который получает ip по группе и сразу генерирует кусок конфига, который будет в logstash filter.


Сперва надо установить модули zabix для питона:

apt install python3-pip

pip3 install pyzabbix


Теперь нам надо получить id группы в zabbix – его можно посмотреть в адресной строке браузера на странице группы – там в конце будет что-то типа groupid=65


Cам скрипт ниже. Мне не захотелось заморачиваться и один первый хост у меня всегда дублируется, вы можете заморочиться.

Пример маленькой автоматизации zabbix-Mikrotik-ELK Системное администрирование, DevOps, Zabbix, Mikrotik, Длиннопост

Получается строка вида «if [host] in ["10.1.1.254", “10.2.2.254”]{»


Теперь её надо вставить в правильное место конфига logstash. Чтобы этого добиться, я ставлю метку #MIKMIKMIK туда, куда будет вставлена получившаяся строка.

Вставлять будем с помощью Ansible, один раз вставится, потом будет проверяться на соответствие. Собственно из-за этого и выбран Ansible – он сам будет проверять наш конфиг на соответствие и вносить изменения только, если они есть.


Вот так выглядит /etc/logstash/conf.d/filter.conf до первой работы анзибля

Пример маленькой автоматизации zabbix-Mikrotik-ELK Системное администрирование, DevOps, Zabbix, Mikrotik, Длиннопост

Теперь собираем котлету вместе. Делаем playbook в ansible, который запустит нам скрипт, потом получившийся конфиг вставит в конфиг logstash, и если зафиксированы изменения – перезапустит службу. Со службой я долго не могла понять – почему перезапуска не происходит и ansible отваливается по timeout – ему просто не хватало прав.

write_logstash.yml:

Пример маленькой автоматизации zabbix-Mikrotik-ELK Системное администрирование, DevOps, Zabbix, Mikrotik, Длиннопост

Ну и запихиваем скрипт в крон делаться каждый час.

15  *  *  *  * ansible-playbook /usr/scripts/write_logstash.yml


Опытный читатель спросит – и что же, нам теперь на 55 микротиках настраивать логирование? И мы возвращаемся к предыдущему моему посту (и понимаем, зачем нам это было надо). Вот пример настройки лог-сервера, при этом в команде к каждому микротику указывается его IP в качестве источника данных. Без этого у меня автоматом выбирался служебный ip с интерфейса ip-ip туннеля и это было неудобно.

Пример маленькой автоматизации zabbix-Mikrotik-ELK Системное администрирование, DevOps, Zabbix, Mikrotik, Длиннопост

Ну и уровень логирования настраивается так же, только команду заменить.


В итоге мы получили что хотели – достаточно добавить микротик в заббикс и настроить на нем пересылку логов, а в ELK оно попадёт автоматом с нужной меткой.


Получился маленький кирпичик автоматизации, но путь в DevOps иногда начинается с одного шага..


Код текстом.

Показать полностью 4

Ansible для Mikrotik: бэкапы по identity и псевдо-иммутабельность

Внезапно появилось у меня 50 микротиков по филиалам. Задача – настроить бэкап в систему контроля версий и получить возможность выполнить какую-то настройку на всех микротиках, где этой настройки нет. Вторая задача стояла – научиться что-то делать в ansible. Тут ansible не содержит особых преимуществ перед обычным bash скриптом, кроме, может, скорости работы за счет параллельности выполнения.


Все мануалы, что я нашла, содержали инструкцию по бэкапу в ansible одного микротика и такие типа «экстраполируйте сами». Ну зашибись, вся проблема в том, что имя бэкапа задаётся вручную, а если микротиков много, то как-то сделанные бэкапы надо различать.


В микротике есть поле identity и логично было бы именем из identity и называть бэкап. Но вначале я не нашла как его сохранить в переменную и пошла задавать переменные вручную. Кому интересно про identity – переходите к способу 2.


Я опущу, как ставить ansible, задавать пароли и шифровать их, это как раз легко гуглится.


Способ с заданием имени бэкапа в переменной вручную.

ansible_user должен иметь доступ на микротик full, а сервер, с которого запускаете yml должен иметь доступ по ssh на микротик. При этом либо надо разок законнектиться по ssh до этого и сохранить ключи, либо отключить проверку ssh ключей в ansible.


Пикабу съедает пробелы. Ссылка на код текстом будет в конце

Ansible для Mikrotik: бэкапы по identity и псевдо-иммутабельность Mikrotik, Системное администрирование, Длиннопост

Но всё же меня глодала мысль, что можно использовать identity, а тут удачно работа оплатила курсы по всяким там девопс штукам и мне рассказали про register. Так что нет ничего невозможного, смотрите далее.


Способ с бэкапами микротика по identity

Тут проблема в том, что stdout_lines возвращает штуку типа [[u’name: Kostroma]] и как я ни крутила – как к массиву я к ней обратиться не могу. Так что немного через задницу (буду рада, если подскажете красивое решение) из этой строки выковыривается строка с непосредственно identity.


Теперь убираем в hosts file_name

Ansible для Mikrotik: бэкапы по identity и псевдо-иммутабельность Mikrotik, Системное администрирование, Длиннопост

Про то, как делать текстовый бэкап – в примере 1, скрестить ужа с ежом можете сами.

Мой скрипт по запихиванию в систему контроля версий и отсылки на почту. Вот тут я писала подробнее как настроить SVN


#!/bin/bash

now=$(date +"%d_%m_%Y")

rm /usr/scripts/log.txt

ansible-playbook --vault-password-file /etc/ansible/vault_pass_file /usr/scripts/mik-backup.yml >> /usr/scripts/log.txt

cd /usr/svn_backup_repo/DFL_BACKUPS

svn add mikrotik/* --force -q >> /usr/scripts/log.txt

svn commit -m "added backups $now" >> /usr/scripts/log.txt

/usr/bin/mail it@mydomain.ru < /usr/scripts/log.txt -s "Отчет о бэкапах Mikrotik"


Иммутабельность – это неизменность. То есть если уже, например, в файле есть такие изменения, то второй раз они не делаются. Это то, в чем фишка Ansible и то, что не реализовано для микротиков (так как например в firewall важен порядок применения – это одна из причин, почему в его конфиге не поддерживается иммутабельность).


Теперь сюжет из жизни: мне понадобилось вкатить на все микротики одинаковый фильтр сетей OSPF – оставить только серые сети и фильтрануть по маске 10.0.0.0/8. При этом на каких-то микротиках я это уже делала, но не помню на каких. Прощелкать 50 штук – ну такая себе забава.


Итого сливается бэкап в текстовом виде, идет поиск по нужной строке и если она не найдена, то выполняем команду. А если найдена – ничего не делаем. Такая вот псевдо-иммутабельность получается. Да, один скрипт – одна команда, что не очень удобно, под список команд надо дорабатывать.

Ansible для Mikrotik: бэкапы по identity и псевдо-иммутабельность Mikrotik, Системное администрирование, Длиннопост

Сылка на весь код текстом вот

Ну и я не претендую на гуру, только-только начала щупать Ansible, надеюсь кому-нибудь пригодится.

Показать полностью 3

Один пинг проходит и тишина – решение проблемы

Кому не интересно, можно сразу переходить к блоку «как лечить».


Симптомы:

Итак, ранним осенним утром внезапно отвалились почти все сервисы для одного из филиалов. Симптомы: один пинг проходит и дальше «тишина». Иногда может пролететь еще 1 icmp, но редко. При повторном запуске пинга даже одного пакета уже не пролетает, если не выдержать паузу в несколько минут. Отвалились не все сервисы, но большинство.

Та часть схемы сети, которая нас интересует:

Один пинг проходит и тишина – решение проблемы Системное администрирование, Пинг, Перенаправление, Сети, Маршрутизация, Длиннопост

Понятно по схеме, что грешить сразу стали на красный ящик WatchGuard Firebox, но на нём явно никаких блокировок в логах не обнаружено. Поэтому коллега пока пускал трафик до самых важных сервисов в обход, а я ставила WireShark на то, что не столь нужно вот-прям-щас.


Что происходит:

Итак, что показал WireShark:

Один пинг проходит и тишина – решение проблемы Системное администрирование, Пинг, Перенаправление, Сети, Маршрутизация, Длиннопост

А показал он нам, что после первой же пары request/reply нам прилетело от Watchguard сообщение ICMP redirect (type 5; code 1), в котором сказано примерно следующее «братюнь, да что ты мне своими реквестами отвечаешь, я тут посмотрел – у меня есть более крутой маршрут для этого хоста – шли всё на шлюз 10.77.10.254».


Вот тут и дошло до меня, что ICMP – это не только пинги, но и «Internet Control Message Protocol». Из вики: «ICMP-сообщения с типом 5 используются маршрутизаторами для обновления записей в таблице маршрутизации отправителя». Далее, собственно, request по-прежнему приходит с WatchGuard, а reply уходит на D-Link. При этом, на сервере есть статический маршрут в сеть 10.97.0.0/16 (через 10.77.10.3), а системе строго срать на этот маршрут! Всё потому, что на самом деле при получении сообщения redirect, маршрут на хост (то есть более специфический) добавляется в таблицу маршрутизации на 10 минут. Но route print его не показывает. И не нужно гнать на винду: во всех debian были всё те же симптомы.


Почему это происходит:

Беда Особенность Watchguard, как и микротиков, что Site-to-Site IPSec не является интерфейсом, не участвует в таблице маршрутизации, и, соответственно, маршруты на сеть за поднятым туннелем вы в ней не увидите. На нашем ватче был маршрут 10.0.0.0/8 на 10.77.10.254, так как за D-Link находятся все остальные филиалы (агрегированные по /16 каждый), чтоб не писать маршрут на каждый филиал (их 50, а динамической маршрутизации нет). Из-за особенностей Watchguard получилось так, что на 10.97.0.0/16 маршрута он не видел. Раньше, кстати, всё было ок до последнего обновления прошивки.


Почему некоторые сервисы и все компы были доступны: на них стоял касперский с сетевым модулем, который отбрасывал эти сообщения как небезопасные.


Что было сделано и не помогло:

Попробовали задрать метрику на маршруте 10.0.0.0/8 на WatchGuard – не помогло. Попробовала сделать правило фильтрации по типу ICMP и блочить эти сообщения – не помогло, через это правило трафик с сообщением редиректа не проходил.

Один пинг проходит и тишина – решение проблемы Системное администрирование, Пинг, Перенаправление, Сети, Маршрутизация, Длиннопост

Ну и были перечитаны кучи мануалов по отключению редиректа на WatchGuard – ничего рабочего не нашлось.


Как лечить в итоге:

На линухе лечится тремя командами (2 чтоб прям вот сейчас, одна, чтоб прям вообще).

Запрет приёма редиректа:

/sbin/sysctl -w net.ipv4.conf.eth0.accept_redirects=0

Запрет отправки редиректа:

/sbin/sysctl -w net.ipv4.conf.eth0.send_redirects=0

И чтоб вообще:

echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

Ну и может networking рестартануть, делала машинально.

При этом редиректы продолжают падать, но эффекта не оказывают:

Один пинг проходит и тишина – решение проблемы Системное администрирование, Пинг, Перенаправление, Сети, Маршрутизация, Длиннопост

На винде правится параметрами реестра, но эффекта до перезагрузки не оказывает (даже если выключить-включить сетевой интерфейс). Параметр в ветке

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

называется EnableICMPRedirect и выставляется в 0. По некоторым советам гугла (про Windows 2000 простихосподи), добавляла еще EnableICMPRedirects (во множественном числе). НО! После ребута сообщения redirect на машинах с исправленном параметром вообще не регистрируются WIreShark’ом, что меня несколько смутило (а вдруг вернутся?). Ну и ребутать over 100 серваков – такая себе идея.


Так что в итоге убрала маршрут 10.0.0.0/8 и добавила вместо него два:

10.0.0.0/10 и 10.64.0.0/11 – получились все сети от 10.0 до 10.95 включительно, а 97-ая, как видите, не вошла, что нас в принципе устроило. Проблема ушла.


То, что обычно пишут в начале поста:

Предыдущий мой пост на ИТ тематику был более 2 лет назад.

Чуть раньше этого я познакомилась на пикабу с классным чуваком, а полтора года назад мы поженились. Сисадмин и программист – норм сочетание оказалось =)


Я попробовала писать на хабр (мне даже одобрили аккаунт за тот пост), но мне не понравилось – на пикабушечке и аудитория поживее и можно не так цензурить текст.


А ещё наш офис вместе с серверной, которая уже стала мини-ЦОД для компании два раза за два года переехал. Если кому интересно – напишите в комментах, могу сделать пост о том, как происходит такой переезд, что мы планируем на каких этапах и т.д. На идеал не претендуем, происходит та ещё трешанина, но рассказать могу.

Показать полностью 4

Настройка TLS на Exchange 2010/2013

Итак, как я кому-то обещала:

Настройка TLS на Exchange 2010/2013

Протокол TLS (Transport Layer Security — безопасность транспортного уровня) – это такая новая версия SSL. И то и другое - криптографические протоколы, обеспечивающие защищенную передачу данных в сети с помощью сертификатов безопасности для шифрования каналов связи.

Когда это бывает нужно в exchange – когда вы хотите, чтобы почта между вами и вашим партнером шифровалась и её было бы трудно расшифровать. Ну, как обычно: если у вас паранойя, это ещё не значит, что за вами не следят ;)

Наш пример выглядит как-то вот так:

Настройка TLS на Exchange 2010/2013 Системное администрирование, Exchange 2013, Exchange 2010, TLS, Почта, Длиннопост

Наша половина левая. У нас (mydomain.ru) два exchange сервера с ролью Hub-Transport (доменные имена ex01 и ex02) и два edge-сервера (доменные имена ed01 и ed02), через которые идет внешняя почта. Для edge-серверов созданы соответственно MX-записи в DNS зоне, которая смотрит вовне. У наших «друзей» (frienddomain.ru) всё аналогично, но может быть и по-другому, для настройки нашей половины это не принципиально.

Я рассматриваю ситуацию, когда почта уже настроена и ходит вовне, но пришло время параноиков.

Общий алгоритм:

Запросить SSL-сертификат

Подписать его в центре сертификации

Подгрузить его в exchange и связать с SMTP

Сделать коннекторы с TLS

Включить в send-коннекторе обязательный запрос TLS


Запрос SSL-сертификата

Большая часть манов на английском начинается с того, что у вас из воздуха появляется сертификат. Обратитесь к администратору безопасности – как я «люблю» такие фразы. Нам придется справляться и за загадочного администратора.

Заходим на edge-сервер ed01 и смотрим текущие сертификаты. Это вам радикально пригодится, если сломаете почту – чтобы вернуть старый сертификат, придется указать его номер.

/из-под админа открываем консоль exchange powershell на edge-сервере/

Get-ExchangeCertificate | fl

Теперь создаем CRC – Certificate Signing Request (тоже на edge, в той же консоли exchange powershell):

New-ExchangeCertificate -GenerateRequest -Domainname ed01.mydomain.ru,mail-server1.mydomain.ru -PrivateKeyExportable $True >>c:\ed01req.txt

В текстовом файле будет простыня символов – она нам нужна на следующем этапе.


Подпись SSL-сертификата

То, что мы создали раньше – лишь запрос, теперь надо получить подписанный сертификат. Если у вас в компании всё круто и вы можете подписать его доверенным центом сертификации – здорово. Но нам хватит и самоподписанного.

Хороший ман по подписыванию сертификата тут и там есть все картинки, чтоб не раздувать пост. Что делаем:

Надо найти сервер, на котором стоит роль центра сертификации (Active Directory Certification Services). Этот сервер точно должен быть, если вы настаивали работу почты через owa или просто вне домена (exchange activesync). У нас это условный сервер DB01 и висит центр сертификации на порту 8080 (потому что 80 уже чем-то оприходован) http://db01.mydomain.ru:8080/certsrv/). Заходить на него надо из-под учетки доменного админа или с аналогичными правами.

Выбрать «Request a certificate»

Выбрать «Or, submit an advanced certificate request»

Выбрать «Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.»

В поле ввода скопировать простыню символов из первого пункта.

Нажать «Submit», выбрать точку «DER Encoded» и скачать сертификат. Получаем файл ed01.cer

Шаблон должен быть "WebServer". Если поля для выбора шаблона, как на картинках в мане нет, то в поле атрибутов указать"CertificateTemplate:WebServer".


Загрузка SSL-сертификата на почтовик

Копируем сертификат в корень диска C:\ на edge-сервер ed01 (для определенности. На самом деле – куда угодно).

На edge-сервере из консоли exchange powershell от доменного админа:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\ed01.cer -Encoding byte -ReadCount 0)) -PrivateKeyExportable $true -Password:(Get-Credential).password | Enable-ExchangeCertificate -Services SMTP

Соглашаемся с заменой сертификата. На этом моменте упадет внешняя почта на данном edge-сервере. Выпадет warning о том, что потеряна подписка на AD, сделайте новую с помощью EdgeSubscription:

Перезагружаем сервер edge (чисто эмпирическое наблюдение, наверное, хватит ребута службы транспорта).

После перезагрузки в консоли exchange powershell создаем новую подписку:

New-EdgeSubscription –FileName c:\edge_subscr.xml

Созданный xml-файл копируем на сервер exchange ex01 в корень диска C:\

Теперь на сервере exchange (вообще-то на сервере с ролью Hub-Transport) подтверждаем подписку:

Для Exchange 2010: Зайдем в консоль управления Exchange -> раздел Конфигурация организации -> действие New Edge Subscription.

В Exchange 2013 надо делать загрузку из консоли powershell:

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\edge_subscr.xml" -Encoding Byte -ReadCount 0)) -Site "S000"

Сайт тут – сайт Active Directory, где у вас находятся почтовик с edge.

Если ed01 был связан и с ex02 – повторяем на нем аналогично.

Можно еще пнуть синхронизацию: Start-EdgeSynchronization

И да, еще раз перегружаем edge (но можно и просто ребутнуть службу, вероятно), минут через 10 починится внешняя почта.

Мануал говорит: на этом этапе сервер уже будет предлагать TLS. Неправда, не верьте.


Создаем коннекторы отправки и получения

На edge-сервере ed01 создаем коннектор получения (Receive Connector). Вот здесь уже хватает инструкций, можно выбрать на свой вкус. Как определить IP MX серверов у друзей:

nslookup –type=MX frienddomain.ru

В коннектор добавляем MX серверов тех друзей, с которыми настраивали TLS. И мы добавляем еще свой Wi-Fi, дабы с него проверить, что строчка 250-STARTTLS появляется.

Настройка TLS на Exchange 2010/2013 Системное администрирование, Exchange 2013, Exchange 2010, TLS, Почта, Длиннопост
Настройка TLS на Exchange 2010/2013 Системное администрирование, Exchange 2013, Exchange 2010, TLS, Почта, Длиннопост

Как проверить, что кому надо будет предлагаться TLS – откуда-нибудь извне домена (с того вайфая, чей адрес указали в коннекторе) заходим в обычную консоль и набираем:

telnet mail-server1.mydomain.ru 25

EHLO localhost

В выводе должна появиться строчка «250-STARTTLS». (где-то посередине).

Создать из консоли edge-сервера коннектор отправки не получится – его надо создавать на сервере с ролью hub-transport (exchange). На 2013 - в web-консоли. А на Edge он автоматом приедет по подписке (минут через 5).

Send-Connector на Exchange:

Настройка TLS на Exchange 2010/2013 Системное администрирование, Exchange 2013, Exchange 2010, TLS, Почта, Длиннопост

Поскольку, FQDN можно указать только один, делаем два аналогичных коннектора.

Коннекторы надо создавать симметрично, в обоих доменах, для которых настраивается TLS.


Включаем обязательный запрос TLS в Send-Connector

На сервере exchange из exchange powershell ("EdgeSync - TLS_to_frienddomain" – Это имя нашего коннектора):

Set-SendConnector "EdgeSync - TLS_to_frienddomain" -RequireTLS 1

Это делаем с обоих сторон. Перезапускаем службу транспорта на edge и проверяем.

Get-SendConnector "EdgeSync - TLS_to_frienddomain" | fl

Настройка TLS на Exchange 2010/2013 Системное администрирование, Exchange 2013, Exchange 2010, TLS, Почта, Длиннопост

Иииии, всё повторяем для второго edge ed02.

Собственно, вопрос для тех, кто в теме: лучше делать два send-коннектора, где указывать разный FQDN и распространять каждый из них на оба edge, или на каждый edge распространять свой коннектор только со своим FQDN?


Ну и заключение: на оригинальность не претендую. Просто рабочая (у меня) инструкция, собранная с 5-6 мануалов, так как до этого ни с чем подобным дело не имела и тупила на элементарных вещах. Ссылки на большинство инструкций найти не смогла, так что тут не привожу.

Показать полностью 5
Отличная работа, все прочитано!