Мојот незавршен проект. Мрежа од 200 MikroTik рутери

Здраво на сите. Оваа статија е наменета за оние кои имаат многу уреди на Mikrotik во паркот, и кои сакаат да направат максимално обединување за да не се поврзуваат со секој уред посебно. Во оваа статија ќе опишам проект кој, за жал, не достигна борбени услови поради човечки фактори. Накратко: повеќе од 200 рутери, брзо поставување и обука на персоналот, обединување по регион, филтрирање на мрежи и специфични хостови, можност за лесно додавање правила на сите уреди, евиденција и контрола на пристап.

Опишаното подолу не се преправа дека е готов случај, но се надевам дека ќе ви биде корисно при планирање на вашите мрежи и минимизирање на грешките. Можеби некои точки и одлуки нема да ви изгледаат сосема точни - ако е така, пишете во коментарите. Критиката во овој случај ќе биде искуство во заедничка свинче банка. Затоа, читателу, погледнете во коментарите, можеби авторот направил груба грешка - заедницата ќе помогне.

Бројот на рутери е 200-300, расфрлани во различни градови со различен квалитет на интернет конекција. Неопходно е да се направи сè убаво и да се објасни на локалните админи на достапен начин како сè ќе функционира.

Значи, каде започнува секој проект? Се разбира, со ТЗ.

1. Организација на мрежен план за сите филијали според барањата на клиентите, сегментација на мрежата (од 3 до 20 мрежи во филијали, во зависност од бројот на уреди).
2. Поставете уреди во секоја гранка. Проверка на реалниот пропусен опсег на давателот во различни работни услови.
3. Организација на заштита на уредот, контрола на белата листа, автоматско откривање на напади со автоматско ставање црна листа за одреден временски период, минимизирање на употребата на различни технички средства што се користат за пресретнување на контролниот пристап и одбивање на услугата.
4. Организација на безбедни vpn конекции со мрежно филтрирање според барањата на клиентите. Најмалку 3 vpn врски од секоја гранка до центарот.
5. Врз основа на точките 1, 2. Изберете ги најдобрите начини за создавање vpn толерантни за грешки. Технологијата за динамично рутирање, со правилно оправдување, може да ја избере изведувачот.
6. Организација на приоритизација на сообраќајот по протоколи, пристаништа, хостови и други специфични услуги што ги користи клиентот. (VOIP, домаќини со важни услуги)
7. Организација на следење и евидентирање на настани на рутерот за одговор на персоналот за техничка поддршка.

Како што разбираме, во некои случаи, TOR се составува од барањата. Овие барања ги формулирав сам, откако ги слушнав главните проблеми. Тој ја призна можноста некој друг да се зафати со спроведувањето на овие точки.

Кои алатки ќе се користат за исполнување на овие барања:

1. ELK стек (по некое време, се разбра дека ќе се користи fluentd наместо logstash).
2. Ансибилни. За полесно администрирање и споделување на пристапот, ќе користиме AWX.
3. GITLAB. Тука нема потреба да се објаснува. Каде без контрола на верзијата на нашите конфигурации.
4. PowerShell. Ќе има едноставна скрипта за почетната генерација на конфигурацијата.
5. Доку вики, за пишување документација и прирачници. Во овој случај, ние користиме habr.com.
6. Следењето ќе се врши преку zabbix. Ќе има и дијаграм за поврзување за општо разбирање.

Точки за поставување на EFK

На првата точка ќе ја опишам само идеологијата на која ќе се градат индексите. Има многу
одлични статии за поставување и примање дневници од уреди кои работат со mikrotik.

Ќе се задржам на некои точки:

1. Според шемата, вреди да се размисли за примање логови од различни места и на различни пристаништа. За да го направите ова, ќе користиме агрегатор на дневници. Исто така, сакаме да направиме универзална графика за сите рутери со можност за споделување пристап. Потоа ги градиме индексите на следниов начин:

еве дел од конфигурацијата со флуентд elasticsearch
logstash_format true
index_name mikrotiklogs.север
logstash_prefix mikrotiklogs.север
flush_interval 10s
Силите еластичен пребарувач: 9200
порт 9200

Така, можеме да комбинираме рутери и да сегментираме според планот - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Зошто да биде толку тешко? Разбираме дека ќе имаме 200 или повеќе уреди. Не следете сè. Од верзијата 6.8 на elasticsearch, безбедносните поставки ни се достапни (без купување лиценца), така што можеме да ги дистрибуираме правата за гледање помеѓу вработените во техничката поддршка или локалните администратори на системот.
Табели, графикони - тука само треба да се согласите - или користете ги истите, или секој го прави тоа како што ќе му биде погодно.

2. Со сеча. Ако ги овозможиме правилата за логирање на заштитен ѕид, тогаш имињата ги правиме без празни места. Може да се види дека користејќи едноставна конфигурација во fluentd, можеме да ги филтрираме податоците и да направиме пригодни панели. Сликата подолу е мојот домашен рутер.

3. Според зафатениот простор и дневниците. Во просек, со 1000 пораки на час, дневниците зафаќаат 2-3 MB дневно, што, гледате, не е толку многу. elasticsearch верзија 7.5.

ANSIBLE.AWX

За наша среќа, имаме готов модул за рутери
Посочив за AWX, но командите подолу се однесуваат само на ansible во неговата најчиста форма - мислам дека за оние кои работеле со ansible, нема да има проблеми со користење на awx преку gui.

Да бидам искрен, пред тоа гледав други водичи каде што користеа ssh, и секој имаше различни проблеми со времето на одговор и еден куп други проблеми. Повторувам, не стигна до битката , земете ја оваа информација како експеримент што не отиде подалеку од штандот од 20 рутери.

Треба да користиме сертификат или сметка. Ваше е да одлучите, јас сум за сертификати. Некоја суптилна точка за правата. Ги давам правата за пишување - барем „ресетирањето на конфигурацијата“ нема да работи.

Не треба да има проблеми со генерирање, копирање на сертификатот и увоз:

Краток список на командиНа вашиот компјутер
ssh-keygen -t RSA, одговорете на прашања, зачувајте го клучот.
Копирај на mikrotik:
кориснички ssh-клучеви увезуваат public-key-file=id_mtx.pub user=ansible
Прво треба да креирате сметка и да доделите права на неа.
Проверка на врската со сертификатот
ssh -p 49475 -i /keys/mtx [заштитена по е-пошта]

Напишете vi /etc/ansible/hosts
MT01 ansible_network_os=рутери ansible_ssh_port=49475 ansible_ssh_user= одговорен
MT02 ansible_network_os=рутери ansible_ssh_port=49475 ansible_ssh_user= одговорен
MT03 ansible_network_os=рутери ansible_ssh_port=49475 ansible_ssh_user= одговорен
MT04 ansible_network_os=рутери ansible_ssh_port=49475 ansible_ssh_user= одговорен

Па, пример за игротека: име: add_work_sites
домаќини:testmt
сериски: 1
врска:network_cli
remote_user: mikrotik.west
собирај_факти: да
задачи:
име: додадете Work_sites
routeros_command:
команди:
- /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

Како што можете да видите од горната конфигурација, составувањето на вашите сопствени книги за игри е едноставна работа. Доволно е добро да се совлада cli mikrotik. Замислете ситуација кога треба да го отстраните списокот со адреси со одредени податоци на сите рутери, а потоа:

Најдете и отстранете/ip firewal address-list отстрани [пронајди каде list="gov.ru"]

Намерно не го вклучив целиот список на заштитен ѕид овде. тоа ќе биде индивидуално за секој проект. Но, можам да кажам едно нешто со сигурност, користете го само списокот со адреси.

Според GITLAB, сè е јасно. Нема да се задржувам на овој момент. Сè е убаво во однос на индивидуалните задачи, шаблони, ракувачи.

PowerShell

