Jump to content

rustrict

Forum Members
  • Posts

    187
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by rustrict

  1. В 04.05.2019 в 09:29, Space Alex сказал:

    2) В Firefox 66.0.3 на данной кнопке текст отображается не ровно, съезжает маленько. В мобильном хроме такого нет.

    @eralde, 3.1.4 Beta с Firefox 69.0.1 и Safari 13.0 (десктоп): если у селектора ".btn.btn--long" выключить свойство "width: 49%;", то ширина кнопки становится нормальной, то есть подписи на русском и украинском становятся посередине.

    • Thanks 1
    • Upvote 1
  2. Пожалуйста, подскажите: в настоящий момент можно ограничить работу DoT/DoH каким-то отдельным сегментом? То есть я хочу, чтобы в Home устройства резолвились только через DoT, а в Guest — только через провайдерские сервера. Или я слишком губу раскатал?

    P. S. Да, можно прописать в настройках DHCP для сегмента сервера провайдера, но по IPv6 link-local все равно работает DoT/DoH (во всех сегментах), а он клиентскими устройствами с IPv6 выбирается как приоритетный.

  3. 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
    <...>

     

     

    • Thanks 2
  4. В 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
    Скрытый текст

    e3372h-web-screenshot.thumb.png.d63cbb10755c99a4b23895e5079cca53.png

     

    • Thanks 1
  5. Простите, да, для 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 — такой команды как раз сейчас нет.

  6. @Le ecureuil, большое спасибо, особенно за скорость :)

    Если можно, пара вопросов:

    1. Я правильно понимаю, что изменения появятся в следующем обновлении 3.1?
    2. Ваш коллега из поддержки написал в запросе, что будет добавлена команда в CLI для управления значениями TTL и MTU на интерфейсе TunnelSixInFour. Теперь не ждать её появления?
  7. Добавлю к уже написанным пожеланиям ещё шейпинг трафика IPv6. Сейчас забавная ситуация возникает в dual-stack, когда в сегменте с ограничением скорости IPv4-трафик режется, а IPv6 нет. Особенно наглядно видно в этом тесте.

  8. 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

     

  9. Я не смог сейчас сходу найти поиском, но @Le ecureuil в разных темах в разное время писал, что такой доступ невозможен. Загвоздка с маршрутизацией на самом модеме, ЕМНИП.

    UPD: Вот, кое-что нашел

     

  10. 16 минут назад, KorDen сказал:

    По мотивам данной темы, из чата: аналогичная проблема с туннелями 6in4, тоже желательно хотя бы IPDEFTTL вместо inherit

    На всякий случай мой запрос по этой теме #446611. Если я ничего не путаю, то @vst там в копии.

    • Thanks 1
  11. Извините, конечно, после "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".

    • Thanks 2
    • Upvote 1
  12. В 19.07.2019 в 22:50, rustrict сказал:

    @enpa, в текущей редакции справочника (1.57) для команды crypto engine (п. 3.13) написано, что по умолчанию используется программный режим. Да, если её выполнить с префиксом no, включается режим software, как и написано дальше. Но, если сбросить роутер до заводских настроек, то в конфиге по умолчанию стоит crypto engine hardware. Это несколько сбивает с толку. Возможно, стоит уточнить описание?

    Изменено в редакции 1.58 (26.07.2019).

    • Thanks 1
  13. @enpa, в текущей редакции справочника (1.57) для команды crypto engine (п. 3.13) написано, что по умолчанию используется программный режим. Да, если её выполнить с префиксом no, включается режим software, как и написано дальше. Но, если сбросить роутер до заводских настроек, то в конфиге по умолчанию стоит crypto engine hardware. Это несколько сбивает с толку. Возможно, стоит уточнить описание?

    • Thanks 1

    IPV6

    В 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 в них по умолчанию заблокирован брандмауэром.

    • Thanks 2
  14. @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

    Учтите при этом дисклеймер внизу поста по ссылке:

    Цитата

    Выпускается по инициативе разработчиков, официальная поддержка не оказывается.

     

  15. @i81, а у вас там флешка случайно не FAT32/NTFS? Если так, вам надо форматировать её в ext2/ext3/ext4 прежде, чем начинать установку. Как это сделать для ext4 можно посмотреть, например, тут: https://help.keenetic.com/hc/ru/articles/115005875145-Использование-файловой-системы-EXT4-на-USB-накопителях

    • Thanks 1
  16. 9 минут назад, dexter сказал:

    Может ему руками нужный файл подсунуть на флешку, предварительно его скачав? 

    Можно вручную забрать нужную часть из Makefile busybox и закинуть её через веб-интерфейс, но без /opt/bin/busybox он сам себе симлинки не восстановит :(

×
×
  • Create New...