@TRIMER ах, ну если используете IPSec+l2tp то да. В смысле это разные реализации VPN. (зачем нужен порт 4500 - не знаю, это явно что-то ваше кастомное)
@SmileyK ну да, он лучше нежели тупой rip (хотя последний понимают клиентские машины и его можно использовать вместе с pptp, например). Но имхо, настройка динамики ради трёх пиров и трёх же подсетей - это избыточно.
@alz5 в нат и в фильтрах два правила с действием accept между двумя сетями (в начале в одном направлении, потом в другом). Правила расположите выше остальных.
@Voiddancer ну полюбому тогда у провайдера нужно копать. Можно например поднять туннель и проверив его стабильность, пустить трафик через него - это снизит возможности провайдера по приоритезации и срезу трафика.
На микротик в итоге приземляется Белый адрес? Киньте правила прорброса сюда (в них всё же может быть ошибка вызывающая такое поведение).
Микротик DHCP и основной шлюз для всего, верно?
Есть возможность вотнутся в микротик ноутбуком в другой порт, где будет поднята отдельная сеть? (это позволит исключить проблемы в файрволах и прочем на локальных клиентах внутри сети и можно будет проверить проброс портов локально)
Но к делу это отношение имеет опосредованное. У вас всё будет так:
1. Между двумя адресами подняли IPSec шифрование в транспортном режиме - в этом режиме будет зашифрован трафик идущий именно между этими двумя адресами
2. Установили EoIP как в доке по ссылке
3. Проверили пинги - должны ходить \ проверили IPSec счётчики - должны расти
4. Соединили полученные EoIP туннели с локальной сетью в бридж на обоих концах - получили плоскую сеть.
IPSec это отдельный от VPN механизм, работающий немного по иным законам нежели VPN. Ну то есть в случае с VPN (равно как и EoIP) вы просто говорите "вот между этими двумя айпишниками у меня туннель" и дальше маршрутизируете туда трафик, то для IPSec вам не просто нужно указать "концы" но и в самих же настройках IPSec сказать для какого трафика служба должна сама поднимать туннель (то есть порядок построения туннеля обратный - вначале трафик потом сеть).
Хорошая демонстрация как это работает в ядре есть в документации к микротику (она применима и для большинства линуксов) wiki.mikrotik.com/wiki/Manual:Packet_Flow последние две диаграммы.
@386DX из вопроса не совсем понятно как планируется работа с системой дедупликации. Темболее есть фраза "прозрачный для операционной системы (windows)". Я предположил, что ms инфрастуктура уже есть.
К сачатью в этом мерзком (и если бы не проблемы с совместимостью его бы использовать не пришлось бы, но) гипервизаре есть миграция без обьединения в кластер.
А вот сам кластер без внешнего хранилища не собрать.
Сейчас я построил плоскую сеть и все виртуалки внутри неё имеют одну адресацию, так же есть три шлюза, способных пускать наружу или натить трафик внутрь - в этом варианте нет проблем с натом и выставлением наружу, нет проблем с миграцией по хостам, но есть проблемы с тем что шлюз по умолчанию - это всегда одна виртуалка, на конкретном хосте и если она "ляжет" нужно перевыдать адреса или переназначить шлюз по-умолчанию, чтобы трафик продолжал ходить.
@aigars535 это и имел ввиду. В смысле нужен хороший ориентир и понимание как "ловить" гребень волны у антенны, он (пик сигнала) часто расположен не там куда смотрит конвертор (а например выше на 30 гр.)
@aigars535 дак а что вы теряетесь, берите тик и последнюю антенну =) Если есть возможность - то само собой на тест для начала. Ну и "лазерный прицел" нужен, чтобы лучами попасть на такой дистанции.
