ну "суммирование" - это миф)

Кто-нибуль, можете подсказать как в Mikrotik при подключении L2TP выставить использование IKEv2 ?

Смотря между чем и чем, если между двумя Mikrotik, то, как и без L2TP, создаёте записи в Policy, Peer, Identity и Profile/Proposal по желанию. Если между Mikrotik и клиентской ОС, то никак, если конечно опять же не воспользуетесь каким-то не стандартным клиентом для этого.

Не понимаю, зачем l2tp, если между микротиками. Какие плюшки?

Спасибо, терпит конечно. Напомнить завтра?

0 ;;; DST-NAT for Local DNS-queries chain=dstnat action=dst-nat to-addresses=192.168.4.12 connection-mark=dns-forward nth=2,1 1 chain=dstnat action=dst-nat to-addresses=192.168.6.154 connection-mark=dns-forward

Добрый день! Кто подскажет, почему dhcp сервер выдаёт ип отличный от того, что закреплён в dhcp-leases ? Сменили ОС на сервере, мак остался прежний, имя хоста прежнее, а ип новый выдаётся. clientid отличаться стал

Уберите clientid из лизы. Или поменяйте на новый

а возможно ли вообще отключить этот clientid? Что бы сотрудники без доступа на микротик могли получать старые ипы при смене ОС

Конечно

как?

Удалите значение поля clientid

новые устройства появляются автоматически с clientid ведь! Как сделать, что бы он не появлялся?

новые устройства появляются автоматически с clientid ведь! Как сделать, что бы он не появлялся?

Я вчера "упоролся" в проблему.... л2тп от билайна + резерв)))) ибо когда падает линк билайна - л2тп билайна пытается установиться через резервный канал %) замучался скриптовать чтоб такого небыло.... отфаерволить так и не получилось.

а где брать этот дст лист, если tp.internet.beeline.ru резолвится каждый раз под разными адресами((((((( и шлюз блин каждый раз разный, который тик получает по дхцп..... в том то и беда какрас. Поэтому и скриптовать пришлось.... Т.е. нужна некая жёсткая привизка, что ВОТ ДАННЫЙ КОНКРЕТНЫЙ л2тп поднимать исключительно через этот интерфейс (не шлюз)

а тут вторая проблема...))))) если линк билайна в это время не активен - tp.internet.beeline.ru резолвится как "unknown"..... даже флушДнс не помогает. И даже после поднятия линка билайна - он всё равно unknown... флушДнс тоже не помогает)))))))))))))))))))))))

Ну я плюс\минус так же и сделал))))))))))) Но это опять таки скрипты))) Поэтому и спросил - можно ли как-то подругому обойти эту проблему, а не через скрипты. СаняСан говорил когда-то - Скрипт - это всегда костыль. И в 99% случаев можно обойтись без него. Просто вы ещё не знаете как

Тогда следующий вопрос))))) Если будет дст лист, в котором tp.internet.beeline.ru резолвится как 5 адресов..... Будет ли тик пытаться достучаться на каждый из них, если первый адрес будет недоступен?

пока не найдёт нужный?

возможно там проксиАрп поднят у провайдера и в качестве шлюза вообще интерфейс можно указать.....

а тут вторая проблема...))))) если линк билайна в это время не активен - tp.internet.beeline.ru резолвится как "unknown"..... даже флушДнс не помогает. И даже после поднятия линка билайна - он всё равно unknown... флушДнс тоже не помогает)))))))))))))))))))))))

в статик днс запихать билайновский FWD на их сервера?

поэтому у меня в итоге получился жутковатый скрипт, который отключает линк резервного провайдера на 30 сек.... затем делает флушДнс... затем убивает коннекшены.... затем опять флушДнс...... передёргивает линк билайна.... и только после этого устанавливается л2тп билайна... а когда линк билайна упал - он гасит л2тп)))))))))))))))))) затем в зависимости от условий поднимает линк резерва))))))))))) а резерв это дешманский тпЛинк с возмоностью впихнуть 3джиМодем

Вместо 10 строчек 🤦🏼

Добрый день! Коллеги, подскажите пожалуйста как решить Ситуация следующая: есть 2 микрота, 1 - белый ip и сервер l2tp, 2 серый ip, за ним серая сеть, между микротами поднят тунель. С микрота 1 сделан проброс портов в серую сеть за микротом 2, со стороны WAN запросы на IP в серой сети приходят, но отвечает он не в тунель, а в шлюз провайдера полученный по DHCP Нужно либо пустить весь исходящий трафик через тунель, либо только маршрутизацию с этого серого IP

На стороне сервера в секрете для клиента укажите в поле route адрес сети за клиентом. На стороне клиента пропишите статический маршрут до сети за сервером через l2tp интерфейс.

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

@Roman_Kazitskiy добавлю к рекомендации от Cumberbatch : можно masquerade сделать для пакетов, отправляемых в эту самую серую сеть. Тогда для машин в серой сети за микротиком 2 все пакеты будут видны как от микротика 1 и ответ пойдет именно по туннелю.

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

Тогда маркируйте соединения с каждой из сторон туннеля и раскидывайте по каналам.

Ну это так себе рекомендация. Если можно обойтись без изменения пакета то нужно это делать

Если не принципиально знать адрес источника - можно и так.

Зачем?

У него клиент в интернете. И сервер из серой сети в этот интернет и отвечает. Пакеты мы не исправляем. Расскажите, пожалуйста, как маршруты в соседнюю сеть помогут отправить пакет через туннель?

Можно и микроскопом гвозди забивать и на потолке спать. Но зачем?

У него, по сути - два канала в интернет. И надо сделать так, чтобы пакеты уходили туда, откуда пришли.

Для этого мы маршрут прописываем

Маршрут куда?

Туда откуда пришёл пакет

Правильно. Но пакет пришёл из интернета. И уйдет через шлюз по-умолчанию.

Правильно. Но пакет пришёл из интернета. И уйдет через шлюз по-умолчанию.

Пакет уйдёт туда, куда правила его погонят согласно маршрутизации. Маркировать надо соединение, а затем пакеты в нём.

Пакеты-то зачем? )

Их можно в маршрутизации порулить.

Пакеты-то зачем? )

Чтобы нагрузку на роутер побольше сделать :)

Можно, но не нужно. )

Догнал. Почитал тред сначала. Всегда маскарад на впн в сторону клиента делаю, когда надо доступ в сеть клиента, но не нужно, чтобы клиент мог залезть обратно. Требует минимальных действий клиента.

Маркировка много жрёт )

Маркировка много жрёт )

Маркировка много жрёт )

А натом вы ограничиваете клиента от выбора кому можно кому нельзя

Клиент-то как что-то ограничить сможет? Ведь это он на сервер через туннель идёт.