Когда цискарь настраивает Juniper...
... Вот почему я всегда говорю, что мало просто взять и сделать что-то по мануалам из интернетов. Нужно всё-таки хотя бы в общих чертах понимать что там находится "под капотом" у той железки / софтины, которую настраиваешь, её дизайн, ограничения, сценарии применения.
Напоролся уже на два случая, когда некий условный Вася до энного момента видел только циски, а потом пошёл настраивать Juniper SRX, попытавшись использовать свой цисковский опыт, не разобравшись толком. В обоих случаях ничего хорошего не вышло.
Случай 1.
Для строительства IPSec-тоннеля в Juniper SRX обязательно использование некоего внутреннего виртуального ST-интрефейса (пример: st0.0), к которому привязывается тот или иной VPN. Явных ограничений на адресацию нет, но в разных местах в разных документах Knowledge Base есть некие мимолётные робкие упоминания, что лучше навешивать на них IP-адрес, который не будет совпадать с "внешними концами" тоннеля.
Прэтому когда я делаю тоннель с кем-то из контрагентов, всегда резервирую под него отдельную серую "/29"-подсеть, один из адресов которой назначаю на st0.*-интерфейс. Таким образом, у меня на каждом из st-адаптеров числится уникальный IP-адрес, и никаких проблем.
А вот предыдущий админ вдохновлялся цисками и её подходами. Он вообще не назначал никакого адреса на st-интерфейсы, а в криптодомен для всех контрагентов прописывал "белый" адрес, на который sNATил все исходящие пакеты. А чтобы сам juniper отвечал бы на пинги "с той стороны", навесил этот же адрес на "lo0.0".
До какого-то момента оно, конечно, работало. Пока не возникли вопросы с Path MTU Discovery в одном из подключений. Взяли в руки tcpdump, посмотрели, а Juniper отсылает сообщение ICMP Fragmentation Needed с адреса "0.0.0.0". Ха-ха, красавчик. Но в чём-то я могу его понять, он тупо не знает какой SRC IP выбрать при имеющихся (а точнее, отсутствующих) настройках ST-интерфейса...
Случай 2.
Строили другой IPSec-тоннель с неким весьма проблемным контрагентом. "Проблемным" - потому что там компетентных спецов нет от слова "совсем": все что были, разбежались после очередных "оптимизаций". Меня на тот проект изначально не позвали, потому что "сами большие и умные, справимся". Спустя недели две таки поняли что обо***лись, про**али все сроки, осознали что уже совсем п***ец-п***ец, и вот тогда уже таки привлекли "тяжёлую артиллерию" в моём лице.
Пришел, посмотрел. Там что с одной, что с другой стороны Juniper-ы, которые настраивали бывшие цискари. И они решили конфигурировать тоннель как policy-based. Но с той стороны оно худо-бедно проканало, а вот с нашей стороны конфигурация чуть сложнее стандартной, т.к. применяются несколько разных routing instance. И эффект получился крайне смешной. Инициировать наш Juniper смог, а вот ответить (responder) - уже нет. По логам это выглядело так, как будто у него вообще отсутствует конфигурация для такого peer-а, хотя в действительности она там, разумеется, была.
Ну я первым же шагом переделал из policy-based в route-based, всё тут же взлетело. Они мудохались ночами на протяжении двух недель, я починил за полчаса вместе с отладкой.
... Мораль... а хрен знает. Может и нет никакой морали. Я сам-то этот Juniper SRX в первый раз в жизни увидел только два с половиной года тому назад...