The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Несколько  IPSec соединений-диапазонов одной подсети"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Информационная безопасность (VPN, IPSec / Linux)
Изначальное сообщение [ Отслеживать ]

"Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от lomaker email(ok) on 22-Сен-11, 12:45 
Имеется исходная конфигурация на Zyxel Zywall 35: несколько VPN  каналов, находящихся в одной подсети, соединяются с частичными диапазонами другой подсети следующего вида:

server
192.168.1.0/24-----------------192.168.7.1-192.168.7.5 (клиент 1)
    |       |
    |       -------------------192.168.7.6-192.168.7.10 (клиент 2)
    |
    ---------------------------192.168.7.11-192.168.7.15 (клиент 3)

Сколько не искал в интернете так и не смог найти, как реализовать данную конфигурацию. Насколько я понял конфигурация IPSec в Linux не позволяет задавать диапазон IP, находящихся в одной подсети. Можно только указывать подсеть полностью. Существуют ли реализации IPSec поддерживающие такую возможность? Поддерживает ли ее ipsec-tools и как она реализуется?

Временно решили пробрасывать всю подсеть на каждого клиента. Вот схема:

server
192.168.1.0/24------------------------------------------------------192.168.7.0/24 (клиент 1)
    |       |
    |       ---------------------------------------------------------------192.168.7.0/24 (клиент 2)
    |
    ----------------------------------------------------------------------192.168.7.0/24 (клиент 3)


Ниже представлены конфигурационные файлы:

racoon:

path pre_shared_key "/etc/racoon/psk.txt";

remote 192.168.5.10 {
    exchange_mode_main;

    # Gateway(ike) proposal
    proposal {
        encryption_algorithm des;
        hash_algorithm md5;
        authentication_method pre_shared_key;
        dh_group modp768;
    }
}

remote 192.168.5.11 {
    exchange_mode_main;

    # Gateway(ike) proposal
    proposal {
        encryption_algorithm des;
        hash_algorithm md5;
        authentication_method pre_shared_key;
        dh_group modp768;
    }
}

remote 192.168.5.12 {
    exchange_mode_main;

    # Gateway(ike) proposal
    proposal {
        encryption_algorithm des;
        hash_algorithm md5;
        authentication_method pre_shared_key;
        dh_group modp768;
    }
}

sainfo address 192.168.1.0/24 any address 192.168.7.0/24 any {
    encryption_algorithm des;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
}


ipsec.conf:

#!/usr/sbin/setkey -f
#
#flush SAD and SPD
flush;
spdflush;

# Create policies for racoon
spdadd 192.168.1.0/24 192.168.7.0/24 any -P out ipsec
    esp/tunnel/192.168.5.1-192.168.5.10/require;
    
spdadd 192.168.7.0/24 192.168.1.0/24 any -P in ipsec
    esp/tunnel/192.168.5.10-192.168.5.1/require;


spdadd 192.168.1.0/24 192.168.7.0/24 any -P out ipsec
    esp/tunnel/192.168.5.1-192.168.5.11/require;
    
spdadd 192.168.7.0/24 192.168.1.0/24 any -P in ipsec
    esp/tunnel/192.168.5.11-192.168.5.1/require;


spdadd 192.168.1.0/24 192.168.7.0/24 any -P out ipsec
    esp/tunnel/192.168.5.1-192.168.5.12/require;
    
spdadd 192.168.7.0/24 192.168.1.0/24 any -P in ipsec
    esp/tunnel/192.168.5.12-192.168.5.1/require;

После перезапуска racoon появились следующие ошибки:

# /etc/init.d/racoon restart
* Stopping racoon ...                                                                                                                                                                                                                 [ ok ]
* Flushing policy entries ...                                                                                                                                                                                                         [ ok ]
* Loading ipsec policies from /etc/ipsec.conf.
The result of line 23: File exists.
The result of line 26: File exists.
The result of line 26: File exists.
The result of line 33: File exists.


