Базовая конфигурация MikroTik (CLI) ( Создание простейшей конфигурации для обеспечения работы небольшого офиса с парой десятков пользователей. )
Задача: создать простейшую конфигурацию маршрутизатора «MikroTik» для обеспечения работы типового небольшого офиса с парой десятков пользователей и двумя-тремя серверами.
Сразу после запуска ненастроенного (или сброшенного до заводского состояния) устройства для доступа к его конфигурации есть два пути: включиться в один из портов (обычно второй и следующие, в зависимости от модели) ethernet-порт (как правило по умолчанию на устройстве запущен DHCP-сервер, выдающий клиентам сетевой адрес) или воспользоваться более простым и надёжным RS-232 (через кабель DB-9). Я предпочитаю последний способ — это не вынуждает меня выключаться из сети, в которой я уже нахожусь:
Прежде всего, если устройство только что поступило на полное реконфигурирование, есть смысл предварительно зачистить его настройки, и уже после этого приступать к дальнейшим действиям:
Аналогичного эффекта сброса настроек до заводских можно достигнуть следующей последовательностью действий:
1. Выключаем питание.
2. Зажимаем кнопку «Reset».
3. Удерживая кнопку «Reset» включаем питание.
4. Отпускаем кнопку «Reset», пока ещё мигает индикатор загрузки.
При входе на устройство сразу после сброса «мастером настройки» будет предложено применить «конфигурацию по умолчанию», но нам это не нужно — отказываемся путём нажатия клавиши «r».
Ознакомиться с текущей конфигурацией проще всего посредством команды экспортирования всего набора команд для воссоздания таковой:
Обращаю внимание, что в версии «RouterOS v6.41» аппаратную L2-коммутацию полностью перенесли на bridge-интерфейсы, отменив ранее использовавшиеся switch-группировки (через опции «master port») — новая реализация «прозрачного моста» поддерживает «аппаратную разгрузку (hardware offload)». Настоятельно рекомендую обновиться до версии v6.41 и выше, так описываемая здесь конфигурация основана уже на новом функционале мостового интерфейса.
Первичные настройки доступа.
Устанавливаем пароль для текущего пользователя «admin»:
Заводим дополнительного пользователя и выдаём ему полномочия суперпользователя:
Выключаем все сервисы управления устройством, кроме SSH, «winbox» и COM-порта:
Активируем повышенный уровень шифрования сеансов SSH и запрещаем транзитные подключения:
Ради повышения уровня пассивной безопасности разрешаем обращения к «winbox» только из локальной сети — для настройки извне достаточно SSH:
Настраиваем сетевое именование.
Задаём символическое сетевое имя (FQDN) устройству:
Задаём набор NS-серверов, к которым следует отправлять DNS-запросы (в примере Google и Yandex):
Разрешаем обслуживание маршрутизатором рекурсивных DNS-запросов от пользователей:
Устанавливаем точное системное время.
Наверняка изначально может потребоваться явно указать желаемый часовой пояс (пример для Новосибирска):
Задаём внешний источник данных для автоматической синхронизации времени:
Сразу по применению новых параметров даты и времени система попытается синхронизировать его с указанными time-серверами.
Позволяем маршрутизатору делиться сведениями о точном времени, активируя NTP-Server:
Об аппаратных чипах и логике коммутации.
Ранее (до «RouterOS v6.41») на большинстве «Mikrotik» в настройках по умолчанию была предустановлена схема из двух уровней коммутации: группа ethernet-интерфейсов собирается в «switch-group» (трафик которой обслуживается только в рамках подключения к физическому чипу коммутации, коих может быть несколько), а порты «switch-group» через произвольный «master-port» (таковым может быть назначен любой из портов группы) вводятся в мостовой виртуальный интерфейс «bridge», коммутирующий (уже на уровне центрального процессора) пакеты «switch-group», автономных ethernet-интерфейсов и беспроводного интерфейса, предоставляя им единое L2 адресное пространство.
С внедрением «hardware offload» в мостовых интерфейсах прослойка «switch-group» была исключена из схемы, что сильно упростило её с точки зрения первичного конфигурирования — теперь по умолчанию все сетевые интерфейсы (кроме WAN) введены в виртуальный «прозрачный мост».
Такая реализация упрощает запуск устройства в работу, но не обеспечивает хорошей сетевой производительности из-за узкого места — CPU, через который будет пропускаться вся паразитная широковещательная коммутация, которой в реальной сети с количеством узлов за пару десятков не избежать.
Рекомендую сразу разделить по разным группам коммутации проводные и беспроводные интерфейсы (помним, что по умолчанию они сведены в «прозрачный мост») с тем, чтобы иметь возможность подключающихся беспроводных клиентов в любых комбинациях изолировать от работающих в проводной сети пользователей, а порты последней распределить в соответствии с назначением, функционально изолировав их в рамках аппаратных чипов.
Планируем распределение сетевых интерфейсов по задачам.
В дальнейшей настройке будем исходить из потребности в следующих сущностях:
WAN1 — интерфейс для подключения к первому провайдеру;
WAN2 — интерфейс для подключения ко второму провайдеру;
LAN1 — виртуальный интерфейс для обслуживания локальной сети;
DMZ1 — виртуальный интерфейс для подключения DMZ-сети;
WLAN1 — интерфейс беспроводного контроллера.
Если устройство начального уровня, то в нём немного физических портов и может статься, что каждый из них будет задействован в своей задаче с индивидуальной сетевой IP-адресацией. Если ethernet-портов больше, чем задач, что часть из них можно свести в группы коммутации, получив в итоге картину вроде нижеследующей:
switch1 — первый чип коммутации (GigabitEthernet):
WAN1:
ether1 — первый провайдер;
LAN1:
bridge1 — группа коммутации:
ether2 — первый клиентский коммутатор;
ether3 — второй клиентский коммутатор;
ether4 — рабочая станция;
ether5 — сетевой принтер;
switch2 — второй чип коммутации (FastEthernet):
WAN2:
ether6 — второй провайдер;
DMZ1:
bridge2 — группа коммутации:
ether7 — первый сервер;
ether8 — второй сервер;
ether9 — сетевая АТС;
ether10 — СХД;
WLAN1:
wlan1 — беспроводная сеть.
Конфигурируем локальные сетевые подключения.
Переименовываем сетевые интерфейсы для удобства восприятия их функциональной привязки, в соответствие с вышеприведённой схемой:
> /interface ethernet
> set [ find default-name=ether1 ] name=ether1-WAN1
> set [ find default-name=ether2 ] name=ether2-LAN1
> set [ find default-name=ether3 ] name=ether3-LAN1
> set [ find default-name=ether4 ] name=ether4-LAN1
> set [ find default-name=ether5 ] name=ether5-LAN1
> set [ find default-name=ether6 ] name=ether6-WAN2
> set [ find default-name=ether7 ] name=ether7-DMZ1
> set [ find default-name=ether8 ] name=ether8-DMZ1
> set [ find default-name=ether9 ] name=ether9-DMZ1
> set [ find default-name=ether10 ] name=ether10-DMZ1
Создаём «мостовые интерфейсы», которые будут играть роль виртуальных коммутаторов:
> /interface bridge add auto-mac=yes name=BR-LAN1 protocol-mode=rstp
> /interface bridge add auto-mac=yes name=BR-DMZ1 protocol-mode=rstp
Подключаем к виртуальным «мостовым интерфейсам» соответствующие сетевые физические интерфейсы:
> /interface bridge port
> add bridge=BR-LAN1 interface=ether2-LAN1
> add bridge=BR-LAN1 interface=ether3-LAN1
> add bridge=BR-LAN1 interface=ether4-LAN1
> add bridge=BR-LAN1 interface=ether5-LAN1
> add bridge=BR-DMZ1 interface=ether7-DMZ1
> add bridge=BR-DMZ1 interface=ether8-DMZ1
> add bridge=BR-DMZ1 interface=ether9-DMZ1
> add bridge=BR-DMZ1 interface=ether10-DMZ1
Проверяем, получилось ли задуманное распределение интерфейсов:
. R — running, S — slave
.
0 ether1-WAN1 ether .
1 S ether2-LAN1 ether .
2 S ether3-LAN1 ether .
3 S ether4-LAN1 ether .
4 RS ether5-LAN1 ether .
5 ether6-WAN2 ether .
6 S ether7-DMZ1 ether .
7 S ether8-DMZ1 ether .
8 S ether9-DMZ1 ether .
9 S ether10-DMZ1 ether .
10 sfp1 ether .
11 X wlan1 wlan .
12 R BR-DMZ1 bridge .
13 R BR-LAN1 bridge .
В следующем выводе сведений об участниках имеющихся «прозрачных мостов» хорошо видно, для каких интерфейсов (всех в примере) активна «аппаратная разгрузка (hardware offload)» — это значит, что между интерфейсами в рамках обоих групп коммутации пакеты будут передаваться с максимальной скоростью — обрабатываемые на аппаратном уровне, без привлечения медленного центрального CPU:
. I — inactive, H — hw-offload
.
0 I H ether2-LAN1 BR-LAN1 .
1 I H ether3-LAN1 BR-LAN1 .
2 I H ether4-LAN1 BR-LAN1 .
3 H ether5-LAN1 BR-LAN1 .
4 I H ether7-DMZ1 BR-DMZ1 .
5 I H ether8-DMZ1 BR-DMZ1 .
6 I H ether9-DMZ1 BR-DMZ1 .
7 I H ether10-DMZ1 BR-DMZ1 .
Назначаем «мостовым интерфейсам» локальных сетей IP-адреса:
> /ip address add address=192.168.1.1/24 interface=BR-LAN1
> /ip address add address=10.10.1.1/24 interface=BR-DMZ1
Результат наших действий по назначению IP-адресов:
Конфигурируем беспроводное сетевое подключение.
Беспроводной интерфейс по умолчанию переведён под управление модуля CAPsMAN (Controlled Access Point system Manager) — контроллера беспроводных точек, призванного упростить настройку и управление единой Wi-Fi-сетью (аналог UniFi-сети на устройствах «Ubiquiti») с бесшовным роумингом:
Хорошо, но для одиночного устройства не нужно — отключаем привязку беспроводного интерфейса к системе CAP:
> /interface wireless cap set interfaces=»» discovery-interfaces=»»
> /interface wireless cap set enabled=no
Создаём выделенный профиль, описывающий метод аутентификации пользователя в беспроводной сети:
> /interface wireless security-profiles add name=staff-profile authentication-types=wpa2-psk group-ciphers=tkip,aes-ccm mode=dynamic-keys unicast-ciphers=tkip,aes-ccm wpa2-pre-shared-key=
Задаём параметры сети, обслуживаемой беспроводным интерфейсом, заодно привязав к нему заранее подготовленный профиль аутентификации:
> /interface wireless set wlan1 band=2ghz-b/g/n channel-width=20mhz default-forwarding=no disabled=no mode=ap-bridge security-profile=staff-profile ssid=zsmtu wps-mode=disabled
Задаём IP-адрес беспроводному интерфейсу и включаем таковой:
Настраиваем автоматическую выдачу IP-адресов.
Запускаем DHCP-сервер для обслуживания клиентов локальной сети:
> /ip pool add name=DHCP_LAN1_POOL ranges=192.168.1.100-192.168.0.250
> /ip dhcp-server add name=DHCP_LAN1 interface=BR-LAN1 address-pool=DHCP_LAN1_POOL lease-time= 22d disabled=no
> /ip dhcp-server network add address=192.168.1.0/24 gateway=192.168.1.1 netmask=255.255.255.0 dns-server=192.168.1.1 ntp-server=192.168.1.1
При необходимости фиксируем IP-адрес компьютера пользователя за его аппаратным MAC-адресом:
> /ip dhcp-server lease add server=DHCP_LAN1 address=192.168.1.51 mac-address=00:AA:B0:C0:A6:F1 comment=»workstation-one»
Запускаем DHCP-сервер для обслуживания клиентов беспроводной сети:
> /ip pool add name=DHCP_WLAN1_POOL ranges=172.16.1.10-172.16.1.254
> /ip dhcp-server add name=DHCP_WLAN1 interface=wlan1 address-pool=DHCP_WLAN1_POOL lease-time= 7d disabled=no
> /ip dhcp-server network add address=172.16.1.0/24 gateway=172.16.1.1 netmask=255.255.255.0 dns-server=172.16.1.1
Удостоверяемся, что наши DHCP-серверы активны в заданной конфигурации:
А вот так можно просмотреть список выданных пользователям сетей IP-адресов:
Конфигурируем внешние сетевые подключения.
Задаём внешнему интерфейсу первого (основного) провайдера IP-адрес:
> /ip address add address=123.45.67.90 netmask=255.255.255.248 interface=ether1-WAN1 disabled=no comment=»ISP1″
Объявляем маршрут «по умолчанию», отправляющий весь нераспределённый трафик в сеть первого провайдера «ISP1»:
> /ip route add check-gateway=ping comment=»GW1″ disabled=no distance=1 dst-address=0.0.0.0/0 gateway=123.45.67.89 scope=30 target-scope=10
Задаём параметры подключения ко второму, резервному интернет-провайдеру (например через xDSL-модем, выдающего динамические адреса на линии связи). По логике маршрутизации мы не должный принимать от DHCP-сервера провайдера «маршрут по умолчанию», нам достаточно просто получить адресацию, чтобы интерфейс был активен — но в комбинации «DHCP + StaticRoute» Mikrotik не вполне корректно отрабатывает маршруты на стыке сетей — так что сразу заводим второй «маршрут по умолчанию», но делаем его менее приоритетным:
> /ip dhcp-client add interface=ether6-WAN2 add-default-route=yes disabled=no comment=»ISP2″
> /ip route add check-gateway=ping comment=»GW2″ disabled=no distance=2 dst-address=0.0.0.0/0 gateway=ether6-WAN2 scope=30 target-scope=10
Просматриваем получившуюся таблицу простейшей статической маршрутизации:
. D — dynamic, S — static .
# DST-ADDRESS . GATEWAY DISTANCE
0 S ;;; GW1
0.0.0.0/0 123.45.67.89 1
1 S ;;; GW2
0.0.0.0/0 ether6-WAN2 2
.
Настраиваем трансляцию запросов из локальной сети в интернет.
Так как внутри «MikroTik» живёт «Linux», управление сетевым трафиком и модификация пакетов реализовано через подсистему ядра «netfilter», только вместо обвязки «iptables» здесь оперируют сущностью «firewall».
Для упрощения дальнейшего конфигурирования отношений между подсетями составляем списки таковых:
> /ip firewall address-list
> add address=192.168.1.0/24 list=LIST_INET_USERS_IP
> add address=172.16.1.0/24 list=LIST_INET_USERS_IP
> add address=10.10.1.0/24 list=LIST_DMZ_IP
> add address=123.45.67.88/29 list=LIST_WAN_IP
Задаём правила NAPT/PAT (NAT Overload/Port Address Translation) трансляции локальных сетевых адресов пользователей во внешние, при обращении за сетевые интерфейсы провайдеров:
> /ip firewall nat add action=src-nat chain=srcnat comment=»NAPT/PAT via WAN1″ out-interface=ether1-WAN1 src-address-list=LIST_INET_USERS_IP to-addresses=123.45.67.90
>
> /ip firewall nat add action=masquerade chain=srcnat comment=»NAPT/PAT via WAN2″ disabled=yes out-interface=ether6-WAN2 src-address-list=LIST_INET_USERS_IP
Проверяем, применились ли правила организации доступа в интернет:
.
1 ;;; NAPT/PAT via WAN1
chain=srcnat action=src-nat to-addresses=123.45.67.90 src-address-list=LIST_INET_USERS_IP out-interface=ether1-WAN1 log=no log-prefix=»»
2 ;;; NAPT/PAT via WAN2
chain=srcnat action=masquerade src-address-list=LIST_INET_USERS_IP out-interface=ether6-WAN2 log=no log-prefix=»»
Настраиваем трансляцию запросов из внешней сети к локальным ресурсам.
Наверняка потребуется обеспечить доступность внутреннего сервиса, спрятанного за «MikroTik», извне.
Добавляем правила DNAT (Destination NAT), разрешающие пропуск трафика снаружи к определённым сервисам и портам:
> /ip firewall nat
> add action=dst-nat chain=dstnat comment=»DNS: ns.example.net» dst-address=123.45.67.92 dst-port=53 protocol=tcp to-addresses=10.10.1.2 to-ports=53
> add action=dst-nat chain=dstnat comment=»DNS: ns.example.net» dst-address=123.45.67.92 dst-port=53 protocol=udp to-addresses=10.10.1.2 to-ports=53
Если нужно обеспечить как пропуск трафика извне, так и вывод такового наружу через определённый внешний IP-адрес, то к правилу DNAT добавим ещё и SNAT (Source NAT) — например, для всего сетевого узла в целом:
> /ip firewall nat
> add action=dst-nat chain=dstnat comment=»NAT To: example.net» dst-address=123.45.67.33 to-addresses=10.10.0.3
> add action=src-nat chain=srcnat comment=»NAT From: example.net» src-address=10.10.0.3 to-addresses=123.45.67.33
Более глубокую настройку защитного экрана, как такового рассмотрим в отдельной заметке.
Деактивируем ненужные в простом офисе функциональные модули:
Выключаем сервисы мониторинга (Ping) и управления (Telnet, Winbox), принимающие подключения с указанием MAC-адреса, если IP-адрес интерфейсу не выдан:
> /tool mac-server ping set enabled=no
> /tool mac-server set allowed-interface-list=none
> /tool mac-server mac-winbox set allowed-interface-list=none
Выключаем для всех сетевых интерфейсов сервис автоматического поиска соседних сетевых устройств посредством LLDP-запросов — в небольшом офисе и так известно, что к чему подключено:
Выключаем сервис, предназначенный для приёма подключений с целью тестирования пропускной способности:
Явно выключаем сервисы проксирования клиентских запросов:
LCD-экранчик у Mikrotik откровенно неудобный — выключаем, не особо разбираясь в его возможностях:
> /lcd interface pages set 0 interfaces=ether1-WAN1
> /lcd set default-screen=stats-all read-only-mode=yes touch-screen=disabled
> /lcd set enabled=no
[ уже посетило: 8661 / +3 ] [ интересно! / нет ]
Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )
How to block specific IP address?
In order to block a specific IP address, you need to add a Firewall filter rule.
Follow these steps to add filter rule using Winbox:
- Go to IP>Firewall;
- Select tab «Filter rules»;
- Click on the + to add new rule;
- Select tab «General»;
- Choose Chain: Input;
- Select Src. Address — input your desired IP;
- Select tab «Action»;
- Choose Action: Drop;
- Click OK, and the desired IP address will be blocked by a firewall filter.
/ip firewall filter add chain=input src-address=1.1.1.1 action=drop
Chain «input» limit the connection to the device itself. To limit traffic going through the device use chain «forward». Please refer to the Building Your First Firewall
Схема подключения
Что у нас с интерфейсами: ether1 будет подключен к провайдеру (WAN порт), Предположим, что к порту ether2 будет подсоединён свитч для подключения компьютеров локальной сети. Итого схема такая:
Т.е. для полноценной работы нам потребуются следующие шаги:
- Настройка клиента PPPoE. Интерфейс ether1 (WAN)
- Назначение шлюза LAN. Интерфейс ether2 для коммутатора (LAN с IP-блоком 192.168.10.0/24)
- Конфигурация DNS IP
- Конфигурация NAT. Компьютеры должны получать серый IP для выхода в интернет
11 thoughts on “ NAT MikroTik доступ к WAN из локальной сети, Hairpin NAT — доступ через внешний IP на свои ресурсы, находясь внутри сети. ”
Почему в правиле «add chain=srcnat out-interface=bridge action=masquerade» указан «out-interface=bridge», а не «out-interface=WAN», например?
Пакет пришел на роутер (по внешнему IP) что бы сервер его напрямую не отправил (минуя роутер), он пакет, должен дойти до сервака с измененным полем (адрес источника) а выходить он будет с интерфейса бриджа, поэтому при выходе пакета с этого интерфейса у него (у пакета) будет заменяться (адрес источника) на адрес роутера. И когда сервак будет отвечать на запрос он пошлет пакет роутеру а не напрямую компу который делает изначально запрос.
Eduard Yamaltdinov :
Данное правило добавлено, для получения доступа к внешнему ресурсу IP адреса сервера в этой же локальной сети.
К примеру наш IP компьютера: 192.168.1.10
IP адрес сервера: 192.168.1.99
На сервере 192.168.1.99 открыли 22 порт ssh.
Мы хотим подключится к серверу не по локальному IP, а по внешнему к примеру 185.167.44.41. Тогда без правила
/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 dst-address=192.168.1.99 protocol=tcp dst-port=22 out-interface=bridge action=masquerade
Мы не получим доступ к нашему внешнему IP в нашей локальной сети 192.168.1.0/24
А как проделать такой же трюк если внешний IP выдается динамически, на каждую новую сессию соединения роутера с провайдером?
Eduard Yamaltdinov :
Для решения вашей задачи нужно использовать https://dynv6.com/
И скрипт — https://gist.github.com/stargieg/1b11d3df9cc6f9cb934037e6c474d618
Если нужна помощь в настройке то оставьте заявку на noc@galaxydata.ru
Отлично, помогло, спасибо
Если я захожу на сайт из вне, то в сё работает хорошо, но если я захожу из локальной сети по внешнему адресу, то всё ужасно тупит. Причём если зайду по локальному адресу, то всё так же прекрасно работает. В чём может быть дело?
Eduard Yamaltdinov :
Пришлите экспорт вашего конфига. Также какой у вас роутер используется?
Eduard Yamaltdinov :
Какой роутер у вас используется?
Пришлите ваш конфиг роутера через команду
export compact
А что посоветуете если схема такова.
локальная-сеть1 — 192.168.1.0/24
локальная-сеть2 — 192.168.2.0/24
веб-сервер — 192.168.2.100
внешний ИП 1.1.1.1
Созданные правила :
;;; проброс портов 80,443
chain=dstnat action=dst-nat to-addresses=192.168.2.100 protocol=tcp
dst-address=1.1.1.1 dst-port=80,443 log=yes log-prefix=»»
;;; scrnat
chain=dstnat action=dst-nat to-addresses=192.168.2.100 protocol=tcp
src-address=192.168.1.0/22 dst-address=1.1.1.1 dst-port=80,443 log=no
log-prefix=»»
;;; masquerade
chain=srcnat action=masquerade protocol=tcp src-address=192.168.1.0/22
dst-address=192.168.2.100 dst-port=443,80 log=no log-prefix=»»
При таком раскладе из подсети 192.168.2.0/24 пользователи могут зайти на веб-сайт по внешнему ИП, вто время как из 192.168.1.0/24 не работает!
