Hallo allemaal. Dit artikel is bedoeld voor degenen die veel MikroTik-apparaten in hun netwerk hebben en maximale uniformiteit wensen, zodat ze niet voor elk apparaat afzonderlijk hoeven in te loggen. In dit artikel beschrijf ik een project dat, helaas, niet de operationele fase heeft bereikt vanwege menselijke factoren. In het kort: meer dan 200 routers, snelle configuratie en training van personeel, uniformiteit per regio, netwer filtratie en specifieke hosts, de mogelijkheid om eenvoudig regels voor alle apparaten toe te voegen, logging en toegangscontrole.
Wat hieronder beschreven wordt, pretendeert geen kant-en-klaar geval te zijn, maar ik hoop dat het je helpt bij het plannen van je netwerken en het minimaliseren van fouten. Sommige punten en oplossingen kunnen je misschien niet helemaal juist lijken – als dat zo is, laat dan een commentaar achter. Critiek in dit geval zal als ervaring worden toegevoegd aan de verzameling. Dus lezer, kijk in de reacties, misschien heeft de auteur een grote fout gemaakt – de gemeenschap zal helpen.
Aantal routers 200-300, verspreid over verschillende steden met verschillende kwaliteit van internetverbindingen. Het is noodzakelijk om alles mooi te organiseren en lokaal de beheerders duidelijk uit te leggen hoe alles zal werken.
Dus, waar begint elk project? Natuurlijk met Vereisten.
- Het organiseren van het netwerkplan voor alle vestigingen volgens de eisen van de klant, netwerksegmentatie (van 3 tot 20 netwerken in filialen afhankelijk van het aantal apparaten).
- Configuratie van apparaten in elke vestiging. Controle van de daadwerkelijke doorvoersnelheid van de provider onder verschillende werkomstandigheden.
- Organisatie van beveiliging van de apparaten, beheer via een witte lijst, automatische detectie van aanvallen met automatische opname in de zwarte lijst voor een bepaalde periode, minimalisering van het gebruik van verschillende technische middelen die worden gebruikt om de beheertoegang te onderscheppen en afzien van onderhoud.
- Organisatie van beveiligde VPN-verbindingen met filtering volgens de eisen van de klant. Minimaal 3 VPN-verbindingen van elke vestiging naar het centrum.
- Op basis van punten 1 en 2. Kies de optimale manieren om failover VPN-netwerken op te zetten. De uitvoerder kan, bij correcte onderbouwing, de technologie voor dynamische routering kiezen.
- Organisatie van het prioriteren van verkeer op basis van protocollen, poorten, hosts en andere specifieke services die door de klant worden gebruikt. (VOIP, hosts met belangrijke diensten)
- Organisatie van monitoring en logging van routerevents voor de respons van technische ondersteuning medewerkers.
Zoals we begrijpen, wordt in sommige gevallen het technische ontwerp op basis van vereisten opgesteld. Deze vereisten heb ik zelf geformuleerd, door naar de belangrijkste problemen te luisteren. Ik hield rekening met de mogelijkheid dat iemand anders deze punten misschien zou aanpakken.
Welke tools zullen worden gebruikt om aan deze vereisten te voldoen:
- ELK-stack (na enige tijd kwam de realisatie dat in plaats van logstash fluentd zal worden gebruikt).
- Ansible. Voor gebruiksgemak in administratie en toegangsbeheer zullen we AWX gebruiken.
- GITLAB. Hier is geen uitleg nodig. Wat zouden we zonder versiecontrole van onze configuraties doen.
- PowerShell. Er komt een eenvoudig script voor de initiële generatie van de configuratie.
- Dokuwiki, voor het schrijven van documentatie en handleidingen. In dit geval gebruiken we habr.com.
- Monitoring zal plaatsvinden via zabbix. Daar zal ook een schema van verbindingen worden getekend voor algemeen begrip.
Aspecten van de EFK-configuratie
Bij het eerste punt beschrijf ik alleen de ideologie waarop de indices zullen worden opgebouwd. Er zijn veel
geweldige artikelen over de configuratie en ontvangst van logs van apparaten die worden beheerd door mikrotik.
Ik zal stilstaan bij enkele punten:
1. Volgens het schema moet er worden nagedacht over het ontvangen van logs uit verschillende bronnen en via verschillende poorten. Hiervoor zullen we een logaggregator gebruiken. We willen ook universele grafieken maken voor alle routers met de mogelijkheid om toegang te scheiden. Dan bouwen we de indices als volgt op:
dit is een stuk configuratie met fluentd type elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts :9200
port 9200
Op deze manier kunnen we routers samenvoegen en segmenteren volgens het plan - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Waarom zo ingewikkeld maken? We begrijpen dat we 200 of meer apparaten zullen hebben. Het is moeilijk om alles te volgen. Met versie 6.8 van elasticsearch zijn beveiligingsinstellingen beschikbaar (zonder licentie aankoop), waardoor we toegangsrechten kunnen verdelen tussen technische ondersteuning medewerkers of lokale systeembeheerders.
Tabellen en grafieken – hier moeten we gewoon overeenkomen: of we gebruiken uniforme stijlen of iedereen doet het zoals het hem uitkomt.
2. Over logging. Als we logging inschakelen in de firewallregels, maken we namen zonder spaties. Het is duidelijk dat, door een eenvoudige configuratie in fluentd te gebruiken, we gegevens kunnen filteren en handige dashboards kunnen maken. Op de afbeelding hieronder – mijn thuisrouter.
3. Over de gebruikte ruimte en logs. Gemiddeld, bij 1000 berichten per uur, nemen logs 2-3 MB per dag in beslag, wat, laten we eerlijk zijn, niet veel is. Versie elasticsearch 7.5.
ANSIBLE.AWX
Gelukkig hebben we een kant-en-klaar module voor routeros.
Ik heb het over AWX genoemd, maar de onderstaande commando's zijn alleen voor Ansible in zijn pure vorm – ik denk dat voor degenen die met Ansible gewerkt hebben, er geen problemen zullen zijn met het gebruik via de GUI van AWX.
Ik moet eerlijk zeggen, daarvoor heb ik naar andere gidsen gekeken waar SSH werd gebruikt, en iedereen had verschillende problemen met responstijden en nog veel meer. Ik herhaal, het kwam niet verder dan een testomgeving met 20 routers.
We moeten een certificaat of account gebruiken. Hierin moet u beslissen, ik verkies certificaten. Een klein, maar belangrijk punt over de rechten. Ik geef schrijfrechten – zelfs een ‘reset config’ kan dan niet uitgevoerd worden.
Wat betreft het genereren, kopiëren van het certificaat en importeren, daar zouden geen problemen mee moeten zijn:
Kort overzicht van de commando'sOp uw pc
ssh-keygen -t RSA, beantwoord de vragen, sla de sleutel op.
Kopiëren naar Mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Eerst moet er een account worden aangemaakt en deze moet de juiste rechten krijgen.
Controleer de verbinding met het certificaat
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120
Schrijf 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
En hier een voorbeeld van een playbook: - name: add_work_sites
hosts: testmt
serial: 1
connection: network_cli
remote_user: mikrotik.west
gather_facts: yes
taken:
- name: 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
Zoals te zien is uit de bovenstaande configuratie, is het samenstellen van uw eigen playbook niet moeilijk. Het is voldoende om de CLI van Mikrotik goed onder de knie te krijgen. Stel je een situatie voor waarin op alle routers de address list met specifieke gegevens moet worden verwijderd, dan:
Zoeken en verwijderen./ip firewal address-list remove [find where list=«gov.ru»]
Ik heb hier opzettelijk niet de hele firewall-lijst ingevoegd, omdat deze voor elk project uniek zal zijn. Maar één ding kan ik met zekerheid zeggen: gebruik alleen de adressenlijst.
Over GITLAB is alles duidelijk. Ik zal hier niet verder op ingaan. Alles is mooi verdeeld over aparte taken, sjablonen en handlers.
Powershell
Er zullen hier 3 bestanden zijn. Waarom Powershell? Je kunt elke tool voor het genereren van configuraties kiezen, afhankelijk van wat het handigst is. In dit geval heeft iedereen Windows op zijn pc staan, dus waarom op bash doen als Powershell handiger is? Gebruik gewoon wat voor jou het prettigst is.
Hier is het script zelf (eenvoudig en begrijpelijk):[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
Excuses, ik kan niet alle regels delen omdat dat niet mooi zou zijn. Je kunt zelf regels opstellen, gebaseerd op de beste praktijken.
Bijvoorbeeld, hier is een lijst met links waar ik me aan heb gehouden::Securing_Your_Router
:IP/Firewall/Filter
:OSPF-examples
:Winbox
:Upgrading_RouterOS
:IP/Fasttrack — hier moet je weten dat wanneer fasttrack is ingeschakeld, prioriteitsregels en traffic shaping niet zullen werken - handig voor zwakke apparaten.
Symbolen voor de variabelen:De volgende netwerken zijn als voorbeeld genomen:
192.168.0.0/24 werknet
172.22.4.0/24 VOIP netwerk
10.0.0.0/24 netwerk voor klanten zonder toegang tot het lokale netwerk
192.168.255.0/24 VPN netwerk voor grote filialen
172.19.255.0/24 VPN netwerk voor kleintjes
Het netwerkadres bestaat uit 4 decimale cijfers, overeenkomstig A.B.C.D, op dezelfde manier werkt de vervanging; als het bij het starten om B vraagt, moet je voor het netwerk 192.168.0.0/24 het nummer 0 invoeren, en voor C = 0.
$EXTERNALIPADDRESS — het toegewezen adres van de provider.
$EXTERNALIPROUTE — de standaardroute naar netwerk 0.0.0.0/0
$BWorknets — Werknet, in ons voorbeeld hier is dat 168
$CWorknets — Werknet, in ons voorbeeld hier is dat 0
$BVoipNets — VOIP-netwerk in ons voorbeeld hier 22
$CVoipNets — VOIP-netwerk in ons voorbeeld hier 4
$CClientss — Netwerk voor klanten – toegang alleen tot internet, in ons geval hier 0
$BVPNWORKs — VPN-netwerk voor grote filialen, in ons voorbeeld 20
$CVPNWORKs — VPN-netwerk voor grote filialen, in ons voorbeeld 255
$BVPNCLIENTS — VPN-netwerk voor kleine filialen, dus 19
$CVPNCLIENTS — VPN-netwerk voor kleine filialen, dus 255
$NAMEROUTER — naam van de router
$ServerCertificate — naam van het certificaat dat u van tevoren importeert
$infile — Geef het pad op naar het bestand waarvan we de configuratie gaan lezen, bijvoorbeeld D:config.txt (bij voorkeur een Engels pad zonder aanhalingstekens en spaties)
$outfile — geef het pad op waar u het wilt opslaan, bijvoorbeeld D:MT-test.txt
Ik heb de adressen in de voorbeelden opzettelijk gewijzigd om begrijpelijke redenen.
Ik heb het punt over het detecteren van aanvallen en abnormaal gedrag overgeslagen – dit verdient een apart artikel. Maar het is vermeldenswaard dat in deze categorie gegevens van monitoring met Zabbix + verwerkte curl-gegevens met Elasticsearch kunnen worden gebruikt.
Op welke punten moet aandacht worden besteed:
- Netwerkplannen. Het is beter om het onmiddellijk in een leesbare vorm op te stellen. Excel is hiervoor voldoende. Helaas zie ik erg vaak dat netwerken worden samengesteld naar het principe 'Er is een nieuw filiaal, hier is je /24'. Niemand onderzoekt hoeveel apparaten er in deze plaats worden verwacht en of er verdere groei zal zijn. Bijvoorbeeld, er is een kleine winkel geopend, waar van tevoren duidelijk is dat er niet meer dan 10 apparaten zullen zijn, waarom dan een /24 toewijzen? Bij grote filialen is het omgekeerde het geval, ze wijzen /24 toe en er zijn 500 apparaten – het is eenvoudig een netwerk toe te voegen, maar het is beter om alles meteen goed te plannen.
- Filterregels. Als het project voorziet in netwerksegmentatie en maximale segmentatie. Best practices veranderen in de loop der tijd. Eerder werd het netwerk van pc's gescheiden van het netwerk van printers, nu is het volkomen normaal om deze netwerken niet te scheiden. Gebruik gezond verstand en vermijd het creëren van talloze subnetten waar ze niet nodig zijn en combineer niet alle apparaten in één netwerk.
- "Gouden" instellingen op alle routers. Dat wil zeggen, als u eenmaal met het plan bent gekomen, zorg er dan voor dat u alles voorziet en probeer ervoor te zorgen dat alle instellingen identiek zijn – alleen de address lists en IP-adressen zijn verschillend. In geval van problemen zal de tijd voor troubleshooting minder zijn.
- Organisatorische punten zijn net zo belangrijk als technische. Vaak voeren luie medewerkers de gegeven aanbevelingen ‘handmatig’ uit, zonder gebruik te maken van kant-en-klare configuraties en scripts, wat uiteindelijk leidt tot problemen uit het niets.
Over dynamische routering. OSPF werd gebruikt met zone-delingen. Maar dit is een testomgeving, in real-life situaties is het interessanter om zulke dingen in te stellen.
Ik hoop dat niemand teleurgesteld is dat ik de routerconfiguraties niet heb gepost. Ik denk dat links meer dan voldoende zijn, en verder hangt alles af van de eisen. En natuurlijk testen, meer testen is noodzakelijk.
Ik wens iedereen in het nieuwe jaar succes met het realiseren van hun projecten. Moge de access granted met jullie zijn!!!
Bron: habr.com
