Mitt orealiserade projekt. Nätverkskonfiguration med 200 MikroTik-routerar

Hej alla. Denna artikel är avsedd för dem som har många MikroTik-enheter i sitt nätverk och som vill maximera enheten, så att de inte behöver ansluta till varje enhet individuellt. I denna artikel kommer jag att beskriva ett projekt som tyvärr inte nådde produktionsstadiet på grund av mänskliga faktorer. Kort sagt: över 200 routrar, snabb installation och utbildning av personal, enhetlighet enligt regioner, filtrering av nätverk och specifika värdar, möjlighet till enkel tillägg av regler till alla enheter, loggning och åtkomstkontroll.

Det som beskrivs nedan anses inte vara en färdig lösning, men jag hoppas att det kommer att vara till nytta för dig när du planerar dina nätverk och minimerar misstagen. Vissa punkter och lösningar kan verka inte helt korrekta – om så är fallet, skriv en kommentar. Kritik i detta fall kommer att vara en erfarenhet i den allmänna kunskapsbasen. Därför, läsare, kolla in kommentarerna, kanske författaren har gjort ett grovt misstag – gemenskapen kommer att hjälpa till.

Antalet routrar är 200–300, spridda över olika städer med varierande kvalitet på internetanslutningen. Det är nödvändigt att göra allt snyggt och tydligt för lokala administratörer för att förklara hur allt kommer att fungera.

Så, var börjar något projekt? Självklart, med Kravspecifikation.

1. Organisering av nätverksplaner för alla kontor enligt kundens krav, segmentering av nätverk (från 3 till 20 nätverk i kontoren beroende på antalet enheter).
2. Inställning av enheter i varje kontor. Kontroll av faktisk bandbredd från leverantören under olika arbetsförhållanden.
3. Organisering av skydd för enheter, hantering enligt vit lista, automatisk upptäckning av attacker med automatisk tillägg i svart lista under en viss tidsperiod, minimering av användningen av olika tekniska medel som används för att avlyssna åtkomst till styrning och avvägning från service.
4. Organisering av skyddade VPN-anslutningar med filtrering enligt kundens krav. Minst 3 VPN-anslutningar från varje kontor till centralen.
5. Baserat på punkt 1 och 2. Välj optimala sätt att bygga redundanta VPN. Teknologin för dynamisk routing kan väljas av utföraren med korrekt motivering.
6. Organisation av trafikprioritering efter protokoll, portar, värdar och andra specifika tjänster som kunden använder. (VOIP, värdar med viktiga tjänster)
7. Organisation av övervakning och loggning av routerhändelser för att reagera på teknisk supportpersonal.

Som vi förstår, upprättas specifikationer ibland utifrån krav. Dessa krav har jag formulerat själv efter att ha lyssnat på de huvudsakliga problemen. Jag förutsatte att genomförandet av dessa punkter eventuellt skulle kunna hanteras av någon annan.

Vilka verktyg kommer att användas för att uppfylla dessa krav:

1. ELK-stacken (efter en tid insåg vi att istället för logstash skulle fluentd användas).
2. Ansible. För att underlätta administrationen och dela upp åtkomsten kommer vi att använda AWX.
3. GITLAB. Här behövs inga ytterligare förklaringar. Vad skulle vi göra utan versionskontroll av våra konfigurationer.
4. PowerShell. Det kommer att finnas ett enkelt skript för den första genereringen av konfigurationen.
5. Dokuwiki, för att skriva dokumentation och guider. I det här fallet använder vi habr.com.
6. Övervakning kommer att ske via zabbix. Här kommer också en diagram över anslutningar att ritas för att ge en allmän förståelse.

Aspekter av EFK-konfiguration

För det första punkten kommer jag att beskriva den ideologi enligt vilken index ska byggas. Det finns många
utmärkta artiklar om konfiguration och mottagning av loggar från enheter som styrs av mikrotik.

Jag kommer att fokusera på vissa aspekter:

1. Enligt schemat bör man tänka igenom mottagningen av loggar från olika platser och olika portar. För detta kommer vi att använda en loggaggregator. Vi vill också göra universella grafer för alla routrar med möjlighet till åtskillnad av åtkomst. Då bygger vi indexen på följande sätt:

Här är en del av konfigurationen med fluentd typ elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts , där serveradressen och mönstret för indexnamnet anges för att skicka det formaterade dokumentet::9200
port 9200

