Моят нереализиран проект. Мрежа от 200 рутера MikroTik

Здравейте на всички. Тази статия е насочена към тези, които разполагат с много устройства MikroTik и искат да постигнат максимална унификация, за да не се налага да се свързват с всяко устройство поотделно. В тази статия ще опиша проект, който, за съжаление, не стигна до бойни условия поради човешки фактори. Накратко: над 200 маршрутизатора, бърза настройка и обучение на персонала, унификация по региони, филтриране на мрежи и определени хостове, възможност за лесно добавяне на правила за всички устройства, логване и контрол на достъпа.

Описание на следващите точки не претендира за готов случай, но се надявам да бъде полезно за планирането на вашите мрежи и минимизирането на грешките. Възможно е някои от точките и решенията да ви се струват неправилни - ако е така, моля пишете в коментарите. Критиката в този случай ще бъде опит в общата сметка. Затова, читателю, погледни коментарите, може би авторът е допуснал груба грешка - общността ще помогне.

Броят на маршрутизаторите е 200-300, разпределени в различни градове с различно качество на интернет връзката. Необходимо е всичко да бъде красиво и ясно обяснено на местните администратори как ще работи.

И така, от какво започва всеки проект. Разбира се, от ТЗ.

1. Организация на мрежовия план във всички филиали в съответствие с изискванията на клиента, сегментация на мрежите (от 3 до 20 мрежи във филиалите в зависимост от броя на устройствата).
2. Настройка на устройствата във всеки филиал. Проверка на реалната пропускна способност на доставчика в различни условия на работа.
3. Организация на защита на устройствата, управление по бял списък, автодетекция на атаки с автоматично добавяне в черен списък за определен период от време, минимизиране на използването на различни технически средства за прихващане на управление и отказ от обслужване.
4. Организация на защитени VPN връзки с филтриране по мрежи в съответствие с изискванията на клиента. Минимум 3 VPN връзки от всеки филиал до централата.
5. На базата на точки 1 и 2. Избор на оптимални маршрути за изграждане на отказоустойчиви VPN. Технологията за динамично маршрутизиране може да бъде избрана от изпълнителя при правилно обоснование.
6. Организация на приоритизация на трафика по протоколи, портове, хостове и други специфични услуги, които използва клиентът. (VOIP, хостове с важни услуги)
7. Организация на мониторинга и логването на събитията от рутерите за реакция от страна на техническата поддръжка.

Както разбираме, в редица случаи ТЗ се съставя на база изисквания. Тези изисквания ги формулирах самостоятелно, изслушвайки основните проблеми. Допусках възможността, че изпълнението на тези точки може да бъде извършено от някой друг.

Кои инструменти ще се използват за изпълнение на тези изисквания:

1. Стек ELK (след известно време, разбрахме, че вместо logstash ще се използва fluentd).
2. Ansible. За удобство на администрирането и разделението на достъпа ще използваме AWX.
3. GITLAB. Тук не е нужно пояснение. Какво без контрол на версиите на нашите конфигурации.
4. PowerShell. Ще има простичък скрипт за първоначалната генерация на конфигурацията.
5. Доку вики, за написване на документация и ръководства. В този случай ще използваме habr.com.
6. Мониторингът ще се извършва чрез zabbix. Там също ще бъде нарисувана схема на свързването за общо разбиране.

Моменти за настройка на EFK

По първата точка ще опиша само идеологията, по която ще се изграждат индексите. Има много
прекрасни статии за настройка и прием на логове от устройства под управление на mikrotik.

Ще се спра на някои моменти:

1. Според схемата, трябва да обмислим приемането на логове от различни места и по различни портове. За това ще използваме агрегатор на логове. Също така искаме да направим универсални графики за всички рутери с възможност за разделяне на достъпа. Тогава индексите изграждаме по следния начин:

това е част от конфигурацията с fluentd type elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts elasticsearch:9200
port 9200

Така можем да обединим рутерите и да сегментираме според плана: mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Защо да усложняваме? Разбираме, че ще имаме 200 и повече устройства. Не можем да следим всичко. С версия 6.8 на elasticsearch имаме достъп до настройки за безопасност (без да купуваме лиценз), така можем да разпределим правата за преглед между служителите на техническата поддръжка или местните системни администратори.
Таблици, графики – трябва просто да се уговорим – или да използваме единен подход, или всеки да прави така, както му е удобно.

2. За логването. Ако в правилата на защитната стена включим log, имената трябва да са без интервали. Ясно е, че с прост конфиг в fluentd можем да филтрираме данните и да създадем удобни панели. На изображението по-долу - моят домашен рутер.

3. За заетото място и логовете. В средно на 1000 съобщения на час, логовете заемат около 2-3 мб на ден, което, признайте, не е толкова много. Версия elasticsearch 7.5.

