Hei alle sammen. Denne artikkelen er ment for de som har mange Mikrotik-enheter i flåten, og som ønsker å gjøre maksimal forening for ikke å koble til hver enhet separat. I denne artikkelen vil jeg beskrive et prosjekt som dessverre ikke nådde kampforhold på grunn av menneskelige faktorer. Kort sagt: mer enn 200 rutere, rask oppsett og opplæring av personalet, forening etter region, filtrering av nettverk og spesifikke verter, muligheten til enkelt å legge til regler på alle enheter, logging og tilgangskontroll.
Det som er beskrevet nedenfor later ikke til å være en ferdig sak, men jeg håper det vil være nyttig for deg når du planlegger nettverkene dine og minimerer feil. Kanskje noen punkter og løsninger kanskje ikke virker helt riktige for deg – i så fall skriv i kommentarfeltet. Kritikk i denne saken vil være en opplevelse for felleskassen. Derfor, leser, ta en titt på kommentarene, kanskje forfatteren gjorde en alvorlig feil - fellesskapet vil hjelpe.
Antall rutere er 200-300, spredt over forskjellige byer med forskjellig kvalitet på Internett-tilkoblinger. Det er nødvendig å gjøre alt vakkert og tydelig forklare for lokale administratorer hvordan alt vil fungere.
Så, hvor begynner ethvert prosjekt? Selvfølgelig med TK.
- Organisering av nettverksplan for alle filialer i henhold til kundens krav, nettverkssegmentering (fra 3 til 20 nettverk i filialer avhengig av antall enheter).
- Sette opp enheter i hver gren. Kontrollere den reelle gjennomstrømningshastigheten til leverandøren under forskjellige driftsforhold.
- Organisering av enhetsbeskyttelse, administrasjon av hviteliste, automatisk gjenkjenning av angrep med automatisk svartelisting i en viss tidsperiode, minimerer bruken av ulike tekniske midler som brukes til å avskjære kontrolltilgang og nekte tjenester.
- Organisering av sikre VPN-tilkoblinger med nettverksfiltrering i henhold til kundens krav. Minimum 3 VPN-tilkoblinger fra hver gren til senteret.
- Basert på punkt 1, 2. Velg de optimale måtene å bygge feiltolerante VPN-er på. Ved riktig begrunnelse kan den dynamiske ruteteknologien velges av entreprenøren.
- Organisering av trafikkprioritering etter protokoller, porter, verter og andre spesifikke tjenester som brukes av kunden. (VOIP, verter med viktige tjenester)
- Organisering av overvåking og logging av ruterhendelser for respons fra teknisk støttepersonell.
Som vi forstår, er de tekniske spesifikasjonene i en rekke tilfeller utarbeidet ut fra kravene. Jeg formulerte disse kravene selv, etter å ha lyttet til hovedproblemene. Han innrømmet muligheten for at noen andre kunne ta seg av disse punktene.
Hvilke verktøy vil bli brukt for å oppfylle disse kravene:
- ELK stack (etter en tid ble det klart at fluentd ville bli brukt i stedet for logstash).
- Ansible. For enkel administrasjon og tilgangsdeling vil vi bruke AWX.
- GITLAB. Det er ikke nødvendig å forklare her. Hvor ville vi vært uten versjonskontroll av konfigurasjonene våre?
- Kraftskall. Det vil være et enkelt skript for den første generasjonen av konfigurasjonen.
- Doku wiki, for å skrive dokumentasjon og guider. I dette tilfellet bruker vi habr.com.
- Overvåking vil bli utført gjennom zabbix. Der vil det også bli tegnet et koblingsskjema for en generell forståelse.
EFK oppsettpunkter
Når det gjelder det første punktet, vil jeg kun beskrive ideologien som indeksene skal bygges etter. Det er mange
utmerkede artikler om å sette opp og motta logger fra enheter som kjører mikrotik.
Jeg vil dvele ved noen punkter:
1. I følge diagrammet er det verdt å vurdere å motta logger fra forskjellige steder og på forskjellige havner. Til dette vil vi bruke en loggaggregator. Vi ønsker også å lage universell grafikk for alle rutere med mulighet for å dele tilgang. Deretter bygger vi indeksene som følger:
her er en del av konfigurasjonen med fluentd type elastikksøk
logstash_format true
indeksnavn mikrotiklogs.north
logstash_prefix mikrotiklogs.north
spyleintervall 10s
Vertskapet : 9200
port 9200
På denne måten kan vi kombinere rutere og segmentere i henhold til planen - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Hvorfor gjøre det så komplisert? Vi forstår at vi vil ha 200 eller flere enheter. Du kan ikke holde styr på alt. Med versjon 6.8 av elasticsearch er sikkerhetsinnstillinger tilgjengelig for oss (uten å kjøpe en lisens), og dermed kan vi distribuere visningsrettigheter mellom tekniske støtteansatte eller lokale systemadministratorer.
Tabeller, grafer - her trenger du bare å være enig - enten bruk de samme, eller så gjør alle det som passer for ham.
2. Ved å logge. Hvis vi aktiverer innlogging i brannmurreglene, lager vi navnene uten mellomrom. Det kan sees at ved å bruke en enkel konfigurasjon i flytende, kan vi filtrere data og lage praktiske paneler. Bildet under er hjemmeruteren min.
3. Etter plass okkupert og logger. I gjennomsnitt, med 1000 meldinger per time, tar logger opp 2-3 MB per dag, som du skjønner ikke er så mye. Elasticsearch versjon 7.5.
ANSIBLE.AWX
Heldigvis for oss har vi en ferdig modul for ruter
Jeg nevnte om AWX, men kommandoene nedenfor handler kun om ansible i sin rene form - jeg tror at for de som har jobbet med ansible vil det ikke være noen problemer med å bruke awx gjennom gui.
For å være ærlig, før dette så jeg på andre guider der de brukte ssh, og de hadde alle forskjellige problemer med responstid og en haug med andre problemer. Jeg gjentar, det kom ikke til en kamp , ta denne informasjonen som et eksperiment som ikke kom lenger enn et standpunkt på 20 rutere.
Vi må bruke et sertifikat eller konto. Det er opp til deg å bestemme, jeg er for sertifikater. Noen subtile poeng om rettigheter. Jeg gir skriverettigheter - i det minste vil ikke "reset config" fungere.
Det skal ikke være noen problemer med å generere, kopiere og importere sertifikatet:
Kort kommandolistePå din PC
ssh-keygen -t RSA, svar på spørsmål, lagre nøkkelen.
Kopier til mikrotik:
bruker ssh-nøkler import public-key-file=id_mtx.pub bruker=ansible
Først må du opprette en konto og tildele rettigheter til den.
Kontrollerer tilkoblingen ved hjelp av sertifikatet
ssh -p 49475 -i /keys/mtx [e-postbeskyttet]
Registrer vi /etc/ansible/hosts
MT01 ansible_network_os=ruter ansible_ssh_port=49475 ansible_ssh_user= ansible
MT02 ansible_network_os=ruter ansible_ssh_port=49475 ansible_ssh_user= ansible
MT03 ansible_network_os=ruter ansible_ssh_port=49475 ansible_ssh_user= ansible
MT04 ansible_network_os=ruter ansible_ssh_port=49475 ansible_ssh_user= ansible
Vel, et eksempel på en lekebok: - navn: add_work_sites
verter: testmt
serie: 1
tilkobling: nettverkskli
remote_user: mikrotik.west
samle_fakta: ja
oppgaver:
- navn: legg til Work_sites
routeros_command:
kommandoer:
— /ip brannmur adresse-liste legg til adresse=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
— /ip brannmur adresse-liste legg til address=habr.com list=work_sites comment=for_habr
Som du kan se fra konfigurasjonen ovenfor, er det ikke vanskelig å lage dine egne spillebøker. Det er nok å mestre cli mikrotik godt. La oss forestille oss en situasjon der du må fjerne adresselisten med visse data på alle rutere, så:
Finn og fjern/ip brannmur adresseliste fjern [finn hvor list="gov.ru"]
Jeg har med vilje ikke inkludert hele brannmuroppføringen her fordi... det vil være individuelt for hvert prosjekt. Men en ting kan jeg si sikkert, bruk kun adresselisten.
I følge GITLAB er alt klart. Jeg vil ikke dvele ved dette punktet. Alt er vakkert for individuelle oppgaver, maler, behandlere.
PowerShell
Det vil være 3 filer her. Hvorfor powershell? Du kan velge hvilket som helst verktøy for å generere konfigurasjoner, det som er mer praktisk for deg. I dette tilfellet har alle Windows på PC-en, så hvorfor gjøre det i bash når powershell er mer praktisk. Hvilken er mer praktisk?
Selve skriptet (enkelt og forståelig):[cmdletBinding()]
Param(
[Parameter(Obligatorisk=$true)]
[string]$EXTERNALIPADDRESS,
[Parameter(Obligatorisk=$true)]
[streng]$EXTERNALIPROUTE,
[Parameter(Obligatorisk=$true)]
[string]$BWorknets,
[Parameter(Obligatorisk=$true)]
[string]$CWorknets,
[Parameter(Obligatorisk=$true)]
[string]$BVoipNets,
[Parameter(Obligatorisk=$true)]
[string]$CVoipNets,
[Parameter(Obligatorisk=$true)]
[string]$CClientss,
[Parameter(Obligatorisk=$true)]
[string]$BVPNWORKs,
[Parameter(Obligatorisk=$true)]
[string]$CVPNWORKs,
[Parameter(Obligatorisk=$true)]
[string]$BVPNCLIENTSs,
[Parameter(Obligatorisk=$true)]
[string]$cVPNCLIENTSs,
[Parameter(Obligatorisk=$true)]
[streng]$NAMEROUTER,
[Parameter(Obligatorisk=$true)]
[string]$ServerCertificates,
[Parameter(Obligatorisk=$true)]
[string]$infile,
[Parameter(Obligatorisk=$true)]
[streng]$utfil
)
Hent-innhold $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("MYNAMEROUTER", $NAMEROUTER)} |
Foreach-Object {$_.Replace("ServerCertificate", $ServerCertificates)} | Set-Content $outfile
Tilgi meg, jeg kan ikke legge ut alle reglene fordi... det blir ikke særlig pent. Du kan lage reglene selv, veiledet av beste praksis.
Her er for eksempel en liste over linker jeg fulgte::Sikker_ruteren_din
:IP/Brannmur/Filter
:OSPF-eksempler
: Winbox
:Upgrading_RouterOS
:IP/Fasttrack - her må du vite at når fasttrack er aktivert, vil ikke trafikkprioriterings- og formingsreglene fungere - nyttig for svake enheter.
Symboler for variabler:Følgende nettverk er tatt som eksempel:
192.168.0.0/24 arbeidsnettverk
172.22.4.0/24 VOIP-nettverk
10.0.0.0/24-nettverk for klienter uten tilgang til det lokale nettverket
192.168.255.0/24 VPN-nettverk for store filialer
172.19.255.0/24 VPN-nettverk for små
Nettverksadressen består av 4 desimaltall, henholdsvis A.B.C.D, erstatningen fungerer etter samme prinsipp, hvis den ved oppstart ber om B, betyr det at du må angi tallet 192.168.0.0 for nettverket 24/0, og for C = 0.
$EXTERNALIPADDDRESS - dedikert adresse fra leverandøren.
$EXTERNALIPROUTE - standard rute til nettverk 0.0.0.0/0
$BWorknets - Arbeidsnettverk, i vårt eksempel vil det være 168
$CWorknets - Arbeidsnettverk, i vårt eksempel vil dette være 0
$BVoipNets - VOIP-nettverk i vårt eksempel her 22
$CVoipNets - VOIP-nettverk i vårt eksempel her 4
$CClientss - Nettverk for klienter - kun Internett-tilgang, i vårt tilfelle her 0
$BVPNWORKs - VPN-nettverk for store filialer, i vårt eksempel 20
$CVPNWORKs - VPN-nettverk for store filialer, i vårt eksempel 255
$BVPNCLIENTS - VPN-nettverk for små filialer, som betyr 19
$CVPNCLIENTS - VPN-nettverk for små filialer, som betyr 255
$NAMEROUTER - ruternavn
$ServerCertificate - navnet på sertifikatet som du tidligere importerte
$infile — Spesifiser banen til filen som vi skal lese konfigurasjonen fra, for eksempel D:config.txt (helst den engelske banen uten anførselstegn og mellomrom)
$outfile — spesifiser banen der den skal lagres, for eksempel D:MT-test.txt
Jeg har bevisst endret adressene i eksemplene av åpenbare grunner.
Jeg gikk glipp av poenget med å oppdage angrep og unormal oppførsel – dette fortjener en egen artikkel. Men det er verdt å påpeke at i denne kategorien kan du bruke overvåkingsdataverdier fra Zabbix + behandlede krølledata fra elasticsearch.
Hvilke punkter bør du være oppmerksom på:
- Nettverksplan. Det er bedre å komponere det umiddelbart i en lesbar form. Excel vil være tilstrekkelig. Dessverre ser jeg veldig ofte at nettverk bygges i henhold til prinsippet "En ny gren har dukket opp, her er /24 for deg." Ingen finner ut hvor mange enheter som forventes på et gitt sted eller om det vil bli ytterligere vekst. For eksempel åpnet det en liten butikk der det i utgangspunktet var klart at enheten ikke ville være mer enn 10, hvorfor tildele /24? For store filialer, tvert imot, tildeler de /24, og det er 500 enheter - du kan ganske enkelt legge til et nettverk, men du vil tenke gjennom alt på en gang.
- Filtreringsregler. Dersom prosjektet forutsetter at det blir separasjon av nettverk og maksimal segmentering. Beste praksis endres over tid. Tidligere var et PC-nettverk og et skrivernettverk delt, men nå er det helt normalt å ikke dele disse nettverkene. Det er verdt å bruke sunn fornuft og ikke lage mange undernett der de ikke er nødvendige og ikke kombinere alle enhetene i ett nettverk.
- "Golden" innstillinger på alle rutere. De. hvis du har bestemt deg for en plan. Det er verdt å forutse alt med en gang og prøve å sørge for at alle innstillingene er identiske - bare adresselisten og IP-adressene er forskjellige. Hvis det oppstår problemer, vil feilsøkingstiden bli kortere.
- Organisatoriske spørsmål er ikke mindre viktige enn tekniske. Ofte utfører late ansatte disse anbefalingene "manuelt", uten å bruke ferdige konfigurasjoner og skript, noe som til slutt fører til problemer fra ingensteds.
Ved dynamisk ruting. OSPF med soneinndeling ble brukt. Men dette er en testbenk; det er mer interessant å sette opp slike ting under kampforhold.
Jeg håper ingen er opprørt over at jeg ikke la ut ruterkonfigurasjonene. Jeg tror at koblingene vil være nok, og da avhenger alt av kravene. Og selvfølgelig tester, flere tester trengs.
Jeg ønsker alle å realisere sine prosjekter i det nye året. Må tilgang gitt være med deg!!!
Kilde: www.habr.com