Artikulu hau "Nola hartu zure sareko azpiegituraren kontrola" artikulu sorta bateko bigarrena da. Serieko artikulu guztien edukia eta estekak aurki daitezke .
Fase honetan gure helburua dokumentazioan eta konfigurazioan ordena jartzea da.
Prozesu honen amaieran, beharrezko dokumentu-multzoa eta horien arabera konfiguratuta egon beharko zenuke sare bat.
Orain ez dugu segurtasun-ikuskaritzari buruz hitz egingo - hau izango da hirugarren zatiaren gaia.
Etapa honetan esleitutako zeregina betetzeko zailtasuna, noski, asko aldatzen da enpresa batetik bestera.
Egoera ideala noiz da
- zure sarea proiektuaren arabera sortu zen eta dokumentu multzo osoa duzu
- zure enpresan ezarri da sarerako
- prozesu horren arabera, egungo egoerari buruzko informazio osoa ematen duten dokumentuak dituzu (beharrezko diagrama guztiak barne).
Kasu honetan, zure zeregina nahiko erraza da. Dokumentuak aztertu eta egindako aldaketa guztiak aztertu behar dituzu.
Kasurik txarrenean, izango duzu
- proiekturik gabe, planik gabe, onespenik gabe sortutako sarea, behar adina kualifikazio-maila ez duten ingeniariek,
- Aldaketa kaotikoekin, dokumentatu gabekoekin, “zabor” askorekin eta irtenbide optimoekin
Argi dago zure egoera tartean dagoela, baina, zoritxarrez, eskala hobean - okerragoan, mutur txarrenetik gertuago egoteko probabilitate handia dago.
Kasu honetan, adimenak irakurtzeko gaitasuna ere beharko duzu, “diseinatzaileek” zer egin nahi zuten ulertzen ikasi beharko duzulako, haien logika berreskuratu, amaitu ez zena amaitu eta “zaborra” kendu.
Eta, noski, haien akatsak zuzendu beharko dituzu, diseinua aldatu (etapa honetan ahalik eta gutxien) eta eskemak aldatu edo birsortu beharko dituzu.
Artikulu honek inola ere ez du osoa denik. Hemen printzipio orokorrak soilik deskribatuko ditut eta konpondu beharreko arazo arrunt batzuetan zentratuko naiz.
Dokumentu multzoa
Has gaitezen adibide batekin.
Jarraian, diseinuan Cisco Systems-en sortu ohi diren dokumentu batzuk daude.
CR – Bezeroaren eskakizunak, bezeroen eskakizunak (zehaztapen teknikoak).
Bezeroarekin batera sortzen da eta sarearen eskakizunak zehazten ditu.HLD – Goi Mailako Diseinua, sareko eskakizunetan (CR) oinarritutako goi-mailako diseinua. Dokumentuak hartutako erabaki arkitektonikoak (topologia, protokoloak, hardware aukeraketa,...) azaltzen eta justifikatzen ditu. HLD-k ez ditu diseinuaren xehetasunak, hala nola erabiltzen diren interfazeak eta IP helbideak. Gainera, hardware konfigurazio espezifikoa ez da hemen eztabaidatzen. Aitzitik, dokumentu honek diseinuaren funtsezko kontzeptuak bezeroaren zuzendaritza teknikoari azaltzea du helburu.
LLD – Behe Level Design, goi-mailako diseinuan (HLD) oinarritutako behe-mailako diseinua.
Proiektua gauzatzeko beharrezkoak diren xehetasun guztiak eduki behar ditu, hala nola ekipoak konektatu eta konfiguratzeko informazioa. Diseinua ezartzeko gida osoa da. Dokumentu honek informazio nahikoa eman behar du ezartzeko, nahiz eta gaitasun gutxiko langileek.Zerbait, adibidez, IP helbideak, AS zenbakiak, kommutazio eskema fisikoa (kableatzea), dokumentu bereizietan "atera" daiteke, adibidez PINa (Sarea Ezartzeko Plana).
Sarearen eraikuntza dokumentu hauek sortu ondoren hasten da eta haiekin bat etorriz gertatzen da eta gero bezeroak egiaztatzen du (probak) diseinua betetzen dela.
Jakina, integratzaile ezberdinek, bezero ezberdinek eta herrialde ezberdinek eskakizun desberdinak izan ditzakete proiektuaren dokumentaziorako. Baina izapideak saihestu eta gaia bere merituetan kontuan hartu nahiko nuke. Etapa hau ez da diseinua, gauzak ordenatzea baizik, eta gure zereginak burutzeko nahikoa dokumentu (diagramak, taulak, deskribapenak...) behar ditugu.
Eta nire ustez, gutxieneko absolutu bat dago, eta hori gabe ezinezkoa da sarea eraginkortasunez kontrolatzea.
Hauek dira dokumentu hauek:
- kommutazio fisikoaren (kableatzea) diagrama (erregistroa)
- sare-diagrama edo L2/L3 funtsezko informazioa duten diagramak
Kommutazio-diagrama fisikoa
Enpresa txiki batzuetan, ekipoen instalazioarekin eta kommutazio fisikoarekin (kableatzea) lotutako lanak sareko ingeniarien ardura dira.
Kasu honetan, arazoa neurri batean konpontzen da hurrengo ikuspegiarekin.
- erabili interfazeko deskribapen bat harekin konektatuta dagoena deskribatzeko
- konektatu gabeko sareko ekipoen ataka guztiak administratiboki itxi
Honek aukera emango dizu, estekarekin arazoren bat izanez gero (cdp edo lldp interfaze honetan funtzionatzen ez dutenean), ataka honetara zer konektatuta dagoen azkar zehazteko.
Era berean, erraz ikus dezakezu zein portu okupatuta dauden eta zeintzuk aske dauden, sareko ekipo, zerbitzari edo lan-estazio berrien konexioak planifikatzeko beharrezkoa dena.
Baina argi dago ekipamendurako sarbidea galtzen baduzu, informazio hori ere galduko duzula. Gainera, horrela, ezin izango duzu hain informazio garrantzitsua grabatu nolako ekipoa, zer energia-kontsumoa, zenbat ataka, zer racktan dagoen, zer adabaki panel dauden eta non (zein rack/patch panel). ) lotuta daude . Hori dela eta, dokumentazio osagarria (ez soilik ekipoari buruzko deskribapenak) oso erabilgarria da oraindik.
Aukera aproposa informazio mota honekin lan egiteko diseinatutako aplikazioak erabiltzea da. Baina taula errazetara muga zaitezke (adibidez, Excel-en) edo beharrezkotzat jotzen duzun informazioa L1/L2 diagrametan bistaratu.
Garrantzitsua da!
Sare-ingeniari batek, noski, nahiko ondo ezagutu ditzake SCS-en konplexutasun eta estandarrak, bastidore motak, etenik gabeko elikadura-iturri motak, korridore hotza eta beroa zer den, lurra nola egin behar den... printzipioz egin dezakeen moduan. oinarrizko partikulen fisika edo C++ ezagutzea. Baina ulertu behar da hori guztia ez dela bere jakintza-eremua.
Hori dela eta, praktika ona da sail dedikatuak edo pertsona dedikatuak izatea instalazioarekin, konexioarekin, ekipoen mantentzearekin eta aldaketa fisikoarekin lotutako arazoak konpontzeko. Normalean datu-zentroentzat datu-zentroko ingeniariak dira, eta bulego batentzat laguntza mahaia da.
Zure enpresan zatiketa horiek ematen badira, aldaketa fisikoa erregistratzeko arazoak ez dira zure zeregina, eta erabili gabeko portuen interfazearen eta administrazio-itxialdiaren deskribapenera soilik muga zaitezke.
Sare-diagramak
Ez dago diagramak marrazteko ikuspegi unibertsala.
Garrantzitsuena zera da, diagramek trafikoa nola igaroko den, zeinen bidez zure sareko elementu logiko eta fisikoen bidez ulertu behar dutela.
Elementu fisikoekin esan nahi dugu
- ekipamendu aktiboa
- ekipo aktiboen interfazeak/atatuak
Logikoaren azpian -
- gailu logikoak (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Vilans
- azpiinterfazeak
- tunelak
- zona
- ...
Gainera, zure sarea guztiz oinarrizkoa ez bada, segmentu ezberdinez osatuta egongo da.
Adibidez
- datu-zentroa
- Internet
- WAN
- urruneko sarbidea
- bulegoko LAN
- DMZ
- ...
Komeni da irudi orokorra (segmentu horien guztien artean trafikoa nola doan) eta segmentu bakoitzaren azalpen zehatza ematen duten hainbat diagrama izatea.
Sare modernoetan geruza logiko asko egon daitezkeenez, beharbada hurbilketa ona da (baina ez beharrezkoa) geruza ezberdinetarako zirkuitu desberdinak egitea, adibidez, gainjarritako hurbilketa baten kasuan honako zirkuitu hauek izan daitezke:
- overlay
- L1/L2 azpiko geruza
- L3 azpiko geruza
Jakina, diagrama garrantzitsuena, zeina gabe ezinezkoa baita zure diseinuaren ideia ulertzea, bideratze diagrama da.
Bideratze-eskema
Gutxienez, diagrama honek islatu beharko luke
- zer bideratze-protokolo erabiltzen diren eta non
- Bideratze-protokoloaren ezarpenei buruzko oinarrizko informazioa (area/AS zenbakia/router-id/...)
- zein gailutan gertatzen da birbanaketa?
- non iragazketa eta ibilbideen agregazioa gertatzen den
- lehenetsitako ibilbidearen informazioa
Gainera, L2 eskema (OSI) erabilgarria da askotan.
L2 eskema (OSI)
Diagrama honek informazio hau ager dezake:
- zer VLANak
- zein portuak diren enbor-atalak
- zein portuak ether-kanalean (portu-kanala) bateratzen diren, portu birtualeko kanalean
- zer STP protokolo erabiltzen diren eta zer gailutan
- Oinarrizko STP ezarpenak: root/root backup, STP kostua, portuaren lehentasuna
- STP ezarpen gehigarriak: BPDU babesa/iragazkia, erro babesa...
Diseinu-akats tipikoak
Sare bat eraikitzeko ikuspegi txarraren adibidea.
Har dezagun adibide sinple bat bulegoko LAN soil bat eraikitzeko.
Ikasleei telekomunikazioak irakasten esperientzia dudanez, esan dezaket ia edozein ikaslek duela bigarren seihilekoaren erdialderako beharrezko ezagutzak (irakasten nituen ikastaroaren zati gisa) bulegoko LAN soil bat ezartzeko.
Zer da hain zaila etengailuak elkarren artean konektatzea, VLANak konfiguratzea, SVI interfazeak (L3 etengailuen kasuan) eta bideratze estatikoa konfiguratzea?
Dena funtzionatuko du.
Baina, aldi berean, lotutako galderak
- segurtasuna
- erreserba
- sarearen eskalatzea
- produktibitatea
- errendimendua
- fidagarritasuna
- ...
Noizean behin, bulegoko LAN bat zerbait oso sinplea dela entzuten dut eta normalean sareak izan ezik dena egiten duten ingeniariei (eta kudeatzaileei) entzuten diet hori, eta hori hain konfiantzaz esaten dute, ezen harritu LANa izango balitz. praktika eta ezagutza nahikorik ez duten pertsonek eginak eta gutxi gorabehera jarraian deskribatuko ditudan akats berdinekin egingo dira.
Ohiko L1 (OSI) Diseinu akatsak
- Hala ere, SCSren arduraduna ere bazara, orduan jaso dezakezun ondare desatseginenetako bat arduragabekeria eta gaizki pentsatutako aldaketa da.
Erabiltzen diren ekipoen baliabideekin lotutako L1 motako erroreak ere sailkatuko nituzke, adibidez,
- banda zabalera nahikoa ez
- ekipoetan TCAM nahikoa (edo erabilera ez eraginkorra)
- errendimendu nahikoa (askotan suebakiekin erlazionatuta)
Ohiko L2 (OSI) Diseinu akatsak
Askotan, STP-k nola funtzionatzen duen eta zer arazo potentzial ekartzen dituen ondo ulertzen ez denean, etengailuak modu kaotikoan konektatzen dira, ezarpen lehenetsiekin, STP sintonizazio gehigarririk gabe.
Ondorioz, askotan honako hauek ditugu
- STP sarearen diametro handia, eta horrek ekaitzak ekar ditzake
- STP erroa ausaz zehaztuko da (mac helbidean oinarrituta) eta trafikoaren bidea optimoa izango da
- ostalariekin konektatutako atakak ez dira ertz gisa (portfast) konfiguratuko, eta horrek STP birkalkulatuko du amaierako geltokiak piztean/desaktibatuta.
- sarea ez da L1/L2 mailan segmentatuko, eta, ondorioz, edozein etengailuren arazoek (adibidez, potentzia gainkargak) STP topologiaren birkalkulua ekarriko dute eta VLAN guztietan trafikoa geldiaraziko dute switch guztietan (barne. kritiko bat jarraitutasun zerbitzuaren segmentuaren ikuspuntutik)
L3 (OSI) diseinuko akatsen adibideak
Saregile hasiberrien ohiko akats batzuk:
- Bideratze estatikoa maiz erabiltzea (edo soilik erabiltzea).
- diseinu jakin baterako bideratze-protokolo optimoen erabilera
- sare logikoen segmentazio optimoa
- helbide-espazioaren erabilera ez-optimoa, bideen agregazioa onartzen ez duena
- segurtasun-biderik ez
- atebide lehenetsirako erreserbarik ez
- bideratze asimetrikoa ibilbideak berreraikitzean (kritikoa izan daiteke NAT/PAT, egoera osoko suebakien kasuan)
- MTUrekin arazoak
- Ibilbideak berreraikitzen direnean, trafikoa beste segurtasun gune batzuetatik edo beste suebakietatik igarotzen da, eta horrek trafiko hori kentzea dakar.
- topologia eskalagarritasun eskasa
Diseinuaren kalitatea ebaluatzeko irizpideak
Optimutasunaz/ez-optimoaz hitz egiten dugunean, hau zein irizpide ebaluatu dezakegunaren ikuspuntutik ulertu behar dugu. Hona hemen, nire ikuspuntutik, irizpide esanguratsuenak (baina ez guztiak) (eta azalpena bideratze-protokoloei dagokienez):
- eskalagarritasuna
Adibidez, beste datu-zentro bat gehitzea erabakitzen duzu. Zein erraz egin dezakezu? - erabiltzeko erraztasuna (kudeagarritasuna)
Zeinen errazak eta seguruak dira aldaketa operatiboak, hala nola sare berri bat iragartzea edo ibilbideak iragaztea? - erabilgarritasuna
Zure sistemak denboraren zein ehuneko eskaintzen du behar den zerbitzu-maila? - segurtasuna
Zenbateko segurua da transmititutako datuak? - prezioa
aldaketak
Etapa honetako oinarrizko printzipioa "ez egin kalterik" formularen bidez adieraz daiteke.
Hori dela eta, diseinuarekin eta aukeratutako ezarpenarekin (konfigurazioarekin) guztiz ados ez egon arren, ez da beti komeni aldaketak egitea. Zentzuzko ikuspegi bat identifikatutako arazo guztiak bi parametroren arabera sailkatzea da:
- zein erraz konpondu daitekeen arazo hau
- zenbat arrisku hartzen du?
Lehenik eta behin, beharrezkoa da gaur egun ematen den zerbitzu-maila maila onargarritik behera murrizten duena desagerrarazi, adibidez, paketeak galtzea eragiten duten arazoak. Ondoren, konpondu errazena eta seguruena arriskuaren larritasunaren hurrenkeraren arabera (arrisku handiko diseinu edo konfigurazio arazoetatik arrisku baxukoetara).
Perfekzionismoa fase honetan kaltegarria izan daiteke. Ekarri diseinua egoera egokira eta sinkronizatu sarearen konfigurazioa horren arabera.
Iturria: www.habr.com