Listy kontroli dostępu (ACL) oraz protokół DHCP to dwa filary nowoczesnego zarządzania sieciami LAN, które często współistnieją na tym samym urządzeniu. ACL umożliwiają administratorowi definiowanie polityk bezpieczeństwa na poziomie warstwy sieciowej i transportowej, co pozwala skutecznie izolować poszczególne segmenty sieci przed nieautoryzowanym dostępem. Z kolei DHCP odpowiada za automatyczne nadawanie parametrów konfiguracyjnych urządzeniom końcowym, eliminując konieczność ręcznej konfiguracji lub stosowania adresów APIPA. W praktyce inżynierskiej oba mechanizmy są ze sobą ściśle powiązane – przykładowo DHCP może przydzielać adresy IP tylko tym urządzeniom, które przeszły weryfikację ACL na interfejsie dostępowym.

Zrozumienie działania ACL i DHCP w różnych systemach operacyjnych routerów (Cisco IOS, MikroTik RouterOS, Linux (iptables)) jest kluczowe dla każdego administratora sieci. Mimo że składnia konfiguracji różni się między platformami, logika działania pozostaje niezmienna – reguły są przetwarzane sekwencyjnie, a protokół DHCP bazuje na wymianie komunikatów DORA. Niniejsza prezentacja kładzie nacisk na aspekty praktyczne, pokazując konfigurację krok po kroku w środowisku symulacyjnym Packet Tracer oraz na rzeczywistym sprzęcie laboratoryjnym.

Materiał prezentacji został podzielony na pięć logicznych bloków tematycznych, które prowadzą słuchacza od podstawowych koncepcji ACL przez zaawansowane zastosowania, aż po konfigurację DHCP i DHCP Relay w dwóch różnych systemach operacyjnych. W bloku pierwszym omówiono definicję ACL, zasadę pierwszego dopasowania, domyślną regułę odrzucającą oraz podział na standardowe i rozszerzone listy dostępu. Blok drugi koncentruje się na praktycznych scenariuszach zastosowania ACL, takich jak blokowanie SSH, ICMP czy ograniczanie dostępu do Internetu dla sieci gościnnej.

Druga połowa prezentacji poświęcona jest w całości protokołowi DHCP – począwszy od procesu DORA, przez konfigurację serwera na Cisco i RouterOS, aż po rezerwacje adresów i obsługę wielu podsieci. Ostatni blok szczegółowo opisuje mechanizm DHCP Relay, który umożliwia centralne zarządzanie adresacją w sieciach VLAN. Całość uzupełniają przykłady praktyczne z symulatora Packet Tracer oraz tabela porównawcza Cisco vs RouterOS.

Access Control List to mechanizm wywodzący się z wczesnych implementacji protokołu IP, który pierwotnie służył do prostego filtrowania ruchu na routerach granicznych. Współcześnie ACL ewoluowały w zaawansowane narzędzie bezpieczeństwa, umożliwiające nie tylko blokowanie niepożądanego ruchu, ale także klasyfikację pakietów dla potrzeb QoS, NAT czy polityk routingu. Każda lista składa się z wpisów ACE (Access Control Entry), które określają akcję (permit lub deny) oraz kryteria dopasowania – im więcej kryteriów, tym bardziej precyzyjna reguła.

Warto zwrócić uwagę na fakt, że ACL nie jest jedynym mechanizmem filtrowania dostępnym na routerze. W odróżnieniu od firewalli stanowych (stateful firewall), ACL Cisco działają bezstanowo – każdy pakiet jest analizowany niezależnie, bez wiedzy o kontekście połączenia. RouterOS natomiast łączy koncepcję ACL z firewallem stanowym, oferując możliwość filtrowania na podstawie stanu połączenia (connection-state), co znacząco zwiększa skuteczność ochrony przy jednoczesnym uproszczeniu konfiguracji.

Mechanizm sekwencyjnego dopasowywania reguł w ACL można porównać do instrukcji warunkowej if-elseif w językach programowania – gdy pierwszy warunek jest spełniony, pozostałe nie są już analizowane. Analogia ta pomaga zrozumieć, dlaczego kolejność wpisów ma decydujący wpływ na skuteczność filtrowania. W przypadku standardowych ACL, gdzie dopasowanie odbywa się wyłącznie na podstawie adresu źródłowego, skutki błędnej kolejności są szczególnie dotkliwe, ponieważ jedna reguła może przypadkowo blokować ruch z całego zakresu adresów.

W inżynierii sieciowej przyjęła się reguła, że wpisy bardziej szczegółowe (deny dla konkretnego hosta lub usługi) umieszcza się przed wpisami ogólnymi (permit any). Dobrą praktyką jest również grupowanie reguł według zaplanowanej akcji – najpierw reguły deny blokujące niepożądany ruch, a następnie reguły permit zezwalające na resztę. Warto pamiętać, że zmiana kolejności istniejących reguł w numerowanej ACL wymaga usunięcia całej listy i zdefiniowania jej od nowa – w named ACL możliwa jest edycja selektywna.

Implicit deny to domyślna reguła bezpieczeństwa, która chroni sieć przed przypadkowym przepuszczeniem ruchu niespełniającego żadnej zdefiniowanej reguły. W systemie Cisco IOS jest to równoważne wpisowi deny ip any any na końcu każdej ACL, natomiast w RouterOS odpowiada mu domyślna akcja drop na końcu każdego łańcucha firewall filter. Konsekwencje pominięcia tej zasady są często katastrofalne w skutkach – administrator może błędnie sądzić, że skonfigurował ACL poprawnie, podczas gdy w rzeczywistości większość ruchu jest blokowana.

Najbezpieczniejszym podejściem do projektowania ACL jest założenie, że implicit deny istnieje i odpowiednie skonstruowanie reguł jawnych tak, aby obejmowały cały oczekiwany ruch. Jeśli celem jest przepuszczenie tylko wybranych usług, reguła permit ip any any na końcu nie powinna być dodawana. W przypadkach, gdy chcemy przepuścić większość ruchu, a blokować tylko konkretne pakiety, reguła permit ip any any jest niezbędna jako ostatnia. W RouterOS dodatkowo można kontrolować domyślną akcję dla każdego łańcucha, co daje jeszcze większą elastyczność.

Historycznie pierwsze implementacje ACL w systemie Cisco IOS obsługiwały wyłącznie standardowe listy dostępu, które ze względu na swoje ograniczenia (filtrowanie tylko po adresie źródłowym) wymagały umieszczania jak najbliżej miejsca docelowego. Wprowadzenie rozszerzonych ACL (numerowane 100–199) zrewolucjonizowało filtrowanie, umożliwiając tworzenie reguł uwzględniających typ protokołu, porty źródłowe i docelowe oraz wiele innych parametrów. Rozszerzone ACL umieszcza się jak najbliżej źródła, co minimalizuje obciążenie sieci niepotrzebnym ruchem.

