vasek00

Ну наверное раз у вас Keenetic то может лучше даты статей май-июнь 2017 https://help.zyxel.ru/hc/ru/articles/214536685-Общие-рекомендации-по-построению-беспроводных-сетей https://help.keenetic.net/hc/ru/articles/213968709 https://help.keenetic.net/hc/ru/articles/213968749 Настройка роутера это еще пол беды, "остальное это возможности клиента"

Речь не о пропадании линка, а в момент когда было на подобие проблемка при схеме ПК ------(LAN) роутер (LAN) ------ (LAN)Keenetic(WAN)------ link на ПК показывал 10Мбит роутер Keenetic был не доступен по LAN, поэтому и возникло предположение, правда у вас GIII но все же. При такой схеме Keenetic не видел "Сегменты локальной сети" вообще. Второе если же он доступен по wi-fi то кто мешает изучить что на роутере случилось?

А вы можете посмотреть в данный момент времени что показывает LAN соединение на ПК - какую скорость 10-100-1000 соединения и в каком режиме у вас карта автосогласование или жестко скорость?

Про то и речь. Про DPI уже было упоминание - что его в реализации не будет, но думаю время покажет и все расставит по местам.

Опять же фишка в том, что данное устройство в маршруте пакета стоит в разрыве между клиентом и сервером, т.е. Сервер ----- устройство ---- Клиент. Он клиент будет думать что работает с сервером хотя на самом деле он работает с устройством. На счет комфортности, тут вы не правы так как в настоящие время железки уже есть http://www.qtech.ru/catalog/dp/, цена по нашим меркам существенная но для верхней 10 провайдеров/связи она посильна. Интересен DPI в качестве приорит.трафика и фильтрация - xt_nDPI https://github.com/vel21ripn/nDPI/tree/netfilter

tls для шифрования только начала соединения (handshake, тут не зашифрованная инфа), далее соединение установлено и вся инфа шифруется с помощью SSL openvpn это тоннель зашифрованный вне зависимости от tls.

Если очень нужно то из Entware - Samba

Кое что интересное нашел в данном поведении. Пояснения к графику ниже (обозначения интерфейсов по ifconfig): - br0 интерфейс Home в котором wi-fi + eth2.1(LAN), ppp0 (pppoe) пров.1 скорость до 100 привязка к eth2.2, ppp1 (pptp) пров.2 сег. скорость до 20 привязка eth2.4 - для поднятия ppp1 использовался LAN eth2.4, для ppp0 WAN eth2.2 - 9:33 старт торрента на ПК, def на ppp0 - 9:40 смена маршрута через ip ro replace default на ppp1 - 9:45 промежуточный результат, но как видно скорость упала до текущей на ppp1 - 9:50 смена маршрута через ip ro replace default на ppp0 и тут то как раз обратил внимание что якобы трафик идет через ppp1, подумал счетчик дал сбой, но нет ifconfig так же дает увеличение байтиков на ppp1 (хотя в связке он с eth2.4, но на нем тишина в отличие от eth2.2). Через ppp1 такой скорости быть не может. Вывод работает как бы правильно но информация не верна. eth2.2 Link encap:Ethernet HWaddr ... RX bytes:29461691523 (27.4 GiB) TX bytes:767221999 (731.6 MiB) ... eth2.4 Link encap:Ethernet HWaddr ... RX bytes:2737133463 (2.5 GiB) TX bytes:120769947 (115.1 MiB) ... ppp0 Link encap:Point-to-Point Protocol ... RX bytes:6880620968 (6.4 GiB) TX bytes:163160352 (155.6 MiB) ppp1 Link encap:Point-to-Point Protocol ... RX bytes:5066326633 (4.7 GiB) TX bytes:125398136 (119.5 MiB) через некоторо время eth2.2 Link encap:Ethernet HWaddr ... RX bytes:30000109890 (27.9 GiB) TX bytes:781012544 (744.8 MiB) ... eth2.4 Link encap:Ethernet HWaddr ... RX bytes:2737635241 (2.5 GiB) TX bytes:120800859 (115.2 MiB) ... ppp0 Link encap:Point-to-Point Protocol ... RX bytes:6880622486 (6.4 GiB) TX bytes:163189571 (155.6 MiB) ppp1 Link encap:Point-to-Point Protocol ... RX bytes:5604743749 (5.2 GiB) TX bytes:139170078 (132.7 MiB) Так же интересную деталь увидел на br0 (Home) при работе клиента на ПК (LAN) трафик для него от ppp0 попадает на eth2.1 (LAN) как и положено, но при работе через ppp1 трафик попал в br0 ( 9:40 смена def на ppp1 с ppp0), а с 9:30 при работе через ppp0 трафик только в eth2.1( для LAN клиента ). Вывод думаю не есть хорошо от попадания трафика в br0 от ppp1 для eth2.1.