Возможно я что либо делаю не так? Посоветуйте как правильно? Реализуема ли данная схема?

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от Moomintroll (ok) on 22-Сен-11, 14:26 
> Сколько не искал в интернете так и не смог найти, как реализовать
> данную конфигурацию. Насколько я понял конфигурация IPSec в Linux не позволяет
> задавать диапазон IP, находящихся в одной подсети. Можно только указывать подсеть
> полностью. Существуют ли реализации IPSec поддерживающие такую возможность?

И дело вовсе не в реализации IPSec. Дело в маршрутизации. Если Вы поделите 7-ю сеть на диапазоны, но так, чтобы они могли быть описаны в терминах CIDR, то  можно.

> Временно решили пробрасывать всю подсеть на каждого клиента.

Странное решение...

>[оверквотинг удален]
> spdadd 192.168.1.0/24 192.168.7.0/24 any -P out ipsec
>  esp/tunnel/192.168.5.1-192.168.5.12/require;
> spdadd 192.168.7.0/24 192.168.1.0/24 any -P in ipsec
>  esp/tunnel/192.168.5.12-192.168.5.1/require;
> После перезапуска racoon появились следующие ошибки:
>  * Loading ipsec policies from /etc/ipsec.conf.
> The result of line 23: File exists.
> The result of line 26: File exists.
> The result of line 26: File exists.
> The result of line 33: File exists.

Пральна! Первая пара правил работает. А две другие выдают ошибки, поскольку правила для трафика из сети 192.168.1.0/24 в сеть 192.168.7.0/24 и обратно УЖЕ ЗАДАНЫ.

> Возможно я что либо делаю не так? Посоветуйте как правильно? Реализуема ли
> данная схема?

Данная схема реализуема только если Вы разделите сеть 192.168.7.0/24 на более мелкие подсети для каждого клиента, например 192.168.7.0/22, 192.168.7.64/22, 192.168.7.128/22 и 192.168.7.192/22.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от lomaker email(ok) on 22-Сен-11, 18:04 
> И дело вовсе не в реализации IPSec. Дело в маршрутизации. Если Вы
> поделите 7-ю сеть на диапазоны, но так, чтобы они могли быть
> описаны в терминах CIDR, то  можно.

Уже думал об этом. Данное решение имеет место быть, но это не совсем то. Дело в том что Zywall позволяет пробрасывать любой диапазон IP, при чем они будут с одной маской подсети. И делается это как я понял на уровне политик IPSec. Хотелось бы реализовать в точности такую же конфигурацию на Linux сервере, если конечно это возможно.

>> Временно решили пробрасывать всю подсеть на каждого клиента.
> Странное решение...

В общем то ничего странного, просто вместо диапазона IP будет пролетать вся подсеть.

> Пральна! Первая пара правил работает. А две другие выдают ошибки, поскольку правила
> для трафика из сети 192.168.1.0/24 в сеть 192.168.7.0/24 и обратно УЖЕ
> ЗАДАНЫ.

Я так и понял. Но видимо я неправильно понимаю эти политики. По мне так часть esp/tunnel/192.168.5.1-192.168.5.12/require у них отличается, стало быть и политики должны отличаться. Ан нет - он смотрит на адреса источника и назначения, остального не принимает во внимание!!! Возможно нужно добавить какой-нибудь отличающий их идентификатор, но какой я не знаю...

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от Moomintroll (ok) on 23-Сен-11, 08:47 
>> И дело вовсе не в реализации IPSec. Дело в маршрутизации. Если Вы
>> поделите 7-ю сеть на диапазоны, но так, чтобы они могли быть
>> описаны в терминах CIDR, то  можно.
> Уже думал об этом. Данное решение имеет место быть, но это не
> совсем то. Дело в том что Zywall позволяет пробрасывать любой диапазон
> IP, при чем они будут с одной маской подсети. И делается
> это как я понял на уровне политик IPSec. Хотелось бы реализовать
> в точности такую же конфигурацию на Linux сервере, если конечно это
> возможно.

