Pop70

Заставить работать кинетик в таком случае можно только если одно из подключений пропустить через ещё один маршрутизатор (и его NAT).

Другие - по сути L3. А tap в ovpn - это L2. - что на уровне L2 "прилетело" с одной стороны, то же на другой стороне и "вылетело". Только на уровне link-ов по L3 ходит. Тот же L2tp в мост не цепляется, а потому, что "вход-выход", всёже, L3 Ну, так мне это виделось. Ещё раз спасибо за помощь.

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

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

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

Да. Ха! Помогло обратное. Прописал tun-mtu 1514, и теперь пинги ведут себя как положено. С -f идут по -l 1472, потом ругаются на "не фрагментировать" Без -f пинги ходят любые. OpenVPN где-то сжирает ещё 14 байт от параметра tun-mtu. Реальный mtu в туннеле на 14 байт меньше, чем параметр tun-mtu. Возможно, это из-за разных версий клиента и сервера? Или так и должно быть?

Да. Не помогло. Теперь через туннель проходит ping -l 1394 mtu снова на 14 байт меньше, чем должно быть. ping с разрешённой фрагментацией, больше, чем -l 1394 просто теряется. Не фрагментируется.

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

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

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

Вот этот момент мне и не ясен. "Узел" - это "комп с виндой", "кинетик", "модем"... А интерфейс "OpenVPN1" в кинетике - это "узел", или не "узел"

Не-не... Я уже добавил служебный в цифре 1436. Проходит максимум ping -f -l 1408. 1409 уже не идёт вообще, а с 1473 ругается на запрет фрагментации. Вот и не понятно. Если tun-mtu 1450, то куда ещё 14 байт mtu делось? Может это быть из-за того, что уже link-mtu при tun-mtu 1450 куда-то "не пролазит"?

Через тоннель, и со смартфона не более 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?) на всех интерфейсах роутера? Как согласовать размеры пакета во всей сети? А, может быть, это вообще не так работает? В общем, катастрофически не хватает знаний.

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

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

Галочку эту пришлось вообще снять. Иначе, видео не ходило. Оно похоже шифрованное. Поставил снова, вылезло WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1450) И снова старт воспроизведения не проходит

Ситуация такая. Два сегмента одной сети соединены мостом 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 ругается, и не поднимает туннель вообще.

По ссылке из ссылки: "Требуется, чтобы видеокамеры находились в одной подсети и выходили в Интернет через основной шлюз на Keenetic Lite, а у остальных пользователей шлюзом оставался Keenetic." несколько иная задача, не находите? Требуется, чтобы шлюзом на обе подсети был ОДИН И ТОТ ЖЕ кинетик, но для кинетика были основным шлюзом РАЗНЫЕ точки подключения к интернету этого кинетика. Как это сделать с двумя кинетиками понятно и без VLAN. Это возможно через VLAN организовать, не выходя vlan-ом за пределы кинетика? Есть интерфейс "домашняя сеть", есть интерфейс "гостевая сеть", есть интерфейс "модем", есть интерфейс "L2TPVPN" Возможно ли так, чтобы входящий трафик "тегировался" на интерфейсах "гостевая сеть" и "L2TPVPN", разруливался в кинетике с тегами, независимо от трафика "домашняя сеть"-"модем", а на выходе из интерфейсов теги снимались - т.е., за пределами кинетика весь трафик нетегированный? Кинетик - вполне себе "для средних умов", пока не требуются "несредние" задачи. А в остальном хотелось бы надеяться на более дружественную поддержку, чем... И от "несредних" пользователей тоже. Согласитесь, что "собственная ОС", как бы подразумевает возможность ознакомиться не только с тем, что "можно потыкать в интерфейсе", и не только на уровне "РТФМ".

И, при этом, клиент не может просто переключиться с одного провайдера на другого. Прописал политику ноутбуку ходить через ВПН - и всё. На прямой канал, не меняя политики, его никак не переключить. А хотелось бы на уровне "домашняя сеть"/"гостевая сеть" ходить по разным маршрутам. Это впринципе возможно? Одну сеть nat-ить в один интерфейс, а другую - в другой?

ip http proxy {domain} x-real-ip

Через CLI в кинетике настраивается проброс заголовков.

Не, ребяты... Проблема есть. У меня на даче омни-2 тоже периодически начинает вышвыривать определённые конкретные устройства из сети. Причём, в логах пишет "оно само дисконнектилось". И одни чаще, другие реже... Рестарт кинетика на какое-то время проблему снимает. Причём, "холодный"(с отключением питания) надёжнее. А потом "снова здорова" Перепробовал всё, что советовали. Одного только не пробовал - всё руки не дойдут. Блок питания роутера заменить. Есть подозрение на него, т.к., напряжение низковато. В районе 10-11В, при заявленных 12.

А чем Вас не устраивает прямое подключение к провайдеру? В чём сакральный смысл "ходить в интернет через впн через интернет"?

Вы сами написали: "А зачем тут кинетик?" А зачем Вам их "аутсорсинг"? Поднимите свой, собственный сервис, и зарабатывайте.

Согласитесь, что это несколько более сложная система, чем http прокси сервер. Кроме имени, Вам ещё и порты выдавать индивидуально. Это уже уровень хостинга, и врядли может быть "бесплатно".