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

Здравствуйте! Есть 2 роутера Микротик, оба ходят в интернет через Йоту. У одной Йоты есть внешний адрес, у второй нет. Йота без внешнего адреса подключается к Йоте с внешним адресом по L2TP + IPSEC, а потом еще идет EoIP. И вся эта конструкция нормально работает до того момента пока Йота без внешника не получает новую динамику от своих серверов. При этом интернет продолжает работать, но подключение уже не устанавливается. Скрипты на перезапуск Йоты без перезапуска всего Микротика проблему не решают, но зато стоит перезагрузить Тик с Йотой без внешника полностью, как он подключается, но уже с новым динамическим адресом. На данный момент сделал скрипт на перезапуск Тика в случае если по VPN перестает пинговать сервер в другом офисе. Вопрос заключается в том, можно ли как то обойтись без постоянных перезагрузок Тика когда Йота решает вдруг сменить динамику на модеме?

А что в логах в это время???

А еще такое бывает, когда в маршрутах указаны IP адреса, а не интерфейсы в качестве шлюза.

В логах банальная попытка конекта дисконект без ошибок и прочего. По поводу маршрутов там поверх L2TP + IPSEC идет EoIP и маршруты сделаны через бриджи добавлением в него интерфейса EoIP. Но в любом случае везде почти всегда выставляю интерфейсы, так что это тут не при чем. Ну и еще один момент я забыл озвучить, на том Микротике который выступает в роли сервера, провайдера два. Второй провайдер обычный проводной и при переключении на него (он как резервный настроен) все подключается. Проверялось по такой схеме: вот Йота к Йоте уже не хочет подключаться, запускаю скрипт на перезапуск Йоты на серверном Микротике, пока Йота недоступна он сам переключает интернет на резервный канал, а на втором Микротике в этот момент автоматом срабатывает скрипт переключения VPN на второго провайдера на сервере и все подключается. Но как только Йота поднимается и интернет начинает ходить через нее все по старому, попытка подключения и все. Перезагружаешь клиентский Тик все снова хорошо на какое то время (я так понял раз в сутки). Логи примерно такие, ничего информативного (Message "Server Mikrotik": connecting...). Использовать PPtP пробовал, эффекта не дало, проблем еще больше. Ну и стоит сказать, что все остальные VPN клиенты коих штук 10 (у которых инэт не от Йоты), никуда никогда не отваливаются.

описание конечно "мега"
1) делайте со второго микротика(с серого) два подключения (то бишь создавайте два L2TP) подключения на белый (соответственно первое подключение на первый айпи(на 1й пров), и на второе подключение на 2й пров)
2) делайте на втором микротике(на сером) два маршрута до первого микротика, НО разными дистанциями, наименьшая будет у более основного соединения, дистанция более повыше у второго подключения.
3) остальные маршруты (если есть на первый микротик) также продублировать...

Если банально подходить, у Вас будут "два линка", но работать будет один, упал основной канал/связь/пров - станет не активным и маршрут, сработает второй (но работать будет если
основной микротик работает, работает второй провайдер и более менее логика настроек сделано нормально и без хитрых моментов)....как-то так...

Именно так все и настроено, но вопрос в другом. Это не вопрос настройки маршрутов и прочего, такие схемы настроены подобным образом в 3 местах и проблемы есть только с Йотой. Да можно переделать настройки чтобы были доступны сразу оба провайдера и на второго повесить VPN, но хотелось бы попробовать понять можно ли что-то сделать с Йотой в такой схеме которая есть. По Вашей схеме (которая итак у меня настроена) ничего не сработает потому что на обоих Тиках будет инэт и будет нормально пинговаться Йота, а так как доступа ко второму провайдеру нет пока доступен первый это ничего не дает, а перезагрузка USB по скрипту аля нетвоч пинг устройство с другой стороны впна, если нет ответа перезапуск не помогает.

