Comments 19
Отличная статья!
Ее бы пару годков назад...)
Чтобы добавил:
— обозначить объекты в 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 (на самом деле, получалось это делать, но только если туннель инициировался с другой стороны относительно ната)
Ее бы пару годков назад...)
Чтобы добавил:
— обозначить объекты в 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 (на самом деле, получалось это делать, но только если туннель инициировался с другой стороны относительно ната)
— обозначить объекты в address book (у вас указано, что в политиках объекты, имеет смысл сразу определять их при создании политик, т.е. добавить пример в статью)
Я добавил их в самом начале =)
— в Policy Based ipsec важно следить за порядком правил в политиках между зонами.
Это общее правило безотносительно ипсека, для всех zone-based политик
— если у вас стоит глобальное правило «запрещать все», то нужно добавить правила для ike между пирами
ike открывается в host-inbound-traffic для соотвествующего интерфейса.
— стоит указать недостаток route-based ipsec: если вы хотите организовать доступ с нескольких подсетей к одной подсети на другой стороне
зато routed-based позволяет NAT, и эту проблему можно обойти =) А если nat не нужен, то можно обойтись policy-based
Я добавил их в самом начале =)
— в Policy Based ipsec важно следить за порядком правил в политиках между зонами.
Это общее правило безотносительно ипсека, для всех zone-based политик
— если у вас стоит глобальное правило «запрещать все», то нужно добавить правила для ike между пирами
ike открывается в host-inbound-traffic для соотвествующего интерфейса.
— стоит указать недостаток route-based ipsec: если вы хотите организовать доступ с нескольких подсетей к одной подсети на другой стороне
зато routed-based позволяет NAT, и эту проблему можно обойти =) А если nat не нужен, то можно обойтись policy-based
Я добавил их в самом начале =)
оу, утро такое утро, был невнимателен)
Это общее правило безотносительно ипсека, для всех zone-based политик
Разумеется, но тут мы обсуждаем ipsec)
ike открывается в host-inbound-traffic для соотвествующего интерфейса.
Да, но помоему мы там открываем возможность этому протоколу ходить через интерфейс, в случае если нет разрешающей политики из зоны в зону — трафик даже не попадет на этот интерфейс, нет?
зато routed-based позволяет NAT, и эту проблему можно обойти =) А если nat не нужен, то можно обойтись policy-based
С этим я не спорю, просто лучше заранее выбирать тип ipsec, исходя из задач.
Самого интересного-то и нету.
Допустим, SA не согласовывается, пакетики не бегают. Как траблшутить? Сразу говорю, «сверить конфиги» — не наш метод :)
Теоретически, вы совершенно правы. Практически — изредка бывают очень интересные проблемы при попытках поднять IPSec туннель между двумя железками разных вендоров, следующие как из багов, так и из немного разного понимания стандарта. И вообще, IPSec — весьма навороченный и сложный фреймворк.
Хотя PPP тоже не сахар…
SA устанавливаются, пакетики бегают, канал работает.
Допустим, SA не согласовывается, пакетики не бегают. Как траблшутить? Сразу говорю, «сверить конфиги» — не наш метод :)
через ipsec гораздо проще, нежели поднимать между ними ppp-соединение. Потому что ipsec умеют почти все роутеры умнее домашней мыльницы (есть и специальные VPN-шлюзы), а вот с ppp-соединениями всегда возможны нюансы.
Теоретически, вы совершенно правы. Практически — изредка бывают очень интересные проблемы при попытках поднять IPSec туннель между двумя железками разных вендоров, следующие как из багов, так и из немного разного понимания стандарта. И вообще, IPSec — весьма навороченный и сложный фреймворк.
Хотя PPP тоже не сахар…
Допустим, SA не согласовывается, пакетики не бегают.
Я думаю, траблшутингу IPSec можно целый материал посвятить =) Хотя сколько я сталкивался с IPSec, проблема в 99% была либо в некорректных policy, либо несогласованности настроек. Были траблы с микротиком — тому помог апгрейд прошивки
Теоретически, вы совершенно правы. Практически — изредка бывают очень интересные проблемы при попытках поднять IPSec туннель между двумя железками разных вендоров, следующие как из багов, так и из немного разного понимания стандарта.
Ну на моей памяти проблем с IPSec не больше, чем с ppp. С тем же ovpn проблем случается больше разных)
Хотя сколько я сталкивался с IPSec, проблема в 99% была либо в некорректных policy, либо несогласованности настроек
по началу примерно такая же статистика была.
Сейчас же 80% проблем — ipsec оборвался на другой стороне и джунипер не смог корректно это обработать (сессия висит как рабочая, трафик не идет)
и 20% какие то странные глюки- несколько раз было, что сидели несколько часов мазолили глазами логи, потом плевали, удаляли конфиг и заливали его заново — все начинало работать
А еще провайдеры временами творят потрясающие вещи с трафиком. Мой самый любимый косяк такого рода — через минуту после установления SA ESP трафик начинает теряться. После переинициализации SA всё восстанавливается на минуту. Возможности собрать дамп пакетов с обеих сторон не было. Однако, я сумел доказать провайдеру, что косяк именно у него, и это поправили :)
Ну нам вроде с операторами везло. Траблы обычно случаются после смены vpn-железки у заказчика, либо при изменениях в его сети, после чего забывают поправить policy
я как то с одним известным провайдером мобильной связи воевал на тему того, что они резали gre пакеты. Причем tcp1723 проходил, а 47 протокол — нет(снимал дампы с джунипера со стороны работы и со своей машины как инициатора соеденения). ПРоблема была в том, что этот провайдер предоставлял один из каналов непосредственно моему домашнему провайдеру. Как следствие — дома не работал vpn на один из рабочих vpn серверов.
Обидно, что я не мог надавить на этого провайдера, т.к. услугу покупал я у своего домашнего провайдера. Забавно то, что на работе, у нас был один временный канал этот этого мобильного оператора, и там всплыла та же тема, хотя и город совсем другой.Результатом переписки было полное отрицание самой возможности того что они резали 47 протокол, и полная работоспособность gre через них в этот же вечер. Может конечно и совпало, но очень уж странное совпадение, до этого не работало около полугода)
Обидно, что я не мог надавить на этого провайдера, т.к. услугу покупал я у своего домашнего провайдера. Забавно то, что на работе, у нас был один временный канал этот этого мобильного оператора, и там всплыла та же тема, хотя и город совсем другой.Результатом переписки было полное отрицание самой возможности того что они резали 47 протокол, и полная работоспособность gre через них в этот же вечер. Может конечно и совпало, но очень уж странное совпадение, до этого не работало около полугода)
Я в Питере встречался с тем, что GRE не проходил. Естественно, первая линия знать ничего не знала ни про какие GRE, и бодро рапортовала, что «у нас все хорошо и ничего не режется».
Тащем-то поэтому мы в свое время стали упаковывать трафик от удаленных точек в ppp (ovpn тогда, сейчас не знаю, что у них там)
Тащем-то поэтому мы в свое время стали упаковывать трафик от удаленных точек в ppp (ovpn тогда, сейчас не знаю, что у них там)
А если с каждой стороны по 2 провайдера, т.е. 4 возможные комбинации провайдеров, можете посоветовать как лучше сделать? сейчас у меня 4 отдельных туннеля и в роутинге прописано использовать st.0, st.1, st.2, st.3 по очереди, возможно, есть лучший способ?
Sign up to leave a comment.
Настойка можжевельника: готовим Juniper SRX. Часть 2: IPSec