Mikrotik

Введение

Идея статьи возникла из желания пропускать определенные сайты через VPN-туннель напрямую через маршрутизатор, так как дома большое количество устройств, а пускать весь трафик через VPN неудобно в связи с низкой пропускной способностью туннеля. Статья написана сразу после создания конфигурации. Настройка будет проходить в Winbox MikroTik.

• Конфигурация StrongSwan

• Импорт сертификатов и настройка IPSec MikroTik

• Настройка маршрутизации трафика и списка ресурсов

Конфигурация StrongSwan

Здесь я рассмотрю только основные конфигурационные файлы StrongSwan, без углубления в настройку данного демона.

/etc/ipsec.conf

config setup   charondebug="ike 2, knl 2, cfg 2, net 2, esp 2, dmn 2,  mgr 2"   uniqueids=neverconn ikev2-vpn   auto=add   compress=no   type=tunnel   keyexchange=ikev2   fragmentation=yes   forceencaps=yes   dpdaction=clear   dpddelay=300s   rekey=no   left=%any   leftid=   leftcert=server-cert.pem   leftsendcert=always   leftsubnet=0.0.0.0/0   right=%any   rightid=%any   rightauth=eap-mschapv2   rightsourceip=10.10.10.0/24   rightdns=8.8.8.8,8.8.4.4   rightsendcert=never   eap_identity=%identity

/etc/ipsec.secrets

# This file holds shared secrets or RSA private keys for authentication.# RSA private key for this host, authenticating it to any other host# which knows the public part.# this file is managed with debconf and will contain the automatically created $include /var/lib/strongswan/ipsec.secrets.inc: RSA "server-key.pem"user1 : EAP "password1"user2 : EAP "password2"

iptables на VPS

-A FORWARD -s 10.10.10.0/24 -o eth0 -p tcp -m policy --dir in --pol ipsec -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360-A POSTROUTING -s 10.10.10.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT-A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT-A INPUT -i lo -j ACCEPT-A INPUT -p udp -m udp --dport 500 -j ACCEPT-A INPUT -p udp -m udp --dport 4500 -j ACCEPT-A INPUT -j DROP-A FORWARD -s 10.10.10.0/24 -m policy --dir in --pol ipsec --proto esp -j ACCEPT-A FORWARD -d 10.10.10.0/24 -m policy --dir out --pol ipsec --proto esp -j ACCEPT-A FORWARD -j DROP

Импорт сертификатов и настройка IPSec MikroTik

Импорт сертификатов

Для добавления сертификатов, необходимо перенести их в память вашего MikroTik в раздел Files.

System -> Certificates

Импортируем открытый ключ корневого сертификата вашего центра сертификации на VPS на котором установлен StrongSwan.

Последовательно импортируем открытый и закрытый ключи авторизации используемые в конфигурации StrongSwan.

Настройка клиента IPsec

IP -> IPsec

Импортируем закрытый ключ авторизации StrongSwan, для использования в клиенте.

Далее, последовательно настраиваем профиль VPN-клиента.

Вместо "VPS IP" указываем адрес вашего сервера, где развернут StrongSwan.

В разделе IPsec Idenity настраиваем профиль авторизации, указываем учётные данные и сертификат импортированный ранее.

После выполнения этого шага туннель между MikroTik и StrongSwan будет поднят автоматически.

В разделе IP -> Addresses при успешной авторизации, появится IP адрес выданный StrongSwan.

Настройка маршрутизации трафика и списка ресурсов

IP -> Firewall

В разделе NAT создаем правило перенаправления трафика.

В данном случае я использовал списки адресов.

local - подсеть маршрутизатора.

List1 - список сайтов.

Перенаправляем трафик на шлюз(IP адрес выданный StrongSwan)

Настройка списков

IP -> Firewall

В разделе Address Lists необходимо добавить следующие списки:

local - подсеть маршрутизатора, в моем случае 192.168.1.0/24

List1 - список сайтов. Например habr.com, можно добавить сайт по fqdn, ip адрес будет определён автоматически.

List1 - список сайтов. Например habr.com, можно добавить сайт по fqdn, ip адрес будет определён автоматически.

Заключение

В данной статье я постарался подробно описать настройку туннеля между MicroTik и StrongSwan. Очень жду фидбека и вашей конструктивной критики.

Одним из способов обеспечения информационной безопасности сетевых ресурсов является организация специально подготовленных для легкого взлома бочонков с медом, детектирования ими угроз, выявления и анализе соответствующих сигнатур с последующей своевременной блокировкой злоумышленников. В статье описано создания honeypot на просторах интернета программными средствами от компании MikroTik.

Философское отступление и предыстория

Серфинг в интернете стал сопряжен с государственным регулированием, выражающимся в выполнении провайдерами требований по ограничению доступа к различным сайтам. Параноики нагнетают обстановку фактом незашифрованности протокола DNS и возможностями по манипуляции с ним со стороны третьих лиц. Старый и добрый HTTP до сих пор встречается на просторах сети. И на десерт аналитика наших интересов со стороны поисковых систем, почтовых сервисов, мессенджеров, социальных сетей и различных сервисов. Как результат, большинство людей знают/слышали/пользуются VPN технологиями для сопротивления реальной глобализации современной жизни в целях защиты цифровой приватности. Темную сторону силы в расчет даже не берем и с ними отношений не имеем.

Как IT специалисты, мы не имеем морального права использовать готовые решения от не известных нам компаний из разряда нажал кнопку и ты в VPN. Нам нужен собственный центр сертификации, да и вся инфраструктура публичных ключей. Свой VPN сервер, полный root, полный контроль, абсолютная гибкость и безопасность. Большинство из нас возьмут Linux сервер и все сделают как в техническом задании. Пласт сетевых инженеров, специализирующихся на оборудовании MikroTik, с удовольствием предпочтет RouterOS, развернутый где-нибудь на VP по ряду причин:

1. Легкость интеграции в существующую инфраструктуру на базе RouterOS.

2. Наличие удобного интерфейса управления, в том числе графического.

3. Простая развертываемость различных сетевых технологий коммутации, маршрутизации, L7 и т.д.

4. Безопасность и стабильность применяемого решения.

5. Чувство эстетического удовольствия от работы с хорошими программными средствами.

6. Поддержка из коробки различных протоколов VPN (openvpn, l2tp, sstp, gre, pptp).

Реализуем облачный маршрутизатор

Развернем собственный облачный маршрутизатор MikroTik. Дешево и быстро арендуем VPS с минимальными характеристиками. Разворачиваем вместо штатного Debian свой любимый RouterOS:

mount -t tmpfs tmpfs /tmp/cd /tmpwget https://download.mikrotik.com/routeros/6.47.9/chr-6.47.9.img.zipapt install zipunzip chr-6.47.9.img.zipdd if=chr-6.47.9.img of=/dev/vda bs=4M oflag=syncecho 1 > /proc/sys/kernel/sysrq echo b > /proc/sysrq-trigger

После перезагрузки, используя VNС, настраиваем сеть, и виртуальный маршрутизатор готов к работе:

/ip address add interface=ether1 address=наш_ip/ip route add dst-address=0.0.0.0/0 gateway=gw_от_провайдера

Сразу же начался знакомый всем Linux администраторам bruteforce ssh-сервера:

... system,error,critical login failure for user root from 104.211.164.221 via ssh... system,error,critical login failure for user yu from 119.29.113.149 via ssh... system,error,critical login failure for user laboratory from 1.245.61.144 via ssh... system,error,critical login failure for user username from 36.133.162.171 via ssh... system,error,critical login failure for user test from 49.232.214.91 via ssh

В этот момент и зародилась идея создания honeypot из Cloud Hosted Router для анализа ботов, специализирующихся на зло вредительстве устройствам MikroTik. Обзорную информацию об угрозах информационной безопасности для данных устройств можно посмотреть в презентации Fools your enemy with Mikrotik.

Настройка honeypot

Для начала определим, какие возможности по записи действий злоумышленников у нас имеются в штатных средствах RouterOS:

1. Удаленное логирование.

2. Регистрация выполненных изменений конфигурации роутера.

3. Контроль проходящего через него трафика.

А вот введенные команды сохранятся, только если не будут принудительно удалены из консоли, дистанционно передавать их нельзя, хотя возможно, со слов компании, это появится в 7 версии операционной системы (на текущий момент последняя доступная версия stable релиза 6.48.1). Цитируем: By upgrading to RouterOS v7 you will get more details in this command output (речь идет об /system history print detail). Начнем сначала, для этого:

/system logging action set 3 remote=ip_удаленного_сервера/system loggingadd action=remote topics=infoadd action=remote topics=criticaladd action=remote topics=erroradd action=remote topics=hotspotadd action=remote topics=warning

Передачу логов осуществляем по vpn каналу, чтобы не передавать открытые данные в сеть. На удаленном сервере настроим лог-коллектор rsyslog, для этого отредактируем файл /etc/rsyslog.conf:

$ModLoad imudp$UDPServerAddress ip_удаленного_сервера$UDPServerRun 514

Перестартуем службу systemctl enable rsyslog, systemctl restart rsyslog. Прослушиваем только vpn интерфейс, чтобы не светить 514 хоть и UDP портом наружу. Удаленный лог будет выглядеть примерно так:

2021-03-24T20:46:02.608642+06:00 ip_роутера system,error,critical login failure for user root from 45.124.86.155 via ssh2021-03-24T20:51:46.427403+06:00 ip_роутера system,error,critical login failure for user root from 193.112.24.94 via ssh2021-03-24T20:52:48.378138+06:00 ip_роутера system,error,critical login failure for user ts3srv from 107.173.209.238 via ssh2021-03-24T20:53:02.692985+06:00 ip_роутера system,error,critical login failure for user root from 61.7.147.29 via ssh2021-03-24T20:53:15.616354+06:00 ip_роутера system,error,critical login failure for user user14 from 68.183.84.215 via ssh2021-03-24T20:53:54.436415+06:00 ip_роутера system,error,critical login failure for user root from 52.172.165.176 via ssh2021-03-24T20:53:56.684200+06:00 ip_роутера system,error,critical login failure for user php from 189.8.95.30 via ssh

Регистрацию выполненных ботом изменений конфигурации роутера будем осуществлять в результате регулярного экспорта всех конфигураций в собственную память, а забирать файлы будем автоматически скриптом на VPS по ftp, разумеется так же через vpn канал (/ip service set ftp address=ip_удаленного_сервера). Для этого делаем планировщик на MikroTik с регулярным заданием: /export compact file=file. А на сервере запустим скрипт:

#!/bin/shHOST=ip_роутераUSER=adminPASSWD=суровый_пароль_настоящего_админаFILE=file.rscSIZE=2091cwhile true; doOUTPUTNAME=`date +%F-%H-%M-%S`.rcscurl -u $USER:$PASSWD ftp://$HOST/$FILE > /root/exports/$OUTPUTNAMEfind /root/exports/ -type 'f' -size 0 -deletefind /root/exports/ -type 'f' -size $SIZE -deletesleep 5;done

В переменой SIZE лежит размер файла экспорта после всех наших манипуляций с honeypot. Если злоумышленник изменит любую конфигурацию, то результатом экспорта будет файл не много другого размера. Таким образом, на удаленном сервере в папке /root/exports окажется что-то новенькое. Так как наш удаленный лог начнет забиваться сообщениями о работе задания в планировщике, поэтому донастроим конфигурацию rsyslog (файл /etc/rsyslog.conf):

if $fromhost-ip contains 'ip_адрес_роутера' then {        if $msg contains 'ftp' then /dev/null        else /var/log/mikrotik.log}

Для контроля проходящего через роутер трафика можно использовать разные подходы. Это и маркировка трафика с последующим снифером, настройка net-flow клиента, но мы воспользуемся самым простым встроенным приложениемpacket-sniffer:

/tool snifferset filter-interface=ether1 filter-port=!ssh,!winbox,!ftp,!наш_порт_для_vpn \    filter-stream=yes memory-scroll=no streaming-enabled=yes \    streaming-server=ip_удаленного_сервера

Пропускать мимо снифера будем шифрованный vpn, ssh и winbox, а также задействованный нами ftp. Трафик будет отправляться UDP пакетами по протоколу Tazmen Sniffer Protocol (TZSP), принять его на сервере можно вместе со служебными заголовками обычным tcpdump-ом, или в уже красивом и удобном виде, используя программу Trafr непосредственно от компании MikroTik. Подробнее как все настроить можно почитать здесь.

Теперь перейдем к ключевому моменту. Для того, чтобы honeypot не натворил плохих дел будем постоянно анализировать внутренний лог RouterOS на факт подключения "учетной записи приманки" пользователя root с паролем qwerty (построчно перебирать лог и искать ключевую фразу user root logged in). Как только это произойдет, включаем обратный отчет и сразу начинаем снифить трафик. Через 10 минут (по нашему мнению этого времени будет достаточно, чтобы проанализировать действия и не достаточно, чтобы сообразить осуществить плохие делишки) просто выключаем маршрутизатор, и бот на это повлиять не сможет:

:local DELAY 600;:local USER root;:local STRING "user $USER logged in";:foreach line in=[/log find message~$STRING] do={if ([ /tool sniffer get running] = no) do={/tool sniffer start;}:delay $DELAY;/system shutdown;}

Не забудем очистить консоль от введенных нами команд /console clear-history. Можно настроить удаленное оповещение о факте доступа к нашему honeypot посредством, например, email, но не будем оставлять какой-либо приватной информации на маршрутизаторе. Контролировать будем в ручную через нативное приложение на телефоне. Если подключение не прошло, значит root все-таки зашел на honeypot, следовательно настало время изучать трафик и логи. При повторной загрузке (после срабатывания) не забываем сразу отключить учетную запись - приманку:

sshpass -p суровый_пароль_настоящего_админа ssh admin@ip_роутера /user disable root

Удачной охоты на ботов!

P.S. В конце 2020 года нами был реализован проект по организации общественного доступа в Интернет для международной компании Coffee Сup: 5 собственных баров формата кофе с собой в разных городах, а так же дилеров по всей России и странах СНГ(до последних руки не дошли). Что вполне не удивительно, но среди клиентов Hotspot сетей находятся не чистые на руку, пытающиеся получить доступ до маршрутизаторов. Интересно, так сказать, узнать их "в лицо"...

Недавно мне посчастливилось заняться достаточно интересной практической задачей по организации общественного доступа в Интернет для международной компании Coffee Сup, имеющей 5 собственных баров формата кофе с собой в разных городах, а так же дилеров по всей России и странах СНГ. Нужно все сделать, так как мы любим: желательно быстро и достаточно качественно. Гостевой доступ в Интернет организуется не только ради удобства пользователей сервиса, но и, в первую очередь, с точки зрения пользы для бизнеса: принудительно смотришь рекламу и получаешь свой бесплатный Интернет. В наше время, это уже абсолютно повсеместный сервис, встречаемый от метро и аэропортов, до торговых центров и других общественных площадок. Этими удаленными осенними вечерами родилось решение сделай все своими руками, поэтому делюсь опытом и практическими наработками. Сразу забегу вперед, стоимость решения на один бар вышла 3700 рублей за оборудование и совсем немного сверху в счет аренды сервера. Но вернемся к нашей задаче.

С чего мы начали, так это с поиска готовых решений на рынке. С этим нет проблем, поддержка различного оконечного оборудования, дружественный интерфейс по его подключению на аутсорсинг, обещанная гарантия, что все по закону, всего 1000 рублей в месяц абонентской платы за каждое подключение. А для Coffee Сup это уже 5000 рублей/месяц, что равно 60000 рублей/год (не считая оборудование). Поиском готовых аппаратно-программных реализаций даже не занимались полная скука, даже можно сказать осенняя хандра. В общем, не наш метод. Надо во всем самим разобраться и все сделать самому.

Для начала была проведена декомпозиция и детализация задачи:

1. Разобраться в нормативно-правовых актах, чтобы все было по закону.

2. Выбрать и закупить необходимое оборудование.

3. Настроить и интегрировать оборудование в уже существующую инфраструктуру баров.

4. Настроить Hotspot (сконфигурировать роутеры и сделать страницы авторизации на сервисе под задачи маркетинга).

5. Настроить централизованное управление (удаленное управление маршрутизаторами, базу данных, backend и frontend).

Нормативно-правовые акты

Обо всем по порядку. Нам нужны постановления правительства России и от 31 июля 2014 г. 758 О внесении изменений в некоторые акты и от 12 августа 2014 г. 801 О внесении изменений в некоторые акты . Одно дополняет второе, как видно, между ними успело пройти целых 2 недели. В соответствии с ними (немного перефразировано для большей ясности):

при оказании универсальных услуг связи по передачи данных и предоставлению доступа к сети Интернет с использованием пунктов коллективного доступа, мы обязаны идентифицировать пользователей в результате достоверного установления абонентского номера, назначенного пользователю.

Это единственно приемлемое решение в настоящее время, все остальные предлагаемые законом решения нам явно не подходят (паспорта, госуслуги и т.д.). Цитируем снова:

сведения о пользователях , а также об объеме и времени оказания им услуг связи хранятся не менее 6 месяцев.

