klink0v (klink0v) wrote,
klink0v
klink0v

Category:

Juniper + IPSec + MTU = баги

Хотите еще багов ждунипера? Их есть у меня. Наступил на очередную пачку. Причём, практически на ровном месте.

Вводные следующие.

Есть IPSec-тоннель с шифрованием AES256GCM. Для семейства шифров со счётчиком Галуа (GCM) не требуется подпись пакета, поэтому при MTU физического линка равному 1500, overhead будет составлять всего 54 байта: 20 на новый IP-заголовок ("обёртка"), 8 на заголовок ESP, 16 на Initialization Vector и 10 на всякую служебную информацию для ESP. Таким образом, MTU для виртуального ST-интерфейса при таком выборе шифра может быть вплоть до 1446 байт.

Ну ок, не подозревая дурного, настраивают примерно так.

... и нихрена не работает. По симптомам, типичная проблема поломки механизма Path MTU Discovery: мелкие пинги бегают, большие теряются, HTTPS не работает.

Лезу проверять. Так и есть. Juniper SRX вот ни разу не удосуживается вернуть Fragmentation Needed (ICMP type=3 code=4) хосту из локальной сети, который пытается послать через тоннель пакетик общей длиной 1500 байт. Ну охренеть. Продолжаю экспериментировать.

Сперва просто убираю директиву "mtu" из настроек ST-интерфейса. Всё работает. Почему? Да он просто начинает втихаря фрагментировать ESP-пакеты, которые потом так же молча собираются с другой стороны. Ну охренеть два раза. Почему тогда в первом случае не стал фрагментировать так же втихаря?

Ладно. Копаюсь дальше. Включаю в настройках "security ipsec vpn" директиву "df-bit copy". Вау, работает! Немного странновато, правда (об этом ниже). Но во всяком случае, Fragmentation Needed уже возвращается. Хотя судя по документации, эта настройка вообще не про то.

Дальше веселее. У меня дома в качестве роутера установлен старенький SRX100H2 с 12-й версией прошивки (свежее для него просто не существует). Там работает всё как надо. То есть я не выставляю никаких "df-bit copy", железко чётко соблюдает MTU и возвращает Fragmentation Needed. А вот Juniper SRX-345 с прошивкой 15.1 ведёт себя вот так вот по-свински. Видать, в новых версиях устранили старые неработающие баги и добавили новых работающих. На более свежих прошивках пока что нет возможности проверить. Хотя, говорят, в офис уже притащили "лабораторный" SRX. Если лапки дойдут, посмотрю как на нём.

Но это только первый баг. Есть ещё и второй.

SRX как-то очень загадочно считает MTU для интерфейса внутри тоннеля. Я выше упоминал, что для таких шифров он должен быть 1446 байт. Сам Juniper же почему-то настаивает на значении 1438 байт. Во всяком сучае, именно столько он присылает в ICMP type 3. Но и это ещё не всё.

Если одновременно включить "df-bit copy" и "mtu 1446", то Juniper в ICMP type 3 присылает уже 1428 байт! Можжевельник, я вот не понял. Если ты типа умнее меня и лучше меня умеешь считать оверхеды, то какого хрена ты меняешь свое мнение после того как я задам MTU на "внутреннем конце" тоннеля? И какого хрена ты выставляешь там своё значение, даже пусть бы моё и якобы неправильное?

В общем, как всегда. Чем дальше, тем страшней. Похоже, софт для этих Juniper-ов пишут не просто индусы, а индусы под кайфом, за которыми никто даже близко не потрудился проверить. Я не знаю как это по-другому можно объяснить.

Tags: it, juniper, баги, ненависть, сети, трудовыебудни
Subscribe

  • И снова PostgreSQL

    ... Есть у нас один "проблемный" сервис, который очень сильно нагружает БД PostgreSQL. Вытащили его из общего кластера на отдельную…

  • Вдогонку про IPSec

    Вдогонку к предыдущему посту. Я разобрался в чём косяк. В IKEv2 появилась новая фича: так называемый "childless IKE_SA" (RFC6023). Это…

  • Очередные грабли с IPSec (StrongSWAN + Juniper + IKEv2)

    Во время строительства очередного IPSec-а опять традиционно походил по граблям. Потерял кучу времени и замудохал саппорт одного хостинг-провайдера.…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 1 comment