W każdej szanującej się sieci komputerowej musimy zadbać o tak zwaną redundancję usług i urządzeń. Awarie sprzętu i oprogramowania mogą przydarzyć się każdemu ale już przestój i niemożność realizowania usług jest stanem bardzo niepożądanym ponieważ gdy sytuacja taka zaistnieje, wiąże się ona najczęściej ze stratami finansowymi. Tak więc aby zapewnić ciągłość pracy naszej sieci nie możemy dopuścić do scenariusza w którym jej praca uzależniona jest od działania jednego urządzenia. Jeden kontroler domeny może więc stać się źródłem potencjalnych problemów. Gdy host sprawujący kontrolę nad naszą domeną działa wszystko jest w porządku lecz w przypadku jego niedostępności nasza sieć "leży". Aby do takiej sytuacji nie dopuścić należałoby zdublować pełnione przez niego funkcje tak by w przypadku ewentualnych problemów inny host mógł przejąć jego zadania. A więc zapraszam do lektury wpisu traktującego o redundancji usług Active Directory.

W artykule tym kontynuujemy tematykę związaną z wykorzystaniem cmdletów PowerShell. Omówimy sposoby konfiguracji interfejsów sieciowych, uruchomienie Pulpitu zdalnego oraz zestawienie sesji zdalnej PowerShell.

Switche tak jak i routery podatne są na wiele ataków dlatego też większość technik zabezpieczania routerów ma zastosowanie również do switchy. Przełączniki jednak z natury swego działania i umiejscowienia dodatkowo narażone są na wiele innych ataków, specyficznych dla tej grupy urządzeń.

Zarządzając daną siecią komputerową najkorzystniejszą dla Nas sytuacją i stanem jak najbardziej pożądanym jest prawidłowo działająca sieć. Nasze wszystkie działania administracyjne sprowadzają się do tego by osiągnąć stan pełnej funkcjonalności sieci. Jeśli wszystko działa - możemy być z siebie dumni lecz nie oznacza to, że możemy spocząć na laurach. Awarie sieci i urządzeń ją tworzących są na porządku dziennym i prędzej czy później każdy administrator z takim problemem będzie musiał się zmierzyć. Z reguły awarie i mogące nastąpić komplikacje w działaniu sieci można z dość dużą dozą prawdopodobieństwa przewidzieć. No chyba, że mamy do czynienia z sytuacją nagłą, taką jak przepięcie w sieci elektrycznej, której efektem jest uszkodzenie urządzenia bądź atakiem hackerskim. Ale jak to już w życiu bywa nie do końca na wszystko mamy wpływ.

Jak wiadomo aby host mógł prowadzić poprawną komunikację z innymi urządzeniami budującymi naszą sieć komputerową (inne komputery, serwery, drukarki), host ten musi mieć przypisany poprawny adres IP i maskę sieci a aby uzyskać połączenie z Internetem również adres bramy i serwera (bądź serwerów) DNS. Na samym początku gdy standardy sieciowe dopiero raczkowały konfigurację sieciową należało przeprowadzić ręcznie. Gdy sieć była mała sposób ręcznego przypisywania adresów spełniał swoją rolę ale wraz ze zwiększaniem się rozmiarów sieci proces ten stał się mało efektywny i często w wyniku pomyłek hosty były błędnie konfigurowane czego następstwem były kłopoty z działaniem samej sieci (duplikacja adresów IP, błędna maska itp.). Aby rozwiązać ten problem wymyślono i opracowano protokół BOOTP (ang. Bootstrap Protocol), którego zadaniem było przeprowadzenie procesu automatycznego przypisywania adresów dla nowo podłączanych urządzeń (tak naprawdę gdybyśmy trzymali się chronologii to przed protokołem BOOTP był jeszcze protokół RARP - Reverse Address Resolution Protocol, protokół ten szybko uznano za nieefektywny gdyż po prostu przyznawał adres IP bez adresu maski podsieci i adresu bramy domyślnej). Protokół BOOTP był pierwszym spełniającym oczekiwania, działającym rozwiązaniem problemu ręcznego przypisywania adresów lecz jak to w życiu bywa nie ustrzeżono się błędów w implementacji tego rozwiązania. Gdy błędy naprawiono światło dzienne ujrzało bardziej zaawansowane rozwiązanie czyli protokół DHCP (ang. Dynamic Host Configuration Protocol). Po pewnym czasie protokół BOOTP całkowicie został zastąpiony przez protokół DHCP. Tak więc protokół DHCP jest do dzisiaj panującą metodą automatycznego przypisywania urządzeniom końcowym informacji konfiguracyjnych podczas podłączania się do sieci.