Что понимать под объемом оказания им услуг связи мы решили уточнить у роскомнадзора, написали им письмо и ничего до сих пор не получили в ответ. Остается на наше усмотрение: под объемом будем понимать результаты NetFlow (сбора информации об открытых пользователями соединениях, подробнее можно прочитать на https://en.wikipedia.org/wiki/NetFlow).

С этим разобрались, уже хорошо. Дошло дело до всеми любимого федерального закона от 27 июля 2006 г. 152-ФЗ О персональных данных. Закон в принципе понятный, уже обкатанный вдоль и поперек, технически сложного он ничего не содержит сплошная организационная рутина: согласия, политики, приказы и т.д. Попадаем ли мы со своим Hotspot под его действие? Ведь мы будем хранить просто номера телефонов Ответ не попадаем. Точку в этом вопросе в настоящее время ставит роскомнадзор на своем сайте в разделе вопросов и ответов (https://15.rkn.gov.ru/p8880/p15987/):

Согласно ст. 3 Федерального закона от 27.07.2006 152-ФЗ О персональных данных

Персональные данные - любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных). Абонентский номер (номер телефона) это выделяемый абоненту номер, (совокупность цифровых знаков) при заключении с абонентом договора об оказании услуг телефонной связи. Данный номер служит для обозначения и возможности идентификации конечного оборудования абонента в сети связи при соединении с ним абонентских устройств из чего следует, что номер телефона без указания на его владельца не является информацией, на основании которой это лицо (субъекта персональных данных) можно однозначно идентифицировать и его использование не может подразумевать обработку персональных данных его владельца.

Оборудование

Приступаем к технической части. В качестве оборудования было решено приобретать роутеры MikroTik по следующим причинам: поддерживают технологию Hotspot, отличное качество, высокая гибкость, дружелюбные русскоязычные сообщества. Самое главное, наличие возможности работы в диапазоне 2.4 и 5 ГГц, чтобы нашему WiFi никто не мешал. Выбрали hAP ac lite TC (подробно про него можно посмотреть на сайте производителя https://mikrotik.com/product/RB952Ui-5ac2nD-TC, в характеристиках нам все нравится, особенно Operating System RouterOS). 3700 рублей каждый, отличная цена. Из рекомендаций вполне можно приобретать изделия, бывшие в употреблении, рынок в Москве наиболее насыщенный и приятный по ценам, а доставка сейчас работает отлично в любой регион. Арендовали в Интернете Linux сервер, особо каких-то требований к этому вопросу тоже не предъявляли.

Интеграция

Все бары уже имели подключение к Интернет. Везде по-разному, где-то стоял 4G USB модем в другом роутере, где-то использовался мобильный WiFi роутер со встроенным аккумулятором. Изменять существующую инфраструктуру было запрещено из-за боязни, что что-нибудь перестанет безвозвратно работать, а все переделывать и безосновательно финансово удорожать проект не хотелось. MikroTik везде интегрировался без проблем. Например, покажем как настроено получение Интернет по WiFi (как настроено это дело по кабелю от другого роутера или через 4G USB модем оставлю без комментариев):

/interface wireless security-profiles set [ find default=yes ] supplicant-identity=MikroTikadd authentication-types=wpa2-psk disable-pmkid=yes eap-methods="" group-ciphers=tkip mode=dynamic-keys name=OPERATOR supplicant-identity="" unicast-ciphers=tkip wpa2-pre-shared-key=1111111111111/interface wireless set [ find default-name=wlan1 ] band=2ghz-onlyn country=russia disabled=no frequency=auto name=wlan1-station security-profile=OPERATOR ssid=OPERATOR-9392 station-roaming=enabled

Добавили скрипт в dhcp-client и скорректировали работу своего NAT (можно было бы настроить masquerade, однако вспомнили презентацию технического специалиста компании MikroTik My holy war against masquerade, а также, что masquerade частный случай SRC-NAT и отказались от этой идеи):

/ip firewall natadd action=src-nat chain=srcnat comment=OPERATOR-NAT out-interface=wlan1-station src-address=192.168.2.0/24 to-addresses=10.0.0.100add action=src-nat chain=srcnat comment=HOME-NAT out-interface=wlan1-station src-address=192.168.1.0/24 to-addresses=10.0.0.100/ip dhcp-clientadd disabled=no interface=wlan1-station use-peer-dns=no use-peer-ntp=no#Script for src-NAT:local OUTINTERFACE wlan1-station;:local COMMENT OPERATOR-NAT;:local COMMENT2 Home-NAT;:local IPFORNAT [/ip dhcp-client get [find interface=$OUTINTERFACE] address];#delete mask in ip:local IPFORNATSHORT [:pick $IPFORNAT 0 [:find $IPFORNAT "/"]];/ip firewall nat set [find comment=$COMMENT] to-addresses=$IPFORNATSHORT;/ip firewall nat set [find comment=$COMMENT2] to-addresses=$IPFORNATSHORT;

Интернет до MikroTik-ов получили, далее настроили качественно и безопасно наши роутеры в качестве точки доступа. Опишем только интересное. Сделали два профиля безопасности для WiFi (free и staff), включили сразу 3 WiFi сети: две для staff (для обоих диапазонов 2.4 и 5 ГГц, так как не все оборудование в барах умеет работать в 5 ГГц) и одну free (только на 5 ГГц). На 2.4 ГГц free решили не делать, так как приоритет отдан предоставлению Интернет пользователям с современными мобильниками, и кроме того наши роутеры умеют делать до 4 точек доступа одновременно. Рекомендовали барам все оборудование переподключить на staff, так как позже была задана приоритезация трафика в маршрутизаторах, а это значит, что никто из гостей нам не провалит "служебный" Интернет. В настройках WiFi оставили много параметров по-умолчанию, чтобы поддерживать максимальный парк подключаемых устройств. Важно помнить, что беспроводной интерфейс, выступающий в качестве клиента WiFi (через который мы забираем Интернет), должен быть обязательно master.

/interface wireless security-profilesset [ find default=yes ] supplicant-identity=MikroTikadd authentication-types=wpa-psk,wpa2-psk eap-methods="" management-protection=allowed name=coffeecup_free supplicant-identity=""add authentication-types=wpa2-psk disable-pmkid=yes eap-methods="" management-protection=allowed mode=dynamic-keys name=coffeecup_staff supplicant-identity="" wpa2-pre-shared-key=2222222222222/interface wirelessset [ find default-name=wlan1 ] antenna-gain=0 band=2ghz-g/n channel-width=20/40mhz-XX country=russia disabled=no frequency=auto frequency-mode=manual-txpower installation=indoor mode=ap-bridge name=wlan1-COFFEECUP_2_staff security-profile=coffeecup_staff ssid=CoffeeCup_Staff2 station-roaming=enabled wireless-protocol=802.11 wps-mode=disabledset [ find default-name=wlan2 ] antenna-gain=0 band=5ghz-n/ac channel-width=20/40/80mhz-XXXX country=russia disabled=no frequency=auto frequency-mode=manual-txpower installation=indoor mode=ap-bridge name=wlan2-COFFEECUP_5_staff security-profile=coffeecup_staff ssid=CoffeeCup_Staff station-roaming=enabled wps-mode=disabledadd default-forwarding=no disabled=no keepalive-frames=disabled mac-address=02:00:00:AA:00:00 master-interface=wlan2-COFFEECUP_5_staff multicast-buffering=disabled name=wlan3-COFFEECUP_5 security-profile=coffeecup_free ssid=CoffeeCup_FreeWiFi wds-cost-range=0 wds-default-cost=0 wps-mode=disabled

Настроили firewall, обязательно сделали отдельное правило для icmp (чтобы не было скрытых проблем с раздачей Интернет от вышестоящих маршрутизаторов) и заложили будущий VPN. Пример для 4G свистка:

/ip firewall filteradd action=accept chain=input comment="Accept established,related" connection-state=established,relatedadd action=drop chain=input comment="Drop invalid" connection-state=invalidadd action=accept chain=input comment="Accept input icmp" protocol=icmpadd action=accept chain=input comment="Accept input ovpn" in-interface=ovpn-coffeecupadd action=accept chain=input comment="Accept input DNS for bridge_guest" dst-port=53 in-interface=bridge_guest protocol=udpadd action=drop chain=input comment="Drop all input from !bridge" in-interface=!bridgeadd action=accept chain=forward comment="Accept established,related" connection-state=established,relatedadd action=drop chain=forward comment="Drop invalid" connection-state=invalidadd action=drop chain=forward comment="Drop all from WAN to !DSTNAT" connection-nat-state=!dstnat connection-state=new in-interface=LTE1_WAN

Qos выполнили через маркировку трафика, скоростные лимиты выбрали из реальных измерений (мы использовали сервис от Яндекс Интернетометр):

/ip firewall mangleadd action=mark-connection chain=prerouting comment="Managment connections" dst-address=192.168.15.21 dst-port=22,8291 new-connection-mark="Managment connections" passthrough=yes protocol=tcpadd action=mark-connection chain=forward comment="VIP connection" connection-mark=no-mark new-connection-mark="VIP connection" passthrough=yes src-address-list=VIPadd action=mark-packet chain=forward comment="VIP packets" connection-mark="VIP connection" new-packet-mark="VIP packets" passthrough=yesadd action=mark-connection chain=forward comment="LAN=>WAN connections" connection-mark=no-mark in-interface=bridge new-connection-mark="LAN=>WAN connections" out-interface=LTE1_WAN passthrough=yesadd action=mark-packet chain=forward comment="LAN=>WAN packets" connection-mark="LAN=>WAN connections" new-packet-mark="LAN=>WAN packets" passthrough=yesadd action=mark-connection chain=forward comment="Guest=>WAN connections" connection-mark=no-mark in-interface=bridge_guest new-connection-mark="Guest=>WAN connections" out-interface=LTE1_WAN passthrough=yesadd action=mark-packet chain=forward comment="Guest=>WAN packets" connection-mark="Guest=>WAN connections" new-packet-mark="Guest=>WAN packets" passthrough=yesadd action=mark-packet chain=output comment="Managment packets" connection-mark="Managment connections" new-packet-mark="Managment packets" passthrough=yesadd action=mark-connection chain=postrouting comment="OVPN connections" dst-address=IP_OUR_SERVER dst-port=1190 new-connection-mark="OVPN connections" out-interface=LTE1_WAN passthrough=yes protocol=tcpadd action=mark-packet chain=postrouting comment="OVPN packets" connection-mark="OVPN connections" new-packet-mark="OVPN packets" passthrough=yes/queue treeadd comment="Guest (bridge-guest)" max-limit=10M name=Guest parent=bridge_guestadd comment="LAN (bridge)" max-limit=10M name=LAN parent=bridgeadd comment="WAN (pppoe)" max-limit=10M name=WAN parent=LTE1_WANadd name=Guest_other packet-mark=no-mark parent=Guestadd name="LAN_LAN=>WAN" packet-mark="LAN=>WAN packets" parent=LANadd limit-at=128k max-limit=512k name=LAN_managment packet-mark="Managment packets" parent=LAN priority=1add name=LAN_other packet-mark=no-mark parent=LANadd name=LAN_ovpn packet-mark="OVPN packets" parent=LANadd name=LAN_vip packet-mark="VIP packets" parent=LAN priority=7add name="WAN_Guest=>WAN" packet-mark="Guest=>WAN packets" parent=WANadd name="WAN_LAN=>WAN" packet-mark="LAN=>WAN packets" parent=WAN priority=7add name=WAN_ovpn packet-mark="OVPN packets" parent=WAN priority=7add name=WAN_vip packet-mark="VIP packets" parent=WAN priority=6add name="Guest=>WAN" packet-mark="Guest=>WAN packets" parent=Guest queue=pcq-download-default

Задействовали семейные DNS сервера от Яндекса: все-таки рабочий Интернет, да и место общественное.

/ip dns set allow-remote-requests=yes servers=77.88.8.7,77.88.8.3

На практике было установлено, что некоторые провайдеры блокируют использование не своих DNS-серверов. Чтобы решить это, можно получать адреса DNS серверов от вышестоящего маршрутизатора при работе DHCP-клиента (активация use-peer-ntp) или вложить свои DNS запросы в VPN туннель, а на арендуемом сервере настроить NAT и включить ip forward:

#На роутере:/ip routeadd distance=1 dst-address=77.88.8.3/32 gateway=192.168.15.1add distance=1 dst-address=77.88.8.7/32 gateway=192.168.15.1#На сервере:iptables -t nat -A POSTROUTING -s 192.168.15.0/24 -o eth0 -j SNAT --to your_server_ipecho '1' > /proc/sys/net/ipv4/ip_forward

Hotspot

Настало время настройки технологии Hotspot непосредственно на роутерах. MikroTik из коробки поддерживает саму технологию, однако мы ее кастомизировали под "Coffee Cup", а также выполнили все требования российского законодательства. В процессе был найден полезный ресурс (https://mikrotik-training.ru/), посвященный настройке оборудования MikroTik, наработками которого мы воспользовались в своем проекте. Приступим к описанию. Создали профиль для Hotspot. При подключении к сети free роутер показывает web страницы авторизации в сервисе Hotspot от имени сайта coffeecuptogo.com, время жизни cookie задали 4 часа (по истечении которых пользователя отправляются на переподключение). Работа технологии Hotspot, разумеется, касается только гостевой сети.

/ip hotspot profileset [ find default=yes ] dns-name=coffeecuptogo.com hotspot-address=192.168.10.1 html-directory=flash/hotspot http-cookie-lifetime=4h name=coffeecup/ip hotspotadd address-pool=pool_guest addresses-per-mac=1 disabled=no idle-timeout=none interface=bridge_guest name=hotspot_coffeecup/ip hotspot user profileset [ find default=yes ] keepalive-timeout=1h mac-cookie-timeout=4h

Здесь же в профиле пользователей создали скрипты, которые автоматически срабатывают при подключении и отключении пользователей. Логика у обоих скриптов одинаковая. Сначала собирается информацию на роутере, затем она отправляется методом http-get на наш сервер, на котором все это аккумулируется в базу данных (разберем ее позднее). Для защиты своего сервера от спама придумали ключ, который также передается и, в первую очередь, проверяется на сервере. На роутере собирается: имя роутера (для каждого бара задали его индивидуально), текущее время и дата на роутере (удобно их забирать здесь, а не получать на сервере, чтобы не заморачиваться потом в backend-е с часовыми поясами в разных барах), mac гостя, его ip в гостевой сети, а также текущие белый и серый ip адреса роутера (белый адрес мы берем через внешний сервис, хотя нет проблем его забирать на нашем сервере через массив $_SERVER в PHP, на котором написан наш backend), номер телефона клиента, который мы позже будем получать через форму авторизации в Hotspot и присваивать его значение в качестве имени пользователя (на сервер отправляется с первой цифрой 7), а также имя хоста телефона (может потом пригодится где-нибудь в маркетинге или статистике). Кстати новые версии iOS при подключении к точке доступа без пароля не передают имя хоста, что реализовано с целью сохранения конфиденциальности. Переменной LOGIN мы передаем отключился (LOGIN=2) ли клиент или наоборот подключился (LOGIN=1). Скрипт для аутентификации имеет вид:

#Out interface to internet:local INTERNETINTERFACE pppoe-out1;:local APIKEY 12345;#status ---> log in:local LOGIN 1;:local SITE oursite;:local PORT 1500;:local nas [/system identity get name];:local today [/system clock get date];:local time1 [/system clock get time ];:local ipuser [/ip hotspot active get [find user=$user] address];:local usermac [/ip hotspot active get [find user=$user] mac-address]:local hour [:pick $time1 0 2]; :local min [:pick $time1 3 5]; :local sec [:pick $time1 6 8];:set $time1 [:put ({hour} . {min} . {sec})] :local mac1 [:pick $usermac 0 2];:local mac2 [:pick $usermac 3 5];:local mac3 [:pick $usermac 6 8];:local mac4 [:pick $usermac 9 11];:local mac5 [:pick $usermac 12 14];:local mac6 [:pick $usermac 15 17];:local USERLONG "7$user";:set $usermac [:put ({mac1} . {mac2} . {mac3} . {mac4} . {mac5} . {mac6})]#ip addresses::local whiteip ([/tool fetch url="http://personeltest.ru/aways/site_for_white_ip/" output=user as-value]->"data");:local grayip [/ip address get [find interface=$INTERNETINTERFACE] address];#delete mask in ip:local grayipshort [:pick $grayip 0 [:find $grayip "/"]];#What host-name:foreach i in=[/ip dhcp-server lease print as-value where address=$ipuser] do={:if (($i->"address")=$ipuser) do={:set $host [($i->"host-name")];}}do {/tool fetch url="http://personeltest.ru/aways/$SITE:$PORT/\?api=$APIKEY&device=$nas\&tel=$USERLONG\&status=$LOGIN\&ipgray=$grayipshort\&ipnat=$ipuser\&mac=$usermac\&date=$today\&time=$time1\&host=$host"\keep-result=no} on-error={};

Скрипт для деаутентификации имеет вид:

#Out interface to internet:local INTERNETINTERFACE pppoe-out1;:local APIKEY 12345;#status ---> log out:local LOGIN 2;:local SITE oursite;:local PORT 1500;:local nas [/system identity get name];:local today [/system clock get date];:local time1 [/system clock get time ];:local hour [:pick $time1 0 2]; :local min [:pick $time1 3 5];:local sec [:pick $time1 6 8];:set $time1 [:put ({hour} . {min} . {sec})] :local USERLONG "7$user";#ip addresses::local whiteip ([/tool fetch url="http://personeltest.ru/aways/site_for_white_ip/" output=user as-value]->"data");:local grayip [/ip address get [find interface=$INTERNETINTERFACE] address];#delete mask in ip:local grayipshort [:pick $grayip 0 [:find $grayip "/"]];do {/tool fetch url="http://personeltest.ru/aways/$SITE:$PORT/\?api=$APIKEY&device=$nas\&tel=$USERLONG\&status=$LOGIN\&ipgray=$grayipshort\&date=$today\&time=$time1"\keep-result=no} on-error={};

О том, что мы сохраняем и можем использовать в маркетинговых целях информацию о наших клиентах, а также конкретно какую именно информацию и пользовательское согласие на это, мы оформили в политике конфиденциальности, показываемой на странице авторизации в Hotspot. Теперь разберем сердце нашего сервиса, а именно скрипт, который будет автоматически выполняться на роутере каждые 10 секунд (через scheduler, разумеется). Для его работы донастроили логирование:

/system logging add action=hotspot topics=hotspot,debug,info,!account/system logging action add name=hotspot target=memory

Наш скрипт обнаруживает в логе MikroTik сообщение с темой hotspot со словами login failed. Эти записи будут появляться автоматически. Со стороны клиента это выглядит так: загрузилась форма авторизации на Hotspot, пользователь ввел свой телефонный номер, нажал кнопку получить пароль, в течение 10 секунд ему приходит пароль посредством SMS, пользователь вводит этот пароль и получает Интернет. На роутере это выглядит немного по-другому: произошла попытка авторизации на сервисе Hotspot неизвестного пользователя (ошибка login failed), скрипт получает имя этого пользователя (из того же лога) и его короткий пароль посредством http-get на наш backend (на сервере генерируются случайные пароли в нужном нам формате, опишем это позже), создает такого пользователя Hotspot, отправляет номер телефона и пароль методом http-get в SMS центр (который пересылает пароль на номер пользователя) и очищает лог с темой hotspot (уменьшает его до 1 строки и сразу увеличивает до 1000 строк). Случайный пароль генерируется на сервере, потому что RouterOS не имеет встроенной функции генерации случайных чисел, а самодельные решения из математических операций со временем (и т.п.) не всегда дают нужный результат. Создание такого механизма на MikroTik заслуживает независимого исследования. Кроме этого сделали защиту от пользователей, которые попытаются получить много SMS (и обнулить наш счет в SMS центре). Для этого воспользовались не по назначению возможностями firewall, а именно адрес листом. Каждого пользователя Hotspot (фактически его номер телефона) скрипт записывает в /ip firewall address-list на 5 минут, а при попытке аутентификации на Hotspot, проверяет, нет ли там такого пользователя. Побочным явлением этого решения является появление посторонних записей в address-list попытка RouterOS определить IP адрес для каждой DNS записи. Просто не обращаем на это внимание. В качестве SMS центра выбран sms.ru, так как у заказчика уже был с ними договор и оформлены все необходимые документы, в следствие чего уже был закреплен корректный caller id Coffee Cup (в качестве номера телефона, от имени которого приходят SMS).

:local SITE oursite;:local PORT 1500;:foreach line in=[/log find buffer=hotspot message~"login failed"] do={:do {:local content [/log get $line message];:local pos1 [:find $content " (" 0];:if ($pos1 != " ") do={:local uname ""; :set uname [:pick $content ($pos1-10) ($pos1-0)];   :local unameforsms "7$uname";#Cheks user from spam:local sendtest yes;:foreach i in=[/ip firewall address-list print as-value where list=spam_cheks_list] do={:if (($i->"address")=$uname) do={:set $sendtest no;}}:if ($sendtest=yes) do={/ip firewall address-list add list=spam_cheks_list address=$uname timeout=00:05:00;#Password generation local pass ([/tool fetch url="http://personeltest.ru/aways/$SITE:$PORT" output=user as-value]->"data")#Add hotspot userdo {/ip hotspot user add name=$uname} on-error={};do {/ip hotspot user set password=$pass numbers=[find name=$uname]} on-error={};#SMSdo {/tool fetch url="http://personeltest.ru/aways/sms.ru/sys/send.php\?AUTH_DATA&phones=$unameforsms&mes=$pass" keep-result=no} on-error={}; :delay 1;}}}}#Clear hostpot log/system logging action set hotspot memory-lines=1;:delay 1;/system logging action set hotspot memory-lines=1000;

Российское законодательство обязывает нас сохранять объем оказания пользователям услуг связи, поэтому настроили связку коллектора и клиента Net-flow. На сервере с backend-ом:

apt install flow-toolsnano /etc/flow-tools/flow-capture.conf#comment all#IMPORTANT Traffic Flow Version need 5 !!-w /var/log/flow -n 275 -N 3 192.168.15.1/0/1234

На MikroTik (обращаем внимание на версию 5 протокола, так как коллектор работает именно с ней):

/ip traffic-flow set enabled=yes interfaces=bridge_guest/ip traffic-flow target add dst-address=192.168.15.1 port=1234 version=5

Кроме этого с целью сохранения конфиденциальности от третьих лиц (в том числе провайдера Интернет) передачу Net-flow трафика осуществляем по VPN каналу (ширины его полностью хватает для этой задачи). Настало время разобраться с формой авторизации в сервисе. При создании Hotspot в RouterOS появляется набор каталогов и файлов, отвечающих за его работу. Нас интересуют файлы /flash/hotspot/login.html и /flash/hotspot/alogin.html. Первый это страница авторизации на сервисе, а вторая это страница, которая будет показана пользователю после успешной авторизации. Подробнее об этом можно почитать тут https://wiki.mikrotik.com/wiki/Manual:Customizing_Hotspot.

Сверстали (переделали) login.html под заказчика, сохранили необходимую RouterOS структуру web страницы. Подробно расписали политику конфиденциальности.

Очень хотелось на странице alogin.html просто сделать редирект на сайт заказчика, но у этого решения есть большой минус: сайт подгружается не моментально (временная задержка на редирект, да и скорость Интернета не всегда достигает отличных значений). Если сверстать эту страницу и положить ее в память роутера, то она будет показана пользователю моментально. То, что мы и сделали. Единственное ограничение - это объем страницы, ведь в нашем маршрутизаторе всего 16 Мб памяти и львиную ее долю забирает созданная RouterOS структура файлов и каталогов Hotspot. Можно, конечно, присоединить USB flash, но не очень хочется занимать свободный (не всегда) единственный USB порт на MikroTik. Мы уместили alogin.html со всеми ссылками в 500 кб. На этом настройка Hotspot закончена, настал черед разобрать backend.

Управление

Начнем с сервера. На нем работает база данных MySQL, в которую накапливается информация о регистрациях пользователей в Hotspot, передаваемая скриптами роутеров. Принимается и сохраняется в базу данных информация посредством backend страницы на PHP, она же генерирует пароли для пользователей. Создали админку для заказчика и прокинули VPN до роутеров (надо же их администрировать кому-то). Теперь подробнее.

Как мы помним, маршрутизаторы передают нам: имя роутера, текущее время и дату, mac гостя, его ip в гостевой сети, а также текущие белый и серый ip адреса роутера, номер телефона клиента, имя хоста телефона и статус (авторизация или деавторизация). Все это аккумулируется в таблице registration. Информацию о барах (имя устройства MikroTik и описательная информация о его расположении) накапливается в таблице coffeepoints (здесь нам все сразу известно). По просьбе заказчика ввели излишнюю таблицу users, в которой накапливается информация о пользователях сервиса: номер телефона, и в каком баре впервые он появился. Создали техническую таблицу status, в которой переводится придуманные нами коды 1 или 2 в значения login и logout. Для резервного копирования базы данных лучше, конечно, настроить автоматическую репликацию, однако в связи с не большими объемами хранения информации в нашем проекте мы пошли другим путям: в cron еженедельно выполняется mysqldump базы данных, результаты периодически копируются в ручную на локальный хост.

Разберем одностраничный код backend. В общем виде там все работает так: проверяется корректность передаваемого на сервер APIKEY, если все верно, тогда наполняется база данных. Сначала извлекается из базы данных информация, описывающая бар. Затем проверяется, новый ли пользователь пришел в бар (в этом случае заполняется таблица users), или информация о нем уже содержится в базе данных. Переводятся в текст коды status. Затем вся необходимая информация заполняется в таблицу registrations. Если APIKEY не передавался (или не верен), то просто генерируется случайный пароль.

//Проверка корректности ключаif ( $key_from_get === $api ) {Защита от спама пройдена}else {//Выводим просто временный пароль$pas1d = random_int (0, 9);$pas2d = random_int (0, 9);$pas3d = random_int (0, 9);$pas4d = random_int (0, 9);$password = "$pas1d$pas2d$pas3d$pas4d";echo $password;}

Осталось поговорить про админку, с которой заказчик сможет работать самостоятельно. Можно, конечно, просто установить на сервер готовые решения по работе с базой данных посредством web интерфейса (вроде phpmyadmin или adminer), но мы сделали все под ключ. Так как web дизайн это не наш конек, да и интереса к нему особо нет, то воспользовались нашим любимым getbootstrap.com. На выходе - строгий адаптивный frontend. В разделе Регистрации отображается журнал регистраций в сервисе, т.е. таблица registrations базы данных.

В разделе Пользователи видим информацию из таблицы users, в разделе Бары из coffeepoints, в разделе Статусы из status, а раздел Подключения введен для отладки. Поля дата и время передаются роутерами не в совсем красивом формате, что можно преобразовывать на нашем backend, но на функционал это не сильно влияет. Добавили возможность фильтровать вывод, а также экспорт в "MS Exel". Да и вообще здесь можно писать код в свое удовольствие, с делом и просто так. Не судите строго.

Пару слов о настройке VPN. Разумеется, VPN сервер вертится здесь же на арендуемом сервере (вот такой комбайн вышел), в качестве протокола выбран OpenVPN, как наиболее гибкий, безопасный и стабильный. С его настройкой нет никаких проблем: сделали инфраструктуру открытых ключей, нагенерировали сертификатов, самоподписали их. RouterOS, правда, умеет пока работать только с TCP соединением для OpenVPN, но это не беда. В целом, соединения устанавливаются и работают годами без проблем. В результате имеем удаленный доступ до роутеров из любой точки мира, самое главное не забываем работать в Safe mode (режим MikroTik, при котором в случае долгого обрыва канала управления маршрутизатор автоматически отменяет последнее изменение своей конфигурации), ведь настраивать удаленно firewall - это верная примета к дальней поездке. А также обращаем внимание на то, что по нашей ошибке при переносе настроенных конфигураций между роутерами, возможно совпадение mac адресов сетевых интерфейсов, что может доставить немного хлопот.

Заключение

Наконец наша статья подошла к концу. Опираясь на имеющиеся в Интернете наработки, мы самостоятельно запустили сервисы Hotspot для баров компании Coffee Сup, функционирующих в рамках действующего российского законодательства, используя силу оборудования MikroTik, мощь PHP и универсальность MySQL. Не боимся экспериментировать и разбираться с разными технологиями. Всех с наступающим 2021 годом!

Стояла задача объединить филиалы с головным офисом предприятия, где находилась серверная. Fortigate 60E организовывал доступ в интернет и выполнял роль межсетевого экрана в головном офисе, в филиалах выполняли роль доступа в интернет Микротик разных моделей. Также было необходимо настроить динамическую маршрутизацию OSPF и поднять IPsec VPN туннели с GRE. Порыскав на просторах интернета, нашел пару разрозненных статей о соединении Fortigate c микротик через IPsec VPN и GRE туннель. Решил объединить эту информацию в одной своей статье, чтобы в дальнейшем самому использовать как шпаргалку. О динамической маршрутизации OSPF напишу в следующей статье.

Итак, входные данные:

1.Головной офис предприятия HQ FortiOS 6.4.5:

• Публичный IP X.X.X.X (сетевой интерфейс port1)

• Внутренняя сеть 192.168.111.0/24 (сетевой интерфейс port2)

2.Филиал предприятия Branch Mikrotik RouterOS 6.48.1:

• Публичный IP Y.Y.Y.Y сетевой интерфейс ether1

• Внутренняя сеть 192.168.112.0/24 (сетевой интерфейс ether2)

На рис. схематично показано подключение главного офиса и филиала.

Опущу основный настройки Fortigate и mikrotik, эта информация есть в интернете, сразу приступим к настройкам IPsec и GRE. Начнем настройку с mikrotik . Начнем с GRE, заходим утилитой Winbox на mikrotik в меню Interfaces->GRE Tunnel->+(нажимаем плюс, чтобы добавить туннель), за тем : - Local Address Y.Y.Y.Y - Remote Address X.X.X.X Укажем параметр "keepalive", который определяет находится ли туннель в рабочем состоянии. Если параметр не включен, то даже, если второй маршрутизатор будет выключен интерфейс все равно будет показывать рабочее состояние, что не удобно для диагностики. Использовать будем значение 10 попыток по 10 секунд. т. е., если в течении 100 секунд не будет никаких сигналов с противоположной стороны туннель перейдет в нерабочее состояние. При этом он автоматически включится, если противоположная сторона попытается установить соединение. В отличии от настройки GRE без IPsec в этой конфигурации должна быть отключена опция "Allow Fast Path", а параметр "Local Address:" является обязательным потому что без него не получится создать автоматические настройки IPsec. Если указать параметр IPsec Secret, то автоматически создадутся необходимые настройки IPsec. Но их поменять будет уже не возможно, поэтому не задаю параметр IPsec Secret.

Назначим IP адрес GRE-туннелю. Зайдем IP->Addresses->+

Команды консоли :

/interface greadd name=gre-tunnel1 keepalive=10s,10 local-address=Y.Y.Y.Y remote-address=X.X.X.X allow-fast-path=no/ip addressadd address=10.10.10.2/30 interface= gre-tunnel1

Настраиваем IPsec . Начнем с phase-1, идентификация устройств между собой, по заранее определенному IP адресу и ключу , настройки в IP->IPsec->Profiles.

Создаем Peer для phase-1, в IP->IPsec->Peers. Указываем имя name Branch-HQ, адрес удаленного FortiGate HQ, локальный адрес и profile1, который соответствует phase-1.

Теперь определяем ключ IPsec phase-1.

Настройка параметров phase-2, он согласует общую политику IPsec, получает общие секретные ключи для алгоритмов протоколов IPsec (AH или ESP), устанавливает IPsec SA. Идем IP->IPsec->Proposals

И создаем политики IPsec , IP->IPsec->Policies->General. Указываем имя Peer Branch-HQ, мы его настраивали выше. Src. Address внешний адрес нашего mikrotik Y.Y.Y.Y, Dst. Address внешний адрес FortiGate HQ X.X.X.X, и указываем протокол GRE в параметре Protocol - 47.

На вкладке Action выбираем Proposal porposal1, который мы тоже настраивали выше.

Настройка в консоли :

 /ip ipsec profileadd dh-group=modp1536,modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=24h name=profile1/ip ipsec peeradd address=X.X.X.X local-address=Y.Y.Y.Y name=Branch-HQ profile=profile1/ip ipsec proposaladd auth-algorithms=sha256 enc-algorithms= aes-256-cbc lifetime=30m name=proposal1 pfs-group=modp1536/ip ipsec policyadd peer=Branch-HQ src-address= Y.Y.Y.Y dst-address= X.X.X.X protocol=47 proposal=proposal1/ip ipsec identityadd peer=Branch-HQ secret=#!@BRaNCH@!#

Прописываем правила в файерволе IP->Firewall->Filter Rules:

В терминале :

/ip firewall filteradd chain=input protocol=17 dst-port=500,4500 in-interface=ether1 action=accept

Пока не поднята динамическая маршрутизация , создадим статический маршрут до локальной сети головного офиса :

/ip routeadd dst-address=192.168.111.0/24 gateway=10.10.10.1

На этом настройка mikrotik окончена , перейдем к настройки FortiGate.

На FortiGate настроим IPsec phase-1 в командной строке:

config vpn ipsec phase1-interface edit HQA-Branch set peertype any set proposal aes256-sha256 set dpd on-idle set dhgrp 5 14 set auto-discovery-sender enable set remote-gw Y.Y.Y.Y set psksecret #!@BRaNCH@!# set dpd-retryinterval 5 nextend

Phase-2 , не забываем указать protocol 47 и указать transport-mode (транспортный режим) для туннеля GRE:

config vpn ipsec phase2-interface edit "HQA-Branch" set phase1name "HQA-Branch" set proposal aes256-sha256 set dhgrp 5 14 set auto-negotiate enable set encapsulation transport-mode set protocol 47 nextend

Настроим GRE tunnel:

config system gre-tunnel edit "HQ-Branch" set interface "HQA-Branch" set remote-gw Y.Y.Y.Y set local-gw X.X.X.X nextend

Настроим локальный IP адрес туннельного интерфейса и укажем IP удаленного интерфейса:

config system interface edit "HQ-Branch" set ip 10.10.10.1 255.255.255.255 set remote-ip 10.10.10.2 255.255.255.252 set interface "HQA-Branch" nextend

Трафик GRE, который должен быть защищен IPsec, создается самостоятельно, он не принимается на интерфейсе. Следовательно, не требуется политика форвардинга, чтобы разрешить трафику GRE входить или выходить из интерфейса IPsec. Однако по замыслу FortiOS для согласования IPsec требуется политика форвардинга. Поэтому для активации IPsec используется произвольная политика форвардинга (например, от самого интерфейса IPsec и обратно).

config firewall policy edit 2 set name "Enable IPsec" set srcintf "HQA-Branch" set dstintf "HQA-Branch" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ALL" next

Разрешим трафик из локальной сети головного офиса port2 в туннель GRE и наоборот:

config firewall policy     edit 3        set name "GRE HQ->Branch"        set srcintf "port2"        set dstintf "HQ-Branch"        set srcaddr "all"        set dstaddr "all"        set action accept        set schedule "always"        set service "ALL"    next    edit 4        set name "GRE Branch->HQ"        set srcintf "HQ-Branch"        set dstintf "port2"        set srcaddr "all"        set dstaddr "all"        set action accept        set schedule "always"        set service "ALL"    nextend

После туннелирования GRE, пакеты GRE должны быть защищены IPsec. Следовательно, remote-gw gre-tunnel должен указывать на интерфейс IPsec. Настраиваем статический маршрут:

config router static edit 1 set dst Y.Y.Y.Y/30 set device "HQA-Branch" next

Создадим статический маршрут до локальной сети филиала

edit 2        set dst 192.168.112.0 255.255.255.0        set device "HQ-Branch"    nextend

И теперь поднялся IPsec и GRE , трафик из локальной сети головного офиса попадает в локальную сеть филиала и наоборот.

Использовал следующие статьи:

1.Fortinet

2.Wiki Микротика

Это мой второй труд , прошу сильно не пинать.

Качество связи во время разговора играет весомую роль в работе компании. Это сказывается и на эффективности работы сотрудников, и на имидже компании в целом. Основные жалобы это: пропадают слова, прерывается голос, слышно эхо или речь приходит с задержкой.

Некоторые провайдеры, конечно подсказывают, что можно предпринять со своей стороны, в чем может быть проблема. Снимут дамп, сделают анализ и дадут рекомендации. Но таких крайне мало. Из памяти, пожалуй вспомню оператора Мобилон. Привет техподдержке, если читаете!

А что происходит, если провайдер не дал рекомендаций, не указал на причину?

Несомненно, у вас начнет закрадываться мысль о смене провайдера. Но решит ли это проблему? Если причина на нашей стороне, то очевидно, что проблема не решится, и качество будет также неудовлетворительным с новым провайдером. А переход, дело не простое и затратное. За такой исход событий руководство компании спасибо нам не скажет.

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

Что же еще можно предпринять? Казалось бы, вариантов больше не осталось...

Но может быть, все таки, разобраться самому? Возможно, это не так сложно?

Да, дорогие друзья!
Отвечу я вам. Всё гораздо проще, чем кажется на первый взгляд!

Имея позитивный опыт в решении подобных проблем у разных компаний, хочу поделиться с вами способом ее диагностики и решения, не прибегая к кардинальным мерам и помощи сторонних лиц.

Для диагностики нам понадобится научиться снимать дамп сети (sniffer) с роутера и маршрутизатор Mikrotik. А также, настроить очереди (QoS) на роутере.

Для упрощения схемы, я поделил весь процесс на этапы:

1. Настроить и запустить sniffer

2. Воспроизвести проблемный вызов

3. Проанализировать sniffer в Wireshark

4. Настроить на роутере выделенную полосу (QoS) для телефонии

5. Протестировать связь

1. Настройка и запуск packet sniffer

Для того чтобы определить причину проблемы, необходимо снять dump звонка. В нем будет содержаться вся информация о состоянии сети во время вызова.

Настраиваем на Микротике packet sniffer: Tools->Packet Sniffer

На вкладке General оставляем значения по умолчанию.

Вкладка Streaming: галочки Streaming Enabled и Filter Stream, в поле Server пишем адрес, куда будем отправлять данные, собираемые сниффером.

Я отправляю на свой ПК в той же сети, поэтому прописываю его локальный адрес. Но можно слать и на удаленный сервер, тогда прописываем его внешний ip.

Вкладка Filter: здесь необходимо в поле IP Address прописать ip адрес провайдера телефонии.

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

Если не получилось выяснить адреса провайдера, то можно прописать просто 0.0.0.0/0

Но тогда в дампе будет очень много лишней информации, что затруднит анализ.

Я пообщался с техподдержкой своего провайдера, они порекомендовали прописать всю подсеть.

Нажимаем Apply и Start. Внизу окна появится статус: running

Сниффер на роутере запущен, теперь необходимо поймать пакеты.

На том ПК или сервере, адрес которого указали в поле Server, нужно запустить tcpdump.

На Windows:

а) нужно скачать утилиту tcpdump

Скачиваем с официального сайта версию не для коммерческого использования.

tcpdump.exe можно запустить даже с флэшки

Для этого запускаем cmd от имени администратора и проваливаемся в директорию с файлом tcpdump.exe

Вводим команду tcpdump -D

Нам отобразится список доступных интерфейсов.

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

Например: tcpdump -i 1 -v -n host 192.168.88.1

где 1 - это номер интерфейса, а host - адрес роутера.

У меня пакеты летят на интерфейсе под 4, его и буду слушать.

Далее запускаем команду для отлова сниффера с Микротика:

tcpdump host 192.168.88.1 -i 4 -C50 -n -v -w name_sniffer.pcap

где i - номер интерфейса, С50 - ограничение размера записываемого файла до 50Мб, n - отображать IP адреса вместо имени хостов, v - уровень отображения получаемой информации (1-й уровень), w - записывать данные в файл.

На Linux :

Необходимо установить утилиту tcpdump. Обычно она присутствует в стандартном репозитории.

Более подробно про установку можно посмотреть, например, здесь.

Запускаем команду:

tcpdump host 192.168.88.1 -i any -C50 -n -v -w /var/tmp/name_sniffer.pcap

После запуска tcpdump вы должны увидеть отсчет улавливаемых пакетов (на Linux), в поле Got. Если отсчет не идет, значит что-то сделали неверно, перепроверьте.

2. Фиксируем проблемный звонок

Теперь, когда у нас tcpdump ловит сниффер с Микротика, нужно зафиксировать проблемный звонок.

Если проблема плавающая, тогда следуют попросить сотрудников, чтобы записали время и номер телефона, когда возникнет деградация голоса.

У меня получилось зафиксировать такой пример самостоятельно с одним из сотрудников:

Как мы слышим на записи, голос идет с прерываниями.

Но может быть и так, что на записи из личного кабинета виртуальной АТС провайдера всё будет отлично, а мы слышали человека на том конце провода плохо. Это значит, что к провайдеру голос приходит хорошего качества, а уже по пути от провайдера до нашего конечного устройства голос доходит с потерей пакетов. Для того, чтобы проверить это, нам поможет сниффер.

3. Останавливаем sniffer и анализируем его в Wireshark

Проблемный вызов необходимо проанализировать. Останавливаем tcpdump (Ctrl+C) и sniffer на Микротике (нажать Stop). Создастся файл name_sniffer.pcap.

Устанавливаем программу Wireshark. Скачать ее можно бесплатно с официального сайта. А на Линуксе можно установить из стандартного репозитория.

Открываем pcap файл в Wireshark и переходим в Телефония->Вызовы VoIP

В новом окне отобразятся все вызовы, которые попали в дамп. У меня такой один.

Для удобства поиска вызовов (когда их в дампе много) установите галочку Время дня.

Выберите вызов и откройте Последовательность потоков, чтобы увидеть движение запросов по вашему звонку.

Здесь мы увидим, с каким сервером провайдера идет обмен сигнальными сообщениями, а с каким сервером осуществляется передача голосовых пакетов (RTP).

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

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

Далее нас интересуют RTCP пакеты.

Из всего перехваченного сниффером трафика нужно отфильтровать только RTCP пакеты.

Прописываем фильтр:

(rtcp.ssrc.fraction>10)||(rtcp.ssrc.jitter>35)

- отобразить RTCP со значением потерь пакетов больше 10 или RTCP со значением джиттера больше 35.

Выбираем сообщение и разворачиваем RTCP -> Source 1 -> SSRC Contents

Здесь видим, что потеряно 50 пакетов из 256 и уровень джиттера 166 (хотя нормальный уровень это 30-70).

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

По каким причинам это может происходить?

1. Забивается линия выделенная вам от интернет провайдера.
   Например, у нас 3Mб/с на "внешку". Устройства в локальной сети потребляют все 3Mб/с, но если просто сёрфить в браузере, то мы не заметим нехватку канала. Так как в этом случае, используется транспортный протокол TCP. А телефония использует UDP, которому свойственно теряться в процессе передачи, если весь ваш выделенный канал занят.

2. Устройства подключены по воздуху (Wi-Fi).
   В таком случае будет высокий показатель джиттера.

3. У провайдера на линии есть радиоканал.

4. Проблема с вашим маршрутизатором.

5. Проблемы на линии интернет провайдера

В этой статье, более подробно, рассмотрена причина под пунктом 1.

По остальным скажу кратко.

Пункт 2 - если на устройствах есть функция джиттер-буфер, то нужно установить режим Fixed. Если нет такой опции, то подключить устройство витой парой.

Пункт 3 и 5 - обратиться к интернет провайдеру, предоставив наши дампы, подтверждающие проблему.

Пункт 4 - диагностировать или заменить роутер.

Но в первую очередь, рекомендую всегда сначала проработать пункт 1.

4. Настраиваем выделенную полосу для ip телефонии

Необходимо в вашей локальной сети обеспечить для ip телефонии отдельную полосу пропускания (QoS), чтобы трафик других устройств не мешал.

Для начала, измерьте фактическую скорость интернета на "внешку".

Я измеряю через speedtest.net

Можно еще с помощью 2ip.ru или утилитой iperf

На speedtest.net я выбираю Change Server город отличный от моего, чтобы исключить вероятность замера скорости в пиринге.

У меня на загрузку скорость 11Мб/с, на отдачу 14Мб/с. Хотя по договору должно быть 15М в обе стороны. Поэтому и рекомендую измерять, какая у вас скорость по факту, а не по бумагам. Это поможет корректно настроить очереди на роутере.

Для настройки очередей открываем на Микротике Queues

Cоздаем правила в разделе Simple Queues.

На вкладке General задаем ограничение по скорости для всей локальной сети.

Я устанавливаю максимальные значения лимита меньше на 2М, чем полученные при замере.

Почему 2М? Беру с запасом, так как скорость может быть не постоянной и в моменте меняться как в большую, так и в меньшую сторону.

В Advanced выставить Queue Type распределение по pcq (это делается для того, чтобы устройства не мешали друг другу и равномерно использовали трафик).

Сохраняем это правило и создаем еще одно, для SIP.

Прописываем ip адрес (можно всю подсеть) провайдера ip телефонии.

Максимальные лимиты устанавливаем, как заявлено по договору интернет провайдера.

В Advanced устанавливаем Limit At. Это позволит для телефонии оставлять 1Мб/с в любом случае, даже если идет максимальная нагрузка на канал другими устройствами.

Сохраняем и устанавливаем правило SIP на верхнюю позицию.

ВНИМАНИЕ!

1. Чтобы очереди (QoS) начали работать, необходимо деактивировать правило Fasttrack в IP -> Firewall -> Filter Rules.

2. Учитывайте порядок настроенных правил. Обработка осуществляется сверху вниз. Поэтому обязательно правило SIP поднимаем на самый верх.

Пояснение по настроенным QoS:

• весь трафик, который идет на ip адреса отличные от адреса voip провайдера, ограничивается 12Мб/с на загрузку и 9Мб/с на отдачу

• весь остаток от этого до 15Мб/с оставляем для телефонии

• и на тот случай, что если даже трафик проскочит выше лимитов, для телефонии отведен 1Мб/с принудительно

Далее проверяем ходит ли вообще трафик в настроенных QoS.

Нужно открыть настройки очереди и перейти на вкладку Traffic.

На вкладке Statistic можно увидеть, количество дропнутых пакетов и распределенных по pcq.

Также можно проверить, как отрабатывают очереди, с помощью утилиты iperf.

5. Тестируем связь

Теперь, когда QoS настроены, нужно протестировать связь.

Ставим дамп и делаем несколько тестовых звонков.

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

Вот пример одного из звонков.

В дампе этого вызова потерь пакетов не наблюдается.

Единственное, можно заметить, что уровень джиттера выше нормы.

Это обусловлено подключением voip устройства через Wi-Fi. И, так как устройство позволяет настроить джиттер-буфер, качество голоса не страдает.

Вы можете также и сами наглядно всё это увидеть в моих дампах. Скачать можно здесь:
дамп звонка до настройки QoS
дамп звонка после настройки QoS

Итог:

Когда у вас возникла проблема с качеством голоса цифрового характера, всегда, в первую очередь, произведите анализ вашей сети и настройте QoS для телефонии. Если даже выяснится, что причина была не на вашей стороне, то у вас уже будут технические данные (дампы), которые вы сможете предоставить провайдерам для подтверждения.

В некоторых организациях в локальной сети может находиться большое количество устройств с разными категориями. Например, помимо ip телефонии еще ip камеры, которые также используют udp протокол для передачи данных. Следовательно для ip камер тоже необходимо выделять QoS.

Вам не обязательно настраивать очереди точно также, как у меня. Главное, что я хотел показать, это логику решения проблемы с качеством голоса.

Более подробно про QoS можно изучить еще в этой статье.

Не самая частая задача на устройствах MikroTik - одномоментное создание большого количества PPP(англ.Point-to-Point Protocol) пользователей. Но когда она возникает, это превращается в очень скучное и нудное дело, что следует исправить.

Предыдущую статью "MikroTik Скрипт: Уведомление о успешном входе на устройство или простой парсер журнала MikroTik" добавило в закладки в закладки 80+ пользователей, надеюсь и эта статья будет не менее полезна.

- Что, мой мальчик, получается ли тебе собрать слово "Вечность"?

- Трудно, моя госпожа, сложить слово "Вечность" из букв "Ж", "П", "О" и "А" - ответил Кай.

Скриптовый язык MikroTik никак нельзя назвать полноценным языком программирования, поэтому слово "Вечность" будем собирать из того что есть, добавляя костыли и перематывая синей изолентой (ведь нет ничего долговечней, чем ...).

Скрипт рассчитан на внимательных пользователей (регистр имени файла, структура файла) и не рассчитан на любознательных пользователей вида "что будет, если вместо IP адреса поставить деление на ноль?". "Защита от дурака" отсутствует, чтобы искусственно не раздувать размер скрипта.

Планируемая последовательность действий

1. Скачиваем шаблон CSV файла (FileTemplate.zip на GitHub);

2. Заполняем шаблон (проверено Microsoft Excel);

3. Загружаем файл на устройство MikroTik;

4. Создаем скрипт импорта PPP пользователей;

5. Включаем Безопасный режим MikroTik;

6. Запускаем скрипт;

7. Смотрим лог и список PPP пользователей;

8. Убедившись, что все прошло хорошо - выключаем Безопасный режим MikroTik;

9. Пишем в комментарий к статье, что всё прошло хорошо (неплохо указать модель устройства, версию RouterOS).

Создание файла

Настоятельно рекомендую использовать шаблон файла с GitHub (в этом случае пропустите этот раздел).

Но вы конечно можете создавать свой файл с любым расширением (в этом случае настраивайте :set Content [:pick $Content 62 $ContentLen]; вместо 62 выставляя свое значение от начала последовательности, в скрипте "отрезается" 62 символа - с учетом "шапки" таблицы в шаблоне).

Как разделитель элементов используется символ ";", но вы можете указать свой символ.

Как разделитель строк используется символ "\r", поэтому шаблон предоставлен в .zip формате с сохранением всех символов, т.к. множество редакторов, в том числе на GitHub отрезают "лишние" по их мнению символы.

Логика скрипта

Укажите в строке :local FileName "FileTemplate.csv"; название импортированного файла (рекомендую скопировать полное название из списка Files);

Проверка, что размер файла не превышен, запись в журнал устройства при превышении размера и остановка скрипта. Для RouterOS6 существует ограничение на размер переменной в 4КБ (у меня это было 80 пользователей, в RouterOS7 вроде как обещают снять ограничения);

"Разбираем" файл, разбивая его на строки и запуская деление на элементы в каждой строке;

Значение найденного элемента присваиваем соответствующему ключу массива ColumnsArray;

Закончив разбор строки, формируем команду MikroTik для создания PPP пользователя;

Если имя пользователя уже существует - пропускаем создание пользователя (вы можете самостоятельно добавить удаление пользователя, если требуется массовое пересоздание пользователей);

Добавляем каждое из значений массива ColumnsArray в текст команды, если значение отсутствует, попускаем.

Выполняем сформированную команду создания пользователя;

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

Создать скрипт

Для запуска скрипта необходимы разрешения: read, write, test, policy.

[System] -> [Scripts] -> [+] -> [Name: CreatePPPUsers] -> [Policy: read, write, test, policy]

Внимание: излишние права (выставляются по умолчанию новому скрипту) могут привести к появлению ошибки "could not run script ParseLogAccountEvents: not enough permissions" (RouterOS 6.48), устанавливайте только указанные в статье права.

Код скрипта

# Name: CreatePPPUsers v1# Description: Bulk create VPN users from a file# Author: Yun Sergey, MHelp.pro 2020# License: GPL-3.0 License# Description, purpose and questions: https://mhelp.pro/mikrotik-script-bulk-create-vpn-users-from-a-file/# More scripts Mikrotik: https://mhelp.pro/tag/mikrotik/:local FileName "FileTemplate.csv";:log warning "Script CreatePPPUsers: running. Import from file: $FileName";:if ([/file get $FileName size]  > 4096) do={    :log error "Error run script CreatePPPUsers: file size exceeded 4 KB (size constraint of a variable in Router OS 6). Split the file $FileName into several parts.";    :error "File size exceeded 4 KB. Stop script."};:local Content [/file get $FileName contents];:local ContentLen [:len $Content];:set Content [:pick $Content 62 $ContentLen];:local StartCursor 0;:local EndCursor;:local LineEndCursor;:while ($StartCursor < [:len $Content]) do={    :set LineEndCursor [:find $Content "\r" $StartCursor];    :local  Cont;    :local ColumnsArray { "01Name"="" ; "02Password"="" ; "03Service"="" ; "04Profile"="" ; "05LocalAdress"="" ; "06RemoveAddress"=""};    # START PARSING STRING    :foreach Key,Value in=$ColumnsArray do={        :local Symbol [:pick $Content $StartCursor];        :if ($Symbol =";") do={:set StartCursor ($StartCursor - 1)};        :set EndCursor [:find $Content ";" $StartCursor];        :if (($EndCursor > $LineEndCursor) or ([:typeof $EndCursor]="nil")) do={:set EndCursor [:find $Content "\r" ($StartCursor-1)];};        :set Cont [:pick $Content $StartCursor $EndCursor];        :set ($ColumnsArray -> $Key ) $Cont;        :set StartCursor ($EndCursor+1);    };    # END PARSING STRING    # START CREATE COMMAND    :local UserName ($ColumnsArray -> "01Name");    :if ([/ppp secret find name=$UserName ]) do={        :log info "Add PPP user: $UserName - already exist! Skipped.";    } else={        :local Command "/ppp secret add name=$UserName";        :local UserPassword ($ColumnsArray -> "02Password");        :if ($UserPassword != ";") do= {:set Command ("$Command" . " password=$UserPassword")};        :local UserService ($ColumnsArray -> "03Service");        :if ($UserService != ";") do= {:set Command ("$Command" . " service=$UserService")};        :local UserProfile ($ColumnsArray -> "04Profile");        :if ($UserProfile != ";") do= {:set Command ("$Command" . " profile=$UserProfile")};        :local UserLocalAdress ($ColumnsArray -> "05LocalAdress");        :if ($UserLocalAdress != ";") do= {:set Command ("$Command" . " local-address=$UserLocalAdress")};        :local UserRemoveAddress ($ColumnsArray -> "06RemoveAddress");        :if ($UserRemoveAddress != ";") do= {:set Command ("$Command" . " remote-address=$UserRemoveAddress")};        [:parse $Command];    };    # END CREATE COMMAND    :set StartCursor ($EndCursor+2);};:delay 2;:log warning "Script CreatePPPUsers: completed.";

Скрипт намеренно сделан в упрощенном виде, избегая вложенных конструкций, затрудняющих чтение кода, но никто не мешает вам "дооптимизировать" скрипт в "одну" или минимальное количество строк.

Если вам интересны другие мои скрипты MikroTik, их можно увидеть здесь или на GitHub.

Если вы использовали скрипт, оставьте пожалуйста обратную связь "Работает. Модель устройства и версия RouterOS". Это поможет другим. Спасибо.

Проверено: MikroTik hAP ac lite (RouterBOARD 952Ui-5ac2nD), RouterOS 6.47.8 (stable).

• Цель статьи

• Определение

• Компоненты

• Общие понятия

• Сфераприменения

  • -login

  • -VPN (ppp*)

  • -wifi

  • -dot1x

• диагностика

• выводы

Цель

Цель данной статьи - объяснить логику работы радиуса в примерах, избавить от боязни и иллюзии сложности использования.

Определение, назначение, общие сведения

RADIUS - это протокол, для авторизации, аутентификации и учёта (AAA).

Позволяет повысить безопасность сети и централизованно управлять доступами.

Сервер RADIUS может иметь свою базу данных с учетными данными (например файлы илиmysql) или работать в паре с другим сервером, например Active Directory.

Кроме AAA позволяет передать некоторые дополнительныеданные (настройки) клиенту прошедшему аутентификацию, в том числе vendor-specific attributes (VSA). У Mikrotik такие тоже есть, позже пройдемся по самым интересным.

Существуют много популярных приложенийрадиус сервера, самый популярные: freeRADIUSи Служба NPS (Network Policy Server) Windows Server. Более подробно мырассмотрим второй вариант.

Компоненты кейса

• Суппликант - устройство которое намеренопройти процедуру авторизации и аутентификации.

• Аутентификатор - устройство к которому подключается суппликант, которое получаету суппликанта данные авторизации и которое проверяет их на RADIUS сервере. NB! Является клиентом для радиус-сервера.

• RADIUS сервер (он же радиус сервер, он же сервер аутентификации).

Настройка

Установку роли описывать не буду, существует 100500 статей в картинках, например: тыц

1. Добавлениерадиус клиента на радиус-сервере Намнужно заполнить "понятное имя", IP адрес и придумать пароль (а.к.а. "секрет"), которыйпонадобится при настройке аутентификатора (mikrotikв нашем случае)

   

Политикизапросов на подключение и Стетевые политики очень похожипри настройке, и нужно понимать разницу между ними. Первые нужны длятого что быпри определенных условияхопределить сервер на котором будет проходить проверка аутентификации клиента (к примеру локально или надругом удаленном радиус сервере) а так же для некоторых манипуляций с атрибутами. Вторые же позволяют определить набор условийпо которымвозможно обозначитьразрешить или отклонитьзапроос клиента на подключение.

Политики имеют порядок и обрабатываются по нему одна за другой. Если подключение не соответствует условиям политики, то проверяется следущаяи так далее. К примеру, это поможет разделить правила обработки для проводных\беспроводных и впн клиентов. {.is-warning}

2. Добавление политики запросов на подключение

3. Добавление сетевой политики

Некоторые типовые кейсы применения радиус сервера :

1. централизованная аутентификация на устройствах поддерживающихaaa

2. аутентификация для vpn (pptp\l2tp)

3. аутентификация вwifi

4. аутентификация устройств при подключении к порту rj45 - dot802.1x

Итак подробнее, + некоторые плюшки. Для всех наших пунктов нам нужнонастроить радиус клиента вmikrotik

/radius add address=10.10.11.100 comment="PVE AD" secret=STRONG_SECRET_PASSWORD service=ppp,login,hotspot,wireless,dhcp,ipsec,dot1x timeout=600ms

address -Адрес радиус сервера secret - пароль, который мы совсем недавно настраивали для радиус клиента service -сервисы в mikrotik, которые могут использовать радиусдля аутентификации.

Отдельно стоит отметить пункт timeout=600ms, если вы используете радиусчерез медленные каналы с большими задержками, стоит увеличитьэто значение.

Теперь можно начинать настраиватьинтересные вещи.

1. настроим входна микротик

/user aaaset accounting=yes default-group=read use-radius=yes

Стоит уделить внимание параметру default-group он означаетгруппу по умолчанию,вкоторая применится к пользователю.

Теперь настроим NPS:

Ноэто слишком просто и не интересно, давайте преставим немного мифическую, но более интересную ситуацию. Предположим мы хотим отразным уровням техподдержки, выдать разный уровень доступа на устройство. Или , предположим,в рамках одной компании разделить админой cетевиков c полным доступом и джунов, котоые могут только смотреть параметры.

ОбратимсякWikimikrotik, мы можем заметить RADIUS атрибут, который позволяет определитьдоступы какой группыприменятся к пользователюкоторый аутентифицируется на устройстве черезRADIUS. *Mikrotik-Group - Router local user group name (defines in /user group) for local users; HotSpot default profile for HotSpot users; PPP default profile name for PPP users. * воспользовавшись промт'оммы понимаем что этот атрибут позволяет задать нам имя встроенной группы при авторизации , или задать имя профиля при аутентификациив сервисыvpn или hostspot. этот атрибут мы буем использовать и позже.что бы отделить мух от котлет приавторизации для впн мы будем использовать дополнительные условия, но это позже.

итак, как мы этого добьемся мы можем создать вSystem -> users ->groupдве группы со специфичными параметрами доступа, а можем и воспользоваться уже существующими, к примеруfullиread.

Но все это ничего без второй части, нам необходимо настроитьNPS. Давайте создадим в остнастке Пользователи и компьютерыДве группы пользователей admins-network иadmins-junior. И два пользователяnet-juniorи net-admin,добавим их в соответствующие группы.

Политику запроса на подключение мы уже создали, перейдем к сетевым политикам. в Оснастке NPSсоздадим двеполитики mikrotik-login-juniorиmikrotik-admin-network ,в условиях первойзададим :

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

Сразу попробуем авторизоваться ивидим что попали в нужную группуread

В методах проверки подлинности указываем :

Политика mikrotik-admin-networkбудет отличаться тем что в условияхвыберем группу admins-networkа значение отрибутаMIKROTIK_GROUPзададим как full Результат ожидаемый, мы залогинилисьв микротик под полными правами:

/user active print detailFlags: R - RADIUS, M - by-romon 0 R when=jan/05/2021 10:36:52 name="net-admin" address=10.10.15.7 via=winbox     group=full 1 R when=jan/05/2021 10:37:04 name="net-admin" address=10.10.15.7 via=telnet     group=full

Перейдем к впн, и к стразу более интересному сценарию.

Предположим мы хотим отделитьадминов, от остальных работников. Выдадим админам профиль с подсетью которая будет иметь доступ к management vlanи не только, и выдадимотстальным сотрудникам профильс подсетью которая будет меть ограниченый доступ только к 1c, RDP, etc.. . Предположим, мы используюем для впнl2tp\ipsec/ Для этого создадим в микротик два профиля в PPP -> profile

/ip pool add name=pool_l2tp_admin ranges=10.10.21.10-10.10.21.250/ip pool add name=pool_l2tp_users ranges=10.10.22.10-10.10.22.250/ppp profile add dns-server=10.10.21.1 local-address=10.10.21.1 name=l2tp-vpn-admin remote-address=pool_l2tp_admin use-compression=no use-encryption=yes/ppp profile add dns-server=10.10.22.1 local-address=10.10.22.1 name=l2tp-vpn-users remote-address=pool_l2tp_users use-compression=no use-encryption=yes

В настройки правил форейвола дляограничения доступа подсетей япожалуй не буду углубляться,подразумевается что вы понимаете как изодной подсети запретить доступ кресурсу икак разрешить. (с)предпологается, что вы немного сетевик. Касательно примера подсети10.10.21.0/24необходимо разрешить форвард в подсети серверов и managementа подсети 10.10.22.0/24необходимо разрешить только доступк корпоративным сервисам, но не к сетям управления.

Настроим NPS. В остнастке Пользователи и компьютеры создадим 2 группы пользователей vpn-admins иvpn-users, знакомого нам net-adminвключим в 1ю группу, а net-buhво вторую. Политика запросов на подключение у нас будет использоваться та же. А политики сети созадим. В Условиях важно не только задать группу пользователей, но и тип порта NAS

Знакомым нам образом добавим атрибут указывающий какой профиль микротика использовать.

Методы проверки подлинности используем как и в прошлый раз. В настройках Сервера VPNрекомендуется указать точно такой же тип.

На вскидку полезными так же могут отказаться атрибуты : Mikrotik-Rate-Limit - дляограничения скорости vpnклиентов

Настроим тестовое поключение и увидим что получилиIPиз пуладля сетевых администраторов.

Теперь настроим политику дляобычных пользователей:

Результат - пользователь получилipизнужной подсети

Wifiи Dot1x

Прежде чем перети к самому вкусному, хочется сделать выбор как мы будем проходить авторизацию,можно выбрать пологину и паролю, компьютеру, использоватьmacадрес как логин и пароль.. и наконец пойти самым сложныминтересным путем,использовать сертификаты. В качестве предварительной подготовки нам необходимо:

• настроить службу центрасертификацииWindowsтыц, актуально и для следующего пункта

• настроить GPO для распространения CAсертификата домена тыц

• GPOавтоматического получения сертификата компьютераdocs.microsoft

• GPOвключение службы dot1X (проводная автонастройка) исоздать Политики проводных сетей (802.3) для выбора способа проверки подлинности тыц

• GPOАвтоматическое подключение кWifiдо логина пользователя тыц

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

wifi

Настройку WiFiкаждый настраивает как ему удобно. Я к примеру,предпочитаю CapsMan,дажеесли это будетединственная APв сети. В любом случае нас интересует только Security Profile/Security Cfg.

Создадим политику сети: В условиях выберем Тип порта NAS= Беспроводная - IEEE 802.11

А в методах проверки подлинности следующее.

Как понять что все получилось или что то идет не так )? - все просто в первую очередь идем в логи. Видим событие с подробной информациейкто куда и когда ходил и согласно какой политике получилразрешение или отказ ы доступе.

Какие радиус атрибуты могут быть нам полезны:

• Framed-Pool - можемдля отдельных групп пользователей использоватьсвойipпули выполнять какие то манипуляции на основе этого вфорейволе

• Filter-Id - применять какое то правило форейвола сразу к клиенту

• Mikrotik-Wireless-VLANID - указать в какойvlanдолжен попасть клиент (Возможно, однажды, по заявкампользователейя дополню статью примером с ипользованиемvlanвwifi)

• устанавливать лимитыпо обьему или/и скорости трафика

• имногие другие параметры из вики, либо их комбинации с условиями сетевой политики, смотря сколько у вас фантазии :)

dot1x

Зачем нужен dot1X и как его настроить.. очень много интересных слов можно было бы тут написать, но все сказанодо нас. Например на каналеодного прекрасного тренераили wiki

Половина смысла с саркальной точки зрения в dot1xв том, что в случае успешной проверки подлинности наше устройство попадетв влан указанный нами в микротике или в влан который мы поличим в качестве атрибута у радиуса. Еслипроверка подлинности пройдет с отказом или ответ не будет получен от радиуса (например в случае его недоступности), то порт перейдет в изолироованный режим (будет заблокирован любой трафик на порту) или в случае если указан Reject VLAN IDто попадет в влан,для которогомы настроили(я надеюсь все таки настроили) максимально безопасные правилафорейвола для чужеродных устройств .

Начнем с микротика:

Настроим политики сети: В условиях необходимо отобрать проводные клиенты

Параметры аутентификации:

В настройках атрибутами выдадим рабочий влан

К примеру вот так выглядит отказ вавторизации:

А вот так успешное подключение:

Диагностика

Не всегданаши настройки сразу работают так как надо, иногда что то идет не так, и очень хочется понять что именно. Для того что бы понять в чем причина у нас есть :

• логи mikrotik

  Идем в system logging add topics=radius,debug action=memory disabled=noи пробуем что то делать, в log printпоявятся записи связанные с радиусом. -логи Службы

• политики сети и доступа

  я уже приводил пример, еще раз - искатьздесь, и читать внимательно сообщения

  

• возможны проблемы из заwindows брандмауерапочинить можно

Get-NetFirewallRule -DisplayGroup "Сервер политики сети" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any

илидляанглоязычной версии:

Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any 

• radclientиз пакета freeradius-utils. Позволяет из командной строки проверить некоторые типы авторизации, к примеру подключение кvpn

Тест:

echo "User-Name = USER,User-Password=PASSWORD,NAS-Port-Type=Virtual" | radclient -s 10.10.11.100:1812 auth SHARE_NPS_SECRET -x

Вывод программы:

Sent Access-Request Id 177 from 0.0.0.0:42354 to 10.10.11.100:1812 length 56       User-Name = "USER"       User-Password = "PASSWORD"       NAS-Port-Type = Virtual       Framed-Protocol = PPP       Cleartext-Password = "PASSWORD"Received Access-Accept Id 177 from 10.10.11.100:1812 to 10.10.15.7:42354 length 94       Mikrotik-Group = "pptp-nps"       Framed-Protocol = PPP       Service-Type = Framed-User       Class = 0xa1cd098c00000137000102000a0a0b6400000000ec967e14be8346ce01d6d63b3e2ca9d70000000000000092Packet summary:       Accepted     : 1       Rejected     : 0       Lost         : 0       Passed filter : 1       Failed filter : 0

Выводы

RADIUSв сетевой средеочень полезенв плане безопасностии удобен вплане централизованного управления. Настраивать не так уж и сложно, главное читать, понимать документацию и логи.

Если какой то из пунктов непонятен, пишите. попробую показать или помочь разобраться.

Если в статье нашли ошибки, неточности или знаете как сделать лучше тоже пишите.

Благодарности:

Спасибо @aslancherkesov за злого редактора и свежий взгляд на буквы.

Вступление

Один из способом сделать доступным некоторые внутренние (домашние) сервисы из Интернета является VPN. Можно, конечно, отдельные порты опубликовать и через ssh, но для более полноценной связи лучше использовать другие решения. Я уже писал и про ZeroTier, и про OpenVPN, и получил упреки, что незаслуженно забыл про Wireguard

Так или иначе, мне стало не хватать VPN клиента (в т.ч. и Wireguard) на отдельно стоящем серверочке, потребовалось связать (в данном случае с vNet в Azure, хотя это не принципиально) всю домашнюю сеть с несколькими ресурсами. И я решил, что пора уже сделать это через роутер, для полноценного site-to-site.

Хотя Keenetic и научился поддерживать Wireguard на новых прошивках, для старенькой Ultra я такой не нашел. С OpenWRT тоже не срослось (для Ultra II есть, а моя моедль старовата). Так что я решил, что пора проапгрейдиться. И, поскольку Mikrotik RouterOS выкатила бету 7 версии с Wireguard, я решил, что пора изучить это чудо.

Действительность оказалась несколько сложнее, чем я рассчитывал, однако все получилось. И сейчас опишу основные моменты, которые нигде не смог найти, и до которых пришлось доходить самому.

Основные моменты

Взял я MikroTik hAP ac2. Модель старая, без излишеств, но все, что нужно, делает.

Хотя дела с Микротиками я раньше не имел, запустил его достаточно быстро. Были некоторые сложности с тем, что в настройке DHCP Server недостаточно установить Network, чтобы IP адреса начали раздаваться из этой сети. Оказалось, что есть еще и отдельный IP Pool. Но это мелочи. Так что довольно быстро я приступил к настройкам именно Wireguard.

Конечно же, ничего не заработало. Более того, на той стороне я даже не видел входящих пакетов.

Потом уже я обратил внимание, что в поле Endpoint указан только IP адрес, но отсутствует порт. Попробовал указать его явно, но обломался. Поле становится красным и не проходит валидацию.

Пошел разбираться с командной строкой. Для меня, в первый раз увидевшего RouterOS, там, конечно, не сахар. Более-менее, разобрался, конечно. Но как узнать, какие вообще параметры имеются, так и не понял. Ну т.е. до /interface wireguard peers я добрался. Даже про add догадался. Только вот при этом система спрашивала только interface, public-key и allowed-address. В общем, всякими переборами подобрал команду:

add allowed-address=192.168.66.128/25,10.10.0.0/16 endpoint=66.166.166.42:51820 \interface=wg0 persistent-keepalive=30 public-key="многобукв="

Т.е. порт можно указать только через командную строку. Впрочем, все равно не заработало.

Напомню, что wg0 был создан ранее через web-интерфейс. Или WinBox, не помню. Он чуток получше, чем веб-интерфейс, но порт тоже не давал указать. И тут до меня дошло, что на обычном Linux я ведь еще IP адрес своего локального хоста указываю. А тут его не задавал. Заработало только после:

/ip addressadd address=192.168.66.253/24 interface=wg0 network=192.168.66.0

Собственно все :) В сети есть инструкции, как установить Wireguard на Mikrotik с OpenWRT. Но как по мне, это извращение. А вот поднять его в родном RouterOS можно за несколько минут. Когда уже знаешь, как. Работает прекрасно, вообще без нареканий.

P.S. Адреса я, конечно, менял. Но allowed-address=192.168.66.128/25 и add address=192.168.66.253/24 не ошибка. Просто у меня к двум серверам подключение. Половина сети класса С на один сервер, половина на другой.

P.P.S. Почему Wireguard, а не OpenVPN? Например, производительность:

https://blog.entrostat.com/openvpn-vs-wireguard-network-performance-tests/

А еще простота настройки и кое-что по мелочи.

В прошлой статье мы внедрили домашний сервер DoH с использованием Pi-Hole, чем не только пофильтровали большое количество рекламы, но и инкапсулировали наши DNS-запросы в HTTPS, что вывело их из поля фильтрации запросов оператором связи.

Всем замечательно это решение, но у него есть один нюанс. Если вдруг у нас закончились деньги на счету у оператора связи или по каким-то другим причинам пропал канал связи до внешнего мира, мы даже не сможем пополнить счет, чтобы восстановить сервис, потому что не будет работать DNS. Или, например, если наш Pi-Hole по каким-то причинам перестал работать - вот вроде и вся сеть работает, и гугл пингуется, а пока не пропишешь другой DNS-сервер - не будет счастья. А если вы еще в этот момент заняты чем-то другим и не можете приступить к восстановлению незамедлительно - домашние негодуют, портят радостное существование своими жалобами и даже котики, чуя общую нервозность, стремятся нагадить вам в тапки.

Огорчать котиков - дело последнее, поэтому в этой статье я опишу, как вы можете внедрить автоматическое переключение с использования Pi-Hole на использование операторских (как, впрочем, и любых других) DNS при проблемах на Pi-Hole.

TL;DR

Настраиваем автоматическое переключение DNS-сервиса между Pi-Hole и Mikrotik, используя протокол VRRP в реализации демона keepalived.
Никаких волшебных know-how не открывается, простая пошаговая инструкция для тех, кому не хочется разбираться во всех хитросплетениях самому.

Что вам для этого потребуется

1. Внедренное решение Pi-Hole из предыдущей статьи. Понятно, что описываемое решение можно использовать для отказоустойчивости в принципе чего угодно, но в данном конкретном случае мы сосредоточимся на именно этой реализации. Базовый Linux у решения - Ubuntu.

2. Маршрутизатор Mikrotik в качестве бордера. Опять же, подойдет и OpenWRT, и EdgeRouter, и какой-нибудь софтовый на PC, но рассмотреть всё разнообразие в статье не получится никак. Если ваш роутер поддерживает VRRP - он сможет быть частью этого решения, а как конкретно его настраивать, если возникнут сложности, спросите в комментариях к посту. Впрочем, если ваш роутер VRRP не поддерживает - можно всё то же самое построить между двумя Pi-Hole или Pi-Hole и другим DNS-сервером.

Исходные данные

• IPv4-адрес нашего сервера Pi-Hole в домашней сети: 192.168.1.10 и он назначен как статический.

• IPv4-адрес нашего маршрутизатора в домашней сети: 192.168.1.1 и он назначен как статический на интерфейсе bridge маршрутизатора.

• Новый IPv4-адрес DNS: 192.168.1.9

• Настройки на Linux выполняем от root (т.е. перед началом настройки выполняем командуsudo -i).

Логика решения и немного теории

Чтобы не превращать статью в совсем уж деревянную инструкцию "нажмите третьим пальцем левой руки на кнопку W", расскажу самую базовую теорию того, что мы пытаемся сделать.

Итак, название протокола VRRP расшифровывается как Virtual Router Redundancy Protocolи он входит в группу протоколов NHRP (Next-Hop Resolution Protocol). Почему-то многие люди считают, что с использованием этих протоколов можно резервировать только адреса шлюзов по умолчанию, хотя, разумеется, это не так. Самому протоколу совершенно без разницы, какие сервисы с его помощью резервируются, он работает на третьем уровне модели ISO/OSI и фактически просто создает виртуальный IP-адрес, который будет перемещаться между устройствами, входящими в VRRP-группу, по определенным критериям. Очевидно, что такая логика подразумевает существование этого адреса только на одном устройстве, поэтому обеспечить, например, балансировку нагрузки между серверами с помощью стандартного VRRP нельзя (но в нашем случае этого и не требуется). Для тех кейсов, где это необходимо, существует, например, проприетарный протокол Cisco GLBP, где адрес активен одновременно на всех устройствах группы, а балансировка осуществляется за счет разных ARP-ответов. По подобной GLBP логике работает и протокол CARP.

В случае VRRP все устройства, входящие в группу, анонсируют себя через рассылку мультикаст-пакетов на адрес 224.0.0.18, внутри которых передается множество технической информации. Из нее нам важен один параметр - приоритет. Логика простая - все устройства, входящие в группу, меряются приоритетом, у кого длиннее больше, тот и победил и приземлил на себя виртуальный IP группы. Остальные сидят в засаде и ждут, пока победитель зазевается и умрет (перестанет слать нужный мультикаст), в этом случае опять проходят выборы и опять побеждает устройство с наибольшим приоритетом. Если устройств с одинаковым приоритетом несколько - побеждает больший IP-адрес, но хорошим тоном считается таких ситуаций избегать и разруливать приоритеты явно.

Большим плюсом для нас является возможность изменять приоритет на ходу. У Cisco используемая для этого фича, например, называется Enhanced Object Tracking. Но она такая есть у любой известной мне имплементации протокола, в том числе и у линуксового демона.

На основе этой фичи вырисовывается логика всей нашей конструкции:

1. Настраиваем на нашем маршрутизаторе в качестве основных DNS сервера провайдера

2. Настраиваем между маршрутизатором и Pi-Hole VRRP с приоритетами 100 на маршрутизаторе и 90 на Pi-Hole

3. Создаем на Pi-Hole скрипт, проверяющий работоспособность DNS и при успешности повышающий приоритет на Pi-Hole до 110

4. Раздаем домашним клиентам по DHCP наш виртуальный IP-адрес как адрес DNS.

Настройка

1. Настройка DNS на Mikrotik

Если помните, в предыдущей статье мы много обсуждали, какой адрес DNS раздавать клиентам и куда форвардить запросы с маршрутизатора. Для целей же нашего нового решения важно на маршрутизаторе указать в качестве DNS-серверов именно сервера нашего провайдера - чтобы они оставались доступны при блокировке сервиса за неуплату, например. Поэтому или настраиваем получение DNS от оператора по DHCP, или идем в Winbox по пути IP - DNS и в поле Servers прописываем адреса DNS-серверов провайдера.

2. Настройка VRRP на Mikrotik

Создаем новый VRRP интерфейс с привязкой к интерфейсу Bridge и навязываем на него наш виртуальный адрес. Можно сделать в Winbox, но гораздо проще сделать это в терминале:

/interface vrrp add interface=bridge name=vrrp-dns version=2 vrid=10/ip address add address=192.168.1.9/24 interface=vrrp-dns network=192.168.1.0

Здесь vrrp-dns - это имя интерфейса (можете выбрать любое на свой вкус, главное совпасть в обеих командах), vrid - ID группы, можно тоже выбрать любой в диапазоне 1-255, нужно совпасть на обоих устройствах. Имя интерфейса bridge и IPv4-адреса нужно скорректировать под вашу домашнюю сеть.

После выполнения этого действия можно попинговать 192.168.1.9 - он уже должен отвечать с маршрутизатора, если пинг не закрыт файрволом.

3. Настройка VRRP на Pi-Hole

Устанавливаем демон keepalived:

apt install keepalived

Создаем файл конфигурации демона /etc/keepalived/keepalived.conf:

! Configuration File for keepalivedvrrp_script check_dns {  script "/etc/keepalived/check_dns.sh"  interval 5 # every 5 seconds  weight 20 # add 20 points if OK  timeout 5 #   rise 2 # avoid dampening  fall 2 # avoid dampening}vrrp_instance VI_1 {    state MASTER    interface ens160    virtual_router_id 10    priority 90    advert_int 1    virtual_ipaddress {        192.168.1.9/24    }    track_script {        check_dns    }}

Здесь обратите внимание на имя интерфейса, на котором сейчас работает Pi-Hole - в примере дефолтное ens160, у вас может быть другое (проверить можно, например, через команду ifconfig).

Создаем скрипт проверки живости DNS /etc/keepalived/check_dns.sh:

#!/bin/bashhost -s -4 amazon.com 127.0.0.1 > /dev/null 2>&1

и не забываем сделать его исполняемым:

chmod +x /etc/keepalived/check_dns.sh

С методикой проверки DNS вы можете экспериментировать как угодно. Для себя я выбрал проверку резолвинга адреса amazon.com. Плюс этого варианта в том, что TTL этой записи - 1 минута, поэтому дольше чем на минуту ваш Pi-Hole закэшировать запись не сможет и, соответственно, на это время максимум и отложится убегание сервиса в случае потери связи с миром. Основной принцип, который надо помнить - если скрипт выдает 0 в качестве error code, то keepalived будет считать, что всё хорошо, и добавит приоритета. Любой другой error code - и адрес уползет на Mikrotik.

Теперь достаточно перезапустить сервис:

systemctl restart keepalived

и всё заработает. В логе Mikrotik можно будет увидеть запись, подобную этой:

vrrp-dns now BACKUP, got higher priority 110 from 192.168.1.10

Вы можете проверить, что теперь на адресе 192.168.1.9 отвечает Pi-Hole, самый простой способ проверки - это резолвинг имени pi.hole:

nslookup pi.hole 192.168.1.9Server:192.168.1.9Address:192.168.1.9#53Name:pi.holeAddress: 192.168.1.10

Обратите внимание, что резолвиться будет в адрес сервера Pi-Hole, а не в наш виртуальный IP - это правильно и так и должно быть.

4. Настройка DHCP на Mikrotik

Ну и наконец нам надо научить DHCP-сервис Mikrotik раздавать клиентам правильный адрес DNS. Это удобнее сделать из WinBox - там вы увидите все свои пулы. Идем по пути IP - Networks, смотрим глазами на все сети, которые у вас связаны с Pi-Hole сейчас и изменяем поле DNS Servers с адреса Pi-Hole 192.168.1.10 на виртуальный адрес 192.168.1.9.

Обновляем аренду адреса на компьютерах, проверяем, что получили правильный адрес DNS, проверяем, что резолвинг работает (например, командой nslookup pi.hole - уже без прямого указания имени используемого сервера). Радуемся.

Особо ответственные могут каким-либо образом сломать своему DNS-серверу резолвинг и проконтролировать, что по истечении таймаута виртуальный адрес переползет на Mikrotik. Но это уже зависит от вашей фантазии.

Заключение

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

На вопросы, традиционно, отвечу и с настройками помогу.

Если в магазине вас угораздило купить роутер MikroTik себе домой и вы не знаете зачем он вам, а отравление DNS кэша вашим провайдером не дает вам спать по ночам, то этот пост для вас.

Можно не мучаться и поставить DNS от Yandex, Google, Adquard и прочее, а можно пойти более сложным путем:

Открываем сайтhttps://root-servers.orgи ищем свой город, смотрим какие там есть корневые сервера DNS

В Питере их 5

Если их несколько, выбираем какой больше нравится вам :)

Далее находим официальный сайт данной компании, в моем случае этоhttps://www.verisign.com и на сайте ищем раздел с публичным DNS.

В данном случае нас перенаправляют на сайтhttps://www.publicdns.neustar, идем туда и копируем адреса в блокнот :)

Открываем WinBox или через http, кому как больше нравится.

1. Первым делом удаляем автополучение DNS провайдера:

открываем настройки интерфейса и убираем галочку "use peer dns"

2. В настройке DNS (IP -> DNS), вводим IP DNS сервера (начиная с сервера который у вас в городе). Размер кэша укажите сколько не жалко (учитывайте свободное место).

На этом можно было бы закончить, но мы пойдем далее.

Помимобелыхофициальных DNS резолверов есть еще итемная сторонаальтернативные корневые серверы DNS, например, выберем OpenNIC (остальные добавляются подобным образом). Нас интересуют поддерживаемые доменыhttps://www.opennic.org:

и IP адресаhttps://wiki.opennic.org/#anycast_tier_2_dns_resolvers

Далее открываем терминал и добавляем статические маршруты

/ip dns static add comment="OpenNIC" forward-to=185.121.177.177,169.239.202.202,2a05:dfc7:5::53::1,2a05:dfc7:5::5353::1 regexp=".*(\\.bbs|\\.chan|\\.cyb|\\.dyn|\\.geek|\\.gopher|\\.indy|\\.libre|\\.neo|\\.null|\\.o)\$" type=FWD

/ip dns static add comment="OpenNIC" forward-to=185.121.177.177,169.239.202.202,2a05:dfc7:5::53::1,2a05:dfc7:5::5353::1 regexp=".*(\\.oss|\\.oz|\\.parody|\\.pirate|\\.opennic.glue|\\.dns\\.opennic\\.glue)\$" type=FWD

Проверяем

В настройках DNS делаем очистку кэша.

Если пользуетесь Microsoft Edge, отключаем "улучшайзеры", в других браузерах аналогично.

Ребутим все что можно отребутить :)

и наслаждаемсяhttps://www.dnsleaktest.com

Что мне это дало? Нормально заработали уведомления от mihome, перестали "тупить" китайские лампочки :) Ну и немного ощущаешь себякулхацкеромчуть более независимым от своего провайдера :)