m4f1ozy писал(а):Именно так все и настроено

m4f1ozy писал(а):Да можно переделать настройки чтобы были доступны сразу оба провайдера

Вы как-то противоречите сами себе!?
У Вас настроено всё же одним линком или с двумя?
Я думаю правильнее уже сделать небольшую схему, а мож и конфиги показать.

Я Вам предложил сделать логическое резервирование, то есть у Вас 2 линка и 2 маршрута, если падает линк,то падает и маршрут,
роутер знает, что если маршрут упал, туда он пакеты уже не гонит, правда чтобы это всё работало, надо в маршруте чтобы ВЫ выставили это проверять (что надо обязательно).

Также коли у Вас проблемы именно с Иота, может в туннельно-сеансовых протоколах таймауты местами где-то уменьшить,
а где-то увеличить. То есть посмотрите по логам, на основном микротике, при обрыве сколько в секундах проходит время до поднятия интерфейса
главного? Может тогда от этого "плясать" и сделать таймаут в L2TP побольше, скажем N+15 sec ?

P.S.
Возможно при здравом подходе и скрипты не понадобятся !?
P.P.S.
Мне кажется проблема на основном микротике, два провайдера, иота, вопрос = правильно ли там "разруливается" маршрутизация при обрыве,
да и L2TP не быстрый протокол, его вообще могут блокировать/ограничивать внутри сети Иота!?
Попробуйте медленный, но везде пролазивающий SSTP

Спасибо за ответы, есть ряд интересных идей. Буду пробовать, пока решилось изменением типа Caller ID с IP на Number в настройках L2TP сервера, но это временный костыль.

Vlad-2 писал(а): ↑11 сен 2017, 10:58 Возможно при здравом подходе и скрипты не понадобятся !?
P.P.S.
Мне кажется проблема на основном микротике, два провайдера, иота, вопрос = правильно ли там "разруливается" маршрутизация при обрыве,
да и L2TP не быстрый протокол, его вообще могут блокировать/ограничивать внутри сети Иота!?
Попробуйте медленный, но везде пролазивающий SSTP

Если о работе с Етой, то без скриптов тут никак...

SSTP только и годится для административных целей, двигать по нему что-то тяжелое - вообще не вариант, жутко тормозной туннель. L2TP это лучшее, что есть у Микротика, т.к. работает по UDP и когда клиенты за серым IP, это единственный способ организовать между сервером и ними реально быстрый канал. Плюс в последних версиях отлично работает многоканальное подключение (MRRU) - наконец-то можно забыть о геморе с MTU в локальных сетях. Не режет L2TP его даже МТС на смартфонных тарифах и еще пяток наших Владивостокских провайдеров за этим не замечены. А вот с Етой поймал похожие странности как у ТС.

m4f1ozy, есть какие-либо еще успехи?

У меня схема следующая. На одной точке стоит центральный роутер, к нему по LANу подключены несколько других роутеров с разными провайдерами с белыми айпишниками, все эти роутеры настроены на DST-NAT всех протоколов и портов на центральный роутер, на нем же поднят L2TP сервер. Разумеется на центральном роутере настроены MANGLE правила и маршруты для ответа на тот интерфейс, с которого пришел запрос. Такая схема работает безупречно, любой клиент может подключиться через любого провайдера по L2TP. Смартфоны, другие роутеры, Windows клиенты - без разницы. Правда в Windows через реестр требуется включить NAT-T для IPSEC, но это мелочи. Одним из провайдеров является Yota с внешним айпишником - с ним тоже нет проблем. И без разницы какие у клиентов айпишники, белые или серые.

Но вот в другом месте стоит роутер с Yota, с интерфейсом LTE и другим L2TP сервером. Уже 3 дня разбираюсь, но не могу понять. Подключаются только клиенты с серыми айпишниками. С обоих стороны создается по паре SA'сов, но пакетики бегут только от клиента в сторону сервера, на самом сервере все "по нолям" и потом соединение рвется и так у всех до бесконечности.

У меня есть подозрение, что белый айпишники присваиваются клиентам Еты через какой-то костыль и именно в этом месте проблемы. Почему при этом хорошо работает схема, где применяется DST-NAT с внешнего IP адреса, на локальный L2TP сервер, мне совсем не понятно...

С логов особо ничего не понимаю, вот вырезка с лога клиента (1.1.1.1 это сервер, 2.2.2.2 - клиент):

Код: Выделить всё

21:02:36 l2tp,ppp,info L2TP-CLIENT (tax1.mydomain.ru): terminating... - session closed 
21:02:36 l2tp,ppp,info L2TP-CLIENT (tax1.mydomain.ru): disconnected 
21:02:37 ipsec,info ISAKMP-SA deleted 2.2.2.2[500]-1.1.1.1[500] spi:0780d3409a8c44b8:02e22ac44e1f35ab rekey:1 
21:02:46 l2tp,ppp,info L2TP-CLIENT (tax1.mydomain.ru): initializing... 
21:02:46 l2tp,ppp,info L2TP-CLIENT (tax1.mydomain.ru): connecting... 
21:02:46 ipsec,info initiate new phase 1 (Identity Protection): 2.2.2.2[500]<=>1.1.1.1[500] 
21:02:48 ipsec,info ISAKMP-SA established 2.2.2.2[500]-1.1.1.1[500] spi:576efa7f25956486:3a5806d890b3cadc 
21:02:48 system,info log rule changed by admin 
21:02:50 system,info log rule changed by admin 
21:05:10 l2tp,debug,packet     (M) Host-Name="ANDERSON" 
21:05:10 l2tp,debug,packet     Vendor-Name="MikroTik" 
21:05:10 l2tp,debug,packet     (M) Assigned-Tunnel-ID=42 
21:05:10 l2tp,debug,packet     (M) Receive-Window-Size=4 
21:05:18 l2tp,debug,packet sent control message to 1.1.1.1:1701 from 0.0.0.0:1701 
21:05:18 l2tp,debug,packet     tunnel-id=0, session-id=0, ns=0, nr=0 
21:05:18 l2tp,debug,packet     (M) Message-Type=SCCRQ 
21:05:18 l2tp,debug,packet     (M) Protocol-Version=0x01:00 
21:05:18 l2tp,debug,packet     (M) Framing-Capabilities=0x1 
21:05:18 l2tp,debug,packet     (M) Bearer-Capabilities=0x0 
21:05:18 l2tp,debug,packet     Firmware-Revision=0x1 
21:05:18 l2tp,debug,packet     (M) Host-Name="ANDERSON" 
21:05:18 l2tp,debug,packet     Vendor-Name="MikroTik" 
21:05:18 l2tp,debug,packet     (M) Assigned-Tunnel-ID=42 
21:05:18 l2tp,debug,packet     (M) Receive-Window-Size=4 
21:05:26 l2tp,debug tunnel 42 received no replies, disconnecting 
21:05:26 l2tp,debug tunnel 42 entering state: dead 
21:05:26 l2tp,debug session 1 entering state: dead 
21:05:26 l2tp,ppp,debug L2TP-CLIENT (tax1.mydomain.ru): CCP close 
21:05:26 l2tp,ppp,debug L2TP-CLIENT (tax1.mydomain.ru): BCP close 
21:05:26 l2tp,ppp,debug L2TP-CLIENT (tax1.mydomain.ru): IPCP close 
21:05:26 l2tp,ppp,debug L2TP-CLIENT (tax1.mydomain.ru): IPV6CP close 
21:05:26 l2tp,ppp,debug L2TP-CLIENT (tax1.mydomain.ru): MPLSCP close 
21:05:26 l2tp,ppp,info L2TP-CLIENT (tax1.mydomain.ru): terminating... - session closed 
21:05:26 l2tp,ppp,debug L2TP-CLIENT (tax1.mydomain.ru): LCP lowerdown 
21:05:26 l2tp,ppp,debug L2TP-CLIENT (tax1.mydomain.ru): LCP down event in initial state 
21:05:26 l2tp,ppp,info L2TP-CLIENT (tax1.mydomain.ru): disconnected 
21:05:27 ipsec,debug Deleting a Ph2... 
21:05:27 ipsec,debug compute IV for phase2 
21:05:27 ipsec,debug phase1 last IV: 
21:05:27 ipsec,debug a9823ed8 b0ca37ef ecbba1bb 67aaafc3 d4f8cfd3 
21:05:27 ipsec,debug hash(sha1) 
21:05:27 ipsec,debug encryption(aes) 
21:05:27 ipsec,debug phase2 IV computed: 
21:05:27 ipsec,debug 6e7a7dad 6f0bf96f 0d6c766e 818b305f 
21:05:27 ipsec,debug HASH with: 
21:05:27 ipsec,debug d4f8cfd3 00000010 00000001 03040001 08c44b38 
21:05:27 ipsec,debug hmac(hmac_sha1) 
21:05:27 ipsec,debug HASH computed: 
21:05:27 ipsec,debug e5ee9e0f 156ae4e6 ac6020e3 165cc482 39baf764 
21:05:27 ipsec,debug begin encryption. 
21:05:27 ipsec,debug encryption(aes) 
21:05:27 ipsec,debug pad length = 8 
21:05:27 ipsec,debug 0c000018 e5ee9e0f 156ae4e6 ac6020e3 165cc482 39baf764 00000010 00000001 
21:05:27 ipsec,debug 03040001 08c44b38 5ddcf064 a25e5207 
21:05:27 ipsec,debug encryption(aes) 
21:05:27 ipsec,debug with key: 
21:05:27 ipsec,debug ccd4948d 02f67ad2 709fccc3 99b132ab 12495ddc 53d70620 0f42bbfd f33816f8 
21:05:27 ipsec,debug encrypted payload by IV: 
21:05:27 ipsec,debug 6e7a7dad 6f0bf96f 0d6c766e 818b305f 
21:05:27 ipsec,debug save IV for next: 
21:05:27 ipsec,debug c6817d2b 08a9c01c 256bec28 0c37360a 
21:05:27 ipsec,debug encrypted. 
21:05:27 ipsec,debug 76 bytes from 2.2.2.2[500] to 1.1.1.1[500] 
21:05:27 ipsec,debug 1 times of 76 bytes message will be sent to 1.1.1.1[500] 
21:05:27 ipsec,debug,packet 9fc486ca 38e225c1 0d0e347a 74b75662 08100501 d4f8cfd3 0000004c 5ee74b82 
21:05:27 ipsec,debug,packet 8f82723b ce085acf 6708db64 153acb78 af0a65d4 a2a8ff97 ac6501e1 c6817d2b 
21:05:27 ipsec,debug,packet 08a9c01c 256bec28 0c37360a 
21:05:27 ipsec,debug sendto Information delete. 
21:05:27 ipsec purged IPsec-SA proto_id=ESP spi=0x32f13a9 
21:05:27 ipsec purged IPsec-SA proto_id=ESP spi=0x8c44b38 
21:05:27 ipsec,debug an undead schedule has been deleted. 
21:05:27 ipsec,debug Removing PH1... 
21:05:27 ipsec,debug compute IV for phase2 
21:05:27 ipsec,debug phase1 last IV: 
21:05:27 ipsec,debug a9823ed8 b0ca37ef ecbba1bb 67aaafc3 ca4cb58a 
21:05:27 ipsec,debug hash(sha1) 
21:05:27 ipsec,debug encryption(aes) 
21:05:27 ipsec,debug phase2 IV computed: 
21:05:27 ipsec,debug fad3dd8b 0ef78a4e 4e4d5e5e 17b101a5 
21:05:27 ipsec,debug HASH with: 
21:05:27 ipsec,debug ca4cb58a 0000001c 00000001 01100001 9fc486ca 38e225c1 0d0e347a 74b75662 
21:05:27 ipsec,debug hmac(hmac_sha1) 
21:05:27 ipsec,debug HASH computed: 
21:05:27 ipsec,debug 3f723c98 e4c87a80 ea2b3857 eb910500 825c8561 
21:05:27 ipsec,debug begin encryption. 
21:05:27 ipsec,debug encryption(aes) 
21:05:27 ipsec,debug pad length = 12 
21:05:27 ipsec,debug 0c000018 3f723c98 e4c87a80 ea2b3857 eb910500 825c8561 0000001c 00000001 
21:05:27 ipsec,debug 01100001 9fc486ca 38e225c1 0d0e347a 74b75662 d055e525 5908f446 a96b270b 
21:05:27 ipsec,debug encryption(aes) 
21:05:27 ipsec,debug with key: 
21:05:27 ipsec,debug ccd4948d 02f67ad2 709fccc3 99b132ab 12495ddc 53d70620 0f42bbfd f33816f8 
21:05:27 ipsec,debug encrypted payload by IV: 
21:05:27 ipsec,debug fad3dd8b 0ef78a4e 4e4d5e5e 17b101a5 
21:05:27 ipsec,debug save IV for next: 
21:05:27 ipsec,debug 242368b8 593d55d8 8d398214 9b057103 
21:05:27 ipsec,debug encrypted. 
21:05:27 ipsec,debug 92 bytes from 2.2.2.2[500] to 1.1.1.1[500] 
21:05:27 ipsec,debug 1 times of 92 bytes message will be sent to 1.1.1.1[500] 
21:05:27 ipsec,debug,packet 9fc486ca 38e225c1 0d0e347a 74b75662 08100501 ca4cb58a 0000005c cc1eb572 
21:05:27 ipsec,debug,packet 361beaf5 4cbea6dc ba486d9f b4359ec8 e02f97b0 c7933107 0c3da32f c624b269 
21:05:27 ipsec,debug,packet baf22f43 91cdd86d dfb62d48 242368b8 593d55d8 8d398214 9b057103 
21:05:27 ipsec,debug sendto Information delete. 
21:05:27 ipsec,info ISAKMP-SA deleted 2.2.2.2[500]-1.1.1.1[500] spi:9fc486ca38e225c1:0d0e347a74b75662 rekey:1 
21:05:27 ipsec,debug an undead schedule has been deleted. 
21:05:27 ipsec flushing active SAs due to setup change.. 
21:05:27 ipsec,debug unbind ::ffff:10.25.128.1 
21:05:27 ipsec,debug unbind ::ffff:10.25.128.129 
21:05:27 ipsec,debug unbind ::ffff:2.2.2.2

Кстати, тут никто не спросил, а у Вас какое устройство используется для доступа в сеть Yota? Часто используются USB свистки с двойным NAT, у меня с ними были проблемы именно с IPSEC L2TP. Сейчас использую модем Sierra Wireles MC7710 в режиме DIRECT IP (IP адрес присваивается непосредственно интерфейсу LTE).

Решил проблему. В цепочке INPUT файрвола нужно было открыть не только UDP порты 1701, 500, 4500, но так же отдельно разрешить протокол 50 (IPSEC-ESP).

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

Проблема с VPN, Yota.

Проблема с VPN, Yota.

Re: Проблема с VPN, Yota.

Re: Проблема с VPN, Yota.

Re: Проблема с VPN, Yota.

Re: Проблема с VPN, Yota.

Re: Проблема с VPN, Yota.

Re: Проблема с VPN, Yota.

Re: Проблема с VPN, Yota.

Re: Проблема с VPN, Yota.