rustrict

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

Простите, да, для 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 нет. Особенно наглядно видно в этом тесте.

Да, 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: Вот, кое-что нашел

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

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

@exeigor, попробуйте сначала удалить симлинк, а потом создать заново: rm -f /opt/etc/localtime ln -sf /opt/share/zoneinfo/Europe/Moscow /opt/etc/localtime

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

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

@Александр Воробьев, вы, скорее всего, проверяли в браузере под Windows 7-10. ICMPv6 в них по умолчанию заблокирован брандмауэром.