Решил наконец-то разобраться с этой мутной доселе темой — IPSec. И в частности — с её реализацией на FreeBSD.

Если не вдаваться в кровавые подробности, то в общих чертах дело обстоит так: L2TP настраивается как обычно, абсолютно без какой-либо оглядки на то, что должен быть ещё и IPSec. Я это делаю обычно на mpd5, путём небольшой правки дефолтного конфига, который идёт с mpd.

IPSec в данном случае логически представляет собой некую надстройку, в которой нужно указать, что «трафик, идущий с такого-то IP на такой-то по таким-то портам и такого-то протокола — требует шифрования (это так называемый „транспортный режим“ работы IPSec). В случае с L2TP эти параметры выставляются так: трафик с любого IP и любого порта, идущий на IP-адрес сервера и порт 1701 (стандартный порт L2TP) по протоколу UDP, потребно шифровать.

Во фре IPSec реализуется с помощью пакета ipsec-tools (он же racoon).

После установки ipsec-tools потребуются следующие модификации в /etc/rc.conf:

Далее идут конфиги самого racoon и утилиты setkey, а также список pre-shared key по-клиентно:

Клиентом выступает маршрутизатор Mikrotik. Там схема та же — настраивается как обычно L2TP-клиент, а затем топаем в раздел IP ==> IPSec и добавляем записи на вкладке Peers и Policies. Вкладка Peers:

Собственно, здесь я изменил только поля Address (в нём указываем IP VPN-сервера) и Secret (это и есть pre-shared key), а также поле Hash algorithm (по дефолту стоял md5). Остальные поля оставил как есть.

И добавляем запись в разделе Policies:

«Как вы понимаете из названия» (с), поля Src. address и SA src. address — это IP-адрес клиента, а Dst. address и SA dst. address — это адрес VPN-сервера.

Запилил тут на Амазоне сервер на фре, и возник вопрос — а как выставить часовой пояс? Раньше как-то на этапе установки системы в инсталляторе выставлял, и всё. И поэтому не в курсе, как это физически реализуется. Оказывается, нужно выбрать файл со своим часовым поясом в /usr/share/zoneinfo и скопировать его в /etc. То есть, для Москвы нужно выполнить команду:

# cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Попытался тут оторвать все модули и жёстко впаять необходимое в ядро. Система грузится с ZFS, а также используется AIO для самбы, ибо сильно увеличивает скорость работы самбовых шар. Проверил как-то ради шутки — без AIO гиговый файл копировался 9 минут 10 секунд, с включенным AIO — 1 минуту 45 секунд. Разница примерно 6 раз.

В общем, пока (на момент версии FreeBSD 9.2) выясняется, что zfs.ko и opensolaris.ko в ядро не включить, можно только модулями ядра грузить. Добавил в ядро только AIO:

И прописал в make.conf:

Собрал ядро, установил, попытался перезагрузиться и получил облом. При загрузке система стала утверждать, что не знает, откуда смонтировать root. Оказывается, нужен ещё модуль krpc.ko, отвечающий за реализацию RPC в солярке (откуда и портирована ZFS). Причём судя по обрывочным сведениям, нужен он только на 64-битной фре, на 32-битной вроде как нет. Проверять, честно говоря, влом :-)

Правим make.conf:

Пересобираем ядро, ставим, перезагружаемся — и всё взлетает нормально.

В свете полученных знаний из ссылок в предыдущем посте решил начать жить по-новому. А именно — бэкапные файлы с фри на фрю складывать не по SMB или FTP, как раньше, а по scp или ssh. Подумал, и решил, что удобнее будет через ssh — туда загоняется поток через pipe, а на удалённой стороне из pipe складывается в локальнный (для удалённого сервера-хранилища бэкапов) файл. Проверил даже скорость — в конкретной сети гиговый файл через SMB скопировался за  1 минуту 48 секунд, а то же самое, но через ssh — за 1 минуту 35 секунд. Профит налицо :-)

Запустил mcedit и начал ваять. Со скриптом бэкапа системы проблем не возникло:

keyfile — это private key для авторизации на удалённом сервере, backup_operator — имя пользователя на том сервере, а backup-ttr — имя самого сервера, где у нас бэкапы хранятся. Получается следующее — dump дампит раздел в stdout, откуда это перегоняется в gzip через pipe, откуда перегоняется вот в эту конструкцию:

Т. е. мы подключаемся к серверу backup-ttr, и выполняем там команду "cat > {backup_dir}/${DATE}_root.dump.gz". Которая читает из stdin сжатый gzip'ом и прокинутый по сети поток и сохраняет его в файл {backup_dir}/${DATE}_root.dump.gz.

В общем, тут всё просто. А вот с бэкапом почты пришлось повозиться. Было принято решение не просто каждый день сваливать полный бэкап почтовой базы и удалять старые копии, а сделать инкрементный бэкап. А для этого нужно производить определённые манипуляции на стороне хранилища бэкапов. Можно, конечно, сделать второй скрипт, и запускать его по крону на стороне хранилища. Но «Шурик, это же не наш метод!». Это придётся контролировать две точки выполнения одной операции — бэкапа почты, так как задействованы будут два скрипта, два крона, два компа и т. д.

Суть задачи такова. Допустим, у нас в день 1 выполняется полный бэкап почтовой базы. В день 2 — только то, что изменилось или добавилось со времени исполнения 1-го бэкапа, отработавшего в день 1. В день 3 — только изменения с момента бэкапа в день 2, и так далее до конца недели. Допустим, за первую неделю у нас сделано 7 архивов, с именами, соответственно, mail1.tgz, mail2.tgz, ... mail7.tgz. Где mail1.tgz — это полная копия базы, а остальные — дельты изменений. Неделя закончилась, надо как-то сделать ротацию бэкапов. То есть, куда-то деть эти 7 архивов. Можно их тупо удалить. Но как-то хочется, чтобы у нас хотя бы двухнедельная история бэкапов хранилась. Самое простое — эти архивы переименовать. Например, по схеме mail1.tgz.bak, mail2.tgz.bak и так далее. Тут-то и началось самое интересное.

Сначала решил сделать как-нибудь так:

Но это получается 1 вызов ssh для получения списка файлов, и потом ещё в цикле 7 раз запускается ssh, чтобы переименовать каждый отдельный файл. Касичок кагбэ, неоптимальненко.

Камрады в интернете посоветовали сделать как-нибудь так:

Я попробовал, не прокатило. Полез искать точный синтаксис однострочного оформления циклов в shell. Нашёл несколько примеров, подставил, но ни один не прокатил. Я так понял, что приведённые примеры — в основном для линуксового bash, а у меня фрёвая /bin/sh, поэтому и не прокатывает. Потом нашёл обрывочные сведения, что циклы типа for, foreach, while — «is not single-line friendly». Но коллективный разум мне сурово возразил, что я не прав.

Копаясь дальше, я обнаружил, что реально, однострочные конструкции типа

работают, будучи запущены в /bin/sh и локально. Но не работают удалённо. Потом до меня дошло, что локально-то я запустил /bin/sh, и в ней пускаю все эти конструкции. Но по дефолту у пользователя backup_operator оболочка прописана /bin/csh, и синтаксис там может отличаться.

Не вопрос, топаем на удалённый сервер и делаем там:

Меняем, иными словами, ему оболочку на sh вместо csh. После этого конструкция

просто обязана была заработать. Но не заработала... А написала, что f: Undefined variable.

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

The shell will expand variables in double-quotes, but not in single-quotes.

что если команду для удалённого исполнения заключать в двойные кавычки, то оболочка подставляет значение переменной вместо имени переменной. А в этой ситуации нужно, чтобы имя переменной передавалось как есть на дальнюю сторону, и значение вычислялось и использовалось уже там. Поэтому эту команду нужно заключать в ОДИНАРНЫЕ кавычки. То есть, вот так:

Но есть и другой путь — просто ставить backslash перед символом переменной. То есть, можно сделать вот так:

Мне так пришлось сделать, потому что по итогу потребовалось, чтобы в одной команде были и локальные и удалённые переменные. Т. е. финальная рабочая конструкция выглядит вот так:

Обнаружил тут ряд интересных статей про использование ssh и screen. Оказывается, SSH умеет сильно больше, чем я подозревал.

Про SSH:
http://habrahabr.ru/post/122445/
http://matt.might.net/articles/ssh-hacks/

Про screen:
http://rus-linux.net/kos.php?name=MyLDP/consol/screen.html

Внезапно сервак стал жаловаться на здоровье, а именно — на то, что по данным SMART одного из дисков, стало этому диску плохеть. Диск у нас этот трудится в HP Proliant DL380 G5, в RAID-5, собранном на контроллере Compaq SmartArray P400.

Ну, винты на замену были, но диск пока вроде работает. Решили подоткнуть новый диск и пометить его как hot spare, на случай если диск из массива самозапилится, то будет подхвачен новый HS-диск. Диск подоткнули, но вот с hot spare получился облом — оказывается, этот контроллер умеет в массив вставлять HS только в момент создания. А в уже существующий массив — нет.

Так что надо менять диск. Я старательно всё забэкапил, тщательно прицелился, из какого отсека диск вынимать, запалил там лампочку-индикатор, и товарищ, находящийся на месте, диск заменил. Всё вроде понялось, спросило у меня «тут это, новый диск. Будем ребилдить массив?» Я грю — конечно, бро, надо ребилдить! И процесс пошёл. Поскольку на сервере стоит FreeBSD, а там особо никаких утилит нет, позволяющих получить кровавые подробности о состоянии массива, то удовольствоваться пришлось командой:

Я так полагаю, что VOLUME reco должно индицировать, что volume recovering. Ну, сидим курим, ждём окончания ребилда. Час, два ждём... И тут кончается рабочий день.

В общем, на следующий день к часу дня статус массива так и не изменился. Тут-то я и насторожился. И обратился к коллективному разуму с вопросом — а нормально ли это, для 150-гигового винта в RAID-5 такое время ребилда? Коллективный разум однозначно решил, что ненормально, но посоветовал использовать утилиту sysutils/cciss_vol_status, каковую я немедленно и проинсталлировал. Утилита английским по белому сказала:

То есть, она считает, что массив уже вполне ОК. Но это расходится с показаниями camcontrol. В общем, похоже, camcontrol не перечитал данные с контроллера. Почему-то. Пришлось ему принудительно сделать

Только после этого camcontrol ответил, что

Вот и думай теперь, как ему после этого доверять. Придётся, видимо, в мониторинге переделывать получение данных о состоянии массива с camcontrol на cciss_vol_status :-(

Экспериментирую сейчас со сжатием в zfs. Насоздавал пачку файлов, где-то в районе 100 тысяч штук. И косанул в команде создания, они создались не в том каталоге, в котором планировалось. В итоге нужно перенести 100 тысяч файлов в другой каталог. Команда mv ./xaaa* /storage/mail/ мне отвечает:

/bin/mv: Argument list too long.

Полез копаться, и выяснилось, что оказывается, оболочка раскрывает wildcard *, просто заменяя её на имена подходящих под шаблон файлов и подставляя в реальную команду. В итоге получалось, что командная строка для mv была нефиговой такой длины. В качестве решения предлагали удалять файло через find :-) Я сделал так: find ./ -type f -exec mv {} /storage/mail \;

Хинт: разделить один файл (например, сгенерированный с помощью dd из /dev/urandom) на кучу мелких можно так:

split -b 1024 -a 10 /storage/mail/test.dat

Где «-b 1024» — размер одного файла, а «-a 10» — количество символов в имени минус 1 символ. Т. е. «-а 10» — будет генерировать файлы с именем длиной 11 символов.

И ещё накопал информацию о наличии некоторых проблем при удалении ОЧЕНЬ БОЛЬШОГО количества файлов (порядка нескольких миллионов и более). Там может не помочь даже использование find — всё потихоньку затормаживается и виснет. Внезапно (tm) выясняется, следующее:

При обновлении системы и и всего софта до распоследних версий столкнулся с тем, что в zabbix-frontend при использовании PHP 5.5 появляется в красной рамочке надпись перед каждой таблицей с выборками из базы:

mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead [include/db.inc.php:77]

Думал, что это PHP warning (простительно после вторых суток колупания в конфигах). ПОтом дошло, что не, что-то тут нечисто. Полез искать, нашёл описание баги в багтрекере заббикса. Баг имеет статус unresolved, но там приложен некий патч (от 11.07.2013), который проблему вроде как решает. Возможно, там какие-то косяки потом всплывут, но бегло пощёлкав по страничкам фронтэнда, ничего такого не выявилось.

Настраивал хранение freebsd-шных конфигов в SVN. Обнаружилось небольшое западло. Маааленькое такое. В результате которого если ты закрыл консоль, то больше к серваку не подключишься :-)

Причиной является то, что при операции svn commit после добавления всех конфигов в репозиторий, svn делает меняет права на конфигурационные файлы. В частности, добавляет права на чтение для ssh-ключей хоста сервера. Вот для этих файлов, иными словами: /etc/ssh_host_dsa_key, /etc/ssh_host_rsa_key и /etc/ssh_host_ecdsa_key. После чего система отказывается принимать новые соединения по ssh, мотивируя это тем, что:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/etc/ssh/ssh_host_rsa_key' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /etc/ssh/ssh_host_rsa_key
Could not load host key: /etc/ssh/ssh_host_rsa_key
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/etc/ssh/ssh_host_dsa_key' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /etc/ssh/ssh_host_dsa_key
Could not load host key: /etc/ssh/ssh_host_dsa_key
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/etc/ssh/ssh_host_ecdsa_key' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /etc/ssh/ssh_host_ecdsa_key
Could not load host key: /etc/ssh/ssh_host_ecdsa_key

