Hei kaikki. Tämä artikkeli on tarkoitettu niille, joilla on paljon Mikrotik-laitteita puistossa ja jotka haluavat tehdä maksimaalisen yhtenäistyksen, jotta ei yhdistetä jokaiseen laitteeseen erikseen. Tässä artikkelissa kuvaan projektia, joka ei valitettavasti päässyt taisteluolosuhteisiin inhimillisten tekijöiden vuoksi. Lyhyesti: yli 200 reititintä, nopea asennus ja henkilöstön koulutus, aluekohtainen yhdistäminen, verkkojen ja tiettyjen isäntien suodatus, mahdollisuus lisätä sääntöjä helposti kaikkiin laitteisiin, kirjaus ja kulunvalvonta.
Alla kuvattu ei ole valmis tapaus, mutta toivon, että siitä on sinulle hyötyä, kun suunnittelet verkkojasi ja minimoit virheitä. Ehkä jotkut kohdat ja päätökset eivät näytä sinusta aivan oikeilta - jos on, kirjoita kommentteihin. Tässä tapauksessa kritiikki on kokemus yhteisestä säästöpossusta. Siksi, lukija, katso kommentteja, ehkä kirjoittaja teki törkeän virheen - yhteisö auttaa.
Reitittimiä on 200-300, hajallaan eri kaupungeissa, joissa on eri laatuinen Internet-yhteys. On välttämätöntä tehdä kaikesta kaunista ja selittää paikallisille ylläpitäjille helposti, kuinka kaikki toimii.
Mistä jokainen projekti sitten alkaa? Tietenkin kanssa TK.
- Verkkosuunnitelman järjestäminen kaikille konttoreille asiakkaan tarpeiden mukaan, verkon segmentointi (3-20 verkkoa konttoreissa, riippuen laitteiden määrästä).
- Aseta laitteet jokaiseen haaraan. Palveluntarjoajan todellisen kaistanleveyden tarkistaminen erilaisissa työolosuhteissa.
- Laitteen suojauksen organisointi, sallittujen listan hallinta, hyökkäysten automaattinen havaitseminen automaattisella mustalla listalla tietyksi ajaksi, erilaisten pääsyn ja palveluneston kaappaamiseen käytettävien teknisten keinojen käytön minimointi.
- Turvallisten vpn-yhteyksien järjestäminen verkkosuodatuksella asiakkaan vaatimusten mukaan. Vähintään 3 vpn-yhteyttä jokaisesta haarasta keskustaan.
- Perustuu kohtiin 1, 2. Valitse parhaat tavat rakentaa vikasietoinen vpn. Urakoitsija voi valita dynaamisen reititystekniikan oikeilla perusteilla.
- Liikenteen priorisoinnin järjestäminen protokollien, porttien, isäntien ja muiden asiakkaan käyttämien erityispalvelujen mukaan. (VOIP, isännät tärkeillä palveluilla)
- Reititintapahtumien seurannan ja kirjaamisen järjestäminen teknisen tukihenkilöstön vastausta varten.
Kuten ymmärrämme, joissakin tapauksissa TOR kootaan vaatimuksista. Muotoilin nämä vaatimukset itse, kuunneltuani pääongelmat. Hän myönsi mahdollisuuden, että joku muu voisi ryhtyä toteuttamaan näitä kohtia.
Mitä työkaluja käytetään näiden vaatimusten täyttämiseen:
- ELK-pino (jonkin ajan kuluttua ymmärsimme, että fluentd:tä käytettäisiin logstashin sijaan).
- Mahdollinen. Käytämme AWX:ää hallinnon ja käyttöoikeuksien jakamisen helpottamiseksi.
- GITLAB. Tässä ei ole tarvetta selittää. Missä ilman kokoonpanojemme versionhallintaa.
- PowerShell. Mukana on yksinkertainen komentosarja konfiguraation ensimmäiselle sukupolvelle.
- Doku wiki, dokumenttien ja käsikirjojen kirjoittamiseen. Tässä tapauksessa käytämme habr.com-sivustoa.
- Valvonta suoritetaan zabbixin kautta. Mukana on myös kytkentäkaavio yleistä ymmärtämistä varten.
EFK-asennuspisteet
Ensimmäisessä kohdassa kuvailen vain ideologiaa, jolle indeksit rakennetaan. On olemassa monia
erinomaisia artikkeleita lokien määrittämisestä ja vastaanottamisesta mikrotikkiä käyttävistä laitteista.
Pysähdyn muutamaan kohtaan:
1. Kaavan mukaan kannattaa harkita lokien vastaanottamista eri paikoista ja eri porteista. Tätä varten käytämme lokikokoojaa. Haluamme myös tehdä yleisen näytönohjaimen kaikille reitittimille, joilla on mahdollisuus jakaa pääsy. Sitten rakennamme indeksit seuraavasti:
tässä on pala fluentd:n konfiguraatiota elastinen haku
logstash_format tosi
index_name mikrotiklogs.north
logstash_prefix mikrotiklogs.north
huuhteluväli 10s
isännät : 9200
portti 9200
Siten voimme yhdistää reitittimiä ja segmenttejä suunnitelman mukaan - mikrotiklogs.west, mikrotiklogs.south, mikrotiklogs.east. Miksi tehdä siitä niin vaikeaa? Ymmärrämme, että meillä on 200 tai enemmän laitetta. Älä seuraa kaikkea. Elasticsearchin versiosta 6.8 lähtien suojausasetukset ovat käytettävissämme (ilman lisenssin ostamista), joten voimme jakaa katseluoikeudet teknisen tuen työntekijöiden tai paikallisten järjestelmänvalvojien kesken.
Taulukot, kaaviot - tässä sinun on vain sovittava - joko käytä samoja tai kaikki tekevät sen niin kuin hänelle sopii.
2. Kirjautumalla. Jos sallimme sisäänkirjautumisen palomuurin säännöt, teemme nimet ilman välilyöntejä. Voidaan nähdä, että käyttämällä yksinkertaista konfigurointia fluentd:ssä voimme suodattaa tiedot ja tehdä käteviä paneeleja. Alla oleva kuva on kotireitittimeni.
3. Käytetyn tilan ja lokien mukaan. Keskimäärin 1000 viestillä tunnissa lokit vievät 2-3 Mt päivässä, mikä ei ole niin paljon. elasticsearch versio 7.5.
ANSIBLE.AWX
Onneksi meillä on valmiina reitittimien moduuli
Mainitsin AWX:stä, mutta alla olevat komennot koskevat vain ansiblea sen puhtaimmassa muodossa - uskon, että niille, jotka ovat työskennelleet ansiblen kanssa, ei tule ongelmia awx: n käyttämisessä guin kautta.
Ollakseni rehellinen, ennen sitä katsoin muita oppaita, joissa he käyttivät ssh: tä, ja jokaisella oli erilaisia ongelmia vasteajan kanssa ja joukko muita ongelmia. Toistan, se ei päässyt taisteluun , ota tämä tieto kokeiluna, joka ei ylittänyt 20 reitittimen telinettä.
Meidän on käytettävä varmennetta tai tiliä. Se on sinun päätettävissäsi, minä kannatan todistuksia. Pieni huomio oikeuksista. Annan kirjoitusoikeudet - ainakaan "reset config" ei toimi.
Varmenteen luomisessa, kopioimisessa ja tuonnissa ei pitäisi olla ongelmia:
Lyhyt luettelo komennoistaPC:lläsi
ssh-keygen -t RSA, vastaa kysymyksiin, tallenna avain.
Kopioi mikroon:
user ssh-keys tuonti public-key-file=id_mtx.pub user=ansible
Ensin sinun on luotava tili ja myönnettävä siihen oikeudet.
Tarkistetaan yhteyttä varmenteeseen
ssh -p 49475 -i /avaimet/mtx [sähköposti suojattu]
Kirjoita osoitteeseen /etc/ansible/hosts
MT01 ansible_network_os=reitittimet ansible_ssh_port=49475 ansible_ssh_user= ansible
MT02 ansible_network_os=reitittimet ansible_ssh_port=49475 ansible_ssh_user= ansible
MT03 ansible_network_os=reitittimet ansible_ssh_port=49475 ansible_ssh_user= ansible
MT04 ansible_network_os=reitittimet ansible_ssh_port=49475 ansible_ssh_user= ansible
No, esimerkki leikkikirjasta: nimi: add_work_sites
hosts:testmt
sarja: 1
yhteys:verkko_cli
remote_user: mikrotik.west
kerätä_facts: kyllä
tehtävät:
nimi: lisää työsivustot
routeros_command:
komennot:
- /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
Kuten yllä olevasta kokoonpanosta näet, omien pelikirjojen kokoaminen on yksinkertaista. Riittää, kun hallitset cli mikrotikin riittävän hyvin. Kuvittele tilanne, jossa sinun on poistettava osoiteluettelo, jossa on tietyt tiedot kaikista reitittimistä, ja sitten:
Etsi ja poista/ip firewal address-list poista [find where list="gov.ru"]
En tarkoituksella lisännyt koko palomuuriluetteloa tähän. se on yksilöllinen jokaiselle projektille. Mutta voin sanoa yhden asian varmaksi, käytä vain osoiteluetteloa.
GITLABin mukaan kaikki on selvää. En viivyttele tässä hetkessä. Kaikki on kaunista yksittäisten tehtävien, mallien, käsittelijöiden suhteen.
PowerShell
Mukaan tulee 3 tiedostoa. Miksi powershell? Työkalun asetusten luomiseen voi valita kuka tahansa mukavampi. Tässä tapauksessa jokaisella on Windows PC:ssä, joten miksi tehdä se bashilla, kun powershell on kätevämpää. Kumpi on mukavampi.
Itse käsikirjoitus (yksinkertainen ja ymmärrettävä):[cmdletBinding()] Param(
[Parametri(Pakollinen=$true)] [merkkijono]$EXTERNALIPADDRESS,
[Parametri(Pakollinen=$true)] [merkkijono]$EXTERNALIPROUTE,
[Parametri(Pakollinen=$true)] [merkkijono]$BWorknets,
[Parametri(Pakollinen=$true)] [merkkijono]$CWorknets,
[Parametri(Pakollinen=$true)] [string]$BVoipNets,
[Parametri(Pakollinen=$true)] [merkkijono]$CVoipNets,
[Parametri(Pakollinen=$true)] [merkkijono]$CClients,
[Parametri(Pakollinen=$true)] [merkkijono]$BVPNWORKs,
[Parametri(Pakollinen=$true)] [merkkijono]$CVPNWORKs,
[Parametri(Pakollinen=$true)] [merkkijono]$BVPNCLIENTSs,
[Parametri(Pakollinen=$true)] [merkkijono]$cVPNCLIENTSs,
[Parametri(Pakollinen=$true)] [merkkijono]$NAMEROUTER,
[Parameter(Pakollinen=$true)] [string]$ServerCertificates,
[Parametri(Pakollinen=$true)] [merkkijono]$infile,
[Parametri(Pakollinen=$true)] [merkkijono]$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
Pyydän anteeksi, en voi esittää kaikkia sääntöjä. se ei tule olemaan kaunista. Voit laatia säännöt itse parhaiden käytäntöjen ohjaamana.
Tässä on esimerkiksi luettelo linkeistä, jotka ohjasivat minua::Reitittimesi turvaaminen
:IP/palomuuri/suodatin
:OSPF-esimerkkejä
: Winbox
:Upgrading_RouterOS
:IP/Fasttrack - tässä sinun on tiedettävä, että kun fasttrack on käytössä, liikenteen priorisointi ja muotoilusäännöt eivät toimi - hyödyllinen heikkoille laitteille.
Muuttuvat sopimukset:Seuraavat verkot ovat esimerkkinä:
192.168.0.0/24 toimiva verkko
172.22.4.0/24 VOIP-verkko
10.0.0.0/24-verkko asiakkaille, joilla ei ole LAN-yhteyttä
192.168.255.0/24 VPN-verkko suurille konttoreille
172.19.255.0/24 VPN-verkko pienille
Verkko-osoite koostuu 4 desimaaliluvusta, vastaavasti ABCD, vaihto toimii samalla periaatteella, jos se kysyy B:tä käynnistyksen yhteydessä, sinun on syötettävä numero 192.168.0.0 verkolle 24/0 ja C = 0 .
$EXTERNALIPADDRESS - palveluntarjoajalta annettu osoite.
$EXTERNALIPROUTE - oletusreitti verkkoon 0.0.0.0/0
$BWorknets - Toimiva verkko, esimerkissämme on 168
$CWorknets - Työverkko, esimerkissämme se on 0
$BVoipNets - VOIP-verkko esimerkissämme tässä 22
$CVoipNets - VOIP-verkko tässä esimerkissämme 4
$CClientss - Verkko asiakkaille - pääsy vain Internetiin, tässä tapauksessa 0
$BVPNWORKs - VPN-verkko suurille konttoreille, esimerkissämme 20
$CVPNWORKs - VPN-verkko suurille konttoreille, esimerkissämme 255
$BVPNCLIENTS - VPN-verkko pienille konttoreille, tarkoittaa 19
$CVPNCLIENTS - VPN-verkko pienille konttoreille, tarkoittaa 255
$NAMEROUTER - reitittimen nimi
$ServerCertificate - sen varmenteen nimi, jonka tuot ensin
$infile - Määritä polku tiedostoon, josta luemme konfiguroinnin, esimerkiksi D:config.txt (parempi englanninkielinen polku ilman lainausmerkkejä ja välilyöntejä)
$outfile - määritä polku, johon tallennetaan, esimerkiksi D:MT-test.txt
Vaihdoin tarkoituksella esimerkeissä olevia osoitteita ilmeisistä syistä.
Missasin hyökkäysten ja poikkeavan käytöksen havaitsemisen - tämä ansaitsee erillisen artikkelin. Mutta on syytä huomauttaa, että tässä kategoriassa voit käyttää Zabbixin seurantatietoarvoja + elasticsearchin työstettyjä kiharatietoja.
Mihin kohtiin kannattaa keskittyä:
- Verkkosuunnitelma. On parempi kirjoittaa se luettavassa muodossa. Excel riittää. Valitettavasti näen usein, että verkostot kootaan periaatteella "Uusi haara on ilmestynyt, tässä /24 sinulle." Kukaan ei tiedä, kuinka monta laitetta tietylle alueelle odotetaan ja onko kasvua vielä tulossa. Esimerkiksi pieni kauppa on avattu, jossa on aluksi selvää, että laite ei ole enempää kuin 10, miksi varata / 24? Päinvastoin, suurille sivukonttoreille ne varaavat / 24, ja laitteita on 500 - voit vain lisätä verkon, mutta haluat ajatella kaiken läpi heti.
- Suodatussäännöt. Jos hankkeessa oletetaan, että verkkojen erottelu ja maksimaalinen segmentointi tapahtuu. Parhaat käytännöt muuttuvat ajan myötä. Aiemmin he jakoivat PC-verkon ja tulostinverkon, nyt on aivan normaalia olla jakamatta näitä verkkoja. Kannattaa käyttää maalaisjärkeä ja olla tuottamatta monia aliverkkoja sinne, missä niitä ei tarvita, eikä yhdistää kaikkia laitteita yhdeksi verkkoksi.
- "Kultaiset" asetukset kaikissa reitittimissä. Nuo. jos sinulla on suunnitelma. Kaikki kannattaa ennakoida heti ja yrittää varmistaa, että kaikki asetukset ovat identtisiä - on vain eri osoiteluettelo ja IP-osoitteet. Ongelmatapauksissa virheenkorjausaika on lyhyempi.
- Organisatoriset näkökohdat eivät ole yhtä tärkeitä kuin tekniset. Usein laiskot työntekijät noudattavat näitä suosituksia "manuaalisesti" käyttämättä valmiita kokoonpanoja ja komentosarjoja, mikä lopulta johtaa ongelmiin tyhjästä.
Dynaamisella reitityksellä. Käytettiin OSPF:ää vyöhykkeellä. Mutta tämä on testipenkki, taisteluolosuhteissa sellaiset asiat ovat mielenkiintoisempia asentaa.
Toivottavasti kukaan ei ollut järkyttynyt siitä, etten lähettänyt reitittimien asetuksia. Uskon, että linkit riittävät, ja sitten kaikki riippuu vaatimuksista. Ja tietysti testejä, lisää testejä tarvitaan.
Toivotan kaikille toteuttamaan hankkeensa uuden vuoden aikana. Myönnetty pääsy olkoon kanssasi!!!
Lähde: will.com