Одновременная маршрутизация через разные каналы

@GTAlex · Регистрация: 19.02.2013

Author24 — интернет-сервис помощи студентам

микротик 1 - офис 192.168.11.0/24 один WAN (белый IP статика) - я сижу в офисе
микротик 2 - склад 192.168.12.0/24 два WAN - основной (белый IP статика) + резервный YOTA (динамический IP)

подняты два шлюза - gre дефолтный по основным каналам с белыми IP + резервный l2tp через yota

на первом роут 192.168.12.0/24 на gre
на втором обратный роут 192.168.11.0/24 на gre

как мне находясь в локалке зайти на микротик 2 по резервному каналу?

Добавлено через 1 час 5 минут
хм ... если l2tp через резервный - то всё должно работать само-собой при обращении с локального компа на "remote addr" в l2tp
оно и работает пока основной канал пашет - получается, что l2tp не через резервный идёт ...

Добавлено через 14 минут
в соседней ветке недоработал

@.None · 14.11.2019, 06:40

это маршрутизация

вы с адреса 192.168.11.100 шлете пакет на "remote addr", пакет идет на МТ1, смотрит там таблицу маршрутизации и дальше уходит через l2tp, доходит до МТ2 и он шлет обратный пакет, смотрит таблицу маршрутизации, а там маршрут до 192.168.11.0/24 через gre, -> шлет пакет через gre

в случае обрыва основного канала, назад пакет пойдет через l2tp, т.к. маршрут через gre будет отключен.

если все же необходимо чтобы пакет назад шел через l2tp, то необходимо промаркировать входящие соединение из l2tp в mangle, и потом там же сделать mark routing, на предварительно созданный маршрут через l2tp c routing mark

Добавлено через 2 минуты

Сообщение от GTAlex

на втором обратный роут 192.168.11.0/24 на gre

а где же маршрут до 192.168.11.0/24 через l2tp?

@insect_87 · 14.11.2019, 10:54

GTAlex, в соседней теме я показал как сделать первые две части.
По 3 части - маршрутизация между локальной и удаленной сетью рекомендую поднять ospf с обеих сторон и рулить через cost.
Интерфейсы:
Для gre cost=5 тип p2p
Для l2tp cost=10 тип p2p
Для интерфейса локалки cost=10 тип broadcast passive=yes
Добавление сетей:
подсеть для gre (скорее по маске /30)
подсеть для локалки по маске/24
адрес l2tp клиента по маске 32 (на стороне сервера) / адрес l2tp сервера по маске 32 (на стороне клиента).
Area с обеих сторон одинаковая, можно оставить дефолтный backbone

GTAlex, давайте сначала с active/backup и дефолтными маршрутами по multiwan разберемся, в соседне теме варианты предложил
И. Для внутренних сетей не забудьте про nat. По src-nat для внутренней сети склада должно все маскарадиться и с выходом через основного провайдера, и с выходом через резервного

Добавлено через 5 минут
И последнее, когда вы оставляли только l2tp (без GRE), Вы статические маршруты меняли?
Вот эти:

на первом роут 192.168.12.0/24 на gre
на втором обратный роут 192.168.11.0/24 на gre

@GTAlex · 14.11.2019, 11:26 **[ТС]**

я пока просто хочу l2tp через резервный с адресом 192.168.13.245 чтоб заработал, не говоря уже о маршрутизации между локальными сетями.
т.е. первая задача - иметь доступ к микротику на складе когда основной канал с белым IP лежит
т.к. внешнего айпишника не имеем - хочу это реализовать через l2tp и внутренний айпишник, но настраивать всё это нужно когда основной канал работает

Добавлено через 6 минут
то есть двигаться от простого к сложному

@insect_87 · 14.11.2019, 12:01

т.е. первая задача - иметь доступ к микротику на складе когда основной канал с белым IP лежит

