rustrict

Попробуйте проверить отпечаток такой командой: echo | openssl s_client -connect ip:port 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64 Если результат аналогичный вашему, напишите в техподдержку.

А пускай и генерирует при установке 256/1024 бит, а потом, кому это необходимо, сами переделают на новые ключи нужной длины. Лишь бы была такая возможность Спасибо большое! Работает.

Я когда-то хотел уровнять ECDSA host key с прошивочным ecdsa-sha2-nistp521, но dropbear в Entware не умеет для ECDSA в "-s" > 256. ~ # for bits in 256 384 521; do dropbearkey -t ecdsa -f ~/$bits -s $bits; done Generating 256 bit ecdsa key, this may take a while... Public key portion is: ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBIhHr6YQXTr2K0vEzGItoAXLDmRWWkJ53pKko2KDquYRBKXoS0mumn+C8hakRYqlFPywK32m1tNZ1L0mQC/IS/c= root@Keenetic-Giga Fingerprint: sha1!! 5d:19:d5:cc:b0:fe:71:63:95:df:18:2e:75:00:d1:2f:1d:f0:f2:51 Generating 384 bit ecdsa key, this may take a while... Exited: Key size 384 isn't valid. Try 256 Generating 521 bit ecdsa key, this may take a while... Exited: Key size 521 isn't valid. Try 256

@Le ecureuil, в 3.3 Beta 4 стали отваливаться процессы nutdns. Раньше я таких сообщений не видел. Судя по PID, они сразу перезапускаются. Стоит ли как-то переживать по этому поводу? Ноя 26 23:24:09 ndm Service: "DoT "System" UDP-to-TCP proxy #1": unexpectedly stopped. Ноя 27 04:47:24 ndm Service: "DoT "System" UDP-to-TCP proxy #0": unexpectedly stopped.

А сколько у вас клиентов в домашней сети? Я вижу, что зарегистрировано 25, а пул адресов на 20. 5-ти даны статические адреса, но, судя по логу, есть еще, как минимум, один MAC (ec:fa:bc — Espressif Inc.), которому места не досталось. Если устройств много, дайте им больше места. ! ip dhcp pool _WEBADMIN_HOME range 192.168.1.2 192.168.1.21 <-- похоже, что этого мало для вашей сети lease 25200 bind Home enable !

Поддержу. Сейчас приходится обмениваться публичными ключами между Кинетиком и Айфоном через Notes.

Я использую у себя такую схему, работоспособность которой меня устраивает. ИМХО, она лучше связки 6to4 + нешифрованный DNS. 1. Установлен компонент DNS-over-TLS. Используются сервера Cloudflare. Вы можете использовать любые с поддержкой DoT, но учтите такой момент: имея доступ по IPv6, необязательно использовать v6-адреса для DNS-серверов, можно обойтись и v4. Важно, чтобы DNS-сервер отдавал AAAA-записи на запрашиваемые домены. ! dns-proxy tls upstream 1.1.1.1 853 sni cloudflare-dns.com tls upstream 1.0.0.1 853 sni cloudflare-dns.com ! 2. Для IPv6 использую туннель 6in4 (через туннельного брокера) от IP4Market. Остановил выбор на нём потому, что их шлюз находится в Москве: для москвичей пинг около 2-3 мс. Минус только в том, что периодически у них бывают потери пакетов на какое-то время, но это всё равно лучше 6to4. ! interface TunnelSixInFour0 description IP4Market ip remote 193.0.203.203 ipv6 address x:x:x::2 ipv6 prefix x:x:x::/48 ipv6 force-default up ! Если вы хотите сохранить ту схему, которая у вас была, тогда напишите об этом, а я отвечу вам, какие настройки DNS лучше использовать.

А v6-адреса из этого списка к вам прилетают от провайдера? У вас есть доступ в сеть по IPv6?

Судя по скриншоту, у вас Safari пытается установить secure-соединение по 80 порту. Попробуйте сбросить кэш браузера и кэш HSTS.

