Russian Users MikroTik | Форум пользователей MikroTik

есть несколько офисов.
в центральном стоит микротик и к нему коннектятся через l2tp микротики из других офисов.

в центральном офисе в локальной сети стоит сервер на котором запущен софт который взаимодействует с клиентами в локальных сетях удаленных офисов.

софт при запросе от клиента выдает данные из таблицы по порядку. софт работает по UDP. т.е. пришел запрос, ответили на запрос туда откуда он пришел.

всё работает без каких либо проблем...
НО... иногда... при переподключении l2tp тоннеля запросы от клиента приходят, сервер отправляет ответы, но клиент их не получает.

мне кажется, что происходит это из за того что в момент запроса от клиента, на центральном маршрутизаторе не поднят/не работает роут на локальную сеть из которой клиент отправляет запрос(та что находится за клиентским микротиком).

почему мне так кажется, потому что отключив руками роут на эту локальную сеть я вижу точно такую же ситуацию... запросы приходят на сервер из этой сети а ответ к ним не доходит так как роут я выключил...

как мне кажется нужно с этим бороться:
мне кажется так как центральный микротик не знает о наличии локальной сети за клиентским микротиком(отключен роут на нее вручную) то все пакеты от неизвестной сети мы должны дропать а не пересылать к серверу, но микротик их пересылает...

вопрос:
как сделать чтобы пакеты не пересылались.... ну и правильно ли это?


ну или еще ищу других советов/рекомендаций....

п.с. решил не загружать тему списком роутов, так как вродь всё понятно написано, но если нужно, добавлю...

После переподключения маршруты в таблице в WinBox каким цветом????

И в качестве шлюза в маршруте указан IP адрес или имя интерфейса???

gmx писал(а):После переподключения маршруты в таблице в WinBox каким цветом????

И в качестве шлюза в маршруте указан IP адрес или имя интерфейса???

цвет черный
в качестве шлюза при автоматическом добавлении маршрута и ручном указывается IP а правее имя интерфейса...

Еще важен момент, у меня не получается воспроизвести такую ситуация руками чтобы отследить момент когда есть проблема...



сегодня утром была проблема с одним офисом.
логи:

центральный микротик
10:03:34 l2tp,info first L2TP UDP packet received from ХХ.ХХ.ХХ.ХХ
10:03:34 l2tp,ppp,info <l2tp-0>: waiting for call...
10:03:34 l2tp,ppp,info <l2tp-0>: authenticated
10:03:34 l2tp,ppp,info <l2tp-0>: connected
10:03:34 l2tp,ppp,info,account username logged in, 192.168.21.2
10:03:34 l2tp,ppp,info <l2tp-username-1>: using encoding - MPPE128 stateless
10:03:40 l2tp,ppp,info,account username logged out, 64167 71745031 64479364 63643
6 556434
10:03:40 l2tp,ppp,info <l2tp-username>: terminating... - administrator request
10:03:40 l2tp,ppp,info <l2tp-username>: disconnected



удаленный офис:

10:03:34 l2tp,ppp,info l2tp-out1: terminating... - session closed
10:03:34 l2tp,ppp,info l2tp-out1: disconnected
10:03:34 l2tp,ppp,info l2tp-out1: initializing...
10:03:34 l2tp,ppp,info l2tp-out1: connecting...
10:03:34 l2tp,ppp,info l2tp-out1: terminating... - old tunnel is not closed yet
10:03:34 l2tp,ppp,info l2tp-out1: disconnected
10:03:34 l2tp,ppp,info l2tp-out1: initializing...
10:03:34 l2tp,ppp,info l2tp-out1: connecting...
10:03:34 l2tp,ppp,info l2tp-out1: terminating... - old tunnel is not closed yet
10:03:34 l2tp,ppp,info l2tp-out1: disconnected
10:03:34 l2tp,ppp,info l2tp-out1: initializing...
10:03:34 l2tp,ppp,info l2tp-out1: connecting...
10:03:34 l2tp,ppp,info l2tp-out1: authenticated
10:03:34 l2tp,ppp,info l2tp-out1: connected
10:03:34 l2tp,ppp,info l2tp-out1: using encoding - MPPE128 stateless

