Mein unrealisiertes Projekt. Netzwerk aus 200 MikroTik-Routern.

Hallo zusammen. Dieser Artikel richtet sich an diejenigen, die viele MikroTik-Geräte im Einsatz haben und eine maximale Vereinheitlichung wünschen, um sich nicht mit jedem einzelnen Gerät verbinden zu müssen. In diesem Artikel beschreibe ich ein Projekt, das leider aufgrund menschlicher Faktoren nicht in die Praxis umgesetzt wurde. Kurz gesagt: über 200 Router, schnelle Einrichtung und Schulung des Personals, Vereinheitlichung nach Regionen, Netzwerkanalyse und bestimmte Hosts, die Möglichkeit, einfach Regeln für alle Geräte hinzuzufügen, Protokollierung und Zugangskontrolle.

Das, was unten beschrieben wird, ist kein fertiger Fall, aber ich hoffe, es wird Ihnen bei der Planung Ihrer Netzwerke und der Minimierung von Fehlern hilfreich sein. Einige Punkte und Lösungen könnten Ihnen nicht ganz richtig erscheinen – wenn ja, schreiben Sie bitte einen Kommentar. Kritik ist in diesem Fall eine wertvolle Erfahrung für die Gemeinschaft. Daher, lieber Leser, schau dir die Kommentare an – vielleicht hat der Autor einen groben Fehler gemacht – die Community wird helfen.

Die Anzahl der Router liegt zwischen 200 und 300, verteilt auf verschiedene Städte mit unterschiedlichen Internetverbindungen. Es ist notwendig, alles schön zu organisieren und lokalen Administratoren klar zu erklären, wie alles funktionieren wird.

Also, womit beginnt jedes Projekt? Natürlich mit Technische Anforderungen.

1. Der Organisation des Netzwerkplans für alle Filialen gemäß den Anforderungen des Auftraggebers, der Segmentierung der Netzwerke (von 3 bis 20 Netzwerken in den Filialen, abhängig von der Anzahl der Geräte).
2. Einrichtung der Geräte in jeder Filiale. Überprüfung der tatsächlichen Bandbreite des Providers unter verschiedenen Betriebsbedingungen.
3. Organisation des Schutzes der Geräte, Verwaltung über eine Whitelist, automatisierte Erkennung von Angriffen mit automatischer Eintragung in die Blacklist für einen bestimmten Zeitraum, Minimierung der Verwendung verschiedener technischer Mittel, die zur Abfangung des Zugriffs auf die Verwaltung verwendet werden, und Vermeidung von Wartungsausfällen.
4. Einrichtung sicherer VPN-Verbindungen mit Netzfilterung gemäß den Anforderungen des Auftraggebers. Mindestens 3 VPN-Verbindungen von jeder Filiale zum Hauptsitz.
5. Basierend auf Punkt 1, 2. Wählen Sie die optimalen Wege für den Aufbau ausfallsicherer VPNs. Die Technologie der dynamischen Routenwahl kann vom Ausführenden bei adäquater Begründung gewählt werden.
6. Organisation der Priorisierung des Verkehrs nach Protokollen, Ports, Hosts und anderen spezifischen Diensten, die der Kunde verwendet. (VOIP, Hosts mit wichtigen Diensten)
7. Organisation der Überwachung und Protokollierung von Ereignissen in Routern zur Reaktion des technischen Supports.

Wie wir verstehen, wird in einigen Fällen das Pflichtenheft aus den Anforderungen erstellt. Diese Anforderungen habe ich selbst formuliert, nachdem ich die Hauptprobleme gehört habe. Ich hatte die Möglichkeit in Betracht gezogen, dass die Umsetzung dieser Punkte von jemand anderem übernommen werden könnte.

Welche Tools werden zur Umsetzung dieser Anforderungen verwendet:

1. ELK-Stack (nach einiger Zeit kam das Verständnis, dass anstelle von logstash fluentd verwendet wird).
2. Ansible. Zur Erleichterung der Verwaltung und Trennung des Zugriffs werden wir AWX verwenden.
3. GITLAB. Hier bedarf es keiner weiteren Erklärung. Wo kämen wir hin ohne Versionskontrolle unserer Konfigurationen.
4. PowerShell. Es wird ein einfaches Skript zur ursprünglichen Generierung der Konfiguration geben.
5. Dokuwiki, zur Erstellung von Dokumentationen und Handbüchern. In diesem Fall verwenden wir habr.com.
6. Die Überwachung erfolgt über zabbix. Dort wird auch das Verbindungsdiagramm zur allgemeinen Verständnis dargestellt.

Einstellungen für EFK

Zu Punkt eins werde ich nur die Ideologie beschreiben, nach der die Indizes aufgebaut werden. Es gibt viele
wunderbare Artikel zur Konfiguration und zum Empfang von Protokollen von Geräten unter mikrotik.

Ich werde auf einige Punkte eingehen:

1. Entsprechend dem Diagramm sollte der Empfang von Protokollen aus verschiedenen Orten und über verschiedene Ports durchdacht werden. Dazu werden wir einen Protokollaggregator verwenden. Außerdem möchten wir universelle Grafiken für alle Router mit der Möglichkeit der Zugangstrennung erstellen. Dann bauen wir die Indizes wie folgt auf:

Das ist ein Ausschnitt der Konfiguration mit fluentd type elasticsearch
logstash_format true
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hosts elasticsearch:9200
port 9200

Auf diese Weise können wir Router zusammenfassen und gemäß dem Plan segmentieren - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Warum es so kompliziert machen? Wir verstehen, dass wir 200 oder mehr Geräte haben werden. Da kann man nicht alles im Auge behalten. Ab Version 6.8 von elasticsearch stehen uns Sicherheitskonfigurationen (ohne Kauf einer Lizenz) zur Verfügung, sodass wir die Zugriffsrechte zwischen den Mitarbeitern des technischen Supports oder lokalen Systemadministratoren verteilen können.
Tabellen und Grafiken – hier muss man einfach entscheiden – entweder gleichförmige verwenden oder jeder macht es so, wie es ihm passt.

2. Zur Protokollierung. Wenn wir in den Firewall-Regeln das Logging aktivieren, verwenden wir Namen ohne Leerzeichen. Man erkennt, dass wir mit einer einfachen Konfiguration in Fluentd Daten filtern und bequeme Dashboard erstellen können. Im Bild unten – mein Heimrouter.

3. Zum Speicher- und Logbedarf. Im Durchschnitt benötigen Logs bei 1000 Nachrichten pro Stunde etwa 2-3 MB pro Tag, was, seien wir ehrlich, nicht viel ist. Version Elasticsearch 7.5.

ANSIBLE.AWX

Zu unserem Glück haben wir ein fertiges Modul für RouterOS.
Ich habe zwar über AWX gesprochen, jedoch beziehen sich die folgenden Befehle nur auf reines Ansible – ich denke, für diejenigen, die mit Ansible gearbeitet haben, wird es keine Probleme bei der Nutzung über die AWX-GUI geben.

Ich muss ehrlich zugeben, dass ich zuvor andere Anleitungen angesehen habe, in denen SSH verwendet wurde, und alle hatten unterschiedliche Probleme mit der Antwortzeit und noch viele andere Probleme. Wiederhole, es kam nicht zu einem Kampf, empfindet diese Informationen als Experiment, das nicht über den Stand von 20 Routern hinausgegangen ist.

Wir müssen ein Zertifikat oder ein Konto verwenden. Hier entscheiden Sie, ich bin für Zertifikate. Ein gewisser feiner Punkt bezüglich der Berechtigungen. Ich gebe Schreibrechte – selbst die "Reset-Config"-Option zu verwenden wird nicht möglich sein.

Bei der Generierung, Kopie des Zertifikats und dessen Import sollte es keine Probleme geben:

Kurz zum Listing der Befehle.Auf Ihrem PC
ssh-keygen -t RSA, beantworten Sie die Fragen und speichern Sie den Schlüssel.
Kopieren auf Mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Vorab muss ein Konto erstellt und ihm Berechtigungen zugewiesen werden.
Überprüfen Sie die Verbindung über das Zertifikat.
ssh -p 49475 -i /keys/mtx ansible@192.168.0.120

Bearbeiten Sie 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

Und hier ein Beispiel-Playbook: --- name: add_work_sites
hosts: testmt
serial: 1
connection: network_cli
remote_user: mikrotik.west
gather_facts: yes
tasks:
--- 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

Wie aus der oben dargestellten Konfiguration hervorgeht, ist die Erstellung eigener Playbooks keine schwierige Aufgabe. Es genügt, sich gut mit der CLI von Mikrotik auszukennen. Angenommen, es muss auf allen Routern die Address List mit bestimmten Daten entfernt werden, dann:

Finden und löschen./ip firewal address-list remove [find where list=«gov.ru»]

Ich habe absichtlich nicht die gesamte Firewall-Liste eingefügt, da sie für jedes Projekt individuell sein wird. Aber eines kann ich mit Sicherheit sagen: Benutzen Sie nur die Adressliste.

Bei GITLAB ist alles klar. Ich werde an diesem Punkt nicht verweilen. Alles ist übersichtlich in separaten Aufgaben, Vorlagen und Bearbeitungen.

Powershell

Hier werden 3 Dateien sein. Warum PowerShell? Man kann jedes beliebige Werkzeug zur Generierung von Konfigurationen wählen, je nachdem, was einem am angenehmsten ist. In diesem Fall haben alle Windows auf dem PC, also warum Bash, wenn PowerShell bequemer ist? Jeder wie er mag.

Hier ist das Skript selbst (einfach und verständlich):[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

Bitte entschuldigen Sie mich, ich kann nicht alle Regeln veröffentlichen, da das nicht ganz angemessen wäre. Sie können die Regeln selbst auf Basis der besten Praktiken erstellen.

Hier ist beispielsweise eine Liste von Links, an denen ich mich orientiert habe: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 - hier muss man wissen, dass beim Aktivieren von Fasttrack die Regeln zur Priorisierung und Bandbreitenkontrolle nicht funktionieren – nützlich für schwache Geräte.

Bezeichnungen für die Variablen:Als Beispiel wurden die folgenden Netzwerke verwendet:
192.168.0.0/24 internes Netzwerk
172.22.4.0/24 VOIP-Netzwerk
10.0.0.0/24 Netzwerk für Kunden ohne Zugang zum lokalen Netzwerk
192.168.255.0/24 VPN-Netzwerk für große Zweigstellen
172.19.255.0/24 VPN-Netzwerk für kleine Zweigstellen

Die Netzwerkadresse besteht aus 4 Dezimalzahlen, entsprechend A.B.C.D; nach dem gleichen Prinzip funktioniert die Ersetzung. Wenn beim Starten nach B gefragt wird, bedeutet das, dass für das Netzwerk 192.168.0.0/24 die Nummer 0 eingegeben werden muss, und für C = 0.
$EXTERNALIPADDRESS - eine von dem Anbieter zugewiesene Adresse.
$EXTERNALIPROUTE - Standardroute für das Netzwerk 0.0.0.0/0
$BWorknets - internes Netzwerk, in unserem Beispiel wird hier 168 stehen
$CWorknets - internes Netzwerk, in unserem Beispiel wird hier 0 stehen
$BVoipNets — VOIP-Netzwerk in unserem Beispiel hier 22
$CVoipNets — VOIP-Netzwerk in unserem Beispiel hier 4
$CClientss — Netzwerk für Kunden – Zugang nur zum Internet, in unserem Fall hier 0
$BVPNWORKs — VPN-Netzwerk für große Filialen, in unserem Beispiel 20
$CVPNWORKs — VPN-Netzwerk für große Filialen, in unserem Beispiel 255
$BVPNCLIENTS — VPN-Netzwerk für kleine Filialen, also 19
$CVPNCLIENTS — VPN-Netzwerk für kleine Filialen, also 255
$NAMEROUTER — Name des Routers
$ServerCertificate — Name des Zertifikats, das vorher importiert wird
$infile — Den Pfad zur Datei angeben, von der wir die Konfiguration lesen, z.B. D:config.txt (am besten einen englischen Pfad ohne Anführungszeichen und Leerzeichen)
$outfile — Den Pfad angeben, wo gespeichert werden soll, z.B. D:MT-test.txt

Ich habe die Adressen in den Beispielen aus verständlichen Gründen absichtlich geändert.

Ich habe den Punkt zur Erkennung von Angriffen und abnormalem Verhalten ausgelassen – das verdient einen eigenen Artikel. Es sei jedoch darauf hingewiesen, dass in dieser Kategorie die Monitoring-Daten von Zabbix + die verarbeiteten Daten von curl mit Elasticsearch verwendet werden können.

Auf welche Punkte sollte besondere Aufmerksamkeit gerichtet werden:

1. Netzwerkplan. Es ist besser, ihn gleich in lesbarer Form zu erstellen. Excel reicht vollkommen aus. Leider sehe ich sehr oft, dass Netzwerke nach dem Prinzip „Es gibt eine neue Filiale, hier ist eure /24“ erstellt werden. Niemand klärt, wie viele Geräte an diesem Ort erwartet werden und ob ein zukünftiges Wachstum stattfinden wird. Zum Beispiel wurde ein kleiner Laden eröffnet, in dem von Anfang an klar ist, dass es nicht mehr als 10 Geräte geben wird, warum dann eine /24 zuweisen? Bei großen Filialen wird im Gegenteil eine /24 zugewiesen, aber es gibt 500 Geräte – man kann einfach ein Netzwerk hinzufügen, aber es möchte ja alles gleich von Anfang an durchdacht sein.
2. Filterregeln. Wenn im Projekt vorgesehen ist, dass es Netzwerktrennungen und maximale Segmentierung geben wird. Best Practices ändern sich im Laufe der Zeit. Früher wurde das Netzwerk von PCs und das Netzwerk von Druckern getrennt, jetzt ist es durchaus normal, diese Netzwerke nicht zu teilen. Man sollte gesunden Menschenverstand nutzen und nicht unnötig viele Subnetze dort schaffen, wo sie nicht gebraucht werden, und nicht alle Geräte in ein Netzwerk zusammenfassen.
3. Die „Gold“-Einstellungen auf allen Routern. D.h. wenn Sie sich mit dem Plan einig sind, sollten Sie alles gleich von Anfang an berücksichtigen und versuchen, alle Einstellungen identisch zu machen – nur die address list und die IP-Adressen sollten unterschiedlich sein. Im Falle von Problemen sollte die Zeit für die Fehlersuche kürzer sein.
4. Organisatorische Aspekte sind ebenso wichtig wie technische. Oft führen träge Mitarbeiter die angegebenen Empfehlungen "manuell" aus, ohne vorhandene Konfigurationen und Skripte zu verwenden, was letztendlich zu Problemen führt, die vermeidbar wären.

Zur dynamischen Routenführung. Es wurde OSPF mit zonaler Unterteilung verwendet. Aber das ist schließlich eine Testumgebung; unter Produktionsbedingungen ist es interessanter, solche Dinge einzurichten.

Ich hoffe, niemand ist enttäuscht, dass ich die Routerkonfigurationen nicht veröffentlicht habe. Ich denke, dass die Links vollkommen ausreichen, und alles Weitere hängt von den Anforderungen ab. Und natürlich die Tests; wir brauchen mehr Tests.

Ich wünsche allen im neuen Jahr, dass sie ihre Projekte umsetzen. Möge der Zugang gewährt sein!!!

Quelle: habr.com