Mit urealiserede projekt. Netværk af 200 MikroTik-routere

Hej alle. Denne artikel er beregnet til dem, der har mange Mikrotik-enheder i deres flåde, og som ønsker at lave maksimal forening for ikke at oprette forbindelse til hver enhed separat. I denne artikel vil jeg beskrive et projekt, der desværre ikke nåede kampbetingelser på grund af menneskelige faktorer. Kort sagt: mere end 200 routere, hurtig opsætning og træning af personale, samling efter region, filtrering af netværk og specifikke værter, muligheden for nemt at tilføje regler til alle enheder, logning og adgangskontrol.

Det, der er beskrevet nedenfor, foregiver ikke at være en færdiglavet sag, men jeg håber, det vil være nyttigt for dig, når du planlægger dine netværk og minimerer fejl. Måske virker nogle punkter og løsninger måske ikke helt korrekte for dig – hvis ja, så skriv i kommentarerne. Kritik vil i denne sag være en oplevelse for fælleskassen. Derfor læser, tag et kig på kommentarerne, måske har forfatteren lavet en alvorlig fejl - fællesskabet vil hjælpe.

Antallet af routere er 200-300, spredt ud over forskellige byer med forskellig kvalitet af internetforbindelser. Det er nødvendigt at gøre alt smukt og tydeligt forklare de lokale administratorer, hvordan alt vil fungere.

Så hvor begynder ethvert projekt? Selvfølgelig med TK.

1. Organisering af en netværksplan for alle filialer i henhold til kundens krav, netværkssegmentering (fra 3 til 20 netværk i filialer afhængig af antallet af enheder).
2. Opsætning af enheder i hver gren. Kontrol af udbyderens reelle gennemløbshastighed under forskellige driftsforhold.
3. Organisering af enhedsbeskyttelse, whitelist-styring, auto-detektering af angreb med auto-sortlisting i en vis periode, minimerer brugen af ​​forskellige tekniske midler, der bruges til at opsnappe adgangskontrol og nægte service.
4. Organisering af sikre VPN-forbindelser med netværksfiltrering i henhold til kundens krav. Minimum 3 VPN-forbindelser fra hver filial til centeret.
5. Baseret på punkt 1, 2. Vælg de optimale måder at bygge fejltolerante VPN'er på. Hvis det begrundes korrekt, kan den dynamiske routing-teknologi vælges af entreprenøren.
6. Organisering af trafikprioritering efter protokoller, porte, værter og andre specifikke tjenester, der anvendes af kunden. (VOIP, værter med vigtige tjenester)
7. Organisering af overvågning og logning af routerhændelser til svar fra teknisk supportpersonale.

Som vi forstår, er de tekniske specifikationer i en række tilfælde udarbejdet ud fra kravene. Disse krav formulerede jeg selv efter at have lyttet til hovedproblemerne. Han indrømmede muligheden for, at en anden kunne tage sig af disse punkter.

Hvilke værktøjer vil blive brugt til at opfylde disse krav:

1. ELK stack (efter nogen tid blev det klart, at fluentd ville blive brugt i stedet for logstash).
2. Ansible. For at lette administrationen og adgangsdeling vil vi bruge AWX.
3. GITLAB. Der er ingen grund til at forklare her. Hvor ville vi være uden versionskontrol af vores konfigurationer?
4. PowerShell. Der vil være et simpelt script til den første generation af konfigurationen.
5. Doku wiki, til at skrive dokumentation og vejledninger. I dette tilfælde bruger vi habr.com.
6. Overvågning vil blive udført gennem zabbix. Der vil også blive tegnet et forbindelsesdiagram for en generel forståelse.

EFK opstillingspunkter

Vedrørende det første punkt vil jeg kun beskrive den ideologi, som indeksene vil bygges op efter. Der er mange
fremragende artikler om opsætning og modtagelse af logfiler fra enheder, der kører mikrotik.

Jeg vil dvæle ved nogle punkter:

1. Ifølge diagrammet er det værd at overveje at modtage logfiler fra forskellige steder og på forskellige havne. Til dette vil vi bruge en log-aggregator. Vi ønsker også at lave universel grafik til alle routere med mulighed for at dele adgang. Derefter bygger vi indeksene som følger:

her er et stykke af konfigurationen med fluentd type elastiksøgning
logstash_format true
indeksnavn mikrotiklogs.north
logstash_prefix mikrotiklogs.north
skylleinterval 10s
værter elastiksøgning: 9200
port 9200

På denne måde kan vi kombinere routere og segmentere efter planen - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Hvorfor gøre det så kompliceret? Vi forstår, at vi vil have 200 eller flere enheder. Man kan ikke holde styr på alt. Med version 6.8 af elasticsearch er sikkerhedsindstillinger tilgængelige for os (uden at købe en licens), hvorved vi kan fordele visningsrettigheder mellem tekniske supportmedarbejdere eller lokale systemadministratorer.
Tabeller, grafer - her skal du bare være enig - enten brug de samme, eller også gør alle, hvad der passer ham.

