Minu elluviimata projekt. 200 MikroTik marsruutijaga võrk.

Tere kõigile. See artikkel on mõeldud neile, kellel on rohkesti MikroTik seadmeid, ja kes soovivad saavutada maksimaalset ühtsust, et mitte ühendada igat seadet eraldi. Selles artiklis kirjeldan projekti, mis kahjuks ei jõudnud reaalsesse ellu inimfaktorite tõttu. Lühidalt: üle 200 ruuteri, kiire seadistamine ja personali koolitus, ühtsuse saavutamine piirkondade kaupa, võrgu ja teatud hostide filtreerimine, lihtne reeglite lisamise võimalus kõikidele seadmetele, logimine ja ligipääsu kontroll.

Allpool kirjeldatu ei pretendeeri valmi juhtumile, kuid loodan, et see aitab teil oma võrkude planeerimisel ja vigade minimeerimisel. Võib-olla tunduvad mõned punktid ja lahendused teile mitte eriti õiged - kui nii, siis kirjutage kommentaarides. Kritiseerimine on antud juhul kogemus meie ühisesse kogumisse. Seega, lugeja, vaata kommentaare, võib-olla on autor teinud tõsise vea - kogukond aitab.

Ruuterite arv 200-300, hajutatud erinevatesse linnadesse erineva internetiühenduse kvaliteediga. On vajalik, et kõik oleks ilus ja arusaadav, et selgitada kohalikele administreerijatele, kuidas kõik töötab.

Nii, millest iga projekt algab. Muidugi, TEx.

1. Võrkude plaanide korraldamine kõikides filiaalides vastavalt kliendi nõudmistele, võrkude segmentatsioon (3 kuni 20 võrku filiaalides sõltuvalt seadmete arvust).
2. Seadmete seadistamine igas filiaalis. Pakkuja tegeliku läbilaskevõime kontrollimine erinevates töötingimustes.
3. Seadmete kaitse korraldamine, haldamine valgelistide alusel, rünnakute automaatne tuvastamine ja musta nimekirja automaatne lisamine kindlaksmääratud ajavahemikuks, erinevate tehniliste vahendite kasutamise minimeerimine, mis võivad juhtimise juurdepääsu tabamise kohta ja teenindamisest loobumise.
4. Kaitstud VPN-ühenduste korraldamine võrgu filtreerimisega vastavalt kliendi nõudmistele. Iga filiaali vähemalt 3 VPN-ühendust keskusesse.
5. Punktide 1 ja 2 põhjal. Valige optimaalsed teed tõrkekindlate VPN-ide ehitamiseks. Dynaamilise marsruutimise tehnoloogia, kui see on õigesti põhjendatud, võib valida teostaja.
6. Liiklusprioriteetide korraldamine protokollide, portide, hostide ja teiste spetsiifiliste teenuste põhjal, mida klient kasutab. (VOIP, hostid oluliste teenuste jaoks)
7. Marsruuterite sündmuste jälgimise ja logimise korraldamine tehnilise toe töötajate reageerimise jaoks.

Kuidas me mõistame, koostatakse tehnilised nõuded teatud juhtudel. Need nõuded koostasin ise, kuuldes põhiprobleeme. Olen arvestanud, et nende punktide täitmisega võib tegeleda keegi teine.

Milliseid vahendeid kasutatakse nende nõuete täitmiseks:

1. ELK stack (aegade möödudes tuli arusaam, et logstashi asemel kasutatakse fluentd).
2. Ansible. Mugavuse huvides haldamise ja juurdepääsu jagamise jaoks kasutame AWX-i.
3. GITLAB. Siin pole vaja pikalt seletada. Kuidas ilmanekse versioonikontrollid meie konfiguratsioonide jaoks.
4. PowerShell. Algse konfiguratsiooni genereerimiseks tuleb lihtne skript.
5. Dokuwiki, dokumentatsiooni ja juhendite kirjutamiseks. Antud juhul kasutame habr.com.
6. Jälgimist teostatakse zabbixi kaudu. Seal joonistatakse ka ühenduste skeem üldiseks arusaamiseks.

EFK seadistamise hetked

Esimese punkti puhul kirjeldan ainult ideoloogiat, millega indeksid luuakse. On palju
ilusate artiklite seas seadistamise ja logide vastuvõtmise kohta mikrotik seadmetest.

Peatun mõningatel hetkedel:

1. Skeemi kohaselt tuleks kaaluda logide vastuvõtmist erinevates kohtades ja erinevatel portidel. Selleks kasutame logide kogujat. Samuti soovime teha universaalseid graafikuid kõigi marsruuterite jaoks juurdepääsu jagamise võimalusega. Seega loome indeksid järgmiselt:

see on kild konfiguratsioonist fluentd tüüp elasticsearch
logstash_format true
indeksi_nimi mikrotiklogs.north
logstash_prefix mikrotiklogs.north
välgukeskmine 10s
hostid elasticsearch:9200
port 9200

Nii saame marsruuterid ühendada ja segmentida plaani kohaselt - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Miks nii keeruliseks teha? Me mõistame, et meil on üle 200 seadme. Kõike ei saa jälgida. Elasticsearchi versiooniga 6.8 on meil saadaval turvaseaded (ilma litsentsi ostmata), seega saame jagada õigusi vaatamiseks tehnilise toe töötajate või kohalike süsteemiadministraatorite vahel.
Tabelid, graafikud – siin tuleb lihtsalt kokku leppida, kas kasutada ühtseid või lasta igalühel teha, nagu tahab.

2. Logimise kohta. Kui firewall'i reeglites aktiveerime logi, siis nimed teeme ilma tühikuteta. Näha on, et kasutades lihtsat konfiguratsiooni fluentd's, saame andmeid filtreerida ja mugavaid paneele teha. Alloleval pildil on minu kodune ruuter.

3. Ruumi ja logide kohta. Keskmiselt, 1000 sõnumit tunni kohta, logid võtavad 2-3 MB päevas, mis, nõustuge, ei ole palju. Elasticsearchi versioon 7.5.

ANSIBLE.AWX

Kuni meie õnneks on meil olemas valmis moodul routeros'ele.
Mainisin AWX-i, kuid allolevad käsud on ainult ansible'i puhtal kujul – arvan, et need, kes on ansible'iga töötanud, ei saa AWX kaudu kasutamisel probleeme.

Tunnistan ausalt, et enne vaatasin teisi juhiseid, kus kasutati ssh-d, ja kõigil olid erinevad probleemid reageerimise ajaga ning veel hulk muid probleeme. Kordan, enne lahingut ei läinud; käsitlege seda teavet nagu eksperimenti, mis ei jõudnud kaugemale 20 ruuterist.

Me peame kasutama sertifikaati või kontot. Siin otsustate teie, mina olen sertifikaatide poolt. Mõned peened punktid õiguste osas. Teen õigused write – vähemalt "reset config" teha ei õnnestu.

Sertifikaadi genereerimise, kopeerimise ja impordiga ei tohiks probleeme tekkida:

Lühidalt käsutuste loeteluTeie arvutis
ssh-keygen -t RSA, vastame küsimustele, salvestame võtme.
Kopeerime mikrotik'ule:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Eelnevalt tuleb konto luua ja sellele õigused määrata.
Kontrollime ühendust sertifikaadi kaudu
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120

Kirjutame 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

Ja siin on näide playbookist: -- 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

Kuidas näha ülaltoodud konfiguratsioonist, oma playbookide koostamine pole keeruline. Piisab, kui hästi osata mikrotik'i CLI-d. Kujutame ette olukorda, kus kõikide ruuterite pealt tuleb eemaldada address list teatud andmetega, siis:

Leida ja eemaldada/ip firewal address-list remove [find where list=«gov.ru»]

Ma ei lisanud siia kogu tulemusi tulemüüri kohta, kuna need on iga projekti jaoks individuaalsed. Aga ma võin kindlalt öelda, et kasutage ainult aadressi loendit.

GITLABi osas on kõik selge. Ma ei peatuks sellel hetkel. Kõik on kenasti eraldi ülesannetes, mallides ja käitlejates.

Powershell

Siin on kolm faili. Miks Powershell? Konfiguratsioonide genereerimiseks võib valida ükskõik millise tööriista, olenevalt sellest, mis kellelegi mugavam on. Antud juhul on kõigil arvutites Windows, seega miks teha bash'i peal, kui Powershell on mugavam. Kellelegi, mis on mugav.

