Mijn onvoltooide project. Netwerk van 200 MikroTik-routers

Mijn onvoltooide project. Netwerk van 200 MikroTik-routers

Dag Allemaal. Dit artikel is bedoeld voor degenen die veel Mikrotik-apparaten in het park hebben en die maximale eenwording willen maken om niet met elk apparaat afzonderlijk verbinding te maken. In dit artikel zal ik een project beschrijven dat helaas vanwege menselijke factoren niet de gevechtsomstandigheden heeft bereikt. Kortom: meer dan 200 routers, snelle setup en training van personeel, unificatie per regio, filteren van netwerken en specifieke hosts, de mogelijkheid om eenvoudig regels toe te voegen aan alle apparaten, logging en toegangscontrole.

Wat hieronder wordt beschreven, heeft niet de pretentie een kant-en-klaar geval te zijn, maar ik hoop dat het nuttig voor u zal zijn bij het plannen van uw netwerken en het minimaliseren van fouten. Misschien lijken sommige punten en beslissingen u niet helemaal correct - zo ja, schrijf dan in de opmerkingen. Kritiek zal in dit geval een ervaring zijn in een gewone spaarpot. Daarom, lezer, kijk in de commentaren, misschien heeft de auteur een grove fout gemaakt - de gemeenschap zal helpen.

Het aantal routers is 200-300, verspreid over verschillende steden met verschillende kwaliteit van de internetverbinding. Het is nodig om alles mooi te maken en op een toegankelijke manier uit te leggen aan lokale beheerders hoe alles zal werken.

Dus waar begint elk project? Natuurlijk, met TK.

  1. Organisatie van een netwerkplan voor alle filialen volgens de wensen van de klant, netwerksegmentatie (van 3 tot 20 netwerken in filialen, afhankelijk van het aantal toestellen).
  2. Stel apparaten in elke vestiging in. De echte bandbreedte van de provider controleren in verschillende werkomstandigheden.
  3. Organisatie van apparaatbeveiliging, whitelist-controle, automatische detectie van aanvallen met automatische blacklisting gedurende een bepaalde periode, minimalisering van het gebruik van verschillende technische middelen die worden gebruikt om controletoegang en denial of service te onderscheppen.
  4. Organisatie van beveiligde vpn-verbindingen met netwerkfiltering volgens de eisen van de klant. Minimaal 3 vpn verbindingen van elke vestiging naar het centrum.
  5. Gebaseerd op punten 1, 2. Kies de beste manieren om fouttolerante vpn te bouwen. De dynamische routeringstechniek kan, met de juiste onderbouwing, door de opdrachtnemer worden gekozen.
  6. Organisatie van verkeersprioritering door protocollen, poorten, hosts en andere specifieke diensten die de klant gebruikt. (VOIP, hosts met belangrijke services)
  7. Organisatie van monitoring en logging van routergebeurtenissen voor de reactie van technisch ondersteunend personeel.

Zoals we begrijpen, wordt de TOR in sommige gevallen samengesteld uit de vereisten. Deze eisen heb ik zelf geformuleerd, nadat ik naar de belangrijkste problemen had geluisterd. Hij gaf de mogelijkheid toe dat iemand anders de uitvoering van deze punten op zich zou kunnen nemen.

Welke tools zullen worden gebruikt om aan deze vereisten te voldoen:

  1. ELK-stack (na enige tijd werd begrepen dat fluentd zou worden gebruikt in plaats van logstash).
  2. Ansible. Om het beheer en het delen van toegang te vergemakkelijken, gebruiken we AWX.
  3. GITLAB. Het is niet nodig om hier uitleg te geven. Waar zonder versiebeheer van onze configuraties.
  4. PowerShell. Er zal een eenvoudig script zijn voor de eerste generatie van het config.
  5. Doku wiki, voor het schrijven van documentatie en handleidingen. In dit geval gebruiken we habr.com.
  6. Monitoring zal worden gedaan via zabbix. Er zal ook een aansluitschema zijn voor een algemeen begrip.

EFK-opstellingspunten

Wat het eerste punt betreft, zal ik alleen de ideologie beschrijven waarop de indexen zullen worden gebouwd. Er zijn veel
uitstekende artikelen over het instellen en ontvangen van logboeken van apparaten met mikrotik.