Ваши 4 правила в мангл, которые метят коннекшн на инпуте, а затем по метке коннекшна навешивают метку маршрута и в итоге разруливают дефолтные маршруты согласно этим меткам маршрута, будут работать только тогда, когда соединение инициируется с удаленных внешних адресов.
У вас же ин-интерфейсы - авантел и йота, а не gre и l2tp.

Для gre и l2tp надо по аналогии создавать, в мангле меняются ин-интерфейсы.
А в маршрутах, если вы хотите через статику, указывается конкретная сеть назначения, в данном случае 11я, ну и соответствующие routing-mark

Ну и да, зачем правило для in-interface yota, у него ж серый адрес

@GTAlex · 14.11.2019, 12:45 **[ТС]**

да, полностью согласен с Вами - спасибо за расшифровку на русский язык

для проброса l2tp по йоте пробовал метить исходящий трафик по интерфейсу - не получилось
потом Вы подсказали - по UDP порту 1701 метить - тоже не пашет почему то

@insect_87 · 14.11.2019, 13:07

По l2tp в другой теме отпишу. Там же конфиги выкладывали.

@GTAlex · 15.11.2019, 07:33 **[ТС]**

Сообщение от .None

это маршрутизация
вы с адреса 192.168.11.100 шлете пакет на "remote addr", пакет идет на МТ1, смотрит там таблицу маршрутизации и дальше уходит через l2tp, доходит до МТ2 и он шлет обратный пакет, смотрит таблицу маршрутизации, а там маршрут до 192.168.11.0/24 через gre, -> шлет пакет через gre

чтобы не было путаницы l2tp поднимаю с адресами 192.168.13.1 (офис) - 192.168.13.2 (склад)
я так понимаю - чтобы с адреса 192.168.11.100 (мой комп) я мог по айпишнику 192.168.13.2 работать с МТ2 через l2tp (сам интерфейс уже сделали чтоб через резервный канал yota поднимался)
либо маркировать входящее соединение (input destination IP 192.168.13.2) и обратный маршрут по таблице маршрутизации через l2pt (я так понял Вы как раз этот вариант предлагаете)

либо может по l2tp маскарадинг включить? тогда по идее должно получится что пна MT2 пришли с 13й подсети - соответственно и ответ будет на MT1 192.168.13.1 (l2tp) и он уже обратно на 192.168.11.100? так может работать или бред?

доеду до работы - оба варианта попробую

@insect_87 · 15.11.2019, 09:03

1.Никакой маскарадинг не нужен, а то еще и сети друг от друга закроете, ТОЛЬКО маркировка и отдельная таблица роутинга.

В input mangle удаленного микротика помечаем коннекшн с src-address 192.168.11.0/24 на in-interface l2tp-out, затем второе правило тут же, но в output, по метке конекшна назначить метку маршрута через yota, ну и собственно сам маршрут до 192.168.11.0/24 через 192.168.13.1 (или с интерфейса yota) с метрикой 1 и routing-mark

ВСЕ

2. OSPF будете настраивать?
Выше в посте 3 я написал как его надо настроить (минут 10), если не будет что-то получаться, выкладывайте настройки ospf, посмотрим
Если ospf настроен правильнно, то статические маршруты до локальных сетей через gre нужно выключить

@GTAlex · 15.11.2019, 10:36 **[ТС]**

Сообщение от insect_87

затем второе правило тут же, но в output, по метке конекшна назначить метку маршрута через yota,

имеется ввиду через l2tp ?

Код

add action=mark-connection chain=input in-interface=l2tp-office new-connection-mark=conn-l2tp passthrough=no src-address=192.168.11.0/24
add action=mark-routing chain=output connection-mark=conn-l2tp new-routing-mark=rm-l2tp passthrough=no

Код

add comment="Office via l2tp" distance=1 dst-address=192.168.11.0/24 gateway=192.168.13.1 routing-mark=rm-l2tp

не пашет как задумано

цепляюсь с компа на 192.168.13.2 вырубаю в сейв моде основной интерфейс - и ... отваливаюсь сам

