Pop70
-
Posts
338 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by Pop70
-
-
26 минут назад, ANDYBOND сказал:30 минут назад, Pop70 сказал:
Т.е., ещё уменьшить tun-mtu на обеих концах туннеля?
Допустим, пишу им (серверу и клиенту) tun-mtu 1436
Да.
Не помогло. Теперь через туннель проходит ping -l 1394
mtu снова на 14 байт меньше, чем должно быть.
ping с разрешённой фрагментацией, больше, чем -l 1394 просто теряется. Не фрагментируется.
-
Только что, ANDYBOND сказал:
само разберётся
ОК, спасибо. Буду пробовать.
-
11 минуту назад, ANDYBOND сказал:
для OVPN 2.4
Т.е., ещё уменьшить tun-mtu на обоих концах туннеля?
Допустим, пишу им (серверу и клиенту) tun-mtu 1436
А на интерфейсе "Home" (к которому комп подключен) надо "подравнять", или кинетик, получив 1500, отправит в интерфейс openvpn1 уже значение как в tun-mtu, фрагментировав пакет, или отбосит, если df ? Но там же "мост"...?
-
Только что, ANDYBOND сказал:
Т.е., если фрагментацию разрешить, пакет проходит?
Через туннель нет. Напрямую в интернет - да. Он же фрагментирует "по максимуму", по mtu до следующего узла. А на интерфейсе, к которому подключен комп mtu 1500
-
19 минут назад, ANDYBOND сказал:
Главное - от узла до узла.
Вот этот момент мне и не ясен.
"Узел" - это "комп с виндой", "кинетик", "модем"...
А интерфейс "OpenVPN1" в кинетике - это "узел", или не "узел"
-
10 минут назад, ANDYBOND сказал:
По ссылкам выше: Вы определяете MSS, а не MTU. MTU=MSS+служебный трафик.
Не-не... Я уже добавил служебный в цифре 1436.
Проходит максимум ping -f -l 1408.
1409 уже не идёт вообще, а с 1473 ругается на запрет фрагментации.
Вот и не понятно. Если tun-mtu 1450, то куда ещё 14 байт mtu делось? Может это быть из-за того, что уже link-mtu при tun-mtu 1450 куда-то "не пролазит"?
-
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?) на всех интерфейсах роутера?
Как согласовать размеры пакета во всей сети?
А, может быть, это вообще не так работает?
В общем, катастрофически не хватает знаний.
-
Может, я не прав, но, возможно, дело в модемном подключении? Просто udp пакеты от openvpn в него не пролазят. А кинетики - нет - не захлёбываются. До 10 Мбит видел скорости через тоннель А рабочих хватает пары, в том числе на кинотеатр в режиме "фоновый шум телевизора"
-
8 минут назад, stefbarinov сказал:
Почему выбор пал на менее скоростной OVPN? Omni II не "задыхается", когда поток льется? Если попробовать EOIP over GRE при условии, что поток от МТС работает только в L2 сегменте.
Потому, что кинотеатр - не основное. Мне нужна одна, единая сеть на двух концах туннеля. Мне так проще решать другие задачи. Кинотеатр раньше гонял через локальный шлюз (и модем). А сейчас МТС палит винду на раздаче с модема, и обрезает скорость на подключении до неприличных цифр, включая собственный к-т-тр. Вот и заверрнул всех виндовых клиентов через тоннель.
-
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)
И снова старт воспроизведения не проходит
-
Ситуация такая.
Два сегмента одной сети соединены мостом 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 ругается, и не поднимает туннель вообще.
-
В 22.05.2023 в 14:52, ANDYBOND сказал:
По ссылке из ссылки:
"Требуется, чтобы видеокамеры находились в одной подсети и выходили в Интернет через основной шлюз на Keenetic Lite, а у остальных пользователей шлюзом оставался Keenetic."
несколько иная задача, не находите?
Требуется, чтобы шлюзом на обе подсети был ОДИН И ТОТ ЖЕ кинетик, но для кинетика были основным шлюзом РАЗНЫЕ точки подключения к интернету этого кинетика.
Как это сделать с двумя кинетиками понятно и без VLAN.
Это возможно через VLAN организовать, не выходя vlan-ом за пределы кинетика?
Есть интерфейс "домашняя сеть", есть интерфейс "гостевая сеть", есть интерфейс "модем", есть интерфейс "L2TPVPN"
Возможно ли так, чтобы входящий трафик "тегировался" на интерфейсах "гостевая сеть" и "L2TPVPN", разруливался в кинетике с тегами, независимо от трафика "домашняя сеть"-"модем", а на выходе из интерфейсов теги снимались - т.е., за пределами кинетика весь трафик нетегированный?
Кинетик - вполне себе "для средних умов", пока не требуются "несредние" задачи. А в остальном хотелось бы надеяться на более дружественную поддержку, чем... И от "несредних" пользователей тоже.
Согласитесь, что "собственная ОС", как бы подразумевает возможность ознакомиться не только с тем, что "можно потыкать в интерфейсе", и не только на уровне "РТФМ".
-
20 часов назад, ANDYBOND сказал:
И, при этом, клиент не может просто переключиться с одного провайдера на другого. Прописал политику ноутбуку ходить через ВПН - и всё. На прямой канал, не меняя политики, его никак не переключить. А хотелось бы на уровне "домашняя сеть"/"гостевая сеть" ходить по разным маршрутам.
Это впринципе возможно?
Одну сеть nat-ить в один интерфейс, а другую - в другой?
-
ip http proxy {domain} x-real-ip
-
1
-
-
В 27.03.2023 в 14:38, panivan сказал:
Скажите пожалуйста, а как Вы настраиваете безопасность?
В Вашем кинетике пробрасываются HTTP-заголовки?
У меня на kn-1810 не пробрасываются заголовки:
HTTP_CLIENT_IP = HTTP_X_REAL_IP = HTTP_X_FORWARDED_FOR = REMOTE_ADDR =192.168.8.1Соответственно прописывая в trusted_domains IP роутера сразу отключаешь защиту от брутфорса для всех.
Ну и в логах Nextcloud также везде IP роутера и не понять кто откуда пришел.
Через CLI в кинетике настраивается проброс заголовков.
-
Не, ребяты...
Проблема есть. У меня на даче омни-2 тоже периодически начинает вышвыривать определённые конкретные устройства из сети. Причём, в логах пишет "оно само дисконнектилось". И одни чаще, другие реже...
Рестарт кинетика на какое-то время проблему снимает. Причём, "холодный"(с отключением питания) надёжнее. А потом "снова здорова"
Перепробовал всё, что советовали. Одного только не пробовал - всё руки не дойдут. Блок питания роутера заменить. Есть подозрение на него, т.к., напряжение низковато. В районе 10-11В, при заявленных 12.
-
43 минуты назад, kodio сказал:
Есть ли опыт в использовании российских VPN-сервисов, чтобы организовать соединение через свой Keenetic?
Нет цели прятаться от кого-то либо получать доступ к запрещении, просто отечественный сервис, через который можно быстро и безопасно пользоваться Интернет.
А чем Вас не устраивает прямое подключение к провайдеру?
В чём сакральный смысл "ходить в интернет через впн через интернет"?
-
1
-
-
1 час назад, Роман25 сказал:
Пусть будет платно. А порты настроить и клиенту можно самому в WEB-е, как в настройках на DDNS сервисах. Жду от Кинетика платный DDNS-сервис, оплатил подписку на год - получил дополнительный функционал. Можно это на аутсорсинг отдать даже. Например мне)))
Вы сами написали:
"А зачем тут кинетик?"
А зачем Вам их "аутсорсинг"?
Поднимите свой, собственный сервис, и зарабатывайте.
-
1
-
1
-
-
26 минут назад, Роман25 сказал:
Да пусть любой из 65535 вариантов присваивается, номер порта прослушивания SSH/Telnet я могу поменять легко. А если DDNS использовать, то вообще всё просто. Если бы ещё для этого дела Кинетик запустил свой DDNS сервер с перенаправлением на нужный порт, было бы идеально.
Согласитесь, что это несколько более сложная система, чем http прокси сервер. Кроме имени, Вам ещё и порты выдавать индивидуально. Это уже уровень хостинга, и врядли может быть "бесплатно".
-
В 22.07.2022 в 04:39, alex_ne_ya сказал:
я бы хотел разделить часть на впн, часть обычный интернет. А как это сделать не представляю, т.к. нуб.
Есть профили доступа клиентов.
В разных профилях, разные приоритеты сетевых подключений.
-
1 час назад, Nikolay Zagorodnov сказал:
В NAS (192.168.1.100) создал маршрут:
ip route add 192.168.50.0/24 via 192.168.1.1На Windows машине создал маршрут:
route add 192.168.50.0 mask 255.255.255.0 192.168.1.1А зачем?
У Вас в сети 1.0 и так должен быть маршрут по умолчанию 192.168.1.1
-
1 час назад, Nikolay Zagorodnov сказал:
Думаете это всё из-за этой настройки?
Я думаю, что NAT на интерфейсе сервера не пускает пакеты из 192.168.50.0 (и 8.0) обратно.
Если сервер подменяет исходящий адрес пинга на свой, то и устройство-клиент 4g отвечает на ip роутера-сервера.
Поэтому, клиент из сети 192.168.1.0 не получает ответа.
У Вас сеть клиентов 4g за NAT, по отношению к сети спидстера.
NAT нужно отключать, и всё делать маршрутами, включая интернет через туннель.
-
20 часов назад, Nikolay Zagorodnov сказал:
Тоннель используется для доступа к интернет для пользователей сети 192.168.50.x, с этим проблем нет.
А не тут ли собака порылась?
Галочка "использовать подключение для выхода в интернет" на стороне клиента стоит?
А если убрать?
Вобщем, похоже, что это NAT.
-
На спидстере (192.168.1.1) маршрут
До сети
192.168.8.0/24
Шлюз 192.168.50.1
ИМХО, мало загнать маршрут в туннель, нужно указать ШЛЮЗ, который знает эту сеть.
А на 4Г (192.168.50.1), при подключенном модеме, есть маршрут до этого модема.
Помогите разобраться с mtu OpenVPN.
in Обсуждение IPsec, OpenVPN и других туннелей
Posted
Ха!
Помогло обратное.
Прописал tun-mtu 1514, и теперь пинги ведут себя как положено.
С -f идут по -l 1472, потом ругаются на "не фрагментировать"
Без -f пинги ходят любые.
OpenVPN где-то сжирает ещё 14 байт от параметра tun-mtu.
Реальный mtu в туннеле на 14 байт меньше, чем параметр tun-mtu.
Возможно, это из-за разных версий клиента и сервера?
Или так и должно быть?