Co w sieci siedzi. Routing dynamiczny.

Transkrypt

1 1 (Pobrane z slow7.pl) Tak więc routing dynamiczny możemy zdefiniować jako zestaw algorytmów odpowiedzialnych za wymianę informacji pomiędzy routerami tak by urządzenia te uzyskały pełny obraz topologii naszej sieci oraz by były w stanie wypełnić swoje tablice routingu co w konsekwencji przełoży się wybór najlepszych tras do sieci zdalnych. Możemy wydzielić następujące składniki protokołów routingu: algorytmy funkcje matematyczne odpowiedzialne za sposób przetwarzania otrzymanych informacji o routingu, których celem jest określenie najlepszej trasy, struktury danych tablice, bazy danych, itp. komunikaty wiadomości wysyłane przez routery celem odkrycia sąsiadów a także służące wymianie informacji. Protokoły routingu mają jeden wspólny cel ale działanie każdego z nich różni się w zależności od wykorzystywanego protokołu, ale ogólnie możemy wyróżnić następujące fazy zdobywania i przetwarzania przez nie informacji: wymiana informacji pomiędzy routerami korzystającymi z tego samego protokołu routingu, wysyłanie i odbieranie informacji na aktywnych interfejsach routera, wymiana wiadomości celem pozyskania informacji o sieciach zdalnych, zmiana w topologii, wymusza na protokole routingu ogłoszenie tej informacji innym routerom. Pierwsze protokoły routingu powstały na początku lat osiemdziesiątych i wraz z rozwojem i rosnącym stopniem skomplikowania sieci, protokoły te ewoluowały w postaci nowszych wersji oraz pojawiały się całkiem nowe. Ale nie zmienia to faktu, że wiele starszych protokołów routingu jest w ciągłym użyciu. Szczególnie ma to miejsce w przypadku urządzeń SOHO w których do tej pory najczęściej implementowanym protokołem routingu dynamicznego jest RIP (w obu wersjach). Tak więc najważniejsze role jakie pełnią protokoły to: wymiana informacji pomiędzy routerami tak aby ich tablice routingu były aktualne, za pomocą wykorzystywanych algorytmów (a każdy protokół routingu korzysta z innego) określanie najlepszej ścieżki do każdej z sieci, dynamiczne uczenie się o sieciach zdalnych, automatycznie określanie tras alternatywnych w przypadku awarii trasy. Niewątpliwie zaletami stosowania protokołów routingu dynamicznego (dla mnie chyba najważniejsza zaleta) jest automatyczna reakcja na zmiany w topologii sieci. Topologia sieci może zmienić się z różnych powodów nie zawsze zależnych od nas, najczęściej dochodzi do uszkodzenia przewodu np.

2 2 (Pobrane z slow7.pl) łączącego poszczególne routery czy uszkodzenie samego interfejsu routera. Przy routingu statycznym administrator musi być na miejscu by wprowadzić poprawki pozwalające na przywrócenie łączności w naszej sieci aż do czasu naprawienia awarii. W przypadku routingu dynamicznego jeśli w naszej sieci istnieją nadmiarowe połączenia (redundancja) routery same będą w stanie zareagować na awarię i tak się między sobą dogadają, że będzie zachowana ciągłość komunikacji. Spójrz na rysunek poniżej, jeżeli administrator skonfigurowałby routing statyczny w ten sposób, że trasa z sieci /24 do sieci /24 prowadziłaby przez routery R_1 i R_2 i byłaby to jedyna trasa to w przypadku uszkodzenia łącza pomiędzy routerami R_1 i R_2, komunikacja pomiędzy tymi sieciami byłaby niemożliwa. W przypadku zaimplementowania routingu dynamicznego, podczas awarii łącza, trasa pomiędzy routerami R_1 a R_2 zostaje usunięta z tablic routingu, następuje ponowna analiza informacji posiadanych przez routery i instalacja trasy do sieci /24, której droga biegnie przez routery R_1, R_3 i R_2. A co najważniejsze nie jest potrzebna żadna ingerencja administratora w konfigurację routerów bo cały proces przebiega samoczynnie. Jeśli łącze zostanie naprawione proces aktualizacji tablic routingu powtórzy się i czynna już trasa zostanie ponownie uwzględniona. Do precyzując oczywiście to jaka trasa jest najlepsza zależy od stanu naszej sieci a także od użytego protokołu routingu dynamicznego (a raczej algorytmu z którego protokół korzysta), bo trasa wybrana przez jeden protokół jako optymalna nie musi się pokrywać z trasą wyznaczoną przez inny protokół. Niewątpliwie do zalet stosowania routingu dynamicznego można zaliczyć również mniejszą możliwość popełnienia pomyłki w konfiguracji urządzeń oraz lepszą skalowalność. Starte powiedzenie mówi Nie ma róży bez kolców. I w przypadku użycia protokołów routingu dynamicznego ma ono swoje potwierdzenie. Niewątpliwie do wad stosowania tego typu rozwiązania należy zaliczyć większe wymagania na zasoby sprzętowe i programowe (co tak naprawdę nie jest większym problem w nowoczesnych sieciach) a także odrębne podejście to kwestii bezpieczeństwa i potencjalnych zagrożeń. Protokoły routingu dynamicznego można sklasyfikować głównie według trzech kryteriów, tak jak na poniższym rysunku.

3 3 (Pobrane z slow7.pl) Pierwszy podział obejmuje klasę adresacji a więc protokoły dzielimy na: klasowe (classful) np. RIP v1, IGRP bezklasowe (classless) np. RIP v2, EIGRP, OSPF, IS-IS Zasadnicza różnica pomiędzy nimi polega na tym, że protokoły bezklasowe informują nie tylko o adresie sieci ale również o użytej masce, natomiast protokoły klasowe informują tylko o adresie sieci a maska jest przyjmowana w zależności od przynależności adresu sieci do danej klasy. Tak więc porównując ze sobą oba te typy protokołów można przypisać im następujące cechy: Protokoły klasowe: protokoły klasowe (starsze) jak już zostało wspomniane w swoich aktualizacjach nie przesyłają maski podsieci, działanie ich opiera się o klasy, maska sieci jest określana na podstawie pierwszego oktetu sieci, brak wsparcia dla VLSM, brak wsparcia dla CIDR, nie wspierają sieci nieciągłych. Protokoły bezklasowe (jak się można domyślić przeciwieństwo protokołów klasowych): protokoły bezklasowe (nowsze) przesyłają maskę podsieci w swoich aktualizacjach,

