Hæ allir. Þessi grein er ætluð þeim sem eru með mörg Mikrotik tæki í flotanum og vilja gera hámarks sameiningu til að tengjast ekki hverju tæki fyrir sig. Í þessari grein mun ég lýsa verkefni sem, því miður, náði ekki bardagaskilyrðum vegna mannlegra þátta. Í stuttu máli: meira en 200 beinar, fljótleg uppsetning og þjálfun starfsfólks, sameining eftir svæðum, síun netkerfis og tiltekinna gestgjafa, getu til að bæta reglum auðveldlega við öll tæki, skráningu og aðgangsstýringu.
Það sem lýst er hér að neðan þykist ekki vera tilbúið mál, en ég vona að það muni nýtast þér þegar þú skipuleggur netkerfin þín og lágmarkar villur. Kannski virðast sumir punktar og lausnir ekki alveg rétt hjá þér - ef svo er, skrifaðu í athugasemdirnar. Gagnrýni í þessu máli verður upplifun fyrir hinn sameiginlega ríkissjóð. Þess vegna, lesandi, skoðaðu athugasemdirnar, kannski gerði höfundurinn alvarleg mistök - samfélagið mun hjálpa.
Fjöldi beina er 200-300, dreifðir um mismunandi borgir með mismunandi gæði nettenginga. Það er nauðsynlegt að gera allt fallega og skýrt útskýra fyrir staðbundnum stjórnendum hvernig allt mun virka.
Svo, hvar byrjar eitthvað verkefni? Auðvitað með ТЗ.
- Skipulag netkerfis fyrir öll útibú í samræmi við kröfur viðskiptavina, netskiptingu (frá 3 til 20 netkerfi í útibúum eftir fjölda tækja).
- Uppsetning tækja í hverri grein. Athugaðu raunverulegan gegnumstreymishraða þjónustuveitunnar við mismunandi rekstrarskilyrði.
- Skipulag tækjaverndar, stjórnun hvítlista, sjálfvirk uppgötvun árása með sjálfvirkri svartan lista í ákveðinn tíma, lágmarkar notkun ýmissa tæknilegra aðferða sem notaðar eru til að stöðva aðgangsstýringu og neita þjónustu.
- Skipulag öruggra VPN-tenginga með netsíu í samræmi við kröfur viðskiptavina. Lágmark 3 VPN tengingar frá hverju útibúi til miðstöðvarinnar.
- Byggt á liðum 1, 2. Veldu bestu leiðirnar til að búa til villuþolin VPN. Ef rétt er rökstutt getur verktaki valið kraftmikla leiðartækni.
- Skipulag forgangsröðunar umferðar eftir samskiptareglum, höfnum, gestgjöfum og annarri sértækri þjónustu sem viðskiptavinurinn notar. (VOIP, gestgjafar með mikilvæga þjónustu)
- Skipulag eftirlits og skráningar á beiniviðburðum til að bregðast við tækniaðstoðarfólki.
Eins og við skiljum eru tækniforskriftirnar í mörgum tilfellum samdar út frá kröfunum. Ég mótaði þessar kröfur sjálfur, eftir að hafa hlustað á helstu vandamálin. Hann viðurkenndi möguleikann á því að einhver annar gæti séð um þessi atriði.
Hvaða verkfæri verða notuð til að uppfylla þessar kröfur:
- ELK stafla (eftir nokkurn tíma varð ljóst að fluentd yrði notað í stað logstash).
- Ansible. Til að auðvelda umsýslu og deila aðgangi munum við nota AWX.
- GITLAB. Hér þarf ekki að útskýra. Hvar værum við án útgáfustýringar á stillingum okkar?
- PowerShell. Það verður einfalt handrit fyrir fyrstu kynslóð stillingarinnar.
- Doku wiki, til að skrifa skjöl og leiðbeiningar. Í þessu tilfelli notum við habr.com.
- Eftirlit verður framkvæmt í gegnum zabbix. Þar verður einnig teiknað tengimynd til almenns skilnings.
EFK uppsetningarstaðir
Varðandi fyrsta atriðið mun ég aðeins lýsa þeirri hugmyndafræði sem vísitölurnar verða byggðar eftir. Það eru margir
frábærar greinar um uppsetningu og móttöku annála frá tækjum sem keyra mikrotik.
Ég ætla að staldra við nokkur atriði:
1. Samkvæmt skýringarmyndinni er þess virði að íhuga að taka á móti logum frá mismunandi stöðum og á mismunandi höfnum. Fyrir þetta munum við nota log aggregator. Við viljum líka búa til alhliða grafík fyrir alla beina með getu til að deila aðgangi. Síðan byggjum við vísitölurnar sem hér segir:
hér er hluti af stillingunni með fluentd gerð elasticsearch
logstash_format satt
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
skola_bil 10s
vélar : 9200
höfn 9200
Þannig getum við sameinað beina og skipt í samræmi við áætlunina - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Af hverju að gera þetta svona flókið? Okkur skilst að við verðum með 200 eða fleiri tæki. Þú getur ekki fylgst með öllu. Með útgáfu 6.8 af elasticsearch eru öryggisstillingar tiltækar fyrir okkur (án þess að kaupa leyfi), þannig getum við dreift skoðunarrétti milli starfsmanna tækniaðstoðar eða staðbundinna kerfisstjóra.
Töflur, línurit - hér þarf bara að vera sammála - annaðhvort notaðu þær sömu, eða allir gera það sem hentar honum.
2. Með því að skrá þig. Ef við virkum innskráningu í eldveggsreglunum, gerum við nöfnin án bils. Það má sjá að með því að nota einfalda stillingar í fluentd getum við síað gögn og búið til þægileg spjöld. Myndin hér að neðan er heimabeini minn.
3. Eftir pláss uppteknum og logs. Að meðaltali, með 1000 skilaboð á klukkustund, taka annálar 2-3 MB á dag, sem þú sérð, er ekki svo mikið. Elasticsearch útgáfa 7.5.
ANSIBLE.AWX
Sem betur fer fyrir okkur erum við með tilbúna einingu fyrir routeros
Ég minntist á AWX, en skipanirnar hér að neðan eru aðeins um ansible í sinni hreinu mynd - ég held að fyrir þá sem hafa unnið með ansible, þá verði engin vandamál að nota awx í gegnum gui.
Til að vera heiðarlegur, áður en þetta skoðaði ég aðra leiðbeiningar þar sem þeir notuðu ssh, og þeir höfðu allir mismunandi vandamál með viðbragðstíma og fullt af öðrum vandamálum. Ég endurtek, það kom ekki til átaka , taktu þessar upplýsingar sem tilraun sem náði ekki lengra en 20 beinar.
Við þurfum að nota vottorð eða reikning. Það er undir þér komið að ákveða, ég er fyrir skírteini. Einhver lúmskur punktur um réttindi. Ég veiti skrifrétt - að minnsta kosti "endurstilla stillingar" mun ekki virka.
Það ættu ekki að vera nein vandamál við að búa til, afrita og flytja inn vottorðið:
Stutt skipanaskráningÁ tölvunni þinni
ssh-keygen -t RSA, svaraðu spurningum, vistaðu lykilinn.
Afritaðu í mikrotik:
notandi ssh-lyklar import public-key-file=id_mtx.pub user=ansible
Fyrst þarftu að búa til reikning og úthluta honum réttindi.
Athugar tenginguna með því að nota vottorðið
ssh -p 49475 -i /keys/mtx [netvarið]
Skráðu þig á /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
Jæja, dæmi leikbók: - nafn: add_work_sites
gestgjafar: testmt
röð: 1
tenging: net_cli
fjarnotandi: mikrotik.west
safna_staðreyndum: já
verkefni:
- nafn: bættu við Work_sites
routeros_skipun:
skipanir:
— /ip eldvegg heimilisfang-listi bæta við heimilisfangi=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
— /ip eldvegg heimilisfang-listi bæta við addressu=habr.com list=work_sites comment=for_habr
Eins og þú sérð af uppsetningunni hér að ofan er ekki erfitt að búa til þínar eigin leikbækur. Það er nóg að ná góðum tökum á cli mikrotik. Við skulum ímynda okkur aðstæður þar sem þú þarft að fjarlægja heimilisfangalistann með ákveðnum gögnum á öllum beinum, þá:
Finndu og fjarlægðu/ip firewal vistfangalista fjarlægja [finndu hvar list="gov.ru"]
Ég setti viljandi ekki alla eldveggskráninguna með hér vegna þess að... það verður einstaklingsbundið fyrir hvert verkefni. En eitt get ég sagt fyrir víst, notaðu aðeins heimilisfangalistann.
Samkvæmt GITLAB er allt á hreinu. Ég ætla ekki að fjölyrða um þetta atriði. Allt er fallegt fyrir einstök verkefni, sniðmát, meðhöndlun.
PowerShell
Hér verða 3 skrár. Af hverju powershell? Þú getur valið hvaða tól sem er til að búa til stillingar, hvað sem er þægilegra fyrir þig. Í þessu tilfelli eru allir með Windows á tölvunni sinni, svo af hverju að gera það í bash þegar powershell er þægilegra. Hvort er þægilegra?
Handritið sjálft (einfalt og skiljanlegt):[cmdletBinding()] Param(
[Parameter(Mandatory=$true)] [strengur]$EXTERNALIPADDDRESS,
[Parameter(Ofboðið=$true)] [strengur]$EXTERNALIPROUTE,
[Parameter(Mandatory=$true)] [strengur]$BWorknets,
[Parameter(Mandatory=$true)] [strengur]$CWorknets,
[Parameter(Mandatory=$true)] [streng]$BVoipNets,
[Parameter(Mandatory=$true)] [strengur]$CVoipNets,
[Parameter(Mandatory=$true)] [strengur]$CClientss,
[Parameter(Mandatory=$true)] [strengur]$BVPNWORKs,
[Parameter(Mandatory=$true)] [strengur]$CVPNWORKs,
[Parameter(Mandatory=$true)] [strengur]$BVPNCLIENTSs,
[Parameter(Mandatory=$true)] [strengur]$cVPNCLIENTSs,
[Parameter(Mandatory=$true)] [strengur]$NAMEROUTER,
[Parameter(Mandatory=$true)] [strengur]$ServerCertificates,
[Parameter(Ofboðið=$true)] [strengur]$innskrá,
[Parameter(Ofboðið=$true)] [strengur]$útskrá
)
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", $cVNCLIENTSs)} |
Foreach-Object {$_.Replace("MYNAMEROUTER", $NAMEROUTER)} |
Foreach-Object {$_.Replace("ServerCertificate", $ServerCertificates)} | Set-Content $outfile
Vinsamlegast fyrirgefðu mér, ég get ekki birt allar reglurnar vegna þess að... það verður ekki mjög fallegt. Þú getur búið til reglurnar sjálfur, með bestu starfsvenjur að leiðarljósi.
Til dæmis, hér er listi yfir tengla sem ég fylgdi::Securing_Your_Router
:IP/eldveggur/sía
:OSPF-dæmi
: Winbox
:Uppfærsla_RouterOS
:IP/Fasttrack - hér þarftu að vita að þegar hraðbraut er virkt virka umferðarforgangsröðun og mótunarreglur ekki - gagnlegt fyrir veik tæki.
Tákn fyrir breytur:Eftirfarandi net eru tekin sem dæmi:
192.168.0.0/24 vinnunet
172.22.4.0/24 VOIP net
10.0.0.0/24 net fyrir viðskiptavini án aðgangs að staðarnetinu
192.168.255.0/24 VPN net fyrir stór útibú
172.19.255.0/24 VPN net fyrir lítil
Netfangið samanstendur af 4 aukastöfum, hvort um sig ABCD, skiptin virkar á sömu reglu, ef við ræsingu það biður um B, þá þýðir það að þú þarft að slá inn töluna 192.168.0.0 fyrir netið 24/0, og fyrir C = 0.
$EXTERNALIPADDDRESS - sérstakt heimilisfang frá þjónustuveitunni.
$EXTERNALIPROUTE - sjálfgefna leið til netkerfis 0.0.0.0/0
$BWorknets - Vinnukerfi, í dæminu okkar verða 168
$CWorknets - Vinnandi net, í okkar dæmi mun þetta vera 0
$BVoipNets - VOIP net í dæminu okkar hér 22
$CVoipNets - VOIP net í dæminu okkar hér 4
$CClientss - Net fyrir viðskiptavini - aðeins internetaðgangur, í okkar tilviki hér 0
$BVPNWORKs - VPN net fyrir stór útibú, í dæmi okkar 20
$CVPNWORKs - VPN net fyrir stór útibú, í okkar dæmi 255
$BVPNCLIENTS - VPN net fyrir lítil útibú, sem þýðir 19
$CVPNCLIENTS - VPN net fyrir lítil útibú, sem þýðir 255
$NAMEROUTER - heiti beins
$ServerCertificate - heiti vottorðsins sem þú fluttir áður inn
$infile — Tilgreindu slóðina að skránni sem við munum lesa stillingarnar úr, til dæmis D:config.txt (helst enska slóðin án gæsalappa og bils)
$outfile — tilgreindu slóðina þar sem á að vista það, til dæmis D:MT-test.txt
Ég hef vísvitandi breytt heimilisföngum í dæmunum af augljósum ástæðum.
Ég missti af punktinum um að greina árásir og afbrigðilega hegðun - þetta á skilið sérstaka grein. En það er þess virði að benda á að í þessum flokki geturðu notað vöktunargagnagildi frá Zabbix + unnum krullugögnum frá elasticsearch.
Hvaða atriði ættir þú að borga eftirtekt til:
- Netáætlun. Það er betra að semja það strax í læsilegu formi. Excel dugar. Því miður sé ég mjög oft að netkerfi eru byggð samkvæmt meginreglunni „Nýtt útibú hefur birst, hér er /24 fyrir þig.“ Enginn er að átta sig á því hversu mörg tæki eru væntanleg á tilteknum stað eða hvort það verði frekari vöxtur. Til dæmis opnaði lítil verslun þar sem upphaflega var ljóst að tækið yrði ekki meira en 10, til hvers að úthluta /24? Fyrir stór útibú, þvert á móti, úthluta þeir /24, og það eru 500 tæki - þú getur einfaldlega bætt við neti, en þú vilt hugsa í gegnum allt í einu.
- Síunarreglur. Ef verkefnið gerir ráð fyrir að aðskilnaður verði netkerfa og hámarkshlutun. Bestu starfsvenjur breytast með tímanum. Áður var tölvuneti og prentaraneti skipt upp en nú er alveg eðlilegt að skipta þessum netum ekki upp. Það er þess virði að nota skynsemi og búa ekki til mörg undirnet þar sem þeirra er ekki þörf og ekki sameina öll tæki í eitt net.
- „Gullnar“ stillingar á öllum beinum. Þeir. ef þú hefur ákveðið áætlun. Það er þess virði að sjá allt fyrir strax og reyna að ganga úr skugga um að allar stillingar séu eins - aðeins vistfangalisti og IP tölur eru mismunandi. Ef vandamál koma upp mun villuleitartími vera styttri.
- Skipulagsmál eru ekki síður mikilvæg en tæknileg. Oft framkvæma latir starfsmenn þessar ráðleggingar „handvirkt“ án þess að nota tilbúnar stillingar og forskriftir, sem að lokum leiðir til vandamála upp úr engu.
Með kraftmikilli leið. Notast var við OSPF með svæðisskiptingu. En þetta er prófunarbekkur; það er áhugaverðara að setja upp slíka hluti í bardagaaðstæðum.
Ég vona að enginn sé í uppnámi yfir því að ég hafi ekki sent inn stillingar á routernum. Ég held að hlekkirnir dugi og þá fer allt eftir kröfunum. Og auðvitað próf, það þarf fleiri próf.
Ég óska öllum að átta sig á verkefnum sínum á nýju ári. Megi veittur aðgangur vera með þér!!!
Heimild: www.habr.com