Dmitry: хороший кейс, сходу даже ответа нет, как бы не получилось что маршрут нужен, но не просто так, а в связке с route rules. Поищу инфу, может найду что. Но мои остальные рекомендации в силе.
Если эта сеть находится за каким либо устройством - то он должен быть шлюзом в этом правиле, если сеть находится в вашей же локальной сети - то микротик должен получить адрес из этой сети к себе на интерфейс.
Но и то и другое догадки, очень похоже что у вас всё сложнее, и телепатия мне не помогает.
1. Правило не такое же, а "очень похожее" - у того, что создаёт микротик, есть метка "C" = connected, это означает, что данная сеть напрямую подключена в устройство, и этот девайс её хозяин. В вашем же случае, всё получается наоборот, сеть есть - вот она, а "кто за неё отвечает?" - а вот сходи вот в этот интерфейс и там ищи. Т.е. с точки зрения микротика - ничего не изменится, а вот с точки зрения любого, кто захочет её при помощи вашего микротика достичь - будут проблемы (в лёгком сценарии правило будет неактивно, и активируется только если у вас изчезнет адрес из сети на устройстве, а в плохом - добро пожаловать в мир постоянного широковещательного трафика).
2. Не очень понял на какой раздел вы кинули ссылку, потому напишу просто:
В таблице маршрутизации, в поле указания шлюза, благодаря технологии ECMP мы можем указывать несколько шлюзов. Понимаете, ключевое слово последнее - шлюзы.
В среде множественного доступа (это такая физическая среда, в которой одновременно в пределах l2 домена может быть множество участников, более двух) - в ethernet'е шлюз это всегда конкретный адрес. Адрес какого-то хоста или виртуальный адрес, но никак не интерфейс.
В среде единственного доступа (а это все виды PPP туннелей, и некоторые виды физических сред - serial port например) - шлюзом может быть конкретный интерфейс, так как в нём - в этом интерфейсе, всё равно кроме нас и соседа никого нет.
Резюмируя. Такой маршрут не верный, в лучшем (самом лёгком способе) - он просто неактивен, создавать его следует только в сценариях нескольких таблиц маршрутизации чётко осознавая что и зачем мы делаем, и не забывая указывать pref-sorce.
Шлюзом может быть интерфейс, но если это интерфейс является туннелем (т.е. в нём всегда не более двух участников), оставляя за скобками все "странные" варианты, администраторы которых прекрасно (или не очень) понимают что они делают и зачем
Шлюзом в сети ethernet (равно как и во многих других) должен быть конкретный адрес (или несколько адресов - несколько шлюзов).
В вашем случае такой маршрут является лишним и паразитным. Отключите его и ищите причину неправильно работы в других местах.
Dmitry: Вы можете повторять ещё и ещё, но маршруты в текущем их виде - это ошибка. Шлюзом для маршрута не может быть адрес интерфейса с множественным доступом (в данном случа это бридж, с ethernet в портах).
То что эта конкретная ошибка не влияла на изначальную проблему, не значит что так настраивать правильно. =)
вроде бы это применимо только для MX записей, по крайней мере RFC только об этом написано. https://tools.ietf.org/html/rfc1034
Поправьте меня, если я не прав
Сергей Золотарёв: ну вы эт самое с TP-Link в сети предприятия по-осторожнее. Лучше брать что-то более надёжное, если сеть строите не для галочки.
Если хотите простое в настройке - берите юнифай, если хотите всё богатство и разнообразие фич MESH\HWFW\Vlan\BGNAC - то берите микротик. Если "денег куры не клюют" можно циску посмотреть.
Александр Романов: ох тыж точно! Спасибо за уточнение! Сергей Золотарёв: обратите на это внимание. В Lite лицензия позволяет только один коннект пользователя на точку.
Годный материал (только клиентская настройка отличается, но думаю вы справитесь: нужно просто с клиентской стороны создать l2tp-client и указать адрес севера и креденшалы) howitmake.ru/blog/waildhand/177.html
localsnet: такс, для начала, с серым адресом работать будет (с адресом за НАТ), и даже с серым динамическим будет (с динамическим адресом за НАТ), но во втором случае нужно скриптом вычислять какой текущий адрес у роутера является публичным и прописывать его в политиках IPSec (и в случае ошибок в генерации политик на стороне сервера и там тоже их менять). Это довольно геморно, но возможно.
Оверхед или увеличение нагрузки при использовании l2tp минимально, при чём его можно использовать и без IPSec, там штатное шифрование очень на уровне. Так же в крайних версиях прошивки (и давольно давно) появился сервер SSTP (он более пробивной для NAT, т.к. использует HTTPS ) и клиент.
Но можно использовать и OpenVPN - по накладным расходам очень близко к IPSec, и, в отличии от второго, так же как другие протоколы сервер\клиент хорошо пробивает НАТ.
Проблема у IPSEC в том, что он изначально заточен не как протокол Сервер-Клиент. Он заточен на то, что обе стороны равноправны, это несколько затрудняет конфигурирование сторон в не симметричном сценарии (как ваш). Когда как тот же L2TP изначально спроектирован как несимметричный, и клиентская сторона хорошо понимает те настройки, что сообщает её сервер.
localsnet: нет, так не выйдет, провайдер вам выдал не публичный адрес. Вам нужно знать реальный ваш адрес, и знать его постоянно, т.е. менять на стороне клиента политики шифрования указывая в Src SA этот самый адрес.
Но очень похоже что дело сложное. Почему отказываетесь от l2tp?
RazorBlade: это всё что нужно прописать в конфиге и положить ключи. Бакенд меняете на что-то своё. Тестируете, выставляете nginx наружу, меняете DNS, добавляете новый сервер в конфиг, новые ключ, и так по кругу.