Ќе има 3 датотеки. Зошто powershell? Алатката за генерирање на конфигурации може да ја избере секој кој е поудобен. Во овој случај, секој има Windows на својот компјутер, па зошто да го правиме тоа на bash кога powershell е поудобен. Кој е поудобен.

Самото сценарио (едноставно и разбирливо):[cmdletBinding()] Парама(
[Параметар(Задолжителен=$true)] [низа]$EXTERNALIPADRESS,
[Параметар(Задолжителен=$true)] [низа]$EXTERNALIPROUTE,
[Параметар(Задолжителен=$true)] [низа]$BWorknets,
[Параметар(Задолжителен=$true)] [низа]$CWorknets,
[Параметар(Задолжително=$true)] [низа]$BVoipNets,
[Параметар(Задолжително=$true)] [низа]$CVoipNets,
[Параметар(Задолжителен=$true)] [низа]$CClientss,
[Параметар(Задолжително=$true)] [низа]$BVPNWORKs,
[Параметар(Задолжителен=$true)] [низа]$CVPNWORKs,
[Параметар(Задолжителен=$true)] [низа]$BVPNCLIENTS,
[Параметар(Задолжителен=$true)] [низа]$cVPNCLIENTS,
[Параметар(Задолжително=$true)] [низа]$NAMEROUTER,
[Параметар(Задолжителен=$true)] [string]$ServerCertificates,
[Параметар(Задолжителен=$true)] [низа]$infile,
[Параметар(Задолжително=$true)] [низа]$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/Филтер
wiki.mikrotik.com/wiki/Manual:OSPF-примери
wiki.mikrotik.com/wiki/Drop_port_scanners
wiki.mikrotik.com/wiki/Manual:Винбокс
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 мрежа за клиенти без пристап до LAN
192.168.255.0/24 VPN мрежа за големи филијали
172.19.255.0/24 VPN мрежа за мали

Адресата на мрежата се состои од 4 децимални броеви, соодветно ABCD, замената работи по истиот принцип, ако бара 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 + разработени податоци за навивам од elasticsearch.

На кои точки треба да се фокусираме:

1. Мрежен план. Подобро е да се напише во читлива форма. Екселот е доволен. За жал, често гледам дека мрежите се компајлираат по принципот „Се појави нова гранка, еве /24 за вас“. Никој не дознава колку уреди се очекуваат на дадена локација и дали ќе има понатамошен раст. На пример, се отвори мала продавница, во која првично е јасно дека уредот нема да биде повеќе од 10, зошто да одвои / 24? За големи филијали, напротив, тие доделуваат / 24, а има 500 уреди - можете само да додадете мрежа, но сакате да размислите сè веднаш.
2. Правила за филтрирање. Доколку проектот претпостави дека ќе има раздвојување на мрежите и максимална сегментација. Најдобрите практики се менуваат со текот на времето. Претходно, тие споделуваа компјутерска мрежа и мрежа на печатачи, сега е сосема нормално да не ги споделувате овие мрежи. Вреди да се користи здравиот разум и да не се произведуваат многу подмрежи каде што не се потребни и да не се комбинираат сите уреди во една мрежа.
3. „Златни“ поставки на сите рутери. Оние. ако имаш план. Вреди да се предвиди сè одеднаш и да се обидете да бидете сигурни дека сите поставки се идентични - има само различни адреси и ip адреси. Во случај на проблеми, времето за дебагирање ќе биде помало.
4. Организациските аспекти не се помалку важни од техничките. Често, мрзливите вработени ги следат овие препораки „рачно“, без да користат готови конфигурации и скрипти, што на крајот доведува до проблеми од нула.

Со динамично рутирање. Се користеше OSPF со зонирање. Ама ова е тест клупа, во борбени услови вакви работи се поинтересни за поставување.

Се надевам дека никој не се вознемири што не ја објавив конфигурацијата на рутерите. Мислам дека линковите ќе бидат доволни, а потоа се зависи од барањата. И секако тестови, потребни се повеќе тестови.

На сите им посакувам да ги реализираат своите проекти во новата година. Доделениот пристап нека биде со вас!!!

Извор: www.habr.com