Le ecureuil

В таблице маршрутизации по-умолчанию (а именно такую выводит netstat) все идентично. Попробуйте заставить openvpn прописывать маршуты самостоятельно (через команды route и push "route", как в примере): https://wiki.archlinux.org/index.php/OpenVPN_(Русский)#.D0.A1.D0.B2.D1.8F.D0.B7.D1.8C_.D0.BA.D0.BB.D0.B8.D0.B5.D0.BD.D1.82.D0.B0_.D0.B8_.D1.81.D0.B5.D1.80.D0.B2.D0.B5.D1.80.D0.B0_.D1.81_.D0.B8.D1.85_.D0.BB.D0.BE.D0.BA.D0.B0.D0.BB.D1.8C.D0.BD.D1.8B.D0.BC.D0.B8_.D1.81.D0.B5.D1.82.D1.8F.D0.BC.D0.B8

Да, у вас фактически 100% загрузка системы, причем довольно размазанная: и приложения в userspace жрут много, и обработка прерываний, и ввод-вывод на диск (тоже очень много). Так что резервов для повышения скорости загрузки файлов нет.

Если все именно так, как вы описываете, то ответ прост и очевиден: нет. Это устройство нарушает стандарт, и никто не проектирует коммутаторы на работу с ним.

На этой картинке внутри коробочки может быть все что угодно, включая микрокомпьютер. Может предоставите немного технических деталей?

Функционала с EoIP вообще еще нет в web, поэтому там пока настроить ничего нельзя. А вообще схема примерно такая. 1. Создаем и настраиваем EoIP-интерфейс: interface EoIP0 ... ... ... 2. Создаем на нем VLAN-интерфейс и настраиваем: interface EoIP0/Vlan256 ... ... ... 3. Выделяем порт (например, номер 3) из свитча в отдельный VLAN с access-доступом (в растегированном виде): interface GigabitEthernet0/3 no switchport access switchport access vlan256 ... ... ... 4. Создаем VLAN-интерфейс на свитче: interface GigabitEthernet0/Vlan256 ... ... ... 5. Создаем объядиняющий их Bridge: interface Bridge256 inherit GigabitEthernet0/Vlan256 include EoIP0/Vlan256 ... ... ...

Да ладно, бярошь любой коммутатор с poe-питанием и profit! А вообще если и дальше будет нечто технически невнятное обсуждаться, то перенесем в Курилку.

Версия прошивки какая? Какое устройство? Мы что, телепаты?

В 2.08 заменили на другую, стороннюю разработку.

80-85% означает, что процессор полностью занят, причем оба виртуальных ядра. Неплохо бы еще разбивку по времени из top увидеть, чтобы понять, какая часть системы сильнее всего загружена. Вот такую строку:

Естественно линка с коммутатором. Потому что хост может в произвольный момент времени исчезнуть из Интернета (а мы на него никак повлиять не можем) - и приплыли.

Для iOS нет, и не будет согласно политике Apple. Даже из My.Keenetic пришлось удалить эту функциональность после угроз удалить приложение из AppStore.

Все, для которых выпущена 2.08, уже поддерживают. Насчет официальности выпуска 2.08 - смотрите объявления.

Не нужно вводить всех в заблуждение, теперь у вас показывает не наличие Интернета, а всего лишь доступность хоста, указанного в pingchecker. Выше уже сказано, как обманывается Windows, и pingcheck с легкостью может быть обманут провайдером, если он весь трафик будет заворачивать на свой сервер, который будет отвечать на ping Проблема "доступности Интернета" настолько сложна, что надежнее чем показывать наличие default route плюс линка/соединения на WAN придумать мало что можно.

Нет, перезаписывается весь netfilter целиком по каждой нужде. Пока это невозможно "быстро" исправить.