4 4 (Pobrane z slow7.pl) nie działają w oparciu o klasy, maska sieci określna jest na podstawie maski zawartej w aktualizacjach, wsparcie dla VLSM, wsparcie dla CIDR, wspierają sieci nieciągłe. Więcej o klasach adresów, CIDR i VLSM przeczytasz w wcześniejszym artykule owych-informacji. Drugi podział obejmuje miejsce użycia (zaimplemetowania) protokołów routingu: protokoły bramy wewnętrznej (IGP Interior Gateway Protocols) np. RIP, IGRP, RIPv2, EIGRP, OSPF, IS-IS, protokoły bramy zewnętrznej (EGP Exterior Gateway Protocols) np. EGP czy BGP. Protokoły bramy wewnętrznej (IGP) stosowane są w obrębie jednego systemu autonomicznego (domena routingu) czyli zbioru routerów będących pod wspólnym nadzorem administracyjnym, np. wewnętrzna sieć przedsiębiorstwa czy sieć ISP. Protokoły bramy zewnętrznej (EGP) służą do wymiany informacji pomiędzy poszczególnymi systemami autonomicznymi czyli obręb ich działania obejmuje cały Internet.

5 5 (Pobrane z slow7.pl) Ostatni podział opiera się na sposobie wyznaczania trasy do sieci zdalnych i tu możemy wyróżnić: protokoły wektora odległości (distance vector routing protocols) np. RIP, RIPv2, IGRP, EIGRP, protokoły stanu łącza, zwane również protokołami łącze-stan (link state routing protocols) np. OSPF, IS-IS, protokoły path-vector np. EGP, BGP. Jak widać po powyższym podziale protokoły wektora odległości oraz protokoły stanu łącza są używane przy routingu w sieciach autonomicznych (IGP) natomiast protokoły path-vector znajdują zastosowanie w wymianie informacji pomiędzy systemami autonomicznymi (EGP). By zrozumieć różnice występujące pomiędzy protokołami wektora odległości a protokołami stanu łącza posłużmy się taką o to analogią. Działanie protokołów wektora odległości można porównać do poruszania się po ulicach miasta ale poruszanie te oparte jest na informacjach uzyskanych jedynie z drogowskazów. Czyli dostarczana jest nam informacja: jak daleko do celu i w którą stronę musimy się udać. Wracając do routerów, routery ogłaszają trasy jako wektory czyli znana jest odległość oraz kierunek do docelowej sieci. Jeśli będziemy mówić o odległości to będziemy mieli do czynienia z tzw. metryką. Metryka to inaczej wielkość, która odzwierciedla nam koszt dotarcia do danej sieci. Dzięki zastosowaniu metryki, router jest w stanie użyć najlepszej ścieżki prowadzącej do punktu przeznaczenia w sytuacji, gdy będzie miał on informację o wielu ścieżkach prowadzących do tego samego miejsca. Ważne jest że każdy z protokół routingu wykorzystuje inną metrykę i niewolno ich porównywać (metryka wyznaczona przez jeden z protokołów ma się ni jak do metryki wyznaczonej przez inny protokół routingu dynamicznego). Metryką może być liczba przeskoków (ilość routerów) jaką musi pokonać pakiet by dotrzeć do celu czy inna, bardziej złożona wielkość. Różne protokoły w różny sposób obliczają metrykę (odległość) do danej sieci i tak np.: RIP liczba przeskoków (hop count), IGRP, EIGRP parametr obliczony na podstawie opóźnienia, szerokości pasma, niezawodności i obciążenia, OSPF parametr (koszt) obliczony na podstawie szerokości pasma. Informację na temat użytej metryki znajdziemy w tablicy routingu. Wydając polecenie show ip route oprócz zainstalowanych tras odnajdziemy również informację o wyznaczonej metryce. Rozszyfrujmy powyższy listing, w tablicy routingu znajdują się następujące wpisy:

6 6 (Pobrane z slow7.pl) C trasa podłączona bezpośrednio prowadząca do sieci /24 przez interfejs Serial0/0/1. S trasa statyczna prowadząca do sieci /24 przez adres następnego skoku Trasy statyczne skonfigurowane za pomocą adresu następnego przeskoku mają zawsze metrykę równą 0. D trasa zainstalowana przez protokół routingu dynamicznego EIGRP a prowadząca do sieci /24 gdzie adres następnego skoku to a interfejs wyjściowy to Serial0/0/0, metryka wynosi R trasa zainstalowana przez protokół routingu dynamicznego RIP a prowadząca do sieci /24 gdzie adres następnego skoku to a interfejs wyjściowy to Serial0/0/0, metryka wynosi2. O trasa zainstalowana przez protokół routingu dynamicznego OSPF a prowadząca do sieci /24 gdzie adres następnego skoku to a interfejs wyjściowy to Serial0/0/0, metryka wynosi Jak widać metryka przyjmuje diametralnie różne wartości zależne od użytego protokołu routingu. Natomiast kierunek to interfejs wyjściowy (lub/i) adres następnego skoku. Tak więc protokoły wektora odległości stosuje się w płaskich i prostych sieciach w których czas zbieżności nie jest problemem a także w tych sieciach w których pracują nieco starsze lub po prostu mniej wydajne routery, dla których obsłużenie protokołów stanu łącza może być problemem. Wracamy do naszej analogi poruszania się po ulicach miasta. Protokoły stanu łącza można porównać do poruszania się po drogach ale w tym przypadku mamy mapę miasta. Router określa najlepszą trasę do sieci docelowej w oparciu o informacje, które posiada od innych routerów. Na podstawie zebranych informacji router jest w stanie utworzyć pełny obraz sieci (topologię) i dzięki temu jest w stanie przesłać pakiet najlepszą znaną mu trasą. Protokołów stanu łącza używa się w dużych sieciach, najczęściej zaprojektowanych w sposób hierarchiczny w których pracują wydajne routery, będące w stanie obsłużyć ten typ routingu dynamicznego oraz w sieciach w których kluczowy jest czas osiągnięcia zbieżności. Pojawił się nowy termin a mianowicie czas zbieżności więc go wytłumaczmy. Czas zbieżności jest to czas potrzebny routerom np. po włączeniu ich czy w sytuacji zmiany topologii sieci, jaki musi upłynąć by posiadały one w swoich tablicach routingu spójne i prawidłowe informacje pozwalające im kierować pakiety do miejsca ich przeznaczenia. Na czas zbieżności mają wpływ takie składowe jak: wymiana informacji pomiędzy routerami, czas potrzebny do obliczenie najlepszych tras czy wysyłane aktualizacje. Sieć dopiero jest w pełni funkcjonalna gdy osiągnie zbieżność, zatem im czas zbieżności niższy tym lepiej. Nie jest tajemnicą, że czas zbieżności mocno zależny jest od typu zastosowanego protokołu routingu i tak wysokie czasy (wolne) osiągają takie protokoły jak: RIP, RIPv2, IGRP. Znacznie mniejszymi czasami (szybkie) mogą pochwalić się takie protokoły jak: EIGRP, OSPF czy IS-IS. By zakończyć rozważania na temat: protokołów wektora odległości vs protokołów stanu łącza i pokazać w czym tak naprawdę tkwi różnica, spójrz na poniższy rysunek.