Ik zal bij enkele punten stilstaan:

1. Volgens het schema is het de moeite waard om logs van verschillende plaatsen en op verschillende poorten te ontvangen. Om dit te doen, gebruiken we een log-aggregator. En we willen ook universele graphics maken voor alle routers met de mogelijkheid om toegang te delen. Vervolgens bouwen we de indexen als volgt op:

hier is een stukje configuratie met fluentd elastisch zoeken
logstash_format waar
index_naam mikrotiklogs.north
logstash_prefix mikrotiklogs.north
spoel_interval 10s
hosts elasticsearch: 9200
poort 9200

We kunnen dus routers combineren en segmenteren volgens het plan - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Waarom het zo moeilijk maken? We begrijpen dat we 200 of meer apparaten zullen hebben. Volg niet alles. Sinds versie 6.8 van Elasticsearch zijn beveiligingsinstellingen voor ons beschikbaar (zonder een licentie te kopen), dus kunnen we kijkrechten verdelen tussen technische ondersteuningsmedewerkers of lokale systeembeheerders.
Tabellen, grafieken - hier hoeft u het alleen maar mee eens te zijn - gebruik dezelfde, of iedereen doet het zoals het hem uitkomt.

2. Door in te loggen. Als we inloggen in de firewallregels inschakelen, dan maken we de namen zonder spaties. Het is te zien dat we met behulp van een eenvoudige configuratie in vloeiendd de gegevens kunnen filteren en handige panelen kunnen maken. De onderstaande afbeelding is mijn thuisrouter.

Mijn onvoltooide project. Netwerk van 200 MikroTik-routers

3. Volgens de bezette ruimte en logboeken. Gemiddeld nemen de logs met 1000 berichten per uur 2-3 MB per dag in beslag, wat, zie je, niet zo veel is. elastischezoekversie 7.5.

ANSIBLE.AWX

Gelukkig voor ons hebben we een kant-en-klare module voor routero's
Ik heb gewezen op AWX, maar de onderstaande commando's gaan alleen over weerwoord in zijn puurste vorm - ik denk dat voor degenen die met weerwoord hebben gewerkt, er geen problemen zullen zijn om awx via de gui te gebruiken.

Om eerlijk te zijn, daarvoor keek ik naar andere gidsen waar ze ssh gebruikten, en iedereen had verschillende problemen met responstijd en een heleboel andere problemen. Ik herhaal, het kwam niet tot de strijd , beschouw deze informatie als een experiment dat niet verder ging dan een stand van 20 routers.

We hebben een certificaat of een account nodig. Het is aan jou om te beslissen, ik ben voor certificaten. Een subtiel punt over rechten. Ik geef de rechten om te schrijven - in ieder geval zal "reset config" niet werken.

Er zouden geen problemen moeten zijn met het genereren, kopiëren van het certificaat en het importeren van:

Korte lijst met commando'sOp je pc
ssh-keygen -t RSA, beantwoord vragen, sla de sleutel op.
Kopiëren naar mikrotik:
gebruiker ssh-sleutels import public-key-file=id_mtx.pub user=ansible
Eerst moet u een account aanmaken en er rechten aan toewijzen.
Controle van de verbinding met het certificaat
ssh -p 49475 -i /toetsen/mtx [e-mail beveiligd]

Schrijf vi /etc/ansible/hosts
MT01 ansible_network_os=routers ansible_ssh_port=49475 ansible_ssh_user= ansible
MT02 ansible_network_os=routers ansible_ssh_port=49475 ansible_ssh_user= ansible
MT03 ansible_network_os=routers ansible_ssh_port=49475 ansible_ssh_user= ansible
MT04 ansible_network_os=routers ansible_ssh_port=49475 ansible_ssh_user= ansible

Nou, een voorbeeld van een draaiboek: naam: add_work_sites
gastheren:testmt
serieel: 1
verbinding:netwerk_cli
externe_gebruiker: mikrotik.west
collect_facts: ja
taken:
naam: werk_sites toevoegen
routeros_commando:
commando's:
- /ip firewall adreslijst add address=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
- /ip firewall adreslijst add address=habr.com list=work_sites comment=for_habr

