Моят нереализиран проект. Мрежа от 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. Документация в Wiki, за написване на документация и ръководства. В този случай ще използваме 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. За логването. Ако в правилата на firewall включим 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. Правила за филтриране. Ако по проекта се предвижда разделение на мрежите и максимална сегментация. Най-добри практики с времето се променят. По-рано разделяха мрежата на компютри и мрежата на принтери, сега е напълно нормално да не се разделят тези мрежи. Трябва да се използва здрав разум и да не се създават множество подсети там, където не са необходими и не се обединяват в една мрежа всички устройства.
3. „Златни“ настройки на всички рутери. Тоест, ако сте се определили с плана. Струва си веднага да предвидите всичко и да се опитате да направите така, че всички настройки да бъдат идентични – да има само различни списъци с адреси и IP адреси. В случай на възникнали проблеми, времето за отстраняване на неизправности ще бъде по-малко.
4. Организационните аспекти не са по-малко важни от техническите. Често мързеливите служители изпълняват дадените указания "на ръка", без да използват готови конфигурации и скриптове, което в крайна сметка води до проблеми на празно място.

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

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

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

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