хотя вроде всё на резервном канале по l2tp

после отката почему-то падает маршрутизация по gre

ребут маршрутизатора - маршрут по gre восстанавливается

в рабочее время уже не буду эксперементировать

народ нервничает

@insect_87 · 15.11.2019, 10:46

В первом правиле passthrough=yes
В правиле маршрута вместо шлюза укажите интерфейс l2tp-office

При проверке вырубать основной канал не обязательно
До проверки ребутните роутер на всякий

@GTAlex · 15.11.2019, 11:09 **[ТС]**

Сообщение от insect_87

В первом правиле passthrough=yes

Passthrough
Ничего не делать. Передать пакет на следующее правило. Однако при этом счетчики работают, показывая сколько пакетов соответствовало этому правилу. Обычно используется для статистики.

если ничего не делать - получается что он и коннекшен метить не будет?
чего то недопонимаю я с этим "passthrough=yes"

Сообщение от insect_87

В правиле маршрута вместо шлюза укажите интерфейс l2tp-office

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

Сообщение от insect_87

При проверке вырубать основной канал не обязательно

как тогда проверить работоспособность данного решения предусмотренного в случае падения основного канала?

Сообщение от insect_87

До проверки ребутните роутер на всякий

Ок

Добавлено через 12 минут

Код

add action=mark-routing chain=output dst-address=93.91.162.154 dst-port=1701 new-routing-mark=rm-Yota passthrough=no protocol=udp
add action=mark-connection chain=input in-interface=l2tp-office new-connection-mark=conn-l2tp passthrough=yes src-address=192.168.11.0/24
add action=mark-routing chain=output connection-mark=conn-l2tp new-routing-mark=rm-l2tp passthrough=no

Код

add comment="Office via l2tp" distance=1 dst-address=192.168.11.0/24 gateway=l2tp-office routing-mark=rm-l2tp

ребутнул МТ2

проверял "по старинке" - зацепился на 192.168.13.2 и вырубил в сейв моде основной маршрут ... меня выкинуло

@.None · 15.11.2019, 11:19

Сообщение от GTAlex

зацепился на 192.168.13.2

с какого ip подключались?

давайте еще раз посмотрим правила маршрутизации на обеих концах, ip route print

я бы привел правила к виду

Код

add action=mark-connection chain=input in-interface=l2tp-office new-connection-mark=conn-l2tp passthrough=yes
add action=mark-routing chain=output connection-mark=conn-l2tp new-routing-mark=rm-l2tp passthrough=no

add comment="Office via l2tp" distance=1 dst-address=0.0.0.0/0 gateway=192.168.13.1 routing-mark=rm-l2tp

т.е. убрал критерий src-address=192.168.11.0/24 из соображений что любой трафик пришедший через VPN должен туда же и уходить
и в маршруте все же указал бы ip адрес шлюза

вопрос остается в фаерволом ip furewall filter rules, там ничего не запрещается (forward input output) что касается туннеля?

@GTAlex · 15.11.2019, 11:27 **[ТС]**

Сообщение от .None

с какого ip подключались?

192.168.11.100 - мой комп в локалке офиса

сейчас поправлю правило, отрублю всё в фаерволе и проверю ещё раз

@.None · 15.11.2019, 11:28

+ ко всему, эти правила маркируют соединения пришедшие через туннель и предназначенные самому микротику (цепочка input output) и отправляют обратно в туннель, для транзитного трафика (из сети в сеть) необходимо делать отдельную маркировку и mark-routing в цепочках forward и prerouting соответственно

@GTAlex · 15.11.2019, 11:41 **[ТС]**

Сообщение от .None

+ ко всему, эти правила маркируют соединения пришедшие через туннель и предназначенные самому микротику (цепочка input output) и отправляют обратно в туннель, для транзитного трафика (из сети в сеть) необходимо делать отдельную маркировку и mark-routing в цепочках forward и prerouting соответственно

вот тут не понял

