Իմ անավարտ նախագիծը. 200 MikroTik երթուղիչների ցանց

Իմ անավարտ նախագիծը. 200 MikroTik երթուղիչների ցանց

Բարեւ բոլորին. Այս հոդվածը նախատեսված է նրանց համար, ովքեր այգում ունեն բազմաթիվ Mikrotik սարքեր, և ովքեր ցանկանում են առավելագույն միավորում կատարել, որպեսզի չմիանան յուրաքանչյուր սարքին առանձին։ Այս հոդվածում ես նկարագրելու եմ մի նախագիծ, որը, ցավոք, մարդկային գործոնների պատճառով չի հասել մարտական ​​պայմանների։ Մի խոսքով, ավելի քան 200 երթուղիչներ, արագ տեղադրում և անձնակազմի ուսուցում, միավորում ըստ տարածաշրջանների, ցանցերի և հատուկ հոսթների զտման, բոլոր սարքերում կանոններ հեշտությամբ ավելացնելու, գրանցման և մուտքի վերահսկման հնարավորություն:

Ստորև նկարագրվածը չի հավակնում որպես պատրաստի դեպք, բայց հուսով եմ, որ դա ձեզ օգտակար կլինի ձեր ցանցերը պլանավորելիս և նվազագույնի հասցնել սխալները: Միգուցե որոշ կետեր և որոշումներ ձեզ այնքան էլ ճիշտ չթվա, եթե այո, ապա գրեք մեկնաբանություններում: Քննադատությունն այս դեպքում կլինի փորձ ընդհանուր խոզուկ բանկում։ Հետևաբար, ընթերցող, նայեք մեկնաբանություններում, գուցե հեղինակը կոպիտ սխալ է թույլ տվել. համայնքը կօգնի:

Երթուղիչների թիվը 200-300 է, ցրված տարբեր քաղաքներում տարբեր որակի ինտերնետ կապով։ Պետք է ամեն ինչ գեղեցիկ դարձնել և տեղական ադմիններին մատչելի կերպով բացատրել, թե ինչպես է ամեն ինչ աշխատելու։

