Choose your future

Довелось попробовать настроить IPSec в туннельном режиме под FreeBSD в «новом стиле», с созданием системного интерфейса ipsec0 со всеми причиндалами, включая MTU, чего раньше очень не хватало при настройке туннеля в «традиционном» стиле одними политиками IPSec, без туннельного интерфейса.

Удалённый пир нам не подконтролен (головная контора), требует согласования туннеля через IKEv2, не выдаёт дополнительных адресов на туннель.

Сначала поставил strongswan-5.8.2_1 из портов и настроил его через новомодный vici-интерфейс. Создал файл с произвольным именем и расширением .conf:

# cat /usr/local/etc/swanctl/conf.d/hq.conf
connections {
  hq {
    version             = 2
    pull                = no
    mobike              = no
    send_certreq        = no
    dpd_delay           = 5
    keyingtries         = 0

    local_addrs         = 1.1.1.1
    local_port          = 500
    remote_addrs        = 2.2.2.2
    remote_port         = 500

    proposals           = aes256-sha256-modp2048
    reauth_time         = 28800

    local {
      auth              = psk
      id                = 1.1.1.1
    }

    remote {
    }

    children {
      net-net {
        mode            = tunnel
        dpd_action      = restart
        ipcomp          = yes
        copy_df         = no
        start_action    = start
        stop_action     = start
        reqid           = 100
        # policies        = no

        local_ts        = 192.168.18.0/24
        remote_ts       = 10.0.0.0/8,192.168.21.0/24

        esp_proposals   = aes256-sha256-modp2048
      }
    }
  }
}

secrets {
  ike-hq {
    id-hq       = 1.1.1.1
    secret      = XXX
  }
}
#EOF

В этом виде после запуска strongswan согласует IPSec в туннельном режиме, но системный интерфейс ipsec0 не используется и strongswan сам инсталлирует в ядро и политики SPD, и маршруты до удалённых сетей в таблицу маршрутизации. Туннель, тем не менее, работает.

Чтобы теперь добавить в картинку p2p-интерфейс ipsec0, добавляем в /usr/local/etc/strongswan.d/charon.conf команду "install_routes = no" внутрь блока charon {}, так что strongswan перестаёт сам добавлять маршруты до сетей 10.0.0.0/8,192.168.21.0/24 через внешний интерфейс (WAN) и раскомментируем "policies = no" в hq.conf (см. выше), чтобы strongswan не добавлял SPD в ядро, их ядро само создаёт при использовании route-based IPSec-туннеля.

Остальные настройки в /etc/rc.conf по такому типу:

cloned_interfaces="ipsec0"
ifconfig_ipsec0="tunnel 1.1.1.1 2.2.2.2 reqid 100 mtu 1460 up"
static_routes="hq1 hq2"
route_hq1="10.0.0.0/8 -iface ipsec0"
route_hq2="192.168.21.0/24 -iface ipsec0"

strongswan_enable="YES"
strongswan_interface="vici"

Индекс 100 после слова reqid должен быть одинаковым в настройках одного и того же туннеля в rc.conf и в конфигурации strongswan, а если есть ещё туннели, то отличаться для разных туннелей.

Update: Добавил keyingtries = 0 (см. выше), так как оказалось, что без этого при запуске strongswan делает 5 переповторов при попытке подключиться к пиру и если он в это время недоступен, прекращает дальшейшие попытки. Нулевое значение заставляет его делать бесконечное число повторов (каждый с 5 переповторами). Кроме того, в /usr/local/etc/strongswan.d/charon.conf полезно прописать make_before_break = yes и retransmit_base = 1 - последнее для того, чтобы сильно ускорить восстановление туннеля после временных обрывов из-за перезагрузки пира или просто аварии по трассе до него.

Update 2: добавил close_action = start, без этого strongswan может бросить попытки восстановить работу туннеля при обрыве.

Довелось поэкспериментировать с компрессией и шифрованием данных на системном уровне в FreeBSD 9/i386. Шифрование делал через GELI, компрессию через ZFS. Обнаружил забавное. В моём случае контейнер для GELI расположен на медленной сетевой шаре (CIFS over 100Mbit/s & mtu=1500) и для уменьшения дополнительных тормозов от "read-modify-write" поигрался с размерами блоков.

И geli init позволяет задать "размер сектора" в создаваемом GEOM, и ZFS позволяет задать размер блока (recordsize). Оказалось, что даже при отлично сжимаемых данных и включенной компрессии ZFS реально ничего не жмет, если размер сектора и recordsize одинаково равны 4096: zfs get compressratio всегда показывает 1.00 и всё работает довольно медленно, упираясь в сеть.

При том же размере сектора в 4k увеличение recordsize до 8k позволяет ZFS достичь compressratio до 2.0 и операции на хорошо жмущихся данных заметно ускоряются. Если при recordsize=8k уменьшить размер сектора до 512 байт, то на тех же данных степень компрессии взлетает до 16.0 и скорость обработки хорошо жмущихся данных, соответственно, взлетает в разы. Например, показания benchmarks/bonnie, который оперирует как раз такими данными, хорошо демонстрируют эффект.

Маленький "размер сектора" контейнера GELI не слишком хорош по разным причинам: и относительные накладные расходы на собственно шифрование возрастают, и совсем мелкие обмены шифрованными данными по сети через CIFS генерируют относительно высокие накладные расходы в TCP. Поэтому "размер сектора" GELI-контейнера увеличил обратно до размера страницы памяти 4k и выставил ZFS recordsize в 8k - при этом на моих характерных данных коэффициент сжатия получается около 1.85.

Это лишь первая серия тестов и, может быть, в итоге - и для других наборов данных - параметры придется поменять.

dir="/mnt/cifs"
size="100g"
poolopts="-O recordsize=8k -O atime=off -O compression=gzip-9 -o failmode=continue"
truncate -s $size $dir/backend
md=$(mdconfig -af $dir/backend)
geli init -s 4096 /dev/$md
geli attach /dev/$md
zpool create $poolopts es /dev/$md.eli


Оказалось, что немецкий хостер-лоукостер Hetzner в порядке защиты своей инфраструктуры от атак режет, в частности, входящие фрагментированные пакеты UDP, что в современном интернете частично ломает DNS-сервис. Проблема актуальна только тем, кто держит собственные DNS-серверы на физических или виртуальных серверах в Hetzner.

Детально проблема расписана в базе знаний ISC (наш случай - пункт 4. DNS queries/responses using EDNS are allowed, but UDP fragmentation and reassembly is broken), но решение достаточно простое - настроить свой DNS-сервер сообщать другим серверам не посылать требующие фрагментации ответы. Этакий аналог TCP adjust mss, но для DNS через UDP. Более крупные ответы будут доставляться сразу по TCP вместо UDP.

Для сервера BIND достаточно прописать в секции options:

options {
  edns-udp-size 1432;
}

В продолжение темы.

После того, как Глеб исправил несколько проблем в ядре FreeBSD, нагруженные роутеры с mpd5/PPPoE у меня работают стабильно. Однако, где-то раз в год всё-таки на каком-нибудь из них нет-нет, да и произойдет паника и все следы ведут в dummynet. Но раньше по разным причинам не удавалось сохранить одновременно крешдамп и отладочное ядро, а сегодня-таки удалось.

По итогам предварительного разбирательства найдено подозрительное место в коде dummynet и оформлен PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195102

Судя по коду, проблема общая и для 9.x, 10.x и CURRENT - это место практически неизменно во всех ветках. Теперь главное, чтобы PR не завис незамеченным на годы.

( только для сетевиков )