мне нужно из локалки с МТ1 зацепиться к МТ2 по резервному интерфейсу при работающем основном
все настройки делаются на МТ2 - в нём по идее никакого транзитного трафика нет

Добавлено через 5 минут

Сообщение от .None

вопрос остается в фаерволом ip furewall filter rules, там ничего не запрещается (forward input output) что касается туннеля?

при работающем основном канале я без проблем цепляюсь на 192.168.13.2 и работаю
значит в фаерволе ничего не запрещается

вот почему при отключении основного я отваливаюсь - вопрос

а как ещё тестировать - не пойму

@.None · 15.11.2019, 11:50

тут нужно смотреть в комплексе, работает ли туннель при отключении основного канала, может при обрыве основного перестает работать и туннель?

после восстановления связи смотрите логи на удаленной стороне может там есть какая информация, поставьте постоянный пинг с микротика сервера на клиент по адресу 192.168.13.2, и разорвите основной канал, пинги продолжают идти?

не работать может из-за маршрутизации, точно ли VPN идет через ОПСОСа?

еще варианты диагностики это log правила, на микротике сервере в фильтре добавьте 2 log правила forward с src-addr 192.168.13.2 и второе с dst-addr 192.168.13.2, с ПК 192.168.11.100 запустите постоянный пинг на 192.168.13.2 и отключите основной канал, в логе будет информация, откуда, куда и через какой интерфейс пришел/ушел пакет, будет видно к примеру что пакет ушел, но назад не вернулся, log правила поднимите в самый вверх списка.

@insect_87 · 15.11.2019, 12:01

.None, транзитный трафик потом через ospf разрулим как active/backup, а если TC захочет, то можно и балансировку сделать

@GTAlex · 15.11.2019, 12:01 **[ТС]**

Сообщение от .None

тут нужно смотреть в комплексе, работает ли туннель при отключении основного канала, может при обрыве основного перестает работать и туннель?

похоже так и есть

Сообщение от .None

поставьте постоянный пинг с микротика сервера на клиент по адресу 192.168.13.2, и разорвите основной канал, пинги продолжают идти?

пинг рвётся и меня тоже выкидывает

Сообщение от .None

не работать может из-за маршрутизации, точно ли VPN идет через ОПСОСа?

что за ОПСОС?

Сообщение от .None

еще варианты диагностики это log правила, на микротике сервере в фильтре добавьте 2 log правила forward с src-addr 192.168.13.2 и второе с dst-addr 192.168.13.2, с ПК 192.168.11.100 запустите постоянный пинг на 192.168.13.2 и отключите основной канал, в логе будет информация, откуда, куда и через какой интерфейс пришел/ушел пакет, будет видно к примеру что пакет ушел, но назад не вернулся, log правила поднимите в самый вверх списка.

Спасибо, буду пробовать!

@insect_87 · 15.11.2019, 12:10

ОПСОС

?
Оператор сотовой связи, йота
GTAlex, у вас туннель l2tp точно через йоту стартанул?

@insect_87 Модератор 11427 / 6996 / 1903 Регистрация: 25.12.2012 Сообщений: 29,398
	15.11.2019, 12:01	18
	.None, транзитный трафик потом через ospf разрулим как active/backup, а если TC захочет, то можно и балансировку сделать 1

@GTAlex 45 / 6 / 1 Регистрация: 19.02.2013 Сообщений: 172
		1
	Одновременная маршрутизация через разные каналы 14.11.2019, 06:20. Показов 4537. Ответов 38 Метки нет (Все метки) микротик 1 - офис 192.168.11.0/24 один WAN (белый IP статика) - я сижу в офисе микротик 2 - склад 192.168.12.0/24 два WAN - основной (белый IP статика) + резервный YOTA (динамический IP) подняты два шлюза - gre дефолтный по основным каналам с белыми IP + резервный l2tp через yota на первом роут 192.168.12.0/24 на gre на втором обратный роут 192.168.11.0/24 на gre как мне находясь в локалке зайти на микротик 2 по резервному каналу? Добавлено через 1 час 5 минут хм ... если l2tp через резервный - то всё должно работать само-собой при обращении с локального компа на "remote addr" в l2tp оно и работает пока основной канал пашет - получается, что l2tp не через резервный идёт ... Добавлено через 14 минут в соседней ветке недоработал 0