7 7 (Pobrane z slow7.pl) Zadajmy sobie pytanie - Jaką trasę do sieci /24 wybierze router R_1? Odpowiedź nie jest jednoznaczna bo zależy od użytego protokołu routingu. RIP jako protokół wektora odległości wybierze trasę przez R_2. Metryką w tym scenariuszu jest ilość skoków a jak widać do sieci /24 przez router R_2 pakiet musi wykonać jeden skok natomiast druga alternatywna trasa wiedzie przez routery R_3 i R_2 (dwa skoki) ale ta trasa zostanie odrzucona jako gorsza. Analizując topologię sieci dojdziemy do wniosku, że ta trasa wybrana przez protokół RIP jest trasą nieoptymalną, bo choć pakiet musi pokonać tylko jeden router to prędkość łącza pomiędzy routerami R_1 i R_2 jest bardzo niska i lepsze rezultaty uzyskamy wybierając trasę wiodącą przez routery R_3 i R_2. Gdy użyjemy protokołu stanu łącza takiego jak np. OSPF, gdzie określana metryka uwzględnia szerokość użytego pasma w tablicy routingu zostanie zainstalowana trasa biegnąca przez routery R_3 i R_2. Jak widać na powyższym przykładzie użycie protokołu routingu dynamicznego nie jest rozwiązaniem w pełni bezkarnym bo czasami nieprzemyślane użycie takiego rozwiązania może dać efekty wręcz przeciwne od zamierzonych. W naszej sieci mogą wystąpić jeszcze dwa zjawiska związane z użyciem protokołów routingu dynamicznego. Pierwsza sytuacja ma miejsce gdy router otrzyma informacje o sieci zdalnej dostępnej np. dwiema różnymi trasami przy czym (co ważne) wyznaczona metryka jest ta sama. Czyli mamy scenariusz w którym występują dwie trasy o równorzędnej metryce. Natomiast druga sytuacja - co zrobi router gdy otrzyma trasę do sieci zdalnej lecz informacja ta pochodzi od np. dwóch różnych protokołów routingu. Czyli dana sieć zdalna jest dostępna dzięki informacją uzyskanym przez protokół RIP a jednocześnie ta sama sieć może być dostępna dzięki informacją uzyskanym od protokołu EIGRP (choć oczywiście kombinacje mogą być różne). To do dzieła, bierzemy na warsztat sytuację numer jeden. Spójrz na schemat poniżej. Za aktualizację tablic routingu odpowiada protokół RIP w wersji 2 (czemu wersja druga o tym za chwilę), router R_2 musi zainstalować trasę do sieci /24. Otrzymuje on informację od routera R_1 oraz R_3 o dostępności tej sieci. Obliczona metryka to 1. Czyli dochodzimy do sytuacji w której sieć /24 jest dostępna przez oba interfejsy routera R_2 a droga do tej sieci ma ten sam koszt (jeden przeskok). Router nie jest w stanie wybrać optymalnej trasy. Dlatego w tablicy routingu routera R_2 zostaną zainstalowane obie trasy a router zacznie wykonywać load balancing czyli równoważenie obciążenia. Od tej pory pakiety będą przesyłane naprzemiennie, pakiety które mają trafić do sieci /24 będą wysyłane zarówno do routera R_1 jak i routera R_3 (zostaną wykorzystane oba interfejsy routera).

8 8 (Pobrane z slow7.pl) Wpis w tablicy routingu przyjmie postać: Natomiast w scenariuszu drugim mamy sytuację w której router uzyskuje informację o sieci zdalnej lecz informacja ta pochodzi od dwóch różnych protokołów routingu dynamicznego. To tak jak

9 9 (Pobrane z slow7.pl) byśmy usłyszeli np. plotkę pochodzącą z dwóch różnych źródeł. Automatycznie nasuwa się pytanie Komu bardziej zaufać? I tu sytuacja jest analogiczna, jedna historia lecz dwie różne osoby je opowiadają, bo jak porównać metryki do tej samej sieci jeśli informacje pochodzą z dwóch różnych protokołów routingu? By rozwiązać ten problem wprowadzono parametr określający poziom zaufania dla danego protokołu routingu jako źródła informacji. Parametr ten nazwano dystansem administracyjnym (administrative distance) i przyjęto regułę - im dystans administracyjny niższy tym lepiej. Więc dystans administracyjny jest brany pod uwagę, wtedy gdy istnieje więcej niż jedno źródło informacji o ścieżce do danej sieci zdalnej. Zatem jeśli zdarzy się sytuacja w której router zostanie poinformowany np. następującymi informacjami: RIP dostarcza informację o sieci /24 z metryką 3 OSPF dostarcza informację o sieci /24 z metryką EIGRP dostarcza informację o sieci /24 z metryką to w tablicy routingu znajdzie się wpis, który zostanie dobrany zgodnie z ustalonymi wartościami dystansu administracyjnego zebranymi w poniższej tabeli: Domyślne dystanse administracyjne Urządzenie podłączone Trasa statyczna Skonsolidowana trasa EIGRP ebgp EIGRP (wewnętrzny) Protokół IGRP Protokół OSPF Protokół IS-IS Protokół RIP EGP ODR EIGRP (zewnętrzny) ibgp DHCP - learned Unknown Ponieważ najlepszy dystans administracyjny ma trasa wewnętrznego protokołu EIGRP (im krótszy dystans, tym wyższy priorytet), zostaje ona zainstalowana w tablicy routingu. Dystans administracyjny w tablicy routingu swoje odzwierciedlenie znajduje w wpisie trasy, jest to liczba przed metryką (uważni czytelnicy na pewno tę wartość zauważyli wcześniej i może już zastanawiali się cóż ona może znaczyć).