Siin on ise skript (lihtne ja arusaadav):[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

Palun andke andeks, ma ei saa kõiki reegleid avaldada, kuna see ei oleks just ilus. Reegleid saate ise koostada, järgides parimaid praktikaid.

Näiteks, siin on linkide loetelu, mille järgi mina juhindusin: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 — siin tuleb märkida, et fasttrack'i sisselülitamisel ei tööta prioriseerimise ja liikluskuju reeglid – kasulik nõrkadele seadmetele.

Märkused muutujate kohta:Näiteks on võetud järgmised võrgud:
192.168.0.0/24 töövõrk
172.22.4.0/24 VOIP võrk
10.0.0.0/24 võrk klientidele, kellel pole juurdepääsu kohalikule võrgule
192.168.255.0/24 VPN võrk suurtele osakondadele
172.19.255.0/24 VPN võrk väikestele

Võrgu aadress koosneb neljast kümnendarvust, vastavalt A.B.C.D, toimetatakse sarnasel põhimõttel asendamist, kui käivitamisel küsitakse B, siis tuleb sisestada võrgu 192.168.0.0/24 numbri 0 jaoks, ja C = 0.
$EXTERNALIPADDRESS — määratud aadress teenusepakkujalt.
$EXTERNALIPROUTE — vaikimisi marsruut võrku 0.0.0.0/0
$BWorknets — Töövõrk, meie näites on siin 168
$CWorknets — Töövõrk, meie näites on siin 0
$BVoipNets — VOIP võrgustik meie näites siin 22
$CVoipNets — VOIP võrgustik meie näites siin 4
$CClientss — Klientide võrk – juurdepääs ainult internetile, meie puhul siin 0
$BVPNWORKs — VPN võrgustik suurtele harudele, meie näites 20
$CVPNWORKs — VPN võrgustik suurtele harudele, meie näites 255
$BVPNCLIENTS — VPN võrgustik väikestele harudele, tähendab 19
$CVPNCLIENTS — VPN võrgustik väikestele harudele, tähendab 255
$NAMEROUTER — ruuteri nimi
$ServerCertificate — sertifikaadi nimi, mille eelnevalt impordite
$infile — Määrake failitee, millelt konfi loeme, näiteks D:config.txt (parem ingliskeelne tee ilma jutumärkide ja tühikuteta)
$outfile — määrake tee, kuhu salvestada, näiteks D:MT-test.txt

Ma muutsin näidatud aadresse tahtlikult arusaadavatel põhjustel.

Jätan välja rünnakute ja ebanormaalse käitumise tuvastamise punkti – see väärib eraldi artiklit. Kuid tasub märkida, et selle kategooria korral on võimalik kasutada jälgimisandmeid Zabbix'ist + töötatud andmeid curl'iga elasticsearchist.

Millistele momentidele tuleks tähelepanu pöörata:

1. Võrgud. Paremini koostada kohe loetaval kujul. Excel on täiesti piisav. Kahjuks näen väga sageli, et võrgud koostatakse põhimõtte järgi 'Ilmus uus haru, siin on teile /24'. Keegi ei uurige, kui palju seadmeid antud kohas eeldatakse ja kas edasine kasv on võimalik. Näiteks avati väike pood, kus on algselt selge, et seadmeid ei ole rohkem kui 10, miks eraldada /24? Suurte harude puhul – vastupidi, eraldatakse /24, kuid seadmeid on 500 — lihtsalt saab võrku lisada, kuid tahaks kõike kohe läbi mõelda.
2. Filtreerimise reeglid. Kui projektis eeldatakse, et võrgud on eraldatud ja maksimaalne segmenteerimine. Parim praktika muutub ajas. Varasemalt eraldati arvutivõrk ja printerivõrk, nüüd on täiesti normaalne neid võrke mitte eraldada. Tuleb kasutada tervet mõistust ja mitte paljundada palju alamvõrke seal, kus neid ei vajata, ning mitte ühendada kõiki seadmeid ühte võrku.
3. Kuldsed seaded kõigil ruuteritel. See tähendab, et kui olete planeeringuga määratlenud, tuleks kohe kõik ette näha ja püüda teha nii, et kõik seadistused oleksid identsed – oleksid ainult erinevad aadresside loendid ja IP-aadressid. Probleemide tekkimisel on aega tõrgete kõrvaldamiseks vähem.
4. Organisatsioonilised aspektid on sama olulised kui tehnilised. Tihti täidavad laisad töötajad antud soovitusi "manuaalselt", kasutades valmis konfiguratsioone ja skripte, mis lõpuks toob kaasa probleeme, mille tõttu on asjata.

Dünaamilise marsruutimise kohta. Kasutati OSPF-i koos tsoonide jagamisega. Kuid see on testimisstand, tõelistes tingimustes on selliste asjade seadistamine palju huvitavam.

Loodan, et keegi ei olnud kurb, et ma ei postitanud marsruuterite konfiguratsioone. Arvan, et lingid on piisavad, edasi sõltub kõik nõudmistest. Ja muidugi testid, vajalik on rohkem teste.

Soovin kõigile uuel aastal oma projekte ellu viia. Olgu teie kõrval access granted!!!

Allikas: habr.com