В Ubuntu подключение к сети настраивается с помощью сервиса Network Manager. Чтобы подключиться к сети, достаточно пару раз кликнуть мышкой, выбрать соединение — и готово. То же самое, и даже ещё проще, при использовании проводного соединения — тут интернет подключается автоматически, как только загрузился апплет.
Но не всегда доступен графический интерфейс: после неудачной установки драйвера или очередного обновления не запускается графическая оболочка, а на серверах она и вовсе не используется. В этой небольшой инструкции будет разобрана настройка сети Ubuntu из консоли. Мы поговорим о том, как настроить получение IP-адреса по DHCP, а также настроить работу DNS. Рассмотрим ручную и автоматическую настройку, также попробуем сделать это через системные конфигурационные файлы.
Данная инструкция будет состоять из двух основных частей — установка программного обеспечения и примеры по его настройки под различные задачи. Мы рассмотрим примеры работы на системах Linux Ubuntu и Rocky Linux (CentOS).
Установка, настройка системы и запуск
1. Установка выполняется немного, по-разному, в зависимости от выбранного дистрибутива Linux. Рассмотрим примеры систем на базе Deb и RPM.
а) Для Debian / Ubuntu (Deb):
apt install dnsmasq
б) Для Rocky Linux / CentOS (RPM):
yum install dnsmasq
Установка завершена.
После установки или старта сервиса мы можем увидеть ошибку:
failed to create listening socket for port 53: Address already in use
Как правило, она связана с тем, что на компьютере работает сервис systemd-resolved, который занял порт 53. Чтобы это исправить, отключаем его:
systemctl disable systemd-resolved --now
2. После установки разрешим автозапуск сервиса.
Вводим команду:
systemctl enable dnsmasq
Для систем на базе RPM также необходимо запустить сервис:
systemctl start dnsmasq
3. Настраиваем брандмауэр. Нам необходимо открыть UDP порт 53.
Как правило, используется 2 системы управления netfilter — iptables и firewalld. Рассмотрим обе.
а) При использовании iptables (как правило, для систем на базе Deb):
Наш dnsmasq установлен и готов к дальнейшей настройке.
Примеры настройки dnsmasq
Переходим к основной части инструкции. Приведем примеры использования и соответствующей настройки dnsmasq.
1. Перевод запросов на другой DNS-сервер для определенного домена
Предположим, у нас есть задача — переводить все запросы для имен с доменом consul на другой DNS-сервер, который находится в нашей сети. Также, данный сервер слушает не на стандартном для NS-сервера порту (53), а на порту 8600. Кстати, это реальный пример работы при настройке кластера consul.
Создаем конфигурационный файл:
vi /etc/dnsmasq.d/consul
В него добавим одну строку:
server=/consul/127.0.0.1#8600
* в данном примере мы будем переводить все запросы для домена consul на сервер 127.0.0.1 (в этом примере локальный сервер, но может быть любой) и порт 8600.
Если мы работаем в системе с включенным SELinux и переводим запросы на нестандартный порт, то необходимо добавить правило:
semanage port -a -t dns_port_t -p tcp 8600
* где 8600 — порт, на который переводим запросы DNS.
Чтобы настройки вступили в силу, перезапускаем dnsmasq:
systemctl restart dnsmasq
2. Настройка кэширования
По умолчанию, dnsmasq работает как кэширующий сервер. Мы же подредактируем настройки.
Создаем конфигурационный файл:
vi /etc/dnsmasq.d/cache
cache-size=10000 all-servers no-negcache
* где:
cache-size — размер кэша (количество хостов).
all-servers — задает поведение, при котором наш сервер будет отправлять запрос всем доступным ему серверам DNS и принимать ответ от того, кто первый ему ответит.
no-negcache — не кэшировать негативные ответы.
Чтобы настройки вступили в силу, перезапускаем dnsmasq:
systemctl restart dnsmasq
3. Подмена IP-адресов
Есть несколько вариантов подмены IP-адресов в dnsmasq. Для настройки создадим файл:
vi /etc/dnsmasq.d/replacement
В зависимости от ситуации, применяем один из вариантов, описанных ниже.
а) Подмена одного адреса:
alias=1.1.1.1,2.2.2.2
* в данном примере если наш сервер получит ответ 1.1.1.1, он его заменит на 2.2.2.2.
б) Подмена адресов в подсети:
alias=1.1.1.0,2.2.2.0,255.255.255.0
* в данном примере все адреса из подсети 1.1.1.0/24 будут заменены на соответствующие адреса подсети 2.2.2.2/24.
* в нашем примере dnsmasq будет знать о двух записях — dmosk.local и mail.dmosk.local. Первая будет разрешаться в два адреса.
Выполняем команду:
systemctl restart dnsmasq
5. Форвард запросов на другой сервер
С помощью опции server мы можем указать серверы, на которые нужно передавать запрос DNS.
vi /etc/dnsmasq.d/forwards
server=8.8.8.8 server=8.8.4.4
* в данном примере мы передадим запросы на серверы Google.
Применяем настройку:
systemctl restart dnsmasq
6. Файл hosts
В зависимости от ситуации, нам может потребоваться разрешать некоторые имена с помощью файла /etc/hosts. Или наоборот — настройки из данного файла могут нам мешать.
В dnsmasq предусмотрена директива hosts, с помощью которой мы можем манипулировать результатами с использованием файла hosts.
vi /etc/dnsmasq.d/hosts
а) Если мы хотим, чтобы данные из файла учитывались:
hosts
б) Если нам не нужны данные из файла:
no-hosts
Применяем настройку:
systemctl restart dnsmasq
Это, далеко, не все возможности dnsmasq. По мере необходимости, они будут дополняться в данной инструкции.
Диагностика и решение проблем
По умолчанию, dnsmasq пишет не очень много логов. Чтобы это исправить, необходимо отредактировать конфигурацию. Для этого создаем файл:
Сегодня научимся переименовывать сетевые интерфейсы на операционной системе Debian.
Рассмотрим два способа для переименования наших интерфейсов.
Первый способ будет основан на редактировании файлов сервиса systemd и перезагрузки последнего – данный способ пригодится, если вы хотите переименовать интерфейсы без перезагрузки системы.
Второй способ подразумевает редактирования файла GRUB – при данном способе будет необходима перезагрузить ПК.
И так приступим!
Переименовываем сетевой интерфейс с помощью systemd
Для того чтобы переименовать сетевой интерфейс в Debian 10 воспользуемся сервисами systemd.
Создаем файл, например 01-eth0.link :
sudo nano /etc/systemd/network/01-eth0.link
со следующей информацией:
[Match] MACAddress=aa:bb:cc:dd:ee:ff
[Link] Name=eth0
После этого создаем ещё один файл:
sudo nano/etc/systemd/network/02-eth0.network
со следующей информацией:
[Match] Name=eth0
[Network] Address=192.168.1.1
Перезапускаем службу systemd-networkd:
sudo systemctl restart systemd-networkd
Наш файл 01-eth0.link обрабатываются с помощью systemd-udev-trigger, поэтому для перезагрузки *.link файлов воспользуемся командой ниже:
В этой статье мы рассмотрим, как защищать роутер MikroTik от атак и сканеров портов, а также предотвратим попадание нашей сети в бан-листы. Полученный опыт поможет тебе настраивать и другие виды файрволов.
Если у тебя большая сеть с несколькими филиалами и в каждом из них по два роутера для отказоустойчивости, то правила лучше настроить так, чтобы их можно было легко развернуть на любой железке, независимо от количества и именования портов или типа подключения. Для соединения по PPPoE, например, WAN-интерфейсом будет pppoe-out1, а для DHCP — ether1. Если попытаться экспортировать конфиг файрвола с одного роутера на другой, ничего не выйдет, потому что у второго просто нет интерфейса pppoe-out1. Или представь себе, что в одном филиале локальная сеть висит на ether9, а в другом стоит роутер с пятью портами, из-за чего конфигурация девятого порта просто не встанет и вылетит с ошибкой.
Поэтому мы будем настраивать роутер так, чтобы конфиг можно было без проблем перенести на любой другой роутер. Это немного усложнит первоначальную настройку, но сэкономит кучу времени в будущем.
Мы уже рассматривали списки интерфейсов. Это фича для оперирования несколькими интерфейсами как одним. Создадим листы WAN и LAN, а затем добавим туда нужные интерфейсы. Теперь правила файрвола будем привязывать к интерфейс-листам, а не к отдельным интерфейсам. Перед экспортом правил на другой роутер просто создадим на нем нужные листы, и конфиг встанет без ошибок.
Interface List
Обрати внимание, что для использования в файрволе нам нужны L3-интерфейсы, то есть те, на которых есть IP-адреса. Если ты получаешь интернет по PPPoE, то в WAN-лист надо добавить именно его. Если IP локальной сети прописан на бридже или VLAN’е, то и в лист LAN нужно добавить их, а не физические интерфейсы. Если включить в список и логический, и физический интерфейс, ничего страшного произойти не должно, но это нужно будет учитывать в конфигурации.
Но это еще не все. Понятно, что в каждом филиале у нас будет своя подсеть LAN: где-то 192.168.10.0/24, где-то 192.168.11.0/24. Чтобы не путаться с этими значениями и не менять конфиг при переносе с одного роутера на другой, оперировать будем не адресами и подсетями, а списками адресов. На каждом роутере создаем список LAN и дальше работаем только с ним.
В прошлый раз мы создавали адрес-лист MGMT, в котором открывали доступ к управлению роутером только с определенных адресов. А еще раньше рассматривали решение Port Knocking, которое предоставляет доступ к управлению, только если со стороны клиента выполнить секретные манипуляции. Для доступа к роутеру из доверенной сети (LAN) вполне подходит вариант с адрес-листом, а для доступа снаружи — Port Knocking. Было бы хорошо совместить эти варианты в нашей конфигурации. Еще будет удобно разделить цепочку input на две части: input со стороны интернета и input со стороны локалки. Тогда можно применять разные политики фильтрации к разным сегментам сети. В этом нам помогут пользовательские цепочки.
Все, что пришло снаружи, перекидываем в новую цепочку WAN_INPUT. Все, что изнутри, — в LAN_INPUT:
Теперь политики фильтрации будут разными для разного источника трафика. Для внешнего трафика будем использовать цепочку WAN_INPUT и более жесткие ограничения, для внутреннего — LAN_INPUT и правила попроще. Цепочка input нам больше не нужна, теперь мы все будем делать в новых цепочках. Причем указывать интерфейсы или списки интерфейсов в правилах больше не понадобится. Однако этот подход может использоваться в сложных решениях, например когда у тебя два провайдера с разными политиками фильтрации или локалка поделена на разные VLAN. Но об этом позже.
В статье о безопасной настройке роутера мы настраивали Port Knocking для доступа к управлению роутером. Ограничивать таким образом доступ изнутри локальной сети — излишество. Поэтому поменяем в правилах цепочку с input на WAN_INPUT. Изнутри сети разрешим доступ к WinBox только с нужных адресов: мы уже делали это в статье про основы файрвола. Оставим в правиле только порт WinBox — TCP 8291. А для SSH разрешим подключения из всей нашей сети, но предотвратим возможность брутфорса (да, изнутри сети тоже может произойти брутфорс SSH, потому что отсутствие троянов в ней не гарантировано).
Тут применяется механизм динамических адрес-листов с тайм-аутами. Мы рассматривали их в статье «Защищаем MikroTik. Хитрости безопасной настройки роутера». При первой попытке подключения пакет обработается правилом 5, и адрес хакера попадет в адрес-лист ssh_stage1. Вторая попытка подключения обработается правилом 4 и добавит брутфорсера в лист ssh_stage2. И так далее вплоть до листа ssh_blacklist, где адрес будет храниться десять дней, а весь трафик, идущий с адресов из этого списка, будет дропаться.
В прошлой статье мы создавали правила, разрешающие коннекты established, related и запрещающие invalid. Давай продублируем эти правила и перенесем их в новые цепочки, а из input удалим. В результате мы получим четыре правила вместо двух. На прохождение трафика это не повлияет, зато позволит видеть статистику по трафику с разных сторон. В правиле с established, related поставь галочку untracked. Чуть позже объясню, зачем она. Думаю, адаптировать остальные правила под новую логику не составит труда. В конце каждой цепочки не забудь указать правило дропа.
Должно получиться примерно так
Две цепочки позволят нам уменьшить количество переходов трафика по правилам, а значит, и немного снизить нагрузку на CPU. Счетчики в разных цепочках дадут возможность увидеть чуть более детальную статистику трафика. Хоть правил и стало больше, но они не применяются ко всему объему трафика: при первом джампе весь трафик будет обрабатываться уже новой цепочкой и в другую никогда не попадет. Подобный подход также упрощает поддержку за счет того, что по названию цепочки сразу видно, что это за трафик и откуда он идет. Можно для разных типов трафика создавать свои цепочки, например отдельную цепочку для management-трафика. За возврат трафика в родительскую цепочку отвечает action return.
Защищаемся от атак
До сих пор мы рассматривали правила файрвола, позволяющие обрабатывать трафик по простым признакам: интерфейсу, адресу, порту. Но файрвол гораздо более гибкий инструмент, с его помощью можно строить сложную логику для противодействия разным типам атак.
Есть зарезервированные адреса, которые не используются в интернете. Они называются «богон-адресами». Отсечем пакеты с таких адресов:
Мы ожидаем пакеты только с юникаст-адресов, поэтому запретим все, кроме них.
Drop non unicast
Port Scan Detect — функция, позволяющая обнаружить сканер портов. Как она работает? Портам задается некий условный вес — Weight. Причем для системных портов (до 1024-го) весовой коэффициент низкий (Low ports), а для остальных — высокий (High ports). Если в течение времени Delay Threshold от одного хоста на роутер прилетят пакеты на порты, сумма весов которых окажется больше, чем Weight Threshold, то адрес отправителя будет добавлен в блек-лист. В нашем примере, если с одного хоста за три секунды поступят десять пакетов на порты до 1024-го (общий вес 10 * 2 = 20) и двадцать пакетов на порты выше 1024-го (20 * 1 = 20), общий их вес составит 40. Обрати внимание, что Port Scan Detect работает только для TCP- или UDP-трафика.
Защищаемся от сканеров
Один из самых распространенных видов атак — это атака на отказ в обслуживании, или DDoS. Защититься от нее своими силами практически нереально. Но с помощью простого правила можно отсечь самые простые попытки атаки. Находим хост, который насоздавал к нам больше 100 сессий, и добавляем его в блек-лист. В этом правиле обязательно нужно использовать параметр connection-state=new. Но мы ведь уже разрешили все established, related и untracked, а invalid дропнули, поэтому сюда дойдут только пакеты new. Оставлять или нет этот флажок в правиле — твое дело. Отмечу, что с помощью этой же фичи можно выявлять в своей сети торрентокачальщиков.
Защищаемся от DDoS
ICMP — один из важных протоколов в любой сети. Многие админы любят блокировать его, но это очень плохой подход. Именно ICMP позволяет работать трассировке, указывать на недоступность UDP-портов, отправлять разные служебные сообщения. И если запретить его полностью, можно наловить кучу багов. У каждого сообщения ICMP свое предназначение, и уже по этому параметру нетрудно понять, имеет ли смысл разрешить какие-то типы ICMP изнутри сети или снаружи. Например:
ICMP Echo Request — наш любимый пинг, имеет тип 8, код 0;
ICMP Echo Reply — ответ на пинг, тип 0, код 0;
Destination Unreachable — узел недоступен, тип 3 и коды 0–15 в зависимости от причины недоступности:0 — сеть недоступна;
1 — хост недоступен;
2 — протокол недоступен;
3 — порт недоступен;
4 — необходима фрагментация пакета, но она запрещена (стоит флаг DF — Don’t Fragment).
Остальное легко найти в интернете, а лучше почитать RFC 792.
Создадим цепочку ICMP и отправим в нее весь ICMP-трафик (можно создать две цепочки: для LAN и WAN — и настроить разные политики). Разрешаем только нужные типы сообщений и ограничиваем обработку пятью пакетами в секунду:
TCP тоже поддерживает кучу флагов, часть которых не может содержаться в одном пакете. Комбинации этих флагов часто используются сканерами портов, чтобы пробить плохо настроенную защиту. Сделаем отдельную цепочку для TCP и дропнем подобные «подозрительные» пакеты:
До сих пор мы в основном смотрели на трафик, прилетевший в input-цепочку, а дальше по каким-то признакам направляли его в разные цепочки. Но весь этот трафик предназначался самому роутеру. Цепочку output используют редко, но ты можешь отфильтровать в ней, например, ICMP-ответы от роутера или IPsec-трафик. Понятно, что большая часть трафика будет попадать в forward — ведь на то он и роутер, чтобы перенаправлять пакеты из одной сети (локалка) в другую (интернет или второй VLAN локалки). И в этой цепочке мы будем управлять трафиком пользователей.
Я не стану детально рассказывать о том, что надо разрешить или запретить, — об основных приемах настройки и так уже написано несколько статей и есть куча примеров в интернете. Рассмотрим более интересный кейс: репутацию сети.
В интернете есть сервисы, содержащие списки спамеров, ддосеров, распространителей нелегального контента. Если на машины в твоей сети попал троян-спамер, то ты тоже окажешься в этих списках. Через какое-то время письма от любого клиента изнутри сети начнут попадать в спам у всех получателей, потом ты будешь добавлен в публичные блек-листы и у пользователей исчезнет доступ ко многим ресурсам. В том числе к сетям партнеров, админы которых пользуются такими списками, чтобы запретить доступ потенциальным вредителям. Представь, что произойдет с твоей премией, когда письмо с многомиллионным контрактом от твоего шефа упадет у контрагента в папку «Спам».
Попробуем защитить свою премию. Для этого нужно понять, по какому поводу нас могут внести в списки. Причин этому несколько:
мы часть DoS- или иного ботнета;
мы рассылаем спам;
с наших адресов брутфорсят чужие сервисы;
мы нарушаем авторские права (раздаем торренты).
Некоторые читатели этой статьи вполне могли участвовать в DDoS-ботнете, сами того не осознавая. Атаки UDP Amplification основаны на некорректных настройках сервисов, когда можно обратиться к ним с просьбой узнать что-то у другого сервера. Например, к нам может прилететь DNS-запрос с просьбой отрезолвить адрес жертвы. И таких, как мы, миллионы. Когда к жертве поступит миллион пакетов в секунду, она не обрадуется, а мы увидим загрузку CPU под 100%, жуткие тормоза и однажды окажемся в блек-листе. Такая же схема работает и с другими UDP-сервисами, например NTP. Вывод простой: блокируй трафик к этим сервисам снаружи. Но это все еще про INPUT.
Не только роутер может быть частью такого ботнета, но и машины внутри сети. Для детекта таких хостов воспользуемся уже известной фичей connection limit.
По порту назначения можно определить, к какому сервису обращаются хосты изнутри нашей сети. И если это общеизвестный порт, например СУБД, а все наши базы расположены внутри периметра, логично предположить, что сотни пакетов в секунду к этому порту в интернете с компьютера бухгалтера — не простая ошибка и не личный интерес самого бухгалтера. Дропаем подозрительные пакеты и возвращаемся в родительскую цепочку (последнее правило):
Мы рассмотрели более продвинутые методы настройки файрвола. Эту статью не нужно воспринимать как инструкцию по настройке: у каждой сети свои особенности и сервисы. Роутеры у всех тоже разные — у кого-то он спокойно обработает тысячи неоптимизированных правил файрвола, для других сотня правил будет обрабатываться с трудом. Поэтому подходи к настройке файрвола с умом.
В две статьи всё не вместишь, и мы не затронули еще несколько больших тем: таблицы NAT, RAW, IPv6 Firewall, Bridge Firewall, фильтрацию по контенту, определение типа трафика по его содержимому (когда мы меняем порт у HTTP, а файрвол все равно понимает, что внутри HTTP), проксирование трафика.
Все эти темы рассматриваются в официальном обучающем курсе MikroTik — MikroTik Certified Traffic Control Engineer. Но чтобы на него попасть, нужно пройти курс MikroTik Certified Network Associate, где изучаются общие принципы настройки роутера и работа TCP/IP.
Представьте задачу: необходимо обеспечить стабильным интернетом и покрыть бесшовным Wi-Fi здание площадью 300 м2 с возможной расчетной нагрузкой до 100 человек. На первый взгляд, “вроде изян”. Но стоит добавить пару деталей, и задача усложняется:
здание стоит в лесопарковой зоне, где нет оптики, так что наш вариант – мобильная связь;
нужно обеспечить регулярные видеотрансляции, то есть добиться стабильного интернета при единственном GSM-провайдере;
бюджет ограничен.
Итого: потери и отвалы от базовой станции подкрадываются в самое неподходящее время.
Такие проблемы я встречал у колл-центров без выделенных каналов связи, передвижных репортерских комплексов, критически важных удаленных систем. Трудности могут возникнуть не только в случае с VoIP и стримингом видео, но и с любым запросом на гарантированный канал доставки чувствительного к потерям трафика. К сожалению, не всегда есть возможность подвести оптику и закупить дорогостоящее оборудование.
В статье покажу, как в одном проекте я решил эти задачи “дешево и сердито” – такой вариант подойдет малому бизнесу. В конце предложу варианты решения для менее скромного бюджета – для крупных заказчиков.
Схема решения вкратце
Итак, при первом столкновении с проблемой отвалов я начал с агрегации частот и убедился, что это не поможет. Смена категории LTE-модема с Cat4 на Cat6 или – еще круче – Cat12 давала преимущество в скорости, но в потерях и отвалах – нет. Пришел к выводу, что нужен второй LTE-провайдер. При этом при переключении не должен потеряться ни один кадр и трансляция не должна отвалиться.
На помощь пришла такая связка: агрегация, она же bonding, и TCP-OpenVPN-туннель поверх этого.
в облаке создал “сервер агрегации” – виртуалку с CLOUD HOSTED ROUTER (CHR) на базе Router OS;
на ней поднял L2TP-сервер с включенным шифрованием IPsec;
поверх L2TP over IPsec создал два EoIP-туннеля;
EoIP-туннели агрегированы bonding-интерфейсом;
вишенка на торте – TCP-шный OpenVPN-туннель.
Итоговая схема:
Вместо виртуальной машины в дата-центре в качестве R1 может выступать любая железка с достаточной производительностью. Например, тот же MikroTik серии CCR, компьютер, размещенный где угодно. Главное – позаботиться о производительности и стабильных каналах связи, использовать схемы активного резервирования (VRRP в помощь).
Поддержка OpenVPN UDP реализована только в 7-й версии RouterOS, поэтому в этой конфигурации безальтернативно используется протокол TCP.
Сейчас схема стабильно работает, но нет предела совершенству. Для надежности можно добавить еще LTE-провайдеров или проводные каналы связи, когда такая возможность появится.
Теперь расскажу подробнее о строительстве схемы. Начнем с R1 (облачного маршрутизатора) и – далее – R2 (филиального).
Маршрутизатор R1
Сначала берем второй белый IP в дата-центре. У меня CHR находился за Edge в облаке VMware, так что обязательно пробрасываем порты на Edge UDP 1701, 500 и 4500 NAT-T – IPSec Network Address Translator Traversal. Также делаем разрешающее правило в межсетевом экране Edge.
Добавляем в таблицу firewall filter разрешающее правило доступа к маршрутизатору извне для портов UDP 1701, 500 и 4500. Если у вас белые IP непосредственно на маршрутизаторе без пробросов через Edge, галочку NAT Traversal НУЖНО СНЯТЬ!Проверяем дефолтный IPsec-профиль:
/ip ipsec profile
set [ find default=yes ] dh-group=modp1024 enc-algorithm=3de
Создаем профиль для L2TP-туннелей:
/ppp profile
add change-tcp-mss=no name=profile01 use-compression=no use-encryption=no use-mpls=no use
Тут важно заметить, что в поле mode (режим работы bonding-интерфейса) я указал broadcast, чтобы пакеты отправлялись сразу по двум тоннелям. Таким образом потеря пакета на любом из двух интерфейсов не приведет к потере пакета на bonding-интерфейсе. Остальные значения устанавливаем, как на картинке.
Активируем OpenVPN-сервер
Так как у меня OpenVPN использовался еще и для внешних подключений, то я предварительно сгенерировал сертификаты и импортировал их в CHR. На этом останавливаться подробно не буду.
Создаем /ppp profile и /ppp secret для OpenVPN:
/ppp profile
add change-tcp-mss=no name=profile02 use-compression=no use-encryption=no use-mpls=no use
/ppp secret
add local-address=172.16.2.1 name=ovpn_over_bonding1 password=ros7.elements.forever profile=profile02 remote-address=172.16.2.2 service=ovpn
/interface ovpn-server server
set auth=sha1 certificate=server.crt_0 cipher=aes256 default-profile=profile02 enabled=yes keepalive-timeout=30 port=1194 require-client-certificate=yes
Обязательно прописываем в nat-таблицу межсетевого экрана правило для нашей серой филиальной сети за маршрутизатором R2, чтобы трафик выходил наружу через R1:
Первым делом прописываем маршруты от одного интерфейса LTE-модема до одного белого IP-адреса дата-центра. Запрещаем в настройках межсетевого экрана в цепочке output прохождение пакетов с другого интерфейса:
Создаем EoIP-туннели по аналогии с R1, только меняем местами local и remote IP L2TP/IPsec-линков маршрутизатора R2. Bonding-интерфейс такой же, как на R1:
Туннели загорелись волшебной буквой R, а EoIP – еще и RS. OpenVPN тоже завелся. Теперь можно направлять трафик с компьютера трансляций в наш слоеный бутерброд – в OpenVPN-туннель. Для этого создаем правило /ip firewall mangle и прописываем сразу новую таблицу маршрутизации:
При развертывании конфигурации на действующем железе нужно обязательно переключить прямой и обратный маршруты с туннелей L2TP на OpenVPN-туннель. Если, например, переключить только прямой маршрут, а обратный оставить на L2TP вместо OpenVPN, агрегация полностью работать не будет и пакеты все равно будут теряться.
Утилиты RouterOS в разделе /tools очень полезны при траблшутинге. Еще неплохо работает связка /tools Packet Sniffer + Wireshark.
Не забудьте “поиграться с mtu”, чтобы достичь лучшей производительности туннелей.
Качество сигнала никто не отменял. RSRP, RSRQ и SINR покажут, насколько все хорошо. При большом удалении от базовой станции и плохом сигнале помогут внешние направленные антенны.
Важно! Если провайдер фильтрует трафик и идет блокировка L2TP, то можно поднять другие туннели в качестве основы для EoIP, например: OpenVPN или SSTP.
Чтобы проверить все в деле, можно сымитировать сбой. Отключаем любой из LTE-интерфейсов или создаем потери искусственно: добавляем в межсетевой экран правило частичной блокировки пакетов и указываем при создании нового правила значение в поле random.
Что еще можно улучшить и оптимизировать
Не рекомендую заворачивать весь интернет-трафик, так как это вызовет повышенные накладные расходы (утилизация процессоров, каналов и др.). Лучше пользоваться маркировкой для гарантированной доставки действительно необходимого трафика, а все остальное отправлять на LTE-провайдеров. К примеру, я так делал с загрузкой видеофайлов на облачный диск.
QOS – хорошая штука, особенно на каналах LTE, и особенно с VoIP. Не забываем про это, чтобы остальной трафик не забил и так не слишком широкий канал.
Можно усилить безопасность, если ограничить подключение извне к портам для L2TP и IPsec маршрутизатора R1. Указываем белый IP LTE-провайдера с помощью firewall и адресных листов. Хоть адрес и из NAT и на нем висит не один клиент, все равно будет лучше. Так как IP динамический, то нужно включить на MikroTik функцию ip – cloud, чтобы DNS-сервера всегда знали актуальный IP, технология DDNS.
Конечно же, у схемы есть коммерческие аналоги с возможностями работы из коробки, например: peplink MAX HD4 LTE и тому подобное оборудование, – агрегирующие соединения. Тут бизнес сам оценивает их стоимость для себя.