På så sätt kan vi förena routrarna och segmentera enligt planen - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Varför komplicera det så? Vi förstår att vi kommer att ha 200 eller fler enheter. Det går inte att hålla koll på allt. Med version 6.8 av elasticsearch får vi tillgång till säkerhetsinställningar (utan att behöva köpa licens), vilket gör att vi kan fördela rättigheterna att se mellan teknisk supportpersonal eller lokala systemadministratörer.
Tabeller och diagram – här behöver vi helt enkelt komma överens – antingen använda enhetliga eller så gör var och en som de tycker är bekvämt.

2. När det gäller loggning. Om vi aktiverar logg i brandväggens regler, gör vi namnen utan mellanslag. Det är tydligt att genom att använda en enkel konfiguration i fluentd kan vi filtrera data och skapa användbara paneler. På bilden nedan är min hemrouter.

3. När det gäller lagringsutrymme och loggar. I genomsnitt, vid 1000 meddelanden per timme, tar loggarna upp 2-3 MB per dag, vilket, som ni håller med om, inte är så mycket. Version elasticsearch 7.5.

ANSIBLE.AWX

Till vår glädje har vi en färdig modul för routeros.
Jag nämnde AWX, men kommandona nedan handlar bara om ansible i ren form – jag tror att det inte kommer att vara några problem att använda det via gui awx för dem som har arbetat med ansible.

Ärligt talat har jag tidigare sett andra guider som använde ssh, och alla hade olika problem med svarstider och en massa andra problem. Jag upprepar, vi kom inte till striden 🙂, så se denna information som ett experiment som inte kom längre än en benkört med 20 routrar.

Vi behöver använda ett certifikat eller ett konto. Det är upp till er att avgöra, jag föredrar certifikat. Något som är viktigt angående rättigheter. Jag ger skrivrättigheter – men att göra en 'reset config' kommer inte att vara möjligt.

När det gäller generation, kopiering av certifikat och import ska det inte uppstå några problem:

Kortfattat lista över kommandonPå din PC
ssh-keygen -t RSA, besvara frågorna, spara nyckeln.
Kopiera till mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Först måste du skapa ett konto och ge det rättigheter.
Kontrollera anslutningen med hjälp av certifikatet
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120

Skriv in 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

Och här är ett exempel på playbook: — namn: add_work_sites
hosts: testmt
serial: 1
connection: network_cli
remote_user: mikrotik.west
gather_facts: yes
tasks:
— namn: add Work_sites
routeros_command:
commands:
— /ip firewall address-list add address=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
— /ip firewall address-list add address=habr.com list=work_sites comment=for_habr

Som man kan se av den angivna konfigurationen är det ganska enkelt att skapa sina egna playbooks. Det är tillräckligt att bemästra mikrotiks cli väl. Låt oss tänka oss en situation där vi behöver ta bort address list med viss information från alla routrar, då:

Hitta och ta bort/ip firewal address-list remove [find where list=«gov.ru»]

Jag har medvetet inte inkluderat hela brandväggslistan här eftersom den kommer att vara individuell för varje projekt. Men jag kan säga en sak säkert, använd endast adresslistor.

Gällande GITLAB är allt klart. Jag kommer inte att stanna på den punkten. Allt ser bra ut med separata uppgifter, mallar och hanterare.

Powershell

Här kommer det att finnas tre filer. Varför PowerShell? Man kan välja vilket verktyg man vill för att generera konfigurationer, beroende på vad som är mest bekvämt. I det här fallet har alla Windows, så varför använda Bash när det är mer bekvämt med PowerShell? Vad som är mest praktiskt.

