rustrict

Захват пакетов на WAN-интерфейсе. "Фильтр захвата" оставьте пустым. Судя по скрину, флуд непрерывный, поэтому для захвата будет достаточно нескольких секунд (счетчик пакетов будет накручиваться очень быстро). В Wireshark посмотрите кто источник.

Проблема в модеме:

Перешёл с 3.5.3 на 3.6 Alpha 6. На этапе загрузки и далее стала появляться ошибка: kernel: nf_conntrack: unable to save third interface 23, already has 20 and 7 Self-test ниже.

Здесь надо или без -i вообще, или -i /root/.ssh/id_rsa. Давайте все-таки вернемся к Entware. Появился ли доступ по ключу после моей команды выше? Если нет, то покажите еще права на папки: На клиентском устройстве ls -la /root/.ssh На роутере ls -la /opt/etc/dropbear

Пока я заметил, что вы переносили ключ не из той папки, которую проверяет ssh. Попробуйте: cat /root/.ssh/id_rsa.pub | ssh -p 222 root@192.168.1.1 "cat > /opt/etc/dropbear/authorized_keys && chmod 600 /opt/etc/dropbear/authorized_keys"

Это не так: Compatible with OpenSSH ~/.ssh/authorized_keys public key authentication Я вам в другой теме предложил посмотреть лог подключения. Проверьте, например, что в ряду PreferredAuthentications publickey стоит впереди password: debug3: preferred publickey,keyboard-interactive,password

Если подключаетесь через ssh, добавьте параметр -vvv для дебага и посмотрите, что там происходит при аутентификации. У меня это выглядит так: <...> debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /Users/rustrict/.ssh/id_ed25519 ED25519 SHA256:XXX explicit debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 60 debug1: Server accepts key: /Users/rustrict/.ssh/id_ed25519 ED25519 SHA256:XXX explicit debug3: sign_and_send_pubkey: ED25519 SHA256:XXX debug3: sign_and_send_pubkey: signing using ssh-ed25519 <...> P. S. С такими вопросами надо в профильный раздел по Entware.

@vst, подскажите, пожалуйста, есть ли в планах на будущее возможность задать для сегментов произвольные IPv6 DNS-сервера (до 3 из-за ограничения в radvd) = управлять полем RDNSS в radvd.conf? То есть, дать возможность резолвить имена по IPv6, минуя DNS proxy, индивидуально для каждого BridgeX.

Лимиты ICMPv6 перенесены, но вот правило для fe80::/10 в INPUT осталось + нет правил, добавленных в _NDM_INPUT.

@Le ecureuil, перенесите, пожалуйста, в netfilter 2.16/2.11 изменения из этой темы помимо лимитов ICMPv6. (config)> show ipv6 netfilter <...> ==== Table: "filter" ==== == Chain INPUT == <...> src: fe80::/10, dst: ::/0, in: "*", out: "*", proto: "any"; ACCEPT <...> (config)> show ver release: 2.16.D.3.0-5 <...>

@enpa, спасибо за исправления в 1.87! Только упущен момент в описании "ip ssh keygen default": с появлением ed25519 эта команда генерирует 3 ключа.

Попробуйте так: #!/bin/sh [ ! -x "$0" ] && exit 0 <...> Есть "+x" - выполнится, нет - exit 0.

@enpa @MuKu, в текущих мануалах 1.86 для устройств с поддержкой 3.4: Нет команды "ip ssh cipher"; В "ip ssh keygen" не упоминается ключ ed25519 в принципе, и его генерация default в частности. Ещё заметил: Нет команды "whoami". Возможно намеренно, но в базовых командах не хватает "exec"; В глоссарии ссылка на Entware в сноске ведёт к архивному репозиторию. Актуальная: https://github.com/Entware/Entware.

К прошивочному dropbear — нет. Если есть возможность использовать Entware, то там authorized_keys работают. Подключаетесь, запускаете ndmc и вы в CLI.

Дёргайте провайдера насчёт настроек их оборудования.