Вы можете пробросить ЛЮБОЙ диапазон IP-адресов используя любую реализацию IPSec. Но Вы ни при каких условиях не организуете маршрутизацию ОДНОЙ И ТОЙ ЖЕ СЕТИ в три точки!

>>> Временно решили пробрасывать всю подсеть на каждого клиента.
>> Странное решение...
> В общем то ничего странного, просто вместо диапазона IP будет пролетать вся
> подсеть.

В какую из трёх конечных точек?
Каким образом будет определяться в какой из трёх конечных точек находится адресуемый хост?

Т.е. речь идёт о том, что имея в трёх точках сеть 192.168.7.0/24, Вы можете в каждой из трёх точек иметь хост, к примеру, 192.168.7.77. При необходимости отправить из центральной точки пакет хосту с адресом 192.168.7.77 КАК будет определяться конечная точка?

>> Пральна! Первая пара правил работает. А две другие выдают ошибки, поскольку правила
>> для трафика из сети 192.168.1.0/24 в сеть 192.168.7.0/24 и обратно УЖЕ
>> ЗАДАНЫ.
> Я так и понял. Но видимо я неправильно понимаю эти политики. По
> мне так часть esp/tunnel/192.168.5.1-192.168.5.12/require у них отличается, стало быть
> и политики должны отличаться. Ан нет - он смотрит на адреса
> источника и назначения, остального не принимает во внимание!!! Возможно нужно добавить
> какой-нибудь отличающий их идентификатор, но какой я не знаю...

Вы неправильно поняли. Политики следует читать, в данном случае, примерно следующим образом:

spdadd 192.168.1.0/24 192.168.7.0/24 any -P out ipsec
  esp/tunnel/192.168.5.1-192.168.5.12/require;

означает что для исходящий (out) пакета любого протокола (any) из сети 192.168.1.0/24 в сеть 192.168.7.0/24 необходимо (require) использовать транспорт IPSec с шифрованием (esp) в туннельном (tunnel) режиме выполняя шифрование на интерфейсе 192.168.5.1 адресуя ЗАШИФРОВАННЫЙ пакет на адрес 192.168.5.12

Получается, что первой парой правил Вы устанавливаете политики между сетями 192.168.1.0/24 и 192.168.7.0/24. Второй и третьей парой Вы опять пытаетесь установить политики между теми же сетями, а для них политики уже определены, пусть и с другими конечными точками (192.168.5.12)! Именно этот факт вызывает ошибку "File exists".

И ещё раз: принципиальная невозможность реализации Вашей "хотелки" не в возможностях реализаций IPSec, а в МАРШРУТИЗАЦИИ!

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от lomaker email(ok) on 23-Сен-11, 10:41 
Я не претендую на правильность своих действий. Если что-то пишу не так и не в том файле, поправьте пожалуйста!!! Как все это увязывается с помощью маршрутизации? Я уже сломал себе голову в поисках решения!!!

На Zywall когда прописываешь эти самые диапазоны все работает и маршрутизируется как надо!!!

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от Moomintroll (ok) on 23-Сен-11, 10:59 
> На Zywall когда прописываешь эти самые диапазоны все работает и маршрутизируется как
> надо!!!

Вы меня убедили. Используйте ZyWall.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от lomaker email(ok) on 23-Сен-11, 11:00 
> Вы меня убедили. Используйте ZyWall.

В том то и дело что нужно его заменить Linux-машиной!!! Выручайте!!!!!!!!!!!!!!!

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от тень_pavel_simple on 26-Сен-11, 14:13 
>> Вы меня убедили. Используйте ZyWall.
> В том то и дело что нужно его заменить Linux-машиной!!! Выручайте!!!!!!!!!!!!!!!

для решения будет достаточyj поyимания policy routing и этого http://lwn.net/Articles/375829/

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от lomaker email(ok) on 07-Окт-11, 11:54 
С помощью старого доброго метода проб и ошибок удалось установить следующее - попытался как советовали установить соединения сеть->хост и смаршрутизировать трафик через этот хост. В итоге получил такую интересную вещь - трафик с хоста за zyxel не шифруется. Когда же делаю связь типа сеть->сеть все благополучно зашифровалось. Проверял tcpdump-ом. Получается что этот злополучный ip range от zyxel является всего навсего списком шифруемых адресов; трафик с адресов, не попадающих в список передается, но без шифрования. Пытался пробовать различные вариации конфигов racoon и ipsec.conf - безрезультатно.

