tinc или gre+ipsec?

Может я чего-то не понимаю, но зачем gre? ipsec же и так работает.

А дальше я вобще запутался, началось всё с серверов в датацентрах, а кончилось каким-то натом и внутреними сетями. Лично я не вижу смысла разных задач обязательно делать один впн-сервер.

У ipsec я не осилил туннельный режим.

А что дальше непонятного? Есть сервера, на серверах есть виртуалки/контейнеры. К этим виртуалкам надо цепляться, логи смотреть, базы ковырять, дебажить приложения и тому подобное. Белые адреса выделять им сильно жирно будет, да ещё придётся прикручивать аутентификацию, чтобы всякие любопытные не шастали. А так можно просто повесить сервисы на внутренние адреса и дать доступ людям во внутреннюю сеть. Просто этим виртуалкам и их хостам ещё и между собой общаться надо (репликация баз, логи, мониторинг, кластерные ноды). Вот я и прикидывал, как бы это организовать не умножая сущности сверх необходимого.

Несколько вопросов:

1) Сколько у вас серверов (физических, между виртуалками туннели, скорее всего, не понадобятся)?

2) Есть ли система управления конфигурациями (Chef/Salt/что угодно способное сделать аналог Chef search)?

Если первых не очень много и они не раскиданы по большому количеству ДЦ, а также внедрено второе, то можно попробовать разворачивать tinc.

С ним есть несколько неприятных моментов:

1) Выбор маршрутов в случае потери связности между двумя узлами «странный» (если ДЦ1 перестал видеть ДЦ2, при этом они оба видят ДЦ3, то трафик по идее должен пойти через ДЦ3, но сходится tinc будет долго => даунтайм может быть неприемлимо долгим)

2) Каждая нода должна иметь публичные ключи всех машин, с которыми нужна связность по vpn (в одной из контор, где я работал, проблема решалась Chef'ом)

3) tinc однопоточный и работает в userland, отсюда производительность чуть ниже, чем у голого ipsec+gre (но не забывайте, что в этом случае вам еще придется поднимать OSPF/BGP, чтобы получить что-то аналогичное tinc)

P.S. Контора в итоге ушла на DMVPN на цисковских коробках + OSPF (из-за пункта 1)

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

Пока на тинке. Правда, это всё работает довольно хлипко и мне не нравится.

Понятно спасибо. А в чем именно хлипкость, хотелось бы знать?
У tinc мне понравилось то что он сам достраивает топологию до full-mesh, правда это не особо очевидно, в документации кажется это явно не указано. Хотя это одна из главных «фишек». А все примеры в сети с 2 - 3 хостами с явным указанием соединений.
Так же в tinc относительно простое управление ключами, проще чем генерить сертификаты для IPSec и даже проще чем easy-rsa для OpenVPN.
Ну и один из главных для меня плюсов в том, создается только 1 интерфейс куда с легкостью можно отправить multicast и он исправно работает.
Кроме того пинг через tinc vpn лучше чем через gre/gretap over ipsec, притом всю задержку вносит именно ipsec с любым методом шифрования даже с null. C tinc пинг ~0.68 msec с IPSec ~1.02 msec.
Главный минус tinc-а в пропускной способности: где IPSec (ipsec-tools | racoon) дают ~680 Мбит/сек tinc выдает ~355 Мбит/сек, метод шифрования в обоих случаях aes-128-cbc

Сделал тут велосипед из gretap тоннелей, бриджей и правил для ebtables, в принципе даже работает неплохо, но наверное еще более хлипко чем tinc. Никак в общем не могу на чем-то остановиться, чтоб потом не переделывать.

Хлипкость как раз в однопоточности. Когда годняешь между хостами многогигабайтные снэпшоты виртуалок, довольно критично оказывается. Ну и общая костыльность решения, идеологически правильно было бы арендовать влан у провайдера. Вот только недёшево. Собственно, в соседней моей теме эта костыльность и вылезла: «Плоская» сеть для контейнеров.

Арендовать влан для отдельного сервера не рационально на мой взгляд, да и возможность далеко не всегда есть. Хотя может у вас там и не по одному серверу на каждом конце.
Костыльности особой не вижу, если нарезать сети покрупней и главное так чтоб диапазоны были подсетями, то думаю вполне можно в том случае обойтись только правилами маршрутизации.

lizard, Hatifnatt, возможно вас заинтересует DMVPN (Full-Mesh IPsec) со strongSwan и quagga: http://git.alpinelinux.org/cgit/user/tteras/quagga/?h=nhrp + http://git.alpinelinux.org/cgit/user/tteras/strongswan/?h=tteras-release

Не знаю насчет tinc, но значительно ускорить OpenVPN можно, увеличив MTU на туннельном интерфейсе, таким образом будет меньше переключений контекста, и пакет будет собираться ядром на IP-уровне из фрагментированных частей. Попробуйте использовать MTU 9000 в tinc.

Спасибо за совет, поэкспериментирую.

DMVPN пытался настроить, используя https://sourceforge.net/projects/opennhrp/ но как-то не взлетело на Debian 7. Ну и главный для меня минус что все это достаточно сырое, и поддерживать не очень просто, собирать все самому, а потом обновлять и т.д. Возможность создавать full-mesh сети в StrongSwan появилась только в 5.3.3

Support for auto=route with right=%any for transport mode connections has been added

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

С фрагментацией пакетов растет и оверхед на заголовки для каждого пакета, будет ли выигрыш от меньшего количества переключений контекста больше чем потери на «лишних» заголовках пакетов?

Пока что реализовал VPN сеть используя gertap туннели и linux-bridge, конфигурировать все равно надо на обоих концах туннеля, но объем конфигурации достаточно небольшой.