пойдите инженерным путём:

а) поменяйте (временно, тест) в одном из филиалов тип подключения, скажем вместо L2TP сделайте подключение
скажем на SSTP или вообще воспользуйтесь не сеансовыми туннелями (IPIP или GRE)

b) сделайте туннель в туннеле, то есть поднимите L2TP и поверх него уже сделайте простой IPIP

с) попробуйте клиента (одного, с филиала) временно по EoIP туннелю пробросить прямо до сервера,
то есть у клиента станет адресация головного офиса и посмотрите как будет это работать.
с.1) попробуйте EoIP "натянуть" как по L2TP
c.2) попробуйте EoIP "натянуть" как по IPIP/GRE

Вышеназванные варианты возможно помогут, возможно во втором варианте UDP пакет пройдёт спокойно,
и ничего ему не помешает, хотя 3й вариант вообще покажет, проблема между филиалами, или
всё же сеть/сервер косячит иногда......
А в целом пока пришёл к мнению, что из-за переконнектов или из-за пересинхронизация L2TP протокола может
нарушать прохождения UDP пакетов, которые как мы знаем не имеют подтверждения доставки.

Цель моего сообщения - донести мысль, что возможно надо обыграть и/или перехитрить текущую ситуацию.

Vlad-2,
1 вариант пробовали и с пптп и сстп ситуацию это не меняло...
3 вариант не вариант, не можем утилизировать канал...

2й вариант буду пробовать, спасибо...


может еще у кого идеи будут какие?
я вообще прав что udp пакет не должен от клиента доходить до сервера если не активен маршрут о сети из которой он поступает на центральном микротике?

Когда я Вам писал первое моё сообщение, я Ваше второе сообщение с логами не видел.
Но как я и предположил, разрывы у Вас есть, и по логам видно, что сессия отвалилась,
а вторая не может подняться, потому что от первой остался след.

uhi писал(а):Vlad-2,
1 вариант пробовали и с пптп и сстп ситуацию это не меняло...

Странно, это ещё больше настораживает...

uhi писал(а):3 вариант не вариант, не можем утилизировать канал...

Вот тут я Вас не понял, в каком смысле утилизировать?
Взять клиентское место с установленным клиентом или настроенным доступом до сервера, подключить этого клиента напрямую в порт микротика в филиале,
дать ему адресацию локальную головного офиса, сбридживать его ether-порт с EoIP туннелем, и такой же туннель с таким же ID поднять на головном офисе и
сбридживать/или добавить EoIP в основную сеть(адресацию) где сервер стоит. Всё, клиент и сервер в рамках L2-layer рядом. Для них ничего нет, кроме фреймов,
и поработать так хотя бы 20мин или 2 часа, с нагрузкой приближённой к реалям.
Какая утилизация канала? Что Вы имели ввиду под утилизацией? Это всё можно сделать в рамках Ваших уже существующих и текущих L2TP связей.

uhi писал(а):2й вариант буду пробовать, спасибо...

Обязательно надо....

uhi писал(а):может еще у кого идеи будут какие?
я вообще прав что udp пакет не должен от клиента доходить до сервера если не активен маршрут о сети из которой он поступает на центральном микротике?