Для информации - выключение канала через WEB со страницы /#broadband.globals как и говорил ранее это "down" и "up" данного интерфейса => и маршрутизация На 2.08 для начала достаточно было посмотреть что происходит с каналами. Как можно назвать "отрицательный эффект для 2-х каналов" вы о чем, если дальше речь идет о балансировке двух каналов - есть два варианта резервного канала - первый как есть, второй держать его в отключенном состоянии и поднимать при потери связи на основном разница будет на лицо - время его подъема. Не понятно что реально вкладывается в ваше сообщение-"самопроизвольным падением канала на разных прошивках", при ручном я описал выше. Например приведу пример (к теме постов отношения не имеет) многие пользователи пишут не работает интернет, при дальнейшем выясняется что канал активен а проблемы с DNS. Так как вы приложили selftest только для разработчиков то другим он не виден и что-то подсказать что и как не могут (конечно весь selftest не нужен). В вашем случае если вы на данном форуме то помимо selftest можно получить данные по системе даже обычными командами, которые предоставят так же полезную информацию что и как и именно по "самопроизвольным падением канала".

Для начала читать не умею, обучен со школы слева на право, по горизонтали. Проверим на 2.09.А.9.0.0 попроще поднимаю два канала в результате имеем PPPoE (ppp0) приоритет 1000 скорость 100Мбит и PPTP/L2TP (ppp1) приоритет 900 скорость 50Мбит /opt/tmp # ip ro | grep default default via хх.хх.хх.54 dev ppp1 меняем default в ручную (ждать чего то когда все это сделает система не хочется) /opt/tmp # ip ro replace default via хх.хх.хх.1 dev ppp0 1. запускаем на ПК торрент ждем пару минут (что скачка пошла) смотрим что имеем в таблице на роутере, кроме пары тек.для второго канала (т.е. только в сторону провайдера) там все для интерфейса ppp0 /opt/tmp # ip route list cache выводить весь список не вижу смысла 81.236.хх.хх from 192.168.1.2 dev ppp0 src 192.168.1.100 cache <src-direct> iif br0 ... 94.50.хх.хх from 192.168.1.2 dev ppp0 src 192.168.1.100 cache <src-direct> iif br0 ... и т.д. для ppp1 нет маршрутов 2. меняем маршрут default ip ro replace default via хх.хх.хх.52 dev ppp1 и смотрим / # ip route list cache 192.168.1.2 from 79.67.хх.хх dev br0 src хх.хх.хх.52 cache rtt 4ms rttvar 4ms cwnd 10 iif ppp0 94.179.хх.хх from 192.168.1.2 dev ppp1 src 192.168.1.100 cache <src-direct> iif br0 134.249.хх.хх from 192.168.1.2 dev ppp1 src 192.168.1.100 cache <src-direct> iif br0 192.168.1.2 from 185.18.хх.хх dev br0 src хх.хх.хх.52 cache <src-direct> rtt 4ms rttvar 4ms cwnd 10 iif ppp1 ... 3. смотрим на ПК и его торрент, как он качал со скоростью 9,1МБ так и качает. 4. проходит время и все устаканивается, т.е. скорость приходит в норму к 50Мбит согласно default ppp1. Запускаем процедуру обратную переход с ppp1 на ppp0, ждем скорости в районе 45Мбит и переходим на другой канал ppp0. Спустя некоторое время скорость канала поднялась, выше чем на ppp1. Нужно будет еще раз попробовать, что то разное получается время при переходе с PPPoE на PPTP/L2TP и на оборот с PPTP/L2TP на PPPoE, в первом случае как-то очень долго скорость не падает до уровня PPTP/L2TP. Теперь немного теории. Запись в таблице маршрутизации не вечна, если данный маршрут в кэше неактивен по моему около 5минут, то он просто удалиться из него, хотя соединение conntrack может еще быть активно, при запросе опять же по этому соединению но маршрута по нему нет да default уже сменился -> пойдет по новому маршруту (примечание у любых соединений есть время жизни в любом случае keep-alive). Есть переменные ядра которые устанавливают временные интервалы. Проверим память по значению 5минут: /proc/sys/net/ipv4/route # cat gc_interval 60 /proc/sys/net/ipv4/route # cat gc_timeout 300 /proc/sys/net/ipv4/route # cat min_adv_mss 256 /proc/sys/net/ipv4/route # cat max_size 16384 /proc/sys/net/ipv4/route # cat gc_elasticity 8 /proc/sys/net/ipv4/route # cat gc_thresh 1024 /proc/sys/net/ipv4/route # Переменные которые используются для сборки мусора в кэше, а к другому маршруту через gc_timeout, ограничение по max_size -> больше 10минут нет не чего. Использовать два канала с одним default можно только стат.маршрутами. Из всего делаю вывод кой какие не стыковки по времени работы якобы на 2.08 в отличие от 2.09 с двумя каналами.