2. Ved at logge. Hvis vi aktiverer log i firewall-reglerne, laver vi navnene uden mellemrum. Det kan ses, at vi ved at bruge en simpel konfiguration i fluentd kan filtrere data og lave praktiske paneler. Billedet nedenfor er min hjemmerouter.

3. Ved optaget plads og logs. I gennemsnit fylder logfiler med 1000 beskeder i timen 2-3 MB om dagen, hvilket du kan se, ikke er så meget. Elasticsearch version 7.5.

ANSIBLE.AWX

Heldigvis for os har vi et færdigt modul til routers
Jeg nævnte om AWX, men kommandoerne nedenfor handler kun om ansible i sin rene form - jeg tror, ​​at for dem, der har arbejdet med ansible, vil der ikke være problemer med at bruge awx gennem gui.

For at være ærlig, før dette kiggede jeg på andre guider, hvor de brugte ssh, og de havde alle forskellige problemer med responstid og en masse andre problemer. Jeg gentager, det kom ikke til en kamp , tag denne information som et eksperiment, der ikke nåede længere end en stand på 20 routere.

Vi skal bruge et certifikat eller en konto. Det er op til dig at bestemme, jeg er for certifikater. En subtil pointe om rettigheder. Jeg giver skriverettigheder - i det mindste virker "reset config" ikke.

Der skulle ikke være problemer med at generere, kopiere og importere certifikatet:

Kort kommandolistePå din pc
ssh-keygen -t RSA, svar på spørgsmål, gem nøglen.
Kopiér til mikrotik:
bruger ssh-nøgler import public-key-file=id_mtx.pub user=ansible
Først skal du oprette en konto og tildele rettigheder til den.
Kontrollerer forbindelsen ved hjælp af certifikatet
ssh -p 49475 -i /keys/mtx [e-mail beskyttet]

Registrer 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

Nå, et eksempel på en spillebog: - navn: add_work_sites
værter: testmt
serie: 1
forbindelse: netværk_cli
remote_user: mikrotik.west
indsamle_fakta: ja
opgaver:
- navn: tilføje Work_sites
routeros_command:
kommandoer:
— /ip firewall adresseliste tilføj adresse=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
— /ip firewall adresseliste tilføj adresse=habr.com list=work_sites comment=for_habr

Som du kan se fra ovenstående konfiguration, er det ikke svært at lave dine egne spillebøger. Det er nok at mestre cli mikrotik godt. Lad os forestille os en situation, hvor du skal fjerne adresselisten med visse data på alle routere, så:

Find og fjern/ip firewal adresseliste fjern [find hvor list="gov.ru"]

Jeg har med vilje ikke inkluderet hele firewall-listen her, fordi... det vil være individuelt for hvert projekt. Men én ting kan jeg med sikkerhed sige, brug kun adresselisten.

Ifølge GITLAB er alt klart. Jeg vil ikke dvæle ved dette punkt. Alt er smukt til individuelle opgaver, skabeloner, handlere.

PowerShell

Der vil være 3 filer her. Hvorfor powershell? Du kan vælge et hvilket som helst værktøj til at generere konfigurationer, uanset hvad der er mere praktisk for dig. I dette tilfælde har alle Windows på deres pc, så hvorfor gøre det i bash, når powershell er mere praktisk. Hvilken er mere praktisk?

Selve scriptet (simpelt og forståeligt):[cmdletBinding()] Param(
[Parameter(Obligatorisk=$true)] [streng]$EXTERNALIPADDRESS,
[Parameter(Obligatorisk=$true)] [streng]$EXTERNALIPROUTE,
[Parameter(Obligatorisk=$true)] [streng]$BWorknets,
[Parameter(Obligatorisk=$true)] [streng]$CWorknets,
[Parameter(Obligatorisk=$true)] [string]$BVoipNets,
[Parameter(Obligatorisk=$true)] [string]$CVoipNets,
[Parameter(Obligatorisk=$true)] [streng]$CClientss,
[Parameter(Obligatorisk=$true)] [streng]$BVPNWORKs,
[Parameter(Obligatorisk=$true)] [streng]$CVPNWORKs,
[Parameter(Obligatorisk=$true)] [streng]$BVPNCLIENTSs,
[Parameter(Obligatorisk=$true)] [streng]$cVPNCLIENTSs,
[Parameter(Obligatorisk=$true)] [streng]$NAMEROUTER,
[Parameter(Obligatorisk=$true)] [string]$ServerCertificates,
[Parameter(Obligatorisk=$true)] [streng]$infil,
[Parameter(Obligatorisk=$true)] [streng]$outfil
)

Hent-indhold $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

Undskyld mig, jeg kan ikke skrive alle reglerne, fordi... det bliver ikke særlig kønt. Du kan selv opstille reglerne, styret af bedste praksis.

