Albram
-
Posts
390 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by Albram
-
-
5 часов назад, TheBB сказал:
Не знаю, из 10 скачавших, все скромно молчат (или всё работает, или не работает).
Аналогичная проблема на Keenetic Ultra 2.16.D.1.0-0. Видимо чего-то не хватает. А жаль, вещь интересная и нужная.
Скрытый текст~ # wireguard wg0 WARNING WARNING WARNING WARNING WARNING WARNING WARNING W G W You are running this software on a Linux kernel, G W which is probably unnecessary and misguided. This G W is because the Linux kernel has built-in first G W class support for WireGuard, and this support is G W much more refined than this slower userspace G W implementation. For more information on G W installing the kernel module, please visit: G W https://www.wireguard.com/install G W G WARNING WARNING WARNING WARNING WARNING WARNING WARNING INFO: (wg0) 2020/02/11 14:41:49 Starting wireguard-go version 0.0.20191012 ~ # ls -l /opt/var/run/wireguard/ srwx------ 1 root root 0 Feb 11 18:41 wg0.sock ~ # wg setconf wg0 /opt/etc/wg0.conf Unable to modify interface: Protocol not supported ~ # wg addconf wg0 /opt/etc/wg0.conf Unable to modify interface: Protocol not supported ~ # wg set wg0 listen-port 1111 Unable to modify interface: Protocol not supported -
15 часов назад, Albram сказал:
Обходным решением тогда оказалось, как ни странно, указание в настройках dnscrypt-proxy2 слушать на любом порту, вместо 127.0.0.1:53 и 192.168.1.1:53, как было у меня раньше.
Ошибся при написании. Конечно же, не на любом порту слушать, а на любом адресе, т.е.:
listen_addresses = ['0.0.0.0:53']
-
Сегодня нашел причину "дыры" описанной мной в этой теме ранее
Напомню: DNS сервер откликался на запросы снаружи на udp/53 на внешний адрес кинетика. Firewall включен, nmap не показывал этот порт открытым. Обходным решением тогда оказалось, как ни странно, указание в настройках dnscrypt-proxy2 слушать на любом порту, вместо 127.0.0.1:53 и 192.168.1.1:53, как было у меня раньше. При этом, при внешних запросах, ответов от dns сервера не было (на внешнем клиенте был таймаут ответа от сервера), но в активных подключениях кинетика всё равно появлялось это соединение.
Менялись версии прошивки, от 2.13 в момент обнаружения проблемы, до 2.16 сейчас, обновлялся Entware, но проблема оставалась.
В итоге, в моем случае причиной оказалось срабатывание правила:
Chain PREROUTING (policy ACCEPT 72 packets, 6120 bytes) num pkts bytes target prot opt in out source destination 3 15 981 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 to:192.168.1.1:53Которое создавалось скриптом /opt/etc/ndm/netfilter.d/10-ClientDNS-Redirect.sh, который описан в шапке этой темы в разделе "Перехват всех DNS запросов на роутере. "Приземление" DNS трафика".
Доработал его, указав исключение внешнего интерфейса:
Было:
[ -z "$(iptables -nvL -t nat | grep "to:192.168.1.1:53")" ] && iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:53
Стало:
[ -z "$(iptables -nvL -t nat | grep "to:192.168.1.1:53")" ] && iptables -t nat -I PREROUTING -p udp ! -i ppp0 --dport 53 -j DNAT --to-destination 192.168.1.1:53
После этого, при внешних запросах на udp/53, dns сервер не отвечал и соединение в активных подключениях не появлялось.
Возможно, такое решение имеет недостатки (например, в случае, когда запросы прилетят со стороны провайдера по IPoE, минуя PPPoE), и кто-то предложит более "элегантное" решение.
-
1
-
1
-
-
33 минуты назад, TheBB сказал:
нет, пакет был криво собран (патчи не применились)
После апгрейда всё стало правильно, Спасибо!
Скрытый текстChain _NDM_MASQ (1 references) num pkts bytes target prot opt in out source destination 1 719 87318 _NDM_MASQ_BYPASS all -- * * 0.0.0.0/0 0.0.0.0/0 2 3 228 _NDM_NAT_UDP udp -- * * 192.168.1.0/24 0.0.0.0/0 udp ndmmark match 0x4/0x4 3 112 6508 MASQUERADE all -- * * 192.168.1.0/24 0.0.0.0/0 ndmmark match 0x4/0x4 Chain _NDM_BACKUP_FORWARD (1 references) num pkts bytes target prot opt in out source destination 1 0 0 CONNNDMMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNNDMMARK match 0x80/0x80 CONNNDMMARK restore mask 0x80 2 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 CONNNDMMARK match 0x80/0x80-
1
-
-
4 минуты назад, TheBB сказал:
Шо, опять? Вот же он http://bin.entware.net/mipselsf-k3.4/keenetic/iptables_1.4.21-3a_mipsel-3.4_kn.ipk
Апгрейд пакетов не делали? У него приоритет выше, и он должен автоматом ставиться.
Upgrade делал месяца два назад. Сейчас глянул, действительно доступен новый пакет iptables. Буду апгрейдить. Спасибо.
Извиняюсь за беспокойство, сам оказался виноват 😐
~ # opkg update
~ # opkg list-upgradable...
iptables - 1.4.21-3 - 1.4.21-3a
... -
8 часов назад, Albram сказал:
Этот пропатченый пакет подойдёт для старой ультры с прошивкой 2.16? Текущая версия iptables такая же - 1.4.21
Отвечу сам себе: не подойдет, т.к. версии всё-таки разные и платформы отличаются.
Указанный выше: iptables_1.4.21-2_mipsel-3x.ipk, а сейчас установлен: iptables_1.4.21-3_mipsel-3.4_kn.ipk
Скрытый текстPackage: iptables Version: 1.4.21-3 Depends: libc, libssp, librt, libpthread Status: install user installed Section: net Architecture: mipsel-3.4_kn Size: 170087 Filename: iptables_1.4.21-3_mipsel-3.4_kn.ipk Description: IP firewall administration tool. Matches: - icmp - tcp - udp - comment - conntrack - limit - mac - mark - multiport - set - state - time Targets: - ACCEPT - CT - DNAT - DROP - REJECT - LOG - MARK - MASQUERADE - REDIRECT - SET - SNAT - TCPMSS Tables: - filter - mangle - nat - raw Installed-Time: 1576431284 -
8 часов назад, Le ecureuil сказал:
2. Да, видимо у вас нет патча на iptables, но это некритично.
Спасибо за ответы.
Этот пропатченый пакет подойдёт для старой ультры с прошивкой 2.16? Текущая версия iptables такая же - 1.4.21. И не будет ли проблем при использовании маркировки в Entware после установки патча?
-
Исходные данные: Keenetic Ultra (старый чёрный) с прошивкой 2.16.D.1.0-0 и Entware BusyBox v1.31.0.
1. Недавно в "Сетевые правила -> Переадресация" появился открытый через UPnP порт. Мне понятно, что источником его открытия был недавно начавший использоваться AnyDesk, но непонятно почему он открыт именно на этот интерфейс от VMware, хотя AnyDesk используется не из виртуальных машин, а локально на компе с адресом из локальной подсети 192.168.1.0/24. Правило это не удаляется после прекращения использования AnyDesk. Адрес 192.168.127.1 пингуется, т.к. этот сетевой интерфейс поднят.
Собственно вопрос: оно не должно удаляться само, и нужно ли оно вообще?
Скрытый текст
Адаптер Ethernet VMware Network Adapter VMnet8: DNS-суффикс подключения . . . . . : Описание. . . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet8 Физический адрес. . . . . . . . . : 00-xx-xx-xx-00-08 DHCP включен. . . . . . . . . . . : Нет Автонастройка включена. . . . . . : Да Локальный IPv6-адрес канала . . . : fe80::5c62:6d16:894d:b3cc%12(Основной) IPv4-адрес. . . . . . . . . . . . : 192.168.127.1(Основной) Маска подсети . . . . . . . . . . : 255.255.255.0 Основной шлюз. . . . . . . . . : IAID DHCPv6 . . . . . . . . . . . : 503337046 DUID клиента DHCPv6 . . . . . . . : 00-01-00-01-xx-xx-xx-4E-00-xx-xx-xx-xx-xx DNS-серверы. . . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 NetBios через TCP/IP. . . . . . . . : Включен2. В правилах iptables увидел вот это, это нормально?
Скрытый текстВ таблице nat: Chain _NDM_MASQ (1 references) num pkts bytes target prot opt in out source destination 1 78 7953 _NDM_MASQ_BYPASS all -- * * 0.0.0.0/0 0.0.0.0/0 2 0 0 _NDM_NAT_UDP udp -- * * 192.168.1.0/24 0.0.0.0/0 udpUNKNOWN match `ndmmark' 3 2 116 MASQUERADE all -- * * 192.168.1.0/24 0.0.0.0/0 UNKNOWN match `ndmmark' В таблице mangle: Chain _NDM_BACKUP_FORWARD (1 references) num pkts bytes target prot opt in out source destination 1 0 0 CONNNDMMARK all -- * * 0.0.0.0/0 0.0.0.0/0 UNKNOWN match `connndmmark' [8 bytes of unknown target data] 2 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 UNKNOWN match `connndmmark' -
Имеется старый (чёрный) Keenetic Ultra с прошивкой 2.16.D.1.0-0.
В настройках в Web GUI имеются обе облачные службы, и Keenetic Cloud, и Keenetic Cloud 2 (с пометкой beta).
Обе службы включены, оба приложения установлены и работают.
Скрытый текст
Несмотря на предупреждение при запуске приложения Keenetic, о том, что необходим интернет-центр с версией прошивки 3.x, оно работает и на 2.16.
В соединениях постоянно есть два входящих UDP соединения на WAN интерфейс по портам 4044 (это, как я понимаю, старая облачная служба) и 5683 (новая).
Т.к. такое дублированное управление мне не особо нужно, возник вопрос, какое из служб и приложений оставить?
Выбор было бы проще сделать, знай я ответы на вопросы:
1. Старая облачная служба и приложение My.Keenetic долго ещё будут работать и поддерживаться?
2. Т.к. работоспособность нового приложения Keenetic не заявлена с версиями прошивок ниже 3.x, не получится ли так, что через какое-то время оно перестанет работать (и, как обычно такое бывает, в самый неподходящий момент)? Это больше риторический вопрос, т.к. понимаю, что никто никаких гарантий на этот счёт не даст, просто, может у разработчиков есть какие-то планы на этот счёт.
3. Какая из этих служб/приложений более защищена (более безопасна при использовании) ?
-
2 минуты назад, r13 сказал:
Ну так для старого ядра не существует ipv6 nat
Да, потому мне пришлось отказаться от использования ipv6, из-за описанной выше проблемы.
Когда читал этот топик, мелькнула мысль: "а вдруг?". Но нет.
-
Я так понимаю, что это актуально только для прошивок 3.x на ядре ndm 4.x, т.к. на 2.16.D.1.0-0 с ядром 3.4.113 указанных модулей нет в /lib/modules/3.4.113/.
Из-за отсутствия nat в ipv6 в 2.16 приходится "извращаться" с перенаправлением пакетов через маркировку. Вместо одного правила получается несколько, и в перехватчике ndm часто бывает так, что какое-то правило не добавляется, и вся цепочка становится на время неработоспособной при частой очистке правил прошивкой. Использование ключа -w в правилах ip6tables улучшает ситуацию, но не устраняет полностью. С правилами iptables такой проблемы нет, только с ip6tables.
-
3 часа назад, AndreBA сказал:
У меня эта команда отрабатывала. Я ей пользовался до того как в веб-интерфейсе внедрили "игнорирования dns".
Даже в статье: https://help.keenetic.com/hc/ru/articles/213966649-Использование-публичных-DNS-серверов такая команда.
Может, что подкорректировали...
Всё правильно, должна эта команда отрабатывать. Во всяком случае описание команды interface совпадает что для старых версий 2.0x, что для новых:
Скрытый текст
Хотя реакция на команду у ТС как будто указано имя несуществующего интерфейса.
-
В 11.12.2019 в 09:23, Glazami сказал:
прописал, команды приняты но не помогло.
(config)> interface PPPoE0 Network::Interface::Repository: "PPPoE0" interface created.Не должно быть такого ответа ""PPPoE0" interface created." это у вас новое соединение создалось, потому и ввод последующих команд не привёл к нужному результату.
Для начала удалите это соединение:
В 13.12.2019 в 03:37, Glazami сказал:вообще появилось дополнительное соединение кстати.
Кликнув по нему всплывает окно со следующим содержимым
Затем посмотрите как у вас называются интерфейсы:
show interfaceВ списке ищите интерфейс с типом PPPoE и смотрите как он называется.
Затем вводите команды (я здесь указал интерфейс PPPoE0, вам нужно использовать ваше имя интерфейса):
interface PPPoE0 ipcp no name-servers system configuration saveПосле этого посмотрите в файле конфигурации секцию вашего PPPoE интерфейса, она должна содержать эти две строки:
interface PPPoE0 ipcp no name-servers ip dhcp client no name-serversЕсли строка "ip dhcp client no name-servers" отсутствует или имеет другое значение, то введите, заменив имя интерфейса на ваше значение:
interface PPPoE0 no ip dhcp client name-servers system configuration saveЭто избавит от получения адресов DNS серверов по DHCP.
-
В 09.06.2019 в 11:51, naileddeath сказал:
В файле скрипта /opt/usr/bin/smarthtml.sh
#MTA_HELPER="exec ${OPENSSLCMD} s_client -quiet -tls1 -starttls smtp -connect ${MAIL_SMTP}"
если данную строку не закомментировать будет ошибка 535-5.7.8Да, действительно, эту строку нужно закомментировать, что-то я её пропустил когда описывал процесс.
Спасибо что заметили.
-
В 16.05.2019 в 01:25, Михаил Лукьянов сказал:
Стоковый DNS сервер никогда наружу не смотрит, поэтому 99% вероятности что это неправильно настроен dnscrypt-proxy. Покажите
grep listen_address /opt/etc/dnscrypt-proxy.toml
Как должно быть (пример):
listen_addresses = ['127.0.0.1:53','192.168.1.1:53','[fe80::127b:efff:fe5d:ffcc%br0]:53']
Как не должно быть:
listen_addresses = ['0.0.0.0:53']
В моем случае всё с точностью до наоборот. При listen_address = ['0.0.0.0:53'] и попытке nslookup <host> <IP_keenetik> извне получаем таймаут ответов dns сервера кинетика. Такое же наблюдается и при указании в качестве слушающего ipv6 адреса кинетика. В остальных других любых комбинациях listen_address получаем ответ dns сервера на внешний адрес кинетика.
В 16.05.2019 в 16:17, Александр Рыжов сказал:Вероятно, @Albram что-то навертел самостоятельно. Здоровый кинетик с своему DNS-проксику доступа при включенном файерволе не предоставит.
Проверил на PPPoE и без и с опцией `opkg dns-override`.
Настроено у меня по инструкции из первого поста этой темы с единственным отличием в том, что использую ещё и ipv6. До этого писал, что остановил dnscrypt-proxy и отключил opkg dns-override и доступ извне к DNS серверу пропал, но оказалось что при этом перестает работать резолв и из локальной сети.
Было подозрение на правило в интернет-фильтре 192.168.1.1 для всех dns запросов, которое, начиная с версий 2.15, стало ругаться в лог на петлю:
Скрытый текстМай 18 22:51:05 ndnproxy Proxy loop detected: 192.168.1.1 <-> 192.168.1.1, request dropped. Май 18 22:51:05 ndnproxy DNS server 192.168.1.1 inactivated. ... Май 18 22:51:06 ndnproxy Proxy loop detected: fe80::xxxx:xxxx:xxxx:xxxx <-> fe80::xxxx:xxxx:xxxx:xxxx, request dropped. Май 18 22:51:06 ndnproxy DNS server fe80::xxxx:xxxx:xxxx:xxxx inactivated.Но его удаление (без перезагрузки роутера) не давало результатов.
При сканировании извне портов кинетика nmap-ом по tcp показывает только один открытый порт 21, на который на самом деле есть правило в firewall, но оно отключено. По udp пишет что все 1000 портов open | filtered, результаты не меняются при любых значениях listen_address.
Оставил listen_address = ['0.0.0.0:53'] и коннекты извне пропали.
По мере возможности буду продолжать искать источник проблемы.
-
В 03.06.2019 в 08:43, dippnsk сказал:
Вчера столкнулся с неочевидной проблемой, предостерегаю всех. Если у вас сделан полный dns-override, в котором выключенный dnsmasq отключает весь dns в роутере в принципе, то апдейт+апгрейд opkg может сделать харакири сам себе.
В моём случае opkg остался в совершенно нерабочем состоянии и я никак не смог восстановить его, пришлось полностью переустанавливать.
Не ошибкой wget закончилось?
Вот здесь есть предостережение: https://forum.keenetic.net/topic/5639-wget-gnu-wget-downloading-files-on-the-protocols-http-https-ftp-and-ftps/?do=findComment&comment=64939
-
1
-
-
9 минут назад, Александр Рыжов сказал:
Вероятно, @Albram что-то навертел самостоятельно. Здоровый кинетик с своему DNS-проксику доступа при включенном файерволе не предоставит.
Проверил на PPPoE и без и с опцией `opkg dns-override`.
Видимо да. Сейчас остановил dnscrypt-proxy и отключил opkg dns-override, Доступ извне к DNS серверу пропал.
Скрытый текст~ # netstat -apn | grep ':53 ' tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 7027/ndnproxy tcp 0 0 :::53 :::* LISTEN 7027/ndnproxy udp 0 0 0.0.0.0:53 0.0.0.0:* 7027/ndnproxy udp 0 0 :::53 :::* 7027/ndnproxy -
3 минуты назад, Александр Рыжов сказал:
Это нечто другое. У вас файервол отключен? Если нет, то по поводу того, что службы слушают 0.0.0.0 я бы не переживал.
Файерволл включен и на ipv4 и на ipv6.
-
1 час назад, Михаил Лукьянов сказал:
Насколько я помню ndm в качестве ресолвера использует lo интерфейс независимо от того что указано в веб интерфейсе. Не получив ответа с 127.0.0.1:53 система аварийно запускает родной DNS сервер причем без текущего конфига с прослушиванием по всем интерфейсам. О - отказоустойчивость🙂
Нужно вернуть '127.0.0.1:53' в /opt/etc/dnscrypt-proxy.toml где росло. Какой смысл его было убирать?
Вернул, не помогло.
Скрытый текст~ # grep listen_address /opt/etc/dnscrypt/dnscrypt-proxy.toml listen_addresses = ['127.0.0.1:53', '192.168.1.1:53', '[fe80::xxxx:xxxx:xxxx:49d8%br0]:53'] ~ # ~ # netstat -apn | grep ':53 ' tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN 24486/dnscrypt-prox tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 24486/dnscrypt-prox tcp 0 0 fe80::xxxx:xxxx:xxxx:49d8:53 :::* LISTEN 24486/dnscrypt-prox udp 0 0 192.168.1.1:53 0.0.0.0:* 24486/dnscrypt-prox udp 0 0 127.0.0.1:53 0.0.0.0:* 24486/dnscrypt-prox udp 0 0 fe80::xxxx:xxxx:xxxx:49d8:53 :::* 24486/dnscrypt-proxУбрал этот адрес ещё в самом начале настроек, что-то было связано с тем, что когда он был в конфиге один, не резолвились хосты с роутера, потом добавил к нему 192.168..... всё стало нормально, попробовал его убрал, ничего не изменилось, так и оставил из-за тяги к минимализму)
1 час назад, Александр Рыжов сказал:ndm в качестве резолвера продолжает использовать собственную службу ndnproxy дальше, общаясь с ней по RPC.
При `opkg dns-override` встроенная служба ndnproxy лишь перестаёт слушать порты TCP53/UDP53.
Т.е. чтобы запретить ndnproxy слушать на внешнем интерфейсе нужно изменить здесь?
udp 0 0 0.0.0.0:54321 0.0.0.0:* 524/ndnproxy udp 0 0 :::50272 :::* 524/ndnproxy -
52 минуты назад, Михаил Лукьянов сказал:
Вывод не информативен, нужно посмотреть так:
netstat -apn | grep ":53 "
Стоковый DNS сервер никогда наружу не смотрит, поэтому 99% вероятности что это неправильно настроен dnscrypt-proxy.
Dnscrypt слушает на двух локальных адресах:
~ # grep listen_address /opt/etc/dnscrypt/dnscrypt-proxy.toml
listen_addresses = ['192.168.1.1:53', '[fe80::xxxx:xxxx:xxxx:49d8%br0]:53']
~ #Вывод netstat -apn | grep “:53” во время коннекта позже пришлю, сейчас нет возможности.
-
На днях случайно заметил на роутере коннекты извне (в основном из Китая) на 53 порт. IP у меня внешний, потому решил проверить, и действительно 53 порт оказался открыт всем желающим. Создал в Web-интерфейсе (версия 2.15.C.3.0-2) правило на PPPoE интерфейсе "запретить UDP с любого IP и порта на "мой IP" порт 53" и поместил его в начало цепочки. Правило создалось в таблице filter в цепочке @PPPoE0. Но оно не работает. Т.е. и с этим правилом коннекты на 53-ий порт извне проходят. Видимо срабатывает какое-то правило раньше этого.
Выглядит это так:
на компе, подключенном через другого провайдера, делаю nslookup ya.ru <мой IP> и на роутере в разделе Диагностика появляется коннект:
Скрытый текстИсточник Адрес назначения Служба 83.xxx.xxx.xxx :46168 Keenetic_Ultra (Broadband connection (PPPoE)) xxx.xxx.xxx.xxx UDP/53 :24072 Keenetic_Ultra (Broadband connection (PPPoE)) xxx.xxx.xxx.xxx UDP/53 :58071 Keenetic_Ultra (Broadband connection (PPPoE)) xxx.xxx.xxx.xxx UDP/53В Entware во время коннекта:
Скрытый текст~ # netstat -unp Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp 0 0 127.0.0.1:57982 127.0.0.1:54321 ESTABLISHED 161/ndm ~ # netstat -ulnp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp 0 0 127.0.0.1:1026 0.0.0.0:* 447/nqnd udp 0 0 127.0.0.1:1027 0.0.0.0:* 447/nqnd udp 0 0 127.0.0.1:41231 0.0.0.0:* 161/ndm udp 0 0 127.0.0.1:41232 0.0.0.0:* 161/ndm udp 0 0 127.0.0.1:41234 0.0.0.0:* 161/ndm udp 0 0 0.0.0.0:54321 0.0.0.0:* 524/ndnproxy ....В конфигурации отключено использование dns и dns6 серверов провайдера на всех публичных интерфейсах (PPPoE, IPoE) и прошивочный dns сервер переведен в режим opkg dns-override, но, судя по выводу из Entware, срабатывает именно он. DNS-crypt настраивался по методике из этой темы.
Вопрос: куда поместить правило, чтобы оно корректно работало?
-
Есть ли смысл обновляться на чёрной (первой) ультре с 2.15.C.3.0-0 до 2.15.C.3.0-2 ?
Из описания изменений увидел для себя смысл в обновлении только в последнем пункте. И то, вряд ли у актуальных и архивных моделей аппаратный ускоритель одинаковый.
Улучшения:
- Wi-Fi: улучшена работа роуминга;
- Wi-Fi: исправлена совместимость с клиентами, высылающими Null data фреймы между Auth и Assoc;
- Wi-Fi: драйвер обновлен до версии 5.0.3.2 (для Keenetic Giga, Ultra, Viva);
- VPN-сервер: исправлено подключение клиентов Mikrotik;
- Исправлена проблема пропуска PPPoE (PPPoE Passthrough) через аппаратный ускоритель.
UPD: Обновился, версия Fast VPN стала выше, похоже смысл всё-таки есть и вопрос потерял актуальность:
Было:
Скрытый текстCore::System::DriverManager: loading /lib/modules/3.4.113/hw_nat.ko.
kernel: Ralink HW NAT 5.0.2.0-tc-8 Module Enabled, FoE Size: 16384
Core::System::DriverManager: loading /lib/modules/3.4.113/fastvpn.ko.
kernel: fastvpn: sizeof(bind) = 200
kernel: fastvpn: sizeof(hashent) = 56
kernel: fastvpn: registered
kernel: fastvpn: enabled
kernel: fastvpn: Fast VPN init, v4.0-123Стало:
Скрытый текстCore::System::DriverManager: loading /lib/modules/3.4.113/hw_nat.ko.
kernel: Ralink HW NAT 5.0.2.0-tc-8 Module Enabled, FoE Size: 16384
kernel: fastvpn: sizeof(bind) = 200
kernel: fastvpn: sizeof(hashent) = 56
kernel: fastvpn: registered
kernel: fastvpn: enabled
kernel: fastvpn: Fast VPN init, v4.0-127
Core::System::DriverManager: loading /lib/modules/3.4.113/fastvpn.ko.-
1
-
В 19.04.2019 в 15:51, Михаил Лукьянов сказал:
В качестве альтернативы/дополнения предлагаю использовать блоклист на базе RuAdList + EasyList (я так понимаю делает один из членов их команды) http://cdn.raletag.gq/rueasyhosts.txt
Я в изначальном файле domains-blacklist.conf из шапки раскомментировал RU AdList и добавил ещё один источник:
Скрытый текст# RU AdList https://easylist-downloads.adblockplus.org/advblock.txt # Adblock # Adblock EasyList Lite https://cdn.adblockcdn.com/filters/easylist_lite.txtБлокирует неплохо, но частенько пропускает огромный верхний баннер на lenta.ru (использую его как один из проверочных для блокировщиков рекламы) и ещё несколько внутри страницы.
Надо будет попробовать добавить ваш источник, спасибо.
-
1
-
-
Обновил Entware
busybox - 1.30.1-1 entware-release - 1.0-2и скрипт перестал показывать SMART, параметры диска и свободное место. Заодно перестала работать ручная проверка на странице.
Со скриптом проблема оказалась в smartctl, новая версия 7.0 перестала автоматически определять тип диска
~ # smartctl -V smartctl 7.0 2018-12-30 r4883 [mips-linux-3.4.113] (localbuild) Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.orgПосле добавления в строку параметров smartctl в скрипте -d sat скрипт заработал.
было:
SMARTCTL_PARAMS="-iAHf old -l scttemp"стало:
SMARTCTL_PARAMS="-d sat -iAHf old -l scttemp"Ручная проверка на странице слетела из-за обновления lighttpd и lighttpd-mod=cgi до версии 1.4.49-5 и замене файла /opt/etc/lighttpd/conf.d/30-cgi.conf
файлом по умолчанию. В нем нужно просто поправить строчку ".cgi" => "/opt/bin/perl", на ".cgi" => "/bin/sh" как написано в начале этой инструкции и ручная проверка на странице заработает.-
1
-
Помогите поднять VPN по новой сверхбыстрой технологии WireGuard
in Вопросы по сборке и настройке Opkg
Posted
При запуске S01wireguard руками:
~ # /opt/etc/wireguard/S01wireguard start WARNING WARNING WARNING WARNING WARNING WARNING WARNING W G W You are running this software on a Linux kernel, G W which is probably unnecessary and misguided. This G W is because the Linux kernel has built-in first G W class support for WireGuard, and this support is G W much more refined than this slower userspace G W implementation. For more information on G W installing the kernel module, please visit: G W https://www.wireguard.com/install G W G WARNING WARNING WARNING WARNING WARNING WARNING WARNING INFO: (wg0) 2020/02/11 16:06:30 Starting wireguard-go version 0.0.20191012 RTNETLINK answers: Operation not supported Unable to modify interface: Protocol not supported Cannot find device "wg0" Cannot find device "wg0" ifconfig: SIOCSIFMTU: No such device ifconfig: SIOCSIFTXQLEN: No such deviceСодержимое S01wireguard и wg-up:
~ # cat /opt/etc/wireguard/S01wireguard #!/bin/sh PATH=/opt/sbin:/opt/bin:/opt/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/u case $1 in start) logger "Starting WireGuard service." /opt/etc/wireguard/wg-up ;; stop) /opt/etc/wireguard/wg-down ;; restart) logger "Restarting WireGuard service." /opt/etc/wireguard/wg-down sleep 2 /opt/etc/wireguard/wg-up ;; *) echo "Usage: $0 {start|stop|restart}" ;; esac ~ # cat /opt/etc/wireguard/wg-up #!/bin/sh #insmod /lib/modules/4.9-ndm-2/wireguard.ko 2>/dev/null wireguard wg0 ip link del dev wg0 2>/dev/null ip link add dev wg0 type wireguard wg setconf wg0 /opt/etc/wireguard/wg0.conf ip address add dev wg0 10.7.7.1/32 ip link set up dev wg0 ifconfig wg0 mtu 1420 ifconfig wg0 txqueuelen 1000 iptables -A FORWARD -o wg0 -j ACCEPT iptables -A OUTPUT -o wg0 -j ACCEPT iptables -t nat -I POSTROUTING -o wg0 -j MASQUERADE