10 10 (Pobrane z slow7.pl) Dla potwierdzenia tej zasady, poniżej zrzut tablicy routingu routera R_2. Topologia sieci pozostaje bez zmian jedyna różnica z scenariuszem pierwszym jest taka, że na routerze R_2 i R_3 dodatkowo oprócz protokołu RIPv2 został skonfigurowany protokół EIGRP. Jak widać sieci /24 oraz /24 wcześniej ogłaszane przez protokół RIPv2 zostały zastąpione wpisami uzyskanymi od protokołu EIGRP. Podsumowując tematykę dystansu administracyjnego: dystans administracyjny może przyjąć wartość 0 255, im niższa wartość tym bardziej wiarygodne źródło informacji, wartość 0 przypisana jest trasą (siecią) bezpośrednio podłączonym parametru tego nie da się zmienić, wartość 1 posiadają trasy statyczne (domyślnie), wartość 255 oznacza, że trasa nigdy nie zostanie wpisana do tablicy routingu, wartość dystansu administracyjnego dla tras statycznych i tras dynamicznych może być modyfikowana, więc to, że dana trasa ma dystans administracyjny 110 wcale nie musi oznaczać, że pochodzi ona z OSPF. Z routingiem dynamicznym nieodzownie związane jest zagadnienie powstawania i zapobiegania pętlom routingu. Pętla routingu (routing loops) to sytuacja, w której pakiet jest przekazywany w kółko pomiędzy

11 11 (Pobrane z slow7.pl) dwoma (lub więcej) routerami i nie ma szans na dotarcie do celu. Najlepiej to zobrazuje sytuacja przedstawiona na rysunku poniżej. Przypuśćmy że router R_1 ma trasę prowadzącą do sieci /24 przez router R_2, natomiast router R_2 tę samą sieć /24 na wskutek np. błędnej konfiguracji będzie chciał wysłać z powrotem do routera R_1. Pakiety nigdy nie osiągną docelowej sieci bo jak ping pong będą odbijane raz od routera R_1 a drugi raz od routera R_2. Powstanie pętla w której to pakiety będą krążyć pomiędzy routerami. Oczywiście nie bez końca czytelniku a wiesz może dlaczego? Przypomnij sobie po co w pakiecie IP występuje pole TTL? Dla przypomnienia pole to zmniejszane jest o jeden gdy pakiet przechodzi przez router. Dlatego w końcu pakiet zostanie odrzucony gdy pole te osiągnie wartość 0. Dzięki temu pakiety będą kasowane ale nigdy nie osiągną celu czyli nie dotrą do sieci /24. A więc pętle routingu powstają wskutek błędów w konfiguracji tras statycznych a także wolnej zbieżności sieci a dzięki pewnym mechanizmom i rozwiązaniom zaimplementowanym w protokołach routingu dynamicznego a szczególnie tych opartych o wektor odległości występowanie ich zostało znacznie zredukowane. Problem pętli routingu nie występuje w protokołach łącze-stan (link-state). By zapobiegać powstawaniu pętli routingu wprowadzono następujące mechanizmy: określono metrykę maksymalną, wprowadzono timer hold-down, podzielony horyzont (split horizon), zatruwanie tras (route poisoning), podzielony horyzont z zatruciem wstecz (poison reverse), aktualizacje wyzwalane triggered update). Do poznania i wytłumaczenia tych mechanizmów, zapobiegających powstawaniu pętli routingu użyję następującej topologii.

12 12 (Pobrane z slow7.pl) Metryka maksymalna Routery wymieniając się aktualizacjami odnośnie routingu zwiększają metrykę do określonej sieci zdalnej. By uniknąć zjawiska zliczania do nieskończoności (count to infinity) wprowadzono ograniczenie odnośnie metryki czyli przyjęto jej maksymalną wartość. W przypadku protokołów z rodziny RIP granica ta wynosi 16. Oznacza to, że gdy router otrzyma informację o sieci zdalnej z metryką większą niż 15 odznaczy ją jako niedostępną. Timer hold-down Aby zapobiegać pętlom routingu wprowadzono liczniki, które determinują sposób działania protokołu RIP. Liczniki te to: licznik aktualizacji okresowych (update) aktualizacje wysyłane są w stałych określonych odstępach czasowych nawet gdy nie zaszła żadna zmiana w topologii sieci. Domyślnie licznik ten ustawiony jest na 30 sekund. Można zmienić domyślne ustawienie zakres od 5 do sekund. licznik uznania trasy za nieistniejącą (invalid) licznik ten domyślnie ustawiony jest na 180 sekund. Jeśli w tym czasie nie pojawi się komunikat odświeżający trasę, trasie zostaje przypisana metryka 16, co jak już wiesz czytelniku oznacza, że dana sieć jest nieosiągalna. Ale sieć ta nadal pozostaje w tablicy routingu, usuwana jest w momencie wygaśnięcia licznika oczyszczania. Zakres licznika można zmienić, dopuszczalne wartości od 1 do sekund. licznik oczyszczania (flush) wartość domyślna to 240 sekund czyli minuta więcej niż wynosi licznik uznania trasy za nieistniejącą, po osiągnięciu tego czasu trasa sieci zdalnej jest usuwana z tablicy routingu. Zakres zmiany wynosi od 1 do sekund. licznik wstrzymania (hold-down) - licznik został wprowadzony by uniemożliwić wprowadzenie wpisów o błędnych bądź niepoprawnych trasach do sieci zdalnych, tak by dać więcej czasu na osiągnięcie zbieżności przez sieć. Gdy w naszej sieci następuje zmiana topologii (np. nieczynne łącze) zostaje aktywowany timer a sieć oznaczana jest jako niedostępna (unavilable), lecz wpis prowadzący do tej sieci nadal znajduje się w tablicy routingu. Aktywowanie licznika ma na celu powstrzymanie routera przed wprowadzeniem zbyt pochopnie zmian. Oznacza to, że jeśli w czasie aktywności timera do routera przyjdzie informacja o takim samym bądź gorszym stanie trasy, anons ten jest ignorowany przez ustalony okres czasu.

13 13 (Pobrane z slow7.pl) Odebranie aktualizacji z innego źródła o lepszej metryce skutkuje wyłączeniem timera i wprowadzeniem wpisu trasy do tablicy routingu. Gdy timer ulega wygaśnięciu dopiero możliwe staje się dodanie trasy do sieci zdalnej o gorszej metryce. Licznik wstrzymania domyślnie ustawiony jest na 180 sekund a zakres jaki można wykorzystać do zmiany domyślnego ustawienia wynosi od 0 do sekund Wartość ustawionych liczników możemy sprawdzić po wydaniu polecenia show ip protocolos. Liczniki te można modyfikować według własnego uznania. Choć należy mieć świadomość, że może to spowodować problemy z routingiem a także jeśli modyfikujemy ustawienia liczników zmianę tą musimy wykonać na wszystkich pozostałych routerach biorących udział w routingu. Poleceniem odpowiedzialnym z zmianę wartości liczników jest polecenie: timers basic <update> <invalid> <holddown> <flush> (tryb konfiguracji routingu). Czyli wydajemy polecenie timers basic i podajemy cztery wartości odpowiadające odpowiednim licznikom: licznik aktualizacji okresowych; licznik uznania trasy za nieistniejącą; licznik wstrzymania; licznik oczyszczania.

