Le ecureuil

Когда в URL не указано доменное имя как можно понять какой сертификат из хранилища брать для проверки? Если брать тот, что пришел в ответе по TLS - а как доказать что юзер хотел именно этот домен и не происходит MITM?

По идее да, не должны. Но тогда у вас никакой проверки сертификата тоже не будет, что вообще говоря не очень. В 3.8 поведение выровнено, и DoT и DoH сначала смотрят в ip host (если там что-то есть, то используют только тот адрес для домена, который вы руками заколотили), потом идут в ip name-server или к провайдеру (в зависимости от того, что есть), и только потом уже лезут на fallback.

Нет, простого решения не видно, кроме другого сегмента без DHCP.

На самом деле любой, который работает, является правильным. Минимальный определен в 576 для IPv4 и 1280 для IPv6.

Для snxconnect нужен браузер же чтобы дергать данные из веб-страницы.

В теории таким параметром является DUID, но тут возникают следующие вопросы: - он необязателен, найдется пачка устройств, которые его не шлют - это спасет только от получения адреса по DHCP, если заколотить руками то все будет работать Потому мне и не очень понятна логика, но контроль DUID наверное можно сделать.

Думаю можно подумать об этом.

@diqipib попробуйте > no ppe пока.

Ну показать вот это вот в web несложно, а что под словом "контроль" подразумевается?

У вас прямое подключение? Cifs? Cifs у вас классический или tsmb?

Даже если в DHCP можно сделать проверку по UID, то никакой защиты от ручного назначения MAC + IP ничего не спасет.

Медленно, но верно двигаемся.

В 3.8 будут браться DNS от провадйера или из команды ip nameserver. Или можно будет заколотить руками через ip host.

Только draft и delta.

Да, в 3.8 тоже будет. Будут использоваться провайдерские DNS или из ip nameserver, и только если везде пусто будет идти fallback на эти.

<hostname>.<domain> подойдет?

Работа ведется над этим, в версии 3.8 (по моим ощущениям) все поправилось. В 3.7 это, к сожалению, перенести не планируется, так как с 3.8 убрана поддержка формата JSON, остался только DNS-Message. Как только появится 3.8.A сразу ставьте и проверяйте.

Ничего неясно. Вообще я бы еще поискал кто генерирует клонированные skb, вероятно это у них skb_shared_info в конце вредит. Как будет время добавлю трейс именно в места создания клонов, по идее их быть не должно в текущем конфиге.

Это встроенный bootstrap, используется для разрешения внешнего имени DoH и DoT. Можете сами увидеть это, посмотря дампы на WAN, какие запросы туда идут. Про запас зашит такой список адресов для DoT: "8.8.8.8", "1.1.1.1", "145.100.185.15", "185.49.141.37" Для DoH вот: https://github.com/aarond10/https_dns_proxy/blob/master/src/options.c#L31

Нет, wg не менялся с самого портирования в 2.16.

Попробуйте WiFi выключить (и ap, и wisp) и попробовать воспроизвести без него. Есть вероятность, что в драйвере wifi баг.

Еще кто-то подтверждает проблемы с SSTP?

Это не мысль, это так работает. Host принудительно перезаписывается в адрес роутера (модемы и всякие китайские приблуды очень нелюбят когда в Host что-то осмысленное и не из сети локалки). Но это можно выключить через preserve-host.

На прямо сейчас нужно дальше смотреть код, может что-то еще увижу. Но причина огромных skb неясна.

Да, баг странный и редкий. Если совсем кратко, то откуда-то начинают лезть пакеты размером с мегабайт (!), и при попытке выполнить их шифрование память резко заканчивается. Причем реальный размер правилен, небольшой, это скорее всего смещение skb->end кривое или skb нелинейна (эту гипотезу я проверил в последней версии, она не подтвердилась), или GSO работает так странно. Откуда такое прет - хз, но вот версия с отключенным GSO, давайте на ней проверим еще: https://disk.yandex.ru/d/CIut0HfC6l1ahw В момент начала тупняка какие сервисы на роутере запущены (transmission?) и что клиенты передают? По WiFi сидят или по LAN?