Hej alla. Den här artikeln är avsedd för dem som har många Mikrotik-enheter i sin flotta och som vill göra maximal enhet för att inte ansluta till varje enhet separat. I den här artikeln kommer jag att beskriva ett projekt som tyvärr inte nådde stridsförhållanden på grund av mänskliga faktorer. Kort sagt: mer än 200 routrar, snabb installation och utbildning av personal, sammanslagning efter region, filtrering av nätverk och specifika värdar, möjligheten att enkelt lägga till regler till alla enheter, loggning och åtkomstkontroll.
Det som beskrivs nedan utger sig inte för att vara ett färdigt fall, men jag hoppas att det kommer att vara användbart för dig när du planerar dina nätverk och minimerar fel. Vissa punkter och lösningar kanske inte verkar helt korrekta för dig - skriv i så fall i kommentarerna. Kritik i det här fallet blir en upplevelse för den gemensamma kassan. Därför, läsare, ta en titt på kommentarerna, kanske författaren gjorde ett allvarligt misstag - samhället kommer att hjälpa.
Antalet routrar är 200-300, utspridda över olika städer med olika kvalitet på internetanslutningar. Det är nödvändigt att göra allt vackert och tydligt förklara för lokala administratörer hur allt kommer att fungera.
Så, var börjar något projekt? Naturligtvis med TK.
- Organisation av nätverksplan för alla filialer efter kundkrav, nätverkssegmentering (från 3 till 20 nätverk i filialer beroende på antal enheter).
- Installation av enheter i varje gren. Kontrollera den verkliga genomströmningshastigheten för leverantören under olika driftsförhållanden.
- Organisation av enhetsskydd, hantering av vitlista, automatisk upptäckt av attacker med automatisk svartlistning under en viss tidsperiod, vilket minimerar användningen av olika tekniska medel som används för att avlyssna kontroll åtkomst och neka tjänster.
- Organisation av säkra VPN-anslutningar med nätverksfiltrering enligt kundens önskemål. Minst 3 VPN-anslutningar från varje filial till centrum.
- Baserat på punkterna 1, 2. Välj de optimala sätten att bygga feltoleranta VPN. Om det motiveras korrekt kan den dynamiska routingtekniken väljas av entreprenören.
- Organisation av trafikprioritering efter protokoll, portar, värdar och andra specifika tjänster som används av kunden. (VOIP, värdar med viktiga tjänster)
- Organisation av övervakning och loggning av routerhändelser för svar från teknisk supportpersonal.
Som vi förstår upprättas i ett antal fall de tekniska specifikationerna utifrån kraven. Jag formulerade dessa krav själv, efter att ha lyssnat på huvudproblemen. Han medgav möjligheten att någon annan kunde ta hand om dessa punkter.
Vilka verktyg kommer att användas för att uppfylla dessa krav:
- ELK stack (efter en tid stod det klart att fluentd skulle användas istället för logstash).
- Ansible. För att underlätta administration och åtkomstdelning kommer vi att använda AWX.
- GITLAB. Det finns ingen anledning att förklara här. Var skulle vi vara utan versionskontroll av våra konfigurationer?
- PowerShell. Det kommer att finnas ett enkelt skript för den första generationen av konfigurationen.
- Doku wiki, för att skriva dokumentation och guider. I det här fallet använder vi habr.com.
- Övervakning kommer att utföras genom zabbix. Ett kopplingsschema kommer också att ritas där för en allmän förståelse.
EFK inställningspunkter
När det gäller den första punkten kommer jag bara att beskriva den ideologi som indexen kommer att byggas efter. Det är många
utmärkta artiklar om att ställa in och ta emot loggar från enheter som kör mikrotik.
Jag kommer att uppehålla mig vid några punkter:
1. Enligt diagrammet är det värt att överväga att ta emot stockar från olika platser och på olika hamnar. För detta kommer vi att använda en loggaggregator. Vi vill också göra universell grafik för alla routrar med möjlighet att dela åtkomst. Sedan bygger vi indexen enligt följande:
här är en del av konfigurationen med fluentd typ elasticsearch
logstash_format sant
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
spolintervall 10s
värdar : 9200
port 9200
På så sätt kan vi kombinera routrar och segmentera enligt planen - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Varför göra det så komplicerat? Vi förstår att vi kommer att ha 200 eller fler enheter. Man kan inte hålla reda på allt. Med version 6.8 av elasticsearch är säkerhetsinställningar tillgängliga för oss (utan att köpa licens), därigenom kan vi distribuera visningsrättigheter mellan teknisk supportanställda eller lokala systemadministratörer.
Tabeller, grafer - här behöver du bara komma överens - använd antingen samma, eller så gör alla vad som är bekvämt för honom.
2. Genom att logga. Om vi aktiverar inloggning i brandväggsreglerna gör vi namnen utan mellanslag. Det kan ses att genom att använda en enkel konfiguration i fluentd kan vi filtrera data och skapa bekväma paneler. Bilden nedan är min hemmarouter.
3. Efter upptaget utrymme och stockar. I genomsnitt, med 1000 meddelanden per timme, tar loggar upp 2-3 MB per dag, vilket du förstår inte är så mycket. Elasticsearch version 7.5.
ANSIBLE.AWX
Lyckligtvis för oss har vi en färdig modul för routers
Jag nämnde om AWX, men kommandona nedan handlar bara om ansible i sin rena form - jag tror att för de som har jobbat med ansible kommer det inte att vara några problem att använda awx genom gui.
För att vara ärlig, innan detta tittade jag på andra guider där de använde ssh, och de hade alla olika problem med svarstid och en massa andra problem. Jag upprepar, det kom inte till ett slagsmål , ta den här informationen som ett experiment som inte kom längre än till 20 routrar.
Vi måste använda ett certifikat eller konto. Det är upp till dig att bestämma, jag är för certifikat. Någon subtil poäng om rättigheter. Jag ger skrivrättigheter - åtminstone "reset config" kommer inte att fungera.
Det ska inte vara några problem att generera, kopiera och importera certifikatet:
Kort kommandolistaPå din PC
ssh-keygen -t RSA, svara på frågor, spara nyckeln.
Kopiera till mikrotik:
användarens ssh-nycklar import public-key-file=id_mtx.pub user=ansible
Först måste du skapa ett konto och tilldela rättigheter till det.
Kontrollerar anslutningen med certifikatet
ssh -p 49475 -i /keys/mtx [e-postskyddad]
Registrera 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
Tja, ett exempel på en lekbok: - namn: add_work_sites
värdar: testmt
serie: 1
anslutning: nätverk_cli
remote_user: mikrotik.west
samla_fakta: ja
uppgifter:
- namn: lägg till Work_sites
routeros_command:
kommandon:
— /ip-brandväggsadresslista lägg till adress=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
— /ip-brandväggsadresslista lägg till adress=habr.com list=work_sites comment=for_habr
Som du kan se från ovanstående konfiguration är det inte svårt att skapa dina egna spelböcker. Det räcker för att behärska cli mikrotik väl. Låt oss föreställa oss en situation där du behöver ta bort adresslistan med vissa data på alla routrar, då:
Hitta och ta bort/ip firewal adresslista ta bort [hitta var list="gov.ru"]
Jag har avsiktligt inte inkluderat hela brandväggslistan här eftersom... det kommer att vara individuellt för varje projekt. Men en sak kan jag säga säkert, använd bara adresslistan.
Enligt GITLAB är allt klart. Jag ska inte uppehålla mig vid denna punkt. Allt är vackert för individuella uppgifter, mallar, hanterare.
powershell
Det kommer att finnas 3 filer här. Varför powershell? Du kan välja vilket verktyg som helst för att generera konfigurationer, det som är bekvämare för dig. I det här fallet har alla Windows på sin PC, så varför göra det i bash när powershell är bekvämare. Vilken är bekvämare?
Själva skriptet (enkelt och begripligt):[cmdletBinding()] Param(
[Parameter(Obligatorisk=$true)] [sträng]$EXTERNALIPADDDRESS,
[Parameter(Obligatorisk=$true)] [sträng]$EXTERNALIPROUTE,
[Parameter(Mandatory=$true)] [sträng]$BWorknets,
[Parameter(Obligatoriskt=$true)] [sträng]$CWorknets,
[Parameter(Mandatory=$true)] [sträng]$BVoipNets,
[Parameter(Mandatory=$true)] [sträng]$CVoipNets,
[Parameter(Obligatoriskt=$true)] [sträng]$CClientss,
[Parameter(Mandatory=$true)] [sträng]$BVPNWORKs,
[Parameter(Mandatory=$true)] [sträng]$CVPNWORKs,
[Parameter(Mandatory=$true)] [sträng]$BVPNCLIENTSs,
[Parameter(Obligatoriskt=$true)] [sträng]$cVPNCLIENTSs,
[Parameter(Obligatoriskt=$true)] [sträng]$NAMEROUTER,
[Parameter(Obligatoriskt=$true)] [sträng]$ServerCertificates,
[Parameter(Obligatoriskt=$true)] [sträng]$infil,
[Parameter(Obligatoriskt=$true)] [sträng]$outfil
)
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
Förlåt mig, jag kan inte lägga upp alla regler eftersom... det blir inte särskilt snyggt. Du kan skapa reglerna själv, vägledd av bästa praxis.
Här är till exempel en lista med länkar som jag följde:: Säkra_din_router
:IP/Brandvägg/Filter
:OSPF-exempel
: Winbox
:Upgrading_RouterOS
:IP/Fasttrack - här behöver du veta att när fasttrack är aktiverat, fungerar inte reglerna för trafikprioritering och formning - användbart för svaga enheter.
Symboler för variabler:Följande nätverk tas som exempel:
192.168.0.0/24 fungerande nätverk
172.22.4.0/24 VOIP-nätverk
10.0.0.0/24 nätverk för klienter 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 decimaltal, respektive ABCD, ersättningen fungerar på samma princip, om den vid uppstart frågar efter B, betyder det att du måste ange siffran 192.168.0.0 för nätverket 24/0, och för C = 0.
$EXTERNALIPADDDRESS - dedikerad adress från leverantören.
$EXTERNALIPROUTE - standardväg till nätverk 0.0.0.0/0
$BWorknets - Arbetsnätverk, i vårt exempel kommer det att finnas 168
$CWorknets - Fungerande nätverk, i vårt exempel kommer detta 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 klienter - Endast internetåtkomst, 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, vilket betyder 19
$CVPNCLIENTS - VPN-nätverk för små filialer, vilket betyder 255
$NAMEROUTER - routernamn
$ServerCertificate - namnet på certifikatet som du tidigare importerade
$infile — Ange sökvägen till filen från vilken vi ska läsa konfigurationen, till exempel D:config.txt (helst den engelska sökvägen utan citattecken och mellanslag)
$outfile — ange sökvägen där den ska sparas, till exempel D:MT-test.txt
Jag har medvetet ändrat adresserna i exemplen av förklarliga skäl.
Jag missade poängen med att upptäcka attacker och avvikande beteende - det här förtjänar en separat artikel. Men det är värt att påpeka att i den här kategorin kan du använda övervakningsdatavärden från Zabbix + bearbetade curldata från elasticsearch.
Vilka punkter bör du vara uppmärksam på:
- Nätverksplan. Det är bättre att komponera det omedelbart i en läsbar form. Excel räcker. Tyvärr ser jag väldigt ofta att nätverk byggs enligt principen "En ny filial har dykt upp, här är /24 för dig." Ingen räknar ut hur många enheter som förväntas på en given plats eller om det kommer att bli ytterligare tillväxt. Till exempel öppnade en liten butik där det från början stod klart att enheten inte skulle vara mer än 10, varför tilldela /24? För stora filialer, tvärtom, allokerar de /24, och det finns 500 enheter - du kan helt enkelt lägga till ett nätverk, men du vill tänka igenom allt på en gång.
- Filtreringsregler. Om projektet förutsätter att det blir separation av nätverk och maximal segmentering. Bästa praxis förändras över tid. Tidigare var ett PC-nätverk och ett skrivarnät uppdelat, men nu är det helt normalt att inte dela upp dessa nätverk. Det är värt att använda sunt förnuft och inte skapa många subnät där de inte behövs och inte kombinera alla enheter till ett nätverk.
- "Gyllene" inställningar på alla routrar. De där. om du har bestämt dig för en plan. Det är värt att förutse allt direkt och försöka se till att alla inställningar är identiska - bara adresslistan och IP-adresserna är olika. Om problem uppstår blir felsökningstiden kortare.
- Organisatoriska frågor är inte mindre viktiga än tekniska. Ofta utför lata anställda dessa rekommendationer "manuellt", utan att använda färdiga konfigurationer och skript, vilket i slutändan leder till problem från ingenstans.
Genom dynamisk routing. OSPF med zonindelning användes. Men det här är en testbänk; det är mer intressant att ställa upp sådana saker i stridsförhållanden.
Jag hoppas att ingen är upprörd över att jag inte postade routerns konfigurationer. Jag tror att länkarna räcker och då beror allt på kraven. Och såklart tester, fler tester behövs.
Jag önskar alla att förverkliga sina projekt under det nya året. Må åtkomsten vara med dig!!!
Källa: will.com