Named ACL stanowią najnowszą ewolucję list dostępu w Cisco IOS. Ich główną zaletą jest możliwość edycji pojedynczych reguł bez konieczności usuwania całej ACL, co było problematyczne w przypadku list numerowanych. Ponadto opisowe nazwy (np. FILTRUJ_GOŚCI, ZEZWÓL_DMZ) znacząco poprawiają czytelność konfiguracji i ułatwiają pracę zespołową. Współczesne wersje IOS zalecają stosowanie wyłącznie named ACL, ponieważ oferują one wszystkie funkcjonalności ACL numerowanych, a jednocześnie są bardziej elastyczne i łatwiejsze w utrzymaniu.

Wildcard mask, znana również jako maska odwrotna, jest specyficznym mechanizmem adresowania stosowanym wyłącznie w kontekście ACL. Jej działanie opiera się na prostej zasadzie logicznej: bit o wartości 0 oznacza konieczność zgodności (must match), a bit o wartości 1 oznacza dowolność (don't care). Aby obliczyć wildcard mask dla danej podsieci, należy odjąć maskę sieci od 255.255.255.255 – na przykład dla maski 255.255.255.0 otrzymujemy 0.0.0.255, a dla maski 255.255.240.0 otrzymujemy 0.0.15.255.

W codziennej praktyce administracyjnej najczęściej używanymi skrótami są słowa kluczowe host i any. Host zastępuje wyrażenie adres IP z maską 0.0.0.0 i oznacza dokładnie jeden adres. Any jest równoważne parze 0.0.0.0 255.255.255.255 i oznacza dowolny adres IP. Warto zapamiętać, że wildcard mask nie musi być ciągła – możliwe jest tworzenie masek nieciągłych (np. 0.0.1.255), co pozwala na dopasowanie wzorca bitowego w adresie w bardzo elastyczny sposób, choć w praktyce stosuje się to rzadko.

Standardowa lista dostępu, mimo swoich ograniczeń, wciąż znajduje zastosowanie w prostych scenariuszach filtrowania, gdzie wystarczy kontrola na podstawie źródłowego adresu IP. Przykładem może być blokowanie całego ruchu pochodzącego z określonej podsieci lub zezwalanie na dostęp tylko wybranym hostom. Składnia komendy access-list w przypadku standardowej ACL wymaga podania numeru listy (1–99 lub 1300–1999), akcji (permit lub deny) oraz adresu źródłowego z maską wildcard.

Zasada umieszczania standardowej ACL jak najbliżej miejsca docelowego wynika z jej ograniczonej selektywności – jeśli umieścimy ją zbyt blisko źródła, może zablokować ruch do wielu niepowiązanych sieci. Na przykład standardowa ACL umieszczona na interfejsie brzegowym routera, która blokuje ruch z sieci 192.168.1.0/24, zablokuje ten ruch do wszystkich sieci za routerem, nie tylko do zamierzonej. W praktyce standardowe ACL są stopniowo wypierane przez bardziej precyzyjne rozszerzone listy dostępu, ale wciąż mogą być użyteczne w prostych konfiguracjach.

Rozszerzone listy dostępu stanowią podstawowe narzędzie precyzyjnego filtrowania ruchu w nowoczesnych sieciach korporacyjnych. Składnia extended ACL jest znacznie bogatsza niż standardowej – po numerze listy i akcji następują parametry protokołu (ip, tcp, udp, icmp, gre, esp), adres źródłowy z maską wildcard, operator logiczny (eq, neq, gt, lt, range) oraz numer portu, a następnie adres docelowy z analogicznymi parametrami. Taka struktura pozwala na tworzenie bardzo szczegółowych reguł, które są w stanie odróżnić na przykład ruch HTTP od ruchu HTTPS pochodzącego z tego samego adresu źródłowego.

Extended ACL należy umieszczać jak najbliżej źródła ruchu, aby minimalizować obciążenie sieci niepotrzebnymi pakietami. Na przykład reguła blokująca SSH z sieci 192.168.2.0/24 do serwera 10.0.0.100 powinna być zastosowana na interfejsie wejściowym routera najbliżej sieci 192.168.2.0/24. Dzięki temu pakiety SSH są odrzucane natychmiast, zanim zajmą przepustowość łącza między routerami. W przypadku wielu reguł w jednej ACL warto pamiętać o dodaniu na końcu reguły permit ip any any, jeśli chcemy przepuścić ruch niespełniający żadnej z wcześniejszych reguł deny.

Named ACL (nazywane listy dostępu) zostały wprowadzone w Cisco IOS w wersji 12.0 jako odpowiedź na potrzeby administratorów, którzy borykali się z ograniczeniami list numerowanych. Główną innowacją jest możliwość selektywnego usuwania i wstawiania pojedynczych reguł za pomocą numerów sekwencyjnych (sequence numbers), które są automatycznie nadawane przy tworzeniu reguły lub mogą być zdefiniowane ręcznie. Domyślnie numery sekwencyjne (sequence numbers) zaczynają się od 10 i zwiększa się co 10, co pozostawia miejsce na wstawienie nowych reguł pomiędzy istniejące.

Konfiguracja named ACL rozpoczyna się od polecenia ip access-list extended NAZWA, które przenosi administratora w tryb konfiguracji reguł danej listy. W tym trybie reguły są definiowane linia po linii bez konieczności każdorazowego poprzedzania ich poleceniem access-list. Po zakończeniu konfiguracji listę przypisuje się do interfejsu standardowym poleceniem ip access-group NAZWA in lub out. Named ACL są obecnie zalecanym standardem konfiguracyjnym w sieciach Cisco, wypierając stopniowo przestarzałe ACL numerowane.

W systemie RouterOS nie istnieje dedykowane polecenie access-list – funkcję ACL realizuje firewall pakietowy, który jest znacznie bardziej rozbudowany niż prosta lista reguł w Cisco IOS. Kluczowym elementem konfiguracji są łańcuchy (chains), które definiują, do jakiego typu ruchu dana reguła ma zastosowanie. Łańcuch input przetwarza pakiety adresowane bezpośrednio do routera (np. SSH do zarządzania), forward – pakiety tranzytowe przechodzące przez router, a output – pakiety generowane przez samego routera. Taki podział daje znacznie większą kontrolę niż klasyczne ACL Cisco, które nie rozróżniają ruchu do routera od ruchu przez router.

RouterOS oferuje również szereg zaawansowanych funkcji niedostępnych w standardowych ACL Cisco. Należą do nich między innymi filtrowanie na podstawie stanu połączenia (connection-state), które pozwala odróżnić nowe połączenia od już nawiązanych, listy adresowe (address-list) umożliwiające grupowanie adresów IP i stosowanie ich w wielu regułach, a także analiza warstwy 7 (layer7) do identyfikacji protokołów na podstawie wzorców w danych. Te możliwości czynią RouterOS jednym z najbardziej elastycznych rozwiązań firewallowych dla sieci małych i średnich.

Kierunek filtrowania ACL na interfejsie ma bezpośredni wpływ na wydajność routera oraz skuteczność polityki bezpieczeństwa. ACL in jest przetwarzana przed decyzją routingu – oznacza to, że pakiety odrzucone przez ACL in nie są poddawane analizie tablicy routingu, co oszczędza zasoby procesora. Z tego powodu ACL in jest zalecana na interfejsach brzegowych, gdzie spodziewamy się dużej ilości niepożądanego ruchu (np. z Internetu). ACL out jest natomiast przetwarzana po decyzji routingu, tuż przed wysłaniem pakietu przez interfejs wyjściowy – jest to przydatne, gdy chcemy kontrolować ruch opuszczający daną sieć.

W praktyce inżynierskiej często spotyka się konfigurację, w której ta sama ACL jest stosowana na wielu interfejsach w różnych kierunkach. Warto pamiętać, że ACL na interfejsie nie filtruje ruchu generowanego przez samego routera – na przykład próba SSH do routera nie zostanie przechwycona przez ACL przypisaną do interfejsu wejściowego. Aby filtrować ruch do routera, należy zastosować ACL na linii vty lub użyć dedykowanego mechanizmu control-plane policing. W RouterOS odpowiednikiem ACL in jest reguła w chain=input, a ACL out – chain=output.

Przykład blokady SSH ilustruje kluczową zasadę projektowania rozszerzonych ACL – najpierw reguły blokujące, potem zezwalające. Sieć 192.168.2.0/24 może reprezentować strefę gościnną lub sieć laboratoryjną, która nie powinna mieć dostępu do zarządzania serwerem przez SSH, ale może korzystać z innych usług. W konfiguracji wykorzystano ACL numer 110, która jest przypisana do interfejsu GigabitEthernet0/1 w kierunku in – oznacza to, że pakiety przychodzące z sieci 192.168.2.0/24 są sprawdzane przed podjęciem decyzji routingu.

Warto zwrócić uwagę na specyfikację portu docelowego w regule deny – użyto parametru eq 22, który oznacza port równy 22 (standardowy port SSH). Gdybyśmy chcieli zablokować wiele portów jednocześnie, moglibyśmy użyć operatora range (np. range 22 23 dla SSH i Telnet). Po skonfigurowaniu ACL należy zweryfikować jej działanie za pomocą polecenia show access-lists, które wyświetli liczniki trafień dla każdej reguły. Jeśli licznik dla reguły deny nie rośnie podczas próby połączenia SSH, oznacza to, że ACL nie została poprawnie przypisana do interfejsu lub że ruch jest blokowany wcześniej.

Blokada protokołu ICMP jest jednym z najczęściej implementowanych scenariuszy ACL w sieciach korporacyjnych, jednak wymaga ostrożności, aby nie zakłócić działania protokołów wyższych warstw. Protokół ICMP składa się z wielu typów komunikatów – echo-request (typ 8) używany przez ping, echo-reply (typ 0), destination unreachable (typ 3), time exceeded (typ 11), parameter problem (typ 12) oraz redirect (typ 5). Blokowanie wszystkich typów ICMP może prowadzić do poważnych problemów z wydajnością i niezawodnością sieci, ponieważ wiele mechanizmów TCP/IP polega na ICMP do raportowania błędów.

Szczególnie ważnym mechanizmem zależnym od ICMP jest Path MTU Discovery (PMTUD), który wykorzystuje komunikaty Fragmentation Needed (kod 4 w typie 3) do określenia maksymalnego rozmiaru pakietu na ścieżce transmisji. Jeśli te komunikaty są blokowane, routery będą próbowały wysyłać zbyt duże pakiety, które nie zmieszczą się w MTU łącza, co prowadzi do problemów z łącznością. Dlatego w regule ACL blokującej ping należy precyzyjnie określić typ ICMP 8 (echo-request), pozostawiając pozostałe typy ICMP bez zmian. W Cisco IOS składnia pozwala na podanie typu ICMP w formacie liczbowym lub słownym (echo-request).

Scenariusz ograniczenia dostępu do Internetu dla sieci gościnnej jest powszechnie stosowany w hotelach, biurach coworkingowych oraz firmach udostępniających Wi-Fi klientom. Kluczowym elementem tej konfiguracji jest zastosowanie ACL in na interfejsie, do którego podłączona jest sieć gościnna. Kierunek in oznacza, że ACL sprawdza pakiety wchodzące do interfejsu od strony sieci gościnnej – czyli ruch generowany przez urządzenia w sieci gościnnej. Dzięki temu można precyzyjnie określić, które zasoby sieci wewnętrznej są dostępne dla gości.

W przykładzie sieć gościnna 192.168.99.0/24 ma zezwolenie wyłącznie na komunikację z drukarką o adresie 192.168.1.200. Cały pozostały ruch (do Internetu, do innych serwerów, do innych podsieci) jest blokowany przez regułę deny ip 192.168.99.0 0.0.0.255 any. Trzecia reguła permit ip any any dotyczy ruchu z innych sieci i zapewnia, że ACL nie blokuje ruchu przychodzącego do sieci gościnnej (np. odpowiedzi z drukarki). Taka konfiguracja jest często łączona z firewall SPI (Stateful Packet Inspection) na RouterOS, który dodatkowo analizuje kontekst połączeń.

Blokada SSH na RouterOS wykorzystuje łańcuch forward, ponieważ ruch SSH z sieci źródłowej do docelowej jest ruchem tranzytowym przechodzącym przez router. Składnia polecenia /ip firewall filter add wymaga podania łańcucha (chain), źródłowego i docelowego adresu IP, protokołu oraz portu. W przeciwieństwie do Cisco, RouterOS nie wymaga oddzielnego przypisywania reguły do interfejsu – reguła w chain=forward obowiązuje na wszystkich interfejsach, przez które przechodzi ruch tranzytowy.

RouterOS oferuje również dodatkowe mechanizmy zwiększające skuteczność filtrowania. Opcja connection-state umożliwia odróżnienie pakietów nowych połączeń od już nawiązanych – na przykład reguła connection-state=invalid action=drop powinna być pierwszą regułą w każdym łańcuchu forward, ponieważ eliminuje nieprawidłowe pakiety. Address-list pozwala na tworzenie dynamicznych grup adresów, które mogą być aktualizowane automatycznie. Layer7 umożliwia identyfikację protokołów na podstawie wzorców w danych, co jest przydatne do blokowania aplikacji peer-to-peer lub streamingu.

Diagnostyka ACL jest równie ważna jak jej poprawna konfiguracja – nawet najlepiej zaprojektowana lista dostępu nie zadziała, jeśli zostanie błędnie przypisana do interfejsu. Polecenie show access-lists w Cisco IOS wyświetla nie tylko wszystkie reguły, ale również liczniki pakietów (matches), które dopasowały się do każdej reguły. Jeśli licznik dla reguły deny nie rośnie, mimo że generujemy odpowiedni ruch (np. ping z zablokowanej sieci), oznacza to problem z konfiguracją. Warto również sprawdzić show running-config | include access-group, aby upewnić się, że ACL jest przypisana do właściwego interfejsu we właściwym kierunku.

W RouterOS analogiczną funkcję pełni polecenie /ip firewall filter print stats, które wyświetla statystyki dla każdej reguły firewall. Dodatkowo RouterOS oferuje narzędzie /tool torch, które pozwala na bieżąco monitorować ruch przechodzący przez interfejs i identyfikować, które reguły są dopasowywane. W przypadku bardziej zaawansowanej diagnostyki warto skorzystać z debugowania ACL za pomocą polecenia debug ip packet w Cisco lub /log print where topics=firewall w RouterOS, które rejestrują szczegółowe informacje o pakietach przetwarzanych przez reguły filtrujące.

Blok ACL w niniejszej prezentacji stanowi kompleksowe wprowadzenie do mechanizmów filtrowania ruchu na routerach Cisco i MikroTik. Omówione zostały wszystkie typy list dostępu – standardowe, rozszerzone i nazwane – wraz z ich praktycznym zastosowaniem. Szczególny nacisk położono na reguły projektowania ACL: zachowanie właściwej kolejności reguł (first match wins), uwzględnienie domyślnej reguły implicit deny oraz wybór odpowiedniego kierunku filtrowania (in vs out). Zrozumienie tych zasad jest kluczowe dla uniknięcia typowych błędów konfiguracyjnych.

Porównanie Cisco IOS i RouterOS w kontekście ACL pokazuje, że mimo różnic składniowych koncepcje leżące u podstaw filtrowania ruchu są uniwersalne. RouterOS oferuje bardziej zaawansowane możliwości (connection-state, address-list, layer7), ale wymaga też większej wiedzy do poprawnej konfiguracji. Cisco IOS z kolei oferuje prostszy, bardziej ustrukturyzowany model ACL, co ułatwia naukę podstaw. Niezależnie od platformy, kluczem do sukcesu jest systematyczne testowanie każdej reguły za pomocą dostępnych narzędzi diagnostycznych oraz dokumentowanie konfiguracji w celach audytowych.

Protokół DHCP, zdefiniowany w RFC 2131, jest następcą protokołu BOOTP (Bootstrap Protocol) i stanowi podstawę automatycznej konfiguracji urządzeń w nowoczesnych sieciach TCP/IP. Proces DORA (Discover, Offer, Request, Ack) opiera się na wymianie czterech komunikatów pomiędzy klientem a serwerem. W pierwszym kroku klient wysyła komunikat DHCP Discover na adres broadcast (255.255.255.255), ponieważ na tym etapie nie posiada jeszcze adresu IP ani informacji o adresie serwera DHCP. Serwer DHCP, nasłuchujący na porcie UDP 67, odbiera ten broadcast i odpowiada komunikatem DHCP Offer na porcie UDP 68.

Po otrzymaniu oferty klient wysyła DHCP Request, w którym akceptuje zaproponowany adres IP i parametry konfiguracyjne. Serwer kończy proces komunikatem DHCP Ack, który potwierdza przydzielenie adresu i zawiera wszystkie niezbędne parametry sieciowe: adres IP, maskę podsieci, bramę domyślną oraz serwery DNS. W przypadku gdy oferowany adres IP jest już zajęty, serwer może odpowiedzieć komunikatem DHCP Nack, zmuszając klienta do rozpoczęcia procesu od nowa. Warto dodać, że DHCP obsługuje również mechanizm odnowienia dzierżawy (DHCP Request w trybie unicast) oraz zwalniania adresu (DHCP Release).

Decyzja o wyborze routera jako serwera DHCP zależy przede wszystkim od skali i złożoności sieci. W segmencie SOHO (Small Office / Home Office) router z wbudowanym serwerem DHCP jest rozwiązaniem optymalnym ze względu na prostotę konfiguracji i niski koszt. Router w takich sieciach pełni zazwyczaj funkcję bramy domyślnej, firewalla i serwera DHCP jednocześnie, co upraszcza architekturę sieci. Producenci tacy jak Cisco i MikroTik oferują wbudowane serwery DHCP, które można skonfigurować w kilka minut za pomocą interfejsu CLI lub GUI.

W sieciach średnich i dużych dedykowany serwer DHCP na platformie Windows Server lub Linux (ISC DHCP, Kea) zapewnia lepszą skalowalność oraz zaawansowane funkcje, takie jak automatyczne aktualizacje DNS (DDNS), polityki adresacji oparte na typie urządzenia (vendor class) czy wysoka dostępność poprzez klasterowanie. W takiej architekturze router przejmuje rolę DHCP Relay, który przekazuje żądania DHCP z poszczególnych podsieci do centralnego serwera. Pozwala to na zachowanie spójności konfiguracji i centralne zarządzanie adresacją IP w całej organizacji.

Wykluczanie adresów z puli DHCP jest pierwszym i niezwykle istotnym krokiem konfiguracji serwera DHCP, który często bywa pomijany przez początkujących administratorów. Polecenie ip dhcp excluded-address w Cisco IOS pozwala zdefiniować zakres adresów IP, których serwer DHCP nie będzie przydzielał klientom. Typowe adresy wymagające wykluczenia to adres bramy domyślnej (interfejs routera), adresy serwerów (DNS, DHCP, plików), drukarek sieciowych, kamer IP oraz innych urządzeń infrastrukturalnych z ręcznie ustawioną adresacją.

Brak wykluczenia adresu bramy domyślnej jest najczęstszą przyczyną konfliktów adresów IP w sieciach z DHCP. Jeśli router przydzieli swój własny adres klientowi, w sieci pojawią się dwa urządzenia z tym samym adresem IP, co spowoduje niestabilność połączeń i błędy komunikacji. Polecenie ip dhcp excluded-address może być użyte wielokrotnie do wykluczenia pojedynczych adresów lub całych zakresów (np. ip dhcp excluded-address 192.168.1.1 192.168.1.20). W RouterOS odpowiednikiem jest odpowiednie zdefiniowanie zakresu puli w /ip pool, który po prostu nie obejmuje adresów statycznych.

Pula DHCP (DHCP pool) w Cisco IOS stanowi centralny element konfiguracji serwera DHCP. Polecenie ip dhcp pool NAZWA tworzy pulę i przenosi administratora w tryb konfiguracji dhcp-config, gdzie definiowane są parametry adresacji. Parametr network określa sieć i maskę, z której adresy będą przydzielane – router automatycznie uwzględnia wykluczone adresy przy alokacji. Parametr default-router definiuje bramę domyślną dla klientów, a dns-server może zawierać do ośmiu adresów serwerów DNS oddzielonych spacjami.

Ważnym parametrem puli jest czas dzierżawy (lease), który określa, jak długo klient może korzystać z przydzielonego adresu przed koniecznością odnowienia dzierżawy. W sieciach o stabilnej liczbie urządzeń (biura) zaleca się dłuższy czas dzierżawy (24 godziny lub więcej), co zmniejsza ruch związany z odnowieniami. W sieciach z dużą rotacją urządzeń (hotele, hotspoty) krótki czas dzierżawy (30 minut do 1 godziny) pozwala na szybkie zwalnianie adresów nieaktywnych klientów. Warto pamiętać, że klient próbuje odnowić dzierżawę po połowie czasu jej trwania (T1) i ponownie po 87,5% czasu (T2).

Opcje DHCP (ang. DHCP options) są standardowym mechanizmem rozszerzania funkcjonalności protokołu DHCP, zdefiniowanym w RFC 2132. Pole options w pakiecie DHCP ma zmienną długość i może przenosić wiele różnych parametrów konfiguracyjnych. Najczęściej używane opcje to: maska podsieci (option 1), brama domyślna (option 3), serwery DNS (option 6), nazwa domeny DNS (option 15) oraz adres serwera czasu NTP (option 42). Każda opcja ma unikalny numer i zdefiniowaną strukturę danych, co zapewnia interoperacyjność między urządzeniami różnych producentów.

Opcja 150 jest specyficznym rozszerzeniem Cisco stosowanym w sieciach VoIP – przekazuje adres serwera TFTP, z którego telefony IP pobierają konfigurację (numerację, provisioning). Opcje 66 (tftp-server-name) i 67 (bootfile-name) są wykorzystywane w środowiskach PXE (Preboot eXecution Environment) do zdalnego bootowania systemów operacyjnych. W RouterOS opcje DHCP definiuje się w sekcji /ip dhcp-server network, gdzie można dodać dowolne opcje za pomocą parametru dhcp-option-set. Zaawansowani administratorzy mogą tworzyć własne opcje lub wykorzystywać opcje vendor-specific do konfiguracji urządzeń określonego producenta.

Prawidłowa diagnostyka serwera DHCP jest niezbędna do utrzymania ciągłości działania sieci. W Cisco IOS kluczowym poleceniem jest show ip dhcp binding, które wyświetla wszystkie aktywne dzierżawy wraz z adresem IP, adresem MAC klienta, typem dzierżawy (automatic, manual) oraz pozostałym czasem dzierżawy. Jeśli po skonfigurowaniu serwera lista dzierżaw pozostaje pusta, należy sprawdzić, czy klienci są w stanie wysyłać żądania DHCP – może to wymagać weryfikacji połączenia sieciowego lub konfiguracji przełączników (np. DHCP snooping blokującego nieautoryzowane serwery DHCP).

Polecenie show ip dhcp pool dostarcza informacji o statystykach puli: liczbie przydzielonych adresów, wolnych adresów oraz adresów wykluczonych. Gdy pula zbliża się do wyczerpania, administrator powinien rozszerzyć zakres adresów lub skrócić czas dzierżawy. Polecenie show ip dhcp conflict wyświetla konflikty adresów wykryte przez router – router wysyła ping na adres przed przydzieleniem, aby sprawdzić, czy jest już używany. W RouterOS odpowiednikami są /ip dhcp-server lease print oraz /ip dhcp-server print stats, które dostarczają analogicznych informacji o stanie serwera DHCP.

W RouterOS konfiguracja DHCP została podzielona na trzy odrębne etapy, co odróżnia to podejście od zintegrowanego modelu Cisco IOS. Pierwszym etapem jest utworzenie puli adresów za pomocą polecenia /ip pool. Pula w RouterOS definiuje wyłącznie zakresy adresów IP – nie zawiera żadnych opcji sieciowych. Składnia pozwala na podanie pojedynczego zakresu (np. 192.168.1.100-192.168.1.200) lub wielu zakresów oddzielonych przecinkami w ramach jednej puli. Taka separacja upraszcza zarządzanie, ponieważ jedna pula może być współdzielona między wieloma serwerami DHCP.

Elastyczność tego rozwiązania przejawia się w możliwości tworzenia nieciągłych zakresów adresów, co jest szczególnie przydatne w sieciach z wieloma strefami adresowymi. Na przykład pula może obejmować zakresy 192.168.1.100-192.168.1.150 oraz 192.168.1.200-192.168.1.250, pomijając adresy z przedziału 151-199, które mogą być używane do rezerwacji. W odróżnieniu od Cisco, gdzie wykluczenie adresów wymaga oddzielnego polecenia ip dhcp excluded-address, w RouterOS adresy wyklucza się poprzez odpowiednie zaprojektowanie zakresów puli. Każda pula może być również przypisana do wielu serwerów DHCP na różnych interfejsach.

Drugi etap konfiguracji DHCP w RouterOS polega na utworzeniu serwera DHCP i powiązaniu go z interfejsem sieciowym. Polecenie /ip dhcp-server add wymaga podania nazwy serwera, interfejsu, na którym serwer będzie nasłuchiwał żądań DHCP, oraz nazwy puli adresów. RouterOS umożliwia utworzenie niezależnych serwerów DHCP dla każdego interfejsu fizycznego, mostka (bridge) lub podinterfejsu VLAN. Dzięki temu można obsługiwać wiele segmentów sieci za pomocą jednego routera, przypisując każdemu segmentowi oddzielny serwer DHCP z własną pulą i polityką adresacji.

W praktyce konfiguracja wielu serwerów DHCP na jednym routerze jest często stosowana w architekturze router-on-a-stick (ROAS), gdzie router obsługuje wiele VLAN na jednym interfejsie fizycznym poprzez podinterfejsy. Każdy podinterfejs VLAN może mieć własny serwer DHCP, co pozwala na automatyczne przydzielanie adresacji w poszczególnych sieciach VLAN bez konieczności stosowania DHCP Relay. Warto również wspomnieć, że RouterOS umożliwia utworzenie serwera DHCP bez przypisanej puli – w takim przypadku adresy przydzielane są wyłącznie na podstawie rezerwacji, co jest przydatne w sieciach z pełną kontrolą adresacji.

Trzeci i ostatni etap konfiguracji DHCP w RouterOS definiuje parametry sieciowe, które będą przekazywane klientom w odpowiedzi DHCP. Polecenie /ip dhcp-server network add pozwala na określenie bramy domyślnej (gateway), serwerów DNS (dns-server), nazwy domeny (domain), serwerów NTP (ntp-server) oraz innych opcji dla konkretnej podsieci. Kluczową zaletą tego rozwiązania jest możliwość przypisania różnych parametrów sieciowych do różnych podsieci obsługiwanych przez ten sam serwer DHCP – router automatycznie dopasowuje opcje na podstawie interfejsu, na którym odebrano żądanie DHCP.

W praktyce oznacza to, że jeden serwer DHCP na interfejsie bridge może obsługiwać wiele sieci VLAN, z których każda otrzyma inną bramę domyślną i inne serwery DNS. Na przykład klient w sieci 192.168.1.0/24 otrzyma bramę 192.168.1.1 i DNS 8.8.8.8, podczas gdy klient w sieci 10.0.0.0/24 na tym samym serwerze otrzyma bramę 10.0.0.1 i DNS 1.1.1.1. Ta elastyczność jest szczególnie przydatna w środowiskach z wieloma VLAN, gdzie upraszcza konfigurację i centralizuje zarządzanie opcjami DHCP. Dodatkowo RouterOS pozwala na definiowanie niestandardowych opcji DHCP za pomocą /ip dhcp-server option.

Rezerwacje DHCP w RouterOS są implementowane za pomocą mechanizmu dzierżaw statycznych (static leases) w systemie /ip dhcp-server lease. Administrator dodaje wpis, w którym określa adres MAC urządzenia oraz przypisany mu adres IP. Router będzie zawsze przydzielał temu samemu urządzeniu ten sam adres IP, o ile adres MAC się nie zmieni. Rezerwacje DHCP stanowią złoty środek między adresacją statyczną a dynamiczną – urządzenie nadal korzysta z DHCP do pobrania wszystkich parametrów (brama, DNS), ale adres IP pozostaje stały i przewidywalny.

W praktyce rezerwacje DHCP w RouterOS są często wykorzystywane do zarządzania adresacją serwerów, drukarek sieciowych, kamer IP oraz punktów dostępowych Wi-Fi. W odróżnieniu od Cisco IOS, gdzie każda rezerwacja wymaga utworzenia oddzielnej puli DHCP, RouterOS pozwala na scentralizowane zarządzanie wszystkimi rezerwacjami w jednym miejscu z możliwością szybkiego przeglądania, edycji i usuwania wpisów. Dodatkowo w RouterOS można zdefiniować opcje DHCP specyficzne dla danej rezerwacji (np. inny serwer DNS dla konkretnego urządzenia), co daje jeszcze większą elastyczność konfiguracyjną.

W Cisco IOS rezerwacje DHCP mają nieco bardziej złożoną strukturę niż w RouterOS. Każda rezerwacja wymaga utworzenia oddzielnej puli DHCP za pomocą polecenia ip dhcp pool, w której definiuje się adres IP i maskę (host) oraz identyfikator sprzętowy urządzenia. Identyfikatorem może być hardware-address (adres MAC w formacie AABB.CCDD.EEFF) lub client-id (adres MAC poprzedzony bajtem 01 dla interfejsów Ethernet). W przypadku Cisco każda rezerwacja jest osobną pulą, co przy większej liczbie rezerwacji może prowadzić do rozbudowanej i trudnej w zarządzaniu konfiguracji.

Podejście Cisco ma jednak pewne zalety: każda rezerwacja może mieć własne opcje DHCP (bramę, DNS, domenę), niezależne od głównej puli, co jest przydatne w przypadku serwerów wymagających specyficznej konfiguracji sieciowej. W praktyce zaleca się stosowanie rezerwacji DHCP dla urządzeń infrastrukturalnych, natomiast dla zwykłych klientów końcowych pozostawienie adresacji dynamicznej z głównej puli. Warto pamiętać, że polecenie show ip dhcp binding wyświetla wszystkie dzierżawy (dynamiczne i statyczne), a rezerwacje są oznaczone typem manual, co ułatwia ich identyfikację.

Router Cisco może obsługiwać jednocześnie wiele pul DHCP dla różnych podsieci, co jest niezbędne w środowiskach z wieloma sieciami VLAN. Mechanizm działania jest prosty, ale elegancki: router automatycznie identyfikuje, z którego interfejsu lub podinterfejsu VLAN pochodzi żądanie DHCP Discover, i na tej podstawie przydziela adres z odpowiedniej puli. Nie wymaga to żadnej dodatkowej konfiguracji mapowania – router sam dopasowuje żądanie do puli na podstawie adresu IP interfejsu, na którym odebrano żądanie. Każda pula DHCP definiuje własną sieć, bramę domyślną, serwery DNS oraz czas dzierżawy.

Ta funkcjonalność jest szczególnie przydatna w architekturze router-on-a-stick (ROAS), gdzie router łączy się z przełącznikiem za pomocą jednego interfejsu fizycznego podzielonego na podinterfejsy VLAN. Każdy podinterfejs VLAN ma przypisany adres IP bramy dla danej sieci VLAN i własną pulę DHCP. Gdy klient w VLAN 10 wysyła żądanie DHCP, router odbiera je na podinterfejsie z adresem 192.168.10.1 i przydziela adres z puli VLAN10_POOL. Analogicznie działa to dla VLAN 20 i pozostałych sieci. Takie rozwiązanie upraszcza zarządzanie adresacją i eliminuje potrzebę stosowania DHCP Relay w obrębie jednego routera.

Blok DHCP w niniejszej prezentacji obejmuje pełen cykl życia konfiguracji serwera DHCP – od podstaw teoretycznych (proces DORA), przez konfigurację praktyczną na dwóch platformach, aż po zaawansowane zagadnienia, takie jak rezerwacje i wiele pul. Najważniejszym wnioskiem koncepcyjnym jest różnica w podejściu między Cisco IOS a RouterOS: Cisco grupuje wszystkie parametry w ramach zintegrowanej puli DHCP, natomiast RouterOS stosuje model trzech odrębnych etapów (pula → serwer → sieć). Każde z tych podejść ma swoje zalety – Cisco jest bardziej intuicyjne dla mniejszych konfiguracji, RouterOS oferuje większą elastyczność przy złożonych sieciach.

Rezerwacje DHCP stanowią pomost między światem adresacji statycznej i dynamicznej, umożliwiając stałe przypisanie adresów do urządzeń infrastrukturalnych przy jednoczesnym zachowaniu zalet centralnego zarządzania DHCP. W praktyce administracyjnej kluczowe znaczenie ma regularne monitorowanie stanu serwera DHCP – wyczerpanie puli adresów może prowadzić do paraliżu sieci, a konflikty adresacji do niestabilności połączeń. Dlatego każdy administrator powinien okresowo sprawdzać statystyki puli za pomocą show ip dhcp pool (Cisco) lub /ip dhcp-server print stats (RouterOS) i odpowiednio wcześnie reagować na zbliżające się wyczerpanie dostępnych adresów.

Podstawowym problemem w rozproszonych sieciach DHCP jest fakt, że routery domyślnie nie przekazują ramek broadcast między interfejsami. Wynika to z fundamentalnej zasady routingu IP – router działa na warstwie 3 modelu OSI i nie forwarduje ramek warstwy 2, w tym broadcastów (adres MAC FF:FF:FF:FF:FF:FF). Oznacza to, że klient DHCP w podsieci A, wysyłając DHCP Discover na adres broadcast 255.255.255.255, nie dotrze do serwera DHCP znajdującego się w podsieci B. Bez mechanizmu pośredniczącego każda podsieć musiałaby mieć własny serwer DHCP.

Rozwiązaniem tego problemu jest DHCP Relay (agent przekazujący), który działa na routerze łączącym podsieci. Router nasłuchuje na porcie UDP 67 na wszystkich interfejsach i przechwytuje pakiety DHCP Discover. Następnie zamienia adres broadcast na unicast i przekazuje pakiet do skonfigurowanego serwera DHCP, dodając do pakietu adres interfejsu (giaddr), na którym odebrano żądanie. Dzięki temu serwer DHCP wie, z której podsieci pochodzi żądanie i może przydzielić adres z odpowiedniej puli. Mechanizm ten jest zdefiniowany w RFC 1542 i jest powszechnie wspierany przez wszystkich producentów sprzętu sieciowego.

DHCP Relay, opisany w standardzie RFC 1542, jest mechanizmem warstwy aplikacji, który umożliwia współpracę klientów DHCP z serwerem znajdującym się w innej podsieci. Router pełniący funkcję relay agent nasłuchuje na wszystkich interfejsach na pakiety DHCP (port UDP 67). Gdy klient wysyła broadcast DHCP Discover, router przechwytuje go i analizuje zawartość. Kluczową modyfikacją jest dodanie do pakietu pola giaddr (Gateway IP Address), które zawiera adres IP interfejsu routera, na którym odebrano żądanie. Następnie router wysyła zmodyfikowany pakiet jako unicast do skonfigurowanego serwera DHCP.

Serwer DHCP odbiera pakiet i na podstawie pola giaddr określa, z której podsieci pochodzi żądanie, co pozwala mu wybrać odpowiednią pulę adresów. Serwer wysyła odpowiedź (DHCP Offer) unicastem z powrotem do adresu w polu giaddr, czyli do interfejsu routera. Router odbiera odpowiedź i przekazuje ją do klienta w jego sieci lokalnej – w przypadku gdy klient nie ma jeszcze adresu IP, router może wysłać odpowiedź jako broadcast w sieci lokalnej. Cały proces jest przezroczysty dla klienta, który nie jest świadomy, że serwer DHCP znajduje się w innej podsieci.

Polecenie ip helper-address w Cisco IOS jest niezwykle użyteczne, ale wymaga świadomości, że domyślnie przekazuje ono broadcasty dla ośmiu różnych protokołów UDP. Oprócz DHCP (porty 67 i 68) są to: DNS (53), TFTP (69), Time (37), NetBIOS Name Service (137), NetBIOS Datagram Service (138) oraz TACACS (49). W większości scenariuszy administracyjnych intencją jest przekazywanie wyłącznie DHCP, a pozostałe protokoły powinny być wyłączone ze względów bezpieczeństwa – niekontrolowane przekazywanie broadcastów DNS czy NetBIOS może prowadzić do wycieku informacji lub niepotrzebnego obciążenia sieci.

Aby ograniczyć zakres przekazywanych protokołów, należy użyć polecenia no ip forward-protocol udp w konfiguracji globalnej routera. Na przykład no ip forward-protocol udp 53 wyłącza przekazywanie broadcastów DNS. ip helper-address konfiguruje się na interfejsie, który ma nasłuchiwać broadcastów – zazwyczaj jest to interfejs sieci LAN, do którego podłączeni są klienci DHCP. Można skonfigurować wiele adresów ip helper-address na jednym interfejsie, jeśli serwery DHCP są redundantne. Warto również pamiętać, że polecenie to działa tylko dla ruchu przychodzącego do interfejsu (kierunek in).

RouterOS implementuje DHCP Relay w sposób bardziej przejrzysty i wyspecjalizowany niż Cisco IOS. Polecenie /ip dhcp-relay add tworzy wpis relay agent, który wymaga podania interfejsu nasłuchującego (interface) oraz adresu zdalnego serwera DHCP (dhcp-server). W przeciwieństwie do modelu Cisco, RouterOS nie przekazuje domyślnie żadnych innych protokołów UDP – relay dotyczy wyłącznie DHCP, co eliminuje ryzyko przypadkowego przekazywania niepożądanych broadcastów. RouterOS automatycznie dodaje trasę do serwera DHCP, jeśli nie istnieje, co upraszcza konfigurację w sieciach z dynamicznym routingiem.

RouterOS umożliwia konfigurację wielu wpisów DHCP Relay dla różnych interfejsów i różnych serwerów DHCP, co jest przydatne w sieciach z wieloma podsieciami i redundantnymi serwerami. Dodatkowo w RouterOS w wersji 7 dodano obsługę DHCPv6 Relay, co pozwala na przekazywanie żądań adresacji IPv6 do centralnego serwera DHCPv6. Warto również wspomnieć o opcji local-address, która pozwala określić adres źródłowy, z którego router wysyła pakiety do serwera DHCP – jest to przydatne w sieciach z wieloma adresami IP na interfejsie lub gdy wymagana jest konkretna polityka routingu dla ruchu DHCP.

Przedstawiony scenariusz praktyczny ilustruje rzeczywiste zastosowanie DHCP Relay w sieci z dwoma segmentami IP. Router R1 pełni rolę pośrednika między siecią LAN A (192.168.1.0/24), w której znajdują się klienci, a siecią LAN B (10.0.0.0/24), gdzie działa centralny serwer DHCP. Konfiguracja sprowadza się do dodania polecenia ip helper-address 10.0.0.1 na interfejsie G0/0 routera R1. Serwer DHCP na R2 ma skonfigurowaną pulę REMOTE_LAN dla sieci 192.168.1.0/24 z bramą 192.168.1.1 – jest to konieczne, aby serwer wiedział, jakie parametry przekazać klientom w zdalnej sieci.

Przepływ pakietów w tym scenariuszu jest następujący: klient w sieci LAN A wysyła DHCP Discover jako broadcast, który dociera do interfejsu G0/0 routera R1. R1 odbiera pakiet, dodaje pole giaddr z adresem 192.168.1.1 i wysyła go jako unicast do serwera 10.0.0.1. Serwer analizuje giaddr i wybiera pulę REMOTE_LAN dla sieci 192.168.1.0/24, przygotowując DHCP Offer z adresem z tej puli i bramą 192.168.1.1. Oferta jest wysyłana unicastem do R1, który przekazuje ją broadcastem w sieci LAN A. Klient otrzymuje adres IP z puli serwera centralnego, co jest przezroczyste z jego perspektywy.

Zastosowanie DHCP Relay wiąże się z koniecznością zważenia zalet centralizacji i ryzyka związanego z pojedynczym punktem awarii. Z jednej strony jeden centralny serwer DHCP znacząco upraszcza zarządzanie konfiguracją – administrator może w jednym miejscu zmienić adres serwera DNS, domenę czy dodać nową podsieć, a zmiany zostaną automatycznie zastosowane dla wszystkich klientów we wszystkich podsieciach. Z drugiej strony awaria centralnego serwera DHCP oznacza utratę możliwości przydzielania adresów we wszystkich podsieciach obsługiwanych przez relay, co może sparaliżować działanie całej sieci.

W sieciach krytycznych stosuje się pary redundantnych serwerów DHCP z mechanizmem failover. W Cisco można skonfigurować wiele adresów ip helper-address na jednym interfejsie, a serwery DHCP mogą działać w trybie active-passive z automatycznym przełączaniem. Na RouterOS mechanizm failover można zrealizować poprzez konfigurację dwóch wpisów DHCP Relay na tym samym interfejsie, kierując żądania do dwóch różnych serwerów. W środowiskach korporacyjnych często stosuje się również rozwiązania takie jak DHCP load balancing, które rozkładają obciążenie między serwerami, zwiększając zarówno wydajność, jak i niezawodność całego systemu.

Blok DHCP Relay przedstawia kompleksowe omówienie mechanizmu przekazywania żądań DHCP między podsieciami, który jest niezbędny w nowoczesnych sieciach VLAN. Głównym wnioskiem jest to, że DHCP Relay pozwala zachować centralne zarządzanie adresacją IP w sieciach rozproszonych, eliminując konieczność utrzymywania serwera DHCP w każdej podsieci. Mimo że konfiguracja w Cisco IOS jest prostsza (jedno polecenie ip helper-address), to model RouterOS oferuje większą kontrolę i przejrzystość dzięki wydzieleniu relay jako osobnego komponentu.

Niezależnie od wybranej platformy, kluczowym aspektem jest zrozumienie, że DHCP Relay działa w sposób przezroczysty dla klienta — urządzenie końcowe nie jest świadome, że serwer DHCP znajduje się w innej podsieci. W praktyce inżynierskiej DHCP Relay jest standardowym elementem konfiguracji w sieciach korporacyjnych z wieloma VLAN, a jego poprawne skonfigurowanie wymaga uwzględnienia zarówno aspektów technicznych (giaddr, routing), jak i organizacyjnych (redundancja serwerów, polityka bezpieczeństwa). Regularna weryfikacja działania relay za pomocą poleceń show ip dhcp binding i logów systemowych pozwala szybko wykryć ewentualne problemy.

Przykład praktyczny z Packet Tracer pokazuje krok po kroku, jak skonfigurować ACL blokującą SSH na routerze Cisco 4321. W tym scenariuszu sieć LAN A (192.168.1.0/24) reprezentuje wewnętrzną sieć firmową, w której znajduje się stacja robocza PC1, natomiast sieć LAN B (10.0.0.0/24) zawiera serwer Linux z usługą SSH. Celem administratora jest zablokowanie dostępu SSH z sieci LAN A do serwera przy jednoczesnym zachowaniu dostępu do innych usług (HTTP, ping itp.). ACL numer 110 została przypisana do interfejsu G0/1 w kierunku in, który jest interfejsem prowadzącym do sieci LAN B.

Po skonfigurowaniu ACL kluczowym krokiem jest weryfikacja jej działania. PC1 (192.168.1.10) próbuje nawiązać połączenie SSH z serwerem 10.0.0.100 – w Packet Tracer można to zasymulować za pomocą polecenia ssh -l user 10.0.0.100 z wiersza poleceń PC. Połączenie powinno zostać odrzucone, a na konsoli PC pojawi się komunikat o błędzie połączenia. Następnie warto przetestować ping z PC1 do serwera – powinien działać bez problemu, ponieważ reguła permit ip any any przepuszcza cały pozostały ruch. Polecenie show access-lists na routerze powinno pokazać rosnący licznik matches dla reguły deny, potwierdzając, że ACL działa zgodnie z założeniami.

Drugi przykład praktyczny demonstruje konfigurację routera Cisco 4321 jako serwera DHCP w środowisku Packet Tracer. Topologia jest prosta: router z jednym interfejsem G0/0 (192.168.1.1/24) podłączonym do przełącznika, do którego podłączeni są klienci w trybie DHCP. Proces konfiguracji rozpoczyna się od wykluczenia adresów statycznych – adres bramy (192.168.1.1) i adresy dla urządzeń infrastrukturalnych (192.168.1.2–192.168.1.10). Następnie tworzona jest pula LAN_POOL z siecią 192.168.1.0/24, bramą 192.168.1.1 i serwerem DNS 8.8.8.8 z czasem dzierżawy 6 godzin.

Po skonfigurowaniu serwera DHCP na routerze, klienci w sieci LAN mogą automatycznie pobrać adresację. W Packet Tracer wystarczy ustawić PC w trybie DHCP (IP Configuration → DHCP) i obserwować proces przydzielania adresu. Po pomyślnym pobraniu adresacji warto zweryfikować działanie serwera za pomocą polecenia show ip dhcp binding, które powinno wyświetlić adres MAC klienta, przydzielony adres IP oraz pozostały czas dzierżawy. Polecenie show ip dhcp pool pokazuje statystyki puli – liczbę przydzielonych i dostępnych adresów. Przykład ten można rozszerzyć o rezerwacje DHCP dla drukarek lub serwerów.

Trzeci przykład praktyczny w Packet Tracer ilustruje konfigurację DHCP Relay w topologii z dwoma routerami i dwiema podsieciami. Router R1 łączy sieć LAN A (192.168.1.0/24) z routerem R2 przez łącze punkt-punkt 10.0.12.0/30. Serwer DHCP działa na R2, który ma również skonfigurowaną pulę REMOTE_LAN dla sieci 192.168.1.0/24. Na interfejsie G0/0 routera R1 (sieć LAN A) skonfigurowano ip helper-address 10.0.0.1 – adres interfejsu G0/0 routera R2. Kluczowe jest, że router R2 musi mieć trasę do sieci 192.168.1.0/24 przez łącze 10.0.12.0/30, aby odpowiedzi DHCP mogły wrócić do klientów.

Testowanie konfiguracji w Packet Tracer polega na ustawieniu PC w sieci LAN A w trybie DHCP i obserwacji przydzielonych parametrów. PC powinien otrzymać adres IP z zakresu 192.168.1.0/24 (np. 192.168.1.2), bramę 192.168.1.1 oraz DNS 8.8.8.8 – wszystkie te parametry pochodzą z serwera DHCP na R2. Na routerze R2 można sprawdzić show ip dhcp binding, które wykaże dzierżawę dla adresu z sieci 192.168.1.0/24, potwierdzając, że DHCP Relay działa poprawnie. Przykład ten można rozbudować o dodatkowe sieci VLAN na przełączniku, demonstrując DHCP Relay dla wielu podsieci przez jeden interfejs routera.

Tabela porównawcza Cisco IOS vs RouterOS stanowi praktyczne narzędzie dla administratorów, którzy muszą pracować z obydwoma systemami. Zestawienie pokazuje, że mimo znaczących różnic w składni i podejściu konfiguracyjnym, każde zagadnienie koncepcyjne ma swój odpowiednik w obu platformach. W Cisco IOS konfiguracja jest bardziej hierarchiczna i sekwencyjna – przechodzi się między trybami global configuration, dhcp-config, interface-config. RouterOS stosuje model płaskich poleceń z podsystemami (/ip, /interface, /routing), co jest bliższe strukturze plików systemu Linux.

Z praktycznego punktu widzenia znajomość obu systemów jest cenną umiejętnością na rynku pracy. Cisco IOS dominuje w dużych sieciach korporacyjnych i centrach danych, gdzie wymagana jest certyfikacja CCNA/CCNP. RouterOS MikroTik jest popularny w sieciach ISP, małych i średnich przedsiębiorstwach oraz jako rozwiązanie ekonomiczne w edukacji. Mimo różnic kluczowe koncepcje – ACL, DHCP, routing – są identyczne, a różnice sprowadzają się do składni. Administrator, który rozumie logikę działania ACL i DHCP, będzie w stanie skonfigurować je w dowolnym systemie po krótkim zapoznaniu się z dokumentacją.

Podsumowanie prezentacji zestawia najważniejsze wnioski z obu bloków tematycznych. W zakresie ACL najistotniejsze jest zrozumienie trzech kluczowych zasad: sekwencyjnego dopasowania reguł (first match wins), domyślnej reguły odrzucającej (implicit deny) oraz znaczenia wyboru kierunku filtrowania (in vs out). W przypadku DHCP kluczowe jest opanowanie procesu DORA, umiejętność konfiguracji puli adresów z odpowiednimi opcjami oraz zrozumienie roli DHCP Relay w sieciach rozproszonych (z wieloma oddziałami). Porównanie Cisco IOS i RouterOS pokazuje, że mimo różnic składniowych koncepcje są uniwersalne.

Praktyczne umiejętności konfiguracji ACL i DHCP są niezbędne na każdym etapie kariery administratora sieci – od stanowisk juniorskich (konfiguracja podstawowych ACL i DHCP w małych sieciach) po seniorskie (projektowanie złożonych polityk bezpieczeństwa i architektur DHCP). Zachęcamy do samodzielnych eksperymentów w symulatorze Packet Tracer oraz na rzeczywistym sprzęcie laboratoryjnym, ponieważ praktyka jest kluczem do osiągnięcia biegłości. Wszystkie omówione scenariusze można odtworzyć w laboratorium, a kod konfiguracyjny z prezentacji może służyć jako szablon do własnych projektów sieciowych.