У меня в качестве сервера Linux + strongswan, а mikrotik как клиент. Может кто еще поделится? Сервер на mikrotik пока еще не планировали, может в лаборатоном окружении сделаю.
Перехват трафика по середине вполне возможен, так что я бы не пренебригал этим.
Вторая описанная вами ситуация имела место при использовании ike1, сейчас там было много исправлений, и сработает ли он корректно — не знаю. Вот ike2 должен работать, однако тут сложности с настройками пира будут, тут уже политика для локального адреса задается, я такую конфигурацию еще не пробовал.
Я бы порекомендовал отказаться от mppe, в виду его низкой стойкости.
Не понятно, что значит к нескольким клиентам? Один клиент за NAT без проблем устанавливает несколько соединений с другими серверами.
Тут проблема немного иная.
Если несколько клиентов из-за одного и того-же NAT идут к одному и тому-же серверу (mikrotik), тогда и были проблемы. Были исправления к ike1, которые исправляли эту проблему, но не на всех ситуациях оно работало, была большая зависимость от клиента (при использовании xauth вообще не было проблемы).
На офф. форуме масса тредов с криками о помощи, ответа готового нет, есть намеки. Статейка в помощь страждущим, проблема + решение. Поэтому и флаг: tutorial.
Учел ваше замечание, и дал небольшое разьяснение про причину ошибки. Кто сталкивался с ней, перечитал десяток тредов на форуме разработчиков, где чистого решения нет, хотя идея была.
Я в массе использую Centos 7 (freenas пробовал, но не стал его использовать дальше, приходится держать несколько ролей на одной машине, что решаю с помощью LXC). Были некоторые напряги при обновление модулей ядра, поэтому затею пока забросил. Надо опробовать еще раз.
Что скажете о потребление ресурсов?
Тесты есть, но руки до обработки результатов еще не дошли (нужно сделать развернутый анализ).
Сообщения о окончание места сыпятся в dmesg или message, посчитал, что найти эти данные будет не сложно.
Выбор размера чанков: вообще холивар, единого мнения нет, кроме не знаешь, оставь по дефолту.
Остальные вопросы подробно расписанны в man, который я посчитал излишним переписывать сюда, статья имеет больше цель поделиться опытом реальной работы, нежели tutorial.
В вашей задаче DUNDi тоже может быть удобным. В простом случае строить звезду с одним центральным узлом. Два транка, один маршрут и практически неизменная конфа для каждого узла (примерно так-же как и обычный транк на двух концах настроить). Но, АТС при этом связываются на прямую (номер могут получить и рекурсивно).
А миграция у меня случилась… Но DUNDi помог мне без массовой остановки работы, в ленивом режиме, объединить (с пропорцией 2/7) планы нумирации двух АТС (офис частично съехал на другую площадку).
Работать оно работает. Пока серьезных проблем нет. Основная цель — это избавление от единого узла коммутации телефонии. Офисов стало относительно много, и сеть между ними нормально туннелями с OSPF работает (есть два филиала, которые обеспечивают общую связность сети). А вот телефония была заведена на одном из узловых филиалов, и настроена звездой (исторически так получилось). Когда узловой филиал остается без интернета, все филиалы, которые сохранили сетевую связность (спасибо OSPF) теряли связь по телефонии между собой. После перехода, на DUNDi связь сохраняется при сохранение сетевой связности.
Добавлять новые узлы не сложнее чем при классической схеме, а плюс в том, что нет нужды держать четкие диапазоны для каждого филиала, я могу с легкостью номер перенести на другую АТС, и он останется рабочим (разве что, надо изменить входящую маршрутизацию до него, если такая была).
Не отменяет генерацию сертификатов, но позволяет немного автоматизировать процесс.
Вторая описанная вами ситуация имела место при использовании ike1, сейчас там было много исправлений, и сработает ли он корректно — не знаю. Вот ike2 должен работать, однако тут сложности с настройками пира будут, тут уже политика для локального адреса задается, я такую конфигурацию еще не пробовал.
Не понятно, что значит к нескольким клиентам? Один клиент за NAT без проблем устанавливает несколько соединений с другими серверами.
Если несколько клиентов из-за одного и того-же NAT идут к одному и тому-же серверу (mikrotik), тогда и были проблемы. Были исправления к ike1, которые исправляли эту проблему, но не на всех ситуациях оно работало, была большая зависимость от клиента (при использовании xauth вообще не было проблемы).
- На офф. форуме масса тредов с криками о помощи, ответа готового нет, есть намеки. Статейка в помощь страждущим, проблема + решение. Поэтому и флаг: tutorial.
- По первым упоминаниям в changelog
.Что скажете о потребление ресурсов?
Сообщения о окончание места сыпятся в dmesg или message, посчитал, что найти эти данные будет не сложно.
Выбор размера чанков: вообще холивар, единого мнения нет, кроме не знаешь, оставь по дефолту.
Остальные вопросы подробно расписанны в man, который я посчитал излишним переписывать сюда, статья имеет больше цель поделиться опытом реальной работы, нежели tutorial.
LOCif обозначает интерфейс локальной сети. Вроде все ясно… Или я не понял вопроса.
А миграция у меня случилась… Но DUNDi помог мне без массовой остановки работы, в ленивом режиме, объединить (с пропорцией 2/7) планы нумирации двух АТС (офис частично съехал на другую площадку).
Добавлять новые узлы не сложнее чем при классической схеме, а плюс в том, что нет нужды держать четкие диапазоны для каждого филиала, я могу с легкостью номер перенести на другую АТС, и он останется рабочим (разве что, надо изменить входящую маршрутизацию до него, если такая была).