Proiectul meu nerealizat. Rețea de 200 de routere MikroTik

Proiectul meu nerealizat. Rețea de 200 de routere MikroTik

Salutare tuturor. Acest articol este destinat celor care au multe dispozitive Mikrotik în flota lor și care doresc să facă unificare maximă pentru a nu se conecta la fiecare dispozitiv separat. În acest articol voi descrie un proiect care, din păcate, nu a ajuns în condiții de luptă din cauza factorilor umani. Pe scurt: peste 200 de routere, configurare rapidă și instruire a personalului, unificare pe regiune, filtrare a rețelelor și gazde specifice, posibilitatea de a adăuga cu ușurință reguli la toate dispozitivele, înregistrare și control al accesului.

Ceea ce este descris mai jos nu pretinde a fi un caz gata făcut, dar sper că vă va fi util atunci când vă planificați rețelele și minimizați erorile. Poate că unele puncte și soluții ți se pot părea în întregime corecte - dacă da, scrie în comentarii. Critica în acest caz va fi o experiență pentru vistieria comună. Prin urmare, cititorule, aruncați o privire la comentarii, poate că autorul a făcut o greșeală gravă - comunitatea vă va ajuta.

Numărul de routere este de 200-300, împrăștiate în diferite orașe cu o calitate diferită a conexiunilor la Internet. Este necesar să faceți totul frumos și să explicați clar administratorilor locali cum va funcționa totul.

Deci, de unde începe orice proiect? Desigur, cu TK.

  1. Organizarea unui plan de retea pentru toate filialele in functie de cerintele clientilor, segmentarea retelei (de la 3 la 20 de retele in filiale in functie de numarul de dispozitive).
  2. Configurarea dispozitivelor în fiecare ramură. Verificarea vitezei reale de transfer a furnizorului în diferite condiții de funcționare.
  3. Organizarea protecției dispozitivelor, gestionarea listei albe, detectarea automată a atacurilor cu auto-lista neagră pentru o anumită perioadă de timp, minimizarea utilizării diferitelor mijloace tehnice utilizate pentru a intercepta accesul de control și a refuza serviciul.
  4. Organizarea conexiunilor VPN securizate cu filtrare de rețea în funcție de cerințele clienților. Minim 3 conexiuni VPN de la fiecare filială la centru.
  5. Pe baza punctelor 1, 2. Selectați modalitățile optime de a construi VPN-uri tolerante la erori. Dacă se justifică corect, tehnologia de rutare dinamică poate fi aleasă de antreprenor.
  6. Organizarea prioritizării traficului pe protocoale, porturi, gazde și alte servicii specifice utilizate de client. (VOIP, gazde cu servicii importante)
  7. Organizarea monitorizării și înregistrării evenimentelor routerului pentru răspunsul personalului de suport tehnic.

După cum înțelegem, într-o serie de cazuri specificațiile tehnice sunt întocmite pe baza cerințelor. Aceste cerințe le-am formulat chiar eu, după ce am ascultat principalele probleme. El a admis posibilitatea ca altcineva să se ocupe de aceste puncte.

Ce instrumente vor fi folosite pentru a îndeplini aceste cerințe:

  1. ELK stack (după ceva timp, a devenit clar că fluentd va fi folosit în loc de logstash).
  2. Ansible. Pentru a facilita administrarea și partajarea accesului, vom folosi AWX.
  3. GITLAB. Nu este nevoie să explici aici. Unde am fi fără controlul versiunilor configurațiilor noastre?
  4. PowerShell. Va exista un script simplu pentru generarea inițială a configurației.
  5. Doku wiki, pentru scrierea documentației și a ghidurilor. În acest caz, folosim habr.com.
  6. Monitorizarea va fi efectuată prin zabbix. O diagramă de conexiune va fi de asemenea desenată acolo pentru o înțelegere generală.

Puncte de configurare EFK

