See artikkel on teine osa artiklite tsüklist «Kuidas võtta võrguinfrastruktuur oma kontrolli alla». Kõikide artiklite sisu ja lingid leiate .
Meie eesmärk sellel etapil on korda luua dokumentatsioonis ja seadistustes.
Selle protsessi lõppedes peaksite saama vajaliku dokumentide komplekti ja võrgu, mis on vastavalt neile konfigureeritud.
Praegu me turvaauditi teemast ei räägi – sellele on pühendatud kolmas osa.
Antud etapi ülesande täitmise keerukus varieerub kindlasti ettevõttest ettevõttesse.
Ideaalne olukord on see, kui
- teie võrk on loodud vastavalt projektile ja teil on täielik dokumentide komplekt
- teie ettevõttes on rakendatud võrgu
- selle protsessi kohaselt on teil olemas dokumendid (sh kõik vajalikud skeemid), mis annavad täieliku ülevaate aktuallsest olukorrast
Sel juhul on teie ülesanne üsna lihtne. Peate uurima dokumente ja vaatama üle kõik tehtud muudatused.
Halvimal juhul on teil
- võrk, mis on loodud ilma projektita, plaanita, ilma kooskõlastuseta, inseneride poolt, kellel pole piisavalt kvalifikatsiooni,
- kaootiliste, dokumenteerimata muudatustega, palju 'prügi' ja mitteoptimeeritud lahendustega
On selge, et teie olukord jääb kuskile vahepeale, kuid kahjuks näitab see skaala, et te tõenäoliselt olete lähemal halvemale otsale.
Sel juhul peate suutma lugeda mõtteid, sest peate õppima mõistma, mida ‘disainerid’ soovisid teha, taastama nende loogika, lõpetama lõpetamata tööd ja eemaldama ‘prügi’.
Ja loomulikult peate nende vigu kõrvaldamiseks, muutma (selle etapi jaoks niinimetatud minimaalselt) disaini ja muutma või uuesti looma skeeme.
Käesolev artikkel ei pretendeeri kindlasti täielikkusele. Kirjeldan vaid üldiseid põhimõtteid ja peatun mõnede levinud probleemide peal, millega tuleks tegelema.
Dokumentide kogum
Alustame näitest.
Allpool on toodud mõned dokumendid, mida on tavaks koostada ettevõttes Cisco Systems projekteerimise käigus.
CR – Klientide nõuded, nõuded kliendi (tehniline ülesanne).
Koostatakse koostöös kliendiga ja määratleb võrgu nõuded.HLD – Kõrgetasemeline disain, kõrgema taseme disain võrgu nõuete (CR) alusel. Dokumendis selgitatakse ja põhjendatakse vastuvõetud arhitektuurilisi otsuseid (topoloogia, protokollid, seadmete valik,…). HLD ei sisalda disainidetaile, näiteks kasutatavaid liideseid ja IP-aadresse. Samuti ei käsitleta siin seadmete konkreetset konfiguratsiooni. See dokument on pigem mõeldud kliendi tehnilisele juhtkonnale disaini põhikontseptsioonide selgitamiseks.
LLD – Madalatasemeline disain, madalama taseme disain kõrgema taseme (HLD) alusel.
See peab sisaldama kõiki üksikasju, mis on vajalikud projekti elluviimiseks, näiteks teavet seadmete ühendamise ja konfigureerimise kohta. See on täielik juhend disaini elluviimiseks. See dokument peab andma piisavalt teavet selle rakendamiseks isegi vähem kvalifitseeritud personali poolt.Mõned, näiteks IP-aadressid, AS-numbrid, füüsilise ühenduse skeem (kaabeldus), võib "välja kanda" eraldi dokumentidesse, nagu NIP (Võrgu rakenduskava).
Võrgu loomine algab nende dokumentide koostamisest ja toimub nende alusel, seejärel kontrollitakse (testitakse) klientide poolt vastavust disainile.
Muidugi, erinevatel integratoritel, erinevates klientides ja erinevates riikides võivad projektdokumentatsiooni nõuded olla erinevad. Kuid sooviks vältida formaalsusi ja käsitleda küsimust sisuliselt. See etapp ei ole projekteerimise, vaid korrastamise teemal ning me vajame oma ülesannete täitmiseks piisavalt dokumente (skeeme, tabeleid, kirjeldusi ...).
Ja minu arvates on olemas teatud absoluutne miinimum, ilma milleta ei ole võimalik tõhusalt võrku kontrollida.
Need dokumendid on:
- füüsilise ühenduse skeem (cabling) (ajakirja)
- võrgu skeem või skeemid, mis sisaldavad olulist L2/L3 teavet
Füüsilise ühenduse skeem
Mõnedes väikestes ettevõtetes on seadmete paigaldamise ja füüsilise ühenduse (cabling) tööd võrguinseneride vastutusalas.
Sellisel juhul lahendatakse ülesanne osaliselt järgmise lähenemisega.
- Kasutage liidese kirjelduse abil selle külge ühendatud seadmeid.
- haldirge administratiivselt kõik ühendamata võrgu seadmete portid
See annab teile võimaluse, isegi juhul, kui link on probleemne (kui sellel liidese ei tööta cdp või lldp), kiiresti kindlaks teha, mis on seotud selle portiga.
Samuti näete kergesti, millised portid on hõivatud ja millised on vabad, mis on vajalik uue võrgu seadmete, serverite või tööjaamade ühendamise planeerimiseks.
Aga selge on, et kui kaotate juurdepääsu seadmele, siis kaotate ka juurdepääsu sellele teabele. Lisaks ei saa te sellist olulist teavet nagu see, milline seade, milline on selle voolutarve, kui palju porte on, millises rack'is see asub, millised seal on patch-paneelid ja kuhu (millises rack'is/patch-paneelis) nad on ühendatud, protokollida. Seega on ikka veel lisadokumendid (mitte ainult seadmete kirjeldused) väga kasulikud.
Ideaalne lahendus on kasutada rakendusi, mis on loodud sellise teabe töötlemiseks. Kuid võite piirduda ka lihtsate tabelitega (näiteks Excelis) või kuvada teavet, mida peate vajalikuks L1/L2 skeemidel.
Oluline!
Võrgutehnik võib muidugi üsna hästi tunda struktuursete kaablite süsteemide, rackide tüüpide, katkematute toiteallikate, külmade ja kuumade koridoride eripärasid ning teha ka õiget maandust, ... just nagu ta võib tunda elementaarosakeste füüsikat või C++. Kuid tuleb mõista, et kõik see ei ole tema teadmiste valdkond.
Seetõttu on hea praktika, et seadmete paigaldamise, ühendamise, töökindluse säilitamise ja füüsilise ühendamisega seotud ülesannete lahendamiseks oleksid olemas kas spetsialiseeritud osakonnad või eraldatud inimesed. Tüüpiliselt on andmekeskustes need andmekeskuse insenerid, kontoris aga help-desk.
Kui teie ettevõttes on sellised osakonnad, siis füüsilise ühenduse logimise küsimused ei kuulu teie ülesannete hulka ning saate piirduda ainult liidese kirjeldamise ja kasutamata portide haldamisega.
Võrguskeemid
Pole ühtset lähenemist skeemide joonistamiseks.
Kõige olulisem on, et skeemid peaksid andma aru sellest, kuidas liiklus liigub, läbi milliste loogiliste ja füüsiliste elementide teie võrgus.
Füüsiliste elementide all mõtleme
- aktiivsetele seadmetele
- aktiivsete seadmete liidestele/portidele
Loogilised —
- loogilised seadmed (N7K VDC, Palo Alto VSYS, …)
- VRF
- VLAN-id
- alamliidesed
- tunnelid
- alad
- …
Samuti, kui teie võrk ei ole täiesti elementaarne, koosneb see erinevatest segmentidest.
Piemēram
- andmekeskus
- interneti
- WAN
- eem access
- kontori LAN
- DMZ
- …
Mõistlik on omada mitmeid skeeme, mis annavad nii üldise ülevaate (kuidas liiklus liigub nende segmentide vahel) kui ka iga eraldi segmenti selgitavat detailset kirjeldust.
Kuna tänapäevastes võrkudes võib olla palju loogilisi tasemeid, on hea (kuid mitte kohustuslik) lähenemine erinevate skeemide loomine erinevate tasemete jaoks. Näiteks katte lähenemise korral võivad need olla järgmised skeemid:
- kate
- L1/L2 alus
- L3 alus
Loomulikult on kõige olulisem skeem, ilma milleta ei ole võimalik mõista teie disaini ideed, marsruutimise skeem.
Marsruutimise skeem
Minimaalselt peaks sellel skeemil olema kajastatud
- millised marsruutimise protokollid ja kus neid kasutatakse
- peamised andmed marsruutimise protokolli seadistuste kohta (area/AS number/router-id/…)
- millistel seadmetel toimub ümberjaotamine
- kus toimub marsruutide filtreerimine ja agregatsioon
- teave vaike marsruudi kohta
Samuti on sageli kasulik L2 skeem (OSI).
L2 skeem (OSI)
Sellel skeemil võib olla kajastatud järgmised andmed:
- millised VLAN-id
- millised portid on trunk-portid
- millised portid on kogutud ether-channel'i (port channel), virtuaalport channel'i
- millised STP protokollid ja millistel seadmetel neid kasutatakse
- peamised STP seaded: root/root backup, STP hind, porta prioritiseerimine
- lisaseaded STP: BPDU guard/filter, root guard…
Tüüpilised vead projekteerimisel
Halva lähenemisviisi näide võrgu ehitamiseks.
Võtame lihtsa näite lihtsa büroovõrgu ehitamisest.
Olles õpetanud telekommunikatsiooni tudengeid, võin öelda, et tegelikult omab igaühel tudengist, kes on läbinud minu kursuse, keskmiselt teisel semestril vajalikud teadmised lihtsa büroo LAN-i seadistamiseks.
Mis on keeruline, et ühendada lülitid, seadistada VLAN, SVI liideseid (L3 lülitite puhul) ja kirjutada staatiline marsruutimine?
Kõik töötab.
Kuid samas jäävad kõrvale küsimused, mis on seotud
- turvalisus
- varundamisega
- võrgu skaaleerimisega
- tõhususe
- läbipaistvusega
- usaldusväärsusega
- …
Aeg-ajalt kuulen väidet, et büroovõrk on midagi väga lihtsat ja tavaliselt kuulen seda inseneridelt (ja juhtidelt), kes tegelevad millegagi, aga mitte võrkudega, ning nad ütlevad seda nii kindlalt, et ärge imestage, kui LAN-i teevad inimesed, kellel on ebapiisav praktika ja teadmised ning see tehakse enam-vähem nendega vigadega, mida ma kirjeldan veidi allpool.
Iseloomulikud L1 (OSI) taseme disainivead
- Kui te siiski vastutate ka SKS-i eest, on üks ebameeldivamaid pärandusi, mis teile võimalik, see hajameelne ja läbimõtlemata kommutatsioon.
Samuti kuuluks L1 tüüpi vigu varustuse ressursse, mida kasutatakse, näiteks,
- piisav läbilaskevõime
- ebapiisav TCAM seadmetes (või selle ebaefektiivne kasutamine)
- ebapiisav jõudlus (tihti viitab tulemüüridele)
Iseloomulikud L2 (OSI) taseme disainivead
Tihti, kui puudub hea arusaam STP toimimisest ja sellega kaasnevatest potentsiaalsetest probleemidest, ühendatakse lülitid kaootiliselt, vaikeparameetritega, ilma STP täiendava häälestamiseta.
Kaasnevad tulemused on tihti järgmised
- suur STP võrgu diameeter, mis võib põhjustada broudcast-torme
- STP juur määratakse juhuslikult (MAC-aadressi põhjal) ja liiklusteed on suboptimaalsed
- pordid, mis on ühendatud hostide juurde, ei ole seadistatud kui edge (portfast), mis viib STP ülekalkuleerimisele lõppjaamade sisse- ja väljalülitamisel
- võrk ei ole segmenteeritud L1/L2 tasemel, mis tähendab, et probleemid mõne lülitiga (näiteks jõuülekoormus) viivad STP topoloogia ümberarvutamiseni ja liikluse peatamiseni kõikides VLANides kõikidel lülititel (sealhulgas kriitilises teeninduskontinuiteti osas).
L3 (OSI) projekteerimise vead
Mõned tüüpilised algajate võrguspetsialistide vead:
- sagedane (või ainult) staatilise marsruutimise kasutamine
- ebasobivate marsruutimisprotokollide kasutamine antud disainile
- ebasobiv loogiline võrgu segmentatsioon
- ebasobiv adresseerimisruumi kasutamine, mis ei võimalda marsruutide agregatsiooni
- varumarsruutide puudumine
- default gateway'i reservatsiooni puudumine
- asümmeetriline marsruutimine marsruutide ümberkorraldamisel (võib olla kriitiline NAT/PAT, stateful tulemüüride korral)
- MTU probleemid
- marsruutide ümberkorraldamisel liigub liiklus läbi teiste turvazoonide või isegi teiste tulemüüride, mis viib selle liikluse kadumiseni
- topoloogia halb skaleeritavus
Disaini kvaliteedi hindamise kriteeriumid
Rääkides optimaalsusest/ mitteoptimaalsusest, peame mõistma, milliste kriteeriumide alusel saame seda hinnata. Minu arvates on kõige olulisemad (aga mitte kõik) kriteeriumid (ja nende selgitused marsruutimisprotokollide kontekstis):
- skaleeritavus (scalability)
Näiteks, kui otsustate lisada veel ühe andmekeskuse. Kui lihtne on teil seda teha? - haldamise mugavus (managability)
Kui hõlpsasti ja ohutult sujuvad operatiivsed muudatused, näiteks uue võrgu teavitamine või marsruutide filtreerimine? - saadavus (availability)
Mis protsent ajast suudab teie süsteem pakkuda nõutud teenuse taset? - turvalisus (security)
Kui kaitstud on edastatud andmed? - hind
Muutused
Peamine põhimõte sel etapil võiks väljenduda valemiga 'ära tee kahju'.
Seetõttu, isegi kui te pole täiesti nõus disaini ja valitud rakendusega (konfiguratsiooniga), ei ole alati mõistlik muudatusi teha. Mõistlik lähenemine on kõikide tuvastatud probleemide liigitamine kahe parameetri alusel:
- kui kergesti saab seda probleemi lahendada
- kui suurrisk see kujutab endast
Esiteks tuleb kõrvaldata kõik, mis praegu alandab pakutava teenuse taset lubatust madalamale, nagu näiteks probleemid, mis põhjustavad pakettide kaotust. Seejärel kõrvalda need probleemid, mis on kergemad ja ohutumaid kõrvaldada, järjestades neid vastavalt riskide tõsidusele (alustades probleemidest, mis disainide või konfiguratsioonide tõttu kannavad suuremaid riske kuni väiksemateni).
Perfektsionism sel etapil võib olla kahjulik. Viige disain rahuldavasse seisundisse ja sünkroniseerige võrgukonfiguratsioon vastavalt sellele.
Allikas: habr.com
