Sveiki visiem. Šis raksts ir paredzēts tiem, kam ir liels Mikrotik tīkls un kuri vēlas panākt maksimālu apvienošanu, nepieslēdzoties katrai ierīcei atsevišķi. Šajā rakstā aprakstīšu projektu, kas diemžēl cilvēcisku kļūdu dēļ nekad netika sasniegts ražošanas vidē. Īsumā: vairāk nekā 200 maršrutētāju, ātra iestatīšana un personāla apmācība, apvienošana pēc reģiona, tīkla un resursdatora filtrēšana, iespēja viegli pievienot noteikumus visām ierīcēm, reģistrēšana un piekļuves kontrole.
Zemāk aprakstītais nav paredzēts kā pilnīgs gadījuma izpētes apraksts, taču ceru, ka tas būs noderīgs, plānojot savus tīklus un samazinot kļūdas. Varbūt daži punkti un risinājumi jums nešķiet pilnīgi pareizi — ja tā, lūdzu, paziņojiet man komentāros. Kritika šajā gadījumā būs kopīga mācību pieredze. Tāpēc, lasītāj, lūdzu, pārbaudiet komentārus; iespējams, autors ir pieļāvis nopietnu kļūdu — kopiena labprāt palīdzēs.
Dažādās pilsētās ir izkaisīti 200–300 maršrutētāji ar atšķirīgu interneta savienojuma kvalitāti. Visam jābūt skaisti izstrādātam un vietējiem administratoriem skaidri izskaidrotam, kā tas darbosies.
Tātad, kur sākas jebkurš projekts? Protams, ar TK.
- Tīkla plāna organizēšana visām filiālēm atbilstoši klienta prasībām, tīkla segmentācija (no 3 līdz 20 tīkliem filiālēs atkarībā no ierīču skaita).
- Ierīces iestatīšana katrā filiālē. Pakalpojumu sniedzēja faktiskā caurlaidspējas ātruma pārbaude dažādos darbības apstākļos.
- Ierīču aizsardzības organizēšana, baltā saraksta pārvaldība, uzbrukumu automātiska noteikšana ar automātisku melno sarakstu uz noteiktu laika periodu, dažādu tehnisko līdzekļu izmantošanas samazināšana, ko izmanto, lai pārtvertu kontroles piekļuvi un pakalpojuma atteikumu.
- Drošu VPN savienojumu izveide ar tīkla filtrēšanu atbilstoši klienta prasībām. Vismaz trīs VPN savienojumi no katras filiāles uz centrālo biroju.
- Pamatojoties uz 1. un 2. punktu, izvēlieties optimālos ceļus kļūdu tolerantu VPN izveidei. Darbuzņēmējs var izvēlēties dinamiskās maršrutēšanas tehnoloģiju ar pienācīgu pamatojumu.
- Trafika prioritāšu noteikšana, pamatojoties uz protokoliem, portiem, resursdatoriem un citiem klienta izmantotajiem specifiskajiem pakalpojumiem (VOIP, resursdatori ar kritiski svarīgiem pakalpojumiem)
- Maršrutētāja notikumu uzraudzības un reģistrēšanas organizēšana, lai tehniskā atbalsta personāls varētu reaģēt.
Kā mēs saprotam, dažos gadījumos specifikācijas ir balstītas uz prasībām. Es pats formulēju šīs prasības, uzklausot galvenos jautājumus. Es pieļāvu iespēju, ka kāds cits varētu uzņemties šo punktu ieviešanu.
Kādi rīki tiks izmantoti, lai izpildītu šīs prasības:
- ELK steks (pēc kāda laika kļuva skaidrs, ka logstash vietā tiks izmantots fluentd).
- Ansible. Administrēšanas un piekļuves kontroles ērtībai mēs izmantosim AWX.
- GITLAB. Tas nav jāskaidro. Mēs nevarētu iztikt bez mūsu konfigurāciju versiju kontroles.
- PowerShell. Sākotnējās konfigurācijas ģenerēšanai būs vienkāršs skripts.
- Vikipēdija dokumentācijas un rokasgrāmatu rakstīšanai. Šajā gadījumā mēs izmantojam habr.com.
- Uzraudzība tiks veikta, izmantojot Zabbix. Vispārējai izpratnei tiks sniegta arī savienojuma shēma.
EFK tūninga punkti
Attiecībā uz pirmo punktu es aprakstīšu tikai ideoloģiju, pēc kuras tiks veidoti indeksi. Ir daudz ideju.
Lieliski raksti par žurnālu iestatīšanu un saņemšanu no Mikrotik ierīcēm.
Ļaujiet man pakavēties pie dažiem punktiem:
1. Saskaņā ar diagrammu ir vērts apsvērt žurnālu saņemšanu no dažādām vietām un dažādos portos. Šim nolūkam mēs izmantosim žurnālu apkopotāju. Mēs arī vēlamies izveidot universālus grafikus visiem maršrutētājiem ar iespēju atdalīt piekļuvi. Pēc tam mēs veidosim indeksus šādi:
Šeit ir fluentd konfigurācijas fragments. tips elastīgā meklēšana
logstash_format patiess
indeksa_nosaukums mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10 s
saimniekiem : 9200
port 9200
Tādā veidā mēs varam apvienot maršrutētājus un segmentēt tos atbilstoši plānam: mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Kāpēc tik ļoti visu sarežģīt? Mēs saprotam, ka mums būs 200 vai vairāk ierīču. Nav iespējams visu izsekot. Ar ElasticSearch 6.8 versiju mums ir piekļuve drošības iestatījumiem (neiegādājoties licenci), kas ļauj mums izplatīt skatīšanās tiesības starp tehniskā atbalsta personālu vai vietējiem sistēmas administratoriem.
Tabulas, grafiki – šeit tikai jāvienojas – vai nu izmanto vienus un tos pašus, vai arī katrs dara tā, kā viņam ir ērtāk.
2. Attiecībā uz reģistrēšanu. Ja ugunsmūra noteikumos iespējojam reģistrēšanu, nosaukumus veidojam bez atstarpēm. Var redzēt, ka, izmantojot vienkāršu konfigurāciju programmā fluentd, mēs varam filtrēt datus un izveidot ērtus informācijas paneļus. Zemāk redzamajā attēlā ir redzams mans mājas maršrutētājs.
3. Pēc vietas un žurnāliem. Vidēji ar 1000 ziņojumiem stundā žurnāli aizņem 2–3 MB dienā, kas, kā jau piekritīsiet, nav daudz. Elasticsearch 7.5. versija.
ANSIBLE.AWX
Par laimi mums ir gatavs modulis maršrutētājiem
Es pieminēju AWX, bet tālāk norādītās komandas attiecas tikai uz tīru Ansible. Domāju, ka tiem, kas ir strādājuši ar Ansible, nebūs problēmu izmantot AWX, izmantojot grafisko lietotāja saskarni.
Godīgi sakot, esmu iepriekš aplūkojis citus ceļvežus, kas izmanto SSH, un tiem visiem bija dažādas reakcijas laika problēmas un virkne citu problēmu. Atkal, līdz konfliktiem nenotika 🙂 Uztveriet šo informāciju kā eksperimentu, kas nepārsniedza 20 maršrutētāju iestatīšanu.
Mums jāizmanto sertifikāts vai konts. Tas ir atkarīgs no jums, bet es atbalstu sertifikātus. Pastāv smalka problēma ar atļaujām. Es piešķiru rakstīšanas atļaujas — pat konfigurācijas atiestatīšana nelīdzēs.
Sertifikāta ģenerēšanai, kopēšanai un importēšanai nevajadzētu rasties problēmām:
Īss komandu sarakstsJūsu datorā
ssh-keygen -t RSA, atbildiet uz jautājumiem, saglabājiet atslēgu.
Kopēt uz mikrotik:
lietotāja ssh-atslēgas importēt publisko atslēgu failu=id_mtx.pub lietotājs=ansible
Vispirms jums ir jāizveido konts un jāpiešķir tam tiesības.
Savienojuma pārbaude, izmantojot sertifikātu
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120
Mēs rakstām 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
Lūk, piemērs rīcības plānam: — nosaukums: pievienot_darba_vietnes
saimniekdatori: testmt
sērijas numurs: 1
savienojums: network_cli
attālais_lietotājs: mikrotik.west
apkopot_faktus: jā
uzdevumi:
— nosaukums: pievienot darba_vietnes
routeros_komanda:
komandas:
— /ip ugunsmūra adrešu saraksts pievienot adresi=gov.ru list=work_sites komentārs=Ticket665436_Ochen_nado
— /ip ugunsmūra adrešu saraksts pievienot adresi=habr.com saraksts=darba_vietnes komentārs=for_habr
Kā redzams no iepriekš redzamās konfigurācijas, savu stratēģiju grāmatu izveide nav sarežģīta. Pietiek ar labu Mikrotik cli pārzināšanu. Iedomāsimies situāciju, kurā mums ir jānoņem adrešu saraksts ar noteiktiem datiem no visiem maršrutētājiem. Pēc tam:
Atrast un dzēst/ip ugunsmūra adrešu saraksta noņemšana [atrast, kur saraksts="gov.ru"]
Es apzināti neiekļāvu šeit visu ugunsmūra sarakstu, jo tas būs specifisks katram projektam. Taču viena lieta ir skaidra: izmantojiet tikai adrešu sarakstu.
Ar GITLAB viss ir skaidrs. Es pie šī jautājuma nekavēšos. Viss ir skaisti sakārtots atsevišķos uzdevumos, veidnēs un apstrādātājos.
PowerShell
Šeit būs trīs faili. Kāpēc PowerShell? Konfigurāciju ģenerēšanai varat izvēlēties jebkuru rīku, kas jums ir ērtākais. Šajā gadījumā visi savā datorā izmanto Windows, tāpēc kāpēc izmantot Bash, ja PowerShell ir ērtāks? Tas ir izvēles jautājums.
Pats skripts (vienkāršs un skaidrs):[cmdletBinding()] Parametrs(
[Parametrs(Obligāti=$true)] [virkne]$ĀRĒJĀ_ADRESE,
[Parametrs(Obligāti=$true)] [virkne]$EXTERNALIPROUTE,
[Parametrs(Obligāti=$true)] [virkne]$BWorknets,
[Parametrs(Obligāti=$true)] [virkne]$CWorknets,
[Parametrs(Obligāti=$true)] [virkne]$BVoipNets,
[Parametrs(Obligāti=$true)] [virkne]$CVoipNets,
[Parametrs(Obligāti=$true)] [virkne]$CClientss,
[Parametrs(Obligāti=$true)] [virkne]$BVPNWORKs,
[Parametrs(Obligāti=$true)] [virkne]$CVPNWORKs,
[Parametrs(Obligāti=$true)] [virkne]$BVPNCLIENTS,
[Parametrs(Obligāti=$true)] [virkne]$cVPNCLIENTS,
[Parametrs(Obligāti=$true)] [virkne]$NOSAUKUMS_MARUZINĀTĀJS,
[Parametrs(Obligāti=$true)] [virkne]$ServerCertificates,
[Parametrs(Obligāti=$true)] [virkne]$infile,
[Parametrs(Obligāti=$true)] [virkne]$izejasfails
)
Get-Content $infile | Foreach-Object {$_.Replace("EXTERNIP", $EXTERNALIPADRESS)} |
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("CVNPCLIENTS", $cVPNCLIENTSs)} |
Foreach-Object {$_.Replace("MYNOSAUKUMA_MARUIZOTĀJS", $NOSAUKUMA_MARUIZOTĀJS)} |
Foreach-Object {$_.Replace("ServerCertificate", $ServerCertificates)} | Set-Content $outfile
Lūdzu, piedodiet, es nevaru izklāstīt visus noteikumus, jo tas nebūtu īpaši jauki. Jūs varat izveidot savus noteikumus, ievērojot labāko praksi.
Piemēram, šeit ir saišu saraksts, kurām es sekoju:Maršrutētāja_drošināšana
IP/ugunsmūris/filtrs
OSPF piemēri
Winbox
:Jaunināšana_maršrutētāja_OS
:IP/Fasttrack — ir svarīgi ņemt vērā, ka, iespējojot fasttrack, datplūsmas prioritāšu noteikšana un veidošanas noteikumi nedarbosies — tas ir noderīgi vājākām ierīcēm.
Mainīgo lielumu tradicionālie apzīmējumi:Kā piemērs tiek ņemti šādi tīkli:
192.168.0.0/24 darba tīkls
172.22.4.0/24 VoIP tīkls
10.0.0.0/24 tīkls klientiem bez piekļuves lokālajam tīklam
192.168.255.0/24 VPN tīkls lielām filiālēm
172.19.255.0/24 VPN tīkls mazajiem uzņēmumiem
Tīkla adrese sastāv no 4 decimālskaitļiem, attiecīgi ABCD, aizstāšana darbojas pēc tā paša principa, ja startēšanas laikā tā prasa B, tad tīklam 192.168.0.0/24 jāievada skaitlis 0, bet C = 0.
$EXTERNALIPADDRESS — pakalpojumu sniedzēja piešķirta adrese.
$EXTERNALIPROUTE — noklusējuma maršruts uz tīklu 0.0.0.0/0
$BWorknets — Darba tīkls, mūsu piemērā tas būs 168
$CWorknets — Darba tīkls, mūsu piemērā tas būs 0
$BVoipNets — mūsu piemērā VoIP tīkls ir 22
$CVoipNets — VoIP tīkls mūsu piemērā 4
$CClientss — Tīkls klientiem — tikai piekļuve internetam, mūsu gadījumā tā ir 0
$BVPNWORKs — VPN tīkls lielām filiālēm, mūsu piemērā 20
$CVPNWORKs — VPN tīkls lielām filiālēm, mūsu piemērā 255
$BVPNCLIENTS — VPN tīkls mazām filiālēm, kas nozīmē 19
$CVPNCLIENTS — VPN tīkls mazām filiālēm, kas nozīmē 255
$NAMEROUTER — maršrutētāja nosaukums
$ServerCertificate — vispirms importējamā sertifikāta nosaukums
$infile — Norādiet ceļu uz failu, no kura mēs lasīsim konfigurāciju, piemēram, D:config.txt (vēlams angļu valodas ceļš bez pēdiņām un atstarpēm)
$outfile — norādiet ceļu, kur saglabāt, piemēram, D:MT-test.txt
Acīmredzamu iemeslu dēļ esmu apzināti mainījis adreses piemēros.
Es palaidu garām domu par uzbrukumu un anomālas uzvedības noteikšanu — tam vajadzētu atsevišķu rakstu. Tomēr ir vērts atzīmēt, ka šī kategorija var izmantot uzraudzības datus no Zabbix un apstrādātus curl datus no elasticsearch.
Uz kādiem punktiem jums vajadzētu koncentrēties:
- Tīkla plāns. Vislabāk to izveidot uzreiz lasāmā formātā. Pietiek ar Excel. Diemžēl es bieži redzu tīklus, kas izveidoti, pamatojoties uz principu "Atvērta jauna filiāle, šeit ir /24". Neviens neaprēķina, cik ierīču paredzēts noteiktā vietā un vai nākotnē ir gaidāma izaugsme. Piemēram, ja tiek atvērts neliels veikals, jau no paša sākuma ir skaidrs, ka tajā būs ne vairāk kā 10 ierīces. Kāpēc piešķirt /24? Lielākām filiālēm ir pretēji: tās piešķir /24, bet beigās ir 500 ierīces. Jūs varētu vienkārši pievienot tīklu, bet jums ir jāpārdomā viss jau no paša sākuma.
- Filtrēšanas noteikumi. Ja projekts ietver tīkla atdalīšanu un maksimālu segmentāciju, labākā prakse laika gaitā mainās. Iepriekš datoru tīkli un printeru tīkli bija atdalīti, bet tagad ir pilnīgi pieņemami šos tīklus turēt atsevišķi. Ir svarīgi izmantot veselo saprātu un izvairīties no vairāku apakštīklu izveides tur, kur tie nav nepieciešami, un izvairīties no visu ierīču apvienošanas vienā tīklā.
- "Zelta" iestatījumi visos maršrutētājos. Tas ir, ja esat izlēmis par plānu. Ir vērts plānot iepriekš un mēģināt nodrošināt, lai visi iestatījumi būtu identiski — atšķiras tikai adrešu saraksti un IP adreses. Ja rodas problēmas, problēmu novēršana būs ātrāka.
- Organizatoriskie aspekti ir ne mazāk svarīgi kā tehniskie. Slinki darbinieki bieži ievieš šos ieteikumus manuāli, neizmantojot gatavas konfigurācijas un skriptus, kas galu galā noved pie problēmām no zila gaisa.
Runājot par dinamisko maršrutēšanu, tika izmantota OSPF ar zonālo sadalīšanu. Taču šī bija testa vide; šādu lietu konfigurēšana ražošanas vidē ir interesantāka.
Ceru, ka neviens neapvainosies, ka nepublicēju maršrutētāja konfigurācijas. Domāju, ka saites ir pietiekamas, un tad viss ir atkarīgs no prasībām. Un, protams, ir nepieciešama testēšana — nepieciešama papildu testēšana.
Vēlu visiem panākumus savu projektu realizēšanā jaunajā gadā. Lai jums tiek piešķirta piekļuve!!!
Avots: www.habr.com
