тунель построен не микротом, микрот только порта пробрасывает, на обоих концах тунеля linux.

понтяно где проверять. Я о другом. как наличие или отстуствие маршрута на PC влияет на MTU? Мне казалось что в нарисованной мной схеме вообще никак. Если тунель кривой то он будет кривой не зависимо от того как туда трафик направлять.

Я может не до конца розобрался в схеме сети. Но разве клиенты не должны получать маршрут 10.8.10.0/24 на 192.168.0.10 при подключении к впн? Зачем их там вручную потом прописывать?

Добрый день, коллеги ! Скажите, может кто видел такое чудо: GSM-шлюз со встроенным роутером и портом FXS?

не, 192.168.0.0/24 это внутренняя сетка. клиенты подключаются к ВПН и получают адреса вида 10.8.10.0/24. ПК стоит в сетке 192.168.0.0. От микрота требуется только построить маршрут вида IP 10.8.10.0/24 gateway 192.168.0.10. Или отправить туда пакеты сразу от ПК, построив на нем такой же статический маршрут. Дальнейшие отношения между 192.168.0.0. и 10.8.10.0 это задача сервера. Там что то натится, что то фильтруется, что то дропается. Там вообще всего много, и ВПН на нем не один... Так вот я не понимаю почему получается разница кто строит маршрут. Физически не канал, не подключения при этом не меняются. Согласно диаграмме на HAP ac2 все порты в один свич-чип идут, и не должно быть вляния кто строит маршрут - таблица на PC или на самом микрот. Но оно (влияние) есть, вот и пытаюсь разобраться.

Возможно, когда маршрут прописан на РС, он знает что маршрут лежит через пк в его же подсети. Формируется Ehternet фрейм и отправляется срузу прямиком на пк сервер через свитч микротика без участия маршрутизации cpu и так дальше. если же РС не знает что маршрут идет через пк в его подсети то формируется tcp пакет и отправляется в начале на шлюз по умолчанию, а там уже через cpu, и на нужный пк, из за етого задрежки и возникают. Пардон если не то что то пишу.

Да, но не в 80 раз же задержки???? Я понимаю что то что то не докрутил в микроте, но не понимаю что? И опять же, по работе интернета вопросов нет. Это ТОЛЬКО про завернутые внутри локалки маршруты.

Просто догадка. Попробуйте добавить правило chain=srcnat action=masquerade dst-address=102.168.0.10 log=no log-prefix=""

Сейчас попробую. какой эффект от этого надо ожидать?

Ну по хорошему задержки должны бы пропасть 😊 Не зная всей конфигурации сети можно только догадываться. Но я думаю так, без маршура на PC он отправляет пакет на 192.168.0.1 (шлюз) с адресом отправителя 192.168.0.2 (своим). Роутер отправляет его уже на 192.168.0.10. А вот 192.168.0.10 уже может отправлять ответ не через роутер а на прямую на 192.168.0.2 так как знает что ето адрес в его подсети.

ну задержки не пропали, правда и счетчик в правиле не натикал.... 10 chain=srcnat action=masquerade dst-address=192.168.0.10 log=no log-prefix="" По поводу кто куда отправляет - логика работы свич-чипа непонятна. Если маршрут прописан на ПК то прилетает пакет и свич понимает что его надо отдать в порт куда воткнут адресат (192.168.0.10). В ситуации если парилетает пакет для 10.8.10.2 то из таблицы свич должен получить маршрут до 10.8.10.2 через 192.168.0.10. и отправить пакет туда. (туда же как и в первом случае) Не понимаю где здесь прилиает такая задержка.

На Linux проверяйте мту и смотрите mss корректно высчитывается

в тунель пролезает 1500-28 не зависимо от того как маршрут выстраивается.

В первом случаи свичу ничего не надо искать. У него есть таблица мак адресов с пренадлежащими ему ип адресами. И РС отправляет пакет не на ип адрес а на мак адрес которому пренадлежит 192.168.0.10. У РС тоже есть таблица маков и он знает все маки своей подсети. Свич работает без участия цпу, ну или с минимальным участием. Если же маршрута нету то отправляется пакет на сам роутер а там уже учавствует цпу, таблицы маршрутицаций, фильтраций и так дальше. Если говорите что счетчик не натикал может попробуйте по выше в таблице его перетянуть.

Маршрут есть. Именно для этого (как я понимаю) и есть таблица маршрутизации со статическими и динамически маршрутами.

Я имел ввиду что когда нету маршрута на РС, то пакет обрабатывается цпу микротика, а когда маршрут есть и ето маршрут в его же подсети, то пакет обрабатывается только свиччипом микротика. Но Вы правы, в 80 раз задержки все ровно быть не должно.

да не должен ЦПУ его обрабатывать.

Ну маршрутизацией же цпу занимается. На микротик прилетает пакет с адресом отправителя 192.168.0.2 и адресом назначения 10.8.10.0/24. Микротик смотрит что подсеть 10.8.10.0/24 доступна через ип 192.168.0.10 так как на нем прописан етот маршрут. После етого формирует весь етот пакет в Ehternet фрейм и отправляет на 192.168.0.10. Между етим пропуская весь етот пакет через фаервол, проверяя розрешена ли такая пересылка Всем етим цпу занимается. Ну а на 192.168.0.10 уже етот Ehternet фрейм розбирается и пакет отправляется получателю.

В чем тогда прелесть отдельног свич-чипа если каждый пакет гонять через ЦПУ?

switching / routing

так я и ожидаю switсhing в описанной ситуации, нет там правил для роутинга по этим адресам, только статический маршрут. А получаю какую то дичь.

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

Разница есть. Сам сталкивался с таким при использовании QinQ на цыско. Очень странно когда на компе какие то сайты открываются а какие то нет, а оказывается что проблема в мту. Так что вполне возможно.

Это говорит от том, что где то по трассе к неоткрывшемуся сайту есть узел который прибиват большие пакеты. У меня же ситуация иная - маршрут через один и тот же тунель прокладывается в любом случае. И параметры тунеля не имеют (не должны иметь) связи с тем, как маршрут по локалке проложен. В общем вечером попробую.

У вас меняется маршрут от Вашего компа к клиенту впн. Когда маршрут прописан на РС то пакет идет через свич чип, без участвия роутинга на микротике. А когда маршрута на РС нету то пакет идет уже через роутер с участием маршрутизации на микротике, подменой ип адреосв отправителя получателя формированием новых фреймов и так дальше. Я понимаю что выглядит оно вроде одинаково. Но пакет в первом и во втором случаи проходит по разным путям и над ним разные манипуляции производятся.

да откуда же там маршрутизация то возьмется? switching да, но не затратный routing. Маршрутизацией уже занимается VPN сервер, кторый является отдельной сущностью, не микротиком.

Знаю я причину.

афаик микротик не умеет расшивать IP на свитччипе

Ну в таком виде я и сам ее знаю Я собственно и сравнимаю две ситуации - когда шлюз до хостов за ВПН статически прописан на ПС и когда шлюз до хостов статически прописан на микроте (он шлюз по умолчанию для ПС). И не понимаю почему если маршрут проложен через микрот получается такой лаг.

Друзья, а не подскажите как скриптом, перевести модуль лте в микротике на другую частоту? с 3G на LTE и обратно http://joxi.ru/Dr8MP5LhzvPV0m

Ну в консоли потыкайте табом на этом интерфейсе.

Друзья, а не подскажите как скриптом, перевести модуль лте в микротике на другую частоту? с 3G на LTE и обратно http://joxi.ru/Dr8MP5LhzvPV0m

А для чего переводить скриптом?

да тыкал... видать не туда )))

Ну 4g в любом случае будет выше, чем 3g с той же базовой станции, даже в часы пик

/interface lte set <tab> 2 раза

/interface lte set <tab> 2 раза

http://joxi.ru/8AnqbeyS7WWyx2 я не могу понять, номер чего, какого показателя он от меня требует? 0_0 вводил от 1 до 10 в ответ error

number=0

http://joxi.ru/8AnqbeyS7WWyx2 я не могу понять, номер чего, какого показателя он от меня требует? 0_0 вводил от 1 до 10 в ответ error

Потому как есть несимметричная маршрутизация. И есть invalid трафик. Который отсеивается микротом и/или линуксом

Ребята, помогите. Настроил L2TP+IPsec тунель. С сервером всё в порядке, айфон подключается без костылей. А вот шпротик (выступает в качестве клиента) подключается, но трафик не гоняет. С роутами всё в порядке, с DNS тоже. Судя по данным wget с ноутбука – трафик уходит, но не приходит (причём похоже, что не всегда). В чём проблема? Может с NAT накосячил? Да вроде нет, srcnat masquerade на L2TP интерфейс стоит (интерфейс добавлен в WAN группу interface list). В чём может быть причина?

Ребята, помогите. Настроил L2TP+IPsec тунель. С сервером всё в порядке, айфон подключается без костылей. А вот шпротик (выступает в качестве клиента) подключается, но трафик не гоняет. С роутами всё в порядке, с DNS тоже. Судя по данным wget с ноутбука – трафик уходит, но не приходит (причём похоже, что не всегда). В чём проблема? Может с NAT накосячил? Да вроде нет, srcnat masquerade на L2TP интерфейс стоит (интерфейс добавлен в WAN группу interface list). В чём может быть причина?