Zoals je aan de bovenstaande configuratie kunt zien, is het samenstellen van je eigen draaiboeken een eenvoudige zaak. Het is voldoende om cli mikrotik goed genoeg onder de knie te krijgen. Stel je een situatie voor waarin je de adreslijst met bepaalde gegevens op alle routers moet verwijderen, dan:

Zoeken en verwijderen/ip firewall adreslijst verwijderen [zoek waar lijst="gov.ru"]

Ik heb hier met opzet niet de volledige lijst met firewalls opgenomen. het zal individueel zijn voor elk project. Maar één ding kan ik zeker zeggen, gebruik alleen de adressenlijst.

Volgens GITLAB is alles duidelijk. Ik zal niet bij dit moment stilstaan. Alles is mooi in termen van individuele taken, sjablonen, handlers.

Powershell

Er zullen 3 bestanden zijn. Waarom powershell? De tool voor het genereren van configuraties kan worden gekozen door iedereen die zich meer op zijn gemak voelt. In dit geval heeft iedereen Windows op zijn pc, dus waarom zou je het op bash doen als powershell handiger is. Wie is comfortabeler.

Het script zelf (eenvoudig en begrijpelijk):[cmdletBinding()] Param(
[Parameter(Verplicht=$true)] [string]$EXTERNALIPADDRESS,
[Parameter(Verplicht=$true)] [tekenreeks]$EXTERNALIPROOUTE,
[Parameter(Verplicht=$true)] [tekenreeks]$BWerknetten,
[Parameter(Verplicht=$true)] [string]$CWorknets,
[Parameter(Verplicht=$true)] [tekenreeks]$BVoipNets,
[Parameter(Verplicht=$true)] [tekenreeks]$CVoipNets,
[Parameter(Verplicht=$true)] [tekenreeks]$CClientss,
[Parameter(Verplicht=$true)] [tekenreeks]$BVPNWORKs,
[Parameter(Verplicht=$true)] [tekenreeks]$CVPNWORKs,
[Parameter(Verplicht=$true)] [string]$BVPNCLIENTSs,
[Parameter(Verplicht=$true)] [tekenreeks]$cVPNCLIENTSs,
[Parameter(Verplicht=$true)] [string]$NAMEROUTER,
[Parameter(Verplicht=$true)] [string]$ServerCertificates,
[Parameter(Verplicht=$true)] [string]$infile,
[Parameter(Verplicht=$true)] [string]$outfile
)

Get-Content $infile | Foreach-Object {$_.Replace("EXTERNIP", $EXTERNALIPADDRESS)} |
Foreach-Object {$_.Replace("EXTROUTE", $EXTERNALIPROOUTE)} |
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-Inhoud $outfile

Neem me niet kwalijk, ik kan niet alle regels opschrijven. het zal niet mooi zijn. U kunt de regels zelf verzinnen, aan de hand van de best practices.

Hier is bijvoorbeeld een lijst met links waar ik me door liet leiden:wiki.mikrotik.com/wiki/Handleiding:Beveiliging_Uw_Router
wiki.mikrotik.com/wiki/Handleiding:IP/Firewall/Filter
wiki.mikrotik.com/wiki/Handleiding:OSPF-voorbeelden
wiki.mikrotik.com/wiki/Drop_port_scanners
wiki.mikrotik.com/wiki/Handleiding:Winbox
wiki.mikrotik.com/wiki/Handleiding:Upgraden_RouterOS
wiki.mikrotik.com/wiki/Handleiding:IP/Fasttrack - hier moet u weten dat wanneer fasttrack is ingeschakeld, de verkeersprioritering en vormgevingsregels niet werken - handig voor zwakke apparaten.

Variabele conventies:De volgende netwerken worden als voorbeeld genomen:
192.168.0.0/24 werkend netwerk
172.22.4.0/24 VOIP-netwerk
10.0.0.0/24 netwerk voor clients zonder LAN-toegang
192.168.255.0/24 VPN-netwerk voor grote vestigingen
172.19.255.0/24 VPN-netwerk voor klein