Այսպիսով, որտեղից է սկսվում յուրաքանչյուր նախագիծ: Իհարկե, հետ TK.

  1. Բոլոր մասնաճյուղերի համար ցանցային պլանի կազմակերպում` ըստ հաճախորդի պահանջների, ցանցի սեգմենտավորում (մասնաճյուղերում 3-ից մինչև 20 ցանց` կախված սարքերի քանակից):
  2. Տեղադրեք սարքեր յուրաքանչյուր մասնաճյուղում: Տարբեր աշխատանքային պայմաններում մատակարարի իրական թողունակության ստուգում:
  3. Սարքի պաշտպանության կազմակերպում, սպիտակ ցուցակի վերահսկում, հարձակումների ավտոմատ հայտնաբերում որոշակի ժամանակահատվածում ավտոմատ սև ցուցակում, նվազագույնի հասցնել տարբեր տեխնիկական միջոցների օգտագործումը, որոնք օգտագործվում են հսկիչ մուտքի և ծառայության մերժման համար:
  4. Անվտանգ vpn կապերի կազմակերպում ցանցային զտիչով` ըստ հաճախորդի պահանջների: Առնվազն 3 vpn միացում յուրաքանչյուր ճյուղից դեպի կենտրոն:
  5. Հիմնվելով 1-ին, 2-րդ կետերի վրա: Ընտրեք սխալներին հանդուրժող VPN ստեղծելու լավագույն ուղիները: Դինամիկ երթուղային տեխնոլոգիան, ճիշտ հիմնավորմամբ, կարող է ընտրվել կապալառուի կողմից:
  6. Երթևեկության առաջնահերթությունների կազմակերպում ըստ արձանագրությունների, նավահանգիստների, հոսթների և այլ հատուկ ծառայությունների, որոնք օգտագործում է հաճախորդը: (VOIP, կարևոր ծառայություններով հյուրընկալողներ)
  7. Տեխնիկական աջակցության անձնակազմի արձագանքման համար երթուղիչի իրադարձությունների մոնիտորինգի և գրանցման կազմակերպում:

Ինչպես հասկանում ենք, որոշ դեպքերում TOR-ը կազմվում է պահանջներից: Այս պահանջները ես ինքնուրույն ձևակերպեցի՝ հիմնական խնդիրները լսելուց հետո։ Նա խոստովանեց, որ մեկ ուրիշը կարող է ձեռնամուխ լինել այս կետերի իրականացմանը:

Ինչ գործիքներ կօգտագործվեն այս պահանջները կատարելու համար.

  1. ELK stack (որոշ ժամանակ անց հասկացվեց, որ logstash-ի փոխարեն կօգտագործվի fluentd):
  2. Անսիբլ. Կառավարման հեշտության և հասանելիության փոխանակման համար մենք կօգտագործենք AWX:
  3. GITLAB. Այստեղ բացատրելու կարիք չկա։ Որտեղ առանց մեր կազմաձևերի տարբերակի վերահսկման:
  4. PowerShell. Կազմաձևի սկզբնական սերնդի համար կլինի պարզ սցենար:
  5. Doku wiki, փաստաթղթեր և ձեռնարկներ գրելու համար։ Այս դեպքում մենք օգտագործում ենք habr.com-ը։
  6. Մոնիտորինգը կկատարվի zabbix-ի միջոցով։ Կլինի նաև միացման սխեման ընդհանուր ըմբռնման համար:

EFK տեղադրման կետեր

Առաջին կետում ես կնկարագրեմ միայն այն գաղափարախոսությունը, որի վրա կկառուցվեն ցուցանիշները։ Կան բազմաթիվ
հիանալի հոդվածներ միկրոտիկով աշխատող սարքերից տեղեկամատյաններ տեղադրելու և ստանալու վերաբերյալ:

Կանդրադառնամ որոշ կետերի վրա.

1. Համաձայն սխեմայի, արժե մտածել տարբեր վայրերից և տարբեր նավահանգիստներից տեղեկամատյաններ ստանալու մասին: Դա անելու համար մենք կօգտագործենք տեղեկամատյանների ագրեգատոր: Մենք նաև ցանկանում ենք համընդհանուր գրաֆիկա պատրաստել բոլոր երթուղիչների համար՝ հասանելիությունը համօգտագործելու ունակությամբ: Այնուհետև մենք կառուցում ենք ինդեքսները հետևյալ կերպ.

ահա fluentd-ով կոնֆիգուրայի մի հատված elasticearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
հանգույցին առաձգական որոնում: 9200
նավահանգիստ 9200

Այսպիսով, մենք կարող ենք համատեղել երթուղիչները և սեգմենտները ըստ պլանի՝ mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east: Ինչու՞ դա այդքան դժվարացնել: Մենք հասկանում ենք, որ կունենանք 200 կամ ավելի սարք։ Մի հետևիր ամեն ինչին. Քանի որ elasticsearch-ի 6.8 տարբերակը, անվտանգության կարգավորումները հասանելի են մեզ (առանց լիցենզիա գնելու), հետևաբար, մենք կարող ենք դիտման իրավունքները բաշխել տեխնիկական աջակցության աշխատակիցների կամ տեղական համակարգի ադմինիստրատորների միջև:
Աղյուսակներ, գծապատկերներ - այստեղ դուք պարզապես պետք է համաձայնեք, կամ օգտագործեք նույնը, կամ բոլորն անում են դա այնպես, ինչպես հարմար կլինի իրեն:

2. Ծառահատումներով. Եթե ​​մենք հնարավորություն ենք տալիս մուտք գործել firewall-ի կանոնները, ապա անունները ստեղծում ենք առանց բացատների: Կարելի է տեսնել, որ օգտագործելով fluentd-ում պարզ կոնֆիգուրացիա՝ մենք կարող ենք զտել տվյալները և պատրաստել հարմար վահանակներ։ Ստորև նկարը իմ տան երթուղիչն է:

Իմ անավարտ նախագիծը. 200 MikroTik երթուղիչների ցանց

3. Ըստ զբաղեցրած տարածքի և գերանների. Միջին հաշվով ժամում 1000 հաղորդագրությունների դեպքում լոգերը օրական 2-3 ՄԲ են զբաղեցնում, ինչը, տեսնում եք, այնքան էլ շատ չէ։ elasticsearch տարբերակ 7.5.

ANSIBLE.AWX

Բարեբախտաբար, մենք ունենք պատրաստի մոդուլ երթուղիչների համար
Ես մատնանշեցի AWX-ի մասին, բայց ստորև բերված հրամանները վերաբերում են միայն ansible-ին իր մաքուր ձևով. կարծում եմ նրանց համար, ովքեր աշխատել են ansible-ի հետ, awx-ի օգտագործման հետ կապված խնդիրներ չեն լինի gui-ի միջոցով:

Ճիշտն ասած, մինչ այդ ես նայեցի այլ ուղեցույցներ, որտեղ նրանք օգտագործում էին ssh, և բոլորի մոտ տարբեր խնդիրներ ուներ արձագանքման ժամանակի հետ կապված և մի շարք այլ խնդիրներ: Կրկնում եմ՝ այն չհասավ ճակատամարտին , վերցրեք այս տեղեկատվությունը որպես փորձ, որը չի գերազանցում 20 երթուղիչի դիրքը:

Մենք պետք է օգտագործենք վկայական կամ հաշիվ: Ձեր որոշելիքն է, ես կողմ եմ վկայականներին: Իրավունքների վերաբերյալ որոշ նուրբ կետ. Ես գրելու իրավունք եմ տալիս. համենայնդեպս, «վերականգնել կազմաձևը» չի աշխատի:

Հավաստագրի ստեղծման, պատճենման և ներմուծման հետ կապված խնդիրներ չպետք է լինեն.

Հրամանների համառոտ ցուցակՁեր համակարգչի վրա
ssh-keygen -t RSA, պատասխանեք հարցերին, պահեք բանալին:
Պատճենել mikrotik-ին.
օգտվողի ssh-keys ներմուծում public-key-file=id_mtx.pub user=ansible
Նախ անհրաժեշտ է ստեղծել հաշիվ և իրավունքներ հատկացնել դրան:
Վկայագրի հետ կապի ստուգում
ssh -p 49475 -i /ստեղներ/mtx [էլեկտրոնային փոստով պաշտպանված]

Գրեք vi /etc/ansible/hosts
MT01 ansible_network_os=երթուղիներ ansible_ssh_port=49475 ansible_ssh_user= ansible
MT02 ansible_network_os=երթուղիներ ansible_ssh_port=49475 ansible_ssh_user= ansible
MT03 ansible_network_os=երթուղիներ ansible_ssh_port=49475 ansible_ssh_user= ansible
MT04 ansible_network_os=երթուղիներ ansible_ssh_port=49475 ansible_ssh_user= ansible

Դե, խաղային գրքի օրինակ. անունը. add_work_sites
տանտերեր:testmt
սերիա: 1
կապ:network_cli
remote_user: mikrotik.west
հավաքել_փաստեր՝ այո
առաջադրանքներ:
անունը՝ ավելացնել Work_sites
routeros_command:
հրամանները.
- /ip firewall address-list add address=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
- /ip firewall address-list ավելացնել հասցե=habr.com list=work_sites comment=for_habr

Ինչպես տեսնում եք վերը նշված կոնֆիգուրացիայից, ձեր սեփական գրքույկ կազմելը պարզ խնդիր է: Բավական է բավական լավ տիրապետել cli mikrotik-ին։ Պատկերացրեք մի իրավիճակ, երբ դուք պետք է հեռացնեք հասցեների ցանկը բոլոր երթուղիչների վրա որոշակի տվյալներով, ապա.

Գտնել և հեռացնել/ip firewal address-list հեռացնել [find where list="gov.ru"]

Ես միտումնավոր չներառեցի այստեղ firewall-ի ամբողջ ցուցակը: այն անհատական ​​է լինելու յուրաքանչյուր նախագծի համար: Բայց մի բան հաստատ կարող եմ ասել՝ օգտագործեք միայն հասցեների ցանկը։

Ըստ GITLAB-ի՝ ամեն ինչ պարզ է. Այս պահի վրա չեմ անդրադառնա։ Ամեն ինչ գեղեցիկ է անհատական ​​առաջադրանքների, կաղապարների, մշակողների առումով։

Powershell

Կլինի 3 ֆայլ։ Ինչու՞ powershell: Կազմաձևեր ստեղծելու գործիքը կարող է ընտրել յուրաքանչյուրը, ով ավելի հարմարավետ է: Այս դեպքում բոլորն ունեն Windows իրենց համակարգչի վրա, ուստի ինչու դա անել bash-ով, երբ powershell-ն ավելի հարմար է: Ո՞վ է ավելի հարմար:

Սցենարն ինքնին (պարզ և հասկանալի).[cmdletBinding()] Պարամ(
[Պարամետր(Պարտադիր=$true)] [string]$EXTERNALIPADDRESS,
[Պարամետր(Պարտադիր=$true)] [string]$EXTERNALIPROUTE,
[Պարամետր(Պարտադիր=$ճշմարիտ)] [string]$BWorknets,
[Պարամետր(Պարտադիր=$true)] [string]$CWorknets,
[Պարամետր(Պարտադիր=$true)] [string]$BVoipNets,
[Պարամետր(Պարտադիր=$true)] [string]$CVoipNets,
[Պարամետր(Պարտադիր=$true)] [string]$CClientss,
[Պարամետր(Պարտադիր=$ճշմարիտ)] [string]$BVPNWORKs,
[Պարամետր(Պարտադիր=$true)] [string]$CVPNWORKs,
[Պարամետր(Պարտադիր=$true)] [string]$BVPNCLIENTSs,
[Պարամետր(Պարտադիր=$true)] [string]$cVPNCLIENTSs,
[Պարամետր(Պարտադիր=$true)] [string]$NAMEROUTER,
[Պարամետր(Պարտադիր=$true)] [string]$ServerCertificates,
[Պարամետր(Պարտադիր=$true)] [string]$infile,
[Պարամետր(Պարտադիր=$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

Ներողություն եմ խնդրում, ես չեմ կարող բոլոր կանոնները դնել: գեղեցիկ չի լինի: Դուք կարող եք ինքներդ կազմել կանոնները՝ առաջնորդվելով լավագույն փորձով:

Օրինակ, ահա հղումների ցանկը, որոնցով ես առաջնորդվել եմ.wiki.mikrotik.com/wiki/Manual:Securing_Your_Router
wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter
wiki.mikrotik.com/wiki/Manual:OSPF-օրինակներ
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 - այստեղ դուք պետք է իմանաք, որ երբ fasttrack-ը միացված է, երթևեկության առաջնահերթությունների և ձևավորման կանոնները չեն աշխատի, ինչը օգտակար է թույլ սարքերի համար:

Փոփոխական կոնվենցիաներ.Որպես օրինակ վերցված են հետևյալ ցանցերը.
192.168.0.0/24 աշխատանքային ցանց
172.22.4.0/24 VOIP ցանց
10.0.0.0/24 ցանց առանց LAN մուտքի հաճախորդների համար
192.168.255.0/24 VPN ցանց խոշոր մասնաճյուղերի համար
172.19.255.0/24 VPN ցանց փոքրի համար

Ցանցի հասցեն բաղկացած է 4 տասնորդական թվերից, համապատասխանաբար ABCD, փոխարինումն աշխատում է նույն սկզբունքով, եթե գործարկման ժամանակ B հարցնում է, ապա ցանցի համար պետք է մուտքագրել 192.168.0.0 թիվը 24/0, իսկ C=0-ի համար: .
$EXTERNALIPADDRESS - հատկացված հասցե մատակարարից:
$EXTERNALIPROUTE - լռելյայն երթուղի դեպի ցանց 0.0.0.0/0
$BWorknets - Աշխատանքային ցանց, մեր օրինակում կլինի 168
$CWorknets - Աշխատանքային ցանց, մեր օրինակում այն ​​կլինի 0
$BVoipNets - VOIP ցանց մեր օրինակում այստեղ 22
$CVoipNets - VOIP ցանց մեր օրինակում այստեղ 4
$CClientss - Ցանց հաճախորդների համար - մուտք միայն ինտերնետ, մեր դեպքում այստեղ 0
$BVPNWORKs - VPN ցանց մեծ մասնաճյուղերի համար, մեր օրինակում 20
$CVPNWORKs - VPN ցանց մեծ մասնաճյուղերի համար, մեր օրինակում 255
$BVPNCLIENTS - VPN ցանց փոքր մասնաճյուղերի համար, նշանակում է 19
$CVPNCLIENTS - VPN ցանց փոքր մասնաճյուղերի համար, նշանակում է 255
$NAMEROUTER - երթուղիչի անունը
$ServerCertificate - վկայագրի անվանումը, որը դուք առաջինը ներմուծում եք
$infile - Նշեք այն ֆայլի ուղին, որտեղից մենք կկարդանք կազմաձևը, օրինակ D:config.txt (ավելի լավ անգլերեն ուղի առանց չակերտների և բացատների)
$outfile - նշեք այն ուղին, որտեղ պետք է պահպանվի, օրինակ D:MT-test.txt

Ես միտումնավոր փոխել եմ օրինակների հասցեները՝ հասկանալի պատճառներով։

Ես բաց թողեցի հարձակումների և անոմալ վարքագծի հայտնաբերման կետը. սա առանձին հոդվածի է արժանի: Բայց հարկ է նշել, որ այս կատեգորիայում կարող եք օգտագործել մոնիտորինգի տվյալների արժեքները Zabbix-ից + մշակված curl տվյալները elasticsearch-ից:

Ինչ կետերի վրա պետք է կենտրոնանալ.

  1. Ցանցային պլան. Ավելի լավ է այն գրել ընթեռնելի ձևով։ Excel-ը բավական է։ Ցավոք սրտի, հաճախ եմ տեսնում, որ ցանցերը կազմվում են «Նոր մասնաճյուղ է հայտնվել, ահա /24-ը» սկզբունքով։ Ոչ ոք չի պարզում, թե տվյալ վայրում քանի սարք է սպասվում և արդյոք հետագա աճ կլինի: Օրինակ, բացվել է մի փոքրիկ խանութ, որում ի սկզբանե պարզ է, որ սարքը լինելու է ոչ ավելի, քան 10, ինչո՞ւ հատկացնել / 24: Ընդհակառակը, խոշոր մասնաճյուղերի համար նրանք հատկացնում են / 24, և կա 500 սարք, պարզապես կարող եք ցանց ավելացնել, բայց ուզում եք ամեն ինչ անմիջապես մտածել:
  2. Զտման կանոններ. Եթե ​​նախագիծը ենթադրում է, որ կլինի ցանցերի տարանջատում և առավելագույն սեգմենտավորում։ Լավագույն փորձը փոխվում է ժամանակի ընթացքում: Նախկինում նրանք կիսում էին ԱՀ ցանցը և տպիչի ցանցը, այժմ միանգամայն նորմալ է չհամօգտագործել այս ցանցերը: Արժե օգտագործել ողջամտությունը և չարտադրել բազմաթիվ ենթացանցեր, որտեղ դրանք պետք չեն և չհամատեղել բոլոր սարքերը մեկ ցանցի մեջ։
  3. «Ոսկե» կարգավորումներ բոլոր երթուղիչների վրա: Նրանք. եթե ունեք ծրագիր. Արժե անմիջապես կանխատեսել ամեն ինչ և փորձել համոզվել, որ բոլոր պարամետրերը նույնական են. կան միայն տարբեր հասցեների ցանկ և ip հասցեներ: Խնդիրների դեպքում վրիպազերծման ժամանակն ավելի քիչ կլինի։
  4. Կազմակերպչական ասպեկտները ոչ պակաս կարևոր են, քան տեխնիկականը։ Հաճախ ծույլ աշխատակիցները հետևում են այս առաջարկություններին «ձեռքով»՝ առանց պատրաստի կոնֆիգուրացիաների և սցենարների օգտագործման, ինչը, ի վերջո, հանգեցնում է զրոյից խնդիրների:

Դինամիկ երթուղիներով: Օգտագործվել է OSPF գոտիավորման հետ: Բայց սա փորձարկման նստարան է, մարտական ​​պայմաններում նման բաները ավելի հետաքրքիր է տեղադրել։

Հուսով եմ, ոչ ոք չի տխրել, որ ես չեմ տեղադրել երթուղիչների կոնֆիգուրացիան: Կարծում եմ, որ հղումները բավական կլինեն, իսկ հետո ամեն ինչ կախված է պահանջներից։ Եվ իհարկե թեստեր, ավելի շատ թեստեր են անհրաժեշտ:

Բոլորին մաղթում եմ, որ նոր տարում իրականացնեն իրենց ծրագրերը։ Թող տրամադրված մուտքը լինի ձեզ հետ!!!

Source: www.habr.com

Добавить комментарий