Меня зовут Алексей, и я работаю  в компании ecommpay IT. Мы пишем и эксплуатируем ПО для эквайринга и процессинга карточных платежей. Если совсем по-простому – мы делаем так, чтобы оплачивать товары в Интернете было удобно, быстро и безопасно.

Я было хотел написать, что в компании я решаю проблемы, как Мистер Вульф из известного фильма, но вовремя вспомнил недавнюю статью и подкаст Василия Пантюхина, и решил, что надо быть скромнее.

Пусть это будет Максми Поташёв Александр Друзь.

Почему? потому что чаще всего я по работе отвечаю на три простых вопроса:

Что из оборудования или софта было заказано в текущему/прошлом месяце/квартале? Что ещё можно/нужно заказать в этом квартале, чтобы уложиться в бюджет?
Где деньги сейчас находится заказанное оборудование? А что есть на складе?
Когда приедет/будет оплачено то, что заказали?

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

disclaimer: “В нашей жизни не всё, всегда и везде, а кое-что, иногда и местами” (с) Максим Дорофеев.
Всё ниженаписанное можно и нужно считать личным мнением автора, не претендующим на истину в последней инстанции, и даже на полноценное исследование. Все персонажи вымышленны, все совпадения случайны.

Кто обычно занимается закупками техники и софта, и какие с этим есть проблемы

В не-ИТ компаниях обычно это офисный сисадмин (ну или начальник ИТ-отдела, если таковой вообще есть).

С ИТ-компаниями всё сложнее. Я видел как варианты “офисного сисадмина на максималках”, когда человек покупал в т.ч. и железо для ДЦ, и софт, и ноутбуки для сотрудников. Если компания большая, то в ней может быть целый отдел, который занимается закупками (причём всего – от скрепок до СХД). В маленьких компаниях со множеством команд “живущих по эджайлу”, вообще у каждой может быть свой бюджет и своя карта для оплаты (и хорошо, если это карта корпоративная, а не личная).

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

Я встречал ситуацию, когда каждый сисадмин в компании мог практически без апрува заказывать серверы для своей команды через письмо в sales-отдел хостинга. Помимо кучи железа, которое не пойми для чего было заказано, и как использовалось, довольно часто возникала ситуация, когда сервер выдали, а кто, когда и зачем его заказал – непонятно. Или сервер выдали – и его тут же по ошибке или намеренно “подрезали” более расторопные коллеги. Отдельно стоит отметить чатик в скайпе на 20+ человек, в котором сидели представители хостинга и все сисадмины, и где одним из самых частых вопросов было “а кто заказывал сервер по тикету xxxxx?”

Но кто бы это ни был, частенько бывает так, что управление расходами на ИТ-инфраструктуру превращается в кошмар:

• у офисного сисадмина часто не хватает квалификации и времени (потому что обычных офисных задач с него никто не снимал);
• у директора ИТ (CIO/CTO/CITO, подставить нужное) и так дел невпроворот, в итоге задачи либо “падают на пол”, либо рандомно скидываются кому-то из его подчинённых, (обычно, когда все сроки уже прошли), либо просто сжирают и без того конечное рабочее время и силы;
• у отдела закупок своё (отличное от ИТ) начальство, свои KPI и свой взгляд на то, как должен быть организован процесс. В идеальном мире сотрудники этого отдела имеют некоторое представление о том, что они покупают, и плотно общаются с командами-заказчиками, но так происходит не всегда. Да и выделенный отдел – это, банально, дорого;
• если оплатой занимаются тимлиды команд или отдельные инициативные сотрудники, то отслеживание этого – мрак, ужас, и много-много новопассита для бухгалтерии. Левые личные карты, учётки на личные почты на гмыле, потеря информации при увольнениях/переходах и т.д. и т.п. Поиск концов каждый раз превращается в увлекательный квест.

Почему так происходит? Айтишники не очень хотят возиться с бумажками, счетами и отчётностью, да и вообще не очень любят общаться с менеджерами. У них (как правило) есть резон побыстрее включить нужный сервис, протестировать, и, если всё ок – запустить в продакшен. Меньше всего им хочется отвечать на письма и звонки от продаванов и обсуждать детали договора с бухгалтерией и юристами.

Процесс управления работой с поставщиками называется на Западе Supplier relationships management, а если по-модному – FinOPS. Когда я только начинал этим заниматься года три с половиной назад, ни про каких FinOPS я не знал, поэтому для названия команды выбрал именно Supplier relations. В англоязычных статьях упирают на то, что FinOPS оптимизируют только облачные расходы (читай: умеют пользоваться Cost calculator), но для простоты здесь я буду считать, что это одно и то же.

Кто такие FinOPS

Supplier relations managers, (или FinOPS) – это люди, которые не только занимаются закупками IT-сервисов, лицензий и оборудования, но и налаживают связь между заказчиком (т.е. компанией, где они работают) и внешними поставщиками. Чтобы не было, как на известной картинке:

Собственно, сам процесс закупки – это только один из этапов довольно длинной цепочки.

Ещё раньше, даже до поиска подходящего поставщика, нужно заняться переводом хотелок заказчика (бизнеса или команды) в нечто измеримое: ядра, гигабайты, стойки, киловатты и т.д. И хорошо если заказчиком является свой родной ИТ-отдел, (хотя и тут бывает не всё радужно).

Например, задача найти “хостинг в Бразилии” может на самом деле означать как то, что нужно проработать вариант организации полноценного PoP с размещением оборудования и подключением провайдеров, так и то, что для тестовых целей нужно поднять пару виртуалок в AWS в соответствующем регионе. Причём, реальные требования могут меняться в процессе жизни всего проекта в обе стороны.

Следующим шагом является поиск подходящего поставщика (в гугле на рынке или через знакомых). При этом у каждого из них свои условия оплаты и гарантии (часто с привлечением партнёров), свои нюансы вроде SLA со звёздочкой и примечанием мелким шрифтом на пятьдесят последней странице договора, и ещё десяток различных мелочей, часть из которых проходит по разряду “так исторически сложилось” и ни в каких документах не отражается. И чем понятнее (на языке поставщика!) будет сформулирован запрос, тем меньше отличий будет между ожиданием и реальностью. (и это происходит, в хорошем сценарии, ещё до подписания договора, на этапе предварительного знакомства). Ну и опять же, в каждом крупном заказе есть множество различных нюансов: например, одни провайдеры делают резервирование VPN-каналов по-умолчанию, другие хотят за это дополнительных денег. Одни готовы подписаться на SLA по latency, другие нет. Какой-нибудь Trusted Platform Module или дополнительная сетевая карта, как опция при заказе сервера, не стоят, практически, ничего, но если покупать их у того же поставщика отдельно, то влетят в копеечку – и таких нюансов просто море.

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

Ну и наконец после получения железки или лицензии есть “послепродажное обслуживание”, с которым тоже далеко не всегда всё бывает гладко, и приходится помогать коллегам решать различные вопросы, в т.ч. и самому общаться с техподдержкой (и её начальством), координировать возвраты по RMA и т.д.

Одна компания пользовалась весьма крупным публичным облаком для тестовых сред. Облако достаточно дешёвое, но его стабильность даже для этих целей оставляла желать, к тому же саппорт отвечал не то, чтобы быстро, а уж про решение проблем я вообще молчу. На звонке с аккаунт-менеджером тот заверил, что это неприемлемо, и он примет все меры… После чего исчез. Натурально, перестал отвечать на письма, а его личного номера у нас не было. Как вы думаете, что сделали FinOPS в этой ситуации?

С одной стороны, это куча бумажек, писем, звонков и новых знакомств практически ежедневно. Ты общаешься с партнёрами, юристами, бухглатерией и “внутренними заказчиками” по совершенно разным вопросам, начиная от причины появления НДС/VAT в очередном инвойсе и заканчивая порядком расположения плат расширения в сервере в зависимости от выбранной в конфигураторе опции razer extender. Нужно следить за рынком, новыми версиями железа и софта, новостями, которые могут повлиять на стратегию закупок (например, недавние остановки фабрик в Техасе могут привести к дефициту и увеличению сроков отгрузки, так что лучше какие-то позиции купить заранее). Не менее важно давать поставщикам обратную связь – не только по нынешним/прошедшим заказам, но и делиться планами на квартал/год.

Как-то мы ждали оборудование от одного очень важного партнёра для размещения в нашей стойке. Партнёр – очень крупная международная компания, поэтому для доставки нанял специального подрядчика, который уже общался с логистами и нами, как получателями груза. Примерно за день до предполагаемой даты доставки мне звонит представитель подрядчика и просит не принимать груз, потому что это оборудование отправили к нам по ошибке, а “правильное” отправят в другой день. Этот же партнёр отличился, заказав в датацентре кроссировку в нашу стойку без LoA (letter of authorization), т.е. без разрешения с нашей стороны. А т.к. кроссировку прокладывал ещё один подрядчик, то о том, что к нам собираются завести кабель, я узнал только от нашего аккаунт-менеджера, который запросил разрешение на доступ в нашу стойку инженеров ДЦ.

В подавляющем большинстве случаев, задачей любого поставщика (не важно, продукта или сервиса) является доставка пользователю счастья. В случае b2b счастье (оно же value) обычно выражается в удовлетворении некой потребности (как бы банально это ни звучало). Но проблема заключается в том, что далеко не всегда заказчик может сформулировать, а что же он, собственно, хочет. И тут FinOPS выступает в роли “переводчика”, причём в обе стороны. С одной стороны, он объясняет поставщикам в технических терминах (и со специфическими для поставщика деталями), что же именно хочет получить бизнес. Да, в идеальном мире это делает “админ или тимлид из ИТ отдела”, но… см выше про интровертную сущность инженеров и недостаток времени у руководителей.

С другой стороны, нужно перевести бравурные презентации пресейлов на технический язык, продраться сквозь бумажки (а вы знали, что английский канцелярит ничуть не лучше русского?), добавить известными “мелочами”, которые не пишутся в оферте, и внятно объяснить своим, что же именно нам хотят продать, но уже на понятном внутри языке.

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

Другой неочевидный момент – это экономия времени. Если у FinOPS есть крепкий технический бэкграунд, то многие вещи он может разруливать сам, не отвлекая коллег или руководителей. Составление оптимальных спек (учитывая особенности вендора или партнёра), общение с пресейлами и саппортом – зачастую, всё это гораздо удобнее решать именно им, т.к. именно у FinOPS есть под рукой и контекст задачи, и нужные контакты, и возможность ускорить решение вопроса за счёт личных знакомств.

Полезно периодически тестировать разных поставщиков одного и того же железа. В сравнении узнаёшь, кто как работает с налогами и логистикой, у кого какие скидки у вендора и т.д. Из курьёзных случаев – как-то один наш давний партнёр предложил нам партию серверов по выгодной цене, хотя раньше именно это оборудование мы у него не покупали. Серверы оказались “почти такие же”, но в несколько штук не доставили сетевые и диски, плюс немного напортачили с гарантией.

Ещё был совершенно классический случай, когда две услуги от разных провайдеров “мамойклянус, независимые!” оказались в одном кабеле. Было неприятно.

С кем взаимодействуют FinOPS по работе

В больших (и очень больших) компаниях отдел закупок может быть централизованным. Но это немного не наш сценарий. Впрочем даже в этом случае FinOPS найдёт своё место либо в рамках этого отдела, либо…

Разумно выделять SR team (или FinOPS team) в рамках ИТ-отдела. Почему? потому что часто это основная точка расходов компании. Закупка железа, лицензий, сервисов – очень быстро расходы на ИТ становятся заметными (и очень заметными) для собственников, и ИТ-директору нужно очень хорошо и чётко не только объяснять, сколько и куда уже потратили, но и делать прогнозы (или составлять бюджет и его исполнять) на квартал, а то и год вперёд. Сюда же относятся управление лицензиями и общение с сервис-провайдерами – всё это забота ИТ, и FinOPS, как его части.

Одна из обычных историй – в пять часов вечера пятницы к тебе приходит представитель поставщика, и говорит, что хорошо бы оплатить вот этот инвойс до конца дня, а то резерв превратится в тыкву, и отгрузка пройдёт неизвестно когда. Далее начинается квест “подтверди закупку, найди бухгалтера и дождись платёжки” длиною в час. Платёжка была отправлена в 17:58, заказ был спасён.

