Minu realiseerimata projekt. 200 MikroTiki ruuteri võrk.

Tere kõigile. Käesolev artikkel on mõeldud neile, kelle seadmete seas on palju MikroTiki seadmeid ja kes soovivad maksimaalset ühtlustamist, et mitte iga seadmega eraldi ühendust võtta. Kirjeldan projekti, mis kahjuks ei jõudnud lahingutingimustesse inimfaktorite tõttu. Lühidalt: üle 200 ruuteri, kiire seadistamine ja personali koolitus, ühtlustamine piirkondade kaupa, võrgu ja teatud hostide filtreerimine, võimalus lihtsasti lisada reegleid kõigile seadmetele, logimine ja juurdepääsu kontroll.

Allpool kirjeldatu ei pretendeeri olema valmis lahendus, kuid loodetavasti on see teile kasulik oma võrkude planeerimisel ja vigade minimeerimisel. Võib-olla tunduvad mõned punktid ja lahendused teile mitte just õiged – kui nii, kirjutage kommentaaridesse. Kriitika on selles osas kogemus, mille paneme kõik koos kokku. Seega, lugeja, vaata kommentaare, võib-olla on autor teinud suure vea – kogukond aitab.

Maruturite 200–300 on eri linnades ja erineva kvaliteediga Interneti-ühendustega. On vajalik, et kõik oleks kaunis ja selgelt seletatud kohalikele administraatoritele, kuidas kõik töötab.

Nii et iga projekti alustamine läheb alates TTP.

1. Võrkude planeerimine kõikide harude vahel vastavalt kliendi nõudmistele, võrkude segmenteerimine (3 kuni 20 võrku harudes sõltuvalt seadmete arvust).
2. Seadmete seadistamine igas haru. Teenusepakkuja tegeliku läbilaskevõime kontrollimine erinevates töötingimustes.
3. Seadmete kaitse korraldamine, juhtimine valge nimekirja alusel, rünnakute automaatne tuvastamine koos automaatse lisamisega musta nimekirja teatud ajaperioodiks, erinevate tehniliste vahendite kasutamise vähendamine, mis on seotud juurdepääsu kontrollimise püüdmise ja teenuse tagasilükkamisega.
4. Kaitstud VPN-ühenduste korraldamine, filtreerimine võrkude alusel vastavalt kliendi nõudmistele. Igal harul peab olema vähemalt 3 VPN-ühendust keskusesse.
5. Punktist 1, 2. Valige optimaalsed teed vea taastamise VPN-ide loomiseks. Dünaamilise suunamise tehnoloogia võib olla valitud teostaja poolt, kui see on õigesti põhjendatud.
6. Trafiku prioriseerimise korraldamine protokollide, portide, hostide ja muude spetsiifiliste teenuste põhjal, mida kasutab klient. (VOIP, hostid oluliste teenustega)
7. Marsruuterite sündmuste jälgimise ja logimise korraldamine tehnilise toe töötajate reageerimise jaoks.

Kuidas me mõistame, et mõnel juhul koostatakse TBa nõuetest. Need nõuded olen koostanud iseseisvalt, kuuldes peamisi probleeme. Olen arvesse võtnud võimalust, et nende punktide täitmisega võib tegeleda keegi teine.

Milliseid tööriistu kasutatakse nende nõuete täitmiseks:

1. ELK stack (mõne aja pärast tuli arusaam, et logstashi asemel kasutatakse fluentd).
2. Ansible. Halduse mugavuse ja juurdepääsu jagamise jaoks kasutame AWX-i.
3. GITLAB. Siin pole vaja selgitada. Kuidas me saaksime ilma versioonide kontrollita meie konfiguratsioonidest.
4. PowerShell. Algse konfi genereerimise jaoks on lihtne skript.
5. Dokumentatsiooni ja juhendite koostamiseks mõeldud wiki. Antud juhul kasutame habr.com.
6. Jälgimine toimub läbi zabbixi. Seal on samuti joonistatud ühenduse skeem üldiseks arusaamiseks.

EFK seadistamise hetked

Esimese punkti puhul kirjeldan ainult ideoloogiat, mille alusel indeksid üles ehitatakse. On palju
suurepäraseid artikleid logide seadistamise ja vastuvõtmise kohta mikrotiki seadmetelt.

Räätan mõned aspektid:

1. Skeemi kohaselt tuleks läbi mõelda logide vastuvõtt erinevatest kohtadest ja erinevatelt portidelt. Selleks kasutame logide kogujat. Samuti soovime luua universaalsed graafikud kõigi ruuterite jaoks puhtuse õiguste jagamise võimalusega. Seega koostame indeksid järgmiselt:

siin on osa konfiguratsioonist fluentd jaoks tüüp elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts elasticsearch:9200
port 9200

Seega saame ruuterid ühendada ja segmentida plaani järgi - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Miks nii keeruliseks minna? Me mõistame, et meil on rohkem kui 200 seadet. Kõike ei jõua jälgida. Alates versioonist 6.8 on elasticsearchile saadaval turvaseaded (ilma litsentsi ostmata), nii et saame jagada vaatamisõigusi tehnikatoe töötajate või kohalike süsteemihaldurite vahel.
Tabelid, graafikud – siin tuleb lihtsalt kokku leppida — kas kasutada ühesuguseid või igaüks teeb nagu endale mugav on.

2. Logimise kohta. Kui lülitame tulemüüris sisse logimist, siis teeme nimed ilma tühikuteta. On selge, et kasutades lihtsat konfigureerimist fluentd-s, saame andmeid filtreerida ja mugavaid paneele luua. Alloleval pildil on minu kodune ruuter.

3. Kasutatava koha ja logide kohta. Keskmiselt, 1000 sõnumi puhul tunnis, võtavad logid 2-3 MB päevas, mis pole nii palju, nõustute? Versioon elasticsearch 7.5.

ANSIBLE.AWX

Meie õnneks on meil valmidusmodul routeros-ile.
Tõin AWX-i esile, kuid allpool olevad käsud käsitlevad ainult Ansible’i puhtal kujul – arvan, et Ansible’i kasutanud inimesed ei pea AWX-i kaudu töötamisel mingeid probleeme kogema.

Pean tunnistama, et enne seda vaatasin mitmeid teisi juhiseid, kus kasutati SSH-d, ja kõigil olid erinevad probleemid vastuse ajaga ja veel hulga muude probleemidega. Kordan, et lahinguni ei jõudnud, käsitlege seda teavet eksperimentina, mis ei jõudnud kaugemale 20 marsruuterist.

Me peame kasutama sertifikaati või kontot. Siin on teil valida, mina eelistan sertifikaate. Teatud õiguslik nüanss. Annen õigused kirjutamiseks – vähemalt „reset config” tegemine ei õnnestu.

Sertifikaadi genereerimise, kopeerimise ja impordiga ei tohiks probleeme olla:

Lühidalt käsude loeteluTeie arvutis
ssh-keygen -t RSA, vastake küsimustele, salvestage võti.
Kopeerime Mikrotikule:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Esmalt tuleb luua konto ja talle õ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 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 eelnevalt toodud konfiguratsioonist näha, on enda playbooki koostamine lihtne ülesanne. Piisab, kui oskad mikrotiki CLI-d.

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

Jätsin siia kogu tulemiste nimekirja sisse panemata, kuna see on igale projektile individuaalne. Aga võin ütelda, et kasutage ainult address list-i.

GITLABi osas on kõik selge. Ei peatuks sellel teemal. Kõik on ilusasti jagatud eraldi ülesanneteks, mallideks, käitlejateks.

Powershell

Siin on kolm faili. Miks PowerShell? Konfiguratsioonide genereerimise tööriista saab valida igaüks, kellele mis sobib. Antud juhul on kõigil arvutites Windows, seega miks teha bashis, kui PowerShell on mugavam. Igaühele, kellele mis sobib.

