klink0v (klink0v) wrote,
klink0v
klink0v

Categories:

Два мира - два Шапиро (про Juniper)

Давно не писал ничего и не отвечал на комменты. Извиняйте. Несмотря на все эти ваши карантины, я продолжаю работать. Только из дома. Причём, даже больше, чем прежде. Потому что проект ни фига не ждёт. Сижу целыми сутками, ковыряю Juniper SRX 345, с перерывами на еду и сон.

И таки знаете что? Сказать, что я разочаровался в жуниперах — значит не сказать ничего. Да, у него достаточно удобный cli-интерфейс. Да, у него есть вот эта офигительная система commit-ов конфигурации. Да, довольно клёво, что можно ковырять боевой роутер и не бояться "отвалиться" от него, потому что "commit confirmed 5" всегда спасёт отца русской демократии ежели где-то совсем конкретно накосячил. Да, у него [пока] нет этой еболы с подписЬками на лицензии как у сиськи (cisco). Да, у него нет этих совршенно идиотских инвертированных масок, а словом "NAT" там действительно называется NAT (цискари поймут о чём это я). Но на этом, ИМХО, все его преимущества и заканчиваются.

Но логикой там вообще даже близко не пахнет. Некоторые вещи делаются через какую-то откровенную задницу, а некоторые не делаются в принципе. Вообще, для меня, профессионально деформированного и развращённого свободой действий iproute2 / iptables, где я могу наворотить чего угодно и как угодно, являются какой-то безумной дикостью попытки загнать админа в жёсткие рамки "туда не ходи, сюда ходи". Или приколы как в анекдоте: "В Америке вы можете купить любой автомобиль любого цвета. Но если вы выберете Ford, то цвет будет красным."

Не знаю сколько раз я за эту и прошлую неделю орал "ЪЫЪ СУКА JUNIPER!!!" и колотил кулаками по столу. Не считал. Много. Прямо сейчас мне хочется взять кувалду и раз***ть к чертям эти сраные SRX-ы. Спасает только то, что они в датацентре, а я дома.

Я уж промолчу про всякие мелочи типа "самый простой способ экспортировать по BGP статический /24-маршрут чтобы потом порезать его внутри на куски — прописать его как discard" или "почему входящие icmp и traceroute работают без указания default gateway, а SSH — нет". Или что в пакетном режиме не работают куча полезностей типа BGP и IPSEC, а в поточном режиме все пакеты принудительно прогоняются через трассировщик соединений. Это всё фигня. Ну грабли. Ну бывает. Но есть задача, которая не решается в принципе. Или я просто не знаю как.

Ситуация. Стойка в датацентре. Два Ethernet-линка от двух разных провайдеров. Каждый даёт "честный" IP-адрес с маской "/30" из своего собственного адресного пространства. Есть отдельный выделенный персонально мне блок адресов с маской "/24" (подсеть класса "C"), с которым я могу делать что хочу, в том числе объявлять по BGP. Провайдеры исходящий от меня трафик никак не фильтруют: могу слать что угодно с какого угодно SRC IP.

Чего хочу.


  1. Объявить свой "/24" блок адресов "в мир" через BGP.

  2. Кусочек этого блока (например, четвертинку) отрезать и замаршрутизировать на свои сервера, для которых нужен "белый" адрес.

  3. Еще несколько адресов из этого блока навесить на собственные псевдоинтерфейсы (lo) маршрутизатора.

  4. Организовать IPSec-пиринг с разными мурзилками, используя со своей стороны IP-адреса из предыдущего пункта.

  5. Сделать так, чтобы у меня всегда был доступ по SSH к моему роутеру (SRX) по обоим IP-адресам из пространств провайдеров. Это нужно на случай, если по каким-то причинам BGP-сессии отвалятся или случится какая-нибудь ещё НЁХ.

Ладно. Начинаю решать. Начинаю почему-то с последнего пункта. В Linux-е это делается элементарно четырмя командами.

ip route add default via 1.2.3.5 table prov1
ip route add default via 5.6.7.7 table prov2
ip rule add from 1.2.3.6 lookup prov1
ip rule add from 5.6.7.8 lookup prov2

Всё!!!

В Juniper-е для этого требуется поднимать (страшно сказать) отдельные "routing instance" типа "virtual-router". (!!!)

Ладно, поднял, сделал, всё работает. Порешал пункты номер один, два, три, а потом внезапно задумался вот над чем. У можжевельника by design нельзя один и тот же интерфейс добавлять в разные routing instance. А интерфейсы из разных routing instance не могут находиться в одной и той же security zone. Таким образом выходит, что мой lo-интерфейс для терминации IPSec-ов находится в одной secutity zone, ethernet одного провайдера — в другой, ethernet второго аплинка — в третьей. Легко может случиться так, что при перестройке маршрутов в недрах интернета очередной входящий пакетик мне может прилететь через другой внешний ethernet-интерфейс. Но раз вся эта баланда распихана по разным security-зонам, то как минимум TCP-сесии порвутся, и IPSec-тоннели развалятся. Нехорошо. Но это было бы ещё полбеды.