3.4 Beta 2 (незарегистрированный хост в protected-сегменте): ~ # ndmc -c "sh run" | grep static ip static udp GigabitEthernet1 53 10.1.30.43 !DNS-test ~ # tcpdump -v -i br1 port 53 tcpdump: listening on br1, link-type EN10MB (Ethernet), capture size 262144 bytes 20:17:50.718700 IP (tos 0x0, ttl 56, id 43324, offset 0, flags [none], proto UDP (17), length 81) pppoe-static.mosoblast.rt.ru.51823 > 10.1.30.43.domain: 37248+ [1au] A? keenetic.com. (53) 20:17:55.717505 IP (tos 0x0, ttl 56, id 44463, offset 0, flags [none], proto UDP (17), length 81) pppoe-static.mosoblast.rt.ru.51823 > 10.1.30.43.domain: 37248+ [1au] A? keenetic.com. (53) 20:18:00.717818 IP (tos 0x0, ttl 56, id 45527, offset 0, flags [none], proto UDP (17), length 81) pppoe-static.mosoblast.rt.ru.51823 > 10.1.30.43.domain: 37248+ [1au] A? keenetic.com. (53) ^C 3 packets captured 3 packets received by filter 0 packets dropped by kernel Не стал поднимать сервер, но, я думаю, что проблем бы не возникло. С зарегистрированным устройством (в ip static не IP, а MAC целевого хоста) в private-сегменте аналогично.

Эти правила нужны для работы с DNS-прокси роутера в сегменте с security-level protected. Можно в вебе на странице переадресации портов.

Менял так-сяк несколько часов и получилось: ipv6-icmptype 3 limit: avg 15/sec burst 30 ipv6-icmptype 128 limit: avg 15/sec burst 30 ipv6-icmptype 129 limit: avg 15/sec burst 30 Оказалось, что и 128, 129 надо бы подтянуть

@vst, можно попросить, пожалуйста, изменить (ослабить) лимит в цепочке _NDM_ICMPV6_POLICY для Time Exceeded (Type 3). У меня за роутером стоит пробник RIPE Atlas, то есть через firewall проходит заметное количество транзитных ICMPv6-пакетов, и при traceroute'ах постоянно возникает ситуация, когда на WAN пакет пришёл, а через fw до хоста не добрался. Ниже, скрытым постом, пример такой ситуации.

Зачем же рубить с плеча? Пусть будет гибкость у работающего сервиса. И потом, это просто голосовалка, я лишь предлагаю.

Предлагаю дополнить easyconfig check командой "easyconfig check exclude-captive" для отключения проверки доступности интернета через сервис NDM. Хотелось бы иметь возможность (пусть это просто надпись и лампочка) не зависеть от одного ресурса при проверке: есть интернет или нет. В настоящий момент чекер игнорирует доступность ресурсов из списка hosts, когда "отвалился" captive. Классическая картина: (config)> show internet status checked: Thu Apr 2 13:23:04 2020 enabled: yes reliable: yes gateway-accessible: yes dns-accessible: yes host-accessible: yes captive-accessible: no internet: no

Доступ можно дать через REST, но ответом будет массив JSON, который телевизор естественно не переварит. Других вариантов без авторизации или без использования Entware я найти не смог.

@Le ecureuil@ndm, похоже, что и в 2.16.D.1.0-1 патч не перенесли.

@vst, насколько я понял, правило в netfilter из первого сообщения было удалено в версии 3.3.7. Но теперь есть небольшая проблема на BridgeX с security-level protected: 53 порт перестал быть доступным по TCP. dig +short AAAA ya.ru @fe80::c835:c0ff:fe11:e492%en1 2a02:6b8::2:242 dig +short +tcp AAAA ya.ru @fe80::c835:c0ff:fe11:e492%en1 ;; Connection to fe80::c835:c0ff:fe11:e492%7#53(fe80::c835:c0ff:fe11:e492%7) for ya.ru failed: timed out. ;; Connection to fe80::c835:c0ff:fe11:e492%7#53(fe80::c835:c0ff:fe11:e492%7) for ya.ru failed: timed out. ;; connection timed out; no servers could be reached ;; Connection to fe80::c835:c0ff:fe11:e492%7#53(fe80::c835:c0ff:fe11:e492%7) for ya.ru failed: timed out. Не силен в правилах netfilter, но я так понимаю, что не хватает такого в цепочке _NDM_INPUT: 0 0 _NDM_SL_PROTECT tcp * * ::/0 ::/0 tcp dpt:53 Для IPv4 оно существует, пусть и в цепочке с другим именем (_NDM_IP_PROTECT): 0 0 _NDM_SL_PROTECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 И проблем с 53 портом и TCP не наблюдается: dig +short AAAA ya.ru @10.1.30.1 2a02:6b8::2:242 dig +short +tcp AAAA ya.ru @10.1.30.1 2a02:6b8::2:242

Копать в техподдержку или попросить помощи тут у @Le ecureuil или @enpa. Я попробовал у себя связку доменное имя + нестандартный порт для HTTPS на сервере dns.seby.io - Vultr (https://doh.seby.io:8443/dns-query), и она также не взлетела. Для работы DoH используется, судя по всему, этот прокси, а я так и не смог понять умеет ли он в что-то отличное от :443.