Эта статья том, как перестать мучиться с сертификатами для IKEv2 и их установкой.
В Интернете есть множество статей и видео по настройке аутентификации IKEv2 с использованием сертификатов. Главная проблема такой конфигурации — необходимость генерации множества сертификатов, доставки и установки их на каждое клиентское устройство. Довольно замороченный процесс, согласитесь?
Здравствуйте коллеги! Сегодня, когда накал страстей вокруг «удалёнки» немного спал, большинство админов победило задачу удаленного доступа сотрудников к корпоративной сети, пришло время поделиться моей давней наработкой по повышению безопасности VPN. В этой статье не будет модных ныне IPSec IKEv2 и xAuth. Речь пойдет о построении системы двухфакторной аутентификации (2FA) пользователей VPN, когда MikroTik выступает в качестве VPN-сервера. А именно, когда используются «классические» протоколы типа PPP.
Наиболее часто задаваемый мне вопрос по использованию рекурсивной маршрутизации звучит так: «Что делать, если основной провайдер назначает нам ip-адрес через dhcp, при этом часто изменяется шлюз по-умолчанию?».
В марте 2018 наконец-то в продажу поступила новинка от MikroTik — hAP AC2 (в кодировке вендора RBD52G-5HacD2HnD-TC. Этот аппарат давно ждали фанаты, долго и заранее обсуждали на форумах предполагаемые эксплуатационные характеристики. Для низкой цены SOHO-сегмента, наиболее ожидаемыми были реализованные в нём:
Нечасто, но с завидной периодичностью на профильных форумах возникал один и тот же вопрос: «как на одном интерфейсе роутера MikroTik получить два IP-адреса с разными MAC?». Обычно этот вопрос остается без ответа, либо вопрошающему отвечают «никак». И действительно, задача нетривиальная. В стандартной конфигурации соблюдается правило «1 интерфейс = 1 MAC». В этой статье я расскажу как обойти это ограничение используя расширенный функционал MikroTik.
Служба обнаружения соседних маршрутизаторов и совместимого оборудования в RouterOS присутствует давно. К сожалению, над схемой функционирования “Neighbor Discovery” товарищи админы задумываются редко. Там вроде как будто всё просто, но просто не настолько как кажется.
Наглядной иллюстрацией служат неудачные попытки скрыть информацию о своём маршрутизаторе MikroTik, при этом получать инфу о маршрутизаторах соседей внутри broadcast-домена провайдера. Так сказать, подглядывать за соседями по провайдерскому свитчу. Обычно это выглядит как запрет фаерволом отправки широковещательных пакетов объявления службы discovery UDP 255.255.255.255:5678. Вбив запрещающее правило в конфиг фаервола, некоторые считают, что полностью скрыли свой маршрутизатор от видимости соседями. Но это не так.
О проблеме отсутствия функции полноценного DHCP-snooping в устройствах MikroTik уже было сказано и написано слишком много. И везде для отлова злодейских DHCP предлагают нагружать CPU. Я же расскажу, как убить чужой DHCP-сервер с помощью свитч-чипа интегрированного в коммутаторы MikroTik CRS.