Предполагаю что это можно сделать с помощью вышеназванной команды ip xfrm или как еще обмануть девайсы? Вопрос только как? Каким-то образом объединить несколько хостов под одну политику, чтобы она смогла согласоваться с политикой zyxel? Опять таки как?

Уважаемые гуру помогите подружить linux с zyxel!!!

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от Deac (ok) on 07-Окт-11, 12:16 
>[оверквотинг удален]
> с хоста за zyxel не шифруется. Когда же делаю связь типа
> сеть->сеть все благополучно зашифровалось. Проверял tcpdump-ом. Получается что этот злополучный
> ip range от zyxel является всего навсего списком шифруемых адресов; трафик
> с адресов, не попадающих в список передается, но без шифрования. Пытался
> пробовать различные вариации конфигов racoon и ipsec.conf - безрезультатно.
> Предполагаю что это можно сделать с помощью вышеназванной команды ip xfrm или
> как еще обмануть девайсы? Вопрос только как? Каким-то образом объединить несколько
> хостов под одну политику, чтобы она смогла согласоваться с политикой zyxel?
> Опять таки как?
> Уважаемые гуру помогите подружить linux с zyxel!!!

Твоя хотелка - оч. странная. :(
Единственное что здесь можно посоветовать - описывать каждого конечного клиента своей политикой.
Т.е. указывать не 192.168.7.0/24, а 192.168.7.1/32 - в один туннель, 192.168.7.2/32 - в другой, 192.168.7.3/32 - в третий и т.д.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от lomaker email(ok) on 07-Окт-11, 12:25 
> Твоя хотелка - оч. странная. :(
> Единственное что здесь можно посоветовать - описывать каждого конечного клиента своей политикой.
> Т.е. указывать не 192.168.7.0/24, а 192.168.7.1/32 - в один туннель, 192.168.7.2/32 -
> в другой, 192.168.7.3/32 - в третий и т.д.

На самом деле очень удобная штука. И что самое главное это реализовано у zyxel! Они как-то нашли решение - значит оно есть :) Можно конечно да и видимо придется в linux прописывать несколько политик. В zywall немножко видимо упростили задачу - вместо того чтобы городить кучу VPN ты указываешь один диапазон. Но вот фишка в том что этот диапазон укладывается в один тоннель - если сделать их много на linux машине такая запись zywall не нравится и тоннель не создается.

У нас много точек с которыми установлены шифрованные каналы, причем за каждой точкой находится еще несколько клиентов, которые по сути и являются этим range. И все эти клиенты находятся кроме всего прочего в одной подсети. Вот потому и необходимо сохранить все как есть, при этом заменив центр с zywall на linux-сервер.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от Deac (ok) on 07-Окт-11, 12:29 
>[оверквотинг удален]
>> Единственное что здесь можно посоветовать - описывать каждого конечного клиента своей политикой.
>> Т.е. указывать не 192.168.7.0/24, а 192.168.7.1/32 - в один туннель, 192.168.7.2/32 -
>> в другой, 192.168.7.3/32 - в третий и т.д.
> На самом деле очень удобная штука. И что самое главное это реализовано
> у zyxel! Они как-то нашли решение - значит оно есть :)
> У нас много точек с которыми установлены шифрованные каналы, причем за каждой
> точкой находится еще несколько клиентов, которые по сути и являются этим
> range. И все эти клиенты находятся кроме всего прочего в одной
> подсети. Вот потому и необходимо сохранить все как есть, при этом
> заменив центр с zywall на linux-сервер.

