May 13th, 2021

Cat-light

Juniper не дружит с IKEv2

Продолжаю рубрику о ненависти к Juniper-ам.

Практика показала, что когда строишь тоннель между Juniper-ом и чем-то другим, то в случае попыток использования IKEv2 тебя ждут большие проблемы.

Самая мелкая из них заключается в том, что Juniper не даёт явно выставлять Pseudo-Random Function. Об этом я уже писал раньше.

Следующий прикол — разработчики софта традиционно по-разному трактуют RFC. А в IKEv2 появилась возможность делать как по принципу "одна SA — один тоннель", так и запихивать в рамки одной и той же SA несколько различных identities (грубо говоря, несколько маршрутов в одном тоннеле с одной SA). Так вот, иногда они не могут договориться: пруф 1, пруф 2. На практике это выглядит так, что тоннель поднимается только по запросу одной из сторон, а Juniper постоянно гадит в логи про то, что не может согласовать какие-то security associations (SA).

И самое мерзкое, с чем лично мне пришлось столкнуться — это конкретное такое "залипание" тоннелей на IKEv2. Настолько конкретное, что не спасают "clear security ike бла-бла-бла", "clear security ipsec бла-бла-бла" от слова "совсем". То есть формально Juniper показывает, что всё нормально, SPI меняются, но трафик не ходит. Помогает только деактивация проблемного traffic selector из конфига, выжидание 10 минут, потом активация обратно.

Короче говоря, между двумя Juniper-ами там особых проблем нет. А вот между какой-нибудь Cisco ASA и Juniper надо всё-таки брать IKEv1 и не вы**ываться.

Хотя, с другой стороны, мне известен как минимум один обратный кейс. Когда строили IPSec-тоннель между Juniper SRX и каким-то Huawei, то там было наоборот. IKEv1 не хотел подниматься из-за косяков в прошивке "хуявого", а вот IKEv2 таки взлетел.

Техника несовершенна. Но Juniper — это лютая попа-боль.

Cat-light

Еще про баги в Juniper SRX

Как я обычно строю IPSec с контрагентом? Выделяю серую "буферную" подсеточку с маской "/29" (6 хостов). Первый адрес из неё присваиваю ST-интерфейсу самого Juniper-а для диагностики и всего остального, в том числе чтобы на пинги откликался. А дальше в зависимости от конкретной задачи второй и последующие адреса либо static nat-ом, либо destination nat-ом перенаправляю на нужные серверы либо отдельные TCP-порты внутри "боевого" сегмента.

Так вот. Допустим, мы назначили адрес "192.168.1.1" на st0.1, а "192.168.1.2" при помощи static nat перенаправили на сервер "172.19.34.8". Везде разрешили ICMP. В такой ситуации контрагент сможет нормально пинговать "192.168.1.1", а вот "192.168.1.2" — хренъ. Почему? А потому что очередной баг. Правда, тщательно задокументированный.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB32123

Это называется "потихоньку между багов нащупал дорогу, но что ж их так много, ей богу?"

Lozhkin

Про anti-dDOS

Есть у меня один проект, который я очень не люблю. Сам присвоил ему кодовое имя "проект с мудаками". Но начальство выводить меня из него, увы, не спешит.

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

Нашли там одну контору... не буду публиковать её название, дабы не делать им рекламы или не отбиваться от их нападок. Но они капец какие смешные.

Вся инфраструктура у них заточена под защиту / фильтрацию исключительно HTTP / HTTPS. Шаг вправо / шаг влево, какой-то относительно нестандартный протокол — уже проблемы.

Для защиты HTTPS требуют отдать им закрытый ключ от твоего X509-сертфиката. Чтобы они, значит, сами терминировали-разворачивали TLS-сессии. Ага, щаззз, разбежались. Я если бы даже и захотел, не смог бы им отдать. Потому что он у меня хранится в специальном отдельном криптоящике, который внаружу его не выпустит ни при каких условиях.

Ладно... если нельзя отдать X509-ключ, тогда по их условиям нужно строить GRE-тоннели, в которые заворачивать весь трафик. При этом.


  • Адресацию внутри GRE-тоннелей они тебе диктуют сами. Пересекается с твоими сетями? А ниипёт! Сам изворачивайся как хочешь.

  • Весь ICMP у них наглухо закрыт. Диагностика? Не, не слышали! Работает тоннель, не работает, догадайся, мол, сама.

Ладно, с помощью кувалды, какой-то там матери и нескольких суток отладки таки построили, как-то даже работает.

Дальше говно ширится. Понадобилось также защищать подключения по протоколу UDP. Ииии? "Ой, нет, а мы так не можем! Давайте объявляйте свою AS через нас, мы будем представляться от вашего имени, только так." Ну охренеть, дайте две! Ещё я им свою ASку целиком отдать должен. А жопа не треснет?

Вот и возникает вопрос: а на хера вы мне вообще такие красивые нужны, а? Впрочем, ответ уже был дан несколько выше.

Ещё маленький нюанс. Эти гаврики участвовали в одной из онлайн-конференций "Yandex NextHop Talks". При этом у их докладчика единственного возникли проблемы с трансляцией видео и звука. До такой степени, что он даже "выпадал" из конференции и не мог восстановить вещание минут 15. Народ его там обстебал по полной программе.

Это всё, что вам нужно знать про защиту от DDoS и про одну из самых популярных в России контор, оказывающую такие услуги.