Есть такая конфигурация.
1. Имеется 2 компьютера А и Б.
2. Компьютеры А и Б являются шлюзами для двух разных сетей (192.168.0.0/24 и 192.168.2.0/24).
3. К Каждому из компьютеров подключено по два канала интернета от 2х разных провайдеров
4. Между шлюзами настроено работающее ВПН соединение с помошью openswan
5. Используется включенная в ядро реализация IPSEC NETKEYВопрос:
1. В конфигурации ipsec.conf прописано 2 ipsec соединения: P1 - P1 (d.d.e.e - d.d.f.f) и P2 - P2 (a.a.b.b - a.a.c.c). При поднятии командой ipsec auto --up P1-P1 встает 1е ВПН соединение. Второе соединение также поднимается и работает. Если поднимать одно из IPSEC соединений в тот момент когда уже работает другое соединение, то поднимаемый ВПН заменяет собой работающий после чего, ранее работающее соединение опускается.
Можно ли заставить работать оба соединения и распределить между ними трафик в соотножении 3:7.
2. Можно ли поднимать одно соединение, но реализовать автоматическое переключение каналов в случае обрыва связи? С помошью каких инструментов можно этого добиться?Буду благодарен разного рода ссылкам на материал по данной теме.
P.S. Зарание спасибо.
>Вопрос:
> 1. В конфигурации ipsec.conf прописано 2 ipsec соединения: P1 -
>P1 (d.d.e.e - d.d.f.f) и P2 - P2 (a.a.b.b - a.a.c.c).
>При поднятии командой ipsec auto --up P1-P1 встает 1е ВПН соединение.
>Второе соединение также поднимается и работает. Если поднимать одно из IPSEC
>соединений в тот момент когда уже работает другое соединение, то поднимаемый
>ВПН заменяет собой работающий после чего, ранее работающее соединение опускается.
> Можно ли заставить работать оба соединения иДумаю, что сделан net-to-net туннель. Я бы предложил сделать два host-to-host, а через них уже роутить сети.
>распределить между ними трафик в соотножении 3:7.
Если будет 2 туннеля (т.е. 3 интерфейса) то можно
> 2. Можно ли поднимать одно соединение, но реализовать автоматическое переключение
>каналов в случае обрыва связи? С помошью каких инструментов можно этого
>добиться?Э... Я думаю можно. Только выглядить это должно несколько монстрообразно:
ipsec tunnel host-to-host
в него засунуть GRE
внутри GRE уже будет работать link-state протокол (OSPF).
Вск в целом должно обеспечивать быстрое переключение при падении одного из каналов.
>Буду благодарен разного рода ссылкам на материал по данной теме.Прости, ссылок нет. Это то, как сделал бы я - возможно есть и более простые решения
>
>Если будет 2 туннеля (т.е. 3 интерфейса) то можноЕсли будет 2 туннеля (т.е. _2_ интерфейса) то можно
>Э... Я думаю можно. Только выглядить это должно несколько монстрообразно:Были бы зеленые президенты на цыски было бы касиво, а так как их нет будет "монстрообразно" :D
>ipsec tunnel host-to-hostВот это навело меня на правильные мысли.
>в него засунуть GRE
>внутри GRE уже будет работать link-state протокол (OSPF).Про это тоже где-то читал. Но не понял как реализовать в соединениях net-to-net с host-to-host все становиться на много понятнее.
>Вск в целом должно обеспечивать быстрое переключение при падении одного из каналов.Огромное админское пасиба.
>Э... Я думаю можно. Только выглядить это должно несколько монстрообразно:
>ipsec tunnel host-to-host
>в него засунуть GRE
>внутри GRE уже будет работать link-state протокол (OSPF).
>Вск в целом должно обеспечивать быстрое переключение при падении одного из каналов.Вобщем реализовал я все задуманное. Удалил Openswan (пробовал юзать racoon но что-то он мне тоже не понравился) сделал ipsec соединения host-to-host с помошью ipsec-tools (конкретно setkey). далее в эти шифрованные соединения засунул gre туннели. На шлюзах появились интерфейсы типа gre+ по интерфейсу на тоннель. И все сразу стало красиво и понятно.
Было бы все просто отлично если бы не один неприятный момент. Некоторые туннели, если их не использовать (не гонять по ним трафик), отваливаются или зависают (10-15 минут может меньше). С основного шлюза, который объединяет филиалы, удаленные сети становятся не доступными. Для того что бы оживить эти туннели достаточно зайти на удаленный шлюз с внешней дырки и послать пинг на главный шлюз (по канальным ипам) и сразу наступает счастье.Собственно пока не нашел красивого решения, посылаю пинг с филиальных шлюзов в скрипте запускаемого по крону 1 раз в минуту.
Есть какие либо соображения по этому поводу?
P.S. читаю маны по OSPF (пакет quagga) не совсем понимаю что к чему. Есть ссылки на примеры внедрения?
>>Э... Я думаю можно. Только выглядить это должно несколько монстрообразно:
>>ipsec tunnel host-to-host
>>в него засунуть GRE
>>внутри GRE уже будет работать link-state протокол (OSPF).
>>Вск в целом должно обеспечивать быстрое переключение при падении одного из каналов.
>
>Вобщем реализовал я все задуманное. Удалил Openswan (пробовал юзать racoon но что-то
>он мне тоже не понравился) сделал ipsec соединения host-to-host с помошью
>ipsec-tools (конкретно setkey).э... а разве ipsec-tools и racoon не есть одно и тоже (в смысле пакеджа)? ;-)
racoon это же isakmp daemon из ipsec-tools (или я уже совсем плохой стал? - надо сходить посмотреть....)>На шлюзах появились интерфейсы типа gre+ по интерфейсу на тоннель. И
>все сразу стало красиво и понятно.
>Было бы все просто отлично если бы не один неприятный момент. Некоторые
>туннели, если их не использовать (не гонять по ним трафик), отваливаются
>или зависаютну дык DPD (это будет что-то типа keep-alive) + поднятие туннеля если он на самом деле свалился
>эти туннели достаточно зайти на удаленный шлюз с внешней дырки и
>послать пинг на главный шлюз (по канальным ипам) и сразу наступает
>счастье.imho overkill
>Есть какие либо соображения по этому поводу?
А как же... Их есть несколько: DPD - это раз, LSA (это от OSPF) - это два. Любой из них будет поддерживать тоннель
>P.S. читаю маны по OSPF (пакет quagga) не совсем понимаю что к
>чему. Есть ссылки на примеры внедрения?На сайте квагги вроде есть примеры... если нужна конкретика - т.е. конкретные сети, адреса, топология - то в приват fish at infonet.nnov.ru (смогу ответить только после четверга).
>э... а разве ipsec-tools и racoon не есть одно и тоже (в
>смысле пакеджа)? ;-)
>racoon это же isakmp daemon из ipsec-tools (или я уже совсем плохой
>стал? - надо сходить посмотреть....)Не знаю, как в смысле пакеджа, но isakmpd и racoon это разные вещи.
Хотя, конечно, функционально это одно и то же.
Racoon, кстати, хуже. Проблеме с закусыванием ключей при работе с Win или Cisco уже черт знает сколько лет, но ее так и не победили.
>
>>э... а разве ipsec-tools и racoon не есть одно и тоже (в
>>смысле пакеджа)? ;-)
>>racoon это же isakmp daemon из ipsec-tools (или я уже совсем плохой
>>стал? - надо сходить посмотреть....)
>
>Не знаю, как в смысле пакеджа, но isakmpd и racoon это разные
>вещи.Ну я все-таки сказал верно: racoon - это ISAKMP/IKE daemon из состава ipsec-tools.
isakmpd - это OpenBSD'шный ISAKMP/IKE daemon. Что это одно и тоже я _не_ утверждал.>Racoon, кстати, хуже. Проблеме с закусыванием ключей при работе с Win или
>Cisco уже черт знает сколько лет, но ее так и не победили.Сергей Лозовский пофиксил это некоторое время назад.
>>
>>>э... а разве ipsec-tools и racoon не есть одно и тоже (в
>>>смысле пакеджа)? ;-)
>>>racoon это же isakmp daemon из ipsec-tools (или я уже совсем плохойНет не входит :D Но это не суть как важно.
>[оверквотинг удален]
>
>Ну я все-таки сказал верно: racoon - это ISAKMP/IKE daemon из состава
>ipsec-tools.
>isakmpd - это OpenBSD'шный ISAKMP/IKE daemon. Что это одно и тоже я
>_не_ утверждал.
>
>>Racoon, кстати, хуже. Проблеме с закусыванием ключей при работе с Win или
>>Cisco уже черт знает сколько лет, но ее так и не победили.
>
>Сергей Лозовский пофиксил это некоторое время назад.
>>>>racoon это же isakmp daemon из ipsec-tools (или я уже совсем плохой
>
>Нет не входит :D Но это не суть как важно.Ага ;-)
http://ipsec-tools.sourceforge.net/IPsec-Tools
Contents:
libipsec - Library with PF_KEY implementation.
setkey - Tool to manipulate and dump the kernel Security Policy Database (SPD) and Security Association Database (SAD).
racoon - Internet Key Exchange (IKE) daemon for automatically keying IPsec connections.
racoonctl - A shell-based control tool for racoon
>[оверквотинг удален]
>http://ipsec-tools.sourceforge.net/
>
>IPsec-Tools
>Contents:
>libipsec - Library with PF_KEY implementation.
>setkey - Tool to manipulate and dump the kernel Security Policy Database
>(SPD) and Security Association Database (SAD).
>racoon - Internet Key Exchange (IKE) daemon for automatically keying IPsec connections.
>
>racoonctl - A shell-based control tool for racoonГы. В Debian это разные пакеты причем ipsec-tools не зависит от racoon.
[...]
>
>э... а разве ipsec-tools и racoon не есть одно и тоже (в
>смысле пакеджа)? ;-)
>racoon это же isakmp daemon из ipsec-tools (или я уже совсем плохой
>стал? - надо сходить посмотреть....)
>[...]
Разные в том то и дело что разные. racoon средство для динамической смены ключиков.
>
>ну дык DPD (это будет что-то типа keep-alive) + поднятие туннеля если
>он на самом деле свалился
>[...]
>
>imho overkill
>[...]
>
>А как же... Их есть несколько: DPD - это раз, LSA (это
>от OSPF) - это два. Любой из них будет поддерживать тоннель
>
>[...]
Уже понял как с этим бороться. Но всеравно спасибо.
>
>На сайте квагги вроде есть примеры... если нужна конкретика - т.е. конкретные
>сети, адреса, топология - то в приват fish at infonet.nnov.ru (смогу
>ответить только после четверга).Да обязательно напишу.
Зашел, зарегался. Так и не понял как в приват написать :(
>Да обязательно напишу.
>Зашел, зарегался. Так и не понял как в приват написать :(это мой почтовый адрес
>
>>Да обязательно напишу.
>>Зашел, зарегался. Так и не понял как в приват написать :(
>
>это мой почтовый адресfish at infonet.nnov.ru
at - понял дословно "в" :D