Имеется исходная конфигурация на 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.
Возможно я что либо делаю не так? Посоветуйте как правильно? Реализуема ли данная схема?
> Сколько не искал в интернете так и не смог найти, как реализовать
> данную конфигурацию. Насколько я понял конфигурация 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.
> И дело вовсе не в реализации 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 у них отличается, стало быть и политики должны отличаться. Ан нет - он смотрит на адреса источника и назначения, остального не принимает во внимание!!! Возможно нужно добавить какой-нибудь отличающий их идентификатор, но какой я не знаю...
>> И дело вовсе не в реализации 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, а в МАРШРУТИЗАЦИИ!
Я не претендую на правильность своих действий. Если что-то пишу не так и не в том файле, поправьте пожалуйста!!! Как все это увязывается с помощью маршрутизации? Я уже сломал себе голову в поисках решения!!!На Zywall когда прописываешь эти самые диапазоны все работает и маршрутизируется как надо!!!
> На Zywall когда прописываешь эти самые диапазоны все работает и маршрутизируется как
> надо!!!Вы меня убедили. Используйте ZyWall.
> Вы меня убедили. Используйте ZyWall.В том то и дело что нужно его заменить Linux-машиной!!! Выручайте!!!!!!!!!!!!!!!
>> Вы меня убедили. Используйте ZyWall.
> В том то и дело что нужно его заменить Linux-машиной!!! Выручайте!!!!!!!!!!!!!!!для решения будет достаточyj поyимания policy routing и этого http://lwn.net/Articles/375829/
С помощью старого доброго метода проб и ошибок удалось установить следующее - попытался как советовали установить соединения сеть->хост и смаршрутизировать трафик через этот хост. В итоге получил такую интересную вещь - трафик с хоста за zyxel не шифруется. Когда же делаю связь типа сеть->сеть все благополучно зашифровалось. Проверял tcpdump-ом. Получается что этот злополучный ip range от zyxel является всего навсего списком шифруемых адресов; трафик с адресов, не попадающих в список передается, но без шифрования. Пытался пробовать различные вариации конфигов racoon и ipsec.conf - безрезультатно.Предполагаю что это можно сделать с помощью вышеназванной команды ip xfrm или как еще обмануть девайсы? Вопрос только как? Каким-то образом объединить несколько хостов под одну политику, чтобы она смогла согласоваться с политикой zyxel? Опять таки как?
Уважаемые гуру помогите подружить linux с zyxel!!!
>[оверквотинг удален]
> с хоста за 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 - в третий и т.д.
> Твоя хотелка - оч. странная. :(
> Единственное что здесь можно посоветовать - описывать каждого конечного клиента своей политикой.
> Т.е. указывать не 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-сервер.
>[оверквотинг удален]
>> Единственное что здесь можно посоветовать - описывать каждого конечного клиента своей политикой.
>> Т.е. указывать не 192.168.7.0/24, а 192.168.7.1/32 - в один туннель, 192.168.7.2/32 -
>> в другой, 192.168.7.3/32 - в третий и т.д.
> На самом деле очень удобная штука. И что самое главное это реализовано
> у zyxel! Они как-то нашли решение - значит оно есть :)
> У нас много точек с которыми установлены шифрованные каналы, причем за каждой
> точкой находится еще несколько клиентов, которые по сути и являются этим
> range. И все эти клиенты находятся кроме всего прочего в одной
> подсети. Вот потому и необходимо сохранить все как есть, при этом
> заменив центр с zywall на linux-сервер.Чем удобная?
Никакая сила не спасёт от тупого клиента, установившего себе адрес из уже имеющихся в другом туннеле.
И получится: шлёт он запросы в один туннель, а раутер инкапсулирует ответы в другой, у него так прописано, как итог - оч. тяжело диагностируемая каша.
> Чем удобная?
> Никакая сила не спасёт от тупого клиента, установившего себе адрес из уже
> имеющихся в другом туннеле.
> И получится: шлёт он запросы в один туннель, а раутер инкапсулирует ответы
> в другой, у него так прописано, как итог - оч. тяжело
> диагностируемая каша.Чем удобная - внес поправку выше. :)
Насчет каши ничего не могу сказать - нужно пробовать.
Тем не менее ищу решение - если имеется.
>> Твоя хотелка - оч. странная. :(
>> Единственное что здесь можно посоветовать - описывать каждого конечного клиента своей политикой.
>> Т.е. указывать не 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-сервер.
> Раз есть решение, значит есть и задача. Сформулируй свою задачу и покажи
> в каком месте решение с диапазоном предпочтительнее чем с подсетями.Метод от противного? К чему? У вас есть реальное решение? Тогда есть смысл обосновывать, иначе не вижу смысла!!!
P.S. Задача сформулирована в самом начале.
>> Раз есть решение, значит есть и задача. Сформулируй свою задачу и покажи
>> в каком месте решение с диапазоном предпочтительнее чем с подсетями.
> Метод от противного? К чему? У вас есть реальное решение? Тогда есть
> смысл обосновывать, иначе не вижу смысла!!!
> P.S. Задача сформулирована в самом начале.В самом начале предложили решение - разбить 192.168.7.0/24 на подсети (192.168.7.1/29, 192.168.7.8/29 и тд) , но вас такое решение не устраивает. Вам обязательно нужен диапазон -- почему?
> В самом начале предложили решение - разбить 192.168.7.0/24 на подсети (192.168.7.1/29,
> 192.168.7.8/29 и тд) , но вас такое решение не устраивает. Вам
> обязательно нужен диапазон -- почему?Взять хотя бы факт добавления маршрутов - или прописать каждому пользователю один маршрут или 25...50...!!!
>> В самом начале предложили решение - разбить 192.168.7.0/24 на подсети (192.168.7.1/29,
>> 192.168.7.8/29 и тд) , но вас такое решение не устраивает. Вам
>> обязательно нужен диапазон -- почему?
> Взять хотя бы факт добавления маршрутов - или прописать каждому пользователю один
> маршрут или 25...50...!!!уважаемый, вам предложили сформулировать задачу, а вы какой-то бред несёте.