Ruszamy z nową serią wpisów na Packet Hunters. Najpierw podejmiemy się tematu, z którym większość z nas zderza się na co dzień – sieci kampusowe.
To nie jest żaden gotowy kurs ani szablonowa ścieżka przygotowująca do certyfikatów typu CCNA. Nie będziemy tu od zera tłumaczyć podstaw protokołu ARP czy uczyć, jak wyliczać maski podsieci. Traktujcie tę serię jako nasz autorski zbiór dobrych praktyk. Zawarliśmy tu wiedzę wyciągniętą z perspektywy czasu i zjedzonych zębów na administracji. To poradnik, jak podejść do projektowania, wdrażania i utrzymania kampusu od właściwej, inżynieryjnej strony, żeby nie musieć non stop gasić pożarów.
Ważna uwaga: ta seria nie jest laurką dla żadnego konkretnego producenta. Będziemy omawiać mechanizmy i architekturę, a przykłady wdrożeń oprzemy na tym, co w danym scenariuszu sprawdza się najlepiej. Raz będziemy analizować konfigurację z poziomu CLI na Cisco, innym razem ustawimy polityki na Fortinecie.. W jeszcze innej kwestii zaproponujemy z kolei rozwiązanie open-source (jak Zabbix czy LibreNMS). Uczymy technologii i dobrych praktyk, a nie robimy tu kryptoreklamy danej technologii.
Czym jest sieć kampusowa (i czego w tej serii NIE będzie)?
Zanim przejdziemy do konkretów, zdefiniujmy obszar działań. Sieć kampusowa to LAN w biurowcu, szpitalu, fabryce czy na uniwersytecie. To środowisko, w którym w 90% przypadków ruch płynie na linii North-South (od użytkownika do bramy i dalej do Internetu lub centrali).
To nie jest płaska sieć domowa z routerem od dostawcy i klientami po Wi-Fi. Z drugiej strony, daleko jej do sterylnej serwerowni. Z jednej strony ogranicza Cię tu fizyka (np. limity odległości kabli miedzianych), z drugiej – masz do czynienia z totalnym chaosem na poziomie endpointów. W porty dostępowe wpinane są stacje robocze, telefony IP wymagające zasilania PoE, drukarki, prywatne laptopy użytkowników (BYOD) czy tanie kamery CCTV. Ślepe zaufanie do tego, co użytkownik włącza do gniazdka w ścianie, to błąd. Może skończyć się pętlą w sieci albo wyciekiem adresów z „lewego” serwera DHCP.
Dlatego trzeba wiedzieć, czego nie będziemy tu omawiać. Jeśli szukasz informacji o architekturze Leaf-Spine, budowaniu sieci pod VMware, VXLAN-ach, BGP EVPN czy optymalizacji przewidywalnego ruchu East-West pomiędzy serwerami – to nie ten adres. Tego typu technologie to domena Data Center. DC rządzi się swoimi prawami i być może kiedyś poświęcimy mu osobną serię. Tutaj skupiamy się wyłącznie na kampusie.
Czego się spodziewać w kolejnych wpisach?
Nie chcemy wrzucać z góry zaplanowanej listy tematów, wolimy nakreślić ogólne ramy tego, co bierzemy na tapet. Skupimy się na filarach stabilnego LAN-u i pozwolimy tej serii ewoluować:
- Widoczność, Dokumentacja i Backupy: Dlaczego te elementy po prostu trzeba w sieci mieć. Opowiemy czym jest Single Source of Truth (SSoT). Pokażemy, jak w tym pomaga NetBox, Zabbix czy LibreNMS.
- Bezpieczństwo LAN (L2 Hardening): Zapobieganie powstawaniu pętli (STP, BPDU Guard). Ochrona przed błędami użytkowników (DHCP Snooping, Dynamic ARP Inspection).
- Redundancja i Routing w Kampusie: Jak zaprojektować sieć, żeby awaria jednego kabla czy switcha nie odcięła połowy biura. Agregacja linków, stacking, czy protokoły redundancji bramy (FHRP).
- Kontrola dostępu (NAC / 802.1x): Jak wpuszczać do sieci wyłącznie autoryzowane urządzenia. Omówimy uwierzytelnianie oparte o certyfikaty lub adresy MAC (MAB) z wykorzystaniem rozwiązań klasy Enterprise.
- Sieci bezprzewodowe (WLAN) i zasilanie: Kampus to też sieć bezprzewodowa. Architektura kontrolerów Wi-Fi (WLC), roaming, budżety PoE pod Access Pointy lub kamery czy też telefony IP.
Kolejne artykuły będą rozwijać te wątki. Rozpoczynamy od fundamentów, a z czasem będziemy dokładać kolejne klocki do architektury kampusu.
Na koniec jedna, nadrzędna zasada: nie ma głupich pytań. A nawet jeśli jakieś pytanie jest rzeczywiście głupie, to jeszcze większą głupotą jest go nie zadać i tkwić w tejże głupocie. Uderzajcie do nas mailowo lub wbijajcie na naszego Discorda. Zapraszamy.