Referitor la primul punct, voi descrie doar ideologia prin care se vor construi indicii. Există multe
articole excelente despre configurarea și primirea jurnalelor de la dispozitivele care rulează mikrotik.

Mă voi opri asupra unor puncte:

1. Conform diagramei, merită să luați în considerare primirea jurnalelor din diferite locuri și pe diferite porturi. Pentru aceasta vom folosi un agregator de jurnal. De asemenea, dorim să facem grafică universală pentru toate routerele, cu posibilitatea de a partaja accesul. Apoi construim indecșii după cum urmează:

aici este o parte din configurația cu fluentd tip elasticsearch
logstash_format adevărat
nume_index mikrotiklogs.north
logstash_prefix mikrotiklogs.north
flush_interval 10s
Gazdele elastic căutare: 9200
portul 9200

Astfel putem combina routere și segmente conform planului - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. De ce să fie atât de complicat? Înțelegem că vom avea 200 sau mai multe dispozitive. Nu poți urmări totul. Cu versiunea 6.8 a elasticsearch, setările de securitate sunt disponibile pentru noi (fără achiziționarea unei licențe), astfel putem distribui drepturile de vizualizare între angajații de asistență tehnică sau administratorii de sistem locali.
Tabelele, graficele - aici trebuie doar să fiți de acord - fie le folosiți pe aceleași, fie fiecare face ceea ce îi este convenabil.

2. Prin logare. Dacă activăm regulile de conectare pentru firewall, atunci facem numele fără spații. Se poate observa că, folosind o configurare simplă în fluentd, putem filtra datele și putem face panouri convenabile. Imaginea de mai jos este routerul meu de acasă.

Proiectul meu nerealizat. Rețea de 200 de routere MikroTik

3. După spațiul ocupat și bușteni. În medie, cu 1000 de mesaje pe oră, jurnalele ocupă 2-3 MB pe zi, ceea ce, vedeți, nu este atât de mult. Elasticsearch versiunea 7.5.

ANSIBLE.AWX

Din fericire pentru noi, avem un modul gata făcut pentru routeros
Am menționat despre AWX, dar comenzile de mai jos sunt doar despre ansible în forma sa pură - cred că pentru cei care au lucrat cu ansible, nu vor fi probleme cu utilizarea awx prin gui-ul.

Sincer să fiu, înainte de asta m-am uitat la alte ghiduri în care au folosit ssh și toți au avut probleme diferite cu timpul de răspuns și o grămadă de alte probleme. Repet, nu a venit la o luptă , luați această informație ca pe un experiment care nu a ajuns mai departe de un stand de 20 de routere.

Trebuie să folosim un certificat sau un cont. Depinde de tine să decizi, eu sunt pentru certificate. Un punct subtil despre drepturi. Dau drepturi de scriere - cel puțin „resetare config” nu va funcționa.

Nu ar trebui să existe probleme la generarea, copierea și importul certificatului:

Scurtă listă de comenziPe computerul dvs
ssh-keygen -t RSA, răspunde la întrebări, salvează cheia.
Copiați pe mikrotik:
user ssh-keys import public-key-file=id_mtx.pub user=ansible
Mai întâi trebuie să creați un cont și să îi atribuiți drepturi.
Verificarea conexiunii folosind certificatul
ssh -p 49475 -i /keys/mtx [e-mail protejat]

Înregistrați-vă pe /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

Ei bine, un exemplu de manual de joc: - nume: add_work_sites
gazde: testmt
seria: 1
conexiune: network_cli
utilizator_la distanță: mikrotik.west
gather_facts: da
sarcini:
- nume: adăugați Work_sites
routeros_command:
comenzi:
— /ip firewall address-list add address=gov.ru list=work_sites comment=Ticket665436_Ochen_nado
— /ip firewall list-adresă add address=habr.com list=work_sites comment=for_habr

După cum puteți vedea din configurația de mai sus, crearea propriilor manuale de joc nu este dificilă. Este suficient să stăpânești bine cli mikrotik. Să ne imaginăm o situație în care trebuie să eliminați lista de adrese cu anumite date pe toate routerele, apoi:

Găsiți și eliminați/ip firewall listă de adrese eliminare [găsiți unde list="gov.ru"]

În mod intenționat, nu am inclus întreaga listă de firewall aici, deoarece... va fi individual pentru fiecare proiect. Dar un lucru pot spune cu siguranță, folosiți doar lista de adrese.

Conform GITLAB totul este clar. Nu mă voi opri asupra acestui punct. Totul este frumos pentru sarcini individuale, șabloane, handler.

PowerShell

Vor fi 3 fișiere aici. De ce powershell? Puteți alege orice instrument pentru generarea de configurații, oricare este mai convenabil pentru dvs. În acest caz, toată lumea are Windows pe computerul lor, așa că de ce să o faci în bash când powershell este mai convenabil. Care este mai convenabil?

Scriptul în sine (simplu și de înțeles):[cmdletBinding()] Param(
[Parametru(Obligatoriu=$adevărat)] [șir]$EXTERNALIPADDRESS,
[Parametru(Obligatoriu=$adevărat)] [șir]$EXTERNALIPROUTE,
[Parametru(Obligatoriu=$adevărat)] [șir]$BWorknets,
[Parametru(Obligatoriu=$adevărat)] [șir]$CWorknets,
[Parametru(Obligatoriu=$adevărat)] [șir]$BVoipNets,
[Parametru(Obligatoriu=$adevărat)] [șir]$CVoipNets,
[Parametru(Obligatoriu=$adevărat)] [șir]$CClients,
[Parametru(Obligatoriu=$true)] [șir]$BVPNWORKs,
[Parametru(Obligatoriu=$true)] [șir]$CVPNWORKs,
[Parametru(Obligatoriu=$true)] [șir]$BVPNCLIENTS,
[Parametru(Obligatoriu=$true)] [șir]$cVPNCLIENTS,
[Parametru(Obligatoriu=$true)] [șir]$NAMEROUTER,
[Parametru(Obligatoriu=$adevărat)] [șir]$ServerCertificates,
[Parametru(Obligatoriu=$adevărat)] [șir]$în fișier,
[Parametru(Obligatoriu=$adevărat)] [șir]$fișier de ieșire
)

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", $BVPNCLIENTS)} |
Foreach-Object {$_.Replace("CVPNCLIENTS", $cVPNCLIENTS)} |
Foreach-Object {$_.Replace("MYNAMERROUTER", $NAMEROUTER)} |
Foreach-Object {$_.Replace(„ServerCertificate”, $ServerCertificates)} | Set-Content $outfile

Vă rog să mă iertați, nu pot posta toate regulile pentru că... nu va fi foarte frumos. Puteți elabora singur regulile, ghidat de cele mai bune practici.

De exemplu, iată o listă de link-uri pe care le-am urmat:wiki.mikrotik.com/wiki/Manual:Securizarea_ruterului_dvs
wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filtru
wiki.mikrotik.com/wiki/Manual:OSPF-exemple
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 - aici trebuie să știți că atunci când este activat Fasttrack, regulile de prioritizare și modelare a traficului nu vor funcționa - utile pentru dispozitivele slabe.

Simboluri pentru variabile:Următoarele rețele sunt luate ca exemplu:
Rețea de lucru 192.168.0.0/24
172.22.4.0/24 Rețea VOIP
Rețea 10.0.0.0/24 pentru clienții fără acces la rețeaua locală
192.168.255.0/24 Rețea VPN pentru filiale mari
172.19.255.0/24 Rețea VPN pentru mici

Adresa de rețea este formată din 4 numere zecimale, respectiv ABCD, înlocuirea funcționează pe același principiu, dacă la pornire cere B, atunci înseamnă că trebuie să introduceți numărul 192.168.0.0 pentru rețeaua 24/0, iar pentru C = 0.
$EXTERNALIPADDRESS - adresa dedicată de la furnizor.
$EXTERNALIPROUTE - ruta implicită către rețeaua 0.0.0.0/0
$BWorknets - Rețea de lucru, în exemplul nostru va fi 168
$CWorknets - Rețea de lucru, în exemplul nostru acesta va fi 0
$BVoipNets - Rețeaua VOIP în exemplul nostru aici 22
$CVoipNets - Rețeaua VOIP în exemplul nostru aici 4
$CClientss - Rețea pentru clienți - numai acces la Internet, în cazul nostru aici 0
$BVPNWORKs - Rețea VPN pentru sucursale mari, în exemplul nostru 20
$CVPNWORKs - Rețea VPN pentru filiale mari, în exemplul nostru 255
$BVPNCLIENTS - Rețea VPN pentru sucursale mici, adică 19
$CVPNCLIENTS - Rețea VPN pentru filiale mici, adică 255
$NAMEROUTER - numele routerului
$ServerCertificate - numele certificatului pe care l-ați importat anterior
$infile — Specificați calea către fișierul din care vom citi configurația, de exemplu D:config.txt (de preferință calea în limba engleză fără ghilimele și spații)
$outfile — specificați calea unde să îl salvați, de exemplu D:MT-test.txt

Am schimbat în mod deliberat adresele din exemple din motive evidente.

Am ratat ideea despre detectarea atacurilor și a comportamentului anormal - acesta merită un articol separat. Dar merită subliniat că în această categorie puteți utiliza valorile datelor de monitorizare de la Zabbix + datele de curl prelucrate de la elasticsearch.

La ce puncte ar trebui să acordați atenție:

  1. Plan de rețea. Este mai bine să-l compuneți imediat într-o formă lizibilă. Excel va fi suficient. Din păcate, văd foarte des că rețelele sunt construite după principiul „A apărut o nouă sucursală, iată /24 pentru tine”. Nimeni nu își dă seama câte dispozitive sunt așteptate într-o anumită locație sau dacă va exista o creștere suplimentară. De exemplu, s-a deschis un mic magazin în care inițial era clar că dispozitivul nu va fi mai mult de 10, de ce să aloci /24? Pentru ramurile mari, dimpotrivă, ele alocă /24 și există 500 de dispozitive - puteți adăuga pur și simplu o rețea, dar doriți să vă gândiți la toate odată.
  2. Reguli de filtrare. Dacă proiectul presupune că va exista separarea rețelelor și segmentarea maximă. Cele mai bune practici se schimbă în timp. Anterior, o rețea de PC-uri și o rețea de imprimante erau împărțite, dar acum este destul de normal să nu se împartă aceste rețele. Merită să folosiți bunul simț și să nu creați multe subrețele unde nu sunt necesare și să nu combinați toate dispozitivele într-o singură rețea.
  3. Setări „de aur” pe toate routerele. Acestea. dacă te-ai hotărât asupra unui plan. Merită să prevedeți totul imediat și să încercați să vă asigurați că toate setările sunt identice - doar lista de adrese și adresele IP sunt diferite. Dacă apar probleme, timpul de depanare va fi mai mic.
  4. Problemele organizaționale nu sunt mai puțin importante decât cele tehnice. Adesea, angajații leneși efectuează aceste recomandări „manual”, fără a utiliza configurații și scripturi gata făcute, ceea ce duce în cele din urmă la probleme de nicăieri.

Prin rutare dinamică. S-a folosit OSPF cu diviziune de zone. Dar acesta este un banc de testare; este mai interesant să instalați astfel de lucruri în condiții de luptă.

Sper că nimeni nu este supărat că nu am postat configurațiile routerului. Cred că legăturile vor fi suficiente, iar apoi totul depinde de cerințe. Și desigur teste, sunt necesare mai multe teste.

Le doresc tuturor să-și realizeze proiectele în noul an. Accesul acordat să fie cu tine!!!

Sursa: www.habr.com

Adauga un comentariu