Firewalls As Routers
Sep. 4th, 2026 10:18 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
cat_muciusОдной из самых глупых и при этом долгоиграющих вещей, что я сделал за свою сетевую карьеру, было решение использовать файерволлы в качестве раутеров. Не повторяйте моих ошибок, друзья мои.
Допустить такую ошибку очень легко, поскольку любой файерволл и впрямь умеет быть раутером, поддерживая весь джентельменский набор - динамические протоколы, туннели, NAT, VRRP, DHCP и так далее. Иногда даже и VRF. Поэтому очень подкупает идея им и обойтись: зачем усложнять и платить больше - и деньгами, и временем-усилиями настраивать-поддерживать дополнительные компоненты?
Но обратите внимание, что в любом большом облаке - AWS, Azure, GCP - функции раутинга и фильтрации трафика строго разнесены. VPN Gateway - раутинг и туннелирование, NSG и Azure Firewall - фильтрация, и так далее. Это не случайно.
Раутер - животина простая, stateless. Принял пакет, нашёл наилучший маршрут, послал, забыл.
Файерволл же stateful. Он отслеживает сессии, ему принципиально, чтобы трафик тёк через него симметрично, в обе стороны. Если ответный пакет приходит на не ту ногу или зону, с которой был послан оригинальный, или и вовсе приходит на другой файерволл - он будет выкинут.
Более того, стандартной фичей файерволлов является RPF (Reverse Path Forwarding) - ещё до того, как приложить к пакету список правил, они смотрят, соответствует ли нога, на которую он пришёл, сети, с которой ожидается трафик на эту ногу. Если пакет с src=192.168.1.11 приходит на port2, но наилучший маршрут на этот адрес - это 192.168.1.0 через port1, то пакет опять же постигнет горькая судьбина. Смысл этого дела - anti-spoofing, борьба с попытками выдавать свои запросы за чужие.
(Там два варианта, на самом деле: более строгий, когда проверяется лишь оптимальный маршрут, попавший в таблицу - и более либеральный, когда и соответствие отвергнутому окей, лищь бы он был. В этом примере, если соседский раутер на port2 объявил, что 192.168.1.0 через него доступен - то файерволл может пакеты с этой сети и от него принять, хотя в обратную сторону пошлёт через port1).
Поэтому файерволл в качестве раутера вполне приемлем, если топология проста и статична, для любого трафика существует однозначный и симметричный путь в обе стороны. Если же есть возможность, что запрос пойдёт путём А, а ответ вернётся путём Б - в результате нормальной операции ли, в результате падения какого-то линка или компонента ли - схема должна быть пересмотрена. Иначе начинается невероятный трэш и мучительные попытки поддерживать симметрию костылями - и чем сложнее топология, тем они мучительнее, тем сложнее удержать схему в голове, тем проще налажать.
Файерволл должен сидеть на входе к ресурсам, которые он защищает, и гонять трафик по очень простой и неизменной схеме. Соединением сетей по топологии более сложной, чем звезда, должен заниматься отдельный слой из раутеров - включая туннелирование.
P.S. Пара не самых страшных, но всё же неприятных последствий, про которые не очень думаешь заранее:
- Невозможность представлять свою сеть соседям как единую AS (автономную систему) и использовать iBGP. Потому что если твои файерволлы представляются соседям с тем же номером AS - то вероятность того, что получив пакет от файерволла А сосед ответит через файерволл Б резко возрастает. Приходится каждый файерволл определять как AS саму по себе - что в определённых вариантах приводит опять же к асимметрии.
- Если у нас файерволлы в кластере, то использование туннелей и динамических протоколов раутинга увеличивает время введения запасного в дело. Если основной рухнул, перезагрузился и т.п. - пока запасной наладит IPsec, пока договорится со соседями по OSPF - время-то идёт. И в результате переключение вместо нескольких секунд занимает минуту - а поломаться за это время может многое.
Поэтому если рассудок и жизнь дороги вам...
Допустить такую ошибку очень легко, поскольку любой файерволл и впрямь умеет быть раутером, поддерживая весь джентельменский набор - динамические протоколы, туннели, NAT, VRRP, DHCP и так далее. Иногда даже и VRF. Поэтому очень подкупает идея им и обойтись: зачем усложнять и платить больше - и деньгами, и временем-усилиями настраивать-поддерживать дополнительные компоненты?
Но обратите внимание, что в любом большом облаке - AWS, Azure, GCP - функции раутинга и фильтрации трафика строго разнесены. VPN Gateway - раутинг и туннелирование, NSG и Azure Firewall - фильтрация, и так далее. Это не случайно.
Раутер - животина простая, stateless. Принял пакет, нашёл наилучший маршрут, послал, забыл.
Файерволл же stateful. Он отслеживает сессии, ему принципиально, чтобы трафик тёк через него симметрично, в обе стороны. Если ответный пакет приходит на не ту ногу или зону, с которой был послан оригинальный, или и вовсе приходит на другой файерволл - он будет выкинут.
Более того, стандартной фичей файерволлов является RPF (Reverse Path Forwarding) - ещё до того, как приложить к пакету список правил, они смотрят, соответствует ли нога, на которую он пришёл, сети, с которой ожидается трафик на эту ногу. Если пакет с src=192.168.1.11 приходит на port2, но наилучший маршрут на этот адрес - это 192.168.1.0 через port1, то пакет опять же постигнет горькая судьбина. Смысл этого дела - anti-spoofing, борьба с попытками выдавать свои запросы за чужие.
(Там два варианта, на самом деле: более строгий, когда проверяется лишь оптимальный маршрут, попавший в таблицу - и более либеральный, когда и соответствие отвергнутому окей, лищь бы он был. В этом примере, если соседский раутер на port2 объявил, что 192.168.1.0 через него доступен - то файерволл может пакеты с этой сети и от него принять, хотя в обратную сторону пошлёт через port1).
Поэтому файерволл в качестве раутера вполне приемлем, если топология проста и статична, для любого трафика существует однозначный и симметричный путь в обе стороны. Если же есть возможность, что запрос пойдёт путём А, а ответ вернётся путём Б - в результате нормальной операции ли, в результате падения какого-то линка или компонента ли - схема должна быть пересмотрена. Иначе начинается невероятный трэш и мучительные попытки поддерживать симметрию костылями - и чем сложнее топология, тем они мучительнее, тем сложнее удержать схему в голове, тем проще налажать.
Файерволл должен сидеть на входе к ресурсам, которые он защищает, и гонять трафик по очень простой и неизменной схеме. Соединением сетей по топологии более сложной, чем звезда, должен заниматься отдельный слой из раутеров - включая туннелирование.
P.S. Пара не самых страшных, но всё же неприятных последствий, про которые не очень думаешь заранее:
- Невозможность представлять свою сеть соседям как единую AS (автономную систему) и использовать iBGP. Потому что если твои файерволлы представляются соседям с тем же номером AS - то вероятность того, что получив пакет от файерволла А сосед ответит через файерволл Б резко возрастает. Приходится каждый файерволл определять как AS саму по себе - что в определённых вариантах приводит опять же к асимметрии.
- Если у нас файерволлы в кластере, то использование туннелей и динамических протоколов раутинга увеличивает время введения запасного в дело. Если основной рухнул, перезагрузился и т.п. - пока запасной наладит IPsec, пока договорится со соседями по OSPF - время-то идёт. И в результате переключение вместо нескольких секунд занимает минуту - а поломаться за это время может многое.
Поэтому если рассудок и жизнь дороги вам...