С начала эту сессию нужно начать

Это уже пройденный этап - пользователю остается оперативно отслеживать мену порта и IP.

Так как в данном случае "пакет в пакете", то не нужен ни какой просмотр шифрования самих данных они не нужны, а нужно обработать только начальные байты заголовка на предмет вложенности пакета и определить его метки для данного сервера и ответы сервера для клиента. Речь идет о метки по которой можно определить принадлежность данного пакета данному приложению, т.е. это как поиск вируса по сигнатуре в файле.

m__a__l Речь шла о принципе работы двух маршрутов, а не про то что у вас исправилось или не исправилось, но сначала про :. Баг не какого отношения к двум маршрутам не имеет. А по поводу pingcheck - и если посмотреть на форуме посты про него (да и на ixbt тоже) то можно увидеть кучу примеров в основном все вешают его на проверку например на google, а вот он google могу сказать на все 100% на любом подключении роутера к интернету может вести себя по разному, т.е. сегодня даст отлуп а завтра нет. Я писал про свой опыт Pingchek на PPPoE на одном включенном канале, после его применения канал разорвался и не поднялся, это правда было давно (нужно попробовать на днях еще раз). Но вы перешли с 2.08 на 2.09, а если вы посмотрите список изменений по 2.08 поиск по L2TP то увидите кучу изменений Просто в "ручном отключении l2tp и повторном его включении" это просто "up" и "down", а вот когда pingchek проверил канал и переключил его на другой посчитав что он "плохой" просто на основании того что IP по которому он проверял не ответил он просто сделал замену default и только, а потом опять вернул (в логах можно увидеть, был ли сброс соединения или нет). Где-то уже описывали его работу - но все упомнить проблематично.

На много все проще - глубокий анализ пакетов на уровни DPI (сами данные кодированы не кодированы роли не играют они не нужны для провайдера), т.е. суть всего найти нужные "метки" в пакете по которым можно его заблокировать.

Это не "баг", а результат того что оба канала подняты. При таком раскладе как уже говорилось - оба канала подняты, но default через тот у которого приоритет выше. Итак ПК качает -> default на роутере куда надо, но самое главное помним что имеем TCP и UDP соединения. Пусть считаем что pingcheck переключил так как ему что-то не понравилось на данном канале -> default сменился, но сам то канал поднят и маршруты все остались кеш то никуда не делся (если конечно pingchek их не подчищает). Так как торент все еще работает то опять таки те соединения которые еще активны продолжают качать по старым маршрутам, те которые закрылись по причине переключения создадутся заново но по новому маршруту (так как default сменился на роутере). Теперь pingchek восстановил основной канал т.е. сделал его default и что имеем в итоге = активные соединения (по маршрутам) на двух каналах = это все прелести uTorrent и так же UDP потоков. Более точно можно сказать если посмотреть conntack и маршруты.

Для вас тогда найдете свой ответ Но для справки VPN сервисы могут быть блокированы - достаточно посмотреть принцип его работы и как результат

