клиент генерирует новый сессионный ключ, и как он его может безопасно передать точке доступа?

Был отличный мультик на эту тему, "как передать шифрованные данные по заведомо прослушиваемому каналу", поищите, очень интересно)

как передать шифрованные данные по заведомо прослушиваемому каналу при условии что есть ключ который известен злоумышленнику?

даже в варианте когда используется ассиметричное шифрование и есть 4 ключа из которых 2 никому не известны требуется третья сторона с сертификатами что бы что то там безопасно передавать

даже в варианте когда используется ассиметричное шифрование и есть 4 ключа из которых 2 никому не известны требуется третья сторона с сертификатами что бы что то там безопасно передавать

как передать шифрованные данные по заведомо прослушиваемому каналу при условии что есть ключ который известен злоумышленнику?

Речь о Diffie-Hellman Groups: порядке и частоте замены ключа. Как говорится ключи нужно менять чаще, чем время их "взлома". У меня l2tp ipsec сделан вот так. Две группы и время в 120 секунд.

А я и не писал что у меня в впн адресация пересекается с локальной. Локальная сеть 192.168.0.0/24. ВПН сеть 192.168.200.0/24

Граждане , а какой параметр в Capsman. делает изоляцию клиентов друг от друга на точках?

client to client forwarding

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

я вижу только /system routerboard upgrade, что выполняется в ROS7 автоматом, но сегодня прозвучало, что оно и в ROS6 как-то само обновляется? В один ребут можно это сделать?

Suggestions When using a RouterBOARD device, it is always suggested to upgrade it's RouterBOOT bootloader after RouterOS is upgraded. To do this, issue the command "/system routerboard upgrade"

Доброго времени суток. Подскажите, где взять бубен - на тестовый hap ac забыл пароль, и включение с зажатым ресетом что-то не помогает. Отпускаю, когда начинает мигать usr. Такое ощущение, то какой-то нюанс забыл

Попробуйте netinstall

хотя на домашнем компе зашел на него аж бегом, конфиг сбросился. на работе бодался из вайна....

ему для работы нужно забайндить 69 порт. под линуксом это можно сделать только под суперюзером или с CAP_NET_ADMIN или CAP_NET_RAW (которые нужно вешать на wineserver). а из-под sudo wine ругается...

ага, спасибо, надо будет порыть

нет, netinstall мне так часто не нужен ) я не смог винбоксом по маку на роутер попасть.

у меня это когда-то работало под очень старым вайном, а потом перестало. сейчас не помню версию в которой сломалось

под линукс есть отдельный консольный netinstall. я его не пробовал

Так по всех клиентах, где микротики стоят, и там чисто, а вот на домашнем загадка

Возможно у провайдера включен proxy-arp на интерфейсе.

Коллеги, нужна помощь. Сам найти решение пока не могу и выглядит все анти-логично. Роутер model: RB2011UiAS revision: r3 firmware-type: ar9344 current-firmware: 6.49.2 В нем в eth1 настроена пачка вланов с серыми подсетями и белыми ip-unnumbered и торчит гирлянда управляемых свитчей. Роутер - свитч - свитч - клиент Проблема: Когда создаю новый bridge_mgmt (нужен для объединения вланов управления l2 свитчами с разных изернет портов микротика) и добавляю в него только mgmt_vlan с eth1 - перестает работать часть клиентов с ip-unnumbered за eth1. А именно - от них нет приходящих пакетов в их вланах. Т.е. Как будто перестает микротик слушать эти вланы. Есть работающие примеры с тем же конфигом, банальное - апгреид, пересоздание интерфейсов, перепривязка IP - делал. Сейчас сделаю срез конфига - пришлю. Может быть есть мысли? Уж не в двух свитч чипах ли дело? С сетевой точки зрения полный бред, не работали бы все - хотябы, а так только выборочно.

Собирал дамп на bridge_mgmt - ничего необычного. Torch - аналогично. В логах сообщений нет с ошибками. 22:43:56 bridge,info "bridge_mgmt" mac address changed to 08:55:31:EF:B0:14 22:43:56 system,info bridge port changed by admin 22:44:07 system,info bridge port changed by admin 22:48:13 system,info device added by admin 22:49:17 system,info device changed by admin 22:49:38 bridge,info "bridge_mgmt" mac address changed to 08:55:31:EF:B0:14 22:49:38 system,info bridge port changed by admin 22:49:54 route,ospf,error Discarding packet: locally originated

На интерфейсах которые в бридже влан нужно вешать на бридж. Pvid назначать на порту при добавлении только на Access порт. Так же нужно включить vlan filtering на бридже

Спасибо. Да вроде грубых ошибок не допустил... и свитчи микроты работают. Проблема с клиентом vl_1101 возникает при добавлении vlan_mgmt в бридж на маршрутизаторе.

на схеме eth1 а в конфиге sfp1, где правда?

Mikrot_cfg - это конфиг роутера микрота Mikrot_11_cfg - это конфиг свитча микрота

если коротко, то создаете бридж, добавляете в него все физические интерфейсы через которые должны ходить виланы, создаете на бридже все виланы которые должны терминироваться на роутере, в бридже создаете все виланы, в таггед каждому добавляете интерфейсы которые должны пропускать тегированный траффик этого вилана и если вилан терминируется на роутере то добавляете еще и бридж, в бридж портс интерфейсам которые должны растегировать траффик вилана в pvid пишете id этого вилана, после всего этого включаете вилан фильтеринг на бридже и все должно заработать

Яков, Вроде не криминал не совать все в бриджи а юзать роутер как роутер, т.е. на физ интерфейсах создавать вланы и только нужное объединять в бриджи. Ща попробую дампы пособирать с свитча микротика, может там ответ найду.

Можно точно сказать что это включенный на bridge по умолчанию spanning tree на микротиках свитчах. Перевод в статус none решил проблему. Чем rstp на bridge мешал свитчевать пока не могу сказать. Может у Вас есть экспертное мнение, буду признателен и не сломаю себе голову.

Можно точно сказать что это включенный на bridge по умолчанию spanning tree на микротиках свитчах. Перевод в статус none решил проблему. Чем rstp на bridge мешал свитчевать пока не могу сказать. Может у Вас есть экспертное мнение, буду признателен и не сломаю себе голову.

Можно точно сказать что это включенный на bridge по умолчанию spanning tree на микротиках свитчах. Перевод в статус none решил проблему. Чем rstp на bridge мешал свитчевать пока не могу сказать. Может у Вас есть экспертное мнение, буду признателен и не сломаю себе голову.