ANSIBLE.AWX

Към нашето щастие имаме готов модул за routeros.
Указах за AWX, но командите по-долу са само за ansible в чист вид – мисля, че за тези, които са работили с ansible, няма да възникнат проблеми с използването на gui awx.

Признавам, че преди това гледах други ръководства, където използваха ssh, и всички имаха различни проблеми с времето за отговор и още куп други проблеми. Повтарям, до битка не се стигна, приемайте тази информация като експеримент, който не стигна по-далеч от стенда с 20 рутера.

Нужно е да използваме сертификат или акаунт. Тук решението е ваше, аз залагам на сертификатите. Някои чувствителни моменти относно правата. Давам права за запис – поне “reset config” не може да се направи.

По генерирането, копирането на сертификата и импорта не би трябвало да възникнат проблеми:

Вкратце списък с командиНа вашия компютър
ssh-keygen -t RSA, отговаряме на въпросите, запазваме ключа.
Копираме на mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Предварително трябва да създадем акаунт и да му присвоим права.
Проверяваме свързаността по сертификата
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120

Записваме vi /etc/ansible/hosts
MT01 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT02 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT03 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible
MT04 ansible_network_os=routeros ansible_ssh_port=49475 ansible_ssh_user= ansible

И ето пример за playbook: --- name: add_work_sites
hosts: testmt
serial: 1
connection: network_cli
remote_user: mikrotik.west
gather_facts: yes
tasks:
--- name: add Work_sites
routeros_command:
commands:
--- /ip firewall address-list add address=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
--- /ip firewall address-list add address=habr.com list=work_sites comment=for_habr

Както може да се види от гореприведената конфигурация, съставянето на собствени playbook не е сложна работа. Достатъчно е добре да се усвои cli mikrotik. Да предположим ситуация, при която на всички рутери трябва да се премахне address list с определени данни, тогава:

Намерете и изтрийте/ip firewal address-list remove [find where list=«gov.ru»]

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

При GITLAB всичко е ясно. Няма да се спирам на този момент. Всичко е подредено по отделни задачи, шаблони и обработващи модули.

Powershell

Тук ще има 3 файла. Защо PowerShell? Можете да изберете всякакъв инструмент за генериране на конфигурации, на когото му е удобно. В този случай всичките ни компютри са с Windows, така че защо да правим на bash, когато PowerShell е по-удобен. На кого как е удобно.

Самият скрипт (прост и разбираем):[cmdletBinding()]
Param(
[Parameter(Mandatory=$true)]
[string]$EXTERNALIPADDRESS,
[Parameter(Mandatory=$true)]
[string]$EXTERNALIPROUTE,
[Parameter(Mandatory=$true)]
[string]$BWorknets,
[Parameter(Mandatory=$true)]
[string]$CWorknets,
[Parameter(Mandatory=$true)]
[string]$BVoipNets,
[Parameter(Mandatory=$true)]
[string]$CVoipNets,
[Parameter(Mandatory=$true)]
[string]$CClientss,
[Parameter(Mandatory=$true)]
[string]$BVPNWORKs,
[Parameter(Mandatory=$true)]
[string]$CVPNWORKs,
[Parameter(Mandatory=$true)]
[string]$BVPNCLIENTSs,
[Parameter(Mandatory=$true)]
[string]$cVPNCLIENTSs,
[Parameter(Mandatory=$true)]
[string]$NAMEROUTER,
[Parameter(Mandatory=$true)]
[string]$ServerCertificates,
[Parameter(Mandatory=$true)]
[string]$infile,
[Parameter(Mandatory=$true)]
[string]$outfile
)

Get-Content $infile | Foreach-Object {$_.Replace("EXTERNIP", $EXTERNALIPADDRESS)} |
Foreach-Object {$_.Replace("EXTROUTE", $EXTERNALIPROUTE)} |
Foreach-Object {$_.Replace("BWorknet", $BWorknets)} |
Foreach-Object {$_.Replace("CWorknet", $CWorknets)} |
Foreach-Object {$_.Replace("BVoipNet", $BVoipNets)} |
Foreach-Object {$_.Replace("CVoipNet", $CVoipNets)} |
Foreach-Object {$_.Replace("CClients", $CClientss)} |
Foreach-Object {$_.Replace("BVPNWORK", $BVPNWORKs)} |
Foreach-Object {$_.Replace("CVPNWORK", $CVPNWORKs)} |
Foreach-Object {$_.Replace("BVPNCLIENTS", $BVPNCLIENTSs)} |
Foreach-Object {$_.Replace("CVPNCLIENTS", $cVPNCLIENTSs)} |
Foreach-Object {$_.Replace("MYNAMERROUTER", $NAMEROUTER)} |
Foreach-Object {$_.Replace("ServerCertificate", $ServerCertificates)} | Set-Content $outfile