Погуглил на эту тему, оказалось, что это вызвано ограничением Google Cloud Storage при использовании CNAME. rustrict@Mac-mini ~ % host docs.help.keenetic.com docs.help.keenetic.com is an alias for c.storage.googleapis.com. c.storage.googleapis.com has address 172.217.21.144 c.storage.googleapis.com has IPv6 address 2a00:1450:400f:80c::2010 Note: You can use a CNAME redirect only with HTTP, not with HTTPS. To serve your content through a custom domain over SSL, you can set up a load balancer. То есть при обращении по HTTPS к домену docs.help.keenetic.com, браузер или, например, wget, естественно, не видят в сертификате этого домена и ругаются. rustrict@Mac-mini ~ % echo | openssl s_client -connect docs.help.keenetic.com:443 | openssl x509 -text | grep "DNS:" depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign verify return:1 depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.storage.googleapis.com verify return:1 DONE DNS:*.storage.googleapis.com, DNS:*.appspot.com.storage.googleapis.com, DNS:*.commondatastorage.googleapis.com, DNS:*.content-storage-download.googleapis.com, DNS:*.content-storage-upload.googleapis.com, DNS:*.content-storage.googleapis.com, DNS:*.googleapis.com, DNS:*.storage-download.googleapis.com, DNS:*.storage-upload.googleapis.com, DNS:*.storage.select.googleapis.com, DNS:commondatastorage.googleapis.com, DNS:storage.googleapis.com, DNS:storage.select.googleapis.com, DNS:unfiltered.news Сейчас, если очень нужен HTTPS-доступ, можно пользоваться ссылками storage-download.googleapis.com. Вот они на все текущие справочники: 4G KN-1210-01RU KN-1210 Air KN-1610-01RU KN-1610 City KN-1510-01RU KN-1510 Extra KN-1710-01RU KN-1710 Giga KN-1010-01RU KN-1010 Lite KN-1310-01RU KN-1310 Omni KN-1410-01RU KN-1410 Start KN-1110-01RU KN-1110 Ultra KN-1810-01RU KN-1810 Viva KN-1910-01RU KN-1910 DSL KN-2010-01RU KN-2010 Duo KN-2110-01RU KN-2110 Keenetic 4G III (Rev.B) EMG1301-T10A-RU01V1F kg_rh Keenetic Air EMG1800-T10A ki_ra Keenetic Extra II EMG1812-T10A ki_rb Keenetic Giga III EMG2880-T10A kng_re Keenetic Lite III Rev.B EMG1311-T10A-RU01V1F kl_rh Keenetic Start II EMG1300-T10A-RU01V1F kl_rg Keenetic Ultra II EMG2885-T20A ku_rd

Проверил у себя: никаких проблем, качается. v4: v6:

Действительно, полностью упустил этот момент. Я проверял по справочнику для KN-1010.

@enpa, в справочнике сейчас (1.66) не хватает значений у аргумента engine в п. 3.105 ppe: помимо software, ещё hardware и hardware-ipv6. Вроде такого +----------+---------------+----------------------------+ | Аргумент | Значение | Описание | +----------+---------------+----------------------------+ | engine | software | Программный ускоритель. | + +---------------+----------------------------+ | | hardware | Аппаратный ускоритель. | + +---------------+----------------------------+ | | hardware-ipv6 | Аппаратный ускоритель IPv6.| +----------+---------------+----------------------------+

@TheBB, точно, вы правы насчет xargs. Я поторопился После моего варианта пришлось бы ещё дополнительно opkg --force-reinstall install findutils grep А postinst, к сожалению, в большинстве случаев обновления busybox улетает вместе с симлинками (по моим наблюдениям).

Реализовано в 3.3 Alpha 8.

@enternet, попробуйте настроить Wi-Fi на Айфонах через меню «Другая». Я, например, на своём iPhone SE с iOS 13.1.2 вижу поддержку только WPA3-Enterprise:

Это не была реклама ESNI Мне казалось, что пользователей будет смущать "x" в том тесте после настройки. Видимо, вы правы, текущего текста достаточно.

