grifin.ru Опубликовано 6 января, 2020 · Жалоба 2 часа назад, grifin.ru сказал: Или "по классике" МЭ отдельно от маршрутизатора предусмотрен ? А совмещение этих функций и приводит к таким вот костылям, типа виртуальных интерфейсов ) В этом случае защищенность IPSEC маршрутизатора сводится к защищенности МЭ. Так и задумано ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
grifin.ru Опубликовано 11 апреля, 2020 · Жалоба В 02.09.2019 в 16:13, jffulcrum сказал: Нет. DNS-имя, к которому идет подключение, сверяется с полем CN сертификата сервера, если там нет полного совпадения - смотрится еще SAN. IP вообще никому не интересен при работе через DNS. Если же идет подключение именно по IP, то сверяется IP с атрибутом ipaddress в поле SAN сертификата сервера. Это если клиент понимает этот атрибут в принципе - даже у Cisco с этим были нехилые проблемы. А если он только принимает входящие подключения ? (и не имеет при этом SA Для каждого возможного подключенца (в remote address прописана подсеть) Короче задача состоит в том, чтоб прописать IP ТОЛЬКО в сертификат, и чтоб у клиента (клиент тоже микротик) не было никакой возможности "подделать" свой IP, ибо если он попытается установить соединение постучаться с "чужого" IP - будет послан, поскольку IP с которого он хочет подключиться не соответствует IP в SAN сертификата. Хочется в итоге получить сеть с "достоверными IP" построенную на микротиках. Т.е. нужно чтоб потом в SA (а следовательно в сгенерированных автоматически полисях) гаранитированно был именно тот IP адрес, на который у клиента есть сертификат. Если сертификата с таким IPшником у клиентского микротика нет - то и не сможет он SA Поднять с этого адреса. надеюсь понятно объяснил... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...