Моля, извинете ме, не мога да публикувам всички правила, тъй като това ще изглежда не съвсем добре. Можете да съставите правилата сами, ръководейки се от най-добрите практики.

Например, ето списък с линкове, от които се ръководех аз:wiki.mikrotik.com/wiki/Manual:Securing_Your_Router
wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter
wiki.mikrotik.com/wiki/Manual:OSPF-examples
wiki.mikrotik.com/wiki/Drop_port_scanners
wiki.mikrotik.com/wiki/Manual:Winbox
wiki.mikrotik.com/wiki/Manual:Upgrading_RouterOS
wiki.mikrotik.com/wiki/Manual:IP/Fasttrack - тук трябва да знаете, че при активиране на fasttrack правилата за приоритизиране и контрол на трафика няма да работят – полезно за слаби устройства.

Условни обозначения по променливите:За пример са взети следните мрежи:
192.168.0.0/24 работна мрежа
172.22.4.0/24 VOIP мрежа
10.0.0.0/24 мрежа за клиенти без достъп до локалната мрежа
192.168.255.0/24 VPN мрежа за големи филиали
172.19.255.0/24 VPN мрежа за малки

Адресът на мрежата се състои от 4 десетични числа, а именно A.B.C.D, по същия принцип работи и замяната – ако при стартиране се изисква B, значи трябва да запишете за мрежата 192.168.0.0/24 номер 0, а за C = 0.
$EXTERNALIPADDRESS - публичен адрес от доставчика.
$EXTERNALIPROUTE - маршрут по подразбиране към мрежата 0.0.0.0/0
$BWorknets - Работна мрежа, в нашия пример тук ще бъде 168
$CWorknets — Работна мрежа, в нашия пример тук ще бъде 0
$BVoipNets — VOIP мрежа, в нашия пример тук 22
$CVoipNets — VOIP мрежа, в нашия пример тук 4
$CClientss — Мрежа за клиенти – достъп само до интернет, в нашия случай тук 0
$BVPNWORKs — VPN мрежа за големи филиали, в нашия пример 20
$CVPNWORKs — VPN мрежа за големи филиали, в нашия пример 255
$BVPNCLIENTS — VPN мрежа за малки филиали, значи 19
$CVPNCLIENTS — VPN мрежа за малки филиали, значи 255
$NAMEROUTER — име на роутера
$ServerCertificate — име на сертификата, който предварително импортирате
$infile — Укажете пътя до файла, от който ще четем конфигурация, например D:config.txt (по-добре английски път без кавички и интервали)
$outfile — посочете пътя, където да запишете, например D:MT-test.txt

Умишлено промених адресите в примерите по разбираеми причини.

Пропуснах точката за откриване на атаки и аномално поведение – това заслужава отделна статия. Но е важно да се отбележи, че в тази категория могат да се използват стойности от мониторинга с Zabbix + обработени данни от curl с elasticsearch.

На какви моменти е необходимо да се обърне внимание:

1. План на мрежите. Най-добре е да се изготви веднага в четим вид. Напълно достатъчно е excel. За съжаление, много често виждам, че мрежите се планират по принципа "Появи се нов филиал, ето ви /24". Никой не изяснява колко устройства ще има на това място и дали ще има по-нататъшен растеж. Например, откри се малък магазин, в който от самото начало е ясно, че устройствата ще бъдат не повече от 10, защо да се отделя /24? За големите филиали – обратно, отделят /24, а устройствата стават 500 — просто можете да добавите мрежа, но е хубаво всичко да се обмисли предварително.
2. Правила за филтриране. Ако по проекта е планирано, че ще има разделение на мрежите и максимална сегментация. Най-добрите практики с времето се променят. По-рано разделяха мрежата на PCs и мрежата на принтери, сега е напълно приемливо да не се разделят тези мрежи. Струва си да се използва здрава логика и да не се създават множество подсетей там, където не са нужни и да не се обединяват в една мрежа всички устройства.
3. „Златни“ настройки на всички рутери. Т.е. ако сте определили плана. Струва си веднага да се предвиди всичко и да се опитате да се направи така, че всички настройки да са идентични – да има само различни списъци с адреси и IP адреси. В случай на възникнали проблеми, времето за отстраняване на неизправности ще бъде по-малко.
4. Организационните аспекти са не по-малко важни от техническите. Често мързеливи служители изпълняват дадените препоръки "на ръка", без да използват готови конфигурации и скриптове, което в крайна сметка води до проблеми на празно място.

За динамичното маршрутизиране. Използваше се OSPF с зоново деление. Но все пак, това е тестова платформа, в реални условия е по-интересно да се настроят такива неща.

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

Пожелавам на всички през новата година да реализират проектите си. Нека да бъде с вас access granted!!!

Източник: habr.com