Помогите разобраться с 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]

13 минуты назад, 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]

58 минут назад, Pop70 сказал:

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

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

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

[Pop70]

8 минут назад, stefbarinov сказал:

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

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

[Pop70]

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

[Pop70]

1 час назад, 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]

10 минут назад, ANDYBOND сказал:

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

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

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

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

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

 

[Pop70]

19 минут назад, ANDYBOND сказал:

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

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

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

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

[Pop70]

Только что, ANDYBOND сказал:

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

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

[Pop70]

11 минуту назад, ANDYBOND сказал:

для OVPN 2.4

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

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

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

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

[Pop70]

Только что, ANDYBOND сказал:

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

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

[Pop70]

26 минут назад, ANDYBOND сказал:

30 минут назад, Pop70 сказал:

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

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

Да.

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

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

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

 

[Pop70]

53 минуты назад, ANDYBOND сказал:

57 минут назад, Pop70 сказал:

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

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

Да.

Ха!

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

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

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

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

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

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

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

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

[Pop70]

Только что, ANDYBOND сказал:

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

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

[krass]

1 минуту назад, ANDYBOND сказал:

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

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

[Pop70]

Только что, ANDYBOND сказал:

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

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

[krass]

1 минуту назад, ANDYBOND сказал:

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

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

[Pop70]

Только что, ANDYBOND сказал:

Нет.

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

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

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

[Pop70]

Только что, ANDYBOND сказал:

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

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

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

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

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