По поводу вот этого.
Еще раз проверял всю эту конструкцию и обнаружил, что через интерфейс gif0 ничего не идет. Стал разбираться, в каком месте меня обманывают. Узнал много нового и интересного.
Upd.Справедливости ради надо отметить, что схема, которую описывал я, работает. Интрига была в том, что до gif-интерфейса дело вообще не доходило. Встал вопрос, почему так происходит и нужен ли вообще этот gif-интерфейс.
Где-то на opennet.ru в комментариях нашел мнение некоего Валентина Нечаева, привожу его ниже без изменений. Мне сейчас уже некогда, да и не на чем, тестировать схему, которую он предлагает, но когда-нибудь обязательно попробую.
«Gif в данном случае противоречит туннельному ipsec'у и просто не используется. Он имел бы смысл, если бы строился транспортный IPSEC между шлюзами (как я и посоветовал бы в данном случае — см.ниже), но в случае туннельного IPSEC до него дело просто не доходит: правила IPSEC SPD — в частности, правило "криптовать всё с 10.0.1.0/24 на 10.0.2.0/24" срабатывает до раутинга (это принципиально в IPSEC), и тут туннельный ipsec реализует по сути свой gif: строит такой же пакет, как в случае ipip туннелирования gif'ом, и криптует по ESP содержимое этого пакета. На стороне получателя происходит обратное: обнаружив ESP и адекватную его содержимому SP, расшифровывает, снимает ipip-оболочку и отправляет пакет в стек.
К чему же тут явный gif? А к попыткам автора (не данной статьи, а скорее той мягкой бумажки, что в старом handbook'е) восстановить конфигурацию, которая у него хоть как-то работала. При отсутствии работающего SP (KMPD в лице racoon не установил SA) и при вариантах правил в SP use вместо require это даст то, что туннелирование не будет сделано, и пакет отправится далее — по раутингу — попадёт в gif и пойдёт абсолютно идентичным путём, но без криптования содержимого. На приёмной стороне, при отсутствии признака ESP, правила SP вообще не будут применяться, с пакета будет снята туннельная оболочка средствами gif и он пойдёт в сеть. Всё будет работать, но без шифрования ;)
Если же оставить текущие require, и поставить на обе стороны такие настройки как сейчас... всё снова будет работать. Но в обход gif ;))
Чем плох такой вариант? Тем, что с туннелями есть проблемы с MTU. Например, мне жаловались, что при MTU 1500 на внешнем линке, IPSEC отправляет обратно ICMP NEEDFRAG с указанием допустимого MTU опять же 1500:( Явный gif честнее в этом плане.
Поэтому рекомендуемый вариант будет следующий: поставить gif точно так же как в статье, обмен ключами — точно так же, но правила в SPD заменить на следующие (для первого шлюза; для второго — аналогично):
spdadd 10.1.1.1 10.1.2.1 any -P out ipsec esp/transport//require;
spdadd 10.1.2.1 10.1.1.1 any -P in ipsec esp/transport//require;
С точки зрения формата и содержимого пакетов вообще ничего не поменяется (так что менять можно даже на одной из сторон;)), но будет меньше проблем с MTU. Проблема с MTU будет решаться в драйвере gif (который на порядок более прозрачен и в котором это решено), остаётся только выставить там разумное MTU (например, 1440). Другое преимущество этого варианта — возможность поддержки динамического раутинга дополнительных сетей (средствами zebra/quagga/gated/routed/аналогов): IPSEC SPD не содержит маршруты сетей они пишутся вместо этого в таблицу раутинга, где с ними значительно легче разбираться. В варианте же с туннельным IPSEC требуется продираться через глупости конструкции SPD (принципиально требуемый по RFC последовательный порядок правил и отсутствие возможности вставлять правила в начало/середину).
И вариант с транспортным IPSEC и gif внутри — я проверял и он работает, лучше, чем с туннелем :)»
Еще раз проверял всю эту конструкцию и обнаружил, что через интерфейс gif0 ничего не идет. Стал разбираться, в каком месте меня обманывают. Узнал много нового и интересного.
Upd.Справедливости ради надо отметить, что схема, которую описывал я, работает. Интрига была в том, что до gif-интерфейса дело вообще не доходило. Встал вопрос, почему так происходит и нужен ли вообще этот gif-интерфейс.
Где-то на opennet.ru в комментариях нашел мнение некоего Валентина Нечаева, привожу его ниже без изменений. Мне сейчас уже некогда, да и не на чем, тестировать схему, которую он предлагает, но когда-нибудь обязательно попробую.
«Gif в данном случае противоречит туннельному ipsec'у и просто не используется. Он имел бы смысл, если бы строился транспортный IPSEC между шлюзами (как я и посоветовал бы в данном случае — см.ниже), но в случае туннельного IPSEC до него дело просто не доходит: правила IPSEC SPD — в частности, правило "криптовать всё с 10.0.1.0/24 на 10.0.2.0/24" срабатывает до раутинга (это принципиально в IPSEC), и тут туннельный ipsec реализует по сути свой gif: строит такой же пакет, как в случае ipip туннелирования gif'ом, и криптует по ESP содержимое этого пакета. На стороне получателя происходит обратное: обнаружив ESP и адекватную его содержимому SP, расшифровывает, снимает ipip-оболочку и отправляет пакет в стек.
К чему же тут явный gif? А к попыткам автора (не данной статьи, а скорее той мягкой бумажки, что в старом handbook'е) восстановить конфигурацию, которая у него хоть как-то работала. При отсутствии работающего SP (KMPD в лице racoon не установил SA) и при вариантах правил в SP use вместо require это даст то, что туннелирование не будет сделано, и пакет отправится далее — по раутингу — попадёт в gif и пойдёт абсолютно идентичным путём, но без криптования содержимого. На приёмной стороне, при отсутствии признака ESP, правила SP вообще не будут применяться, с пакета будет снята туннельная оболочка средствами gif и он пойдёт в сеть. Всё будет работать, но без шифрования ;)
Если же оставить текущие require, и поставить на обе стороны такие настройки как сейчас... всё снова будет работать. Но в обход gif ;))
Чем плох такой вариант? Тем, что с туннелями есть проблемы с MTU. Например, мне жаловались, что при MTU 1500 на внешнем линке, IPSEC отправляет обратно ICMP NEEDFRAG с указанием допустимого MTU опять же 1500:( Явный gif честнее в этом плане.
Поэтому рекомендуемый вариант будет следующий: поставить gif точно так же как в статье, обмен ключами — точно так же, но правила в SPD заменить на следующие (для первого шлюза; для второго — аналогично):
spdadd 10.1.1.1 10.1.2.1 any -P out ipsec esp/transport//require;
spdadd 10.1.2.1 10.1.1.1 any -P in ipsec esp/transport//require;
С точки зрения формата и содержимого пакетов вообще ничего не поменяется (так что менять можно даже на одной из сторон;)), но будет меньше проблем с MTU. Проблема с MTU будет решаться в драйвере gif (который на порядок более прозрачен и в котором это решено), остаётся только выставить там разумное MTU (например, 1440). Другое преимущество этого варианта — возможность поддержки динамического раутинга дополнительных сетей (средствами zebra/quagga/gated/routed/аналогов): IPSEC SPD не содержит маршруты сетей они пишутся вместо этого в таблицу раутинга, где с ними значительно легче разбираться. В варианте же с туннельным IPSEC требуется продираться через глупости конструкции SPD (принципиально требуемый по RFC последовательный порядок правил и отсутствие возможности вставлять правила в начало/середину).
И вариант с транспортным IPSEC и gif внутри — я проверял и он работает, лучше, чем с туннелем :)»
Оставить комментарий