Otse skripti (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 andestage, ma ei saa kõiki reegleid jagada, kuna see ei näeks just kõige paremini välja. Saate neid ise koostada, järgides parimaid tavasid.

Näiteks siin on linkide loetelu, mille põhjal 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 — siinkohal on oluline teada, et fasttracki aktiveerimisel ei tööta prioritiseerimise ja liikluse kujundamise reeglid – kasulik nõrkade seadmete puhul.

Muutujate tähised:Võetud näitena järgmised võrgud:
192.168.0.0/24 töönet
172.22.4.0/24 VOIP võrk
10.0.0.0/24 klientide võrk, kellel puudub juurdepääs kohalikule võrgule
192.168.255.0/24 VPN võrk suurematele harukontoritele
172.19.255.0/24 VPN võrk väikestele

Võrgu aadress koosneb neljast kümnendnumbrist, vastavalt A.B.C.D, selle põhimõtte järgi töötab ka asendamine; kui käivitamisel küsitakse B, tähendab see, et peate sisestama võrgu 192.168.0.0/24 numbriga 0 ja C = 0.
$EXTERNALIPADDRESS — operaatori poolt määratud staatiline aadress.
$EXTERNALIPROUTE — vaikimisi marsruut võrgule 0.0.0.0/0
$BWorknets — Töönet, meie näites on siin 168
$CWorknets — Töönet, meie näites on siin 0
$BVoipNets — VOIP võrk, meie näites on siin 22
$CVoipNets — VOIP võrk, meie näites on siin 4
$CClientss — Klientide võrk – ainult interneti juurdepääs, meie juhtumiga siin 0
$BVPNWORKs — VPN võrk suurematele harukontoritele, meie näites 20
$CVPNWORKs — VPN võrk suurematele harukontoritele, meie näites 255
$BVPNCLIENTS — VPN võrk väikestele harukontoritele, tähendab 19
$CVPNCLIENTS — VPN võrk väikestele harukontoritele, tähendab 255
$NAMEROUTER — ruuteri nimi
$ServerCertificate — sertifikaadi nimi, mille te eelnevalt impordite
$infile — Määrake failitee, kust loeme konfiguratsiooni, näiteks D:config.txt (parem on kasutada ingliskeelset teed ilma jutumärkide ja tühikuteta)
$outfile — määrake tee, kuhu salvestada, näiteks D:MT-test.txt

Ma muutsin näidetes aadresse teadlikult arusaadavatel põhjustel.

Jätsin vahele ründeteadlikkuse ja ebanormaalse käitumise tuvastamise punkti – see väärib eraldi artiklit. Siiski tasub märkida, et selles kategoorias võib kasutada Zabbixi jälgimisandmeid koos ElasticSearch'i töötlemata andmetega.

Millistele punktidele tuleks tähelepanu juhtida:

1. Võrguplaan. On parem koostada kohe arusaadaval kujul. Excel on täiesti piisav. Kahjuks näen sageli, et võrke koostatakse põhimõttel "Ilmus uus filiaal, siin on /24". Keegi ei selgita, kui palju seadmeid selles kohas eeldatakse ja kas tulevikus on kasv. Näiteks avati väike pood, kus on algselt selge, et seadmeid ei tule rohkem kui 10, milleks eraldada /24? Suuremates filiaalides eraldatakse vastupidi /24, kuid seadmeid on 500 — võrku saab lihtsalt lisada, aga tahaks kõik kohe läbi mõelda.
2. Filtreerimise reeglid. Kui projektis eeldatakse võrgu eraldamist ja maksimaalset segmentimist. Parimad praktikad muutuvad ajaga. Varem jagati arvutivõrk ja printerivõrk, praegu on täiesti normaalne, et neid võrke ei jagata. Tuleb kasutada mõistust ja mitte luua liiga palju alamvõrke seal, kus need pole vajalikud, ega ühendada kõiki seadmeid ühte võrku.
3. „Kuldne” seadistus kõigis ruuterites. St, kui olete plaaniga otsustanud, tuleks kohe kõik ette näha ja püüda teha nii, et kõik seadistused oleksid identsed – ainult erinevad aadressi nimekirjad ja IP-aadressid. Probleemide hetkel on vähem aega tõrgete kõrvaldamiseks.
4. Organisatsioonilised küsimused on sama olulised kui tehnilised. Sageli täidavad laiskad töötajad antud soovitusi „käsitsi”, kasutamata valmis konfiguratsioone ja skripte, mis lõpuks toob kaasa probleeme tühjas kohas.

Dünaamilise marsruutimise kohta. Kasutati OSPF-i tsoonide jagamisega. Kuid see on testkeskkond, lahingutingimustes on selliseid asju huvitavam seadistada.

Loodan, et mitte keegi ei pettunud, et ma marsruutijate konfiguratsioone jaganud ei ole. Usun, et linkidest piisab ning edasi sõltub kõik nõudmistest. Ja loomulikult testidest; testid on hädavajalikud.

Soovin kõigile uue aasta puhul oma projekte ellu viia. Olgu teiega access granted!!!

Allikas: habr.com