Le ecureuil
-
Постов
10 886 -
Зарегистрирован
-
Посещение
-
Победитель дней
637
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Le ecureuil
-
Видимо где-то установлены последние системные обновления, а где-то нет. Еще может быть банально часы врут (где работает все).
-
Хм, да, появилась такая тема. А реально какие-то серверы ее требуют (покупные, а не самодельные)? Я лично жду версии 2.6, чтобы сразу с dco все добавить. Если сейчас добавлять на месяца-полтора 2.5, а потом снова 2.6 - это лишняя работа. Прошу немного обождать. -
Конкретно с 8.8.8.8 наверное все прокатит, но не везде есть жестко вшитые в сертификат адреса, это скорее даже исключение.
-
Сетевые устройства с разными ip имеют один mac адрес
Le ecureuil ответил lun4r вопрос в Обмен опытом
Так и ожидается. WiFi-точки доступа всегда делают Mac Address Translation из-за физических ограничений WiFi. Потому только терпеть такое, или целиком на провод переходить. В MWS используется особый, 4-адресный режим, и там такой проблемы нет, но он поддерживается только между устройствами KN. Как вариант можно выкинуть это и поставить KN. -
Еще Identrust устаревший нужно удалить похоже.
-
Давайте по шагам. - OpenVPN на 53 порту по идее не работает, это порт для DNS. - tls-crypt-v2 поддерживает. - в нашей версии 2.4.6 есть все патчи по CVE и принесена поддержка chapoly. Что еще вам не хватает в 2.4.6 из 2.5.3?
-
Установите корневые сертификаты в винде отсюда: https://letsencrypt.org/certificates/ Нужен ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1). Потом в IE стоит проверить как открывается вот этот сайт: https://valid-isrgrootx1.letsencrypt.org/
-
Когда в URL не указано доменное имя как можно понять какой сертификат из хранилища брать для проверки? Если брать тот, что пришел в ответе по TLS - а как доказать что юзер хотел именно этот домен и не происходит MITM?
-
По идее да, не должны. Но тогда у вас никакой проверки сертификата тоже не будет, что вообще говоря не очень. В 3.8 поведение выровнено, и DoT и DoH сначала смотрят в ip host (если там что-то есть, то используют только тот адрес для домена, который вы руками заколотили), потом идут в ip name-server или к провайдеру (в зависимости от того, что есть), и только потом уже лезут на fallback.
-
Нет, простого решения не видно, кроме другого сегмента без DHCP.
-
На самом деле любой, который работает, является правильным. Минимальный определен в 576 для IPv4 и 1280 для IPv6.
-
Для snxconnect нужен браузер же чтобы дергать данные из веб-страницы.
-
В теории таким параметром является DUID, но тут возникают следующие вопросы: - он необязателен, найдется пачка устройств, которые его не шлют - это спасет только от получения адреса по DHCP, если заколотить руками то все будет работать Потому мне и не очень понятна логика, но контроль DUID наверное можно сделать.
-
Думаю можно подумать об этом.
- 1 ответ
-
- 2
-
-
@diqipib попробуйте > no ppe пока.
-
Ну показать вот это вот в web несложно, а что под словом "контроль" подразумевается?
-
У вас прямое подключение? Cifs? Cifs у вас классический или tsmb?
-
Даже если в DHCP можно сделать проверку по UID, то никакой защиты от ручного назначения MAC + IP ничего не спасет.
-
В 3.8 будут браться DNS от провадйера или из команды ip nameserver. Или можно будет заколотить руками через ip host.
- 3 ответа
-
- 5
-
-
-
Только 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 в конце вредит. Как будет время добавлю трейс именно в места создания клонов, по идее их быть не должно в текущем конфиге.