А теперь внимательно прочтите этот пост: И вы увидете, что да, в IF-MIB::ifDescr.N = STRING: FastEthernet0/Vlan2 ставится системное неизменяемое Ralink-специфичное наименование интерфейса, однако в IF-MIB::ifName.N = STRING: ISP и IF-MIB::ifAlias.N = STRING: ISP вы можете увидеть кастомное наименование интерфейса, заданное командой rename, которое как раз и отображается в Web (Для Home аналогично, IF-MIB::IfDescr выставляется в Bridge0, а IF-MIB::ifName и IF-MIB::ifAlias выставляются в Home). Просто используйте другие значения из IF-MIB для получения имен интерфейсов, и все. Причем через rename вы их сами можете задать какими угодно.

Нет, пока прошивка сделана именно так, и переделывать ее не запланировано.

Не совсем, IPsec ставил/снимал марки на своих пакетах, потому fwmarks конфликтовал с ним.

Да, все так.

Итак, начиная с версии прошивки 2.08.A.11.0-3 мы полностью исключили использование skb->mark в ndm, поэтому вы можете его спокойно использовать (iptables match mark и target MARK). Для полной совместимости с ядром и системой NDMS необходимо использовать следующие патчи для iptables: 920-xt_ndmmark.patch, 930-xt_conndmmark.patch, 940-xt_connskip.patch, 950-xt_PPE.patch, 960-xt_tls.patch (в этом случае iptables-save и iptables-restore не будут ругаться). У вас будут показываться ndmmark/conndmmark/connskip/tls match и NDMMARK/CONNDMMARK/PPE target, но трогать их не стоит - они активно используются системой. Однако, следует понимать, что в ядре NDMS присутствуют различные ускорители, которые так или иначе меняют логику работы netfilter. Поэтому если у вас что-то не работает в netfilter, tc, policy routing и подобных вещах, то сперва проверьте, сделали ли вы нижеследующее: - отключить FastNAT: > system set net.ipv4.netfilter.ip_conntrack_fastnat 0 (NDMS 2.x) > system set net.netfilter.nf_conntrack_fastnat 0 (NDMS 3.x) (обратно включить можно через > system set net.ipv4.netfilter.ip_conntrack_fastnat 1 (NDMS 2.x) > system set net.netfilter.nf_conntrack_fastnat 1 (NDMS 3.x) - отключить ppe software: > no ppe software - отключить ppe hardware: > no ppe hardware И проверить результат работы. Если поведение ядра вас устраивает, можете сохранить настройки: > system configuration save Начиная с 2.11 стоит учитывать, что таблица raw монопольно захватывается компонентом netflow и не загружается автоматически. Если она вам нужна - удалите компонент netflow, и загружайте руками iptable_raw.ko. Важно: скрипты в netfilter.d могут вызываться очень часто и с произвольным интервалом, потому обязательно проверьте свои скрипты на работу в таких условиях + на то, что вы проверяете и версию протокола (IPv4 или IPv6), как указано здесь: https://github.com/ndmsystems/packages/wiki/Opkg-Component#ndmnetfilterd Важный момент: скорость без всех ускорителей будет так себе, но вы должны понимать на что идете: или полноценная функциональность, или скорость. Если после всего описанного все равно остаются вопросы, лучше их задать в этой теме. Новая важная информация будет заноситься в шапку.

2.08 еще не вышла, потому мануал по cli еще не написан до конца. А в web подобное врядли кто будет дописывать.

У нас и web, и система, и cli изначально не рассчитаны на то, что будут видны реальные системные linux-интерфейсы Плюс ко всему, там не прямое отображение 1:1, например у WifiMaster0 нет аналога в системе. Потому так все и сделано. Основной вопрос - зачем нужно выводить реальные системные названия интерфейсов, кроме как "хочется"?

Хорошо, проверим.

Уже неоднократно обсуждалась эта тема: Окончательное решение вот такое:

По идее переподключится через 90 секунд.

В текущей реализации резервирования никак, это особенность реализации. Полноценный multiwan обсуждается здесь: