поддержу про ДГУ.
На всех критичных для нас площадках стоят ИБП + ДГУ. При этом есть площадки, где падение сайта по питанию не критично для бизнеса — там ДГУ конечно не стоит.
Любая задача должна рассматриваться не только с технической точки зрения, но и со стороны бизнеса.
Хобби — фото. Хотя в последние несколько лет — скорее вторая работа. Долгое время стоял перед выбором фото\IT, но в итоге похоже склонился к IT)
+ По специализации я сетевик, но вот решил выучить какой нибудь язык программирования. Скачал Python, записался на курсы в курсере, читаю мануалы))
ipsec site2site, поэтому в ситуации когда они падают, сразу начинаешь контактировать с сетевиками клиентов, в такой ситуации мозговой штурм из нескольких специалистов с разной стороны позволяет быстрее найти проблему.
Но суть я понял, проактивность наше все) К тому же обычно такие детали и ускользают от внимания)
Спасибо, буду знать)
Хотя, если изменится анонс, то упадет куча ipsec`ов… и тысячи людей, оперативнее любого мониторинга, прийдут по мою душу:)
PS хотя аномалии могут быть разными, туннели могу и не упасть, а новый as-path с участием моей сетки (с меньшей маской и участком который не используется в данный момент) может где то и засветится не в том месте.
Я думал, что после диких факапов связанных с тем, что провайдер не проверяет может ли клиент анонсировать то, что анонсирует — проверка стала обязательной. Выходит это просто рекомендация, которой много кто не придерживается?
как раз на днях закончил формировать карту сети для Zabbix. Мультивендорной ее не назовешь, но скрипты для интерфейсов подошли и к Cisco и к Juniper SRX.
Остальные скрипты, которые писал — проприетарные технологии, на джунипере не проверишь (nbar, ip sla)
Но, допустим OID загрузки CPU на ASR и на ISR отличаются. В рамках одного lld скрипта, сделал оба oid. Если шаблон цепляется на ISR, то тот кусок что касается ASR показывается как «OID не поддерживается на устройстве.»
Хорошие L3-схемы содержат следующую информацию:
подсети
VLAN ID (все)
названия VLAN'ов
сетевые адреса и маски (префиксы)
Слишком уж радикально, как по мне.
Если в моей ситуации вывести на L3 схему все вланы с адресацией по всем сайтам, у меня бы живого места не осталось бы. При этом у нас далеко не большая сетевая инфраструктура (порядка 12 распределенных площадок)
Поэтому эту информацию, мы выводим на L2 схему площадки.
PS. Большое спасибо за перевод и ссылки. Хочется улучшить скилл рисования красивых схем)
я как то с одним известным провайдером мобильной связи воевал на тему того, что они резали gre пакеты. Причем tcp1723 проходил, а 47 протокол — нет(снимал дампы с джунипера со стороны работы и со своей машины как инициатора соеденения). ПРоблема была в том, что этот провайдер предоставлял один из каналов непосредственно моему домашнему провайдеру. Как следствие — дома не работал vpn на один из рабочих vpn серверов.
Обидно, что я не мог надавить на этого провайдера, т.к. услугу покупал я у своего домашнего провайдера. Забавно то, что на работе, у нас был один временный канал этот этого мобильного оператора, и там всплыла та же тема, хотя и город совсем другой.Результатом переписки было полное отрицание самой возможности того что они резали 47 протокол, и полная работоспособность gre через них в этот же вечер. Может конечно и совпало, но очень уж странное совпадение, до этого не работало около полугода)
Хотя сколько я сталкивался с IPSec, проблема в 99% была либо в некорректных policy, либо несогласованности настроек
по началу примерно такая же статистика была.
Сейчас же 80% проблем — ipsec оборвался на другой стороне и джунипер не смог корректно это обработать (сессия висит как рабочая, трафик не идет)
и 20% какие то странные глюки- несколько раз было, что сидели несколько часов мазолили глазами логи, потом плевали, удаляли конфиг и заливали его заново — все начинало работать
Это общее правило безотносительно ипсека, для всех zone-based политик
Разумеется, но тут мы обсуждаем ipsec)
ike открывается в host-inbound-traffic для соотвествующего интерфейса.
Да, но помоему мы там открываем возможность этому протоколу ходить через интерфейс, в случае если нет разрешающей политики из зоны в зону — трафик даже не попадет на этот интерфейс, нет?
зато routed-based позволяет NAT, и эту проблему можно обойти =) А если nat не нужен, то можно обойтись policy-based
С этим я не спорю, просто лучше заранее выбирать тип ipsec, исходя из задач.
Чтобы добавил:
— обозначить объекты в address book (у вас указано, что в политиках объекты, имеет смысл сразу определять их при создании политик, т.е. добавить пример в статью)
— в Policy Based ipsec важно следить за порядком правил в политиках между зонами. Если в политиках есть финальная, «deny all» политика с логированием, то нужно не забывать смещать ее в самый низ, после создания ipsec политик. (например insert security policy from zone UNTRUST to-zone TRUST policy DENY-ALL after policy vpn-from-untrust)
— если у вас стоит глобальное правило «запрещать все», то нужно добавить правила для ike между пирами
— стоит указать недостаток route-based ipsec: если вы хотите организовать доступ с нескольких подсетей к одной подсети на другой стороне — с route-based не получится, нужно использовать policy based. Но с policy based ipsec вы не сможете натить трафик, по крайней мере source (на самом деле, получалось это делать, но только если туннель инициировался с другой стороны относительно ната)
В примере nat для конкретной подсети — разве там прописывается не псевдоним, который нужно потом назначить на зону и присвоить ему адрес подсети? Так пишутся policy based правила и кажется также это работает и в вашем примере
за 1.5 года пользования Juniper у меня сложилось следующее впечатление о платформе:
Оборудование отличное, удобное, некоторые фишки очень клево сделаны, да и в целом приятно пользоваться. НО. Иногда как вылезет какая нибудь хрень и все впечатление смазывается. Как например глюченный ALG, который очень клевый, но все рекомендуют его отключать из за многочисленных багов (как то полдня траблшутил непрохождение sip трафика через ipsec, при том что я видел что трафик идет в туннель, но на другой стороне его не было)
или ограничения в route based ipsec (помоему работает только с одним encr domain со стороны джунипера) или то, что policy based ipsec не работает с nat (хотя я с дуру смог заставить его работать, но только если происходит инициирование туннеля со стороны клиента).
Но не смотря на все это — мне нравится джунипер) хотя бы за его commit confirmed =)
PS с документацией все равно у них как то заморочено) часть открыта, часть доступна только зарегистрированным. Пробовал зарегится на просто аккаунт — не дает почему то.
На всех критичных для нас площадках стоят ИБП + ДГУ. При этом есть площадки, где падение сайта по питанию не критично для бизнеса — там ДГУ конечно не стоит.
Любая задача должна рассматриваться не только с технической точки зрения, но и со стороны бизнеса.
+ По специализации я сетевик, но вот решил выучить какой нибудь язык программирования. Скачал Python, записался на курсы в курсере, читаю мануалы))
Но суть я понял, проактивность наше все) К тому же обычно такие детали и ускользают от внимания)
Хотя, если изменится анонс, то упадет куча ipsec`ов… и тысячи людей, оперативнее любого мониторинга, прийдут по мою душу:)
PS хотя аномалии могут быть разными, туннели могу и не упасть, а новый as-path с участием моей сетки (с меньшей маской и участком который не используется в данный момент) может где то и засветится не в том месте.
Я думал, что после диких факапов связанных с тем, что провайдер не проверяет может ли клиент анонсировать то, что анонсирует — проверка стала обязательной. Выходит это просто рекомендация, которой много кто не придерживается?
Остальные скрипты, которые писал — проприетарные технологии, на джунипере не проверишь (nbar, ip sla)
Но, допустим OID загрузки CPU на ASR и на ISR отличаются. В рамках одного lld скрипта, сделал оба oid. Если шаблон цепляется на ISR, то тот кусок что касается ASR показывается как «OID не поддерживается на устройстве.»
Слишком уж радикально, как по мне.
Если в моей ситуации вывести на L3 схему все вланы с адресацией по всем сайтам, у меня бы живого места не осталось бы. При этом у нас далеко не большая сетевая инфраструктура (порядка 12 распределенных площадок)
Поэтому эту информацию, мы выводим на L2 схему площадки.
PS. Большое спасибо за перевод и ссылки. Хочется улучшить скилл рисования красивых схем)
— перезагрузить роутер
— проверить оплачен ли у меня интернет
Обидно, что я не мог надавить на этого провайдера, т.к. услугу покупал я у своего домашнего провайдера. Забавно то, что на работе, у нас был один временный канал этот этого мобильного оператора, и там всплыла та же тема, хотя и город совсем другой.Результатом переписки было полное отрицание самой возможности того что они резали 47 протокол, и полная работоспособность gre через них в этот же вечер. Может конечно и совпало, но очень уж странное совпадение, до этого не работало около полугода)
по началу примерно такая же статистика была.
Сейчас же 80% проблем — ipsec оборвался на другой стороне и джунипер не смог корректно это обработать (сессия висит как рабочая, трафик не идет)
и 20% какие то странные глюки- несколько раз было, что сидели несколько часов мазолили глазами логи, потом плевали, удаляли конфиг и заливали его заново — все начинало работать
оу, утро такое утро, был невнимателен)
Разумеется, но тут мы обсуждаем ipsec)
Да, но помоему мы там открываем возможность этому протоколу ходить через интерфейс, в случае если нет разрешающей политики из зоны в зону — трафик даже не попадет на этот интерфейс, нет?
С этим я не спорю, просто лучше заранее выбирать тип ipsec, исходя из задач.
Ее бы пару годков назад...)
Чтобы добавил:
— обозначить объекты в address book (у вас указано, что в политиках объекты, имеет смысл сразу определять их при создании политик, т.е. добавить пример в статью)
— в Policy Based ipsec важно следить за порядком правил в политиках между зонами. Если в политиках есть финальная, «deny all» политика с логированием, то нужно не забывать смещать ее в самый низ, после создания ipsec политик. (например insert security policy from zone UNTRUST to-zone TRUST policy DENY-ALL after policy vpn-from-untrust)
— если у вас стоит глобальное правило «запрещать все», то нужно добавить правила для ike между пирами
— стоит указать недостаток route-based ipsec: если вы хотите организовать доступ с нескольких подсетей к одной подсети на другой стороне — с route-based не получится, нужно использовать policy based. Но с policy based ipsec вы не сможете натить трафик, по крайней мере source (на самом деле, получалось это делать, но только если туннель инициировался с другой стороны относительно ната)
В NAT правилах прописываются чистые подсети, без псевдонимов.
Оборудование отличное, удобное, некоторые фишки очень клево сделаны, да и в целом приятно пользоваться. НО. Иногда как вылезет какая нибудь хрень и все впечатление смазывается. Как например глюченный ALG, который очень клевый, но все рекомендуют его отключать из за многочисленных багов (как то полдня траблшутил непрохождение sip трафика через ipsec, при том что я видел что трафик идет в туннель, но на другой стороне его не было)
или ограничения в route based ipsec (помоему работает только с одним encr domain со стороны джунипера) или то, что policy based ipsec не работает с nat (хотя я с дуру смог заставить его работать, но только если происходит инициирование туннеля со стороны клиента).
Но не смотря на все это — мне нравится джунипер) хотя бы за его commit confirmed =)
PS с документацией все равно у них как то заморочено) часть открыта, часть доступна только зарегистрированным. Пробовал зарегится на просто аккаунт — не дает почему то.