Sveiki visi. Šis straipsnis skirtas tiems, kurie parke turi daug Mikrotik įrenginių ir nori maksimaliai suvienodinti, kad neprisijungtų prie kiekvieno įrenginio atskirai. Šiame straipsnyje aprašysiu projektą, kuris, deja, dėl žmogiškųjų faktorių nepasiekė kovinių sąlygų. Trumpai: daugiau nei 200 maršrutizatorių, greita sąranka ir personalo apmokymas, suvienodinimas pagal regioną, tinklų ir konkrečių prieglobų filtravimas, galimybė lengvai pridėti taisykles prie visų įrenginių, registravimas ir prieigos kontrolė.
Tai, kas aprašyta žemiau, nepretenduoja į paruoštą atvejį, tačiau tikiuosi, kad tai bus naudinga planuojant tinklus ir sumažinant klaidas. Galbūt kai kurie punktai ir sprendimai jums atrodys ne visai teisingi – jei taip, parašykite komentaruose. Kritika šiuo atveju bus patirtis bendrame taupyklėje. Todėl, skaitytojau, pažiūrėk komentaruose, galbūt autorius padarė grubiai klaidą – bendruomenė padės.
Maršrutizatorių skaičius yra 200-300, išsibarsčiusių skirtinguose miestuose su skirtinga interneto ryšio kokybe. Reikia viską gražinti ir vietiniams adminams prieinamai paaiškinti kaip viskas veiks.
Taigi nuo ko prasideda kiekvienas projektas? Žinoma, su TK.
- Visų filialų tinklo plano organizavimas pagal klientų reikalavimus, tinklo segmentavimas (nuo 3 iki 20 tinklų filialuose, priklausomai nuo įrenginių skaičiaus).
- Kiekviename filiale nustatykite įrenginius. Tikrinamas tikrasis teikėjo pralaidumas skirtingomis darbo sąlygomis.
- Įrenginių apsaugos organizavimas, baltojo sąrašo kontrolė, automatinis atakų aptikimas su automatiniu juoduoju sąrašu tam tikram laikotarpiui, įvairių techninių priemonių, naudojamų prieigos kontrolės perėmimui ir paslaugų atsisakymui, naudojimo sumažinimas.
- Saugių vpn jungčių su tinklo filtravimu organizavimas pagal kliento reikalavimus. Mažiausiai 3 vpn jungtys iš kiekvienos šakos į centrą.
- Remdamiesi 1, 2 punktais. Pasirinkite geriausius gedimams atsparaus VPN kūrimo būdus. Dinaminę maršruto parinkimo technologiją, tinkamai pagrįstą, gali pasirinkti rangovas.
- Srauto prioritetų nustatymo organizavimas pagal protokolus, prievadus, pagrindinius kompiuterius ir kitas specifines paslaugas, kuriomis naudojasi klientas. (VOIP, šeimininkai su svarbiomis paslaugomis)
- Maršrutizatoriaus įvykių stebėjimo ir registravimo organizavimas techninės pagalbos personalui reaguoti.
Kaip suprantame, kai kuriais atvejais TOR sudaromas pagal reikalavimus. Šiuos reikalavimus suformulavau savarankiškai, išklausęs pagrindines problemas. Jis pripažino galimybę, kad kas nors kitas galėtų imtis šių punktų įgyvendinimo.
Kokios priemonės bus naudojamos šiems reikalavimams įvykdyti:
- ELK stack (po kiek laiko suprato, kad vietoj logstash bus naudojamas fluentd).
- Ansible. Kad būtų lengviau administruoti ir dalytis prieiga, naudosime AWX.
- GITLAB. Čia nereikia aiškinti. Kur be mūsų konfigūracijų versijos valdymo.
- PowerShell. Pradiniam konfigūracijos generavimui bus paprastas scenarijus.
- Doku wiki, skirta dokumentacijai ir vadovams rašyti. Šiuo atveju naudojame habr.com.
- Stebėjimas bus atliekamas per zabbix. Taip pat bus jungties schema bendram supratimui.
EFK nustatymo taškai
Pirmajame punkte aprašysiu tik ideologiją, kuria remiantis bus kuriami indeksai. Yra daug
puikūs straipsniai apie žurnalų nustatymą ir gavimą iš įrenginių, kuriuose veikia mikrotik.
Apsistosiu ties kai kuriais punktais:
1. Pagal schemą verta apsvarstyti rąstų priėmimą iš skirtingų vietų ir skirtinguose uostuose. Norėdami tai padaryti, naudosime žurnalų agregatorių. Taip pat norime sukurti universalią grafiką visiems maršrutizatoriams su galimybe dalytis prieiga. Tada mes sudarome indeksus taip:
čia yra dalis konfigūracijos su fluentd elastinga paieška
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
šeimininkai : 9200
uostas 9200
Taigi galime derinti maršrutizatorius ir segmentuoti pagal planą - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Kodėl taip sunku? Suprantame, kad turėsime 200 ir daugiau įrenginių. Nesek visko. Nuo elasticsearch versijos 6.8 saugos nustatymai mums prieinami (neperkant licencijos), todėl peržiūros teises galime paskirstyti tarp techninės pagalbos darbuotojų ar vietinių sistemų administratorių.
Lentelės, grafikai – čia tik reikia susitarti – arba naudok tuos pačius, arba kiekvienas daro taip, kaip jam bus patogu.
2. Miško kirtimu. Jei įjungsime prisijungimo užkardos taisykles, tada pavadinimus padarysime be tarpų. Matyti, kad naudojant paprastą konfigūraciją fluentd, galime filtruoti duomenis ir padaryti patogias paneles. Žemiau esančioje nuotraukoje yra mano namų maršrutizatorius.
3. Pagal užimamą plotą ir rąstus. Vidutiniškai esant 1000 pranešimų per valandą, žurnalai per dieną užima 2-3 MB, o tai, matote, nėra tiek daug. elasticearch versija 7.5.
ANSIBLE.AWX
Mūsų laimei, turime paruoštą maršrutizatorių modulį
Nurodžiau apie AWX, bet žemiau pateiktos komandos yra tik apie ansible gryniausia forma – manau, tiems, kurie dirbo su ansible, nebus jokių problemų naudojant awx per gui.
Tiesą sakant, prieš tai pažvelgiau į kitus vadovus, kuriuose jie naudojo ssh, ir visi turėjo skirtingų problemų su atsako laiku ir daugybe kitų problemų. Pasikartosiu, jis nepateko į mūšį , priimkite šią informaciją kaip eksperimentą, kuris neperžengė 20 maršrutizatorių stendo.
Turime naudoti sertifikatą arba paskyrą. Spręskite patys, aš už sertifikatus. Kai kurie subtilūs klausimai apie teises. Suteikiu teises rašyti - bent jau „reset config“ neveiks.
Sugeneruojant, kopijuojant sertifikatą ir importuojant neturėtų kilti problemų:
Trumpas komandų sąrašasJūsų kompiuteryje
ssh-keygen -t RSA, atsakykite į klausimus, išsaugokite raktą.
Kopijuoti į mikrotiką:
vartotojo ssh-keys importuoti public-key-file=id_mtx.pub user=ansible
Pirmiausia turite susikurti paskyrą ir suteikti jai teises.
Tikrinamas ryšys su sertifikatu
ssh -p 49475 -i /keys/mtx [apsaugotas el. paštu]
Rašykite 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
Na, žaidimo knygos pavyzdys: pavadinimas: add_work_sites
šeimininkai: testmt
serija: 1
ryšys:network_cli
remote_user: mikrotik.west
surinkti_faktus: taip
užduotys:
pavadinimas: pridėti Work_sites
routeros_command:
komandos:
- /ip ugniasienės adresų sąrašas add address=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
- /ip ugniasienės adresų sąrašas add address=habr.com list=work_sites comment=for_habr
Kaip matote iš aukščiau pateiktos konfigūracijos, savo žaidimų knygelių sudarymas yra paprastas dalykas. Tai pakankamai gerai įvaldyti cli mikrotik. Įsivaizduokite situaciją, kai reikia pašalinti visų maršrutizatorių adresų sąrašą su tam tikrais duomenimis, tada:
Raskite ir pašalinkite/ip ugniasienės adresų sąrašas pašalinti [rasti kur list="gov.ru"]
Sąmoningai neįtraukiau čia viso ugniasienės sąrašo. jis bus individualus kiekvienam projektui. Tačiau viena galiu pasakyti tikrai – naudokite tik adresų sąrašą.
GITLAB teigimu, viskas aišku. Šia akimirka nesigilinsiu. Viskas gražu atskirų užduočių, šablonų, tvarkyklių atžvilgiu.
PowerShell
Bus 3 failai. Kodėl powershell? Konfigūracijų generavimo įrankį gali pasirinkti bet kas, kam patogiau. Šiuo atveju kiekvienas turi Windows savo kompiuteryje, tad kam tai daryti su bash, kai powershell yra patogesnis. Kam patogiau.
Pats scenarijus (paprastas ir suprantamas):[cmdletBinding()] Param(
[Parametras (privalomas = $true)] [eilutė]$EXTERNALIPADDRESS,
[Parametras (privalomas = $true)] [eilutė]$EXTERNALIPROUTE,
[Parametras (privalomas = $true)] [eilutė]$BWorknets,
[Parametras (privalomas = $true)] [eilutė]$CWorknets,
[Parametras (Privalomas = $true)] [eilutė]$BVoipNets,
[Parametras(privalomas=$true)] [eilutė]$CVoipNets,
[Parametras (privalomas = $true)] [eilutė]$CClients,
[Parametras (privalomas = $true)] [eilutė]$BVPNWORKs,
[Parametras (privalomas = $true)] [eilutė]$CVPNWORKs,
[Parametras (privalomas = $true)] [eilutė]$BVPNCLIENTS,
[Parametras (Privalomas = $true)] [eilutė]$cVPNCLIENTS,
[Parametras (privalomas = $true)] [eilutė]$NAMEROUTER,
[Parameter(Privaloma=$true)] [eilutė]$ServerCertificates,
[Parametras(privalomas=$true)] [eilutė]$infile,
[Parametras(privalomas=$true)] [eilutė]$outfile
)
Gauti turinį $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", $CClients)} |
Foreach-Object {$_.Replace("BVPNWORK", $BVPNWORKs)} |
Foreach-Object {$_.Replace("CVPNWORK", $CVPNWORKs)} |
„Foreach-Object“ {$_.Replace("BVPNCLIENTS", $BVPNCLIENTS)} |
„Foreach-Object“ {$_.Replace("CVPNCLIENTS", $cVPNCLIENTS)} |
Foreach-Object {$_.Replace("MYNAMERROUTER", $NAMEROUTER)} |
Foreach-Object {$_.Replace("ServerCertificate", $ServerCertificates)} | Set-Content $outfile
Atsiprašau, negaliu išdėstyti visų taisyklių. tai nebus gražu. Taisykles galite sudaryti patys, vadovaudamiesi geriausia praktika.
Pavyzdžiui, čia yra nuorodų, kuriomis vadovaujuosi, sąrašas::Tavo_maršrutizatoriaus apsauga
:IP/Ugniasienė/Filtras
:OSPF pavyzdžiai
: Winbox
:Upgrading_RouterOS
:IP/Fasttrack – čia reikia žinoti, kad įjungus „fasttrack“ neveiks eismo prioritetų nustatymo ir formavimo taisyklės – naudinga silpniems įrenginiams.
Kintamos sutartys:Kaip pavyzdžiai paimami šie tinklai:
192.168.0.0/24 veikiantis tinklas
172.22.4.0/24 VOIP tinklas
10.0.0.0/24 tinklas klientams, neturintiems LAN prieigos
192.168.255.0/24 VPN tinklas dideliems filialams
172.19.255.0/24 VPN tinklas mažiems
Tinklo adresą sudaro 4 dešimtainiai skaičiai, atitinkamai ABCD, pakeitimas veikia pagal tą patį principą, jei paleidžiant klausia B, tada reikia įvesti skaičių 192.168.0.0 tinklui 24/0, o C = 0 .
$EXTERNALIPADDRESS – teikėjo suteiktas adresas.
$EXTERNALIPROUTE – numatytasis maršrutas į tinklą 0.0.0.0/0
$BWorknets – veikiantis tinklas, mūsų pavyzdyje bus 168
$CWorknets – darbo tinklas, mūsų pavyzdyje jis bus 0
$BVoipNets – VOIP tinklas mūsų pavyzdyje čia 22
$CVoipNets – VOIP tinklas mūsų pavyzdyje čia 4
$CClientss – Tinklas klientams – prieiga tik prie interneto, mūsų atveju čia 0
$BVPNWORKs – VPN tinklas dideliems filialams, mūsų 20 pavyzdyje
$CVPNWORKs – VPN tinklas dideliems filialams, mūsų pavyzdyje 255
$BVPNCLIENTS - VPN tinklas mažiems filialams, reiškia 19
$CVPNCLIENTS - VPN tinklas mažiems filialams, reiškia 255
$NAMEROUTER – maršrutizatoriaus pavadinimas
$ServerCertificate – sertifikato, kurį pirmiausia importuojate, pavadinimas
$infile – nurodykite kelią į failą, iš kurio skaitysime konfigūraciją, pavyzdžiui, D:config.txt (geresnis kelias anglų kalba be kabučių ir tarpų)
$outfile – nurodykite kelią, kur išsaugoti, pavyzdžiui, D:MT-test.txt
Pavyzdžiuose esančius adresus tyčia pakeičiau dėl akivaizdžių priežasčių.
Aš praleidau mintį apie atakų ir anomalaus elgesio aptikimą – tai nusipelno atskiro straipsnio. Tačiau verta paminėti, kad šioje kategorijoje galite naudoti stebėjimo duomenų reikšmes iš Zabbix + parengtus garbanų duomenis iš elasticsearch.
Į kokius dalykus reikia atkreipti dėmesį:
- Tinklo planas. Geriau rašyti skaitoma forma. Užtenka Excel. Deja, dažnai matau, kad tinklai kompiliuojami pagal principą „Atsirado nauja šaka, štai tau /24“. Niekas nežino, kiek įrenginių tikimasi tam tikroje vietoje ir ar bus tolesnis augimas. Pavyzdžiui, atidaryta nedidelė parduotuvė, kurioje iš pradžių aišku, kad įrenginio bus ne daugiau kaip 10, kam skirti / 24? Priešingai, dideliems filialams jie skiria / 24, o įrenginių yra 500 - galite tiesiog pridėti tinklą, bet norite iš karto viską apgalvoti.
- Filtravimo taisyklės. Jei projekte numatoma, kad bus atskirti tinklai ir maksimalus segmentavimas. Laikui bėgant geriausia praktika keičiasi. Anksčiau jie bendrai naudojosi kompiuterių ir spausdintuvų tinklu, o dabar visai įprasta šiais tinklais nesidalyti. Verta vadovautis sveiku protu ir negaminti daug potinklių ten, kur jų nereikia ir nejungti visų įrenginių į vieną tinklą.
- „Auksiniai“ nustatymai visuose maršrutizatoriuose. Tie. jei turi planą. Verta viską numatyti iš karto ir pasistengti, kad visi nustatymai būtų identiški – skiriasi tik adresų sąrašas ir IP adresai. Iškilus problemoms derinimo laikas bus trumpesnis.
- Organizaciniai aspektai yra ne mažiau svarbūs nei techniniai. Dažnai tingūs darbuotojai vykdo šias rekomendacijas „rankiniu būdu“, nenaudodami paruoštų konfigūracijų ir scenarijų, o tai galiausiai sukelia problemų nuo nulio.
Dinaminiu maršruto parinkimu. Buvo naudojamas OSPF su zonavimu. Bet tai yra bandymų stendas, kovos sąlygomis tokius dalykus įdomiau statyti.
Tikiuosi, niekas nenusiminė, kad nepaskelbiau maršrutizatorių konfigūracijos. Manau, kad nuorodų užteks, o tada jau viskas priklauso nuo reikalavimų. Ir, žinoma, bandymai, reikia daugiau testų.
Linkiu visiems naujais metais įgyvendinti savo projektus. Tegul prieiga yra su jumis!!!
Šaltinis: www.habr.com