Маленький вопрос по dnscrypt-proxy функционал можно расширить с помощью плагинов, что-то типа https://github.com/jedisct1/dnscrypt-proxy/tree/master/src : - возвращает пустой ответ на запросы AAAA -> libdcplugin_example-ldns-aaaa-blocking - блокировка конкретных доменов и IP-адресов -> libdcplugin_example-ldns-blocking - запись клиентских запросов -> libdcplugin_example-logging - libdcplugin_example-ldns-forwarding "This plugin redirects queries for specific zones to a set of non-DNSCrypt resolvers. This can be useful for private zones that can only be resolved by a local DNS server." - dnscrypt-plugin-masquerade https://github.com/gchehab/dnscrypt-plugin-masquerade - dnscrypt-plugin-geoip-block https://github.com/jedisct1/dnscrypt-plugin-geoip-block Есть ли что-то для тек.релиза от Entware, интересен был бы libdcplugin_example-ldns-blocking Запуск dnscrypt-proxy ...--plugin=libdcplugin_example_ldns_blocking.so --domains=/etc/domain.lst --ips=/etc/blocking.ips --logfile=/var/log/dnscrypt.block.log ...

А что ждать, берете канал заводите, на странице IGMP прокси настройки чего и куда, на клиенте ПК например vlc и плейлист данного провайдера с его каналами (думаю у него он так же есть).

Вернемся к первому посту То же подумал сначала как и вы KorDen но потом - желательно гарантированно получить интернет и поток мультикаста (чтоб не зависал) имеем 3 приставки с общим потом до 100Мбит (пакеты UDP которые не требуют подтверждения) и противовес 5-6 компов по LAN и выход в интернет до 100Мбит/лок.ресурс выше 100Мбит (нагрузка если честно ни какая) MT7621 [GE1] -> встроенный -> WAN / IPTV MT7621 [GE2] -> RTL8370M -> WAN (vlan) +-----> LAN (Home) +-----> LAN (vlan) или MT7621 [GE1] -> встроенный -> WAN MT7621 [GE2] -> RTL8370M -> WAN / IPTV(vlan) +-----> LAN (Home) +-----> LAN (vlan) Напомню мощь CPU - 2ядра 4 потока какая нагрузка интернета может его загрузить ? Теперь если не смотреть на нагрузку (по барабану для такого проца), а на качество - стабильная работа интернета и стабильный поток на приставки. В любом случае практика может расходиться с теорией.

Ну это уже самый простой вариант, но мы легких путей не ищем, мало ли что по мимо IPTV со второго канала.

Это как из точки "А" попасть в "С" есть вариант напрямую и короче "А->C", а есть через "B" "А->B->C", что для вас будет проще, то и выбирайте : - вариант 1 создать таблицу маршрутизации для каналов - вариант 2 например промаркировать пакеты и направить опять же их в нужную таблицу маршрутизации согласно маркировке

Была же начата тема Для начало обратить внимание на странице /#broadband.globals - это Приоритет и Интернет, т.е. у вас интернет канал должен иметь приоритет выше чем созданный VPN (новый), тогда маршрут по умолчанию на интернет будет идти по основному каналу, а нужные сайты направить на новый интерфейс VPN.

Инет1 -------------- WAN1 (UII) WAN2 ------ IPTV Приставка1-------------(LAN) (LAN)---------Приставка2 Инет1 -------------- WAN1 (UII) LAN ------ LAN (Lite3) (WAN)----- IPTV Приставка1-------------(LAN) (LAN)---------Приставка2 т.е. схема 1 если на Ultra 2 добавить второй канал от провайдера и настроить IGMP Proxy - к провайдеру данный канал не имеет права на жизнь при использовании под IPTV, а при схеме 2 не хило выкинуть за UII 8000-9000руб. Ultra II - MT7621AT 2x @880MHz (with HW_NAT) RAM: 256MB (DDR3) Switch: Realtek RTL8370M 8x GbE (10/100/1000) и это с его-то RGMII и двумя GMAC (правда я потерялся в сег.конфигурации портов WAN и LAN на RGMII). Много было информации про MT7621 и обсуждения в которых принимали участия Padavan и McMCC, если я не путаю то сейчас в UII возможна схема MT7621 [GE1] -> встроенный -> WAN MT7621 [GE2] -> RTL8370M -> LAN Тут наверное нужно попробовать, где кабель с IPTV подключить на WAN (стандартный) порт, а провайдера с его интернетом на новый WAN2 (LAN1) : -LAN2-LAN4 Ноme для приставок -LAN остальные порты лок.сеть Home2