Может ли Softether VPN Full-Mesh

Всмысле чтобы он туннели строил сам, без настройки? Аля DMVPN цыскин?

Нет. Мне нужно чтобы трафик шел по кратчайшему маршруту.

Скажем физически имеются три филиала с такими настройками. 1 филиал подсеть 192.168.1.0/24 GW 192.168.1.1 2 филиал подсеть 192.168.2.0/24 GW 192.168.2.1 3 филиал подсеть 192.168.3.0/24 GW 192.168.3.1

Я могу настроить примитивные маршруты

1 Филиал 192.168.2.0/24 -> Внешний IP Филиала 2 192.168.3.0/24 -> Внешний IP Филиала 3

2 Филиал 192.168.1.0/24 -> Внешний IP Филиала 1 192.168.3.0/24 -> Внешний IP Филиала 3

3 Филиал 192.168.1.0/24 -> Внешний IP Филиала 1 192.168.2.0/24 -> Внешний IP Филиала 2

Ну и настроив фаервол чтобы пакеты проходили я получу не защищенную связь между филиалами, по кратчайшему маршруту. Общая работоспособность сети не зависит доступности любого филиала.

С VPN мы получаем этакий виртуальный свич к которому подключены все узлы сети, но трафик физически сначала идет на главный VPN сервер, а только потом на узел назначения. Если VPN сервер упадет, упадет весь VPN.

Мне нужно чтобы при VPN схеме трафик направлялся сразу в узел назначения, и чтобы при падении VPN сервера фактически работоспособность сети не падала.

Эту фичу называют поразному P2P VPN, Full-Mesh VPN. Знаю что такое умеет проприетарный Hamachi, пробовал tinc но он не стабилен.

Поэтому спрашиваю может ли такое Softether VPN?

есть три филиала

А о чем тут думать вообще? Свяжи каждый с каждым и всё.

А как это будет выглядеть с VPN? В ручную создавать n подключений, а затем при добавлении нового филиала проводить до настройку в каждом филиале?

http://habrahabr.ru/post/150151/

Это можно реализовать любым VPN-ом(по одному соединению на пару филиалов + ospfd/bgpd), но DM-VPN на цисках делает это удобнее всего.

да это простыми бриджами решится.

Спасибо, видел. А по сабжу?

На циску денег не дадут, надо Open Source, маршрутизаторы на Linux\Windows

маршрутизаторы на Linux\Windows

печалька но SEV для этого и сделан. у меня есть опыт подобных решений. за печеньки помогу.

Я смотрел SoftEther как только он стал OpenSource, и в нем этого нельзя было сделать из коробки. Рекомендую вам tinc.

Последний релиз 11-May-2014. Попробую может под Win стал более стабилен.

Ну в крайнем случае поднимишь под Win, виртуалочку с любым Linux.

А, у тебя филиалы добавляются.
Ну тады ой.

а затем при добавлении нового филиала проводить до настройку в каждом филиале?

Вроде бы без этого никак.

О, живой юзер tinc!
Оно умеет само оповещать всех участников при добавлении нового сервера? Ну, что-то вроде «указал ему ближайшего соседа, а дальше всё само»?

Я могу настроить примитивные маршруты

1 Филиал 192.168.2.0/24 -> Внешний IP Филиала 2 192.168.3.0/24 -> Внешний IP Филиала 3

2 Филиал 192.168.1.0/24 -> Внешний IP Филиала 1 192.168.3.0/24 -> Внешний IP Филиала 3

3 Филиал 192.168.1.0/24 -> Внешний IP Филиала 1 192.168.2.0/24 -> Внешний IP Филиала 2

Это чушь, так работать не будет.

пробовал tinc но он не стабилен.

В чем конкретно нестабильность?

Самый простой в реализации вариант, если филиалов не планируется очень много - просто создать на каждом туннели до всех других через openvpn или ipsec+gre и на каждом ротуере запустить quagga/ospf для анонсов своих сетей - траффик пойдёт всегда оптимально. Раскидывать туннели можно централизованно какой-нибудь системой вроде puppet/chef.

С этими хипсторскими чефопаппетами одмины уже и rsync+ssh позабыли, брезгуют...

Да зачем там протокол маршрутизации, если связывать каждый с каждым. Как ни крути - один хоп из конца в конец.

Я им не пользуюсь. Вроде, не умеет он так.

Ну, я просто от статики стараюсь отказываться, мало ли какую еще сеть сбоку одного из филиалов добавят - нужно будет везде ее хреначить, а так само анонсирует.

Я им не пользуюсь.

Эх.

Это чушь, так работать не будет.

What? Если не блочится у провайдера по source IP то почему не пройдет?