@.None 4284 / 1621 / 325 Регистрация: 23.06.2009 Сообщений: 5,788
	14.11.2019, 06:40	2
	это маршрутизация вы с адреса 192.168.11.100 шлете пакет на "remote addr", пакет идет на МТ1, смотрит там таблицу маршрутизации и дальше уходит через l2tp, доходит до МТ2 и он шлет обратный пакет, смотрит таблицу маршрутизации, а там маршрут до 192.168.11.0/24 через gre, -> шлет пакет через gre в случае обрыва основного канала, назад пакет пойдет через l2tp, т.к. маршрут через gre будет отключен. если все же необходимо чтобы пакет назад шел через l2tp, то необходимо промаркировать входящие соединение из l2tp в mangle, и потом там же сделать mark routing, на предварительно созданный маршрут через l2tp c routing mark Добавлено через 2 минуты Сообщение от GTAlex на втором обратный роут 192.168.11.0/24 на gre а где же маршрут до 192.168.11.0/24 через l2tp? 1

@insect_87 Модератор 11427 / 6996 / 1903 Регистрация: 25.12.2012 Сообщений: 29,398
	14.11.2019, 10:54	3
	GTAlex, в соседней теме я показал как сделать первые две части. По 3 части - маршрутизация между локальной и удаленной сетью рекомендую поднять ospf с обеих сторон и рулить через cost. Интерфейсы: Для gre cost=5 тип p2p Для l2tp cost=10 тип p2p Для интерфейса локалки cost=10 тип broadcast passive=yes Добавление сетей: подсеть для gre (скорее по маске /30) подсеть для локалки по маске/24 адрес l2tp клиента по маске 32 (на стороне сервера) / адрес l2tp сервера по маске 32 (на стороне клиента). Area с обеих сторон одинаковая, можно оставить дефолтный backbone GTAlex, давайте сначала с active/backup и дефолтными маршрутами по multiwan разберемся, в соседне теме варианты предложил И. Для внутренних сетей не забудьте про nat. По src-nat для внутренней сети склада должно все маскарадиться и с выходом через основного провайдера, и с выходом через резервного Добавлено через 5 минут И последнее, когда вы оставляли только l2tp (без GRE), Вы статические маршруты меняли? Вот эти: на первом роут 192.168.12.0/24 на gre на втором обратный роут 192.168.11.0/24 на gre 2

@GTAlex 45 / 6 / 1 Регистрация: 19.02.2013 Сообщений: 172
	14.11.2019, 11:26 [ТС]	4
	я пока просто хочу l2tp через резервный с адресом 192.168.13.245 чтоб заработал, не говоря уже о маршрутизации между локальными сетями. т.е. первая задача - иметь доступ к микротику на складе когда основной канал с белым IP лежит т.к. внешнего айпишника не имеем - хочу это реализовать через l2tp и внутренний айпишник, но настраивать всё это нужно когда основной канал работает Добавлено через 6 минут то есть двигаться от простого к сложному 0

@insect_87 Модератор 11427 / 6996 / 1903 Регистрация: 25.12.2012 Сообщений: 29,398
	14.11.2019, 12:01	5
	т.е. первая задача - иметь доступ к микротику на складе когда основной канал с белым IP лежит Ваши 4 правила в мангл, которые метят коннекшн на инпуте, а затем по метке коннекшна навешивают метку маршрута и в итоге разруливают дефолтные маршруты согласно этим меткам маршрута, будут работать только тогда, когда соединение инициируется с удаленных внешних адресов. У вас же ин-интерфейсы - авантел и йота, а не gre и l2tp. Для gre и l2tp надо по аналогии создавать, в мангле меняются ин-интерфейсы. А в маршрутах, если вы хотите через статику, указывается конкретная сеть назначения, в данном случае 11я, ну и соответствующие routing-mark Ну и да, зачем правило для in-interface yota, у него ж серый адрес 1

