Mikrotik: small utility. Part 1
In this article I want to share the small finds and devices that I managed to find and implement in RouterOS. Everything that will be written below is verified and works on the Mikrotik RB 951 series.
Today I will share the following things in the RouterOS environment:
1) Semi-automatic updating of firmware of Mikrotik devices, notification by e-mail and / or SMS
2) Automatically copy settings between devices
3) Blocking traffic, turning it to another gateway
Interesting? Then I ask for cat.
As many know, the firmware for Mikrotik comes out regularly, with every update a bunch of fixes. You need to update the device, it does not go away. But not only do you need to update ROS, you also need to update the FW of the device itself.
Honestly, I'm too lazy to follow the updates. I am subscribed to news on the Mikrotik website, but already 3 months with this news is all very bad (there are simply no letters). And everything would be fine, but I have 3 devices at home and 2 in the enterprise.
')
First, a little theory: my case is 3 951 series devices, each connected to each VPN. One of the points is the master, the rest take the necessary updates from the master through the internal channel. The wizard checks for updates via the Internet, automatically downloads them and sends a notification by mail and SMS.
But there is one thing: by default, update files are added to the root of the Files, only from there Mikrotik can be updated upon reboot. Immediately after the update files are deleted. For my scheme, this is critical, so you need to put the files in one of the folders, there they will not be deleted and other points will see them.
What you need :
need an FTP server on the wizard.
optional - customized Email and SMS branches
How to: Master
Only a script is needed, the necessary variables are at the top.
The script for version 6.32.2+ includes checking for already downloaded updates. Also note that even if updates are downloaded, check-for-updates sets the status to "New version is available".
Depending on your Internet channel, you need to set the corresponding second delay.
In the schedule, set the desired check interval. My choice is every 12 hours.
Note: starting from version 6.32.1 there were problems with the encoding of e-mail messages.
How to make: Slave
Required setup and 2 scripts.
In my case, the scripts are executed 1 time per day, the interval between them is 10 minutes.
The second script in the schedule can be installed on the startup system. If someone does not know, startup means starting 3 seconds after the device starts.
“Why not fetch files straight to the slave point?” You ask. Because on the points can be installed different packages. Better, the slaves themselves will decide what to swing and what not.
If you have one Mikrotik device, then you can build scripts for fully automated software updates.
As I said, laziness is my middle name. And I have an open guest Wi-Fi on each of the devices only “for my own people”, according to the MAC. Therefore, a volitional decision was made to have the same list of permitted devices at all points. The base is located on one of the points (Master) and will be copied once a day to the necessary devices. You need FTP servers at points where you need to copy the settings.
So, there are 2 options: simple and correct.
Plain:
It consists in the sequential sending of 2 files.
Right:
The previous version does not take into account the possible disconnection between fetches. If this situation occurs, the access-list will be empty with all the consequences. Therefore, we need to check for the presence of a file with the settings, and after that we need to clear the current contents of the sheet. The last action of the script is to delete the file. Namely:
Strictly speaking, the address_flush.rsc and address_proc.rsc files can have arbitrary names and extensions, but their output in the dst-path should be * .auto.rsc.
In the image and likeness you can copy the settings you need almost "on the fly."
On the topic of blocking a certain traffic of the article googling, so I will be brief - Layer7 Protocol.
For example, blocking telemetry Microsoft:
Read more about L7 on the project website.
The next moment is turning the traffic of individual machines to another gateway, which is not the default.
Distance should be lower than the default gateway. If necessary, instead of the source subnet, you can specify a single IP or address list.
Thus, you can wrap all outgoing traffic to the gateway 192.168.1.1. I strongly advise you to specify the gateway via IP, otherwise if you break the rule in the Route List is simply erased.
Well, the last trick for today is turning of only certain sites to the non-default gateway. This is very useful if you have a proxy not in the territory of the Russian Federation, but you want and / or need to visit the blocked RKN site.
This is a little more difficult, because L7 works when the connection is already established. Therefore, we will use the address lists.
For example, let's take forum.mikrotik.com, for which my main IP was in the spam range.
The disadvantage of this solution is that the first connection will end in error, but the subsequent ones will go through the required gateway.
PS: updated 10/20/2015. Added update script for version 6.32.2+
PPS: With the release of version 6.32.3, they fixed the email newsletter. I would like to think that this article was promoted to repair.
PPPS: Updated 11/09/2015.
With the release of version 6.33, it turned out to be a nuisance: the microtic cannot compare versions of different orders, i.e. 6.32.3 and 6.33.
Therefore, the script is modified to reflect this incident. Also, notifications are postponed below for sending to the last turn.
Today I will share the following things in the RouterOS environment:
1) Semi-automatic updating of firmware of Mikrotik devices, notification by e-mail and / or SMS
2) Automatically copy settings between devices
3) Blocking traffic, turning it to another gateway
Interesting? Then I ask for cat.
Item 1: Semi-automatic Mikrotik device firmware update, email and / or SMS notification
As many know, the firmware for Mikrotik comes out regularly, with every update a bunch of fixes. You need to update the device, it does not go away. But not only do you need to update ROS, you also need to update the FW of the device itself.
Honestly, I'm too lazy to follow the updates. I am subscribed to news on the Mikrotik website, but already 3 months with this news is all very bad (there are simply no letters). And everything would be fine, but I have 3 devices at home and 2 in the enterprise.
')
First, a little theory: my case is 3 951 series devices, each connected to each VPN. One of the points is the master, the rest take the necessary updates from the master through the internal channel. The wizard checks for updates via the Internet, automatically downloads them and sends a notification by mail and SMS.
But there is one thing: by default, update files are added to the root of the Files, only from there Mikrotik can be updated upon reboot. Immediately after the update files are deleted. For my scheme, this is critical, so you need to put the files in one of the folders, there they will not be deleted and other points will see them.
What you need :
need an FTP server on the wizard.
optional - customized Email and SMS branches
How to: Master
Only a script is needed, the necessary variables are at the top.
Update script for version <6.32.2
:local email " email" :local user " " :local pass " " :local folder " " :local phone " +" ##### /system package update check-for-updates :delay 3 :if ( [/system package update get installed-version] = [/system package update get latest-version] ) do={ /tool e-mail send to=$email subject=" Mikrotik" body=" RouterOS! - $[/system package update get latest-version]. - http://www.mikrotik.com/download" /tool sms send usb1 channel=2 "$phone" message="New RouterOS version is available!" /system package update download :delay 20 :foreach i in=[/file find where package-version=[/system package update get latest-version]] do={ /tool fetch address=127.0.0.1 src-path="$[/file get number="$i" name]" dst-path="$folder/$[/file get number="$i" name]" user=$user password=$pass mode=ftp } } Update script for version> = 6.32.2
:local email " email" :local user " " :local pass " " :local folder " " :local phone " +" ##### :if ( [/system package update get status] != "Downloaded, please reboot router to upgrade it" ) do={ /system package update check-for-updates :delay 3 :if ( [/system package update get installed-version] != [/system package update get latest-version] ) do={ /system package update download :delay 20 :foreach i in=[/file find where package-version=[/system package update get latest-version]] do={ /tool fetch address=127.0.0.1 src-path="$[/file get number="$i" name]" dst-path="$folder/$[/file get number="$i" name]" user=$user password=$pass mode=ftp } /tool e-mail send to=$email subject=" Mikrotik" body=" RouterOS! - $[/system package update get latest-version]. - http://www.mikrotik.com/download" /tool sms send usb1 channel=2 "$phone" message="New RouterOS version is available!" } } The script for version 6.32.2+ includes checking for already downloaded updates. Also note that even if updates are downloaded, check-for-updates sets the status to "New version is available".
Depending on your Internet channel, you need to set the corresponding second delay.
In the schedule, set the desired check interval. My choice is every 12 hours.
Note: starting from version 6.32.1 there were problems with the encoding of e-mail messages.
How to make: Slave
Required setup and 2 scripts.
Target Master Point
And enter the password of the remote user.
/system upgrade upgrade-package-source add address=xxx.xxx.xxx.xxx user=user And enter the password of the remote user.
RouterOS update script
/system upgrade refresh :delay 5 /system upgrade download-all reboot-after-download=yes FW update script
:if ( [/system routerboard get current-firmware] < [/system routerboard get upgrade-firmware] ) do { /system routerboard upgrade /system reboot } In my case, the scripts are executed 1 time per day, the interval between them is 10 minutes.
The second script in the schedule can be installed on the startup system. If someone does not know, startup means starting 3 seconds after the device starts.
“Why not fetch files straight to the slave point?” You ask. Because on the points can be installed different packages. Better, the slaves themselves will decide what to swing and what not.
If you have one Mikrotik device, then you can build scripts for fully automated software updates.
Item 2: Automatically copy settings between devices
As I said, laziness is my middle name. And I have an open guest Wi-Fi on each of the devices only “for my own people”, according to the MAC. Therefore, a volitional decision was made to have the same list of permitted devices at all points. The base is located on one of the points (Master) and will be copied once a day to the necessary devices. You need FTP servers at points where you need to copy the settings.
So, there are 2 options: simple and correct.
Plain:
It consists in the sequential sending of 2 files.
Script
:local ip "IP , " :local user "" :local password "" ##### /interface wireless access-list export compact file=address :delay 1 /tool fetch upload=yes address=$ip mode=ftp src-path=address_flush.rsc dst-path=address_flush.auto.rsc user=$user password=$password :delay 1 /tool fetch upload=yes address=$ip mode=ftp src-path=address.rsc dst-path=address.auto.rsc user=$user password=$password The contents of the file address_flush.rsc
/interface wireless access-list remove [/interface wireless access-list find] Right:
The previous version does not take into account the possible disconnection between fetches. If this situation occurs, the access-list will be empty with all the consequences. Therefore, we need to check for the presence of a file with the settings, and after that we need to clear the current contents of the sheet. The last action of the script is to delete the file. Namely:
Script
:local ip "IP , " :local user "" :local password "" ##### /interface wireless access-list export compact file=wifi2_mac :delay 1 /tool fetch upload=yes address=$ip mode=ftp src-path=wifi2_mac.rsc dst-path=wifi2_mac.rsc user=$user password=$password :delay 1 /tool fetch upload=yes address=$ip mode=ftp src-path=address_proc.rsc dst-path=address_proc.auto.rsc user=$user password=$password :delay 10 /file remove [/file find where name=wifi2_mac.rsc] The contents of the file address_proc.rsc
#2015.09.11 - AcidVenom - Copy MAC to extertnal Script :delay 5 :if ( [/file find where name=wifi2_mac.rsc] != "" ) do={ /interface wireless access-list remove [/interface wireless access-list find] /import wifi2_mac.rsc :delay 1 /file remove [/file find where name=wifi2_mac.rsc] } Strictly speaking, the address_flush.rsc and address_proc.rsc files can have arbitrary names and extensions, but their output in the dst-path should be * .auto.rsc.
In the image and likeness you can copy the settings you need almost "on the fly."
Point 3: Blocking traffic, turning it to another gateway
On the topic of blocking a certain traffic of the article googling, so I will be brief - Layer7 Protocol.
For example, blocking telemetry Microsoft:
/ip firewall layer7-protocol add name=telemetry regexp=^.+(data.microsoft.com|telemetry.microsoft.com).*$ /ip firewall filter add chain=forward protocol=tcp in-interface=bridge-local layer7-protocol=telemetry action=reject reject-with=tcp-reset /ip firewall filter add chain=forward protocol=tcp out-interface=bridge-local layer7-protocol=telemetry action=reject reject-with=tcp-reset Read more about L7 on the project website.
The next moment is turning the traffic of individual machines to another gateway, which is not the default.
/ip firewall mangle add chain=prerouting src-address=192.168.0.0/24 dst-address=!192.168.0.0/16 action=mark-routing new-routing-mark=another_gateway passthrough=yes /ip route add dst-address=0.0.0.0/0 gateway=192.168.1.1 check-gateway=ping type=unicast distance=1 routing-mark=another_gateway Distance should be lower than the default gateway. If necessary, instead of the source subnet, you can specify a single IP or address list.
Thus, you can wrap all outgoing traffic to the gateway 192.168.1.1. I strongly advise you to specify the gateway via IP, otherwise if you break the rule in the Route List is simply erased.
Well, the last trick for today is turning of only certain sites to the non-default gateway. This is very useful if you have a proxy not in the territory of the Russian Federation, but you want and / or need to visit the blocked RKN site.
This is a little more difficult, because L7 works when the connection is already established. Therefore, we will use the address lists.
For example, let's take forum.mikrotik.com, for which my main IP was in the spam range.
/ip firewall layer7-protocol add name=forum.mikrotik regexp=^.+(forum.mikrotik.com).*$ /ip firewall mangle add chain=prerouting src-address=192.168.0.0/24 dst-address=!192.168.0.0/16 layer7-protocol=forum.mikrotik action=add-dst-to-address-list address-list=forum.mikrotik.ip address-list-timeout=24:00:00 /ip firewall mangle add chain=prerouting src-address=192.168.0.0/24 dst-address=!192.168.0.0/16 dst-address-list=forum.mikrotik.ip action=mark-routing new-routing-mark=forum.mikrotik.rm passthrough=yes /ip route add dst-address=0.0.0.0/0 gateway=192.168.1.1 check-gateway=ping type=unicast distance=1 routing-mark=forum.mikrotik.rm The disadvantage of this solution is that the first connection will end in error, but the subsequent ones will go through the required gateway.
PS: updated 10/20/2015. Added update script for version 6.32.2+
PPS: With the release of version 6.32.3, they fixed the email newsletter. I would like to think that this article was promoted to repair.
PPPS: Updated 11/09/2015.
With the release of version 6.33, it turned out to be a nuisance: the microtic cannot compare versions of different orders, i.e. 6.32.3 and 6.33.
Therefore, the script is modified to reflect this incident. Also, notifications are postponed below for sending to the last turn.
Source: https://habr.com/ru/post/266847/
All Articles