Помогите разобраться с mtu OpenVPN.

[Pop70]

Ситуация такая.

Два сегмента одной сети соединены мостом OpenVPN (tap).

В качестве сервера Keenetic viva 3.9.8, клиент - omni II 2.16.D.12.0-8, через модем (3г,ЛТЕ).

Настраивалось всё давным-давно, по инструкции в соответствующей статье.

Впринципе "всё работает", но недавно понадобилось гонять через туннель онлайн кинотеатр от МТС, и вылезли глюки. Видеопоток не идёт.

Начал разбираться с mtu, и заметил странную вещь.

При указании в конфигах сервера и клиента одного и того же tun-mtu, в логах клиента выскакивает ворниниг на тему несовпадения mtu на сторонах туннеля. На клиенте показывает mtu на 32 байта больше, чем в параметре tun-mtu.

Например, пишу с обеих сторон tun-mtu 1500, вылазит предупреждение с цифрами tun-mtu локально 1532, удалённо 1500.

Попробовал на клиенте указать 1468. Получил предупреждение уже о различиях уже в link-mtu. Теперь уже с разницей в 32 в обратную сторону. (на сервере больше, на клиенте меньше).

Победить удалось только прописав на обеих сторонах

 tun-mtu-extra 0.

Сейчас предупреждений нет.

tun-mtu 1450

tun-mtu-extra 0

С этими записями в конфигах, видеотрафик пошёл.

Но... Проблема решена не окончательно. При попытках пинговать через туннель разными по длине пакетами, максимально "пролазящий" 1408(1436). Пакеты большего размера через туннель не пролазят и не фрагментируются.

При пинге с винды, от 1409 по 1472 просто 100% потеря пакетов, без ругани на "требуется фрагментация".

Пинг с андроида через туннель, начиная с 1409 вообще затыкается. При этом, напрямую, через локальный шлюз и модем, пинги с андроида ходят любого размера до любых удалённых адресов.

Т.е., "затык" где-то в туннеле.

Специалисты, прошу помощи.

Как заставить всю систему работать? Чтобы, при необходимости, пакеты фрагментировались перед туннелем, или самим openvpn в туннеле, а не терялись.

mssfix не помогает.

На fragment омни 2 ругается, и не поднимает туннель вообще.

 

Изменено 1 июня, 2023 пользователем Pop70

[stefbarinov]

А галочка в чек-боксе "Подстройка TCP MSS" не решает проблему? Помимо MTU существует еще и MSS.

Изменено 1 июня, 2023 пользователем stefbarinov

[Pop70]

  В 01.06.2023 в 04:16, stefbarinov сказал:

А галочка в чек-боксе "Подстройка TCP MSS" не решает проблему? Помимо MTU существует еще и MSS.

Показать  

Галочку эту пришлось вообще снять. Иначе, видео не ходило. Оно похоже шифрованное.

Поставил снова, вылезло

WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1450)

И снова старт воспроизведения не проходит

Изменено 1 июня, 2023 пользователем Pop70

[stefbarinov]

  В 01.06.2023 в 03:34, Pop70 сказал:

понадобилось гонять через туннель онлайн кинотеатр от МТС

Показать  

Почему выбор пал на менее скоростной OVPN? Omni II не "задыхается", когда поток льется? Если попробовать EOIP over GRE при условии, что поток от МТС работает только в L2 сегменте.

Изменено 1 июня, 2023 пользователем stefbarinov

[Pop70]

  В 01.06.2023 в 04:30, stefbarinov сказал:

Почему выбор пал на менее скоростной OVPN? Omni II не "задыхается", когда поток льется? Если попробовать EOIP over GRE при условии, что поток от МТС работает только в L2 сегменте.

Показать  

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

[Pop70]

Может, я не прав, но, возможно, дело в модемном подключении? Просто udp пакеты от openvpn в него не пролазят. А кинетики - нет - не захлёбываются. До 10 Мбит видел скорости через тоннель А рабочих хватает пары, в том числе на кинотеатр в режиме "фоновый шум телевизора"

[Pop70]

  В 01.06.2023 в 09:13, ANDYBOND сказал:

Касаемо смартфона, Гугль любит на всех своих сервисах и устройствах MTU 1400.

Показать  

Через тоннель, и со смартфона не более 1408(1436). А через модем на стороне омни2 любой.

Почему и спрашиваю про настройку всей системы. 

Ovpn на нестандартном порту, поэтому врядли блочится udp трафик самого линка ovpn.

Я вообще плохо понимаю как работает mtu/mru в масштабах всей сети. Простой бытовой чайник. Поэтому, и прошу помощи спецов.