@GTAlex 45 / 6 / 1 Регистрация: 19.02.2013 Сообщений: 172
	14.11.2019, 12:45 [ТС]	6
	да, полностью согласен с Вами - спасибо за расшифровку на русский язык для проброса l2tp по йоте пробовал метить исходящий трафик по интерфейсу - не получилось потом Вы подсказали - по UDP порту 1701 метить - тоже не пашет почему то 0

@insect_87 Модератор 11427 / 6996 / 1903 Регистрация: 25.12.2012 Сообщений: 29,398
	14.11.2019, 13:07	7
	По l2tp в другой теме отпишу. Там же конфиги выкладывали. 1

@GTAlex 45 / 6 / 1 Регистрация: 19.02.2013 Сообщений: 172
	15.11.2019, 07:33 [ТС]	8
	Сообщение от .None это маршрутизация вы с адреса 192.168.11.100 шлете пакет на "remote addr", пакет идет на МТ1, смотрит там таблицу маршрутизации и дальше уходит через l2tp, доходит до МТ2 и он шлет обратный пакет, смотрит таблицу маршрутизации, а там маршрут до 192.168.11.0/24 через gre, -> шлет пакет через gre чтобы не было путаницы l2tp поднимаю с адресами 192.168.13.1 (офис) - 192.168.13.2 (склад) я так понимаю - чтобы с адреса 192.168.11.100 (мой комп) я мог по айпишнику 192.168.13.2 работать с МТ2 через l2tp (сам интерфейс уже сделали чтоб через резервный канал yota поднимался) либо маркировать входящее соединение (input destination IP 192.168.13.2) и обратный маршрут по таблице маршрутизации через l2pt (я так понял Вы как раз этот вариант предлагаете) либо может по l2tp маскарадинг включить? тогда по идее должно получится что пна MT2 пришли с 13й подсети - соответственно и ответ будет на MT1 192.168.13.1 (l2tp) и он уже обратно на 192.168.11.100? так может работать или бред? доеду до работы - оба варианта попробую 0

@insect_87 Модератор 11427 / 6996 / 1903 Регистрация: 25.12.2012 Сообщений: 29,398
	15.11.2019, 09:03	9
	1.Никакой маскарадинг не нужен, а то еще и сети друг от друга закроете, ТОЛЬКО маркировка и отдельная таблица роутинга. В input mangle удаленного микротика помечаем коннекшн с src-address 192.168.11.0/24 на in-interface l2tp-out, затем второе правило тут же, но в output, по метке конекшна назначить метку маршрута через yota, ну и собственно сам маршрут до 192.168.11.0/24 через 192.168.13.1 (или с интерфейса yota) с метрикой 1 и routing-mark ВСЕ 2. OSPF будете настраивать? Выше в посте 3 я написал как его надо настроить (минут 10), если не будет что-то получаться, выкладывайте настройки ospf, посмотрим Если ospf настроен правильнно, то статические маршруты до локальных сетей через gre нужно выключить 1

@GTAlex 45 / 6 / 1 Регистрация: 19.02.2013 Сообщений: 172
	15.11.2019, 10:36 [ТС]	10
	Сообщение от insect_87 затем второе правило тут же, но в output, по метке конекшна назначить метку маршрута через yota, имеется ввиду через l2tp ? Код add action=mark-connection chain=input in-interface=l2tp-office new-connection-mark=conn-l2tp passthrough=no src-address=192.168.11.0/24 add action=mark-routing chain=output connection-mark=conn-l2tp new-routing-mark=rm-l2tp passthrough=no Код add comment="Office via l2tp" distance=1 dst-address=192.168.11.0/24 gateway=192.168.13.1 routing-mark=rm-l2tp не пашет как задумано цепляюсь с компа на 192.168.13.2 вырубаю в сейв моде основной интерфейс - и ... отваливаюсь сам хотя вроде всё на резервном канале по l2tp после отката почему-то падает маршрутизация по gre ребут маршрутизатора - маршрут по gre восстанавливается в рабочее время уже не буду эксперементировать народ нервничает 0

	15.11.2019, 12:10

