rustrict
-
Posts
187 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by rustrict
-
-
@eralde, версия 3.1.4 Beta (3.01.C.4.0-0): по-прежнему есть этот всплывающий текст из title. Я так понимаю, что это рудимент от 2.15, и в 3.x всплывающих подсказок у "?" вообще нет?
-
Пожалуйста, подскажите: в настоящий момент можно ограничить работу DoT/DoH каким-то отдельным сегментом? То есть я хочу, чтобы в Home устройства резолвились только через DoT, а в Guest — только через провайдерские сервера. Или я слишком губу раскатал?
P. S. Да, можно прописать в настройках DHCP для сегмента сервера провайдера, но по IPv6 link-local все равно работает DoT/DoH (во всех сегментах), а он клиентскими устройствами с IPv6 выбирается как приоритетный.
-
7 часов назад, VOG V сказал:
4. При переходе на домен третьего роуетра а котором не нестроен IPV6 - ошибка
@Le ecureuil, подтверждаю: то же самое. Версия 2.16.D.1.0-0. Ставится галочка у Режим работы (IPv6), подключаешься по IPv6 к *.keenetic.pro на кинетик с IPv4-only и вылетает ошибка 0x22 (34) [ошибка определения IPv4 адреса клиента]. Пробуешь по IPv4 — всё ок:
Скрытый текстMac-mini:~ rustrict$ curl -v https://*.keenetic.pro * Rebuilt URL to: https://*.keenetic.pro/ * Trying 2a01:4f8:d1:1d00::103... * TCP_NODELAY set * Connected to *.keenetic.pro (2a01:4f8:d1:1d00::103) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: none * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384 * ALPN, server did not agree to a protocol * Server certificate: * subject: CN=keenetic.pro * start date: Aug 11 21:56:20 2019 GMT * expire date: Nov 9 21:56:20 2019 GMT * subjectAltName: host "*.keenetic.pro" matched cert's "*.keenetic.pro" * issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3 * SSL certificate verify ok. > GET / HTTP/1.1 > Host: *.keenetic.pro > User-Agent: curl/7.54.0 > Accept: */* > < HTTP/1.1 403 Forbidden < Content-Length: 20950 < Content-Type: text/html < Server: NDM NDNS < X-Detail: Unclassified (0x22) < Date: Wed, 18 Sep 2019 22:59:47 GMT <...>
Mac-mini:~ rustrict$ curl -4v https://*.keenetic.pro * Rebuilt URL to: https://*.keenetic.pro/ * Trying 23.105.235.71... * TCP_NODELAY set * Connected to *.keenetic.pro (23.105.235.71) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: none * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=*.keenetic.pro * start date: Sep 12 17:40:24 2019 GMT * expire date: Dec 11 17:40:24 2019 GMT * subjectAltName: host "*.keenetic.pro" matched cert's "*.keenetic.pro" * issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3 * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x7f8a71806c00) > GET / HTTP/2 > Host: *.keenetic.pro > User-Agent: curl/7.54.0 > Accept: */* > * Connection state changed (MAX_CONCURRENT_STREAMS updated)! < HTTP/2 200 < server: Web server < date: Wed, 18 Sep 2019 23:03:55 GMT < content-type: text/html; charset=utf-8 < content-length: 3004 < last-modified: Mon, 16 Sep 2019 19:11:54 GMT < vary: Accept-Encoding < etag: "5d7fde7a-bbc" < expires: Wed, 18 Sep 2019 23:03:55 GMT < cache-control: max-age=0 < cache-control: private < cache-control: must-revalidate < accept-ranges: bytes <...>
- 2
-
В 29.08.2019 в 16:34, rustrict сказал:
Я не смог сейчас сходу найти поиском, но @Le ecureuil в разных темах в разное время писал, что такой доступ невозможен. Загвоздка с маршрутизацией на самом модеме, ЕМНИП.
Простите меня, что, в общем, ввёл в заблуждение: доступ возможен.
В 29.08.2019 в 20:31, adach сказал:получилось коряво запустить nat на L2TP клиенте. Доступ к модему 192.168.8.1 заработал после команды ip nat 192.168.33.0 255.255.255.0. Это подсеть сервера, из которой через туннель хожу на модем.
@adach, огромное спасибо за наводку! И мне ip nat помогла с доступом.
В 29.08.2019 в 20:31, adach сказал:Уважаемые знатоки, может подскажете более элегантное решение? Может поменять туннель на PPTP или другой, чтоб можно было на интерфейс клиента vpn сослаться в 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
- 1
-
8 минут назад, Le ecureuil сказал:
TTL не будет, пока смысла в ней не вижу совсем.
Ок, я вас понял. Ещё раз спасибо за исправление.
-
Простите, да, для 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. Теперь не ждать её появления?
-
Добавлю к уже написанным пожеланиям ещё шейпинг трафика IPv6. Сейчас забавная ситуация возникает в dual-stack, когда в сегменте с ограничением скорости IPv4-трафик режется, а IPv6 нет. Особенно наглядно видно в этом тесте.
-
5 часов назад, Татьяна Любимцева сказал:
Вроде тут пишут https://developers.google.com/speed/public-dns/docs/dns-over-tls
The stub resolver is configured with the DNS-over-TLS resolver name dns.google.
А не dns.google.com. Нет?
Да, Google рекомендует использовать в качестве Authentication Domain Name (ADN) адрес dns.google. Он же прописан в их сертификате как «Common Name» (CN).
Но в этом же сертификате есть поле «Subject Alternative Name» (SAN), в котором есть адрес dns.google.com. Поэтому проблем с подключением по такому адресу быть не должно.
Mac-mini:~ rustrict$ echo | openssl s_client -connect dns.google.com:853 | 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 = dns.google verify return:1 DONE DNS:dns.google, DNS:*.dns.google.com, DNS:8888.google, DNS:dns.google.com, DNS:dns64.dns.google, IP Address:2001:4860:4860:0:0:0:0:64, IP Address:2001:4860:4860:0:0:0:0:6464, IP Address:2001:4860:4860:0:0:0:0:8844, IP Address:2001:4860:4860:0:0:0:0:8888, IP Address:8.8.4.4, IP Address:8.8.8.8
Ну и собственно пример запроса:
rustrict@debian:~$ kdig -d @dns.google.com +tls-ca +tls-host=dns.google.com keenetic.com ;; DEBUG: Querying for owner(keenetic.com.), class(1), type(1), server(dns.google.com), port(853), protocol(TCP) ;; DEBUG: TLS, imported 128 system certificates ;; DEBUG: TLS, received certificate hierarchy: ;; DEBUG: #1, C=US,ST=California,L=Mountain View,O=Google LLC,CN=dns.google ;; DEBUG: SHA-256 PIN: vEbqO29VPXOULHxmGJxvrlGDm1MJ4XJQ6MtmlpgvL40= ;; DEBUG: #2, C=US,O=Google Trust Services,CN=GTS CA 1O1 ;; DEBUG: SHA-256 PIN: YZPgTZ+woNCCCIW3LH2CxQeLzB/1m42QcCTBSdgayjs= ;; DEBUG: TLS, skipping certificate PIN check ;; DEBUG: TLS, The certificate is trusted. ;; TLS session (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 13351 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 512 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; keenetic.com. IN A ;; ANSWER SECTION: keenetic.com. 3599 IN A 46.105.148.88 ;; Received 57 B ;; Time 2019-09-01 18:49:02 MSK ;; From 2001:4860:4860::8888@853(TCP) in 58.0 ms
-
Это еще из 2.15 "хвост":
-
-
С другой стороны, есть еще по теме:
-
Я не смог сейчас сходу найти поиском, но @Le ecureuil в разных темах в разное время писал, что такой доступ невозможен. Загвоздка с маршрутизацией на самом модеме, ЕМНИП.
UPD: Вот, кое-что нашел
-
16 минут назад, KorDen сказал:
По мотивам данной темы, из чата: аналогичная проблема с туннелями 6in4, тоже желательно хотя бы IPDEFTTL вместо inherit
На всякий случай мой запрос по этой теме #446611. Если я ничего не путаю, то @vst там в копии.
- 1
-
Извините, конечно, после "rm" ключ "f" у "ln" уже будет лишним. Правильнее так:
rm -f /opt/etc/localtime ln -s /opt/share/zoneinfo/Europe/Moscow /opt/etc/localtime
Дело там в том, что Entware устанавливается с симлинком "localtime -> /opt/share/zoneinfo/". Если выполнить "ln -sf /opt/share/zoneinfo/Europe/Moscow /opt/etc/localtime", то с localtime ничего не произойдет, зато в /opt/share/zoneinfo создастся симлинк "Moscow -> /opt/share/zoneinfo/Europe/Moscow".
- 2
- 1
-
@exeigor, попробуйте сначала удалить симлинк, а потом создать заново:
rm -f /opt/etc/localtime ln -sf /opt/share/zoneinfo/Europe/Moscow /opt/etc/localtime
- 2
-
В 19.07.2019 в 22:50, rustrict сказал:
@enpa, в текущей редакции справочника (1.57) для команды crypto engine (п. 3.13) написано, что по умолчанию используется программный режим. Да, если её выполнить с префиксом no, включается режим software, как и написано дальше. Но, если сбросить роутер до заводских настроек, то в конфиге по умолчанию стоит crypto engine hardware. Это несколько сбивает с толку. Возможно, стоит уточнить описание?
Изменено в редакции 1.58 (26.07.2019).
- 1
-
@enpa, в текущей редакции справочника (1.57) для команды crypto engine (п. 3.13) написано, что по умолчанию используется программный режим. Да, если её выполнить с префиксом no, включается режим software, как и написано дальше. Но, если сбросить роутер до заводских настроек, то в конфиге по умолчанию стоит crypto engine hardware. Это несколько сбивает с толку. Возможно, стоит уточнить описание?
- 1
-
В 09.04.2019 в 11:43, Александр Воробьев сказал:
1. Your router or firewall is filtering ICMPv6 messages sent to your computer. An IPv6 host that cannot receive ICMP messages may encounter problems like some web pages loading partially or not at all. (Маршрутизатор или брандмауэр фильтрует сообщения ICMPv6, отправляемые на компьютер. Хост IPv6, который не может получать сообщения ICMP, может столкнуться с такими проблемами, как частичная или полная загрузка некоторых веб-страниц.).
@Александр Воробьев, вы, скорее всего, проверяли в браузере под Windows 7-10. ICMPv6 в них по умолчанию заблокирован брандмауэром.
- 2
-
@denis0605, ответ у вас прямо в логе:
ЦитатаJul 09 16:30:10 ndm
Opkg::Manager: /opt/etc/init.d/doinstall: FATAL: kernel too old.Вам нужно внимательнее просмотреть эту инструкцию (в данном случае — "Требования").
На ваш Keenetic можно поставить прошивку версии 2.15 через CLI:
components list delta components commit
Учтите при этом дисклеймер внизу поста по ссылке:
ЦитатаВыпускается по инициативе разработчиков, официальная поддержка не оказывается.
-
@i81, а у вас там флешка случайно не FAT32/NTFS? Если так, вам надо форматировать её в ext2/ext3/ext4 прежде, чем начинать установку. Как это сделать для ext4 можно посмотреть, например, тут: https://help.keenetic.com/hc/ru/articles/115005875145-Использование-файловой-системы-EXT4-на-USB-накопителях
- 1
-
Недавно писали об этом, см.:
-
Если вы там ещё не делали opkg update && opkg upgrade, то можно ввести команду opkg flag hold busybox, чтобы не давать ему обновляться.
-
9 минут назад, dexter сказал:
Может ему руками нужный файл подсунуть на флешку, предварительно его скачав?
Можно вручную забрать нужную часть из Makefile busybox и закинуть её через веб-интерфейс, но без /opt/bin/busybox он сам себе симлинки не восстановит
Ultra (KN-1810) - 3.00.B.0.0-0 - Вкладка проводной
in 3.1
Posted
@eralde, 3.1.4 Beta с Firefox 69.0.1 и Safari 13.0 (десктоп): если у селектора ".btn.btn--long" выключить свойство "width: 49%;", то ширина кнопки становится нормальной, то есть подписи на русском и украинском становятся посередине.