Juniperобсирание, серия 24

[klink0v]

Очередные увлекательные эротические приключения с индийской кривой сетевой псевдожелезкой под названием "Juniper SRX".

В энный раз на игрековой технической площадке меня достали всякие скрипткиддисы и прочие порт-сканеры. Всё бы ничего, но когда они "идут" по всему диапазону ASки, Juniper начинает генерировать ARP-запросы к хостам, которых нет. Потом он решает, что этих ARP-запросов как-то зело много, включает троттлинг, перестаёт откликаться на ARP от BGP-соседа и тем самым начинает терять полезный коммерческий трафик. Подход дебильный сам по себе, но ничего не поделаешь.

Тогда я озаботился тем, чтобы сформировать "белые списки" (скоро будет ругательством) из хостов, реально присутствующих в моей ASке. А заодно чётко перечислить весь полезный трафик, а остальной отфильтровать на "низкоуровневом" stateless-файрволле (pfe) чтобы не допускать всякий мусор до stateful-полисира и тем самым повысить живучесть этого несчастного ждунипера при всевозможных сканированиях и DDoS-атаках.

Штош, сказано — сделано. Перечень полезной нагрузки составлен, правила написаны. И всё было бы хорошо, но помимо прочего в списки затесалась парочка GRE-тоннелей. А GRE-тоннель по мнению жуниперов — это что особенное, сакральное, и общим правилам ни фига не подчиняющееся.

Я пошел "в лоб". Source IP такой-то, Destination IP такой-то (мой собственный), протокол GRE, действие "разрешить". Всё остальное запретить. Применяю набор правил на "внешний железный" интерфейс, направление "только на вход" (input). И всё падает. Протираю очки глаза, дважды всё перепроверяю. Снова применяю. Снова всё падает.

Дальше я стал размышлять в сторону маршрутизации. Потому что тот Juniper SRX у меня разбит на несколько Virtual Routers, ибо через те самые GRE-тоннели проложены маршруты по умолчанию для некоторых сервисов. А у GRE и с этим приколы, кому интересно можете посмотреть в документации и другие гневные посты. Была версия, что при "accept" входящий пакет в какой-то "не тот" routing instance приземляется. Но она разбилась об то, что accept "на весь GRE" без указания Source Address вполне себе отрабатывает. А вот если определить SRC IP, то уже нет.

Долго мучался. Благо, у меня дома есть Juniper SRX точно такой же линейки. Прикупил как раз для таких вот опытов. Стал ковырять. И выяснил прекрасное.

Исходящий GRE-пакет тоже попадает под критерий "input" внешнего физического сетевого интерфейса. Да-да. Исходящий. Уже "упакованный" (после инкапсуляции). Тот который готовится уйти внаружу. В input. На внешний железный интерфейс. Именно так.

Моя реакция ожидаема: сссссууууккккааааа!!!! Нигде в документации про это не сказано. Вообще нигде. Как я должен был про такое догадаться? И такое бл****во наблюдается только для GRE. С тем же IPSec-ом, например, вопросов нет; оный отрабатывает обычным ожидаемым образом: ESP ушел в output, ESP пришел в input.

В итоге добавил "зеркальное" разрешающее правило в общий набор, в тот же самый "input", и всё стало хорошо. Но как бычно, цензурных слов у меня нет, один мат.

Где логика? Где справедливость?