Опции темы

@insect_87 Модератор 11427 / 6996 / 1903 Регистрация: 25.12.2012 Сообщений: 29,398
	15.11.2019, 10:46	11
	В первом правиле passthrough=yes В правиле маршрута вместо шлюза укажите интерфейс l2tp-office При проверке вырубать основной канал не обязательно До проверки ребутните роутер на всякий 1

@GTAlex 45 / 6 / 1 Регистрация: 19.02.2013 Сообщений: 172
	15.11.2019, 11:09 [ТС]	12
	Сообщение от insect_87 В первом правиле passthrough=yes Passthrough Ничего не делать. Передать пакет на следующее правило. Однако при этом счетчики работают, показывая сколько пакетов соответствовало этому правилу. Обычно используется для статистики. если ничего не делать - получается что он и коннекшен метить не будет? чего то недопонимаю я с этим "passthrough=yes" Сообщение от insect_87 В правиле маршрута вместо шлюза укажите интерфейс l2tp-office тут тоже не понимаю - в мануалах обычно рекомендуют именно айпишник интерфейса указывать Сообщение от insect_87 При проверке вырубать основной канал не обязательно как тогда проверить работоспособность данного решения предусмотренного в случае падения основного канала? Сообщение от insect_87 До проверки ребутните роутер на всякий Ок Добавлено через 12 минут Код add action=mark-routing chain=output dst-address=93.91.162.154 dst-port=1701 new-routing-mark=rm-Yota passthrough=no protocol=udp add action=mark-connection chain=input in-interface=l2tp-office new-connection-mark=conn-l2tp passthrough=yes src-address=192.168.11.0/24 add action=mark-routing chain=output connection-mark=conn-l2tp new-routing-mark=rm-l2tp passthrough=no Код add comment="Office via l2tp" distance=1 dst-address=192.168.11.0/24 gateway=l2tp-office routing-mark=rm-l2tp ребутнул МТ2 проверял "по старинке" - зацепился на 192.168.13.2 и вырубил в сейв моде основной маршрут ... меня выкинуло 0

@.None 4284 / 1621 / 325 Регистрация: 23.06.2009 Сообщений: 5,788
	15.11.2019, 11:19	13
	Сообщение от GTAlex зацепился на 192.168.13.2 с какого ip подключались? давайте еще раз посмотрим правила маршрутизации на обеих концах, ip route print я бы привел правила к виду Код add action=mark-connection chain=input in-interface=l2tp-office new-connection-mark=conn-l2tp passthrough=yes add action=mark-routing chain=output connection-mark=conn-l2tp new-routing-mark=rm-l2tp passthrough=no add comment="Office via l2tp" distance=1 dst-address=0.0.0.0/0 gateway=192.168.13.1 routing-mark=rm-l2tp т.е. убрал критерий src-address=192.168.11.0/24 из соображений что любой трафик пришедший через VPN должен туда же и уходить и в маршруте все же указал бы ip адрес шлюза вопрос остается в фаерволом ip furewall filter rules, там ничего не запрещается (forward input output) что касается туннеля? 1

@GTAlex 45 / 6 / 1 Регистрация: 19.02.2013 Сообщений: 172
	15.11.2019, 11:27 [ТС]	14
	Сообщение от .None с какого ip подключались? 192.168.11.100 - мой комп в локалке офиса сейчас поправлю правило, отрублю всё в фаерволе и проверю ещё раз 0