Чем удобная?
Никакая сила не спасёт от тупого клиента, установившего себе адрес из уже имеющихся в другом туннеле.
И получится: шлёт он запросы в один туннель, а раутер инкапсулирует ответы в другой, у него так прописано, как итог - оч. тяжело диагностируемая каша.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от lomaker email(ok) on 07-Окт-11, 12:32 
> Чем удобная?
> Никакая сила не спасёт от тупого клиента, установившего себе адрес из уже
> имеющихся в другом туннеле.
> И получится: шлёт он запросы в один туннель, а раутер инкапсулирует ответы
> в другой, у него так прописано, как итог - оч. тяжело
> диагностируемая каша.

Чем удобная - внес поправку выше. :)
Насчет каши ничего не могу сказать - нужно пробовать.
Тем не менее ищу решение - если имеется.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от a2l email on 12-Окт-11, 14:51 
>> Твоя хотелка - оч. странная. :(
>> Единственное что здесь можно посоветовать - описывать каждого конечного клиента своей политикой.
>> Т.е. указывать не 192.168.7.0/24, а 192.168.7.1/32 - в один туннель, 192.168.7.2/32 -
>> в другой, 192.168.7.3/32 - в третий и т.д.
> На самом деле очень удобная штука. И что самое главное это реализовано
> у zyxel! Они как-то нашли решение - значит оно есть :)

Раз есть решение, значит есть и задача. Сформулируй свою задачу и покажи в каком месте решение с диапазоном предпочтительнее чем с подсетями.

>[оверквотинг удален]
> В zywall немножко видимо упростили задачу - вместо того чтобы городить
> кучу VPN ты указываешь один диапазон. Но вот фишка в том
> что этот диапазон укладывается в один тоннель - если сделать их
> много на linux машине такая запись zywall не нравится и тоннель
> не создается.
> У нас много точек с которыми установлены шифрованные каналы, причем за каждой
> точкой находится еще несколько клиентов, которые по сути и являются этим
> range. И все эти клиенты находятся кроме всего прочего в одной
> подсети. Вот потому и необходимо сохранить все как есть, при этом
> заменив центр с zywall на linux-сервер.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

14. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от lomaker email(ok) on 12-Окт-11, 15:49 
> Раз есть решение, значит есть и задача. Сформулируй свою задачу и покажи
> в каком месте решение с диапазоном предпочтительнее чем с подсетями.

Метод от противного? К чему? У вас есть реальное решение? Тогда есть смысл обосновывать, иначе не вижу смысла!!!

P.S. Задача сформулирована в самом начале.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от a2l email on 13-Окт-11, 13:54 
>> Раз есть решение, значит есть и задача. Сформулируй свою задачу и покажи
>> в каком месте решение с диапазоном предпочтительнее чем с подсетями.
> Метод от противного? К чему? У вас есть реальное решение? Тогда есть
> смысл обосновывать, иначе не вижу смысла!!!
> P.S. Задача сформулирована в самом начале.

В самом начале предложили решение - разбить 192.168.7.0/24 на подсети (192.168.7.1/29, 192.168.7.8/29 и тд) , но вас такое решение не устраивает. Вам обязательно нужен диапазон -- почему?

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

16. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от lomaker email(ok) on 13-Окт-11, 14:54 
> В самом начале предложили решение - разбить 192.168.7.0/24 на подсети (192.168.7.1/29,
> 192.168.7.8/29 и тд) , но вас такое решение не устраивает. Вам
> обязательно нужен диапазон -- почему?

Взять хотя бы факт добавления маршрутов - или прописать каждому пользователю один маршрут или 25...50...!!!

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

17. "Несколько  IPSec соединений-диапазонов одной подсети"  +/
Сообщение от a2l email on 14-Окт-11, 05:53 
>> В самом начале предложили решение - разбить 192.168.7.0/24 на подсети (192.168.7.1/29,
>> 192.168.7.8/29 и тд) , но вас такое решение не устраивает. Вам
>> обязательно нужен диапазон -- почему?
> Взять хотя бы факт добавления маршрутов - или прописать каждому пользователю один
> маршрут или 25...50...!!!

уважаемый, вам предложили сформулировать задачу, а вы какой-то бред несёте.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру