Mon projet non réalisé. Réseau de 200 routeurs MikroTik

Mon projet non réalisé. Réseau de 200 routeurs MikroTik

Salut tout le monde. Cet article est destiné à ceux qui possèdent de nombreux appareils Mikrotik dans leur flotte, et qui souhaitent réaliser une unification maximale afin de ne pas se connecter à chaque appareil séparément. Dans cet article, je décrirai un projet qui, malheureusement, n'a pas atteint les conditions de combat en raison de facteurs humains. En bref : plus de 200 routeurs, une configuration et une formation du personnel rapides, ununification par région, filtrage des réseaux et des hôtes spécifiques, possibilité d'ajouter facilement des règles à tous les appareils, journalisation et contrôle d'accès.

Ce qui est décrit ci-dessous ne prétend pas être un cas tout fait, mais j'espère qu'il vous sera utile pour planifier vos réseaux et minimiser les erreurs. Peut-être que certains points et solutions ne vous semblent pas tout à fait corrects - si c'est le cas, écrivez dans les commentaires. La critique dans ce cas sera une expérience pour le trésor commun. Par conséquent, lecteur, jetez un œil aux commentaires, peut-être que l'auteur a commis une grave erreur - la communauté vous aidera.

Le nombre de routeurs est de 200 à 300, répartis dans différentes villes avec des connexions Internet de différentes qualités. Il est nécessaire de tout faire magnifiquement et d'expliquer clairement aux administrateurs locaux comment tout fonctionnera.

Alors, où commence un projet ? Bien sûr, avec TK.

  1. Organisation d'un plan réseau pour toutes les agences selon les besoins clients, segmentation du réseau (de 3 à 20 réseaux en agences selon le nombre d'appareils).
  2. Mise en place des appareils dans chaque branche. Vérification de la vitesse de débit réelle du fournisseur dans différentes conditions de fonctionnement.
  3. Organisation de la protection des appareils, gestion des listes blanches, détection automatique des attaques avec liste noire automatique pendant une certaine période, minimisant l'utilisation de divers moyens techniques utilisés pour intercepter le contrôle d'accès et refuser le service.
  4. Organisation de connexions VPN sécurisées avec filtrage réseau selon les exigences du client. Minimum 3 connexions VPN de chaque succursale vers le centre.
  5. Sur la base des points 1, 2. Sélectionnez les moyens optimaux pour créer des VPN tolérants aux pannes. Si cela est correctement justifié, la technologie de routage dynamique peut être choisie par l'entrepreneur.
  6. Organisation de la priorisation du trafic par protocoles, ports, hôtes et autres services spécifiques utilisés par le client. (VOIP, hébergeurs avec services importants)
  7. Organisation de la surveillance et de la journalisation des événements du routeur pour la réponse du personnel d'assistance technique.

Comme nous le comprenons, dans un certain nombre de cas, les spécifications techniques sont établies en fonction des exigences. J'ai formulé moi-même ces exigences, après avoir écouté les principaux problèmes. Il a admis la possibilité que quelqu'un d'autre puisse s'occuper de ces points.

Quels outils seront utilisés pour répondre à ces exigences :

  1. Pile ELK (après un certain temps, il est devenu clair que fluentd serait utilisé à la place de logstash).
  2. Ansible. Pour faciliter l'administration et le partage d'accès, nous utiliserons AWX.
  3. GITLAB. Il n’est pas nécessaire d’expliquer ici. Où serions-nous sans le contrôle de version de nos configurations ?
  4. PowerShell. Il y aura un script simple pour la génération initiale de la configuration.
  5. Wiki Doku, pour rédiger de la documentation et des guides. Dans ce cas, nous utilisons habr.com.
  6. Le suivi sera effectué via zabbix. Un schéma de connexion y sera également dessiné pour une compréhension générale.

Points de configuration EFK

Concernant le premier point, je décrirai seulement l’idéologie selon laquelle les indices seront construits. Il y a beaucoup de
excellents articles sur la configuration et la réception des journaux des appareils exécutant Mikrotik.

Je m'attarderai sur quelques points :

1. D'après le diagramme, il vaut la peine d'envisager de recevoir des journaux de différents endroits et sur différents ports. Pour cela, nous utiliserons un agrégateur de logs. Nous souhaitons également créer des graphiques universels pour tous les routeurs avec la possibilité de partager l'accès. Ensuite, nous construisons les index comme suit :

voici un morceau de la configuration avec fluentd tapez recherche élastique
logstash_format vrai
nom_index mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
hôtes elasticsearch: 9200
Port 9200

De cette façon, nous pouvons combiner les routeurs et segmenter selon le plan - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Pourquoi rendre les choses si compliquées ? Nous comprenons que nous aurons 200 appareils ou plus. Vous ne pouvez pas tout suivre. Avec la version 6.8 d'elasticsearch, les paramètres de sécurité sont à notre disposition (sans acheter de licence), nous pouvons ainsi répartir les droits de visualisation entre les employés du support technique ou les administrateurs système locaux.
Tableaux, graphiques - ici il suffit d'être d'accord - soit utilisez les mêmes, soit chacun fait ce qui lui convient.

2. En vous connectant. Si nous activons la connexion dans les règles de pare-feu, nous créons les noms sans espaces. On peut voir qu'en utilisant une configuration simple dans fluentd, nous pouvons filtrer les données et créer des panneaux pratiques. L'image ci-dessous représente mon routeur domestique.

Mon projet non réalisé. Réseau de 200 routeurs MikroTik

3. Par espace occupé et journaux. En moyenne, avec 1000 2 messages par heure, les journaux occupent 3 à 7.5 Mo par jour, ce qui, voyez-vous, n'est pas tant que ça. Elasticsearch version XNUMX.

ANSIBLE.AWX

Heureusement pour nous, nous avons un module prêt à l'emploi pour les routeurs
J'ai mentionné AWX, mais les commandes ci-dessous concernent uniquement ansible dans sa forme pure - je pense que pour ceux qui ont travaillé avec ansible, il n'y aura aucun problème à utiliser awx via l'interface graphique.

Pour être honnête, avant cela, j'ai consulté d'autres guides dans lesquels ils utilisaient ssh, et ils avaient tous des problèmes différents avec le temps de réponse et un tas d'autres problèmes. Je le répète, cela n’a pas abouti à une bagarre , prenez cette information comme une expérience qui n’a pas dépassé un stand de 20 routeurs.

Nous devons utiliser un certificat ou un compte. C'est à vous de décider, je suis pour les certificats. Un point subtil sur les droits. Je donne des droits d'écriture - au moins « réinitialiser la configuration » ne fonctionnera pas.

Il ne devrait y avoir aucun problème pour générer, copier et importer le certificat :

Brève liste de commandesSur votre PC
ssh-keygen -t RSA, répondez aux questions, enregistrez la clé.
Copier sur Mikrotik :
utilisateur ssh-keys import public-key-file=id_mtx.pub utilisateur=ansible
Vous devez d'abord créer un compte et lui attribuer des droits.
Vérification de la connexion à l'aide du certificat
ssh -p 49475 -i /clés/mtx [email protected]

Enregistrez 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

Eh bien, un exemple de playbook : - nom : add_work_sites
hôtes : testmt
série : 1
connexion : network_cli
utilisateur_distant : mikrotik.west
rassemble_facts : oui
Tâches:
- nom : ajouter Work_sites
commande_routeros :
commandes:
— /liste d'adresses du pare-feu IP add address=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
— /liste d'adresses du pare-feu ip add adresse=habr.com list=work_sites comment=for_habr

Comme vous pouvez le voir dans la configuration ci-dessus, créer vos propres playbooks n'est pas difficile. Il suffit de bien maîtriser cli mikrotik. Imaginons une situation dans laquelle vous devez supprimer la liste d'adresses contenant certaines données sur tous les routeurs, puis :

Rechercher et supprimer/liste d'adresses du pare-feu ip supprimer [trouver où list="gov.ru"]

Je n'ai intentionnellement pas inclus la liste complète des pare-feu ici parce que... il sera individuel pour chaque projet. Mais une chose que je peux dire avec certitude, utilisez uniquement la liste d’adresses.

Selon GITLAB, tout est clair. Je ne m'étendrai pas sur ce point. Tout est beau pour les tâches individuelles, les modèles, les gestionnaires.

Powershell

Il y aura 3 fichiers ici. Pourquoi PowerShell ? Vous pouvez choisir n'importe quel outil pour générer des configurations, celui qui vous convient le mieux. Dans ce cas, tout le monde a Windows sur son PC, alors pourquoi le faire en bash alors que PowerShell est plus pratique. Lequel est le plus pratique ?

Le script lui-même (simple et compréhensible) :[cmdletBinding()] Param(
[Paramètre(Obligatoire=$true)] [chaîne]$EXTERNALIPADDDRESS,
[Paramètre(Mandatory=$true)] [string]$EXTERNALIPROUTE,
[Paramètre(Obligatoire=$true)] [chaîne]$BWorknets,
[Paramètre(Mandatory=$true)] [string]$CWorknets,
[Paramètre(Obligatoire=$true)] [string]$BVoipNets,
[Paramètre(Obligatoire=$true)] [string]$CVoipNets,
[Paramètre(Mandatory=$true)] [string]$CClientss,
[Paramètre(Mandatory=$true)] [string]$BVPNWORKs,
[Paramètre(Mandatory=$true)] [string]$CVPNWORKs,
[Paramètre(Mandatory=$true)] [string]$BVPNCLIENTS,
[Paramètre(Mandatory=$true)] [string]$cVPNCLIENTS,
[Paramètre(Mandatory=$true)] [string]$NAMEROUTER,
[Paramètre(Mandatory=$true)] [string]$ServerCertificates,
[Paramètre(Mandatory=$true)] [string]$infile,
[Paramètre(Obligatoire=$true)] [string]$outfile
)

Obtenir le contenu $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)} | Définir le contenu $outfile

S'il vous plaît, pardonnez-moi, je ne peux pas publier toutes les règles parce que... ce ne sera pas très joli. Vous pouvez établir les règles vous-même, guidé par les meilleures pratiques.

Par exemple, voici une liste de liens que j'ai suivis :wiki.mikrotik.com/wiki/Manuel:Sécurisation_de_votre_routeur
wiki.mikrotik.com/wiki/Manuel:IP/Pare-feu/Filtre
wiki.mikrotik.com/wiki/Manuel: Exemples OSPF
wiki.mikrotik.com/wiki/Drop_port_scanners
wiki.mikrotik.com/wiki/Manuel:Winbox
wiki.mikrotik.com/wiki/Manuel:Mise à niveau_RouterOS
wiki.mikrotik.com/wiki/Manuel:IP/Fasttrack - ici, vous devez savoir que lorsque Fasttrack est activé, les règles de priorisation et de mise en forme du trafic ne fonctionneront pas - utile pour les appareils faibles.

Symboles pour les variables :Les réseaux suivants sont pris comme exemple :
Réseau de travail 192.168.0.0/24
Réseau VOIP 172.22.4.0/24
Réseau 10.0.0.0/24 pour les clients sans accès au réseau local
Réseau VPN 192.168.255.0/24 pour grandes succursales
Réseau VPN 172.19.255.0/24 pour petits

L'adresse réseau est constituée de 4 nombres décimaux, respectivement ABCD, le remplacement fonctionne sur le même principe, si au démarrage il demande B, alors cela signifie qu'il faut saisir le chiffre 192.168.0.0 pour le réseau 24/0, et pour C = 0.
$EXTERNALIPADDDRESS - adresse dédiée du fournisseur.
$EXTERNALIPROUTE - route par défaut vers le réseau 0.0.0.0/0
$BWorknets - Réseau de travail, dans notre exemple il y en aura 168
$CWorknets - Réseau de travail, dans notre exemple ce sera 0
$BVoipNets - Réseau VOIP dans notre exemple ici 22
$CVoipNets - Réseau VOIP dans notre exemple ici 4
$CClientss - Réseau pour clients - Accès Internet uniquement, dans notre cas ici 0
$BVPNWORKs - Réseau VPN pour grandes succursales, dans notre exemple 20
$CVPNWORKs - Réseau VPN pour grandes succursales, dans notre exemple 255
$BVPNCLIENTS - Réseau VPN pour petites succursales, soit 19
$CVPNCLIENTS - Réseau VPN pour petites succursales, soit 255
$NAMEROUTER - nom du routeur
$ServerCertificate - le nom du certificat que vous avez précédemment importé
$infile — Spécifiez le chemin d'accès au fichier à partir duquel nous lirons la configuration, par exemple D:config.txt (de préférence le chemin anglais sans guillemets ni espaces)
$outfile — spécifiez le chemin où l'enregistrer, par exemple D:MT-test.txt

J'ai délibérément modifié les adresses dans les exemples pour des raisons évidentes.

J'ai raté l'essentiel sur la détection des attaques et des comportements anormaux - cela mérite un article séparé. Mais il convient de souligner que dans cette catégorie, vous pouvez utiliser les valeurs des données de surveillance de Zabbix + les données curl traitées d'elasticsearch.

À quels points devez-vous faire attention :

  1. Plan de réseau. Il est préférable de le rédiger immédiatement sous une forme lisible. Excel suffira. Malheureusement, je constate très souvent que les réseaux se construisent selon le principe « Une nouvelle branche est apparue, voici /24 pour vous ». Personne ne sait combien d’appareils sont attendus dans un endroit donné ni s’il y aura une nouvelle croissance. Par exemple, un petit magasin a ouvert ses portes dans lequel il était initialement clair que le nombre d'appareils ne dépasserait pas 10, pourquoi allouer /24 ? Pour les grandes succursales, au contraire, elles allouent /24 et il y a 500 appareils - vous pouvez simplement ajouter un réseau, mais vous voulez tout réfléchir en même temps.
  2. Règles de filtrage. Si le projet suppose qu'il y aura séparation des réseaux et segmentation maximale. Les meilleures pratiques évoluent avec le temps. Auparavant, un réseau de PC et un réseau d'imprimantes étaient divisés, mais il est désormais tout à fait normal de ne pas diviser ces réseaux. Il vaut la peine de faire preuve de bon sens et de ne pas créer de nombreux sous-réseaux là où ils ne sont pas nécessaires et de ne pas combiner tous les appareils en un seul réseau.
  3. Paramètres « Golden » sur tous les routeurs. Ceux. si vous avez décidé d'un plan. Cela vaut la peine de tout prévoir tout de suite et d'essayer de s'assurer que tous les paramètres sont identiques - seules la liste d'adresses et les adresses IP sont différentes. Si des problèmes surviennent, le temps de débogage sera réduit.
  4. Les problèmes organisationnels ne sont pas moins importants que les problèmes techniques. Souvent, les employés paresseux exécutent ces recommandations « manuellement », sans utiliser de configurations ni de scripts prêts à l'emploi, ce qui conduit finalement à des problèmes survenus de nulle part.

Par routage dynamique. OSPF avec division de zone a été utilisé. Mais il s’agit d’un banc d’essai, il est plus intéressant de mettre en place de telles choses en conditions de combat.

J'espère que personne n'est contrarié par le fait que je n'ai pas publié les configurations du routeur. Je pense que les liens suffiront, et puis tout dépend des besoins. Et bien sûr des tests, d’autres tests sont nécessaires.

Je souhaite à chacun de réaliser ses projets au cours de la nouvelle année. Que l'accès accordé soit avec vous !!!

Source: habr.com

Ajouter un commentaire