@.None 4284 / 1621 / 325 Регистрация: 23.06.2009 Сообщений: 5,788
	15.11.2019, 11:28	15
	+ ко всему, эти правила маркируют соединения пришедшие через туннель и предназначенные самому микротику (цепочка input output) и отправляют обратно в туннель, для транзитного трафика (из сети в сеть) необходимо делать отдельную маркировку и mark-routing в цепочках forward и prerouting соответственно 1

@GTAlex 45 / 6 / 1 Регистрация: 19.02.2013 Сообщений: 172
	15.11.2019, 11:41 [ТС]	16
	Сообщение от .None + ко всему, эти правила маркируют соединения пришедшие через туннель и предназначенные самому микротику (цепочка input output) и отправляют обратно в туннель, для транзитного трафика (из сети в сеть) необходимо делать отдельную маркировку и mark-routing в цепочках forward и prerouting соответственно вот тут не понял мне нужно из локалки с МТ1 зацепиться к МТ2 по резервному интерфейсу при работающем основном все настройки делаются на МТ2 - в нём по идее никакого транзитного трафика нет Добавлено через 5 минут Сообщение от .None вопрос остается в фаерволом ip furewall filter rules, там ничего не запрещается (forward input output) что касается туннеля? при работающем основном канале я без проблем цепляюсь на 192.168.13.2 и работаю значит в фаерволе ничего не запрещается вот почему при отключении основного я отваливаюсь - вопрос а как ещё тестировать - не пойму 0

@.None 4284 / 1621 / 325 Регистрация: 23.06.2009 Сообщений: 5,788
	15.11.2019, 11:50	17
	тут нужно смотреть в комплексе, работает ли туннель при отключении основного канала, может при обрыве основного перестает работать и туннель? после восстановления связи смотрите логи на удаленной стороне может там есть какая информация, поставьте постоянный пинг с микротика сервера на клиент по адресу 192.168.13.2, и разорвите основной канал, пинги продолжают идти? не работать может из-за маршрутизации, точно ли VPN идет через ОПСОСа? еще варианты диагностики это log правила, на микротике сервере в фильтре добавьте 2 log правила forward с src-addr 192.168.13.2 и второе с dst-addr 192.168.13.2, с ПК 192.168.11.100 запустите постоянный пинг на 192.168.13.2 и отключите основной канал, в логе будет информация, откуда, куда и через какой интерфейс пришел/ушел пакет, будет видно к примеру что пакет ушел, но назад не вернулся, log правила поднимите в самый вверх списка. 1

@GTAlex 45 / 6 / 1 Регистрация: 19.02.2013 Сообщений: 172
	15.11.2019, 12:01 [ТС]	19
	Сообщение от .None тут нужно смотреть в комплексе, работает ли туннель при отключении основного канала, может при обрыве основного перестает работать и туннель? похоже так и есть Сообщение от .None поставьте постоянный пинг с микротика сервера на клиент по адресу 192.168.13.2, и разорвите основной канал, пинги продолжают идти? пинг рвётся и меня тоже выкидывает Сообщение от .None не работать может из-за маршрутизации, точно ли VPN идет через ОПСОСа? что за ОПСОС? Сообщение от .None еще варианты диагностики это log правила, на микротике сервере в фильтре добавьте 2 log правила forward с src-addr 192.168.13.2 и второе с dst-addr 192.168.13.2, с ПК 192.168.11.100 запустите постоянный пинг на 192.168.13.2 и отключите основной канал, в логе будет информация, откуда, куда и через какой интерфейс пришел/ушел пакет, будет видно к примеру что пакет ушел, но назад не вернулся, log правила поднимите в самый вверх списка. Спасибо, буду пробовать! 0

@insect_87 Модератор 11427 / 6996 / 1903 Регистрация: 25.12.2012 Сообщений: 29,398
	15.11.2019, 12:10	20
	ОПСОС ? Оператор сотовой связи, йота GTAlex, у вас туннель l2tp точно через йоту стартанул? 1