@enpa, возможно стоит перенести из английской версии статьи про DoT/DoH в русскую уточнение про флаг ESNI в чекере Cloudflare? The Encrypted SNI (ESNI) feature must be enabled in the browser itself to pass the test on that page. Сейчас не совсем понятно из русской статьи, что резолвер в кинетике проверку ESNI не обеспечивает на той странице. Это уж не говоря про особенности браузеров. В Firefox, например, ESNI не будет задействовано без работы через встроенный DoH-резолвер и включенной опции в about:config. И только на тех сайтах, что добавили TXT-запись с публичным ключом к поддомену _esni (на эту тему есть тикет в баг-трекере Мозиллы — https://bugzilla.mozilla.org/show_bug.cgi?id=1500289).

@Le ecureuil, а я верно понимаю, что обработка была исправлена именно для случая отключения интерфейса? Дело в том, что сейчас (3.1.6 Beta) при упавшем коннекте до провайдера (то есть интерфейс остается включен) каждые 2 секунды валятся эти ошибки: Сен 27 14:53:12 ndm Network::Interface::Tunnel: "IPIP0": resolved source 0.0.0.0, any destination. Сен 27 14:53:13 ndm Network::Interface::SecureIpTunnel: "IPIP0": unable to start server mode without specified local source. Сен 27 14:53:13 ndm Network::Interface::SecureIpTunnel: "IPIP0": invalid local source address, reresolving. Сен 27 14:53:13 ndm IpSec::Manager: "IPIP0": IP secure connection and keys was deleted. Сен 27 14:53:13 ndm Network::Interface::Tunnel: "IPIP0": resolved source 0.0.0.0, any destination. Сен 27 14:53:13 ndm Network::Interface::SecureIpTunnel: "IPIP0": updating server IP secure configuration. Сен 27 14:53:13 ndm IpSec::Manager: "IPIP0": IP secure connection was added.

Пожалуйста, подскажите: в настоящий момент можно ограничить работу DoT/DoH каким-то отдельным сегментом? То есть я хочу, чтобы в Home устройства резолвились только через DoT, а в Guest — только через провайдерские сервера. Или я слишком губу раскатал? P. S. Да, можно прописать в настройках DHCP для сегмента сервера провайдера, но по IPv6 link-local все равно работает DoT/DoH (во всех сегментах), а он клиентскими устройствами с IPv6 выбирается как приоритетный.

@Le ecureuil, подтверждаю: то же самое. Версия 2.16.D.1.0-0. Ставится галочка у Режим работы (IPv6), подключаешься по IPv6 к *.keenetic.pro на кинетик с IPv4-only и вылетает ошибка 0x22 (34) [ошибка определения IPv4 адреса клиента]. Пробуешь по IPv4 — всё ок:

Простите меня, что, в общем, ввёл в заблуждение: доступ возможен. @adach, огромное спасибо за наводку! И мне ip nat помогла с доступом. Я у себя воспользовался такой схемой: туннель IPIP over IPsec с настройками от @KorDen. Дополнительно к ним добавил маршрут к модему (на кинетике, из сети которого надо получать доступ): ip route 192.168.8.1 172.31.255.2 IPIP0 auto. На кинетике с модемом выполнил такую команду: ip nat 172.31.255.1 255.255.255.255. После этого доступ появился: Mac-mini:~ rustrict$ traceroute -I 192.168.8.1 traceroute to 192.168.8.1 (192.168.8.1), 64 hops max, 72 byte packets 1 192.168.1.1 (192.168.1.1) 0.674 ms 0.298 ms 0.278 ms 2 172.31.255.2 (172.31.255.2) 85.284 ms 47.494 ms 55.890 ms 3 192.168.8.1 (192.168.8.1) 69.939 ms 73.488 ms 79.967 ms Mac-mini:~ rustrict$ ping -c 5 192.168.8.1 PING 192.168.8.1 (192.168.8.1): 56 data bytes 64 bytes from 192.168.8.1: icmp_seq=0 ttl=62 time=84.598 ms 64 bytes from 192.168.8.1: icmp_seq=1 ttl=62 time=59.497 ms 64 bytes from 192.168.8.1: icmp_seq=2 ttl=62 time=114.291 ms 64 bytes from 192.168.8.1: icmp_seq=3 ttl=62 time=110.362 ms 64 bytes from 192.168.8.1: icmp_seq=4 ttl=62 time=107.353 ms --- 192.168.8.1 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 59.497/95.220/114.291/20.636 ms

Ок, я вас понял. Ещё раз спасибо за исправление.

Простите, да, для MTU команда interface ip mtu работает. Но для TTL я ничего в справочнике не вижу, а ip adjust-ttl send неприменима для TunnelSixInFour: (config)> interface TunnelSixInFour0 Core::Configurator: Done. (config-if)> ip adjust-ttl send 64 Network::Interface::Repository error[6553609]: unable to find TunnelSixInFour0 as "Network::Interface::IP". В запросе мне ваш коллега так описал команду: interface TunnelSixInFour0 ip mtu - set Maximum Transmit Unit size remote - set a remote peer address ttl - set Time to live value interface ip ttl — такой команды как раз сейчас нет.

@Le ecureuil, большое спасибо, особенно за скорость Если можно, пара вопросов: Я правильно понимаю, что изменения появятся в следующем обновлении 3.1? Ваш коллега из поддержки написал в запросе, что будет добавлена команда в CLI для управления значениями TTL и MTU на интерфейсе TunnelSixInFour. Теперь не ждать её появления?