14 14 (Pobrane z slow7.pl) Chcąc przywrócić domyślne ustawienia wydaj komendę no timers basic. Podzielony horyzont (split horizon) Zasada ta mówi o tym, że router nie rozgłasza (wysyła) informacji o sieciach poprzez interfejsy, z których informacja o nich została uzyskana. Reguła podzielonego horyzontu uniemożliwia przesłanie informacji o danej sieci z powrotem do źródła jej pochodzenia. Jak to się ma do naszej topologii? Ano tak. Router0 wysyła aktualizację o sieci /24 do Routera1, następnie router ten umieszcza sieć w swojej tablicy routingu i wysyła aktualizację jednocześnie zwiększając metrykę o sieci /24 do Routera2 (interfejs fa0/1) ale nie wysyła jej z powrotem (interfejs fa0/0) ponieważ naruszałoby to regułę podzielonego horyzontu. Należałoby by jeszcze dodać że routery Cisco umożliwiają wyłączenie stosowania tej reguły za pomocą komendy no ip split-horizon, wydanej w trybie konfiguracji interfejsu. W naszym przypadku routery są połączone point-to-point czyli jedno połączenie z jednym routerem i w takim przypadku stosowanie tej reguły jest jak najbardziej uzasadnione. Natomiast w połączeniach multipoint (jeden router przez jedno połączenie komunikuje się z kilkoma routerami np. do jednego switcha podłączonych jest 5 routerów czy w przypadku użycia sieci FrameRelay) działająca reguła podzielonego horyzontu może uniemożliwić prawidłowy routing. Podobna sytuacja może mieć miejsce w sieciach w których jest zapewniona redundancja (nadmiarowość) połączeń. Zatruwanie tras Rozważmy taką o to sytuacje - sieć /24 staje się nieosiągalna, Router0 odznacza sieć jako niedostępną i jednocześnie wysyła aktualizację do Routera1 w której wartość metryki dla sieci /24 wynosi 16. Router1 otrzymując taką informację usuwa wpis prowadzący do sieci zdalnej a aktualizację przekazuje dalej. Mówi się, że nastąpiło zatrucie trasy. Dzięki temu mechanizmowi sieć szybciej osiąga zbieżność.

15 15 (Pobrane z slow7.pl) Podzielony horyzont z zatruciem wstecz Mechanizm podzielonego horyzontu z zatruciem wstecz polega na wysłaniu aktualizacji routingu z danego interfejsu z informacją o nieosiągalności sieci zdalnych przy czym informacja o sieciach zdalnych, które są oznaczane jako nieosiągalne (zatrute) muszą być znane przez ten interfejs (router na tym interfejsie dowiedział się o istnieniu tych sieci). Czyli przekładając to na naszą topologię. Router0 wysyła do Routera1 informację o sieci /24, z metryką ustawioną na 1. Router1 wysyła aktualizację dalej do Routera2 a jednocześnie do Routera0 trafia informacja o nieosiągalności sieci /24 (metryka jest ustawiona na 16). Dzięki temu Router0 wie, że do sieci /24 na pewno nie dostanie się poprzez Router1. Aktualizacje wyzwalane Aby opisane mechanizmy mogły efektywnie działać, zadbano o to by informacja o niedostępności danej sieci była natychmiastowo rozgłaszana do sąsiadujących routerów. Oznacz to, że jeśli przez router zostanie wykryta zmiana w topologii sieci, natychmiast wyśle on informację o tej zmianie nie czekając na upływ timera sygnalizującego czas następnej aktualizacji okresowej. OK napisałem się i natłumaczyłem przechodzimy do przykładu gdzie postaram się to co wyżej opisałem pokazać w rzeczywistości. Posłużmy się tym samy przykładem co przy opisywaniu routingu statycznego a więc dla przypomnienia topologia sieci wygląda następująco:

16 Urządzenie Router R_1 Router R_1 Router R_2 Router R_2 Router R_2 Router R_2 Router R_2 Router R_2 Router R_3 Router R_3 Komputer PC1 Komputer PC2 Komputer PC3 Interfejs Fa0/0 S0/0/0 Fa0/0 S0/0/0 S0/0/1 Loopback 1 Loopback 2 Loopback 3 Fa0/0 S0/0/1 karta sieciowa karta sieciowa karta sieciowa 16 (Pobrane z slow7.pl) Adres IP Domyślna brama Routery, komputery zostały skonfigurowane, interfejsy mają przypisane adresy sieciowe przechodzimy do konfiguracji routingu. By uruchomić protokół routingu RIP, przechodzimy do trybu konfiguracji globalnej (router R_1) i wydajemy polecenie - router rip, by dostać się do trybu odpowiedzialnego za konfigurację protokołu RIP, wiersz poleceń przyjmuje postać - R_1(config-router). Musimy powiedzieć routerowi, które sieci ma rozgłaszać. Za rozgłaszanie sieci odpowiedzialne jest polecenie network <adres sieci> (nie podajemy maski, ponieważ protokół RIP jest protokołem klasowym). Tak naprawdę sprowadza się to do rozgłoszenia sieci, które są bezpośrednio podłączone do naszego routera. Jak widać na rysunku topologii sieci do routera R_1 bezpośrednio podłączone są dwie sieci /24 oraz /30, więc rozgłośmy te sieci. Sieci zostały dodane, protokół RIP został uruchomiony. Weryfikację powyższych ustawień możemy wykonać wydając następujące polecenia: a) show ip protocols