Если я настроил tun-mtu в самом ovpn 1450, то нужно ли изменять mtu/mru на интерфейсе OpenVPN1 в роутере. Он, к тому же, объединён с другими интерфейсами в мост "Home" на обеих сторонах. Нужно ли изменять дефолтные настройки всех интерфейсов, и как? (В смысле какие параметры? mtu? ,mru? и сколько нужно "в граммах"?

Если затык в mtu модемного соединения (а в настройках интерфейса cdc mtu1500), то нужно ли понизить mtu там?

Что делать, и делать ли с mtu/mru на интерфейсах со стороны сервера?

В общем, если с натройками tun-mtu, я, вроде как, справился (?), то как "это работает" в моей сети вцелом, я просто не понимаю.

В туннель от винды не влазит больше 1436 байт(почему не 1450?), винда сама хочет фрагментировать пакет только начиная с 1501. Понизить mtu (или mru?) на всех интерфейсах роутера? 

Как согласовать размеры пакета во всей сети?

А, может быть, это вообще не так работает?

В общем, катастрофически не хватает знаний.

[Pop70]

  В 01.06.2023 в 11:37, ANDYBOND сказал:

По ссылкам выше: Вы определяете MSS, а не MTU. MTU=MSS+служебный трафик.

Показать  

Не-не... Я уже добавил служебный в цифре 1436.

Проходит максимум ping -f -l 1408.

1409 уже не идёт вообще, а с 1473 ругается на запрет фрагментации.

Вот и не понятно. Если tun-mtu 1450, то куда ещё 14 байт mtu делось? Может это быть из-за того, что уже link-mtu при tun-mtu 1450 куда-то "не пролазит"?

 

[Pop70]

  В 01.06.2023 в 11:37, ANDYBOND сказал:

Главное - от узла до узла.

Показать  

Вот этот момент мне и не ясен.

"Узел" - это "комп с виндой", "кинетик", "модем"...

А интерфейс "OpenVPN1" в кинетике - это "узел", или не "узел"

[Pop70]

  В 01.06.2023 в 11:59, ANDYBOND сказал:

Т.е., если фрагментацию разрешить, пакет проходит?

Показать  

Через туннель нет. Напрямую в интернет - да. Он же фрагментирует "по максимуму", по mtu до следующего узла. А на интерфейсе, к которому подключен комп mtu 1500

[Pop70]

  В 01.06.2023 в 12:04, ANDYBOND сказал:

для OVPN 2.4

Показать  

Т.е., ещё уменьшить tun-mtu на обоих концах туннеля?

Допустим, пишу им (серверу и клиенту)  tun-mtu 1436

А на интерфейсе "Home" (к которому комп подключен) надо "подравнять", или кинетик, получив 1500, отправит в интерфейс openvpn1 уже значение как в tun-mtu, фрагментировав пакет, или отбосит, если df ? Но там же "мост"...?

Изменено 1 июня, 2023 пользователем Pop70

[Pop70]

  В 01.06.2023 в 12:18, ANDYBOND сказал:

само разберётся

Показать  

ОК, спасибо. Буду пробовать. 

[Pop70]

  В 01.06.2023 в 12:18, ANDYBOND сказал:

  В 01.06.2023 в 12:14, Pop70 сказал:

Т.е., ещё уменьшить tun-mtu на обеих концах туннеля?

Допустим, пишу им (серверу и клиенту)  tun-mtu 1436

Показать  

Да.

Показать  

Не помогло. Теперь через туннель проходит  ping -l 1394

 mtu снова на 14 байт меньше, чем должно быть.

ping с разрешённой фрагментацией, больше, чем -l 1394 просто теряется. Не фрагментируется.

 

[Pop70]

  В 01.06.2023 в 12:18, ANDYBOND сказал:

  В 01.06.2023 в 12:14, Pop70 сказал:

Т.е., ещё уменьшить tun-mtu на обеих концах туннеля?

Допустим, пишу им (серверу и клиенту)  tun-mtu 1436

Показать  

Да.

Показать  

Ха!

Помогло обратное.

Прописал tun-mtu 1514, и теперь пинги ведут себя как положено.

С -f идут по -l 1472, потом ругаются на "не фрагментировать"

Без -f пинги ходят любые.

OpenVPN где-то сжирает ещё 14 байт от параметра tun-mtu.

Реальный mtu в туннеле на 14 байт меньше, чем параметр tun-mtu.

Возможно, это из-за разных версий клиента и сервера?

Или так и должно быть?

[Pop70]

  В 01.06.2023 в 13:41, ANDYBOND сказал:

У OpenVPN и свой служебный трафик имеется.

Показать  

Я думал, что этот "служебный трафик" учитывается в link-mtu, а tun-mtu, по идее, должен соответствовать mtu пакетов в виртуальном туннеле.

[krass]

  В 01.06.2023 в 13:43, ANDYBOND сказал:

Но не при соединении со старыми версиями как то 2.16.

Показать  

Есть небольшая надежда что и там обновят openvpn

[Pop70]

  В 01.06.2023 в 13:43, ANDYBOND сказал:

В версии прошивки 4.0, где возможно, можно будет не терять эти 14 байт. Но не при соединении со старыми версиями как то 2.16. Так что у Вас лучшее из возможного.

Показать  

Вот отсюда, видимо, и расхождения в соответствии link-mtu и tun-mtu, и разный "зачёт" tun-mtu-extra в разных версиях ovpn?

[krass]

  В 01.06.2023 в 13:47, ANDYBOND сказал:

И флешку прирастят, да?

Показать  

Ну 2.16 на многих роутерах в том числе и на кн-1810 ультра. К тому же всегда есть возможность убрать ненужные модули, освободив тем самым место...

[Pop70]

  В 01.06.2023 в 13:47, ANDYBOND сказал:

Нет.

А без идеи в домашнем сегменте могут одновременно работать разные VPN с разными MTU, и всё само собой автоматически нормально согласуется. Это - внутреннее дело маршрутизатора.

Показать  

Без идеи, tap-интерфейс - это как провод между свичами. У него не может быть "своего mtu". Там даже маршрутизатор "не маршрутизирует" - "просто мост".

С tun - другое дело.

[Pop70]

  В 01.06.2023 в 13:53, ANDYBOND сказал:

у других VPN MTU другой

Показать  

Другие - по сути L3. А tap в ovpn - это L2. - что на уровне L2 "прилетело" с одной стороны, то же на другой стороне и "вылетело". Только на уровне link-ов по L3 ходит.

Тот же L2tp в мост не цепляется, а потому, что "вход-выход", всёже, L3

Ну, так мне это виделось.

Ещё раз спасибо за помощь.