Werld

Dropbox не поддерживает доступ по webdav

root есть только в opkg. Без opkg в прошивочном cli этот пользователь никогда не был доступен. Только admin и любой другой пользователь, которого вы создадите и дадите нужные права

Hello. 802.11 standard defines 20MHz channels, and as long as you wish to remain standard, it will be 20/40MHz and AP has to allow devices to use only single channel. Same for 802.11ac with 20/40/80

Полностью согласен

Взять у контроллера и положить экстендеру и есть "синхронизация". Она не делится на типы, нет такого, что синхронизация при захвате, одно, а при смене настроек на контроллере - другое. Она происходит в заданном объеме при любом чихе же. А если начать разделять эти вещи, при захвате - синхронизация одна, полная, с доп параметрами, а при перезагрузке устройства уже другая синхронизация без этих параметров, то как раз и вылезают вопросы о реализации. Поэтому я и позволил себе заметить, что "Тут тоже есть о чем подумать" и "не уверен, что организация такой логики проста в реализации..."

В текущей реализации экстендеры переинициализируют настройки с контроллера при любом чихе. Иначе смена пароля или ssid на контроллера не приводила бы к смене этих параметров на экстендерах. Поэтому нет никакой первоначальной настройки при захвате, настройки переезжают постоянно, даже просто после перезагрузки любого устройства.

С другой стороны, а как экстендер будет понимать брать настройки с контроллера или оставлять свои? Тут тоже есть о чем подумать. Одно дело, тупо перенимать настройки с контроллера в 100% случаев, а другое прикрутить какую-то систему приоритетов, когда какие настройки важнее. Типа если настройки сделаны вручную - оставлять, если нет - перенимать с контроллера, но не уверен, что организация такой логики проста в реализации...

Тогда да, не так понял. Если при такой реализации возможность изменять эти доп настройки на экстендерах все равно оставят, то ничего не имею против)

Тогда и канал будет тоже копироваться с контроллера, а это не нужно. К примеру, у вас частный дом, свободный эфир, три кинетика, соединены кабелем, вы на них в 2.4 выставили 1, 6 и 11 канал - красота. Или, к примеру, есть старый девайс, который умеет только 802.11g и всегда стоит на втором этаже. Вы на нужном экстендере выставили g,n а на остальных оставили n-only - опять красота. То есть, ради мизерного удобства, избавляющего при конфигурировании wifi-системы от минутной доп настройки на экстендерах , мы теряем львиную долю гибкости возможных настроек.

interface pppoe0 lcp echo 30 3 adaptive

Есть статья как раз на эту тему.

Можно сделать через cli. show interface и в списке интерфейсов выбираете какой-нибудь из WifiMaster/AccessPoint. К примеру WifiMaster0/AccessPoint2 - это на 2.4Ггц. Далее добавляете выбранный wifi-интерфейс в свой сегмент. Т.е. если вам нужно добавить в основной Home сегмент, то это будет Bridge0. interface Bridge0 - для доступа к настройке этого интерфейса. Далее include WifiMaster0/AccessPoint2 - для включения точки доступа в сегмент. Подробнее в cli manual для вашего устройства. Для KN-1910

Huawei HG8245 - это оптический GPON терминал. Если он работает в режиме роутера, то необходимо перевести его в режим бриджа, чтобы функции роутера выполнял кинетик, тогда никаких пробросов делать не понадобится.

Не согласен с Вами. Я это понимаю так: пакет сначала попадет на сетевой интерфейс, входящий в интерфейс home(bridge0), затем принимается решение о маршрутизации. Т.к. пакет транзитный, он попадает в цепочку FORWARD, а не в INPUT. Цепочку FORWARD проходят ВСЕ пакеты, идущие транзитом через роутер. Если вы сделаете из cli "show netfilter", то вы увидите , что правила, добавленные через веб-интерфейс, попадают в цепочку "_NDM_ACL_IN" прыжок на которую есть не только в цепочке INPUT, но и в цепочке FORWARD, что вам и нужно. Так что, транзитный пакет будет обработан и при добавлении правил через веб-морду для интерфейса Home(Bridge0). Должен заметить, что правила добавленные для интерфейса L2TP0 на out, по идее точно так же должны отработать на проходящем трафике (если вы все верно указали и действительно не ошиблись с 0.0.0.0/32). Если они не отрабатывают, тогда и вправду похоже на баг.

