FreeBSD
L2TP+IPSec
Решил наконец-то разобраться с этой мутной доселе темой — IPSec. И в частности — с её реализацией на FreeBSD.
Если не вдаваться в кровавые подробности, то в общих чертах дело обстоит так: L2TP настраивается как обычно, абсолютно без какой-либо оглядки на то, что должен быть ещё и IPSec. Я это делаю обычно на mpd5, путём небольшой правки дефолтного конфига, который идёт с mpd.
IPSec в данном случае логически представляет собой некую надстройку, в которой нужно указать, что «трафик, идущий с такого-то IP на такой-то по таким-то портам и такого-то протокола — требует шифрования (это так называемый „транспортный режим“ работы IPSec). В случае с L2TP эти параметры выставляются так: трафик с любого IP и любого порта, идущий на IP-адрес сервера и порт 1701 (стандартный порт L2TP) по протоколу UDP, потребно шифровать.
Во фре IPSec реализуется с помощью пакета ipsec-tools (он же racoon).
После установки ipsec-tools потребуются следующие модификации в /etc/rc.conf:
...
ipsec_program="/sbin/setkey"
ipsec_file="/usr/local/etc/racoon/setkey.conf"
racoon_enable="YES"
racoon_flags="-l /var/log/racoon.log"
...
Далее идут конфиги самого racoon и утилиты setkey, а также список pre-shared key по-клиентно:
flush;
spdflush; spdadd 0.0.0.0/0[any] 192.168.2.2[1701] udp -P in ipsec esp/transport//require;
spdadd 192.168.2.2[1701] 0.0.0.0/0[any] udp -P out ipsec esp/transport//require;
path pre_shared_key "/usr/local/etc/racoon/psk.txt";
log debug;
listen
{
isakmp 192.168.2.2 [500];
isakmp_natt 192.168.2.2 [4500];
strict_address;
}
remote anonymous
{
exchange_mode main;
passive on;
proposal_check obey;
support_proxy on;
nat_traversal off;
ike_frag on;
dpd_delay 20;
proposal
{
encryption_algorithm aes;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}
proposal
{
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}
}
sainfo anonymous
{
encryption_algorithm aes,3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
pfs_group modp1024;
}
192.168.2.4 Password
192.168.2.5 Password1
192.168.1.4 Password2
Клиентом выступает маршрутизатор 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-сервера.
Часовой пояс во FreeBSD
Запилил тут на Амазоне сервер на фре, и возник вопрос — а как выставить часовой пояс? Раньше как-то на этапе установки системы в инсталляторе выставлял, и всё. И поэтому не в курсе, как это физически реализуется. Оказывается, нужно выбрать файл со своим часовым поясом в /usr/share/zoneinfo и скопировать его в /etc. То есть, для Москвы нужно выполнить команду:
# cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime
Минимальное ядро и загрузка с ZFS
Попытался тут оторвать все модули и жёстко впаять необходимое в ядро. Система грузится с 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:
Пересобираем ядро, ставим, перезагружаемся — и всё взлетает нормально.
Удалённое выполнение команд по ssh
В свете полученных знаний из ссылок в предыдущем посте решил начать жить по-новому. А именно — бэкапные файлы с фри на фрю складывать не по SMB или FTP, как раньше, а по scp или ssh. Подумал, и решил, что удобнее будет через ssh — туда загоняется поток через pipe, а на удалённой стороне из pipe складывается в локальнный (для удалённого сервера-хранилища бэкапов) файл. Проверил даже скорость — в конкретной сети гиговый файл через SMB скопировался за 1 минуту 48 секунд, а то же самое, но через ssh — за 1 минуту 35 секунд. Профит налицо :-)
Запустил mcedit и начал ваять. Со скриптом бэкапа системы проблем не возникло:
#!/bin/sh
backup_dir="/home/backup_operator/backups/os/buhserver-ttr"
keyfile="/home/gateway/service/keyfile.ppk"
username="backup_operator@backup-ttr"
DATE=`date +%Y.%m.%d`
dump -0 -L -u -C 32 -f — / | gzip -5 | ssh -q -i ${keyfile} ${username} "cat > ${backup_dir}/${DATE}_root.dump.gz"
dump -0 -L -u -C 32 -f — /usr | gzip -5 | ssh -q -i ${keyfile} ${username} "cat > ${backup_dir}/${DATE}_usr.dump.gz"
dump -0 -L -u -C 32 -f — /var | gzip -5 | ssh -q -i ${keyfile} ${username} "cat > ${backup_dir}/${DATE}_var.dump.gz"
dump -0 -L -u -C 32 -f — /home | gzip -5 | ssh -q -i ${keyfile} ${username} "cat > ${backup_dir}/${DATE}_home.dump."
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 и так далее. Тут-то и началось самое интересное.
Сначала решил сделать как-нибудь так:
do
ssh -q -i ${keyfile} ${username} "mv ${i} ${i}.bak"
done
Но это получается 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 tips&tricks
Обнаружил тут ряд интересных статей про использование 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
Ребилд RAID-5
Внезапно сервак стал жаловаться на здоровье, а именно — на то, что по данным SMART одного из дисков, стало этому диску плохеть. Диск у нас этот трудится в HP Proliant DL380 G5, в RAID-5, собранном на контроллере Compaq SmartArray P400.
Ну, винты на замену были, но диск пока вроде работает. Решили подоткнуть новый диск и пометить его как hot spare, на случай если диск из массива самозапилится, то будет подхвачен новый HS-диск. Диск подоткнули, но вот с hot spare получился облом — оказывается, этот контроллер умеет в массив вставлять HS только в момент создания. А в уже существующий массив — нет.
Так что надо менять диск. Я старательно всё забэкапил, тщательно прицелился, из какого отсека диск вынимать, запалил там лампочку-индикатор, и товарищ, находящийся на месте, диск заменил. Всё вроде понялось, спросило у меня «тут это, новый диск. Будем ребилдить массив?» Я грю — конечно, бро, надо ребилдить! И процесс пошёл. Поскольку на сервере стоит FreeBSD, а там особо никаких утилит нет, позволяющих получить кровавые подробности о состоянии массива, то удовольствоваться пришлось командой:
<COMPAQ RAID 5 VOLUME reco> at scbus0 target 0 lun 0 (da0,pass0)
<TEAC DV-W28E-RW G.B1> at scbus2 target 0 lun 0 (pass1,cd0)
Я так полагаю, что VOLUME reco должно индицировать, что volume recovering. Ну, сидим курим, ждём окончания ребилда. Час, два ждём... И тут кончается рабочий день.
В общем, на следующий день к часу дня статус массива так и не изменился. Тут-то я и насторожился. И обратился к коллективному разуму с вопросом — а нормально ли это, для 150-гигового винта в RAID-5 такое время ребилда? Коллективный разум однозначно решил, что ненормально, но посоветовал использовать утилиту sysutils/cciss_vol_status, каковую я немедленно и проинсталлировал. Утилита английским по белому сказала:
Controller: Smart Array P400
Board ID: 0x3234103c
Logical drives: 1
Running firmware: 7.18
ROM firmware: 7.18
/dev/ciss0: (Smart Array P400) RAID 5 Volume 0 status: OK.
Physical drives: 7
connector 1I box 1 bay 7 HP DG146BABCF BS05P8708AUE0827 HPD6 OK
connector 1I box 1 bay 6 HP DG146ABAB4 3NM14RAG00009821Q0QZ HPDD OK
connector 1I box 1 bay 5 HP DG146BABCF BS05P86088T90827 HPD6 OK
connector 2I box 1 bay 4 HP DG146BABCF BS05P8608A890827 HPD6 OK
connector 2I box 1 bay 3 HP DG146BABCF BS05P8607UYT0826 HPD6 OK
connector 2I box 1 bay 2 HP DG146ABAB4 3NM15CQ500009822WG3Q HPDA OK
connector 2I box 1 bay 1 HP DG146BABCF BS05P8607V070826 HPD6 OK
То есть, она считает, что массив уже вполне ОК. Но это расходится с показаниями 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 2.0
При обновлении системы и и всего софта до распоследних версий столкнулся с тем, что в 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), который проблему вроде как решает. Возможно, там какие-то косяки потом всплывут, но бегло пощёлкав по страничкам фронтэнда, ничего такого не выявилось.
Хранение серверных конфигов в SVN
Настраивал хранение 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 на файлы. А то западло получается...
MikroTik и OpenVPN
Есть у нас в офесе 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 — так раза в полтора.