Själva skriptet (enkelt och tydligt):[cmdletBinding()]
Param(
[Parameter(Mandatory=$true)]
[string]$EXTERNALIPADDRESS,
[Parameter(Mandatory=$true)]
[string]$EXTERNALIPROUTE,
[Parameter(Mandatory=$true)]
[string]$BWorknets,
[Parameter(Mandatory=$true)]
[string]$CWorknets,
[Parameter(Mandatory=$true)]
[string]$BVoipNets,
[Parameter(Mandatory=$true)]
[string]$CVoipNets,
[Parameter(Mandatory=$true)]
[string]$CClientss,
[Parameter(Mandatory=$true)]
[string]$BVPNWORKs,
[Parameter(Mandatory=$true)]
[string]$CVPNWORKs,
[Parameter(Mandatory=$true)]
[string]$BVPNCLIENTSs,
[Parameter(Mandatory=$true)]
[string]$cVPNCLIENTSs,
[Parameter(Mandatory=$true)]
[string]$NAMEROUTER,
[Parameter(Mandatory=$true)]
[string]$ServerCertificates,
[Parameter(Mandatory=$true)]
[string]$infile,
[Parameter(Mandatory=$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

Jag ber om ursäkt, jag kan inte publicera alla regler eftersom det inte skulle se särskilt bra ut. Du kan själv skapa reglerna med hjälp av bästa praxis.

Till exempel, här är en lista på länkar som jag följde:wiki.mikrotik.com/wiki/Manual:Securing_Your_Router
wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter
wiki.mikrotik.com/wiki/Manual:OSPF-examples
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 — här måste man veta att när fasttrack är aktiverat, kommer prioritetsregler och trafikformning inte att fungera – användbart för svaga enheter.

Förklaringar av variabler:Exempel på följande nätverk:
192.168.0.0/24 arbetsnätverk
172.22.4.0/24 VOIP-nätverk
10.0.0.0/24 nätverk för kunder utan åtkomst till det lokala nätverket
192.168.255.0/24 VPN-nätverk för stora filialer
172.19.255.0/24 VPN-nätverk för små

Nätverksadressen består av 4 decimaler, enligt A.B.C.D-principen, på samma sätt fungerar substitutionen, om den vid start begär B, så måste man ange för nätverket 192.168.0.0/24 nummer 0, och för C = 0.
$EXTERNALIPADDRESS — dedikerad adress från leverantören.
$EXTERNALIPROUTE — standardrutt till nätverket 0.0.0.0/0
$BWorknets — Arbetsnät, i vårt exempel här kommer det att vara 168
$CWorknets — Arbetsnät, i vårt exempel här kommer det att vara 0
$BVoipNets — VOIP-nätverk i vårt exempel här 22
$CVoipNets — VOIP-nätverk i vårt exempel här 4
$CClientss — Nätverk för kunder – endast åtkomst till internet, i vårt fall här 0
$BVPNWORKs — VPN-nätverk för stora filialer, i vårt exempel 20
$CVPNWORKs — VPN-nätverk för stora filialer, i vårt exempel 255
$BVPNCLIENTS — VPN-nätverk för små filialer, alltså 19
$CVPNCLIENTS — VPN-nätverk för små filialer, alltså 255
$NAMEROUTER — namn på routern
$ServerCertificate — namn på certifikatet som du importerar på förhand
$infile — Ange sökvägen till filen som vi ska läsa konfigurationen från, till exempel D:config.txt (bättre med en engelsk sökväg utan citationstecken och mellanslag)
$outfile — Ange sökvägen där filen ska sparas, till exempel D:MT-test.txt

Jag har avsiktligt ändrat adresserna i exemplen av uppenbara skäl.

Jag hoppade över punkten om detektering av attacker och onormalt beteende – detta förtjänar en egen artikel. Men det är värt att nämna att i denna kategori kan man använda övervakningsdata från Zabbix + processade curl-data från elasticsearch.

Vilka punkter som behöver uppmärksammas:

1. Nätverksplan. Det är bättre att göra en läsbar version från början. Excel räcker gott. Tyvärr ser jag ofta att nätverk planeras med principen "Ny filial, här har ni /24". Ingen tar reda på hur många enheter som planeras på plats och om det kommer att bli någon fortsatt tillväxt. Till exempel om en liten butik öppnar, där det från början är klart att det inte kommer att finnas mer än 10 enheter, varför avsätta /24? För stora filialer – tvärtom, avsätter man /24 och enheterna blir 500 – man kan enkelt lägga till ett nätverk, men man vill gärna planera allt från början.
2. Filtreringsregler. Om projektet förutsätter att det kommer att vara nätverksuppdelningar och maximal segmentering. Best Practices förändras över tid. Tidigare delade man upp nätverk för datorer och nätverk för skrivare, nu är det helt okej att inte dela dessa nätverk. Använd sunt förnuft och undvik att skapa många subnät där de inte behövs och att slå samman alla enheter i ett nätverk.
3. "Gyllene" inställningar på alla routrar. Det vill säga, om du har bestämt dig för en plan. Det är bra att tänka på allt från början och försöka se till att alla inställningar är identiska - det handlar endast om olika adresseringslistor och IP-adresser. Vid eventuella problem kommer tiden för felsökning att bli kortare.
4. Organisatoriska aspekter är lika viktiga som de tekniska. Ofta utför lata anställda de angivna rekommendationerna "för hand", utan att använda färdiga konfigurationer och skript, vilket i slutändan leder till problem utan orsak.

Om dynamisk routing. OSPF användes med zonindelning. Men detta är en testmiljö; i skarpa förhållanden är det mer intressant att konfigurera sådana saker.

Jag hoppas att ingen blev besviken över att jag inte la upp routerkonfigurationerna. Jag tror att länkarna räcker, och sedan beror allt på kraven. Och givetvis tester, vi behöver fler tester.

Jag önskar alla att förverkliga sina projekt det nya året. Må access granted vara med er!!!

Källa: habr.com