1) судя по разрывам сессий L2TP у вас не стабильный канал в целом, и думаю тут никак не связано с UDP пакетами. Думаю программисты и разработчики предусмотрели
вариант работы программы по UDP и что пакеты могут теряться и не доходить.
Поэтому думаю что проблема с каналаобразующей техникой. Поэтому и советую проверить через туннель EoIP и ещё пару разными вариантами.
2) на счёт пакета UDP и что он должен или не должен, я Вашу фразу не до конца понимаю её смысл, поэтому отвечу как я понимаю маршрутизацию (в очень при очень простом варианте):
а) если пакет от клиента вышел, дошёл до роутера и тут роутер должен посмотреть у себя, а есть ли у него описание сети и как туда попасть на которую ссылается пакет?
б) если в таблице маршрутизации есть явное описание сети, то роутер загонит пакет по тому маршруту....
в) если нет явного описания, у роутера любого почти должна быть маршрут по дефолту, туда этот пакет и попадёт
г) если этот маршрут будет на какой то головной роутер, он до головного офиса и дойдёт
д) а если дефолтный маршрут - это связь/канал с провайдером, то пакет уйдёт туда
е) провайдер (если хороший,чёткий и не используется серую адресацию у себя в сети) - убъёт пакет на ближайшем пограничном маршрутизаторе,
ё) а если провайдер плохой, он адрес в пакете примит за свой и ещё куда то его отправит......

P.S.
Ещё мысля стрельнула: думал об утилизации Вашей, и ведь сам L2TP протокол не плохой,но и нагрузку даёт существенную,
так что там с каналами и с нагрузками в целом? Может Вы упёрлись в какое то ограничения?

вы писали:
Но как я и предположил, разрывы у Вас есть, и по логам видно, что сессия отвалилась,
а вторая не может подняться, потому что от первой остался след.
так да... я же в первом сообщении и написал что проблема возникает когда переподключается l2tp...


по поводу утилизации первая попавшаяся статья была от https://netflow.by/blog/item/114-eoip-mikrotik
ну и как-то список недостатков в статье меня оттолкнул
но потом обратился к
https://wiki.mikrotik.com/wiki/Russian/ ... D0%B8_EoIP

и решил последовать вашему совету, 2 филиала перевел на EoIP, посмотрим что будет

на счет опасений про нагрузки и каналы, то там всё норм в это точно не упираемся.

