[Tonny_Bennet]

Всё оказалось не так сложно как могло показаться на первый взгляд.

Для тестов оставил Mikrotik дома. Отключил в нём фаервол для доступа из вне. Между офисным шлюзом и домом сначала поднял GRE тунель.
Пример для ubuntu пример для MikroTik, к слову, если создавать его из GUI или веб интерфейса - нужно отдельно создать адрес и отдельно создать сам тунель. После поднятия тунеля железки видят друг друга через тунельные интерфейсы.

Для запуска динамической маршрутизации в Ubuntu понадобилось поставить один пакет и немного его настроить. Вот пример под CentOS, но у меня он заработал без проблем, после я закоментировал строку про "соседа", которая явно на него указывает, выключил пароли (почему-то не заработали с МТ), изменил ID зоны т.к. MT понимает ID похожие на IP адрес я указал 0.0.0.1. В Микротике всё настраивается аналогично, просто в нескольких окнах: отдельно зона, отдельно сети и интерфейсы. Всё заработало достаточно быстро маршруты прописались пакеты побежали, правда в логах увидел нестыковку MTU тунельных интерфейсов и быстренько поправил.

С шифрованием бился очень долго, ибо мне нужен не тунельный, а транспортный режим: IPSec только шифрует канал и не создаёт тунель. Пакет racoon под ubuntu в принципе не завёлся. Остановился на openswan. Путём проб и ошибок дошёл до вот такого конфига:

Код:

config setup
    nat_traversal=yes
    protostack=netkey

conn mikrotik #Подключение к Mikrotik
    type=transport
    authby=secret
    left=<внешний IP адрес Ubuntu>
    right=<внешний IP адрес MikroTik>
    esp=3des-sha1
    ike=3des-md5-modp1024
    keylife=8h
    keyexchange=ike
    auto=start

В отдельном файле храниться PSK. Со стороны МТ нужно сделать аналогичные настройки шифрования и авторизации, и указать в качестве пира ip адрес Ubuntu. Сделать политики, в которых шифруется весь трафик между внешними интерфейсами. (Сейчас я переделал и у меня шифруется только протокол GRE, но насколько это безопасно и обосновано я пока не знаю).

В итоге у меня сейчас есть две точки, связанные тунелем GRE, с поднятой динамической маршрутизацией по OSPF и шифрующийся трафик. Дальше попробую перевести все точки Ubuntu на подобную схему и быть может перейду на HW маршрутизаторы от MikroTik.

Из вопросов которые накопились в процессе создания всего:

Для GRE тунеля между двумя точками я взял подсеть 192.168.20.0/30. 192.168.20.1 со стороны Ubuntu, 192.168.20.2 со стороны MT. В спецификации и настройках OSPF сказано, что маршрутизатор ищет соседей путём рассылки широковещательных пакетов. Стоит ли мне при подключении ещё одного узла выделять ещё одну /30 сеть или можно расширить существующую с /30 до /29 и использовать адреса для других тунелей из /29 сети? Намного ли это упростит работу OSPF?

Я очень мало сталкивался с шифрованием и защитой информации, к слову в pptp настраивается три типа авторизации и три типа шифрования. Сейчас авторизация проходит по PSK, как мне кажется это не самое лучшее решение. У IPSec возможностей намного больше и если не сложно поясните на пальцах что лучше использовать в соотношении цена/качество (безопасность/нагрузка на оборудование)? Может есть в сети адекватные обзоры по данной тематике?

Про мои опасения по поводу падения IPSec. В схеме три элемента: GRE тунель, демон OSPF маршрутизации, IPSec шифрование.
Если падает тунель, OSPF удаляет маршрут - трафик никуда не пойдёт.
Если упадёт OSPF, маршрутов опять таки не будет и трафик не пойдёт.
Если отключится IPSec - одна из сторон будет отправлять шифрованный трафик, а вторая не шифрованый. Связи не будет, но перехватив пакеты с не шифрованной стороны наверное можно что-то из-них получить.

[exo]

Если отключится IPSec - одна из сторон будет отправлять шифрованный трафик, а вторая не шифрованый. Связи не будет, но перехватив пакеты с не шифрованной стороны наверное можно что-то из-них получить. »

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

к сожалению, не могу помочь с вашей инфраструктурой, но могу предложить следующий вариант, но с перестрой схемы сети и добавления оборудования:
сделать VPN S2S через OpenVPN или IPSec только для нужных направлений.
для каждого туннеля выбрать свою сеть.
для всех сетей руками записать маршруты (не ленитесь).

[Tonny_Bennet]

ну так запретите отправлять нешифрованный трафик. »

Пока некогда, но реально сделать добавив в фаервол правило, которое будет убивать не шифрованные пакеты (проверять по флагу ESP).

для всех сетей руками записать маршруты (не ленитесь). »

Динамические как оказалось ничем не хуже. Сами поднимаются, сами удаляются, меняется метрика в зависимости от "стоимости" маршрута и т.д.
Пока работают три маршрутизатора, планируется ещё.

[User001]

Динамические как оказалось ничем не хуже. Сами поднимаются, сами удаляются, меняется метрика в зависимости от "стоимости" маршрута и т.д. »

Раз уж поднимаете интерес к теме. Интересно насчет того, все ли сразу поднялось, т.к. OSPF же мультикаст гоняет, поэтому видел рекомендации насчет L2 между роутерами с OSPF.

[Tonny_Bennet]

Интересно насчет того, все ли сразу поднялось, т.к. OSPF же мультикаст гоняет, »

OSPF поднялась не сразу, но там были проблемы в том, что я неверно указал идентификатор зоны (сейчас он 0.0.0.1). Да и всё прекрасно отображалось в логах. По поводу мультикаста: он гоняет его только на стыковочных GRE интерфейсах в пределах /30-й сети.

видел рекомендации насчет L2 между роутерами с OSPF. »

Т.е. о L2 тунелях между маршрутизаторами? Насколько я понял из всего что прочитал о OSPF он использует многоадресную L3 рассылку.