И если своевременно не принять меры по устранению и недопущению, может получиться казус. Пока ssh-консоль открыта, есть некоторый шанс. Нужно вернуть права на ключи обратно, запретив чтение группе и другим. А в идеале — вернуть вообще все уехавшие права с файлов каталога /etc и всех подкаталогов, так как модификации прав подверглись все файлы.

Сделать это можно, воспользовавшись силой данного нам природой мозга и утилитой freebsd-update. У неё есть параметр IDS, который ревизует систему на предмет соответствия прав, структур каталогов и хэшей системных файлов тем, которые должны быть в системе искаропки. Нам же нужны только права доступа на файлы, а на хэши на текущем историческом этапе чхать. Поэтому делаем раз:

server# freebsd-update IDS | awk '/permissions/{ print $8" "$1 }' | xargs -t -L 1 chmod

Утиля долго думает, сверяется с Большим Братом в интернетах, а затем начинает генерировать отчёт, в котором английском по чёрному написано, на каком файле какие права стоят, а какие должны быть. Аккуратно выкусываем awk'ом строчки со словом permissions, который также извлекает 8 и 1 колонки (это права и имя файла соответственно), а утиля xargs доделывает всё остальное, вызывая chmod и подставляя ему результат работы предыдущего конвейера. В итоге эта команда проходится по всем файлам в каталоге /etc, возвращая им правильные права.

Стоит также отметить, что в /usr/local/etc/, которые я тоже сложил в SVN, права тоже поедут. Но там менее критично всё это, по крайней мере, не приведёт к потере управления удалённым сервером. А в идеале, надо делать отчёт с помощью утилиты mtree по правам доступа всех файлов, а после svn add / svn commit возвращать их с помощью этой же mtree обратно. Потому как после каждого commit'a права на закоммиченные файлы будут приводиться в соответствие с umask. Наверное, в идеале стоит написать какую-то обёртку для svn commit, которая будет затем возвращать права на файлы обратно. Либо пойти по пути asvn и реализовать хранение разрешений для файла в репозитории с помощью properties, а при коммите их перечитывать и делать chmod на файлы. А то западло получается...

Есть у нас в офесе VPN. Точнее, между 40 офесами. По мере роста сети всплыла грабля — некоторые удалённые (и отсталые) провайдеры грешат packet reordering. Что напрочь сносит крышу модулю, ответственному за реализацию MPPC/MPPE в mpd5. Симптомы при этом такие — туннель визуально жив, и по нему спокойно ходят LCP-пакеты, но вот трафик уже не ходит. В логах mpd при этом наличествуют сообщения:

ng_mppc_decompress: too many (4094) packets dropped, disabling node

Если вы такие обнаружили — знайте, это вилы. Надо валить. Потому что не лечится никак. Хотя вот эксперимент показал, что с микротика на микротик такой же канал, с MPPC/MPPE держится нормально. Т. е. микротиковцы в RouterOS этот вопрос решили. Но ни фря, ни линукс в качестве VPN-сервера с packet reordering бороться не умеют. В связи с чем было принято волевое решение проблемных клиентов перевести на OpenVPN. По той же схеме — сервер на FreeBSD, клиенты — микротики RB750.

Спустя некоторое время вдумчивого курения манов и некоторого количества глупых вопросов в ru_root наступило просветление и я принялся ваять конфиги сервера и создавать сертификаты. Создав всё, начал терзать первого проблемного клиента, отключив L2TP-линк на нём и создав клиентский интерфейс OpenVPN. Ну, момент истины, нажимаю «Apply» в настройках openvpn-интерфейса на микротике, и... теряю связь с объектом вообще. А он километров за 600 от меня.

Сначала грешил на то, что забыл убрать галку Add default route у openvpn-интерфейса. Проверил на тестовом роутере — ни фига, по умолчанию эта галка отсутствует. А шо же за ботва? Повторяю процедуру на тестовом роутере, подключившись к нему по локалке, и... теряю связь уже с тестовым роутером. Правда, как-то странно — winbox не отвалился, но списка интерфейсов получить не удаётся, выдаётся ошибка «out of index». Странно. Однако роутер частично подконтролен — его удаётся перезагружать. И если всё сделать очень быстро, то openvpn-интерфейс подняться ещё не успевает, и его можно отключить. Тогда роутер остаётся на связи и можно им рулить.

В общем, практика показала, что в RouterOS, зашитых в наших микротиках (v4.11) есть суровый баг. Который приводит к тому, что при поднятии openvpn-интерфейса у роутера сваливается WAN-интерфейс в несознанку, и тянет за собой что-то ещё. Только проапгрейдившись до версии 5.21 удалось нормально создать связь по OpenVPN с микротиком. И ещё одно западло в микротиках — они не умеют openvpn по UDP, только TCP. Что заметно снижает скорость, по сравнению с L2TP — так раза в полтора.