по поводу:
1) судя по разрывам сессий L2TP у вас не стабильный канал в целом, и думаю тут никак не связано с UDP пакетами. Думаю программисты и разработчики предусмотрели вариант работы программы по UDP и что пакеты могут теряться и не доходить.
целая беда с этим софтом... никто-ничего не предусмотрел :(

по поводу стабильных каналов, обычные адсл модемы со сбросом сессии через 3 суток со стороны провайдера...

наблюдаем что будет

uhi писал(а):вы писали:
Но как я и предположил, разрывы у Вас есть, и по логам видно, что сессия отвалилась,
а вторая не может подняться, потому что от первой остался след.
так да... я же в первом сообщении и написал что проблема возникает когда переподключается l2tp...

Все смешалось в кучу люди, кони..
Кто это написал???

Последнее предложение вроде бы топикстартер.
За зависшими сессиями следит протокол Keep Alive. Он отключает сессию по тайм-ауту, если нету ответа от встречного VPN. Он настроен у вас на ваших VPN, причем с обеих сторон???

gmx писал(а):

uhi писал(а):вы писали:
Но как я и предположил, разрывы у Вас есть, и по логам видно, что сессия отвалилась,
а вторая не может подняться, потому что от первой остался след.
так да... я же в первом сообщении и написал что проблема возникает когда переподключается l2tp...

Все смешалось в кучу люди, кони..
Кто это написал???

Последнее предложение вроде бы топикстартер.
За зависшими сессиями следит протокол Keep Alive. Он отключает сессию по тайм-ауту, если нету ответа от встречного VPN. Он настроен у вас на ваших VPN, причем с обеих сторон???

keep alive
на l2tp сервере и клиенте стояло 60
на клиенте до начала бодания стояло 60, потом изменил на 5

на EoIP не стоит keep alive

вот лог с центрального микротика:
06:33:02 l2tp,ppp,info <l2tp-tadamvo>: terminating... - hungup
06:33:02 l2tp,ppp,info,account tadamvo logged out, 7465 2175623 2851822 19390 24101
06:33:02 l2tp,ppp,info <l2tp-tadamvo>: disconnected
06:33:02 interface,info eoip-tunnel_moi link down
06:33:02 l2tp,info first L2TP UDP packet received from хх.хх.х.ххх
06:33:03 l2tp,ppp,info,account tadamvo logged in, 192.168.24.2
06:33:03 l2tp,ppp,info <l2tp-tadamvo>: authenticated
06:33:03 l2tp,ppp,info <l2tp-tadamvo>: connected
06:33:03 l2tp,ppp,info <l2tp-tadamvo>: using encoding - MPPE128 stateless
06:33:03 interface,info eoip-tunnel_moi link up

судя по логам сервера, запросы без ответов начались в 06:32:45, т.е. в это время клиент уже не получил от сервера ответ.

такое ощущение что тонннеле остановился траффик от центрального маршрутизатора к клиенту в 06:32:45

какой keep alive выставить для l2tp и для EoIP сервера и клиента?
рискну предположить что для l2tp клиенту и серверу выставлять 5 так как юдп пакеты отправляются через 10 секунд...

настроил на сервере и клиенте keep alive 5
дисконнект в 19:55:

поставил логирование ежесекундное пингов к клиентскому компу
в 19:55:15 перестал пинговаться клиентский комп
в 19:55:55 начал пинговаться клиентский комп


центральный
19:55:42 l2tp,ppp,info <l2tp-tadamvo>: terminating... - peer is not responding
19:55:42 l2tp,ppp,info,account tadamvo logged out, 16357 76050898 79002450 563610 572708
19:55:42 l2tp,ppp,info <l2tp-tadamvo>: disconnected
19:55:42 interface,info eoip-tunnel_moi link down
19:55:52 l2tp,info first L2TP UDP packet received from хх.хх.хх.хх
19:55:53 l2tp,ppp,info,account tadamvo logged in, 192.168.24.2
19:55:53 l2tp,ppp,info <l2tp-tadamvo>: authenticated
19:55:53 l2tp,ppp,info <l2tp-tadamvo>: connected
19:55:53 l2tp,ppp,info <l2tp-tadamvo>: using encoding - MPPE128 stateless
19:55:53 interface,info eoip-tunnel_moi link up


клиентский:
19:55:28 l2tp,ppp,info l2tp-out1: terminating... - peer is not responding
19:55:28 l2tp,ppp,info l2tp-out1: disconnected
19:55:28 l2tp,ppp,info l2tp-out1: initializing...
19:55:28 l2tp,ppp,info l2tp-out1: connecting...
19:55:28 interface,info eoip-tunnel_moi link down
19:55:52 l2tp,ppp,info l2tp-out1: terminating... - session closed
19:55:52 l2tp,ppp,info l2tp-out1: disconnected
19:55:52 l2tp,ppp,info l2tp-out1: initializing...
19:55:52 l2tp,ppp,info l2tp-out1: connecting...
19:55:52 l2tp,ppp,info l2tp-out1: terminating... - old tunnel is not closed yet
19:55:52 l2tp,ppp,info l2tp-out1: disconnected
19:55:52 l2tp,ppp,info l2tp-out1: initializing...
19:55:52 l2tp,ppp,info l2tp-out1: connecting...
19:55:53 l2tp,ppp,info l2tp-out1: authenticated
19:55:53 l2tp,ppp,info l2tp-out1: connected
19:55:53 l2tp,ppp,info l2tp-out1: using encoding - MPPE128 stateless
19:55:56 interface,info eoip-tunnel_moi link up


по логам есть самый главный вопрос:

в 19:55:15 перестал пинговаться комп клиентский и мы видим из лога, клиентский микротик рубанул подключение
19:55:28 l2tp,ppp,info l2tp-out1: terminating... - peer is not responding

через 13 секунд, ну я предположу что время могло на винде и микротике отличаться на пару секунд и тут keepalive вродь как отработал нормально...
но почему центральный микротик увидел разрыв только через 27 секунд после остановки пингов и через 14 секунд когда клиентский уже 100% прервал свою сессию.... то есть его 100% не было уже....:
19:55:42 l2tp,ppp,info <l2tp-tadamvo>: terminating... - peer is not responding

может еще где-то нужна дополнительная настройка keep alive кроме как в настройках l2tp сервера?