17 17 (Pobrane z slow7.pl) Po wydaniu tego polecenia uzyskamy informację o: 1. uruchomionym protokole routingu, 2. ustawionych taimerach i wysyłanych aktualizacjach, 3. interfejsach biorących udział w wymianie informacji i typach wysyłanych aktualizacji na powyższym przykładzie router R_1 wysyła aktualizacje: RIP wersja 1 natomiast odpiera aktualizacje: RIP wersja 1 i wersja rozgłaszanych sieciach, 5. tzw. interfejsach pasywnych (passive interface) o tym później, 6. dystansie administracyjnym. b) show running-config Informacja o uruchomionym protokole wraz z rozgłaszanymi sieciami przez ten protokół. c) debug ip rip Poleceniem tym włączamy debugowanie informacji związanych z protokołem RIP, jak widać uzyskujemy informację o wysyłanych aktualizacjach tj.: wersja wysyłanych aktualizacji (w naszym

18 18 (Pobrane z slow7.pl) przypadku RIP wersja 1), rozgłaszanych sieciach, metryce czy interfejsach wykorzystanych do wysłania aktualizacji. Jak widać protokół RIP wersja 1 do wysyłania aktualizacji używa adresu broadcast Debugowanie wyłączamy poleceniem: undebug ip rip bądź undebug all (wyłącza wszelkie debugowanie). Router R_1 został skonfigurowany przejdźmy do routera R_2. oraz routera R_3 Protokół został skonfigurowany sprawdźmy czy uzyskaliśmy połączenie. Sprawdźmy połączenie pomiędzy komputerami PC1 a PC3. Jak widać komunikacja jest niemożliwa a po odpowiedzi można domniemywać, że router R_1 nie ma pojęcia o istnieniu sieci /24. Sprawdźmy więc tablice routingu routera R_1.

19 19 (Pobrane z slow7.pl) Nasze przypuszczenie okazało się słuszne. Rzeczywiście brak jest wpisu trasy do sieci /24. Nasuwa się pytanie dlaczego tak się dzieje? Przecież jak widać ścieżki do innych sieci uzyskane dzięki uruchomieniu protokołu RIP pojawiły się w tablicy routingu. Choć wprawny obserwator pewnie zauważy pewne nieścisłości np. w wpisie prowadzącym do sieci /24 bo dlaczego jest tam maska /8? Zanim zacznę tłumaczyć taki stan rzeczy, sprawdźmy jeszcze tablicę routingu routera R_2. W tym przypadku zastanawiający jest zaznaczony wpis. Bo dlaczego nie pojawiły się sieci /24 oraz /24 tylko trasa a raczej trasy prowadzące do sieci /16 (dwie trasy, ta sama metryka = load balancing). By odpowiedzieć na te pytania musimy sobie zdać sprawę z ograniczeń protokołu RIP wersji 1. Wersja 1 ponieważ wydając polecenie router rip, taki protokół uruchomiliśmy.

20 20 (Pobrane z slow7.pl) Jak już wspomniałem protokół RIPv1 jest protokołem klasowym i nie wspiera takich mechanizmów jak VLSM i CIDR a jest to spowodowane tym jak było widać w przypadku debugowania, że w swoich aktualizacjach nie wysyła masek sieci. A więc protokół ten przyjmuje maski przypisane do poszczególnych zakresów adresów IP. Dla przypomnienia dla sieci prywatnych: w klasie A: zakres od do , maska domyślna ( /8), w klasie B: zakres od do , maska domyślna ( /16), w klasie C: zakres od do maska domyślna ( /24). I tu mamy odpowiedź dlaczego w wpisach tablicy routingu routera R_1 i R_2 znalazły się takie sieci jak: /8 oraz /16 (zresztą to samo się tyczy się sieci /24 na routerze R_1) Brak wsparcia dla VLSM i CIDR powoduje, że niemożliwe jest zainstalowanie ścieżki prowadzącej do sieci zdalnej z inną maską niż domyślna, nie zainstalujemy np. trasy z maską dłuższą niż domyślna np /30 ale również trasy z maską krótszą niż domyślna np /16. Jeszcze jednym bardzo ważnym ograniczeniem protokołu RIPv1 jest brak obsługi sieci nieciągłych czyli mówiąc w skrócie jeżeli mamy w naszej sieci, podsieci należące do różnych klas adresów protokół RIPv1 nam takich posieci nie obsłuży. A więc jak zapewnić routing w tak zbudowanej sieci? Oczywiście można to wykonać, lecz do tego celu wykorzystamy również protokół RIP ale w wersji drugiej (RIPv2). W porównaniu do swojego starszego brata w RIPv2 wprowadzono: informacja o masce podsieci zawarta jest w aktualizacji RIP, zmianę sposobu rozgłaszania, zamiast wykorzystywać adres broadcast wykorzystano adres multicast, opcjonalne uwierzytelnianie, adres następnego przeskoku dołączony jest do aktualizacji. Pozostało bez zmian: zachowano mechanizm split-horizon i split-horizon with poison reverse, triggered updates, timery, maksymalna liczba przeskoków 15, 16 przeskoków = nieskończoność (sieć nieosiągalna). Różnice pomiędzy obiema wersjami protokołu RIP można zaobserwować po analizie przechwyconych pakietów aktualizacji RIP (nie zwracaj uwagi czytelniku na adresy źródłowe pakietów gdyż nie są one związane z naszą przyjętą topologią, moim celem jest pokazanie różnic pomiędzy obiema wersjami protokołu RIP). Pakiet RIPv1

21 Po analizie pakietu można stwierdzić, co poniżej: 1. aktualizacja jest wysyłana na adres broadcastowy aktualizacje przenoszone są poprzez protokół UDP, port 520, 3. w aktualizacjach zawarta jest informacja o adresie sieci oraz metryce. Pakiet RIPv2 21 (Pobrane z slow7.pl)

22 22 (Pobrane z slow7.pl) Analiza pakietu aktualizacji RIPv2 uwidacznia nam różnicę pomiędzy wersją 1 a wersją 2: 1. zmiana adresu wysyłania aktualizacji na adres multicast protokół warstwy transportowej oraz wykorzystywany port nie uległ zmianie, 3. do aktualizacji dołączono informację o masce sieci oraz adresie następnego skoku. A więc sprawdźmy czy uruchamiając RIP w wersji drugiej nasza sieć w końcu zacznie działać. Aby uruchomić RIPv2 trzeba wydać jedno dodatkowe polecenie (w 50% procentach rozwiązuje to nasze problemy z routingiem dynamicznym przy wykorzystaniu protokołu RIP) a więc w linii poleceń odpowiedzialnej za konfigurację routingu dodajemy version 2. No to wprowadźmy tą zmianę, polecenie wydajemy na wszystkich routerach.

23 23 (Pobrane z slow7.pl) Sprawdźmy czy protokół RIPv2 został uruchomiony i czy działa poprawnie, wydajmy polecenie show ip protocols. Z zrzutu widać, że router R_1 wysyła aktualizacje RIP w wersji drugiej i takie same odbiera. Należy dopowiedzieć, że uruchamiając RIPv1 protokół ten będzie odbierał aktualizacje wersji 1 jak i 2 (wysyłana będzie aktualizacja wersja 1), natomiast domyślnie router z uruchomionym protokołem RIPv2 wysyła i przetwarza aktualizacje tylko wersji 2. Aby zachować kompatybilność pomiędzy różnymi wersjami protokołu RIP, skorzystaj z poleceń ip rip send oraz ip rip received, polecenia wydajemy w trybie konfiguracji interfejsu. Sprawdźmy jeszcze co wykaże proces debugowania:

24 24 (Pobrane z slow7.pl) Tu już mamy więcej danych: widać, że adres wysyłania aktualizacji to adres multicast a także jakie informacje router wysyła oraz jakie informacje router odbiera (adres sieci, maska, interfejsy, metryka). OK RIPv2 jest uruchomiony czas sprawdzić czy komunikacja jest już możliwa. Wykonajmy ten sam test co wcześniej czyli wyślijmy ping z komputera PC1 do PC2. I niestety pomimo naszych wszystkich starań sieć dalej nie działa. Można by zapytać ale o co chodzi? Sprawdźmy więc tablice routingu routera R_1 oraz R_2.

25 25 (Pobrane z slow7.pl) Jak widać nie nastąpiła żadna zmiana tablic routingu w porównaniu z protokołem RIPv1. Pewnie niektórym zapaliła się czerwona lampka przy stwierdzeniu, że wydanie komendy odpowiedzialnej za uruchomienie drugiej wersji protokołu RIP rozwiązuje sprawę w 50% - no bo co z pozostałymi 50%. Za widniejące wpisy znajdujące się w tablicach routingu jest odpowiedzialny mechanizm, który z reguły ma nam pomóc niż zaszkodzić. Mowa tu o sumaryzacji tras. Mechanizm ten został opisany przy routingu statycznym a odpowiedzialny jest za zmniejszenie wpisów w tablicach routingu. Sieci do siebie przyległe zostają zsumaryzowane do jednej. Dzięki temu zamiast np. 10 wpisów mamy 1. Działanie tego mechanizmu w pewnych sytuacjach (jak to ma miejsce w tym przypadku) przynosi więcej szkody niż pożytku. Dlatego by móc zapewnić zbieżność sieci należy go wyłączyć. Więc za pomocą polecenia no auto-summary wydanym w linii poleceń konfiguracji routingu rozwiązujemy pozostałe 50% problemów związanych z protokołem RIP. Nie pozostało nam nic innego jak sprawdzić efekt wydania tej komendy. Komendę no auto-summary wydajemy na wszystkich routerach.

26 26 (Pobrane z slow7.pl) Sprawdźmy efekt naszych działań. Wydajmy polecenie ping skierowane do komputera PC3, oczywiście pakiet wysyłamy z komputera PC1. No i mamy SUKCES. Komunikacja jest zapewniona można przesyłać dane pomiędzy hostami. Zajrzyjmy jeszcze do tablic routingu. Router R_1.

27 Router R_2. Oraz router R_3. 27 (Pobrane z slow7.pl)

28 28 (Pobrane z slow7.pl) Jak widać na powyższych zrzutach wszystkie sieci są dostępne, dzięki czemu wszystkie urządzenia w naszej topologii mają zapewnioną komunikację. W naszej sieci może dojść do jeszcze jednej sytuacji A co jeśli topologia naszej sieci wykorzystuje oprócz routingu dynamicznego również routing statyczny. Rodzi się pytanie Jak przekazać innym routerom informacje o skonfigurowanych trasach statycznych? Aby zasymulować tę sytuację skorzystamy z tzw. interfejsu zerowego (null interface). Interfejs zerowy jest zawsze włączony (nie trzeba wydawać żadnych dodatkowych komend) ale nie wysyła on i również nie odbiera żadnego ruchu. Każdy pakiet, który trafia do interfejsu zerowego jest odrzucany. My wykorzystamy go do utworzenia trasy statycznej na routerze R_1 a następnie informację o tej trasie statycznej przekażemy pozostałym routerom. Tworzona sieć to zgodnie z rysunkiem poniżej.

29 A więc skonfigurujmy trasę statyczną. Sprawdźmy jeszcze czy trasa ta została do tablicy routingu. 29 (Pobrane z slow7.pl)

30 30 (Pobrane z slow7.pl) Trasa znajduje się w tablicy routingu, czas by ta informacja trafiła do innych routerów. By nakazać routerowi dołączenie tej trasy do aktualizacji routingu trzeba skorzystać z polecenia redistribute static (tryb konfiguracji routingu). Sprawdźmy czy trasa została dodana do aktualizacji routingu. Po włączeniu debugowania protokołu RIP widać, że trasa do sieci /16 zostaje umieszczona w aktualizacji routingu. Nie pozostało nam nic innego jak sprawdzenie tablic routingu routerów R_2 oraz R_3.

31 31 (Pobrane z slow7.pl) Informacja o trasie statycznej znajdującej się na routerze R_1, została przekazana do innych routerów od tej pory możliwa jest komunikacja z siecią /16. Osobnego wytłumaczenia wymaga redystrybucja trasy domyślnej np. wykorzystanej do podłączenia z ISP. A więc w naszej topologii zachodzi mała zmiana a mianowicie do routera R_2 zostaje doprowadzone nowe łącze, które łączy router R_2 z Internetem.

32 32 (Pobrane z slow7.pl) Aby przekazać cały ruch nie pasujący do skonfigurowanych sieci na routerze R_2 została skonfigurowana trasa domyślna. Aby routery R_1 i R_3 dowiedziały się o niej wydajemy polecenie default-information originate (tryb konfiguracji routingu). Od tej pory informacja o trasie domyślnej zostaje włączona do aktualizacji. A także trasa domyślna zostaje umieszczona w tablicach routingu routera R_1 oraz R_3.

33 33 (Pobrane z slow7.pl) Od tej pory wszystkie hosty w naszej sieci mają dostęp z Internetem (choć jeszcze wypadałoby skonfigurować NAT). Kilka akapitów wyżej, wspomniałem o tzw. passive interface, więc czas by wytłumaczyć o co chodzi. Po uruchomieniu protokołu routingu RIP, aktualizacje są wysyłane na wszystkie interfejsy routera czyli router R_1 wysyła aktualizacje RIP zarówno poprzez interfejs f0/0 jak i s0/0/0. Jak łatwo zauważyć do interfejsu f0/0 jest podłączony tylko host, więc wysyłanie aktualizacji RIP poprzez ten interfejs jest zbędne ponieważ aktualizacje te może przetworzyć tylko router. Wysyłanie aktualizacji poprzez interfejs do którego nie jest podłączony router mija się z celem bo aktualizacje te raz, że marnują pasmo, dwa zużywają zasoby routera a trzy stanowią źródło potencjalnych niebezpieczeństw. Do