Запись 0.0.0.0/32 - это не верно, она не может быть адресом назначения. Да и вообще, если я правильно понял, чего Вы хотите добиться, то для начала Вам нужно прописать маршруты в нужную сеть через нужный интерфейс. А далее для интерфейса Home уже добавить правила разрешающие доступ определенным адресам к корпоративной сети, и одно правило, запрещающее доступ всем остальным. По аналогии с примером настройки, разрешающей доступ в Интернет только одному определенному компьютеру локальной сети, а для всех остальных блокирующей. Только адрес назначения у вас будет не "любой", как в примере, а конкретный адрес вашей корпоративной сети. Эти правила можно добавить через веб-интерфейс, т.к. это будет по сути access-list на in для интерфейса Home.

В порядке бреда, TX Burst попробуйте выключить. Во всплывающей подсказке к этой функции написано "...если оборудование провайдера не совместимо с этим режимом, скорость интернета для WIFI устройств может снизиться". Может это как раз тот случай и работа именно через бридж порт приводит к этому.

Почему на А? На кинетике В, для интерфейса ISP добавьте правила разрешающие. Сеть назначения 192.168.2.0/24 для icmp, tcp, udp, в общем всего что вам нужно.

Какой протокол VPN используется от роутера до офиса? Если что-то типа pptp, l2tp/ipsec, openvpn, то проверьте чтобы на соответствующем сетевом интерфейсе в Giga стоял признак ip global. Есть интересная особенность у Кинетик, заключается в том, что для впн-клиентов роутера, маршруты, прописанные в интерфейсы не отмеченные признаком global не отрабатывают. Если у вас именно такая ситуация, то выставление признака global на впн интерфейс к офису - поможет. Только приоритет заданный этим параметром не должен быть выше чем у основного соединения ведущего в интернет, чтобы через туннель не гнался весь трафик.

К слову, для работы с iptables нужно установить пакеты opkg, т.е вам в любом случае нужен с usb портом

У kn-3010 нет usb порта. kn-1910 (viva) 2 x usb2.0, у kn-1010 (giga) 1 х usb2.0, 1 x usb3.0.

Keenetic, насколько я знаю, пока не умеет ikev2. Какой версии у вас strongswan на сервере? Некоторые параметры в вашем ipsec.conf не имеют эффекта в новых версиях strongswan, подробнее см здесь. К примеру в параметре esp=aes128-sha1-modp1024 Выделенное - это вы указали группу Диффи-Хелмана, что, в соответствии с wiki.strongswan.org (PFS is enforced by defining a Diffie-Hellman dhgroup in the esp parameter), принуждает использовать pfs, в то же время у вас написано pfs=no. Может и не в этом дело. У меня к серверу с убунтой 16.04 кинетик подключается по l2tp/ipsec. Версия strongswan у меня там 5.3.5 Мой ipsec.conf: config setup # strictcrlpolicy=yes # uniqueids = no # Add connections here. conn L2TP fragmentation=yes dpdaction=clear dpddelay=60s dpdtimeout=180s keyexchange=ikev1 keyingtries=3 ikelifetime=8h lifetime=1h ike=aes128-sha1-modp1536,aes128-sha1-ecp384,aes128-sha1-modp1024,aes256-sha1-modp1536,aes256-sha1-ecp384,aes256-sha1-modp1024,aes12$ esp=aes128-sha1,aes256-sha1,aes128-sha256,aes256-sha256 left=здесь был ip сервера leftsubnet=%dynamic[/1701] right=%any rightsubnet=%dynamic leftauth=psk rightauth=psk type=transport auto=add

Если кому-то будет полезно, то установка признака ip global на нужный интерфейс помогла, маршруты к сетям за этим интерфейсом стали отрабатывать нормально для впн-клиентов. НО еще раз хочу акцентировать внимание, до версии ОС 3.х.х маршруты прекрасно отрабатывали для впн клиентов l2tp/ipsec-сервера. До этого в версиях со старым интерфейсом все отрабатывало и для клиентов pptp-сервера. Считаю, что это баг и его нужно исправлять.

Под старыми я имел в виду 2.15 на которой работало хотя бы для клиентов l2tp/ipsec впн-сервера. На версии 3.1.6 не работает ни для кого. Я не ищу промежуточных решений, я могу потерпеть, лишь бы взялись за исправление.

А установка этого признака не приведет к тому, что маршрутом по умолчанию станет маршрут через это дополнительное соединение и вес трафик пойдет туда? Кроме того, ведь работало же все на предыдущих версиях ос, может все-таки обратят внимание и исправят.

По словам техподдержки, суть проблемы, если коротко, в том, что для клиентов впн сервера роутера маршрут, который должен идти через дополнительное (резервное соединение) отрабатывает только в том случае, если на этом соединении есть признак ip global, то есть соединение используется для выхода в интернет. В противном случае соединение отсутствует в основном профиле доступа и маршрут не отрабатывает.