Het netwerkadres bestaat uit 4 decimale getallen, respectievelijk ABCD, de vervanging werkt volgens hetzelfde principe, als het B vraagt ​​bij het opstarten, dan moet je het getal 192.168.0.0 invoeren voor het netwerk 24/0, en voor C = 0 .
$EXTERNALIPADDRESS - toegewezen adres van de provider.
$EXTERNALIPROOUTE - standaardroute naar netwerk 0.0.0.0/0
$BWorknets - Werkend netwerk, in ons voorbeeld zijn dat er 168
$CWorknets - Werknetwerk, in ons voorbeeld is dit 0
$BVoipNets - VOIP-netwerk in ons voorbeeld hier 22
$CVoipNets - VOIP-netwerk in ons voorbeeld hier 4
$CClientss - Netwerk voor klanten - alleen toegang tot internet, in ons geval hier 0
$BVPNWORKs - VPN-netwerk voor grote vestigingen, in ons voorbeeld 20
$CVPNWORKs - VPN-netwerk voor grote vestigingen, in ons voorbeeld 255
$BVPNCLIENTS - VPN-netwerk voor kleine vestigingen, betekent 19
$CVPNCLIENTS - VPN-netwerk voor kleine vestigingen, betekent 255
$NAMEROUTER - routernaam
$ServerCertificate - de naam van het certificaat dat u als eerste importeert
$infile - Specificeer het pad naar het bestand waaruit we de configuratie zullen lezen, bijvoorbeeld D:config.txt (beter Engels pad zonder aanhalingstekens en spaties)
$outfile - geef het pad op waar moet worden opgeslagen, bijvoorbeeld D:MT-test.txt

Ik heb bewust de adressen in de voorbeelden gewijzigd om voor de hand liggende redenen.

Ik miste het punt over het detecteren van aanvallen en afwijkend gedrag - dit verdient een apart artikel. Maar het is de moeite waard erop te wijzen dat u in deze categorie monitoringgegevenswaarden van Zabbix + uitgewerkte krulgegevens van Elasticsearch kunt gebruiken.

Waarop moet worden gelet:

  1. Netwerkplan. Het is beter om het in een leesbare vorm te schrijven. Exel is genoeg. Helaas zie ik vaak dat netwerken worden samengesteld volgens het principe "Er is een nieuwe tak verschenen, hier is /24 voor jou." Niemand komt erachter hoeveel toestellen er op een bepaalde locatie worden verwacht en of er nog meer groei komt. Er is bijvoorbeeld een kleine winkel geopend, waarin in eerste instantie duidelijk is dat het apparaat niet meer dan 10 zal zijn, waarom / 24 toewijzen? Voor grote vestigingen daarentegen wijzen ze / 24 toe, en er zijn 500 apparaten - je kunt gewoon een netwerk toevoegen, maar je wilt alles meteen doordenken.
  2. Regels voor filteren. Als het project ervan uitgaat dat er sprake is van scheiding van netwerken en maximale segmentatie. Best Practices veranderen in de loop van de tijd. Vroeger deelden ze een pc-netwerk en een printernetwerk, nu is het heel normaal om deze netwerken niet te delen. Het is de moeite waard om gezond verstand te gebruiken en niet veel subnetten te produceren waar ze niet nodig zijn en niet alle apparaten in één netwerk te combineren.
  3. "Gouden" instellingen op alle routers. Die. als je een plan hebt. Het is de moeite waard om alles in één keer te voorzien en te proberen ervoor te zorgen dat alle instellingen identiek zijn - er zijn alleen verschillende adreslijsten en IP-adressen. In geval van problemen zal de tijd voor het debuggen korter zijn.
  4. Organisatorische aspecten zijn niet minder belangrijk dan technische. Vaak volgen luie medewerkers deze aanbevelingen ‘handmatig’ op, zonder gebruik te maken van kant-en-klare configuraties en scripts, wat uiteindelijk vanaf nul tot problemen leidt.

Door dynamische routing. OSPF met zonering werd gebruikt. Maar dit is een testbank, in gevechtsomstandigheden zijn dergelijke dingen interessanter om op te zetten.

Ik hoop dat niemand boos was dat ik de configuratie van de routers niet heb gepost. Ik denk dat links voldoende zullen zijn, en dan hangt het allemaal af van de vereisten. En natuurlijk testen, er zijn meer testen nodig.

Ik wens dat iedereen zijn projecten in het nieuwe jaar realiseert. Moge de verleende toegang bij u zijn !!!

Bron: www.habr.com

Voeg een reactie