Команда SR (FinOPS) может успешно работать (и работает) в связке с Ops и инфраструктурными командами (которые непосредственно занимаются эксплуатацией датацентров, сетевого и серверного железа), привлекая их экспертизу и помогая общаться с вендорским саппортом, начиная от помощи с эскалациями (когда проблема не решается в разумные сроки, и нужен живительный пендель; и заканчивая полным ведением тикета (как правило, общение с саппортом крупного вендора вялотекущее, но контекст всё равно нужно держать в голове. Плюс в случае RMA помогать с доставкой или организацией визита сервис-инженера).

Я встречал мнение, что быть технарём FinOPS не обязательно, ему главное бумажки вовремя перекладывать, эскалации писать и за оплатами следить. Но на своём опыте могу сказать. что именно FinOPS в таком случае не получится, а будет очередной “отдел закупок”, слабо понимающий, что за услуги он закупает.

Ещё одна типичная история – это постоянный анализ “выгодных предложений” от партнёров. Предложения бывают выгодные или не очень, своевременные и не совсем. Их первичным анализом занимается именно FinOPS, как “первая линия обороны”. Если же он просто будет бегать туда-сюда с вопросами, то какой в нём смысл?

Неочевидные нюансы работы и требования к FinOPS

Как я уже говорил выше, при оформлении сделки (подписании договора и/или выставлении инвойса) возникают различные неожиданные моменты, даже если мы говорим о 100% белых компаниях.

Сюда относится:

• юрисдикция сделки (по законодательству какой страны заключается соглашение);
• резидентами каких стран являются стороны сделки;
• по какому адресу необходимо отгрузить товар или предоставить услугу;
• валюта (RUR/USD/EUR – порой одна из сторон, например, не принимает платежи в USD, или наоборот, не может платить в USD без большого геморроя, предпочитая евро, сюда же платежи из России в пользу иностранных юр. лиц);
• налоги (в каждой стране свои приколы);
• сроки поставки и её стоимость;
• трансграничная торговля, санкции и ограничения регуляторов (и связанные с этим ограничения на поддержку, увеличение сроков поставки и т.д.);
• срок договора (расторгнуть его досрочно может быть очень дорого), SLA сервиса, и т.д. и т.п.

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

Например, некоторое время назад покупать софт в РФ было выгоднее, чем в Европе, потому что на него не начислялся НДС. С января, к сожалению, халява закончилась, и по этому поводу в конце 2020 года было достаточно жарко, т.к. нужно было успеть заказать/подписать/оплатить самые важные и дорогие позиции.

Что требуется от Supplier relations manager/FinOPS

• Разговорный английский. Это прямо must have и не обсуждается, если только ваша компания не общается сугубо с российскими поставщиками
• Разумная степень занудства.
• Не бояться разбираться с бумажками, огромным количеством почты и кучей разных сейлзов, часть из которых разговаривает по-английски хуже, чем вы (хотя по опыту, общаться с британцами и ирландцами тоже нелегко).
• Умение ориентироваться в 100500 различных сервисах, в части из них разбираться очень хорошо.
• Умение и желание находить нужных людей и добиваться от них того, что тебе нужно.
• Умение найти нужный сервис по очень примерному ТЗ, а заодно набросать MVP или задать правильные вопросы пресейлу (например, при выборе датацентра).
• Совершенно обязателен технический кругозор (а также желание его постоянно расширять), чтобы разговаривать на одном языке и со своими командами, и с вендорами/партнёрами.
• Умение держать в голове кучу вещей одновременно и помнить сроки, суммы и проценты (это бывает важно). Можно, конечно, обойтись каким-то аналогом CRM, но помнить всё равно нужно много (как минимум – как и где быстро найти нужную информацию).

Инструменты FinOPS

Начать можно с почты (это вообще основной инструмент); шаренной папки (хоть на гуглодиске) для сканов документов, вики (для ведения реестра поставщиков) и гуглотаблицы с раскладом по оплатам.

Уже после, когда поймёте, что вам нужно, можно будет поискать (или написать самим) соответствующие инструменты а-ля “CRM наоборот”.

Не надо недооценивать силу эксель-таблиц и усложнять что-то раньше времени.

Ну и конечно, мессенджеры становятся вашими лучшими друзьями. Причём почти все, включая довольно экзотические – потому что у всех партнёров разные предпочтения и корпоративные правила. В 2021 говорить про использование мессенджеров это, наверное, из разряда “советы Капитана Очевидность”, но нужно понимать, что у FinOPS это не опция, а суровая необходимость и бОльшая часть работы.

Заключение

Закупки в IT – это просто, как кататься на горящем велосипеде. Управление закупками в IT – это не только своевременная оплата счетов и бюджетирование. Это ещё и общение с партнёрами, коллегами и “просто так”, потому что никогда не знаешь, какая информация и какие знакомства тебе пригодятся завтра. Сегодня ты слушаешь байки об особенностях работы в арабских странах и думаешь “как хорошо, что мы там не работаем!”, а завтра ищешь партнёра для размещения там нового PoP. Это ещё и глубокое понимание особенностей собственной инфраструктуры, чтобы коллеги из эксплуатации получили нужное качество сервиса без звёздочек и сносок мелким шрифтом. Это, наконец, понимание юридических и финансовых “правил игры”, потому что вовремя подмеченная неточность в договоре или бланке заказа может сэкономить неделю-другую времени на согласованиях.

В общем, это весело!

The post Закупки как сервис appeared first on Логово (а)социальной твари.

С той поры и рекомендованный JunOS для SRX обновился на 15.1 (для линейки SRX300, по крайней мере), и ASA научилась в route based IPSec (c версии софта 9.8), что несколько упрощает настройку. И вот на текущей работе не так давно представился шанс снова собрать такую схему. И снова неудачно – при регенерации туннель благополучно падал (и не всегда поднимался без ручного рестарта). И снова в логах тишина и непонятки, а т.к. ASA находилась у нашего партнёра, то и дебажить, соответственно, не было никакой возможности.И вот теперь представился случай собрать схему, при которой обе стороны (и SRX, и ASA) находятся под нашим управлением, соответственно, поиграться можно на славу.

Диспозиция

Итак, что у нас имеется:

• Juniper SRX340, JunOS 15.1X49D150.2
• Cisco ASA 5506 asa 9.8.4
• route based IPSec между ними (роутинг будет обеспечиваться BGP, о нём тоже скажу пару слов)
  

Схема

Конфигурация

Juniper

Начнём с конфигурации SRX. У меня довольно много различных туннелей строится на SRX, в итоге я пришёл примерно к такой схеме:

set security ike policy IKE-ASA mode main
set security ike policy IKE-ASA proposals SHA256-AES128-5-86400
set security ike policy IKE-ASA pre-shared-key ascii-text ...

set security ike gateway GW-ASA ike-policy IKE-ASA
set security ike gateway GW-ASA address 192.0.2.2 
set security ike gateway GW-ASA dead-peer-detection interval 10
set security ike gateway GW-ASA dead-peer-detection threshold 3
set security ike gateway GW-ASA local-identity inet 198.51.100.2
set security ike gateway GW-ASA external-interface ae0.4
set security ike gateway GW-ASA version v2-only

set security ipsec vpn VPN-ASA bind-interface st0.7
set security ipsec vpn VPN-ASA df-bit clear
set security ipsec vpn VPN-ASA vpn-monitor source-interface st0.7
set security ipsec vpn VPN-ASA vpn-monitor destination-ip 169.254.100.2
set security ipsec vpn VPN-ASA ike gateway GW-ASA
set security ipsec vpn VPN-ASA ike ipsec-policy SHA256-AES128-3600-14-policy
set security ipsec vpn VPN-ASA establish-tunnels immediately

set interfaces st0 unit 7 description "ASA AnyConnect router"
set interfaces st0 unit 7 family inet mtu 1436
set interfaces st0 unit 7 family inet address 169.254.100.1/30

set routing-options static route 192.0.2.2/32 next-hop 198.51.100.1

set security zones security-zone ZONE-VPN interfaces st0.7 host-inbound-traffic system-services ping
set security zones security-zone ZONE-VPN interfaces st0.7 host-inbound-traffic system-services ike
set security zones security-zone ZONE-VPN interfaces st0.7 host-inbound-traffic system-services traceroute
set security zones security-zone ZONE-VPN interfaces st0.7 host-inbound-traffic protocols bgp

Видно, что используется IKEv2, без traffic-selectors (у нас в арсенале и без того достаточно средств, чтобы ограничить хождение трафика – от префикс-листов BGP до security policies). До кучи используется DPD (dead peer detection) и vpn-monitor (у них немного разный тип проверок, для надёжности я использую оба).

Cisco

Конфигурация ASA:

crypto ipsec ikev2 ipsec-proposal SHA256-AES128
 protocol esp encryption aes-256 aes-192 aes
 protocol esp integrity sha-256

crypto ipsec profile IPSEC-PROFILE-AMS1-VPN2
 set ikev2 ipsec-proposal SHA256-AES128
 set pfs group14
 set security-association lifetime kilobytes unlimited
 set security-association lifetime seconds 3600

crypto ikev2 policy 1
 encryption aes-256 aes-192 aes
 integrity sha256
 group 5
 prf sha256
 lifetime seconds 86400
  
tunnel-group 198.51.100.2 type ipsec-l2l
tunnel-group 198.51.100.2 ipsec-attributes
 isakmp keepalive threshold 30 retry 10
 ikev2 remote-authentication pre-shared-key ...
 ikev2 local-authentication pre-shared-key ...

crypto ikev2 enable outside

interface Tunnel7
 nameif l2l-ams1-vpn2
 ip address 169.254.100.2 255.255.255.252 
 tunnel source interface outside
 tunnel destination 198.51.100.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PROFILE-AMS1-VPN2

Структура конфигов примерно одинаковая на обоих роутерах, но, как обычно, название секций не совпадают совершенно.
Давайте пробежимся, что чему соответствует.

Сравнение конфигов

IKE policy / proposal

crypto ikev2 policy 1
 encryption aes-256 aes-192 aes
 integrity sha256
 group 5
 prf sha256
 lifetime seconds 86400

set security ike proposal SHA256-AES128-5-86400 description ike-phase1-proposal1
set security ike proposal SHA256-AES128-5-86400 authentication-method pre-shared-keys
set security ike proposal SHA256-AES128-5-86400 dh-group group5
set security ike proposal SHA256-AES128-5-86400 authentication-algorithm sha-256
set security ike proposal SHA256-AES128-5-86400 encryption-algorithm aes-128-cbc
set security ike proposal SHA256-AES128-5-86400 lifetime-seconds 86400

set security ike policy IKE-ASA mode main
set security ike policy IKE-ASA proposals SHA256-AES128-5-86400
set security ike policy IKE-ASA pre-shared-key ascii-text ...

Здесь начинается некоторая путаница в терминологии. То, что у Cisco называется IKE policy, у Juniper – IKE Proposal. А IKE policy у Juniper похоже на tunnel group у ASA… Лично мне больше нравится подход Juniper, но тут, безусловно, дело привычки. Надо сказать, настройка IKEv2 (тем более route based) на ASA выглядит всё же куда логичнее, чем crypto maps и прочее безобразие, которое было раньше.

IPSec policy/proposal

crypto ipsec ikev2 ipsec-proposal SHA256-AES128
 protocol esp encryption aes-256 aes-192 aes
 protocol esp integrity sha-256

crypto ipsec profile IPSEC-PROFILE-SHA256-AES128-3600-14
 set ikev2 ipsec-proposal SHA256-AES128
 set pfs group14
 set security-association lifetime kilobytes unlimited
 set security-association lifetime seconds 3600

set security ipsec proposal SHA256-AES128-3600 description ipsec-phase2-proposal
set security ipsec proposal SHA256-AES128-3600 protocol esp
set security ipsec proposal SHA256-AES128-3600 authentication-algorithm hmac-sha-256-128
set security ipsec proposal SHA256-AES128-3600 encryption-algorithm aes-128-cbc
set security ipsec proposal SHA256-AES128-3600 lifetime-seconds 3600

set security ipsec policy SHA256-AES128-3600-14-policy description SHA256-AES128-3600-14-policy
set security ipsec policy SHA256-AES128-3600-14-policy perfect-forward-secrecy keys group14
set security ipsec policy SHA256-AES128-3600-14-policy proposals SHA256-AES128-3600

Здесь оба вендора делают плюс-минус одинаково – сначала создаём proposal с параметрами шифрования/аутентификации, а потом навешиваем на него lifetime и pfs.

Gateway

tunnel-group 176.56.179.13 type ipsec-l2l
tunnel-group 176.56.179.13 ipsec-attributes
 isakmp keepalive threshold 30 retry 10
 ikev2 remote-authentication pre-shared-key ...
 ikev2 local-authentication pre-shared-key ...

set security ike gateway GW-ASA ike-policy IKE-ASA-LEGAL
set security ike gateway GW-ASA address 192.0.2.2
set security ike gateway GW-ASA dead-peer-detection interval 10
set security ike gateway GW-ASA dead-peer-detection threshold 3
set security ike gateway GW-ASA local-identity inet 198.51.100.2
set security ike gateway GW-ASA external-interface ae0.4
set security ike gateway GW-ASA version v2-only

А здесь отличия уже более явные. На ASA PSK указывается непосредственно в настройках пира. Juniper же позволяет здесь задать и исходящий интерфейс и дополнительные опции типа local-identity, плюс ссылается на ike policy (где мы указывали PSK). Кстати, если вы захотите переделать на ASA IKEv2 в IKEv1 (и наоборот), то у Cisco надо будет пересоздавать всю tunnel-group. А на SRX всего лишь сменить одну строчку. (Правда, далее при commit могут вылезти несовместимые опции, но это уже детали)

VPN / VTI

interface Tunnel7
 nameif l2l-ams1-vpn2
 ip address 169.254.100.2 255.255.255.252 
 tunnel source interface outside
 tunnel destination 198.51.100.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PROFILE-SHA256-AES128-3600-14

set security ipsec vpn VPN-ASA bind-interface st0.7
set security ipsec vpn VPN-ASA df-bit clear
set security ipsec vpn VPN-ASA vpn-monitor source-interface st0.7
set security ipsec vpn VPN-ASA vpn-monitor destination-ip 169.254.100.2
set security ipsec vpn VPN-ASA ike gateway GW-ASA
set security ipsec vpn VPN-ASA ike ipsec-policy SHA256-AES128-3600-14-policy
set security ipsec vpn VPN-ASA establish-tunnels immediately

set interfaces st0 unit 7 description "AnyConnect router"
set interfaces st0 unit 7 family inet mtu 1436
set interfaces st0 unit 7 family inet address 169.254.100.1/30

И снова конфиг Juniper мне кажется более логичным. VPN настраивается отдельно (он может быть и policy-based), сам security tunnel – отдельно. Отдельное спасибо за “establish-tunnels immediately”. Очень полезная опция (цисководы поймут, о чём я). Ещё один “бонус” SRX – можно строить многоточечные IPSec, как с автообнаружением пиров (работает, к сожалению, только между SRX), так с ручным роутингом. Это, конечно, не полноценный DMVPN, но жизнь в сетапах типа “один центр – много филиалов” значительно облегчает.

Interfaces

Отдельно остановлюсь на настройке интерфейсов, на которых строится IPSec. У Juniper это, соответственно, ae0.4, у ASA – outside

crypto ikev2 enable outside

set security zones security-zone ZONE-INTERNET interfaces ae0.4 host-inbound-traffic system-services ike
set security zones security-zone ZONE-VPN interfaces st0.7 host-inbound-traffic system-services ping
set security zones security-zone ZONE-VPN interfaces st0.7 host-inbound-traffic system-services traceroute
set security zones security-zone ZONE-VPN interfaces st0.7 host-inbound-traffic protocols bgp

На интерфейсах нужно разрешить ike, иначе работать ничего не будет Дополнительно, у SRX нужно для туннельного интерфейса разрешить bgp/ipsec/whatever для входящих подключений на st0.x интерфейсе

Настройка BGP

Тут всё довольно банально (с одной стороны)

set protocols bgp group ASA type external
set protocols bgp group ASA description "AnyConnect router"
set protocols bgp group ASA hold-time 30
set protocols bgp group ASA import IMPORT-EBGP-ASA
set protocols bgp group ASA export EXPORT-EBGP-ASA
set protocols bgp group ASA local-as 64666
set protocols bgp group ASA neighbor 169.254.100.2 peer-as 65001

set policy-options policy-statement EXPORT-EBGP-ASA term 0 from route-filter 10.0.0.0/8 exact
set policy-options policy-statement EXPORT-EBGP-ASA term 0 then accept
set policy-options policy-statement EXPORT-EBGP-ASA term 1 then reject

set policy-options policy-statement IMPORT-EBGP-ASA term 1 then reject

На ASA отдаём агрегированный префикс нашей локалки – у меня это будет 10/8. От ASA ничего не принимаем, потому что с версии софта 9.8.4 всё равно нельзя анонсировать по BGP адреса management-интерфейсов (что объяснимо) и BVI (что жутко неудобно). Но если у вас за ASA есть ещё какие-то сети, их нужно будет добавить в policy, конечно.

asa(config-router-af)# network 10.255.32.252 mask 255.255.255.254
ERROR: BGP configuration not supported on management-only/BVI interface

Чтобы “увидеть” inside интерфейс, нужно будет на SRX прописать static route в сторону ipsec:

set routing-options static route 10.255.32.252/31 next-hop 169.254.100.2

Вдобавок, ASA до сих пор не умеет в loopback интерфейсы, поэтому все логи/netflow и прочая мы будем отправлять с inside.В ASA5506 есть встроенный свич, поэтому можно использовать виртуальный BVI-интерфейс (особенно полезно, когда у вас схема “роутер-на-палочке”, и используется всего лишь один физический порт.

interface BVI1
 nameif inside
 security-level 100
 ip address 10.255.32.253 255.255.255.254
management-access inside

После этого в нужных местах (logging, snmp, flow) в качестве интерфейса-источника нужно будет указать `inside`.

Если что-то пошло не так a.k.a. troubleshooting

IKE/IPSec

Первое – у вас должны установиться обе фазы IPSec (у Juniper это, собственно, IKE/IPSec). Смотрим:

admin@srx> show security ike security-associations 
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address   
2128190 UP     ae7d7d447326218a  2be3b3004ae0e36a  IKEv2          192.0.2.2    

admin@srx> show security ipsec security-associations  
  Total active tunnels: 6
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway   
  <131077 ESP:aes-cbc-128/sha256 fec3c7d1 2867/ unlim U root 500 192.0.2.2    
  >131077 ESP:aes-cbc-128/sha256 74d792ca 2867/ unlim U root 500 192.0.2.2    

На ASA:

asa# sho crypto ikev2 sa 

IKEv2 SAs:

Session-id:5, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id Local                                               Remote                                                  Status         Role
585564345 192.0.2.2/500                                  198.51.100.2/500                                        READY    RESPONDER
      Encr: AES-CBC, keysize: 128, Hash: SHA256, DH Grp:5, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/47018 sec
Child sa: local selector  0.0.0.0/0 - 255.255.255.255/65535
          remote selector 0.0.0.0/0 - 255.255.255.255/65535
          ESP spi in/out: 0xc989d9ea/0xcca8b6d5

У Juniper ещё можно посмотреть статистику по ipsec-туннелю, включая причины падения:

admin@srx> show security ipsec security-associations index 131078 detail 

ID: 131078 Virtual-system: root, VPN Name: VPN-ASA-LEGAL-PL
  Local Gateway: 198.51.100.2, Remote Gateway: 192.0.2.2
  Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Version: IKEv2
  DF-bit: clear, Copy-Outer-DSCP Disabled, Bind-interface: st0.7
  Port: 500, Nego#: 734, Fail#: 0, Def-Del#: 0 Flag: 0x600a29 
  Tunnel events: 
    Mon Dec 09 2019 13:40:35: IPSec SA rekey successfully completed (48 times)
    Mon Dec 09 2019 00:30:47: IKE SA rekey successfully completed (10 times)
    Fri Nov 29 2019 02:13:55: IPSec SA negotiation successfully completed (1 times)
    Fri Nov 29 2019 02:13:55: IKE SA negotiation successfully completed (1 times)
    Fri Nov 29 2019 02:13:55: No response from peer. Negotiation failed (7 times)
    Fri Nov 29 2019 02:10:14: DPD detected peer as down. Existing IKE/IPSec SAs cleared (1 times)
    Fri Nov 29 2019 01:39:15: IPSec SA rekey successfully completed (1 times)
    Fri Nov 29 2019 00:49:50: IPSec SA negotiation successfully completed (1 times)
    Fri Nov 29 2019 00:49:50: IKE SA negotiation successfully completed (1 times)
    Fri Nov 29 2019 00:49:30: No response from peer. Negotiation failed (23 times)
    Fri Nov 29 2019 00:37:24: DPD detected peer as down. Existing IKE/IPSec SAs cleared (1 times)
    Fri Nov 29 2019 00:30:00: IPSec SA rekey successfully completed (77 times)
    Thu Nov 28 2019 20:11:31: IKE SA rekey successfully completed (7 times)
    Tue Nov 26 2019 08:51:44: IPSec SA negotiation successfully completed (1 times)
    Thu Nov 21 2019 21:24:32: IKE SA negotiation successfully completed (1 times)
    Thu Nov 21 2019 01:06:27: IKE SA rekey successfully completed (6 times)
  Direction: inbound, SPI: 4bd2e2bd, AUX-SPI: 0
                              , VPN Monitoring: UP
    Hard lifetime: Expires in 3132 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 2495 seconds
    Mode: Tunnel(10 10), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (128 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64
  Direction: outbound, SPI: 504f306e, AUX-SPI: 0
                              , VPN Monitoring: UP
    Hard lifetime: Expires in 3132 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 2495 seconds
    Mode: Tunnel(10 10), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (128 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

Если с IPSec всё в порядке, то нужно смотреть на ACL (security policies, host-inbound правила и т.д.). На крайней случай, можно попробовать перезагрузить коробку (ASA) – мне, бывало, помогает.

BGP

Здесь всё довольно стандартно – если сессия не устанавливается, можно посмотреть через capture , летят ли BGP-hello в обе стороны.

На этом всё. Не знаю, виной ли тому новый софт, или звёзды так сошлись – но туннель ASA<>SRX держится стабильно и не падает раз в сутки, как было раньше.Надеюсь, у вас тоже всё получится!

The post Juniper SRX и Cisco ASA: серия очередная appeared first on Логово (а)социальной твари.

Итак, рассмотрим простую ситуацию. У нас есть аккаунт в Yandex (у меня это Yandex.PDD). Мы хотим отправлять почту с linux-машины (ubuntu 18.04) через SMTP Relay с авторизацией.
Делать мы это будем при помощи postfix.

1. Ставим нужное

Поехали:
[cc lang=”bash”]apt install postfix mailutils libsasl2-2 sasl2-bin libsasl2-modules[/cc]

2. Правим конфиги

cat /etc/mailname
[cc]server.example.com[/cc]
cat /etc/hostname
[cc]server.example.com[/cc]

cat /etc/postfix/main.cf
[cc lang=”bash”]
myorigin = /etc/mailname
ЕСЛИ почтовый домен совпадает с hostname сервера, меняем параметр mydestination
mydestination = localhost.$mydomain, localhost
Если этого не сделать, сервер не сможет слать письма в свой домен, т.к. будет искать адресатов в таблице локальных пользователей — разумеется безуспешно.
[/cc]
Часть настроек я опустил, оставил только то, что изменится по сравнению с дефолтной конфигурацией.

В этом файлике мы будем настраивать маппинг внутренних адресов
Подробное описание тут:
cat /etc/postfix/generic
[cc]
root robot@example.com
mailer-daemon robot@example.com
@localhost robot@example.com
@localhost robot@example.com
@example.com robot@example.com
@localhost.localdomain robot@example.com
[/cc]

Настраиваем rewrite адресов отправителей.
Вместо домена можно указать конкретный адрес
Подробное описание тут:
cat /etc/postfix/sender_canonical_maps
[cc]@example.com robot@example.com[/cc]

Тут мы говорим, для каких доменов (или адресантов) мы будем использовать релей
cat /etc/postfix/sender_relay
[cc]@example.com [smtp.yandex.ru][/cc]

А в этом файле, указываем, собственно, smtp-сервер и параметры аутентификации.
cat /etc/postfix/sasl_passwd
[cc][smtp.yandex.ru]:587 robot@example.com:password[/cc]

Т.к. взаимодействие с сервером идёт по TLS, не помешает скачать сертификат SMTP-сервера.
Добыть сертификат можно вот так:
[cc lang=”bash”]openssl s_client -starttls smtp -crlf -connect smtp.yandex.ru:25[/cc]

Из вывода нам нужно что-то вроде такого:
[cc]—–BEGIN CERTIFICATE—–
MIIGazCCBVOgAwIBAgIQcUU9mJXW4OUs5Gf0JfLtsjANBgkqhkiG9w0BAQsFADBf
MQswCQYDVQQGEwJSVTETMBEGA1UEChMKWWFuZGV4IExMQzEnMCUGA1UECxMeWWFu
ZGV4IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MRIwEAYDVQQDEwlZYW5kZXggQ0Ew
HhcNMTcxMDExMTMyNzI2WhcNMTkxMDExMTMyNzI2WjB3MQswCQYDVQQGEwJSVTET
MBEGA1UECgwKWWFuZGV4IExMQzEMMAoGA1UECwwDSVRPMQ8wDQYDVQQHDAZNb3Nj
b3cxGzAZBgNVBAgMElJ1c3NpYW4gRmVkZXJhdGlvbjEXMBUGA1UEAwwOc210cC55
YW5kZXgucnUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCTI5WsplxQ
g7gZDCEmnbxHI0a0/cXtx0+Zwz7Y9TSFy0NI/SzYC+bgukWvsnvuIheM3yKpJ+cU
Ss2G+K3nKOYDNJUezzziirhu3UVC/tZLD39orKKGAa6qmx5Dv2Z7/ynkOfKZjmXB
t9HemoCItyM62YTD8AQQmkMCB4Kue+j2wm8fHxPtgIYuQzEtD9xCU9vANj6imgaM
IlrM0cegknd6sWBDR074pDsBEUjg2GsNSqAo2nD0tvOGCFZ2qkIMLIjZgsCmtain
nM7Xt+THw8ApMu9BVsgTyXMTfVC0CzfB1HbId1UzqIbILprB3iLrxCHn3K1F68ok
WfBXBDY4gphTAgMBAAGjggMJMIIDBTAMBgNVHRMBAf8EAjAAMGkGA1UdHwRiMGAw
L6AtoCuGKWh0dHA6Ly9jcmxzLnlhbmRleC5uZXQvY2VydHVtL3ljYXNoYTIuY3Js
MC2gK6AphidodHRwOi8veWFuZGV4LmNybC5jZXJ0dW0ucGwveWNhc2hhMi5jcmww
cQYIKwYBBQUHAQEEZTBjMCwGCCsGAQUFBzABhiBodHRwOi8veWFuZGV4Lm9jc3At
cmVzcG9uZGVyLmNvbTAzBggrBgEFBQcwAoYnaHR0cDovL3JlcG9zaXRvcnkuY2Vy
dHVtLnBsL3ljYXNoYTIuY2VyMB8GA1UdIwQYMBaAFDdc4xngso6hqE7Sz6vQ3OML
XDVNMB0GA1UdDgQWBBTC1Kbatmr8y04cui/VCaPVq1mgKzAOBgNVHQ8BAf8EBAMC
BaAwggEXBgNVHSAEggEOMIIBCjCCAQYGDCqEaAGG9ncCBQEKAjCB9TCB8gYIKwYB
BQUHAgIwgeUwIBYZVW5pemV0byBUZWNobm9sb2dpZXMgUy5BLjADAgECGoHAVXNh
Z2Ugb2YgdGhpcyBjZXJ0aWZpY2F0ZSBpcyBzdHJpY3RseSBzdWJqZWN0ZWQgdG8g
dGhlIENFUlRVTSBDZXJ0aWZpY2F0aW9uIFByYWN0aWNlIFN0YXRlbWVudCAoQ1BT
KSBpbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlIGhlcmVpbiBhbmQgaW4gdGhlIHJl
cG9zaXRvcnkgYXQgaHR0cHM6Ly93d3cuY2VydHVtLnBsL3JlcG9zaXRvcnkuMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjARBglghkgBhvhCAQEEBAMCBsAw
egYDVR0RBHMwcYIOc210cC55YW5kZXgucnWCDnNtdHAueWFuZGV4LmJ5gg5zbXRw
LnlhbmRleC5reoIPc210cC55YW5kZXguY29tgg5zbXRwLnlhbmRleC51YYISc210
cC55YW5kZXguY29tLnRyggpzbXRwLnlhLnJ1MA0GCSqGSIb3DQEBCwUAA4IBAQA1
GjyKSYMgaRVLGd4EWtB3oTkybDu5QrUXt/eoZiquzUqZwk7x9FRsEEirawKsrSS6
FXcliRD7xcXneROVDZK1a4ur6974vn742B/lOx9T/7+6a8XQo4jz191zZWS3J47G
dSvkMZPSdsZPxn7cDbAymFP4yw3b/aJJBFarpYTUixvRXZardO93VAFx157pCt/8
3dN7jLWyYVWBvZh93JioukAu9uDt7Nzuq9XhTBLUzLnFFi4vXVsssKk7h3X2sMNU
kZ3EPMAOSsvl9XY5RHZJs7BZubvGgnDxxGFfziP1XnTbL4MRCAXbdhwx3nmnQ3yZ
nRG0DfdqYIuPGApFORYe
—–END CERTIFICATE—–[/cc]

..и сохранить в файл (в моём случае /etc/postfix/yandex.crt).

3. Проверяем

Комилируем конфигурацию для postfix:
[cc]
postmap /etc/postfix/canonical
postmap /etc/postfix/generic
postmap /etc/postfix/sasl_passwd
postmap /etc/postfix/sender_relay
[/cc]

И рестартуем сервис
[cc]service postfix restart[/cc]

Отправку почты проверяем так (возможно, потребуется поставить mailx):
[cc]echo ‘Hello, world!’ | mail -s ‘Test of Yandex relay’ root@example.com[/cc]

Если всё ок, то будет так (смотреть можно так: `sudo tail -F /var/log/mail.log`):
[cc]
May 5 01:10:38 server postfix/qmgr[18264]: 6F57B7D92E: from=, size=365, nrcpt=1 (queue active)
May 5 01:10:39 server postfix/smtp[18274]: 6F57B7D92E: to=, relay=smtp.yandex.ru[213.180.204.38]:25, delay=1.3, delays=0.01/0/0.49/0.8, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued on smtp4j.mail.yandex.net as 1557007839-eNWMy4YFLq-AcPCKVEh)
[/cc]

А если не ок, то вот так:
[cc]
May 5 01:05:36 vpn01 postfix/qmgr[18014]: 6B2567D92E: from=, size=386, nrcpt=1 (queue active)
May 5 01:05:36 vpn01 postfix/smtp[18024]: 6B2567D92E: to=, relay=smtp.yandex.ru[213.180.204.38]:25, delay=0.49, delays=0.01/0/0.42/0.05, dsn=5.5.4, status=bounced (host smtp.yandex.ru[213.180.204.38] said: 503 5.5.4 Error: send AUTH command first. (in reply to MAIL FROM command))
[/cc]
Я, в своё время, долго бился с этой ошибкой (потому что часть почты таки ходила нормально, а часть отбрасывалась сервером), даже переписывался с поддержкой Яндекса на этот счёт. Ничего вразумительного мне, конечно же, не ответили. Помогла тотальная ревизия конфигурации. Так что проверьте внимательно – возможно, что-то где-то вы написали не так, как надо

Или вот так:
[cc]May 5 00:33:43 vpn01 postfix/qmgr[14714]: 2B1877D92F: from=<>, size=2359, nrcpt=1 (queue active)
May 5 00:33:43 vpn01 postfix/smtp[14724]: 2B1877D92F: to=, relay=smtp.yandex.ru[93.158.134.38]:587, delay=0.55, delays=0.01/0/0.49/0.05, dsn=5.7.1, status=bounced (host smtp.yandex.ru[93.158.134.38] said: 553 5.7.1 Sender address rejected: not owned by auth user. (in reply to MAIL FROM command))
[/cc]
Такая ошибка возникает, если в поле from указан не тот адрес, с которым вы логинитесь в почту.
Возможны и другие ошибки, но при корректной конфигурации мне они не попадались.

P.S. Я советую использовать ansible для раскатывания ПО на ваши машины, и хранить YAML-описание ваших хостов в Git. Такой подход не только экономит время при раскатывании новой машины (или переустановке старой), но и позволяет хранить всю конфигурацию ваших хостов в одном месте – наглядно и просто.

The post Настройка Postfix через Yandex relay appeared first on Логово (а)социальной твари.

Что мы рассмотрим?

• настройка доступов
• репликация
• резервные копии и восстановление

А теперь обо всём этом подробнее под катом

Настройка доступов

В нашей схеме работы используется связка PgBouncer + PostgreSQL 9.x.
PgBouncer – это мультиплексор соединений к БД, его использование обусловлено тем, что приложения могут плодить сотни коннектов к базе – а в postgresql схема работы такова, что “один коннект == один процесс”: соответственно, кол-во одновременно работающих коннектов(процессов) не сможет превышать кол-во ядер процессора.

PgBouncer позволяет группировать подключения к бд по связке “username/database”, и использовать тем самым одно подключение к БД для разных коннектов приложений. В некоторых случаех это позволяет неплохо сэкономить ресурсы и не дёргать базу лишний раз.

Для контроля доступа/подключения используется так называемый “hba” файл (сокр. от “host-based authentication”).
Почитать подробнее про него и его формат можно в официальной документации, здесь же стоит отметить лишь то, что у нас здесь их используется два: один – для PgBouncer’a, второй – для самого сервера PostgreSQL.

В файле для pgbouncer’a прописаны доступы для хостов приложений, в файле сервера – доступы для самого pgbouncer, ldap-пользователей и настройки, необходимые для работы репликации.
Так же, возможен дополнительный уровень проверки с использованием pg_ident.conf.

В общих чертах, это всё. В конце будет приведен наглядный пример настроек.

Репликация

Прежде, чем я опишу механизм настройки репликации для postgresql, следует сделать небольшую вводную.

PostgreSQL предоставляет такой механизм, как “потоковая репликация” (streaming replication): это механизм работы, основанный на постоянном копировании WAL-логов с master-сервера и применении их на слейве.
Чтобы это работало, нам необходим сервер, на котором установлена та же версия postgresql, что и на мастере (а в идеале – и такое же железо, чтобы, в случае становления слейва – мастером, он смог “потянуть” рабочую нагрузку), и идентичные настройки в конфигах и hba (кроме listen_addresses, понятное дело).

WAL (сокр. от “write-ahead log”) – это бинарный лог, в который postgres пишет диффы и правила, как их применять: это НЕ лог транзакций, в котором описаны SQL-команды для выполнения, и НЕ классический бинарный лог, в котором светятся только сырые данные – его внутреннее содержание отличается (хотя ближе ко второму варианту). Но основная особенность этого лога в том, что он пишется прежде, чем действия реально применяются в базе (отсюда и его название).
Имея сохраненную копию папки с данными postgresq и WAL-логи с того момента, как была сделана копия данных, можно осуществить восстановление PITR (сокр. от “point-in-time-recovery”) – восстановление на любой, заданный момент времени от создания бэкапа до последней метки времени в WAL-логе (об этом позже).

PostgreSQL позволяет себя настроить таким образом, чтобы стягивать WAL-логи в real-time режиме (за это отвечает специальный демон), причем это будет практически “бесплатно”. Делать это можно как с мастера, так и с других реплик (т.н. “каскадная репликация”), в нашем случае мы можем позволить себе делать это напрямую с мастера (в случае с резервным копированием, это разумно – чтобы не было ошибок, связанных с несовпадающими id транзакций на мастере и слейвах).

Для начала, нам необходимо проверить, что в конфиге postgresql.conf имеются следующие настройки:

wal_level = archive (или выше); необходимо для того, чтобы WAL-логи содержали информацию, необходимую для работы streaming replication
hot_standby = on; позволяет обрабатывать запросы на чтение в процессе восстановления
max_wal_senders = “number_of_replicas + 1”; учитываются в общем кол-ве соединений к серверу max_connections; так же, можно задать max_replication_slots
wal_keep_segments = 1000; количество файлов WAL в директории pg_xlog/, которое будет храниться в папке с данными (по умолчанию, 16mb/файл);
оно должно быть достаточным для того, чтобы обеспечить реплике успевание их стягивать при потоковой репликации;
в противном случае, вы рискуете получить ситуацию, когда мастер удалит файлы журналов, которые ещё не были скопированы на реплику, и репликация сломается;
если у вас активная запись в БД, и за время “лага репликации” вы успеваете выбрать это количество – вам стоит его увеличить.

Если вы хотите дополнительно копировать WAL-логи в другое хранилище – вам понадобятся:

archive_mode = on;
archive_command = ‘test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f’ ; # здесь может быть любая ваша команда или даже скрипт, который обеспечит копирование файлов, например rsync

Далее, создаём в базе пользователя с определенной ролью REPLICATION, и прописываем в hba-файле сервера для него доступ.
Все действия производятся на pgsql-master.server из-под пользователя “postgres”:

[cc lang=”bash”]# md5 пароля формируется следующим образом: “md5” + $( echo -n “” | md5sum – )
# в psql выполняем:
postgres=$ CREATE ROLE repusr;
postgres=$ ALTER ROLE repusr WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN REPLICATION NOBYPASSRLS PASSWORD ‘md540e8137e4ef276ecbcbe3f1b2eb5c343’;

# добавляем в /etc/postgresql/9.6/main/pg_hba.conf следующую строчку (в данном случае, 192.168.0.11/32 – адрес pgsql-slave.server):
# помните: если в вашем hba-файле имеются запретительные правила, то порядок следования строк приобретает значение – анализ идёт сверху вниз, и если вы попадёте под запретительное правило – до вашего разрешения вы уже не доберетесь
host replication repusr 192.168.0.11/32 md5 # pgsql-slave.server

# чтобы применились новые правила из pg_hba.conf, выполним команду (нужны sudo-привилегии):
root@pgsql-master ~$: sudo systemctl reload postgresql
[/cc]

После этого необходимо сходить на pgsql-slave.server, и сделать т.н. “pg_basebackup” – команду, которая автоматизирует за нас следующие действия:

• создание checkpoint’a (когда сервер флашит все изменения на диск и создает контрольную точку);
• выполнение “pg_start_backup()” (в этот момент серверу сообщается о начале резервного копирования; создается checkpoint, метки начала, а все изменения в базе на это время будут писаться в WAL);
• запуск копирования основной директории с данными на резервный сервер с помощью rsync/cp или любыми другими способами;
• создание файла восстановления recovery.conf ;
• выполнение “pg_stop_backup()” (сообщает серверу о том, что резервное копирование завершено, и можно продолжить работу в штатном режиме);

Функционал “pg_basebackup” стал доступен начиная с версии 9.2, до этих пор процедура бэкапов и настройки репликации происходили по описанной выше схеме (подробнее здесь).
Итак. На сервере pgsql-slave.server выполняем (подразумевается, что основная директория с данными располагается в /db/9.6/main ):

[cc lang=”bash”]
root@pgsql-slave ~$: sudo systemctl stop postgresql
root@pgsql-slave ~$: sudo rm -rf /db/9.6/main/*
root@pgsql-slave ~$: su – postgres
postgres@pgsql-slave ~$: pg_basebackup -P -R -X stream -c fast -h pgsql-master.server -U repusr -D /db/9.6/main
postgres@pgsql-slave ~$: echo -e “recovery_target_timeline = ‘latest’\n# recovery_min_apply_delay = 10min \ntrigger_file = ‘/tmp/psql.trigger'” >> /db/9.6/main/recovery.conf
root@pgsql-slave ~$: systemctl start postgresql
[/cc]

Параметр “recovery_min_apply_delay = XX” позволяет настроить применение изменений из WAL-логов с задержкой на XX минут (часов, дней). Это быавет полезно, если вы любите дропать у себя таблички =)
Параметр “trigger_file” позволит нашей реплике быстро стать мастером в случае необходимости: для этого надо всего лишь создать этот файл – и postgresql перестанет стримить WAL-логи с мастера, сам станет мастером и откроется на запись.

Проверить, что наша репликация работает, можно следующим образом:

[cc lang=”bash”]
— (on slave – “t”, on master – “f”) SELECT pg_is_in_recovery();
postgres=$ SELECT pg_is_in_recovery();
# pg_is_in_recovery
# ——————-
# t
# (1 row)

— (on slave, т.н. “лаг репликации”) SELECT now()-pg_last_xact_replay_timestamp();
— если вы выставляли параметр “recovery_min_apply_delay”, то оно будет ~равно этому значению
postgres=$ SELECT now()-pg_last_xact_replay_timestamp();
# ?column?
# —————–
# 00:00:00.021257
# (1 row)

— (on master) SELECT * FROM pg_stat_replication;
postgres=$ \x
# Expanded display is on.
postgres=$ SELECT * FROM pg_stat_replication;
# -[ RECORD 1 ]—-+——————————
# pid | 507
# usesysid | 27581
# usename | repusr
# application_name | walreceiver
# client_addr | 192.168.0.11
# client_hostname |
# client_port | 54340
# backend_start | 2017-06-16 20:34:43.342+03
# backend_xmin |
# state | streaming
# sent_location | 3/9FABB8E0
# write_location | 3/9FABB8E0
# flush_location | 3/9FABB8E0
# replay_location | 3/9FABB8A8
# sync_priority | 0
# sync_state | async[/cc]

Итог: у нас есть рабочая реплика. Таким способом можно цеплять любое (разумное) количество реплик к мастеру, не трогая при этом сам мастер – надо лишь следить, чтобы мы не выходили за рамки max_wal_senders.

Если понадобится из неё сделать мастера – достаточно создать trigger_file: в этот момент slave станет new_master’ом и позволит влить в себя пачку данных.
При этом, файл recovery.conf переименуется в recovery.done, а trigger_file будет удален автоматически, как только слейв почувствует себя мастером.

ВАЖНО: стоит следить – чтобы не был запущен прежний “old_master”, в противном случае вы рискуете получить жёсткий рассинхрон.
Процедура возврата old_master -> master будет состоять из шагов:

• удалить папку с данными на old_master;
• сделать old_master репликой к new_master (создать пользователя, выполнить pg_basebackup);
• остановить new_master (бывший слейв), и переименовать обратно recovery.done > recovery.conf;
• запустить postgresql на old_master;

Если всё прошло без ошибок – таким образом мы получим картину, которая была до создания trigger_file; “удобно”, конечно – но что поделать

Резервное копирование и восстановление

Существует 3 основных способа, как можно делать резервные копии:

• использовать классические SQL-дампы нужных таблиц или баз данных;
• использовать периодическое резервное копирование средствами pg_dump/pg_dumpall;
• использовать резервное копирование на основе базовых копий и архивов WAL.

Первый вариант полезен для проверки консистентности данных (дамп не сделается, если нарушена связность в бд), но нам не подходит.
Второй вариант также не подходит: выполнение pg_dump не блокирует мастера, но создает довольно высокую нагрузку на дисковую подсистему и, главное, не позволяет выполнить Point-In-Time Recovery (PITR).
Поэтому мы будем использовать третий подход.

По своей сущности, он ничем не отличается от процедуры настройки реплики, описанной выше: бэкап с возможностью восстановления на момент во времени == pg_basebackup + пачка WAL-логов, начиная с момента создания бэкапа.
Это можно делать с использованием самописных скриптов, или с использованием утилиты barman (http://www.pgbarman.org/).
Barman – это всего лишь python-обвязка над всеми теми же действиями и функциями postgresql, но оформленными в довольно удобный инструмент.

Итак. Для приготовления нам понадобятся:

• сервер с достаточным количеством диска, на котором будет работать barman, 1шт;
• сервер для проверки наших резервных копий, 1шт;
• новые пользователи в базе с нужными привилегиями, 2шт;
• новые записи в pg_hba.conf для этих пользователей, по вкусу.

На сервер с barman’ом устанавливаем:

• postgresql-client
• postgresql-client-common
• postgresql-client-9.6 (версия должна совпадать с той, что стоит на нашем сервере БД)
• barman (версия 2+)

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

• postgresql-9.6
• postgresql-common
• postgresql-client-common
• postgresql-client-9.6 (версия должна совпадать с той, что стоит на нашем сервере БД)
• barman (версия 2+)
• postgresql-contrib-9.6
• python-psycopg2

Далее.
На master-базе (которую мы хотим бэкапить) создадим новых пользователей, и добавим их в pg_hba.conf.
Для корректной работы barman нам понадобятся 2 пользователя: “barman” (должен быть суперюзером) и “streaming_barman” (пользователь для стриминга WAL-логов, достаточно привилегий REPLICATION):

[cc lang=”bash”]
# добавим новых пользоавтелей в pg_hba.conf на сервере:
host postgres barman 192.168.0.12/32 md5 # pgsql-barman.server
host replication streaming_barman 192.168.0.12/32 md5 # pgsql-barman.server

# из-под пользователя “postgres”, в psql-консоли:
# как сделать правильный MD5-hash написано выше
postgres=$ BEGIN;
postgres=$ CREATE ROLE barman;
postgres=$ CREATE ROLE streaming_barman;
postgres=$ ALTER ROLE barman WITH SUPERUSER NOCREATEDB NOCREATEROLE LOGIN PASSWORD ‘md567e47ea958fcd33af11cb8fb8d3ecad1’;
postgres=$ ALTER ROLE streaming_barman WITH LOGIN REPLICATION PASSWORD ‘md5ce13788c9e6d33c997a5723aecb742a6’;
postgres=$ COMMIT;
postgres=$
postgres=$ SELECT pg_reload_conf();
[/cc]

Если мы всё сделали правильно, то теперь barman должен уметь ходить в нашу БД. Самое время настроить его для создания бэкапов.
Идём на сервер pgsql-barman.server и настраиваем конфигурационную секцию для нашего сервера. Напомню, что мы хотим схему “pg_basebackup + streaming WAL”.
[cc lang=”bash”]
#
# создаём файл следующего содержания в /etc/barman.d/pgsql-master.conf из-под пользоавтеля “root” (в этой директории уже есть подходящие шаблоны конфигов, в т.ч. для streaming replication)
# обратите внимание: название секции в конфигурационном файле и название самого файла совпадают – это идентификатор, по которому barman будет работать с вашим сервером.
#
#192.168.0.10 – это адрес нашего сервера с PostgreSQL
root@pgsql-barman ~$: cat /etc/barman.d/pgsql-master.conf
; Barman, Backup and Recovery Manager for PostgreSQL
; http://www.pgbarman.org/ – http://www.2ndQuadrant.com/
;
; Template configuration file for a server using
; only streaming replication protocol
;

[pgsql-master]
description = “pgsql-master.server”
conninfo = host=192.168.0.10 user=barman dbname=postgres
streaming_conninfo = host=192.168.0.10 user=streaming_barman
backup_method = postgres
streaming_archiver = on
slot_name = barman
retention_policy = RECOVERY WINDOW OF 7 DAYS
minimum_redundancy = 5
[/cc]

[cc lang=”bash”]
#
# создаем в домашней директории пользователя “barman” файлик .pgpass, кот. будет содержать информацию по подключениям к нашим серверам
# BE AWARE: лучше всего, чтобы этот файл должен быть с правами “только на чтение”, а сам сервер pgsql-barman.server должен быть надёжно защищен
# т.к. в этом файле пароли хранятся в открытом виде, а созданный нами в базе пользователь “barman” имееть привилегии SUPERUSER
# формат этого файла следующий: сервер:порт:база_данных:имя_пользователя:пароль
# допускается использование шаблона ‘*’
#
barman@pgsql-barman ~$: cat .pgpass
192.168.0.10:5432:postgres:barman:PASSWORDbarman
192.168.0.10:5432:*:streaming_barman:PASSWORDstreaming_barman

barman@pgsql-barman ~$: ls -la ~/.pgpass
-r——– 1 barman barman 329 Jun 14 10:27 /var/lib/barman/.pgpass
[/cc]
[cc lang=”bash”]
#
# проверяем, что созданные нами пользователи имеют все необходимые привилегии и доступы (выполняем команды из-под пользователя “barman”):
#
barman@pgsql-barman ~$: psql -c ‘SELECT version()’ -U barman -h 192.168.0.10 postgres
# version
# —————————————————————————————————————–
# PostgreSQL 9.6.3 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609, 64-bit
# (1 row)

barman@pgsql-barman ~$: psql -U streaming_barman -h 192.168.0.10 -c “IDENTIFY_SYSTEM” replication=1
# systemid | timeline | xlogpos | dbname
# ———————+———-+———–+——–
# 6429565456649844276 | 1 | 8/C9E37B8 |
# (1 row)
[/cc]
[cc lang=”bash”]
#
# создадим слот для репликации, и запустим стриминг WAL-логов
#
barman@pgsql-barman ~$: barman receive-wal –create-slot pgsql-master
barman@pgsql-barman ~$: barman receive-wal pgsql-master
[/cc]
[cc lang=”bash”]
#
# теперь нам осталось проверить статус сервера, и мы сможем запустить бэкап
#
barman@pgsql-barman ~$: barman check pgsql-master
# Server pgsql-master:
# PostgreSQL: OK
# superuser: OK
# PostgreSQL streaming: OK
# wal_level: OK
# replication slot: OK
# directories: OK
# retention policy settings: OK
# backup maximum age: OK (no last_backup_maximum_age provided)
# compression settings: OK
# failed backups: OK (there are 0 failed backups)
# minimum redundancy requirements: FAILED (have 1 backups, expected at least 5)
# pg_basebackup: OK
# pg_basebackup compatible: OK
# pg_basebackup supports tablespaces mapping: OK
# pg_receivexlog: OK
# pg_receivexlog compatible: OK
# receive-wal running: OK
# archiver errors: OK

barman@pgsql-barman ~$: barman backup pgsql-master
# Starting backup using postgres method for server pgsql-master in /var/lib/barman/pgsql-master/base/20170620T153138
# Backup start at xlog location: 3/B3D45640 (0000000100000003000000B3, 00D45640)
# Copying files.
# Copy done.
# Finalising the backup.
# WARNING: pg_basebackup does not copy the PostgreSQL configuration files that reside outside PGDATA. Please manually backup the following files:
# /etc/postgresql/9.6/main/postgresql.conf
# /etc/postgresql/9.6/main/pg_hba.conf
# /etc/postgresql/9.6/main/pg_ident.conf
# Backup size: 187.7 MiB
# Backup end at xlog location: 3/B5000000 (0000000100000003000000B4, 00000000)
# Backup completed

barman@pgsql-barman ~$: barman list-backup pgsql-master
# pgsql-master 20170620T153138 – Tue Jun 20 15:31:38 2017 – Size: 203.7 MiB – WAL Size: 0 B

barman@pgsql-barman ~$: barman show-backup pgsql-master 20170620T153138
# Backup 20170620T153138:
# Server Name : pgsql-master
# Status : DONE
# PostgreSQL Version : 90603
# PGDATA directory : /db/9.6/main
# Base backup information:
# Disk usage : 187.7 MiB (203.7 MiB with WALs)
# Incremental size : 187.7 MiB (-0.00%)
# Timeline : 1
# Begin WAL : 0000000100000003000000B4
# End WAL : 0000000100000003000000B4
# WAL number : 1
# Begin time : 2017-06-20 12:35:02+00:00
# End time : 2017-06-20 15:31:38.593898+03:00
# Begin Offset : 11299552
# End Offset : 0
# Begin XLOG : 3/B4AC6AE0
# End XLOG : 3/B5000000
# WAL information:
# No of files : 0
# Disk usage : 0 B
# Last available : 0000000100000003000000B4
# Catalog information:
# Retention Policy : VALID
# Previous Backup : 20170619T172911
# Next Backup : – (this is the latest base backup)
[/cc]

Вот мы и сделали бэкап, cool. Можем поставить эту команду в crontab, и делать бэкапы по расписанию. Вот толку от них будет немного, если мы не сможем из них восстановиться.

Чтобы этого избежать, мы будем регулярно восстанавливаться из нашего бэкапа на отдельном сервере. Делать это можно тоже по крону.
Только предварительно надо выполнить следующие действия:

• создать ssh-ключ пользвателю “barman”, чтобы он мог ходить на сервер для восстановления без пароля;
• добавить публичную часть ключа в .ssh/authorized_keys пользователю “postgres” на сервере для восстановления;
• добавить пользователю “postgres” привилегии для старта/стопа/проверки статуса postgresql.

[cc lang=”bash”]
#
# на сервере pgsql-barman.server, из-под пользователя “barman”
#
barman@pgsql-barman ~$: ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/barman/.ssh/id_rsa):
Created directory ‘/home/barman/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/barman/.ssh/id_rsa.
Your public key has been saved in /home/barman/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:npqoTQYiASIKYeL1EZeDkBIQy0MG/lTXg3ngsSliAgE barman@pgsql-barman
The key’s randomart image is:
+—[RSA 2048]—-+
|EO.oo+o=* |
|/o..o.==++ |
|+*.+ o +o . |
| .* . . |
|o .. S |
|.. . . . |
| o o |
| + . o |
| ..o o |
+—-[SHA256]—–+

barman@pgsql-barman ~$: cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDEXvb9WLCIS9Lkxb9MENOXl1Uvv+nqpIkvdx38zp7/h68maLCqDFXMfXciR8j1pS7xbtOgvjzxfAxZ4MAiqRfDq/PNwjiI3Bi+ZDrwRkUeQ4GBuwl99uVTnaa6qkTBZa4BKMZNnYhuAB8ZhhJ/r7TqwN+duch7cxt1Vc9O2zwJJE85doS3DZAO+cjoXuONgDLuF9p4w1A4NIhG9KxAgkLCwvjrvowhTB6zv8PJk7UKEUtgVSdpRDmS5g9OhSyzXZ7nrfHM96qheJgB0jSGOTMVo3UTpZ7orqEqR40QcHiMsiTEocRhzEiphPh82/3leOBtMhhvoJ3gT3j+XEalOOz9 barman@pgsql-barman
[/cc]
[cc lang=”bash”]
#
# на сервере pgsql-verify.server, из-под пользователя “postgres”
# так же, сразу добавим необходимые sudo-привилегии этому пользователю в sudoers (из-под пользователя “root”)
#
postgres@pgsql-verify ~$: install -m 700 -d ~/.ssh && echo -n ‘ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDEXvb9WLCIS9Lkxb9MENOXl1Uvv+nqpIkvdx38zp7/h68maLCqDFXMfXciR8j1pS7xbtOgvjzxfAxZ4MAiqRfDq/PNwjiI3Bi+ZDrwRkUeQ4GBuwl99uVTnaa6qkTBZa4BKMZNnYhuAB8ZhhJ/r7TqwN+duch7cxt1Vc9O2zwJJE85doS3DZAO+cjoXuONgDLuF9p4w1A4NIhG9KxAgkLCwvjrvowhTB6zv8PJk7UKEUtgVSdpRDmS5g9OhSyzXZ7nrfHM96qheJgB0jSGOTMVo3UTpZ7orqEqR40QcHiMsiTEocRhzEiphPh82/3leOBtMhhvoJ3gT3j+XEalOOz9 barman@pgsql-barman’ > .ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys
#
root@pgsql-verify ~$: echo ‘%postgres ALL=(ALL) NOPASSWD: /usr/sbin/service postgresql stop ,/usr/sbin/service postgresql start’ > /etc/sudoers.d/barman
[/cc]
[cc lang=”bash”]
#
# проверяем. пробуем зайти по ssh: barman@pgsql-barman.server -> postgres@pgsql-verify.server (должно пускать без проблем)
#
barman@pgsql-barman ~$: ssh postgres@pgsql-verify.server
[/cc]
ВАЖНО: на вашем сервере для проверок уже должны быть конфигурационные файлы, поскольку barman не копирует их при создании резервной копии базы – он об этом явно пишет в своём выводе:
[cc]
WARNING: pg_basebackup does not copy the PostgreSQL configuration files that reside outside PGDATA. Please manually backup the following files:
/etc/postgresql/9.6/main/postgresql.conf
/etc/postgresql/9.6/main/pg_hba.conf
/etc/postgresql/9.6/main/pg_ident.conf
[/cc]
Лучше всего скопировать их с вашего pgsql-master.server (только не забудьте подправить параметр ‘listen_addresses’ и вписать в него адрес сервера pgsql-verify.server)

Теперь у нас есть всё, что необходимо для восстановления бэкапа на сервере для проверок.
Само восстановление представляет из себя следующую последовательность действий:

• остановить postgresql на сервере;
• удалить все данные из PGDATA;
• запустить barman recover;
• запустить postgresql на сервере;
• проверить, что сервер поднялся и готов обрабатывать запросы.

Команда восстановления на заданный Point-In-Time выглядит так:

[cc lang=”bash”]barman recover –target-time “2017-06-19 16:08:00” –remote-ssh-command “ssh postgres@pgsql-verify.server” pgsql-master latest /db/9.6/main[/cc]

параметры означают следующее:
[cc]
–target-time | желаемый Point-In-Time, формат: date +’%Y-%m-%d %H:%M:%S’
–remote-ssh-comand | команда для доступа на сервер, в нашем примере: “ssh postgres@pgsql-verify.server”
| получается из вывода `barman list-backup`, в нашем примере: pgsql-master latest
| путь к директории, в которую следует восстанавливать бэкап, в нашем примере: /db/9.6/
[/cc]

Поскольку мы настроили доступ по ssh для пользователя barman, мы можем всё это сделать удаленно. Выглядит это примерно так:

[cc lang=”bash”]
/usr/bin/ssh -o ConnectTimeout=4 -o PubkeyAuthentication=yes -o PasswordAuthentication=no postgres@pgsql-verify.server ‘/usr/bin/sudo /usr/sbin/service postgresql stop’
/usr/bin/ssh -o ConnectTimeout=4 -o PubkeyAuthentication=yes -o PasswordAuthentication=no postgres@pgsql-verify.server ‘/usr/sbin/service postgresql status’
/usr/bin/ssh -o ConnectTimeout=4 -o PubkeyAuthentication=yes -o PasswordAuthentication=no postgres@pgsql-verify.server ‘/bin/rm -rf /db/9.6/main/*’
/usr/bin/barman recover –target-time “2017-06-19 16:08:00” –remote-ssh-command “ssh postgres@pgsql-verify.server” pgsql-master latest /db/9.6/main
/usr/bin/ssh -o ConnectTimeout=4 -o PubkeyAuthentication=yes -o PasswordAuthentication=no postgres@pgsql-verify.server ‘/usr/bin/sudo /usr/sbin/service postgresql start’
/usr/bin/ssh -o ConnectTimeout=4 -o PubkeyAuthentication=yes -o PasswordAuthentication=no postgres@pgsql-verify.server ‘/usr/sbin/service postgresql status'[/cc]

NB: в случае, когда вы восстанавливаете бэкап с timestamp’ом, сильно отличным от текущего – может потребоваться после завершения восстановления выполнить на сервере в psql из-под пользователя “postgres” команду
[cc lang=”bash”]SELECT pg_xlog_replay_resume();[/cc]

Это всё.
Можно это дело обернуть в скрипт и так же запускать по крону, после того как бэкап снимается.

The post Репликация PostgreSQL appeared first on Логово (а)социальной твари.

Ну а мы будем настраивать аналог IP SLA в Juniper, и называется он RPM (Realtime Perfomance Monitoring)

1. Что есть что

У нас есть пробы и тесты.
Проба – это, собственно, метрика, которую мы будем снимать. ICMP, UDP и т.д. Проба посылается на удалённый хост и отправляет ответ. Разумеется, если мы проверяем не просто ICMP, а udp/tcp-порт, то на удалённом хосте должен быть настроен респондер – причём вовсе не обязательно это должен быть такой же Juniper, может быть и обычный веб-сервер, если мы проверяем http url.

Поддерживаемые типы проб:

• HTTP GET request at a target URL
• HTTP GET request for metadata at a target URL
• ICMP echo request to a target address (the default)
• ICMP timestamp request to a target address
• UDP ping packets to a target device
• UDP timestamp requests to a target address
• TCP ping packets to a target device

Тест – это проба, запущенная в нужном количестве с нужным интервалом и параметрами (типа source port или next-hop). По каждому тесту можно посмотреть результат и статистику.

Давайте уже что-нибудь запустим

Настройка RPM довольно простая. Например, вот так выглядит простой icmp-тест
[cc]
set services rpm probe BRANCH test ICMP-PROBE probe-type icmp-ping
set services rpm probe BRANCH test ICMP-PROBE target address 172.27.1.17
set services rpm probe BRANCH test ICMP-PROBE probe-count 5
set services rpm probe BRANCH test ICMP-PROBE probe-interval 5
set services rpm probe BRANCH test ICMP-PROBE test-interval 5
set services rpm probe BRANCH test ICMP-PROBE thresholds successive-loss 5
set services rpm probe BRANCH test ICMP-PROBE destination-interface st0.4
[/cc]

“Как же так?” – спросите вы. Ведь мы только что договорились, что проба – это часть теста, а тут получается наоборот. Я не знаю, чем руководствовались разработчики JunOS, но в данном случае после probe идёт имя PROBE_OWNER – т.е. например роутер в филиале, к которому запускаются несколько тестов, или клиент, которого мы хотим мониторить. Немного путано, но так вот есть.

Параметры теста можно посмотреть в документации (там почти два десятка параметров). Также в этой же ветке (services rpm) можно настроить ответную часть пробы.

Что в результате?

Смотреть статистику по пробам можно вот так (можно все тесты указанного OWNER, можно только выбранного теста):
[cc]
root@srx340-01> show services rpm probe-results owner BRANCH
Owner: BRANCH, Test: ICMP-PROBE
Target address: 172.27.1.17, Probe type: icmp-ping
Destination interface name: st0.4
Test size: 5 probes
Probe results:
Response received, Thu Jan 11 08:38:38 2018, No hardware timestamps
Rtt: 12362 usec, Round trip jitter: -1450 usec, Round trip interarrival jitter: 1797 usec
Results over current test:
Probes sent: 5, Probes received: 5, Loss percentage: 0.000000
Measurement: Round trip time
Samples: 5, Minimum: 12362 usec, Maximum: 13886 usec, Average: 12975 usec, Peak to peak: 1524 usec, Stddev: 714 usec, Sum: 64876 usec
Measurement: Positive round trip jitter
Samples: 2, Minimum: 1426 usec, Maximum: 1456 usec, Average: 1441 usec, Peak to peak: 30 usec, Stddev: 15 usec, Sum: 2882 usec
Measurement: Negative round trip jitter
Samples: 3, Minimum: 436 usec, Maximum: 1500 usec, Average: 1129 usec, Peak to peak: 1064 usec, Stddev: 490 usec, Sum: 3386 usec
Results over last test:
Probes sent: 5, Probes received: 5, Loss percentage: 0.000000
Test completed on Thu Jan 11 08:38:38 2018
Measurement: Round trip time
Samples: 5, Minimum: 12362 usec, Maximum: 13886 usec, Average: 12975 usec, Peak to peak: 1524 usec, Stddev: 714 usec, Sum: 64876 usec
Measurement: Positive round trip jitter
Samples: 2, Minimum: 1426 usec, Maximum: 1456 usec, Average: 1441 usec, Peak to peak: 30 usec, Stddev: 15 usec, Sum: 2882 usec
Measurement: Negative round trip jitter
Samples: 3, Minimum: 436 usec, Maximum: 1500 usec, Average: 1129 usec, Peak to peak: 1064 usec, Stddev: 490 usec, Sum: 3386 usec
Results over all tests:
Probes sent: 981160, Probes received: 980587, Loss percentage: 0.058400
Measurement: Round trip time
Samples: 980587, Minimum: 9317 usec, Maximum: 994921 usec, Average: 14290 usec, Peak to peak: 985604 usec, Stddev: 10607 usec, Sum: 14012472325 usec
Measurement: Positive round trip jitter
Samples: 491354, Minimum: 0 usec, Maximum: 983440 usec, Average: 4496 usec, Peak to peak: 983440 usec, Stddev: 11249 usec, Sum: 2209222966 usec
Measurement: Negative round trip jitter
Samples: 489232, Minimum: 1 usec, Maximum: 983726 usec, Average: 4516 usec, Peak to peak: 983725 usec, Stddev: 11274 usec, Sum: 2209221859 usec
[/cc]

А какой с этого прок?

IP SLA хорош тем, что позволяет на основе результатов проб выполнять различные действия – в т.ч. включать или выключать маршруты. В Juniper тоже есть такая функция, называется IP monitoring.
Настраивается вот так:
[cc]
set services rpm probe BRANCH test ICMP-PROBE probe-type icmp-ping
set services rpm probe BRANCH test ICMP-PROBE target address 8.8.8.8
set services rpm probe BRANCH test ICMP-PROBE probe-count 5
set services rpm probe BRANCH test ICMP-PROBE probe-interval 5
set services rpm probe BRANCH test ICMP-PROBE test-interval 5
set services rpm probe BRANCH test ICMP-PROBE thresholds successive-loss 5
set services rpm probe BRANCH test ICMP-PROBE next-hop 192.168.1.1
set services ip-monitoring policy ISP-CHECK match rpm-probe BRANCH
set services ip-monitoring policy ISP-CHECK then preferred-route route 0.0.0.0/0 next-hop 192.168.2.1
[/cc]
Т.е. если группа тестов возвращает fail, то происходит переключение. Как только проба восстанавливается, возвращается и “нормальный” маршрут.

Выглядеть это будет примерно так:
[cc]
root@srx340-01> show services ip-monitoring status

Policy – ISP-CHECK (Status: PASS)
RPM Probes:
Probe name Test Name Address Status
———————- ————— —————- ———
BRANCH ICMP-PROBE 8.8.8.8 PASS
Route-Action:
route-instance route next-hop state
—————– —————– —————- ————-
inet.0 0.0.0.0/0 192.168.2.1 NOT-APPLIED

[/cc]

Посмотреть последние переключения:
[cc]root@srx340-01> show services rpm history-results
Owner, Test Probe received Round trip time
BRANCH, ICMP-PROBE Mon Jan 15 14:30:04 2018 1753 usec
BRANCH, ICMP-PROBE Mon Jan 15 14:30:06 2018 7318 usec
BRANCH, ICMP-PROBE Mon Jan 15 14:30:07 2018 1891 usec
BRANCH, ICMP-PROBE Mon Jan 15 14:30:09 2018 7575 usec
BRANCH, ICMP-PROBE Mon Jan 15 14:30:11 2018 1695 usec
BRANCH, ICMP-PROBE Mon Jan 15 14:30:13 2018 Internal error
BRANCH, ICMP-PROBE Mon Jan 15 14:30:15 2018 Internal error
BRANCH, ICMP-PROBE Mon Jan 15 14:30:18 2018 Internal error
BRANCH, ICMP-PROBE Mon Jan 15 14:30:20 2018 Internal error
BRANCH, ICMP-PROBE Mon Jan 15 14:30:22 2018 Internal error
[/cc]

На этом, собственно, всё. Спасибо за внимание

The post Мониторинг с помощью RPM probe в Juniper appeared first on Логово (а)социальной твари.

А теперь мы попробуем ещё одну связку – Juniper SRX и linux-виртуалку. В качестве ipsec-демона будем использовать Libreswan и Strongswan (кому что больше нравится).

Итак, поехали!

Для начала сконфигурирем наш SRX. Я использую последний доступный софт из ветки 15.1X49: JUNOS 15.1X49-D120.3. Связано это с тем, что связка IKEv2+Traffic selectors не работает на более младшем софте, а без IKEv2 у меня не получилось запустить туннель из-за NAT. Предполагаается, что у SRX есть белый статический адрес.
[cc]
set security ike policy IKE-NIXMAN mode main
set security ike policy IKE-NIXMAN proposals MD5-AES128-2-86400
set security ike policy IKE-NIXMAN pre-shared-key ascii-text “$9$vW38-wgoZk.569RclKx7.Pf5Q369tuBR/CX-b2JZfTzF9pEcyKWXRE87”
set security ike gateway GW-NIXMAN ike-policy IKE-NIXMAN
set security ike gateway GW-NIXMAN address 1.2.3.4
set security ike gateway GW-NIXMAN external-interface ge-0/0/0.0
set security ike gateway GW-NIXMAN version v2-only
set security ipsec vpn VPN-NIXMAN bind-interface st0.1
set security ipsec vpn VPN-NIXMAN ike gateway GW-NIXMAN
set security ipsec vpn VPN-NIXMAN ike ipsec-policy MD5-AES128-3600-2-policy
set security ipsec vpn VPN-NIXMAN traffic-selector TS-01 local-ip 10.0.0.0/8
set security ipsec vpn VPN-NIXMAN traffic-selector TS-01 remote-ip 172.16.43.254/32
set security ipsec vpn VPN-NIXMAN establish-tunnels immediately

set security ike proposal MD5-AES128-2-86400 description ike-phase1-proposal1
set security ike proposal MD5-AES128-2-86400 authentication-method pre-shared-keys
set security ike proposal MD5-AES128-2-86400 dh-group group2
set security ike proposal MD5-AES128-2-86400 authentication-algorithm md5
set security ike proposal MD5-AES128-2-86400 encryption-algorithm aes-128-cbc
set security ike proposal MD5-AES128-2-86400 lifetime-seconds 86400
set security ike policy IKE-NIXMAN proposals MD5-AES128-2-86400

set security ipsec proposal MD5-AES128-3600 description ipsec-phase2-proposal
set security ipsec proposal MD5-AES128-3600 protocol esp
set security ipsec proposal MD5-AES128-3600 authentication-algorithm hmac-md5-96
set security ipsec proposal MD5-AES128-3600 encryption-algorithm aes-128-cbc
set security ipsec proposal MD5-AES128-3600 lifetime-seconds 3600
set security ipsec policy MD5-AES128-3600-2-policy description ipsec-phase2-policy
set security ipsec policy MD5-AES128-3600-2-policy perfect-forward-secrecy keys group2
set security ipsec policy MD5-AES128-3600-2-policy proposals MD5-AES128-3600
[/cc]

Здесь 1.2.3.4 – адрес удалённого пира
10.0.0.0/8 – сеть на нашей стороне
172.16.43.254/32 – сеть на удалённой стороне
Шифрование можно выбрать и посильнее, но тут надо учитывать

Конфигурация удалённого пира (в случае libreswan) будет следующая (/etc/ipsec.d/nixman.conf):
[cc]
conn srx
authby=secret
auto=start
type=tunnel
esp=aes128-md5;modp1024
ike=aes128-md5;modp1024
ikelifetime=86400s
keylife=3600s
rekey=no
dpddelay=30
dpdtimeout=120
dpdaction=clear
fragmentation=yes
ikev2=insist
narrowing=yes
leftid=1.2.3.4
left=172.16.43.254
leftsourceip=172.16.43.254
right=4.3.2.1
leftsubnet=172.16.43.254/32
rightsubnet=10.0.0.0/8
[/cc]

Наша виртуалка располагается за NAT, и имеет адрес 172.16.43.254 (что мы и указываем).
Если бы у нас была виртуалка с честным белым адресом, конфиг выглядел бы чуть-чуть иначе :
[cc]
conn srx
authby=secret
auto=start
type=tunnel
esp=aes128-md5;modp1024
ike=aes128-md5;modp1024
ikelifetime=86400s
keylife=3600s
rekey=no
dpddelay=30
dpdtimeout=120
dpdaction=clear
fragmentation=yes
ikev2=insist
narrowing=yes
left=1.2.3.4
right=4.3.2.1
leftsubnet=172.16.43.254/32
rightsubnet=10.0.0.0/8
[/cc]
В принципе, при этом даже не обязательно использовать ikev2 (я его включил просто по той причине, что с v1 не работал NAT-T).

Файл /etc/ipsec.secrets:
[cc]1.2.3.4 4.3.2.1 : PSK “VeRy$tR0nGp@s$w0rD”[/cc]

А вот так будет выглядеть конфиг для StrongSwan (/etc/ipsec.d/nixman.conf):
[cc]config setup

conn %default
keyexchange = ikev2
authby = psk
keyingtries = %forever
ike = aes128-md5-modp1024!
ikelifetime = 24h
esp = aes128-md5-modp1024!
keylife = 1h
right = 4.3.2.1
dpdaction = restart
closeaction = restart
rightsubnet = 10.0.0.0/8
auto = start

conn ts-01
leftsubnet = 172.16.43.254/32
[/cc]

/etc/ipsec.d/nixman.secret:
[cc]1.2.3.4 : PSK “VeRy$tR0nGp@s$w0rD”
4.3.2.1 : PSK “VeRy$tR0nGp@s$w0rD”[/cc]

При успешном подключении должно быть так:
[cc]
admin@srx340-02> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
7937209 UP 8fb291a33b5bcbb4 742ad541fcbb8f2c IKEv2 1.2.3.4

admin@srx340-02> show security ipsec security-associations
Total active tunnels: 2
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<67108867 ESP:aes-cbc-128/md5 cd9e67ad 3169/ unlim - root 4500 1.2.3.4 >67108867 ESP:aes-cbc-128/md5 e57ed5c1 3169/ unlim – root 4500 1.2.3.4
[/cc]

и вот так (пример для libreswan):
[cc]

root@server:~# ipsec status
000 using kernel interface: netkey
000 interface lo/lo ::1@500
000 interface lo/lo 127.0.0.1@4500
000 interface lo/lo 127.0.0.1@500
000 interface eth0/eth0 172.16.43.254@4500
000 interface eth0/eth0 172.16.43.254@500
000
000
000 fips mode=disabled;
000 SElinux=disabled
000
000 config setup options:
000
000 configdir=/etc, configfile=/etc/ipsec.conf, secrets=/etc/ipsec.secrets, ipsecdir=/etc/ipsec.d, dumpdir=/var/run/pluto/, statsbin=unset
000 sbindir=/usr/sbin, libexecdir=/usr/lib/ipsec
000 pluto_version=3.16, pluto_vendorid=OE-Libreswan-3.16
000 nhelpers=-1, uniqueids=yes, perpeerlog=no, shuntlifetime=900s, xfrmlifetime=300s
000 ddos-cookies-treshold=50000, ddos-max-halfopen=25000, ddos-mode=auto
000 ikeport=500, strictcrlpolicy=no, crlcheckinterval=0, listen=, nflog-all=0
000 secctx-attr-type=
000 myid = (none)
000 debug none
000
000 nat-traversal=yes, keep-alive=20, nat-ikeport=4500
000 virtual-private (%priv):
000 – allowed subnets: 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 25.0.0.0/8, 100.64.0.0/10, fd00::/8, fe80::/10
000
000 ESP algorithms supported:
000
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8, keysizemin=128, keysizemax=128
000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=12, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=16, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm AH/ESP auth: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
000 algorithm AH/ESP auth: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
000 algorithm AH/ESP auth: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
000 algorithm AH/ESP auth: id=6, name=AUTH_ALGORITHM_HMAC_SHA2_384, keysizemin=384, keysizemax=384
000 algorithm AH/ESP auth: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512, keysizemin=512, keysizemax=512
000 algorithm AH/ESP auth: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD, keysizemin=160, keysizemax=160
000 algorithm AH/ESP auth: id=9, name=AUTH_ALGORITHM_AES_XCBC, keysizemin=128, keysizemax=128
000 algorithm AH/ESP auth: id=251, name=AUTH_ALGORITHM_NULL_KAME, keysizemin=0, keysizemax=0
000
000 IKE algorithms supported:
000
000 algorithm IKE encrypt: v1id=0, v1name=0??, v2id=16, v2name=AES_CCM_C, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: v1id=0, v1name=0??, v2id=15, v2name=AES_CCM_B, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: v1id=0, v1name=0??, v2id=14, v2name=AES_CCM_A, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: v1id=5, v1name=OAKLEY_3DES_CBC, v2id=3, v2name=3DES, blocksize=8, keydeflen=192
000 algorithm IKE encrypt: v1id=24, v1name=OAKLEY_CAMELLIA_CTR, v2id=24, v2name=CAMELLIA_CTR, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: v1id=8, v1name=OAKLEY_CAMELLIA_CBC, v2id=23, v2name=CAMELLIA_CBC, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: v1id=20, v1name=OAKLEY_AES_GCM_C, v2id=20, v2name=AES_GCM_C, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: v1id=19, v1name=OAKLEY_AES_GCM_B, v2id=19, v2name=AES_GCM_B, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: v1id=18, v1name=OAKLEY_AES_GCM_A, v2id=18, v2name=AES_GCM_A, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: v1id=13, v1name=OAKLEY_AES_CTR, v2id=13, v2name=AES_CTR, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: v1id=7, v1name=OAKLEY_AES_CBC, v2id=12, v2name=AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: v1id=65004, v1name=OAKLEY_SERPENT_CBC, v2id=65004, v2name=SERPENT_CBC, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: v1id=65005, v1name=OAKLEY_TWOFISH_CBC, v2id=65005, v2name=TWOFISH_CBC, blocksize=16, keydeflen=128
000 algorithm IKE encrypt: v1id=65289, v1name=OAKLEY_TWOFISH_CBC_SSH, v2id=65289, v2name=TWOFISH_CBC_SSH, blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashlen=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashlen=20
000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, hashlen=32
000 algorithm IKE hash: id=5, name=OAKLEY_SHA2_384, hashlen=48
000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashlen=64
000 algorithm IKE hash: id=9, name=DISABLED-OAKLEY_AES_XCBC, hashlen=16
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000 algorithm IKE dh group: id=22, name=OAKLEY_GROUP_DH22, bits=1024
000 algorithm IKE dh group: id=23, name=OAKLEY_GROUP_DH23, bits=2048
000 algorithm IKE dh group: id=24, name=OAKLEY_GROUP_DH24, bits=2048
000
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,201,64} trans={0,201,6144} attrs={0,201,4096}
000
000 Connection list:
000
000 “srx”: 172.16.43.254/32===172.16.43.254<172.16.43.254>[1.2.3.4]…4.3.2.1<4.3.2.1>===10.0.0.0/8; prospective erouted; eroute owner: #0
000 “srx”: oriented; my_ip=unset; their_ip=unset
000 “srx”: xauth info: us:none, them:none, my_xauthuser=[any]; their_xauthuser=[any]
000 “srx”: modecfg info: us:none, them:none, modecfg policy:push, dns1:unset, dns2:unset, domain:unset, banner:unset;
000 “srx”: labeled_ipsec:no;
000 “srx”: policy_label:unset;
000 “srx”: ike_life: 86400s; ipsec_life: 3600s; replay_window: 32; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0;
000 “srx”: retransmit-interval: 500ms; retransmit-timeout: 60s;
000 “srx”: sha2_truncbug:no; initial_contact:no; cisco_unity:no; fake_strongswan:no; send_vendorid:no;
000 “srx”: policy: PSK+ENCRYPT+TUNNEL+PFS+DONT_REKEY+IKEV2_ALLOW+IKEV2_PROPOSE+IKEV2_ALLOW_NARROWING+SAREF_TRACK+IKE_FRAG_ALLOW;
000 “srx”: conn_prio: 32,8; interface: eth0; metric: 0; mtu: unset; sa_prio:auto; nflog-group: unset; mark: unset;
000 “srx”: dpd: action:clear; delay:30; timeout:120; nat-t: force_encaps:no; nat_keepalive:yes; ikev1_natt:both
000 “srx”: newest ISAKMP SA: #0; newest IPsec SA: #0;
000 “srx”: IKE algorithms wanted: AES_CBC(7)_128-MD5(1)_000-MODP1024(2)
000 “srx”: IKE algorithms found: AES_CBC(7)_128-MD5(1)_128-MODP1024(2)
000 “srx”: ESP algorithms wanted: AES(12)_128-MD5(1)_000; pfsgroup=MODP1024(2)
000 “srx”: ESP algorithms loaded: AES(12)_128-MD5(1)_000
000 “srx”[1]: 172.16.43.254<172.16.43.254>[1.2.3.4]…4.3.2.1<4.3.2.1>===10.0.0.0/8; erouted; eroute owner: #398
000 “srx”[1]: oriented; my_ip=unset; their_ip=unset
000 “srx”[1]: xauth info: us:none, them:none, my_xauthuser=[any]; their_xauthuser=[any]
000 “srx”[1]: modecfg info: us:none, them:none, modecfg policy:push, dns1:unset, dns2:unset, domain:unset, banner:unset;
000 “srx”[1]: labeled_ipsec:no;
000 “srx”[1]: policy_label:unset;
000 “srx”[1]: ike_life: 86400s; ipsec_life: 3600s; replay_window: 32; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0;
000 “srx”[1]: retransmit-interval: 500ms; retransmit-timeout: 60s;
000 “srx”[1]: sha2_truncbug:no; initial_contact:no; cisco_unity:no; fake_strongswan:no; send_vendorid:no;
000 “srx”[1]: policy: PSK+ENCRYPT+TUNNEL+PFS+DONT_REKEY+UP+IKEV2_ALLOW+IKEV2_PROPOSE+IKEV2_ALLOW_NARROWING+SAREF_TRACK+IKE_FRAG_ALLOW;
000 “srx”[1]: conn_prio: 32,8; interface: eth0; metric: 0; mtu: unset; sa_prio:auto; nflog-group: unset; mark: unset;
000 “srx”[1]: dpd: action:clear; delay:30; timeout:120; nat-t: force_encaps:no; nat_keepalive:yes; ikev1_natt:both
000 “srx”[1]: newest ISAKMP SA: #397; newest IPsec SA: #398;
000 “srx”[1]: IKE algorithms wanted: AES_CBC(7)_128-MD5(1)_000-MODP1024(2)
000 “srx”[1]: IKE algorithms found: AES_CBC(7)_128-MD5(1)_128-MODP1024(2)
000 “srx”[1]: IKEv2 algorithm newest: AES_CBC_128-AUTH_HMAC_MD5_96-PRF_HMAC_MD5-MODP1024
000 “srx”[1]: ESP algorithms wanted: AES(12)_128-MD5(1)_000; pfsgroup=MODP1024(2)
000 “srx”[1]: ESP algorithms loaded: AES(12)_128-MD5(1)_000
000 “srx”[1]: ESP algorithm newest: AES_128-HMAC_MD5; pfsgroup=MODP1024
000 “v6neighbor-hole-in”: ::/0===::1<::1>:58/34560…%any:58/34816===::/0; prospective erouted; eroute owner: #0
000 “v6neighbor-hole-in”: oriented; my_ip=unset; their_ip=unset
000 “v6neighbor-hole-in”: xauth info: us:none, them:none, my_xauthuser=[any]; their_xauthuser=[any]
000 “v6neighbor-hole-in”: modecfg info: us:none, them:none, modecfg policy:push, dns1:unset, dns2:unset, domain:unset, banner:unset;
000 “v6neighbor-hole-in”: labeled_ipsec:no;
000 “v6neighbor-hole-in”: policy_label:unset;
000 “v6neighbor-hole-in”: ike_life: 0s; ipsec_life: 0s; replay_window: 0; rekey_margin: 0s; rekey_fuzz: 0%; keyingtries: 0;
000 “v6neighbor-hole-in”: retransmit-interval: 0ms; retransmit-timeout: 0s;
000 “v6neighbor-hole-in”: sha2_truncbug:no; initial_contact:no; cisco_unity:no; fake_strongswan:no; send_vendorid:no;
000 “v6neighbor-hole-in”: policy: PFS+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+PASS+NEVER_NEGOTIATE;
000 “v6neighbor-hole-in”: conn_prio: 0,0; interface: lo; metric: 0; mtu: unset; sa_prio:1; nflog-group: unset; mark: unset;
000 “v6neighbor-hole-in”: newest ISAKMP SA: #0; newest IPsec SA: #0;
000 “v6neighbor-hole-out”: ::/0===::1<::1>:58/34816…%any:58/34560===::/0; prospective erouted; eroute owner: #0
000 “v6neighbor-hole-out”: oriented; my_ip=unset; their_ip=unset
000 “v6neighbor-hole-out”: xauth info: us:none, them:none, my_xauthuser=[any]; their_xauthuser=[any]
000 “v6neighbor-hole-out”: modecfg info: us:none, them:none, modecfg policy:push, dns1:unset, dns2:unset, domain:unset, banner:unset;
000 “v6neighbor-hole-out”: labeled_ipsec:no;
000 “v6neighbor-hole-out”: policy_label:unset;
000 “v6neighbor-hole-out”: ike_life: 0s; ipsec_life: 0s; replay_window: 0; rekey_margin: 0s; rekey_fuzz: 0%; keyingtries: 0;
000 “v6neighbor-hole-out”: retransmit-interval: 0ms; retransmit-timeout: 0s;
000 “v6neighbor-hole-out”: sha2_truncbug:no; initial_contact:no; cisco_unity:no; fake_strongswan:no; send_vendorid:no;
000 “v6neighbor-hole-out”: policy: PFS+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+PASS+NEVER_NEGOTIATE;
000 “v6neighbor-hole-out”: conn_prio: 0,0; interface: lo; metric: 0; mtu: unset; sa_prio:1; nflog-group: unset; mark: unset;
000 “v6neighbor-hole-out”: newest ISAKMP SA: #0; newest IPsec SA: #0;
000
000 Total IPsec connections: loaded 4, active 1
000
000 State Information: DDoS cookies not required, Accepting new IKE connections
000 IKE SAs: total(1), half-open(0), open(0), authenticated(1), anonymous(0)
000 IPsec SAs: total(1), authenticated(1), anonymous(0)
000
000 #398: “srx”[1] 4.3.2.1:4500 STATE_PARENT_R2 (received v2I2, PARENT SA established); EVENT_SA_EXPIRE in 2818s; newest IPSEC; eroute owner; isakmp#397; idle; import:respond to stranger
000 #398: “srx”[1] 4.3.2.1 esp.cd9e67ad@4.3.2.1 esp.e57ed5c1@172.16.43.254 tun.0@4.3.2.1 tun.0@172.16.43.254 ref=0 refhim=4294901761 Traffic: ESPin=33KB ESPout=304KB! ESPmax=0B
000 #397: “srx”[1] 4.3.2.1:4500 STATE_PARENT_R2 (received v2I2, PARENT SA established); EVENT_SA_EXPIRE in 85618s; newest ISAKMP; isakmp#0; idle; import:respond to stranger
000 #397: “srx”[1] 4.3.2.1 ref=0 refhim=0 Traffic:
000
000 Bare Shunt list:
000
[/cc]

наконец, проверяем, что пинги ходят в обе стороны (не забудьте про маршруты) и защищённые сети доступны с обеих сторон.

Вот, собственно, всё =)

The post Juniper SRX и Libreswan (и ещё StrongSwan) appeared first on Логово (а)социальной твари.

Однако же, далеко не всегда нужно использовать API. Например, если нужно просто выполнить определённую последовательность действий (пусть и параметризованную), гораздо быстрее, удобнее и надёжнее использовать ansbile (как я уже показал в прошлой статье).

А тут как раз подвернулась задачка – нужно раз в три месяца обновлять сертификаты на нашем микротике, которые мы получаем от let’s encrypt.
Хотите узнать, как? Прошу под кат

Для начала определимся, что у нас уже есть микротик, debian и certbot, через который мы и получаем сертификаты от let’s encrypt. Вместо certbot можно использовать любое другое, удобное для вас решение. Так же подразумевается, что вы уже получили сертификат любым удобным вам образом (например через webroot).

Т.к. нативного модуля для Mikrotik у Ansible нет, то приходится выкручиваться. Один из способов – это выполнение команд на устройстве последовательно через ssh. Можно было бы, конечно, залить rsc-файл и сделать import, но это лишает нас возможности получить хоть какую-то отладочную информацию.
На эту идею меня натолкнул пользователь 0x566164696D, за что ему большое спасибо.

ansible.cfg будет примерно таким:

[defaults]
inventory = inventory
remote_tmp = $HOME/.ansible/tmp
pattern = *
forks = 20
poll_interval = 15
transport = smart
remote_port = 22
roles_path = ./roles
host_key_checking = False
sudo_exe = sudo
timeout = 10
remote_user = hspot_admin
ansible_managed = Ansible managed: {file} modified on %Y-%m-%d %H:%M:%S by {uid} on {host}
action_plugins = /usr/share/ansible_plugins/action_plugins
callback_plugins = /usr/share/ansible_plugins/callback_plugins
connection_plugins = /usr/share/ansible_plugins/connection_plugins
lookup_plugins = /usr/share/ansible_plugins/lookup_plugins
vars_plugins = /usr/share/ansible_plugins/vars_plugins
filter_plugins = /usr/share/ansible_plugins/filter_plugins
etcd_url = 'http://127.0.0.1:4001'
retry_files_save_path = ~/ansible/.ansible-retry

Особое внимание обратите на remote_user (его мы создадим на микротике и roles_path – в этой папке будут лежать наши роли.

Сначала зададим переменные:

rsa_key_file: "ansible_user.key"
mkt_user_name: "hspot_admin"
mkt_user_key: "{{ lookup('file', rsa_key_file) }}"
cert_dir: "/etc/letsencrypt/live/oauth.{{ hspot_domain }}/"
cert_file: cert.pem
key_file: privkey.pem
chain_file: fullchain.pem

в ansible_user.key лежит мой публичный ssh-ключ.

Теперь создадим пользователя и добавим ему ssh-ключ, чтобы ходить на устройство без ввода пароля:

#file=tasks/main.yml
---
- name: Generate random password via pwgen
command: "pwgen -s 19 1"
register: random_passwd

#file=templates/add_ansible_user.rsc.j2
:if ([/user find name={{mkt_user_name}}] ="") do={ :log info "User {{mkt_user_name}} not found... Add it"}
:if ([/user find name={{mkt_user_name}}] ="") do={/file print file=ansible_key.txt; :delay 2; /file set ansible_key.txt contents="{{mkt_user_key}}";}
:if ([/user find name={{mkt_user_name}}] ="") do={/user add name={{mkt_user_name}} group=full password="{{random_passwd.stdout}}"; :delay 2; /user ssh-keys import user={{mkt_user_name}} public-key-file=ansible_key.txt}


Прогоняем плейбук. Если всё отработало штатно, то у нас на микротике будет наш пользователь:

PLAY [all] *********************************************************************

PLAY RECAP *********************************************************************
hotspot : ok=4 changed=4 unreachable=0 failed=0


Теперь, наконец, можно приступить к заливке сертификатов. Роль будет вот такая:

#file=tasks/main.yml
---
- name: Generate .rsc to add certs
template: src=cert_install.rsc.j2 dest=/tmp/{{inventory_hostname}}.rsc

#file=templates/cert_install.rsc.j2
#1. Remove cert file with same common-name (You need to define it below)
/foreach i in=[/certificate find common-name="Let's Encrypt Authority X3"] do {/certificate remove $i}
/foreach i in=[/certificate find common-name="{{hspot_oauth}}"] do {/certificate remove $i}
#2. install new certs (cert.pem, privkey.pem, chain.pem)
/certificate import file={{cert_file}}
/certificate import file={{key_file}}
/certificate import file={{chain_file}}
#3. check www-ssl and hotspot certs (set new cert at www-ssl and hotspot you need to define common-name)
/foreach i in=[/ip hotspot profile find login-by=https] do {/ip hotspot profile set $i ssl-certificate=[/certificate find common-name={{hspot_oauth}}]}
/foreach i in=[/ip service find name=www-ssl] do {/ip service set $i certificate=[/certificate find common-name={{hspot_oauth}}]}


Запускаем наш плейбук:

PLAY [all-mkt] ****************************************************************

PLAY RECAP ********************************************************************
10.0.2.7 : ok=4 changed=2 unreachable=0 failed=0


Если всё ок, то на микротике мы увидим свежие сертификаты.

В этой статье я разобрал довольно простой случай, поле для улучшения обширное, как и для написания других плейбуков, упрощающих работу с микротиками. К сожалению, для ansible ещё нет нативного модуля router-os, поэтому все операции выполняются через shell, что совсем не best way. Но, будем надеяться на лучшее, а пока просто лучше продумывать логику плейбуков, дабы повторный накат ничего не сломал.

Мой форк репо mikroansible можно найти на github. Там же лежат роли, описанные в этой статье.

The post Mikrotik и ansible: устанавливаем сертификаты appeared first on Логово (а)социальной твари.

Качаем, слушаем, пишем в комментарии своё мнение!

Ссылка на сайт
Ссылка на подкаст

The post Подкаст Linkmeup: Сетевики не нужны? appeared first on Логово (а)социальной твари.

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

Мы же остановимся именно на разграничении трафика между тремя сетями – для каждой будет отдельное адресное пространство, интерфейсы и правила фаервола.
Хорошей идеей было бы ограничить гостевую сеть с помощью очередей (queues), но это оставим для следующей статьи.
Приступим?

0. Обновление, установка ntp server

Для начала, нужно установить актуальную версию Router OS (я использую bugfix-ветку, но можно и current) и обновить firmware.
Т.к. микротик в нашей локалке будет ещё и ntp-сервером, установим соответствующий пакет.
В моём случае это следуюшие пакеты

ntp-6.37.5-mipsbe.npk
routeros-mipsbe-6.37.5.npk

С помощью WinBox (или веб-интерфейса) кладём файлы в корень ФС устройства, перезагружаемся.

1. Настройка с нуля

Теперь сбросим конфигурацию, чтобы настроить с нуля. Зачем? Всё просто – настраиваем мы не просто домашний роутер, а роутер для офиса, тем более с претензией на защищённость, и настройки необходимо держать под контролем.
После сброоса конфигурации, подключиться к устройству можно через WinBox и функцию mac-telnet (я надеюсь, как это сделать, вы знаете).

Интерфейсы

#Настройки интерфейсов приведены для роутера RB951
#На вашем роутере настройки интерфейсов могут отличаться
/interface ethernet
set [ find default-name=ether1 ] comment=Internet name=ether1
set [ find default-name=ether2 ] name=ether2
set [ find default-name=ether3 ] master-port=ether2 name=ether3
set [ find default-name=ether4 ] master-port=ether2 name=ether4
set [ find default-name=ether5 ] master-port=ether2 name=ether5

IP, DHCP-сервер

/ip address
add address=192.168.88.1/24 comment="servers" interface=ether2 network=192.168.88.0
/ip pool
add name=guest ranges=192.168.88.10-192.168.88.254
/ip dhcp-server network
add address=192.168.88.0/24 comment="servers" dns-server=192.168.88.1 gateway=192.168.88.1 ntp-server=192.168.88.1
/ip dhcp-server
add address-pool=servers disabled=no interface=ether2 lease-time=3d name=servers


/ip address
add address=192.168.89.1/24 comment="Stuff WiFi" interface=wlan1 network=192.168.89.0
/ip pool
add name=stuff ranges=192.168.89.10-192.168.89.254
/ip dhcp-server network
add address=192.168.89.0/24 comment="stuff wifi" dns-server=192.168.89.1 gateway=192.168.89.1 ntp-server=192.168.89.1
/ip dhcp-server
add address-pool=stuff disabled=no interface=wlan1 lease-time=3d name=stuff


NTP-сервер
/system ntp client
set enabled=yes primary-ntp=95.104.192.10 secondary-ntp=93.180.6.3
/system ntp server
set enabled=yes

5. WiFi (channel, psk)
/interface wireless
#Выставляем режим 2.4GHz b/g/n (у вас, возможно, будет другая модель роутера, например с поддержкой 5GHz-диапазона.
#В таком случае, настройки будут отличаться
#Также, возможно, придётся поменять частоту
set [ find default-name=wlan1 ] band=2ghz-b/g/n comment=hs-ap-default disabled=no distance=indoors frequency=2437 guard-interval=long mode=ap-bridge ssid=Stuff wireless-protocol=802.11
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk group-ciphers=aes-ccm mode=dynamic-keys supplicant-identity=MikroTik unicast-ciphers=aes-ccm wpa2-pre-shared-key=123WiFi321


Задаём пароль админа
[admin@snake-mikrotik] > /user set 0 password=VeRy$tR0nGp@s$

NAT – он у нас будет один на всех
/ip firewall nat
add action=masquerade chain=srcnat comment="NAT Internet" out-interface=ether1 src-address-list=internal-nets dst-address-list=!internal-nets

2. Гостевой wifi (virtual ap, shaping, отдельная сеть)

Т.к. стоит задача изолировать беспроводных клиентов от проводной сети, а их всех вместе – от гостевой, то сетей у нас будет три (можно и больше), с разными правилами доступа для каждой.
Создаем виртуальную точку доступа и security profile
/interface wireless security-profiles
add name=hs-ap-prof-nixman authentication-types=wpa2-psk group-ciphers=aes-ccm mode=dynamic-keys supplicant-identity=MikroTik unicast-ciphers=aes-ccm wpa2-pre-shared-key=WiFiPaSsWoRd
/interface wireless
add master-interface=wlan1 mode=ap-bridge name=hs-ap-nixman security-profile=hs-ap-prof-nixman ssid="Guest WiFi"

IP, DHCP-сервер

/ip address
add address=192.168.90.1/24 comment="Guest WiFi" interface=hs-ap-nixman network=192.168.90.0 arp=reply-only
/ip pool
add name=guest ranges=192.168.90.10-192.168.90.254
/ip dhcp-server network
add address=192.168.90.0/24 comment="guest wifi" dns-server=8.8.8.8 gateway=192.168.90.1
/ip dhcp-server
add address-pool=guest disabled=no interface=hs-ap-nixman lease-time=1h name=guest add-arp=yes


3. Защищаем роутер

Отключаем ненужные службы.
/ip service
set telnet disabled=yes
set ftp disabled=yes
set api disabled=yes
set api-ssl disabled=yes
Для нужных – меняем порты (либо ограничиваем доступ только списком администраторов – см. правила фаервола ниже)
/ip service
set www port=8080
set ssh port=2222

Теперь настраиваем фаервол. Я воспользовался правилами от Грега, только немного изменив “под себя”. У вас, вполне вероятно, получится что-то своё.

/ip firewall address-list
#rfc 1918, loopback, мультикаст и прочие bogon networks
add address=0.0.0.0/8 comment="" disabled=no list=rfc-1918
add address=127.0.0.0/8 comment="" disabled=no list=rfc-1918
add address=100.64.0.0/10 comment="" disabled=no list=rfc-1918
add address=10.0.0.0/8 comment="" disabled=no list=rfc-1918
add address=169.254.0.0/16 comment="" disabled=no list=rfc-1918
add address=172.16.0.0/12 comment="" disabled=no list=rfc-1918
add address=192.0.0.0/24 comment="" disabled=no list=rfc-1918
add address=192.0.2.0/24 comment="" disabled=no list=rfc-1918
add address=192.168.0.0/16 comment="" disabled=no list=rfc-1918
add address=198.18.0.0/15 comment="" disabled=no list=rfc-1918
add address=198.51.100.0/24 comment="" disabled=no list=rfc-1918
add address=203.0.113.0/24 comment="" disabled=no list=rfc-1918
add address=224.0.0.0/3 comment="" disabled=no list=rfc-1918

#Запрещаем несанкционированную активность
add action=drop chain=forward comment="block disallowed forward" disabled=no
add action=drop chain=input comment="block inbound traffic from everyone else" disabled=no


Теперь настраиваем NAT. Помимо обычного маскарадинга (его мы настроили выше) нам еще нужно сделать проброс портов к нашему почтовому серверу в DMZ.
/ip firewall nat
add action=dst-nat chain=dstnat comment="HTTPS" dst-address-list=public-add dst-port=443 protocol=tcp to-addresses=192.168.88.5 to-ports=443
add action=dst-nat chain=dstnat comment="HTTP" dst-address-list=public-add dst-port=80 protocol=tcp to-addresses=192.168.88.5 to-ports=80
add action=dst-nat chain=dstnat comment="Mail" dst-address-list=public-add dst-port=25 protocol=tcp to-addresses=192.168.88.5 to-ports=25
add action=dst-nat chain=dstnat comment="Mail" dst-address-list=public-add dst-port=465 protocol=tcp to-addresses=192.168.88.5 to-ports=465
add action=dst-nat chain=dstnat comment="Mail" dst-address-list=public-add dst-port=587 protocol=tcp to-addresses=192.168.88.5 to-ports=587
add action=dst-nat chain=dstnat comment="Mail" dst-address-list=public-add dst-port=995 protocol=tcp to-addresses=192.168.88.5 to-ports=995

В заключение – отключаем mac-telnet и neighbor discovery. При желании можете оставить для проводной сети, но только если вы твёрдо уверены, что вам оно нужно.
/ip neighbor discovery settings set default=n default-for-dynamic=no

[admin@snake-mikrotik] > /tool mac-server mac-winbox print
Flags: X - disabled, * - default
# INTERFACE
0 X* all
1 ether2-master-local
2 ether3-slave-local
3 ether4-slave-local
4 ether5-slave-local
5 wlan1
6 bridge-local
[admin@snake-mikrotik] > /tool mac-server mac-winbox set 1,2,3,4,5,6 disabled=y

[admin@snake-mikrotik] > /tool mac-server print
Flags: X - disabled, * - default
# INTERFACE
0 X* all
1 ether2-master-local
2 ether3-slave-local
3 ether4-slave-local
4 ether5-slave-local
5 wlan1
6 bridge-local
[admin@snake-mikrotik] > /tool mac-server set 1,2,3,4,5,6 disabled=y
На этом всё. Надеюсь, руководство окажется для вас полезным.

The post Mikrotik для небольшого офиса appeared first on Логово (а)социальной твари.

Диспозиция: dedicated-сервер с одним диском, загруженный с rescue CD. Задача: сделать lvm, разметить диск нужным нам образом и поставить чистую операционку (Debian Jessie).

Шаг 1. Собираем lvm

Размечаем диск. Не забываем установить правильный partition type и загрузочный флаг.

Command (m for help): p
Disk /dev/sda: 1,8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x472be2a1

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 526335 524288 256M 83 Linux
/dev/sda2 526336 3907029167 3906502832 1,8T 8e Linux LVM


Создаём lvm
pvcreate /dev/sda2
vgcreate vgstorage /dev/sda2
lvcreate -L20G -n lvroot vgstorage
lvcreate -L20G -n lvvar vgstorage
lvcreate -L1G -n lvswap vgstorage
lvcreate -l100%FREE -n lvhome vgstorage
vgchange -a y vgstorage


Создаем файловые системы.
mkfs.ext2 /dev/sda1
mkfs.ext4 /dev/vgstorage/lvroot
mkfs.ext4 /dev/vgstorage/lvvar
mkfs.ext4 /dev/vgstorage/lvhome


Шаг 2. Ставим систему

Пишем скрипт, который поставит нам систему. Я воспользовался скриптами уважаемго @derlaft, за что ему большое спасибо, и немного изменил их под себя.
Скрипт можно положить, например, в /root

install.sh

#!/bin/bash

## строчки ниже трогать не нужно, они монтируют системные директории в новый /
mount -o bind /dev $TARGET/dev
mount -o bind /sys $TARGET/sys


Создаем окружение для установки системы
mkdir /mnt/debian
mkdir /mnt/debian/boot
mkdir /mnt/debian/home
mkdir /mnt/debian/var
mount /dev/vgstorage/lvroot /mnt/debian
mount /dev/sda1 /mnt/debian/boot
mount /dev/vgstorage/lvvar /mnt/debian/var
mount /dev/vgstorage/lvhome /mnt/debian/home


Теперь просто запускаем скрипт:
bash ./install.sh


Система скачана и установлена. Теперь делаем ещё один скрипт, который поставит нам ядро, загрузчик и некоторые доп. пакеты.
Его можно сразу поместить в $TARGET, чтобы было удобнее запускать из chroot

postinst.sh

#!/bin/bash
## обновление индекса репозитария
apt-get update
## настройка часовых поясов
dpkg-reconfigure tzdata
## монтирование файловых систем
mount -t proc /proc /proc
mount -a

## Завершающий этап - установка загрузчика:
grub-install /dev/sda
update-grub


Запускается скрипт командой:
env LANG=C env HOME=/root chroot $TARGET /bin/bash /postinst.sh

Осталось немного:
Добавляем информацию в /etc/fstab

/dev/sda1 /boot ext2 defaults 0 0
/dev/mapper/vgstorage-lvroot / ext4 errors=remount-ro,relatime 0 1
/dev/mapper/vgstorage-lvhome /home ext4 defaults ,relatime 0 2
/dev/mapper/vgstorage-lvvar /var ext4 defaults 0 0
/dev/mapper/vgstorage-lvswap none swap sw 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts defaults 0 0

Настраиваем сеть (в простейшем случае это будет dhcp, однако, бывает всякое)
/etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

Наконец, настраиваем /etc/apt/sources.list

deb http://deb.debian.org/debian stable main

# jessie-backports
deb http://deb.debian.org/debian/ jessie-backports main contrib non-free
deb-src http://deb.debian.org/debian/ jessie-backports main contrib non-free


Выходим из chroot, перезагружаемся. После ребута нас должна встретить свежеустановленная система

Пост на хабре, который был источником вдохновения

The post Yet another debootstrap manual appeared first on Логово (а)социальной твари.