34 34 (Pobrane z slow7.pl) wyłączenia wysyłania aktualizacji RIP poprzez dany interfejs służy komenda: passive interface <interfejs> wydana w trybie konfiguracji routingu. Reasumując w naszej topologii należy wyłączyć wysyłanie aktualizacji poprzez interfejsy: router R_1 interfejs f0/0 router R_2 interfejs f0/0 router R_3 interfejs f0/0 Wszystkie te interfejsy mają łączność tylko z hostami więc poprzez wydanie poniższych komend wyłączamy wysyłanie aktualizacji. Od tej pory w pełnej wymianie informacji o routingu biorą udział tylko interfejsy serialowe. Wspomniałem, że wysyłanie informacji w kierunku hostów może narazić naszą sieć na niebezpieczeństwo. Dziej się tak ponieważ pakiety z aktualizacjami RIP można przechwycić co atakującemu daje informację o użytej adresacji w naszej sieci. By rozpocząć rozważanie o kwestii bezpieczeństwa przygotowałem małą prościutką sieć jak na rysunku poniżej, jeden router z włączonym protokołem routingu RIP oraz jednym komputerem do którego trafiają te aktualizacje. Jak widać do interfejsu routera R1 o adresie jest podłączony jeden komputer, którego adres IP to W tablicy routingu routera znajduje się jedna sieć /24

35 Włączony jest protokół RIPv1. Poprzez interfejs, router wysyła swoje aktualizacje. 35 (Pobrane z slow7.pl)

36 36 (Pobrane z slow7.pl) Aktualizacje te trafiają do komputera ale są przez niego nie przetwarzane. Na komputerze znajduje się program, który potrafi wysłać spreparowane pakiety RIP. Ten typ ataku nosi nazwę spoofing (ang. spoof naciąganie, szachrajstwo) a polega na umieszczaniu w sieci preparowanych, modyfikowanych lub uszkodzonych pakietów danych. W tym przypadku będziemy wysyłać fałszywe aktualizacje RIP. Naszym celem jest umieszczenie w tablicy routingu sieci, które to będą osiągalne właśnie poprzez komputer PC np /24 i /24. Program zostaje uruchomiony, fałszywe aktualizacje zostają wysłane do routera, co przedstawia poniższy rysunek. Aktualizacje te trafiają do routera R1 (patrz poniżej), widać że router odebrał je na swoim interfejsie ethernetowym. Następnie trasy zostają umieszczone w tablicy routingu.

37 37 (Pobrane z slow7.pl) Od tej pory jeśli router odbierze pakiety przeznaczone do sieci /24 oraz /24 wyśle je w kierunku komputera PC. Jak łatwo się domyślić stanowi to poważne naruszenie bezpieczeństwa ponieważ cały ruch od tej pory może być przechwytywany i analizowany celem znalezienia poufnych danych (hasła, loginy itp.). Przed tego typu atakiem nie uchroni nas wyłączenie wysyłania aktualizacji routingu na interfejsach, które są bezpośrednio podłączone z hostami, ponieważ w protokole RIP (inaczej jest w przypadku EIGRP i OSPF) polecenie passive-interface blokuje wysyłanie aktualizacji RIP przez dany interfejs ale nie blokuje aktualizacji przychodzących. Dlatego by zwiększyć poziom bezpieczeństwa naszej sieci możemy wykorzystać uwierzytelnienie aktualizacji pomiędzy routerami. Wprowadzenie uwierzytelnienia zapobiega uszkodzeniu tras np. przez dodanie nieautoryzowanego routera protokołu RIP czy jak to w scenariusz opisanym powyżej, przeprowadzenia skutecznego ataku mającego na celu wprowadzenie do tablic routingu niewłaściwych wpisów. Interfejsy routerów protokołu RIPv2 można skonfigurować tak aby korzystały z hasła. Odebrane anonse protokołu RIP, które nie odpowiadają hasłu, są odrzucane. Topologia naszej sieci wygląda następująco:

38 38 (Pobrane z slow7.pl) Zadaniem naszym jest skonfigurowanie uwierzytelnienia pomiędzy routerami. Routing dynamiczny został włączony sieci są rozgłaszane, sieć jest zbieżna. Natomiast procedura ustawienia uwierzytelnienia sprowadza się do dwóch kroków: 1. ustawienia hasła (tryb konfiguracji globalnej) za pomocą komendy key-string (bardzotajnehaslo), 2. przypisania hasła do interfejsu (tryb konfiguracji danego interfejsu). W powyższym przykładzie hasło będzie przesyłane jawnie czyli nie będzie szyfrowane. Uruchomienie procesu debugowania na routerze R2 ujawni nam te hasło. Widać, że router odbiera pakiet aktualizacji z ustawionym uwierzytelnieniem. Hasło również zdobędziemy jeśli uda na się przechwycić pakiet aktualizacji RIPv2.

39 39 (Pobrane z slow7.pl) Po uruchomieniu uwierzytelnienia na routerze R1 nasza sieć straciła zbieżność. Niemożliwa jest komunikacja z siecią /24, która jest dostępna poprzez router R1.

40 40 (Pobrane z slow7.pl) By przywrócić komunikację, musimy włączyć uwierzytelnienie na routerze R2. Proces przebiega analogicznie jak na routerze R1. Włączenie uwierzytelnienia na routerze R2 powoduje odzyskanie zbieżności sieci, sieć /24 ponownie jest osiągalna.

41 41 (Pobrane z slow7.pl) Przesyłanie hasła jawnie, ułatwia potencjalnemu intruzowi zaburzenie działania naszej sieci. Dlatego bardziej bezpieczną opcją jest skorzystanie z szyfrowania naszego hasła, tak by nie było one przesyłane czystym tekstem. By to wykonać postępujemy podobnie jak w przypadku włączenia uwierzytelnienia z tekstem jawny z jedną małą różnicą. Różnica ta sprowadza się do wydania jednej dodatkowej komendy, która nakazuje routerowi shashowanie hasła za pomocą algorytmu md5. Komendę tą wydajemy w trybie konfiguracji interfejsu. Router R1. Router R2.

42 42 (Pobrane z slow7.pl) Tym razem włączenie procesu debugowania ujawnia nam tylko informację o włączonym uwierzytelnieniu protokołu RIPv2. Natomiast przechwycony pakiet aktualizacji już tak łatwo nie zdradzi nam hasła.

43 43 (Pobrane z slow7.pl) Innym mechanizmem chroniącym router przed dodawaniem niewłaściwych wpisów do tablicy routingu jest skorzystanie z tzw. distribute-list bądź skorzystanie z mechanizmu ACL, który to przefiltruje nam ruch UDP na porcie 520 (protokół i port używany przez protokół RIP) CDN...