Ubuntu Server is one of most popular open-source Linux Server distribution. It is stable and reliable than other Linux distributions. So, enterprise level application can be hosted on Ubuntu Server. Ubuntu RADIUS Server is popularly used for remote authentication and mostly used with the freeRADIUS open source RAIDUS application.
freeRADIUS is one of the most popular and powerful AAA (Authorization, Authentication and Accounting) application. Any enterprise (specially ISP company) can use freeRADIUS for AAA solution and can develop billing system. freeRADIUS can be easily installed and configured in Ubuntu Linux Server and can be used as Ubuntu RADIUS Server.
In my previous article, I discussed how to installed Ubuntu Linux Server with LVM and in this article I am going to discuss how to install and configure freeRADIUS daemon in Ubuntu Linux Server and how to use Ubuntu RADIUS Server with freeRADIUS.
How to install and configure freeRADIUS in Ubuntu Server
freeRADIUS installation in Ubuntu Server
freeRADIUS package is available in Ubuntu Server package repository. At the time of writing this article, the available version of freeRADIUS is freeRADIUS 3. You can find the current available version with the following command.
# sudo apt search freeradius
With the above command, you will find a lot of freeRADIUS packages available in Ubuntu Repository. Among these packages, we will only install the basic freeradius and freeradius-utils package initially.
Issue the following command to install freeRADIUS basic packages in Ubuntu Server.
# sudo apt install freeradius freeradius-utils -y
Within few times, the freeRADIUS daemon will be installed in your Ubuntu Server. You can verify freeRADIUS installation in Ubuntu Server with the following command.
# sudo apt list –installed | grep freeradius
Managing freeRADIUS Service in Ubuntu Server
The freeradius service will be started by default after installing the freeradius package. We can see the status of the freeradius service with the following command.
# sudo systemctl status freeradius
We will now find that the freeradius service is active and running. To make it start automatically when Ubuntu Server rebooted, issue the following command.
# sudo systemctl enable freeradius
We can also start or restart the freeradius service with the following two commands respectively.
If we need to stop the freeradius service for any reason, we can issue the following command.
# sudo systemctl stop freeradius
Testing freeRADIUS Installation and Default Configuration
To test and debug freeRADIUS installation and configuration as well as freeRADIUS data send and receive, we can run freeRADIUS as debug mode. To run freeradius as debug mode in Ubuntu Server, issue the following command but make sure the freeradius service is stopped.
# sudo freeradius -X
With the above command, you will find the following output at the bottom that means your server is ready to accept NAS authentication, authorization and accounting request.
Listening on auth address 127.0.0.1 port 18120 bound to server inner-tunnel Listening on auth address * port 1812 bound to server default Listening on acct address * port 1813 bound to server default Listening on auth address :: port 1812 bound to server default Listening on acct address :: port 1813 bound to server default Listening on proxy address * port 54279 Listening on proxy address :: port 52868 Ready to process requests
Allowing RADIUS Ports in Firewall
From the above command, you can see that freeradius is listening the auth (Authorization and Authentication) request on UDP port 1812 and the acct (Accounting) request on UDP port 1813. So, we have to keep allowed these UDP ports in our installed firewall in Ubuntu Server. As I am fond of Firewalld daemon for firewalling in Ubuntu Server, I am showing how to enable these UDP ports in firewalld service. If you use any other firewall daemon, use that service to allow these two UDP ports.
Issue the following command to allow these ports in firewalld service (on public zone, if you have any other zone, enable these ports on that zone also if required).
freeRADIUS Server Basic Configuration in Ubuntu Server
We will now do FreeRADIUS basic configuration which includes RADIUS client (NAS) and RADIUS User configuration. In Ubuntu FreeRADIUS Server, all the configuration files are placed in /etc/freeradius/version_number directory. So, go to this directory and open clients.conf file.
# cd /etc/freeradius/3.0/ # vim clients.conf
In this file, a default RADIUS client named localhost is configured by default for testing purpose. So, we will use this client for testing FreeRADIUS configuration. The default configuration of the localhost client looks like the following lines.
client localhost { ipaddr = 127.0.0.1 secret = testing123 require_message_authenticator = no nas_type = other }
Similarly, we can add other NAS devices such MikroTik Router, Cisco Router etc. We will discuss how to add NAS devices in clients configuration file in the upcoming tutorials. Now we will add our test users in FreeRADIUS Server.
By default, user will be authorized and authenticated from users file in FreeRADIUS Server. So, open the users file located in this directory and add the following bob user at the top of this file. Also make sure that the second and third lines are indented by a single tab character.
In the above user information, the first line contains authorization and authentication information which is user name and password, and the rest of the line contains AVPs (Attribute Value Pair) those will be returned when the user will be authenticated.
FreeRADIUS basic configuration has been completed. Now it is time to test the configuration. FreeRADIUS provides radtest and radclient tools to test user and its configuration. We will use radclient tool test our bob user.
So, reload the freeradius daemon and issue the following radclient command and observe the output of this command.
Sent Access-Request Id 10 from 0.0.0.0:60243 to 127.0.0.1:1812 length 43
User-Name = “bob”
User-Password = “password”
Cleartext-Password = “password”
Received Access-Accept Id 10 from 127.0.0.1:1812 to 127.0.0.1:60243 length 38
Framed-IP-Address = 192.168.10.10
Reply-Message = “Hello, bob”
The above output of the radclient command is showing how auth request is being sent to the radius server and how the response is being sent to the Radius client.
So, Ubuntu RADIUS Server with freeRADIUS is now ready to accept Radius client (NAS) request and sent response to the NAS. In the next article, we will learn how to add MikroTik Router as NAS device of the freeRADIUS Server and authenticated RouterOS system user from Ubuntu RADIUS Server.
How to install and configure freeRADIUS Server in Ubuntu Server has been discussed in this article. I hope, you will now be able to install and configure freeRADIUS Server in Ubuntu Server. However, if you face any issue to install and to do basic configuration of freeRADIUS Server, feel free to discuss in comment or contact me from Contact page. I will try my best to stay with you.
VPN (Virtual Private Network) is one of the most popular services in MikroTik RouterOS. A lot of VPN services (IPsec, EoIP, OpenVPN, PPTP, L2TP, IPIP etc.) are available in MikroTik RouterOS but in RouterOS7, a new VPN service named WireGuard has been introduced which is extremely simple yet first, secure and modern VPN. WireGuard uses cryptography to make it secure.
In RouterOS7, WireGuard can be used either Client-Server (Road Warrior) VPN tunnel or site to site VPN tunnel. Using Client-Server WireGuard VPN tunnel, a Windows, Mac, Linux, iOS or Android user can be connected to his remote network and can access servers and other network devices as if he/she has be seated in that network. On the other hand, using site to site WireGuard VPN tunnel, two remote offices can always be connected across public network and can comminate with each other over this VPN tunnel.
In my previous article, I discussed how to configure MikroTik RouterOS 7 first time with step-by-step guideline. In this article, I will discuss how to configure Road Warrior WireGuard VPN tunnel in MikroTik RouterOS7 and then I will also discuss how to configure WireGuard Client in Window 10/11.
WireGuard Configuration in MikroTik RouterOS 7 (Road Warrior)
To configure Client-Server WireGuard VPN tunnel with Windows client, we will follow the following network diagram.
WireGuard VPN in MikroTik RouterOS 7
In the above diagram, WireGuard VPN Server is configured in the office network. So, WireGuard client configured in Windows or Linux or Android device can be connected to the office network creating a secure WireGuard VPN tunnel and can access remote servers and other network devices securely.
We will now configure such an office network where WireGuard VPN Server will be configured in a MikroTik RouterOS 7 and a Windows client will connect to this WireGuard VPN Server to access remote servers and other network devices.
WireGuard VPN Configuration in MikroTik RouterOS 7
WireGuard package is enabled by default in MikroTik RouterOS7. So, we don’t need to install it manually. We just need to setup WireGuard service. To configure WireGuard VPN for a Client-Server (Road Warrior) tunnel, follow the following steps.
Login to MikroTik RouterOS using Winbox with full access user permission.
From menu item, click on WireGuard. WireGuard window will appear.
Click on PLUS SIGN(+) to create a new WireGuard interface. New Interface window will appear.
Put an interface name in Name input field or you can keep the default name wireguard1.
In ListenPort input field, put 443 because we want to use 443 port which is usually not blocked. In MikroTik RouterOS7, the default WireGuard Listen Port is 13231. WireGuard works on UDP protocol because UDP is faster. On the other hand, TCP packets follow over TCP VPN tunnel makes performance issue. So, TCP is not used in WireGuard VPN tunnel.
Click Apply button. Public Key and Private Key will be generated as soon as you click the Apply button. The Public Key will be required when WireGuard client will be configured.
Click OK button.
WireGuard VPN Server Configuration in RouterOS7
WireGuard VPN service is now enabled in MikroTik RouterOS7. Now we will assign IP address on newly created WireGuard interface. To assign IP address on WireGuard Interface, issue the following steps.
From Winbox, go to IP > Addresses menu item. Address List window will appear.
Click PLUS SIGN (+). New Address window will appear.
In Address input field, put an IP address which you want. According to the network diagram, I am assigning 10.10.105.1/24. WireGuard clients will get IP address from this IP block.
From Interface dropdown menu, choose the created WireGuard interface (wireguard1).
Click Apply and OK button.
Assigning IP Address on WireGuard Interface
WireGuard VPN Server configuration in RouterOS7 has been completed. We will now download and install WireGuard Client in Windows 10/11.
Downloading and Installing WireGuard in Windows Operating System
As we are going to connect Windows OS to WireGuard VPN Server, we need to download and install WireGuard’s Windows application from WireGuard’s website. So, go to WireGuard installation page and download the installer for Windows Operating System. At the time of writing this article, the installation page of WireGuard looks like the following image.
Downloading WireGuard Windows Installer
Installing WireGuard Windows installer is as simple as installing other Windows applications. So, download the Windows installer and make a double click on it. The WireGuard installer will do the rest of the work for you. After installing WireGuard in your Windows Operating System, it will start WireGuard service and open a new WireGuard window like the following image where it will ask to provide configuration either manually or importing any configuration file.
WireGuard Client in Windows Operating System
We will configure WireGuard tunnel here manually because MikroTik RouterOS does not provide any configuration file. So, from this window, click on Add Tunnel dropdown menu and then choose Add empty tunnel… option. Create new tunnel window will appear where we will provide all the options required to create WireGuard Tunnel.
In Create new tunnel window, put a name (example: wg1) for the tunnel in Name input field and then click Save button. You will also find generated Public Key and Private Key in this window. Among these two keys, the Public Key will be required to configure peer between WireGuard Server and Client.
Creating New Tunnel in WireGuard Windows Client
Creating Peer Between WireGurad Server and Client
To create a VPN tunnel between Windows client and the RouterOS WireGuard Server, we need to configure WireGuard Peer. So, at first, we will configure peer in MikroTik RouterOS and then we will configure peer in WireGuard Windows client.
To configure WireGuard peer in MikroTik RouterOS, follow the following steps.
From WireGuard window, click on Peers tab and then click on PLUS SIGN (+). New WireGuard Peer window will appear.
In New WireGuard Peer window, choose WireGuard interface (wiregurad1) from Interface dropdown menu.
In Public Key input field, put the public key generated by the Windows client (with whom it will make peer).
In Allowed Address field, put the IP address (10.10.105.3/32) that will be assigned to the WireGuard Client.
Click Apply and OK button.
Peer configuration in MikroTik RouterOS has been completed. Now we will configure WireGuard Peer in Windows Client.
Open WireGuard client in Windows OS and select the WireGuard interface that was created before and then click on Edit button.
In Interface configuration, add two more properties (Address = 10.10.105.3/32 and DNS = 8.8.8.8). These two values will be assigned the WireGuard virtual interface. Change the IP values according to your network configuration.
Now add a new option named [Peer] and add these properties (PublicKey = y9uah2vvBg9nkBhovSA72Ji3C3LmMxoUab0dwhUwAy0= AllowedIPs = 0.0.0.0/0 Endpoint = 103.177.246.6:443 PersistentKeepalive = 10). Here, the Public Key is the Public Key of the RouterOS WireGuard, AllowedIPs will be the IPs those can access this client and by default it is 0.0.0.0/0 that means it can access any IP, the Endpoint property is very important and it will be the IP of the MikroTik RouterOS where WireGuard Server is enabled and the Port number, the PersistentKeepalive property keeps the tunnel active by checking the status of the tunnel every assigned time (seconds).
Click the Save button to save the configuration.
WireGuard Peer Configuration between RouterOS and Windows Client App
Peer configuration between the WireGuard Server and Client has been completed. Now click the Activate button from the WireGuard client. If everything is OK, the tunnel will be created and you can access your remote servers and other network devices without any issue and the client window looks like the following image.
Connected WireGuard Client in Windows OS
If you face any confusion to follow the above steps, watch the following video for step by step guideline.
How to configure Road Warrior WireGuard VPN in MikroTik RouterOS7 has been discussed in this article. I hope you will now be able to configure Client Server WireGuard VPN tunnel in RouterOS 7. However, if you face any confusion to setup WireGuard VPN in RouterOS7, feel free to discuss in comment or contact me form Contact page. I will try my best to stay with you.
В этой статье мы рассмотрим, как защищать роутер 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 и тому подобное оборудование, – агрегирующие соединения. Тут бизнес сам оценивает их стоимость для себя.
Купили новый маленький роутер от Mikrotik — RB4011iGS+RM. Решили попробовать как он будет работать в маленькой сетке в качестве роутера (странно? Да? 🙂 ). У него есть 10G SFP+ интерфейс, подключенный непосредственно к процессору. Если включить FastPath, то по идее должен справляться.
SFP+ интерфейс естественно в trank. На всякий пожарный eth6, тоже в транк. Eth с 1-го по 5-й в 1-й vlan, в режиме access mode, что бы подключаться прямо в серверной к коммутаторам, если вдруг чего. Остальные не задействованы.
При обращении к Google с вопросом Mirotik+vlan вываливается куча страниц с описанием настройки vlan. Но, проблема в том, что они блин все устарели! В новых версиях router os все уже не так.
Как сейчас рулить vlan с возможностью маршрутизации? Теперь там все через bridge интерфейс.
В первую очередь добавляем сам мост:
> /interface bridge
/interface bridge> add name=core
Добавим к мосту порты, в которых будут бегать тегированные пакеты:
Итак, мы добавили vlan 1 к нужным нам интерфейсам и заодно определили режимы работы самих интерфейсов. Так же были определены другие vlan, которые будут приходить на mikrotik и в дальнейшем мы будем заниматься маршрутизацией между этими сетями.
На данном этапе пакеты Ethernet начнут бегать в своих vlan.
Пришло время заняться маршрутизацией.
Обязательно добавляйте интерфейс моста в параметре tagget при добавлении vlan в разделе bridge! Без этого у нас ничего не получиться на 3-м уровне 🙁
Для того, что бы маршрутизатор смог маршрутизировать 🙂 нам необходимо для каждого vlan создать свой интерфейс и задать им параметры ip.
Как обычно, интерфейсы создаём в разделе interface vlan (не bridge vlan!).
Наши админы очень любят DHCP сервер mikrotik, поэтому его тоже придется поднимать на этом устройстве. Поскольку интерфейсы сконфигурированы, DHCP сервер настраивается обычным образом.
Инструкция по настройке VPN туннеля типа IpSec между облачным роутером Pfsense и MikroTik. В результате настройки должно получиться объединение двух сетей, за MikroTik и за Pfsense.
Что такое Pfsense
PfSense — дистрибутив для создания межсетевого экрана/маршрутизатора, основанный на FreeBSD. PfSense предназначен для установки на персональный компьютер, известен своей надежностью и предлагает функции, которые часто можно найти только в дорогих коммерческих межсетевых экранах. Настройки можно проводить через web-интерфейс, что позволяет использовать его без знаний базовой системы FreeBSD. Сетевые устройства с pfSense обычно применяются в качестве периметровых брандмауэров, маршрутизаторов, серверов DHCP/DNS, и в технологии VPN в качестве узла топологии hub/spoke.
Настройка VPN в MikroTik для подключения к Pfsense
Со стороны роутера MikroTik будет настроен стандартный VPN туннель типа IpSec. Больше сведений по настройке VPN типа IpSec представлено в статье:
VPN туннель IpSec состоит из двух фаз:
PHASE-1 – идентификация устройств между собой, по заранее определенному IP адресу и ключу.
PHASE-2 – определение политики для трафика между туннелей: шифрование, маршрутизация, время жизни туннеля.
Создание профиля для MikroTik IpSec phase-1
Настройка находится в IP→IPsec→Profile
Pfsense и MikroTik, создание профиля для IpSec phase-1
Создание Peer для MikroTik IpSec phase-1
Настройка находится в IP→IPsec→Peers
Pfsense и MikroTik, создание Peer для IpSec phase-1
Определение ключа MikroTik IpSec phase-1
Настройка находится в IP→IPsec→Identities
Pfsense и MikroTik, определение ключа IpSec phase-1
