Bu makale, “Ağ altyapınızın kontrolünü nasıl ele geçirirsiniz?” başlıklı bir dizi makalenin ikincisidir. Serideki tüm yazıların içeriğine ve bağlantılara ulaşabilirsiniz .
Bu aşamada amacımız dokümantasyon ve konfigürasyona düzen getirmektir.
Bu sürecin sonunda gerekli belge setine ve bunlara uygun yapılandırılmış bir ağa sahip olmalısınız.
Şimdi güvenlik denetimlerinden bahsetmeyeceğiz - bu üçüncü bölümün konusu olacak.
Bu aşamada verilen görevi tamamlamanın zorluğu elbette şirketten şirkete büyük farklılıklar gösteriyor.
İdeal durum şu:
- ağınız projeye uygun olarak oluşturuldu ve eksiksiz bir belge setine sahipsiniz
- şirketinizde uygulandı ağ için
- bu sürece uygun olarak, mevcut durum hakkında eksiksiz bilgi sağlayan belgeleriniz (gerekli tüm diyagramlar dahil) var
Bu durumda göreviniz oldukça basittir. Belgeleri incelemeli ve yapılan tüm değişiklikleri gözden geçirmelisiniz.
En kötü senaryoda, sahip olacaksınız
- Projesiz, plansız, onaysız, yeterli niteliklere sahip olmayan mühendisler tarafından oluşturulan bir ağ,
- kaotik, belgelenmemiş değişikliklerle, çok sayıda “çöp” ve optimal olmayan çözümlerle
Durumunuzun arada bir yerde olduğu açık, ancak ne yazık ki, bu daha iyi - daha kötü ölçeğinde, en kötü sona yaklaşma olasılığınız yüksek.
Bu durumda, zihin okuma yeteneğine de ihtiyacınız olacak çünkü "tasarımcıların" ne yapmak istediğini anlamayı, mantıklarını yeniden kurmayı, bitmemiş olanı bitirmeyi ve "çöpü" kaldırmayı öğrenmeniz gerekecek.
Ve elbette, hatalarını düzeltmeniz, tasarımı değiştirmeniz (bu aşamada mümkün olduğunca minimum düzeyde) ve şemaları değiştirmeniz veya yeniden oluşturmanız gerekecektir.
Bu makale hiçbir şekilde eksiksiz olduğunu iddia etmemektedir. Burada yalnızca genel ilkeleri anlatacağım ve çözülmesi gereken bazı ortak sorunlara odaklanacağım.
Belge kümesi
Bir örnekle başlayalım.
Aşağıda tasarım sırasında Cisco Systems'de geleneksel olarak oluşturulan bazı belgeler bulunmaktadır.
CR – Müşteri Gereksinimleri, müşteri gereksinimleri (teknik özellikler).
Müşteri ile ortaklaşa oluşturularak ağ gereksinimlerini belirler.HLD – Yüksek Düzey Tasarım, ağ gereksinimlerine (CR) dayalı üst düzey tasarım. Belge, alınan mimari kararları (topoloji, protokoller, donanım seçimi,...) açıklıyor ve gerekçelendiriyor. HLD, kullanılan arayüzler ve IP adresleri gibi tasarım ayrıntılarını içermez. Ayrıca spesifik donanım konfigürasyonu burada tartışılmamaktadır. Daha ziyade bu belge, temel tasarım kavramlarını müşterinin teknik yönetimine açıklamayı amaçlamaktadır.
EUE – Düşük Seviyeli Tasarım, yüksek seviyeli tasarıma (HLD) dayalı düşük seviyeli tasarım.
Ekipmanın nasıl bağlanacağı ve yapılandırılacağına ilişkin bilgiler gibi, projeyi uygulamak için gerekli tüm ayrıntıları içermelidir. Bu, tasarımın uygulanmasına yönelik eksiksiz bir kılavuzdur. Bu belge, daha az vasıflı personel tarafından bile uygulanması için yeterli bilgiyi sağlamalıdır.Örneğin IP adresleri, AS numaraları, fiziksel anahtarlama şeması (kablolama) gibi bir şey ayrı belgelerde "verilebilir"; NIP (Ağ Uygulama Planı).
Ağın inşası, bu belgelerin oluşturulmasından sonra başlar ve bunlara tam olarak uygun olarak gerçekleşir ve ardından müşteri tarafından tasarıma uygunluk açısından kontrol edilir (testler).
Elbette farklı entegratörlerin, farklı müşterilerin ve farklı ülkelerin proje dokümantasyonu konusunda farklı gereksinimleri olabilir. Ancak formalitelerden kaçınıp konuyu kendi esasları çerçevesinde ele almak istiyorum. Bu aşama tasarımla ilgili değil, işleri düzene koymakla ilgilidir ve görevlerimizi tamamlamak için yeterli sayıda belgeye (diyagramlar, tablolar, açıklamalar...) ihtiyacımız var.
Ve bana göre, ağı etkili bir şekilde kontrol etmenin imkansız olduğu belirli bir mutlak minimum var.
Bunlar aşağıdaki belgelerdir:
- fiziksel anahtarlamanın (kablolama) diyagramı (günlüğü)
- temel L2/L3 bilgilerini içeren ağ şeması veya şemaları
Fiziksel anahtarlama şeması
Bazı küçük şirketlerde ekipman kurulumu ve fiziksel anahtarlama (kablolama) ile ilgili işler ağ mühendislerinin sorumluluğundadır.
Bu durumda aşağıdaki yaklaşımla sorun kısmen çözülmektedir.
- ona neyin bağlı olduğunu açıklamak için arayüzde bir açıklama kullanın
- bağlı olmayan tüm ağ ekipmanı bağlantı noktalarını yönetimsel olarak kapatma
Bu size, bağlantıda bir sorun olması durumunda bile (cdp veya lldp bu arayüzde çalışmadığında), bu bağlantı noktasına neyin bağlı olduğunu hızlı bir şekilde belirleme fırsatı verecektir.
Ayrıca yeni ağ ekipmanlarının, sunucuların veya iş istasyonlarının bağlantılarını planlamak için gerekli olan bağlantı noktalarının dolu ve hangilerinin boş olduğunu kolayca görebilirsiniz.
Ancak ekipmana erişiminizi kaybederseniz bu bilgilere erişiminizi de kaybedeceğiniz açıktır. Ayrıca bu sayede ne tür ekipman, ne tür güç tüketimi, kaç port, hangi rafta olduğu, hangi patch panellerin orada ve nerede (hangi raf/patch panelde) gibi önemli bilgileri kayıt altına alamayacaksınız. ) bağlıdırlar. Bu nedenle, ek belgeler (yalnızca ekipmanla ilgili açıklamalar değil) hala çok faydalıdır.
İdeal seçenek, bu tür bilgilerle çalışmak üzere tasarlanmış uygulamaları kullanmaktır. Ancak kendinizi basit tablolarla (örneğin Excel'de) sınırlandırabilir veya gerekli olduğunu düşündüğünüz bilgileri L1/L2 diyagramlarında görüntüleyebilirsiniz.
Önemli!
Bir ağ mühendisi elbette SCS'nin inceliklerini ve standartlarını, raf türlerini, kesintisiz güç kaynağı türlerini, soğuk ve sıcak koridorun ne olduğunu, doğru topraklamanın nasıl yapılacağını oldukça iyi bilebilir... tıpkı prensipte olduğu gibi. Temel parçacıkların fiziğini veya C++'ı bilir. Ancak yine de tüm bunların onun bilgi alanı olmadığını anlamak gerekir.
Bu nedenle, kurulum, bağlantı, ekipmanın bakımı ve fiziksel anahtarlama ile ilgili sorunları çözmek için özel departmanların veya özel kişilerin bulunması iyi bir uygulamadır. Genellikle veri merkezleri için bu, veri merkezi mühendisleridir ve bir ofis için yardım masasıdır.
Şirketinizde bu tür bölümler sağlanmışsa, fiziksel geçişin günlüğe kaydedilmesi sorunları sizin göreviniz değildir ve kendinizi yalnızca arayüzdeki açıklama ve kullanılmayan bağlantı noktalarının idari olarak kapatılmasıyla sınırlayabilirsiniz.
Ağ diyagramları
Diyagram çizmeye yönelik evrensel bir yaklaşım yoktur.
En önemlisi diyagramların trafiğin nasıl akacağına, ağınızın hangi mantıksal ve fiziksel unsurları üzerinden bir anlayış sağlamasıdır.
Fiziksel unsurlar derken kast ettiğimiz
- aktif ekipman
- aktif ekipmanın arayüzleri/bağlantı noktaları
Mantıksal olarak -
- mantıksal cihazlar (N7K VDC, Palo Alto VSYS, ...)
- VRF uzantısı
- Villalar
- alt arayüzler
- tüneller
- bölge
- ...
Ayrıca ağınız tamamen temel değilse farklı segmentlerden oluşacaktır.
Örneğin
- veri merkezi
- Internet
- WAN
- uzaktan erişim
- ofis LAN'ı
- DMZ
- ...
Hem büyük resmi (trafiğin tüm bu bölümler arasında nasıl aktığını) hem de her bir bölümün ayrıntılı açıklamasını veren birkaç diyagramın olması akıllıca olacaktır.
Modern ağlarda birçok mantıksal katman olabildiği için, farklı katmanlar için farklı devreler oluşturmak belki de iyi (ancak gerekli olmayan) bir yaklaşımdır; örneğin, bir kaplama yaklaşımı durumunda bu, aşağıdaki devreler olabilir:
- kaplama
- L1/L2 altlığı
- L3 altlık
Elbette, tasarımınızın fikrini anlamanın imkansız olduğu en önemli diyagram, yönlendirme diyagramıdır.
Yönlendirme şeması
Bu diyagram en azından şunları yansıtmalıdır:
- Hangi yönlendirme protokolleri kullanılıyor ve nerede
- yönlendirme protokolü ayarları hakkında temel bilgiler (alan/AS numarası/yönlendirici kimliği/...)
- Yeniden dağıtım hangi cihazlarda gerçekleşir?
- filtreleme ve rota toplamanın gerçekleştiği yer
- varsayılan rota bilgisi
Ayrıca L2 şeması (OSI) sıklıkla faydalıdır.
L2 şeması (OSI)
Bu şema aşağıdaki bilgileri gösterebilir:
- hangi VLAN'lar
- hangi bağlantı noktaları ana bağlantı noktalarıdır
- hangi bağlantı noktaları eter kanalı (bağlantı noktası kanalı), sanal bağlantı noktası kanalında toplanır
- Hangi STP protokolleri kullanılıyor ve hangi cihazlarda
- temel STP ayarları: kök/kök yedekleme, STP maliyeti, bağlantı noktası önceliği
- ek STP ayarları: BPDU koruması/filtresi, kök koruması…
Tipik tasarım hataları
Ağ oluşturmaya yönelik kötü bir yaklaşım örneği.
Basit bir ofis LAN'ı oluşturmanın basit bir örneğini ele alalım.
Öğrencilere telekomünikasyon öğretme deneyimine sahip olduğum için, hemen hemen her öğrencinin ikinci yarıyılın ortasında basit bir ofis LAN'ı kurmak için gerekli bilgiye (öğrettiğim dersin bir parçası olarak) sahip olduğunu söyleyebilirim.
Anahtarları birbirine bağlamanın, VLAN'ları, SVI arayüzlerini (L3 anahtarları durumunda) kurmanın ve statik yönlendirmeyi ayarlamanın nesi bu kadar zor?
Her şey işe yarayacak.
Ancak aynı zamanda konuyla ilgili sorular
- güvenlik
- rezervasyon
- ağ ölçeklendirme
- üretkenlik
- verim
- güvenilirlik
- ...
Zaman zaman ofis LAN'ının çok basit bir şey olduğu ifadesini duyuyorum ve bunu genellikle ağlar dışında her şeyi yapan mühendislerden (ve yöneticilerden) duyuyorum ve bunu o kadar kendinden emin söylüyorlar ki, LAN'ın böyle bir şey yapmasına şaşırmayın. yeterli pratiğe ve bilgiye sahip olmayan kişiler tarafından yapılacak ve aşağıda anlatacağım hataların hemen hemen aynısı yapılacaktır.
Yaygın L1 (OSI) Tasarım Hataları
- Yine de SCS'den de sorumluysanız, alabileceğiniz en tatsız miraslardan biri dikkatsiz ve kötü düşünülmüş geçiştir.
Ayrıca, kullanılan ekipmanın kaynaklarıyla ilgili L1 tipi hataları da sınıflandırabilirim; örneğin,
- yetersiz bant genişliği
- Ekipmanda yetersiz TCAM (veya verimsiz kullanımı)
- yetersiz performans (genellikle güvenlik duvarlarıyla ilgilidir)
Yaygın L2 (OSI) Tasarım Hataları
Çoğu zaman, STP'nin nasıl çalıştığı ve beraberinde hangi potansiyel sorunları getirdiği konusunda iyi bir anlayış olmadığında, anahtarlar ek STP ayarlaması olmadan varsayılan ayarlarla düzensiz bir şekilde bağlanır.
Sonuç olarak, sıklıkla aşağıdaki durumlarla karşılaşırız
- yayın fırtınalarına yol açabilecek geniş STP ağ çapı
- STP kökü rastgele belirlenecek (mac adresine göre) ve trafik yolu optimalin altında olacak
- ana bilgisayarlara bağlı bağlantı noktaları uç (portfast) olarak yapılandırılmayacaktır; bu, uç istasyonları açarken/kapatırken STP'nin yeniden hesaplanmasına yol açacaktır
- ağ L1/L2 seviyesinde bölümlere ayrılmayacak, bunun sonucunda herhangi bir anahtarla ilgili problemler (örneğin aşırı güç) STP topolojisinin yeniden hesaplanmasına ve tüm anahtarlardaki tüm VLAN'lardaki trafiğin durdurulmasına yol açacaktır (anahtarlar dahil). süreklilik hizmet segmenti açısından kritik bir durum)
L3 (OSI) tasarımındaki hata örnekleri
Acemi ağ kullanıcılarının birkaç tipik hatası:
- Statik yönlendirmenin sık kullanımı (veya yalnızca kullanımı)
- Belirli bir tasarım için optimal olmayan yönlendirme protokollerinin kullanılması
- optimumun altındaki mantıksal ağ bölümlemesi
- rota toplamaya izin vermeyen adres alanının yetersiz kullanımı
- yedekleme yolu yok
- varsayılan ağ geçidi için rezervasyon yok
- Rotaları yeniden oluştururken asimetrik yönlendirme (NAT/PAT, durum bilgisi olan güvenlik duvarları durumunda kritik olabilir)
- MTU'daki sorunlar
- Rotalar yeniden oluşturulduğunda trafik diğer güvenlik bölgelerinden ve hatta diğer güvenlik duvarlarından geçer ve bu da trafiğin kesilmesine neden olur
- zayıf topoloji ölçeklenebilirliği
Tasarım kalitesini değerlendirme kriterleri
Optimumluk/optimalsizlikten bahsettiğimizde bunu hangi kriterlere göre değerlendirebileceğimizi anlamamız gerekiyor. Benim bakış açıma göre, en önemli (ama hepsi değil) kriterler (ve yönlendirme protokolleriyle ilgili açıklamalar):
- ölçeklenebilirlik
Örneğin başka bir veri merkezi eklemeye karar verdiniz. Bunu ne kadar kolay yapabilirsin? - kullanım kolaylığı (yönetilebilirlik)
Yeni bir şebekenin duyurulması veya rotaların filtrelenmesi gibi operasyonel değişiklikler ne kadar kolay ve güvenli? - kullanılabilirlik
Sisteminiz gerekli hizmet düzeyini yüzde kaç oranında sağlıyor? - güvenlik
İletilen veriler ne kadar güvenli? - fiyat
Değişiklikler
Bu aşamadaki temel prensip “zarar verme” formülüyle ifade edilebilir.
Bu nedenle, tasarım ve seçilen uygulama (konfigürasyon) ile tamamen aynı fikirde olmasanız bile, değişiklik yapmanız her zaman tavsiye edilmez. Makul bir yaklaşım, belirlenen tüm sorunları iki parametreye göre sıralamaktır:
- bu sorun ne kadar kolay çözülebilir
- ne kadar risk taşıyor?
Öncelikle sunulan hizmetin seviyesini kabul edilebilir seviyenin altına düşüren, örneğin paket kaybına yol açan sorunları ortadan kaldırmak gerekiyor. Ardından, risk ciddiyetine göre azalan sırada düzeltilmesi en kolay ve en güvenli olanı düzeltin (yüksek riskli tasarım veya yapılandırma sorunlarından düşük riskli olanlara doğru).
Bu aşamada mükemmeliyetçilik zararlı olabilir. Tasarımı tatmin edici bir duruma getirin ve ağ yapılandırmasını buna göre senkronize edin.
Kaynak: habr.com