Her er for eksempel en liste over links, som jeg fulgte:wiki.mikrotik.com/wiki/Manual:Sikker_din_router
wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter
wiki.mikrotik.com/wiki/Manual:OSPF-eksempler
wiki.mikrotik.com/wiki/Drop_port_scanners
wiki.mikrotik.com/wiki/Manual: Winbox
wiki.mikrotik.com/wiki/Manual:Opgradering_RouterOS
wiki.mikrotik.com/wiki/Manual:IP/Fasttrack - her skal du vide, at når fasttrack er aktiveret, vil reglerne for trafikprioritering og formgivning ikke fungere - nyttigt for svage enheder.

Symboler for variabler:Følgende netværk tages som eksempel:
192.168.0.0/24 fungerende netværk
172.22.4.0/24 VOIP netværk
10.0.0.0/24 netværk til klienter uden adgang til det lokale netværk
192.168.255.0/24 VPN-netværk til store filialer
172.19.255.0/24 VPN-netværk til små

Netværksadressen består af 4 decimaltal, henholdsvis A.B.C.D, udskiftningen fungerer efter samme princip, hvis den ved opstart beder om B, så betyder det at du skal indtaste tallet 192.168.0.0 for netværket 24/0, og for C = 0.
$EXTERNALIPADDDRESS - dedikeret adresse fra udbyderen.
$EXTERNALIPROUTE - standardrute til netværk 0.0.0.0/0
$BWorknets - Arbejdsnetværk, i vores eksempel vil der være 168
$CWorknets - Arbejdsnetværk, i vores eksempel vil dette være 0
$BVoipNets - VOIP-netværk i vores eksempel her 22
$CVoipNets - VOIP-netværk i vores eksempel her 4
$CClientss - Netværk for klienter - kun internetadgang, i vores tilfælde her 0
$BVPNWORKs - VPN-netværk til store filialer, i vores eksempel 20
$CVPNWORKs - VPN-netværk til store filialer, i vores eksempel 255
$BVPNCLIENTS - VPN-netværk til små filialer, hvilket betyder 19
$CVPNCLIENTS - VPN-netværk til små filialer, hvilket betyder 255
$NAMEROUTER - routernavn
$ServerCertificate - navnet på det certifikat, som du tidligere importerede
$infile — Angiv stien til filen, hvorfra vi vil læse konfigurationen, for eksempel D:config.txt (helst den engelske sti uden anførselstegn og mellemrum)
$outfile — angiv stien, hvor den skal gemmes, for eksempel D:MT-test.txt

Jeg har bevidst ændret adresserne i eksemplerne af indlysende årsager.

Jeg gik glip af pointen med at opdage angreb og unormal adfærd - dette fortjener en separat artikel. Men det er værd at påpege, at du i denne kategori kan bruge overvågningsdataværdier fra Zabbix + behandlede krølledata fra elasticsearch.

Hvilke punkter skal du være opmærksom på:

1. Netværksplan. Det er bedre at komponere det straks i en læsbar form. Excel vil være tilstrækkeligt. Desværre ser jeg meget ofte, at netværk er bygget efter princippet "En ny filial er dukket op, her er /24 til dig." Ingen ved, hvor mange enheder der forventes på et givet sted, eller om der vil være yderligere vækst. For eksempel åbnede en lille butik, hvor det oprindeligt var klart, at enheden ikke ville være mere end 10, hvorfor tildele /24? For store filialer tildeler de tværtimod /24, og der er 500 enheder - du kan blot tilføje et netværk, men du vil tænke alt igennem på én gang.
2. Filtreringsregler. Hvis projektet forudsætter, at der vil ske adskillelse af netværk og maksimal segmentering. Bedste praksis ændrer sig over tid. Tidligere var et pc-netværk og et printernetværk delt, men nu er det helt normalt ikke at opdele disse netværk. Det er værd at bruge sund fornuft og ikke oprette mange undernet, hvor de ikke er nødvendige og ikke kombinere alle enheder i ét netværk.
3. "Gyldne" indstillinger på alle routere. De der. hvis du har besluttet dig for en plan. Det er værd at forudse alt med det samme og prøve at sikre, at alle indstillinger er identiske - kun adresselisten og IP-adresserne er forskellige. Hvis der opstår problemer, vil fejlretningstiden være kortere.
4. Organisatoriske spørgsmål er ikke mindre vigtige end tekniske. Ofte udfører dovne medarbejdere disse anbefalinger "manuelt", uden at bruge færdige konfigurationer og scripts, hvilket i sidste ende fører til problemer ud af ingenting.

Ved dynamisk routing. OSPF med zoneinddeling blev brugt. Men dette er en testbænk; det er mere interessant at sætte sådanne ting op under kampforhold.

Jeg håber, ingen er kede af, at jeg ikke postede routerkonfigurationerne. Jeg tror, ​​at linkene vil være nok, og så afhænger alt af kravene. Og selvfølgelig tests, flere tests er nødvendige.

Jeg ønsker alle at realisere deres projekter i det nye år. Må adgang givet være med dig!!!

Kilde: www.habr.com