А потом я "влетел" вот в это.

То есть, ежели развести терминирующий IPSec lo-интерфейс и "физику" (ethernet-ы) по разным security-зонам, то IPSec работать не будет. От слова "совсем". ЪЫЪ СУКА!!!11

Тихо поматерившись, "разобрал" свою красивую схему с тремя routing instance и запихнул всё в одну. Но тут внезапно выплыл второй вопрос: а как обеспечить доступность SSH через любого из провайдеров, независимо от состояния линка и настроения второго?

То есть в линуксе при помощи банального iproute2 я запросто могу задать правило типа "с какого интерфейса пакет пришёл, через такой и отпули его взад" (см. пример выше). Здесь (в juniper-е) я тоже могу сделать что-то похожее. Но только для транзитного трафика. Для локального (входящего) — XYЙ!

Как я только не пытался изгаляться. И пытался создавать дополнительные lo-интерфейсы, выносить их в отдельные routing instance. И всякие пляски с unnumbered interfaces. И шаманил с таблицами маршрутизации. Результат один: xyй. Если у тебя разные routing instance под каждого провайдера — не работает IPSec. Всё в одном instance — нет гарантированного SSH. И хоть обкакайся.

В довершение, я никак не могу вкурить как сиё изделие разграничивает локальный трафик и транзитный. В Linux-е просто: есть цепочка INPUT, есть цепочка FORWARD. Всё ясно и прозрачно. В Juniper-е вроде бы доступ к локальным ресурсам (всякие там SSH, ping, IKE и прочие) настраивается мантрой "host-inbound-traffic system-services", что как бе намекает. Но при этом никто не мешает создать security policy типа "from-zone бла_бла_бла to-zone junos_host" (последняя является встроенной). Аналогично, если надо NATить исходящие с самого роутера пакеты, то надо создавать NAT-правило с привязкой типа "from-zone junos_host to-zone бла_бла_бла". Ну охренеть, дайте две! Ах, да. Если два интерфейса, например, lo0.1 и reth0.5 находятся в одной security zone, то пришедший через reth0.5 снаружи в lo0.1 трафик будет расцениваться как транзитный и обработается межзонной политикой "из себя самой в саму себя". После долгих лет работы с iptables от подобного кульбита просто съезжает крыша сразу.

Я не работал сильно плотно с cisco, не знаю лучше ли у них обстоят с этим дела или хуже. Понятно одно. Попытка "причесать под одну гребёнку" пачку самых разношерстных сервисов и запихнуть всё это в один "стандартизированный" конфиг с унифицированным синтаксисом ни к чему хорошему не приводит. Поэтому, скорее всего, все специализированные сетевые железки страдают полным отсутствием логики в своей настройке. Собственно, как раз из-за этого "сетевики" и "линуксоиды" — это две разных профессии, слабо пересекающиеся друг с другом. Потому что нужно быть правильным образом профдеформированным, чтобы "врубиться" в идеологию функционирования сетевых спецжелезок. С другой стороны, я время от времени наблюдаю яркое зарево от пуканов всяких завзятых жуниперистов-цискарей, которые сталкиваются на практике с iptables / iproute2.

Например, лично я все вышеописанные задачи при помощи Linux-а решил бы максимум за пару часов. С Juniper-ом приходится мудохаться неделями. И это мне ещё постоянно помогал бесценными советами hvostat_hvostat (за что ему спасибо), без которых я бы вообще забуксовал. Кстати, вот он наоборот: лучше купит и внедрит vSRX, но форточку не откроет с Linux-ом связываться ни за какие коврижки не станет. Человеческий фактор-с...

И забавно. С одной стороны, мне мой Linux-овый опыт помогает: я заранее понимаю в какую сторону копать и по каким словам гуглить. С другой стороны, он же сильно мешает: мне просто в голову не приходит попробовать сделать не так, а сяк. Кажется это дикой тупостью, но на самом-то деле как раз так и надо.

В общем, не в восторге я от Juniper-ов, мягко говоря. Совсем не в восторге. По крайней мере, от SRX-ов. Вот был бы нормальный агрегат с "ванильным" Linux-ом внутри, умеющий нормально прожёвывать много PPS и FPS, было бы мне щастье. А все эти узкоспециализированные сетевые железки... тьфу.

Расскажите что ли как там с цисками. Те же яйца, или лучше/хуже?

Tags: it, juniper, ненависть, ссылки, трудовыебудни
Subscribe
  • 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 

  • 16 comments