В чем конкретно нестабильность?

Тупо пинги пропадают, сейчас уже не помню связь терял и сам не переподнимал.

Оно умеет само оповещать всех участников при добавлении нового сервера?

Насколько я знаю ничего не умеет, но добавлять филиал достаточно скопировать папочку с настройками, и возможно ее можно хранить в одном месте видном отовсюду....

А научи. На данный момент я не понимаю, как при добавлении новой сети «сбоку филиала» можно обойтись без донастройки ipsec'овых описаний.

PC-to-PC Это то?

https://www.softether.org/4-docs/1-manual/A._Examples_of_Building_VPN_Network...

Ну смотри, у тебя есть роутер, за ним некая сеть. У него туннельных интерфейсов куча до других роутеров и он в эти интерфейсы свою эту сеть анонсирует по OSPF. Потом ты к этому роутеру еще сеть подключаешь и добавляешь ее в конфиг ospf для анонса, всё, удаленные роутеры автоматически имеют ее у себя в таблице роутинга.

IPSEC ессесно в транспортном режиме должен быть и шифровать только подключения между хостами-роутерами, а сам роутинг через GRE туннели.

What? Если не блочится у провайдера по source IP то почему не пройдет?

Как ты собрался добавлять маршрут до некоей сети через IP адрес, который на другом конце интернета находится, м?

Спасибо, понял.

Эмм я был уверен... но видимо я ошибался... Получается маршрутизатор назначения должен быть в Broadcast домене...

route: netmask 000000ff doesn't make sense with host route

Получается маршрутизатор назначения должен быть в Broadcast домене...

Само собой. И не обязательно в броадкаст, а может быть просто p2p интерфейс, обычно так и бывает. Поэтому прогрессивное человечество придумало туннели, через которые можно роутить спокойно хоть через пол-мира :)

Сейчас в ядре вроде появилась возможность не юзать GRE, а вместо него использовать IPSEC VTI (Virtual Tunnel Interface), сам не пробовал, но по идее оверхеда должно быть меньше.

Вопрос еще в том, будет ли через него ходить мультикаст (по которому работает OSPF), а то иначе придётся в OSPF прописывать соседей, что усложняет настройку. Через ipip туннели (которые имеют меньший оверхед чем GRE), например, не ходит.

Оно умеет само оповещать всех участников при добавлении нового сервера? Ну, что-то вроде «указал ему ближайшего соседа, а дальше всё само»?

Есть в разрабатываемой ветке 1.1 - http://tinc-vpn.org/documentation-1.1/tinc-commands.html см. команды «invite» и «join».

Может, поделишься публично с сообществом?

IPSEC VTI (Virtual Tunnel Interface)

Во блин, я даже не знаю, что это. Надо будет покурить.

По доке не очень понятно, как именно оно работает. Ну, или надо все маны курить, а лень же. Вот бы кто историю успеха рассказал - было бы хоть ясно, что оно того стоит.

Ну тогда OpenVPN+Quagga(на Linux) и тоже самое вкупе с службой маршрутизации - на Windows. В качестве протокола маршрутизации можно выбрать RIP(т.к. OSPF в винде закопали с 2008)

Да зачем там протокол маршрутизации, если связывать каждый с каждым. Как ни крути - один хоп из конца в конец.

чтобы не заморачиваться прописыванием кучи статики при добавлении нового филиала(а ТСу это критично, судя по тому что филиалы добавлятся будут)

IPSEC ессесно в транспортном режиме должен быть и шифровать только подключения между хостами-роутерами, а сам роутинг через GRE туннели.

Я тоже такую схему замутил в своё время(IPSEC+GRE) - работает просто отлично.

Вопрос еще в том, будет ли через него ходить мультикаст (по которому работает OSPF)

я вообще подумываю заменить OSPF на iBGP между филиалами. Один хрен - соединение точка-точка, так что мультикаст там - нафиг не упёрся. А у меня до каждого филиала всё равно своя OSPF area(для безопасности).

А вот blind_oracle, например, заметил оборот «если связывать каждый с каждым».

Как раз если связывать каждый с каждым, динамическая маршрутизация выигрывает, если точек связывания >2, конечно :-)

При этом если связывать сети каждую с каждой _и сети имеют постоянный адрес_, то динамическая маршрутизация там вообще ни к чему.
Имею в виду наиболее частый факап, т.е. «какая-то из сетей недоступна никому извне».

Он имеет в виду, что для прописывания нового филиала один фиг нужно будет туннель делать - добавить заодно и маршрут через него проблем не составит.

Другое дело - если адресация сетей в филиалах будет меняться или новые сети добавляться - тогда без динамики придётся туго, так что лучше сразу делать с ней.