150875
numer indeksu
Grzegorz Graczyk
imie i nazwisko
151021
numer indeksu
Paweł Tarasiuk
imię i nazwisko
Data 2010-03-03
Kierunek Informatyka Rok akademicki 2009/10
Semestr 4
Grupa dziekańska 2 Grupa laboratoryjna 15
Laboratorium
podstaw sieci komputerowych
Zadanie 4
Część teoretyczna
Umiejscowienie protokołu Ethernet w modelu ISO/OSI
Protokół Ethernet został zdefiniowany przez standard IEEE 802.3. Standard ten obejmu- je specyfikację kabli oraz przesyłanych sygnałów. Opisane są w nim także protokoły dwóch najniższych warstw modelu ISO/OSI (fizycznej oraz łącza danych) wraz z formatami pakietów.
Protokół Ethernet według standardu IEEE802.3 definiuje podział warstwy łącza danych modelu OSI podzieloną na dwie podwarstwy: podwarstwę MAC (Media Access Control) oraz podwar- stwę klienta MAC. Natomiast opisana w standardzie IEEE802.3 warstwa fizyczna dokładnie odpowiada warstwie fizycznej z modelu ISO/OSI.
Popularne odmiany Ethernetu, ich topologie, okablowanie i ograniczenia, bu- dowa ramki
Istnieje wiele różnorodnych odmian Ethernetu. Poniżej omówione zostały różnorodne imple- mentacje sprzętowe przesyłania danych w standardzie Ethernet:
Najwcześniej powstałe realizacje Ethernetu to:
• Xerox Ethernet – oryginalna implementacja firmy Xerox używająca ramek formatu 1 i 2.
• 10BASE5, zwana też ThickNet (czyli ”gruby koncentryk”) – standard IEEE 802.3 z 1980 roku, używający grubego (średnica 12 mm) kabla koncentrycznego o impedancji 50 Ω.
Kabel ten umożliwiał budowę segmentów o długości do 500 m. Obecnie już nie stosowa- ny (nie powstają już nowe rozwiązania oparte o tą odmianę), ale można spotkać nadal pracujące instalacje, których migracja na inne technologie nie jest potrzebna. Połączenie zrealizowane w tej technologii pozwalało na uzyskanie przepustowości 10 Mb/s.
• 10BROAD36 – przestarzała implementacja, pracująca na 75 Ω kablu TV.
• 1BASE5 – także przestarzała technologia, pozwalająca uzyskać szybkość 1 Mb/s.
• StarLAN 1 – pierwsza implementacja w oparciu o kabel będący skrętką.
Wersje Ethernetu pozwalające na uzyskanie przepustowości 10 Mb/s:
• 10BASE2, bądź popularnie ThinNet albo Cheapernet (”cienki koncentryk”) – implementa- cja z wykorzystaniem kabla koncentrycznego o średnicy około 5 mm. W tej realizacji kabel musiał biec pomiędzy wszystkimi kartami sieciowymi wpiętymi do sieci. Karty podłącza się za pomocą tzw. ”trójnika”, do którego podpina się także kabel za pomocą złącz BNC. Na obu końcach kabla montowany jest dławik (bądź ”terminator”) o impedancji 50 Ω. Maksy- malna długość segmentu wynosiła 185 m, chociaż specyficzne rozwiązania niektórych firm np. 3COM dopuszczały nawet do 300 m. Przez wiele lat była to dominująca forma sieci Ethernet. Jej kluczową wadą było to, że uszkodzenie kabla w jednym miejscu powodowało uniemożliwienie działania sieci w całym segmencie.
• StarLAN 10 – pierwsza implementacja w oparciu o kabel będący skrętką, która umożliwiła uzyskanie szybkości 10 Mb/s.
• 10Base–T – kabel pracujący na 4 żyłach (dwóch parach ”skrętki”), kategorii 3 lub 5.
Każda karta sieciowa musi być podłączona do huba lub switcha. Maksymalna długość kabla wynosi 100 m. W przeciwieństwie do 10BASE2, awaria kabla w jednym miejscu powodowała zanik dostępu do sieci tylko jednego komputera. To właśnie było przyczyną stopniowego wyparcia realizacji 10Base2 przez 10Base–T.
• FOIRL – (Fiber–optic inter–repeater link) – pierwotny standard Ethernetu realizowanego za pomocą światłowodu.
• 10BASE–F – rodzina standardów 10BASE–FL, 10BASE–FB i 10BASE–FP, pozwalających na realizację Ethernetu za pomocą światłowodu.
• 10BASE–FL – ulepszony standard FOIRL. Jedyna szeroko stosowana implementacja z rodziny 10BASE–F.
• 10BASE–FB – standard przeznaczony do łączenia hubów lub switchy, przestarzały.
• 10BASE–FP – standard do sieci nie wymagających elementów aktywnych (hubów, swit- chy). Nigdy nie został on zaimplementowany.
Wersje określane jako ”Fast Ethernet” - czyli przepustowość około 100 Mb/s:
• 100BASE–T – rodzina 3 standardów Ethernetu 100 Mb/s, realizowanych na kablu będącym skrętką. Obejmuje ona 100BASE–TX, 100BASE–T4 i 100BASE–T2.
• 100BASE–TX – standard podobny do 10BASE–T, ale z szybkością 100 Mb/s. Wymaga 2 par skrętki i kabli kategorii 5. Obecnie jest to jeden z najpopularniejszych standardów sieci opartych na skrętce.
• 100BASE–T4 – Używa 4 par skrętki kategorii 3. Obecnie przestarzały.
• 100BASE–T2 – Miał używać 2 par ’skrętki’ kategorii 3. Nigdy nie powstał jednak sprzęt sieciowy wspierający ten typ Ethernetu.
• 100BASE–FX – Ethernet 100 Mb/s realizowany za pomocą włókien światłowodowych.
Gigabit Ethernet, czyli, zgodnie z nazwą, standardy pozwalające osiągnąć przepustowości około 1 Gb/s:
• 1000BASE–T – 1 Gb/s na kablu miedzianym kat. 5 lub wyższej. Ponieważ kabel kategorii 5e może bez strat przenosić do 125 Mb na sekundę, osiągniecie 1000 Mb/s wymaga uży- cia czterech par przewodów oraz modyfikacji układów transmisyjnych dającej możliwość transmisji ok 250Mb/s na jedną parę przewodów w skrętce.
• 1000BASE–SX – 1 Gb/s na światłowodzie (do 550 m).
• 1000BASE–LX – 1 Gb/s na światłowodzie (do 550 m). Zoptymalizowany dla połączeń na dłuższe dystanse (do 10 km) za pomocą światłowodów jednomodowych.
• 1000BASE–LH – 1 Gb/s na światłowodzie (do 100 km).
• 1000BASE–CX – 1 Gb/s na specjalnym kablu miedzianych na odległość do 25 m. Obecnie przestarzały i wyparty przez 1000BASE–T.
10 Gigabit Ethernet - przepustowości rzędu 10 Gb/s:
• 10GBASE–SR – Ethernet 10 Gb/s przeznaczony dla światłowodów wielomodowych o mak- symalnym zasięgu od 26 do 82 m (przy 850 nm średnicy włókna). Umożliwia także zasięg 300 m przy wykorzystaniu nowszych światłowodów wielomodowych 2000 MHz/km.
• 10GBASE–LX4 – implementacja światłowodowa wykorzystująca modulację typu ’WDM’
umożliwia zasięg 240 lub 300 m za pomocą światłowodów wielomodowych (przy 1310 nm średnicy włókna) lub 10 km przy wykorzystaniu światłowodów jednomodowych.
• 10GBASE–LR – Ethernet wykonany za pomocą światłowodów jednomodowych, pozwala- jący przesyłać dane na odległość 10 km.
• 10GBASE–ER – Ethernet wykonany za pomocą światłowodów jednomodowych, pozwala- jący przesyłać dane na odległość 40 km.
• 10GBASE–SW, 10GBASE–LW i 10GBASE–EW – odpowiedniki 10GBASE–SR, 10GBASE–
LR i 10GBASE–ER używające transmisji synchronicznej na tych samych typach światło- wodów i tych samych odległościach.
Inne realizacje Ethernetu:
• Ethernet bezprzewodowy – opisany w IEEE 802.11. Wymiana danych z szybkościami od 11 do 54 Mb/s za pomocą urządzeń radiowych.
• 100BaseVG – standard zaproponowany przez firmę Hewlett–Packard o szybkości 100 Mb/s na 2 parach skrętki kategorii 3. Nie został rozpowszechniony.
Spośród różnych sposobów łączenia urządzeń sieciowych, czyli topologii, można wyróżnić następujące:
• Topologia magistrali – wszystkie urządzenia podłączone są do pojedynczego przewodu (zazwyczaj - do kabla koncentrycznego), który pełni funkcję łącza. Jeszcze kilkanaście lat temu topologia magistrali była najczęściej spotykaną w praktyce topologia sieci. Sieć w takiej topologii jest łatwa do zainstalowania i łatwo w niej wykrywać usterki – to jej dwie decydujące zalety. Wadami tej topologii są: ograniczenie odległości między urządzeniami oraz ograniczenie liczby klientów które mogą pracować w takiej sieci.
• Topologia gwiazdy – W tej strukturze wszystkie urządzenia łącza się z wybranym spośród nich urządzeniem centralnym, które przyjmuje transmisję od nadawcy i przekierowuje dane do odpowiedniego odbiorcy. Urządzeniem centralnym jest zwykle koncentrator lub prze- łącznik.
• Topologia pierścienia – Podstawowym projektantem technologii Token Ring (czyli pierście- nia z przekazywaniem żetonu), która zapewnia kontrolę nad jednoczesnością pracy wielu klientów sieci, była firma IBM . Aby móc umieścić dane w sieci, klient musi posiadać że- ton (token) dostępu do sieci. Żeton przekazywany jest kolejno w logicznym pierścieniu. W każdej chwili w sieci dostępny jest tylko jeden żeton, dzięki czemu jednocześnie tylko jeden klient może z niego skorzystać. Mechanizm ten może sprawiać wrażenie spowalniającego ruch w sieci, lecz w sieci typu Token Ring żeton może być przesłany wzdłuż pierścienia o długości 2 kilometrów nawet 10000 razy na sekundę.
• Topologia oczkowa – Najbardziej odporną na uszkodzenia struktura sieci jest topologia oczkowa (Mesh). W tej topologii jedyną możliwością załamania pracy sieci jest klęska żywiołowa. Topologie oczkowe stosowane mogą być wyłącznie w bardzo małych sieciach, z uwagi na wymogi sprzętowe. Po zainstalowaniu, nadmiarowe transmisje w tej topologii są znikome. Właśnie dzięki nadmiarowości w każdym kliencie, dopuszczalna jest awaria nawet kilku składników.
• Topologia hybrydowa gwiazda–magistrala – Zbiór sieci o topologii gwiaździstej, połączo- nych magistralą, daje w wyniku topologię hybrydowa gwiazda–magistrala. Chociaż nie daje ona odporności na uszkodzenia, nie posiada również pojedynczego punktu awarii, który uniemożliwiałby pracę całej sieci.
• Gwiazda–pierścień – Zbiór sieci o topologii gwiazdy połączonych pierścieniem daje w wy- niku topologię hybrydowa gwiazda–pierścień, która należy do najczęściej stosowanych to- pologii hybrydowych. Ma przewagę nad topologią gwiazda–magistrala, gdyż jest odporna na uszkodzenia. W tym rozwiązaniu topologia pierścienia zawiera pierścień podstawowy i zapasowy. Jeśli któryś z nich zostanie uszkodzony, siec funkcjonuje nadal. Jeśli zawiedzie jedna z sieci gwiaździstych, reszta sieci również funkcjonuje dalej. W typowej topologii hybrydowej gwiazda–pierścień sieci gwiaździste są typu Ethernet, natomiast pierścień jest światłowodowy. Taki projekt zwiększa szybkości przesyłania danych pomiędzy sieciami gwiaździstymi.
Przy realizacji sieci Ethernet stosuje się następujące rodzaje okablowania:
• Kabel koncentryczny (współosiowy) jest bardzo powszechnie stosowanym typem kabla sie- ciowego, przede wszystkim dlatego, ze jest tani, lekki, elastyczny i łatwy w eksploatacji.
Kabel koncentryczny zawiera dwa przewody o wspólnej osi. Przewód centralny (drut lub linka miedziana) otoczony jest przez przewodnik zewnętrzny (ekran), służący jako uziemie- nie i ochrona przewodu centralnego przed zakłóceniami elektromagnetycznymi. Warstwa izolacji pomiędzy przewodami wewnętrznym i zewnętrznym utrzymuje stałą odległość jed- nego od drugiego. Ostatni element – zewnętrzna koszulka z tworzywa sztucznego – izoluje kabel od otoczenia zewnętrznego. Kable koncentryczne umożliwiają uzyskanie prędkości transmisji od 10 Mb/s do 100 Mb/s. Stosowane są dwa najpopularniejsze typy kabla kon- centrycznego: gruby i cienki.
– Cienki kabel koncentryczny (ThinNet lub Thin Ethernet) jest elastycznym kablem o średnicy około 6 mm. Może służyć do przesyłania sygnałów na odległość około 185 metrów bez znaczącej utraty mocy.
– Gruby kabel koncentryczny (ThickNet lub Standard Ethernet) jest sztywnym kablem o średnicy ok. 12 mm. Kabel ten pozwala na przesyłanie danych na duże odległości (około 500 metrów), lecz jest droższy od cienkiego.
• Skrętka – składa się z pary izolowanych skręconych ze sobą przewodów miedzianych. Ist- nieją dwa typy skrętki:
– Skrętka nieekranowana (UTP – Unshielded Twisted Pair) – kabel UTP zawiera pa- ry przewodów miedzianych, z których każda jest skręcona razem, w celu redukcji zakłóceń elektromagnetycznych.
– Skrętka ekranowana (STP – Shielded Twisted Pair) – kable STP posiadają metalowy ekran otaczający skręcone pary przewodów. Ekran dodatkowo chroni przed zewnętrz- nymi zakłóceniami elektromagnetycznymi.
• Światłowody – kable tego typu przesyłają dane za pomocą impulsów światła (poprzecznych fal elektromagnetycznych) zamiast sygnałów elektrycznych, w związku z czym dane trzeba przetworzyć na impulsy świetlne. Do konwersji służą źródła światła, emitujące impulsy świetlne po przepuszczeniu przez nie prądu elektrycznego. Źródłem światła może być dioda świecąca LED lub dioda laserowa. Impuls świetlny reprezentuje bit 1, a jego brak – 0.
Detektor na drugim końcu światłowodu (fotodioda) odbiera sygnały świetlne i przekształca je z powrotem na sygnały elektryczne.
Ramka Ethernet to po prostu ciąg bitów przesyłany poprzez warstwę łącza danych. Do pól ramki Ethernet (według standardu IEEE 802.3) należą:
• Preambuła – niezależnie od używanego typu ramki, sygnały we wszystkich sieciach Ether- net są kodowane w taki sam sposób – za pomocą kodu Manchester. Skuteczność tej metody wymaga spełnienia dwóch warunków:
– synchronizacji wewnętrznych zegarów wszystkich komputerów w sieci Ethernet – wstępnego ustalenia czasu trwania przesyłania każdego bitu podczas transmisji
Oba te warunki mogą być spełniane dzięki zastosowaniu preambuły, czyli sekwencji je- dynek i zer poprzedzającej faktyczną ramkę Ethernet. Ciąg wstępny składa się z ośmiu bajtów, zawierających na przemian zera i jedynki, zaś kończy się dwiema jedynkami. Gdy komputer w sieci Ethernet emituje ramkę, pozostałe komputery używają ciągu wstępnego do synchronizacji z wewnętrznym zegarem nadawcy. Zważywszy na niezerowy czas trwa- nia synchronizacji, pierwsze bity ciągu wstępnego są w praktyce tracone. Po osiągnięciu synchronizacji między nadawcą i odbiorcą, odbiorca czeka na sekwencję ”11”, która ozna- cza, iż następujące po niej bity będą stanowiły właściwą ramkę Ethernet. Ponieważ ciąg wstępny służy jedynie do synchronizacji komputerów, jego bity nie są wprowadzane do bufora w pamięci karty sieciowej.
• Adres docelowy – pierwsze sześć oktetów bitów ramki, o numerach od 0 do 5, składa się na adres węzła (komputera) docelowego. Niezależnie od typu ramki Ethernet, format adresu docelowego pozostaje taki sam we wszystkich implementacjach. Gdy wszystkie bity adresu docelowego mają wartość 1, wówczas komunikat jest typu rozgłoszeniowego i zostaje odebrany przez wszystkie węzły w segmencie.
• Adres źródłowy – następne sześć bajtów ramki, o numerach od 6 do 11, określa adres węzła nadawcy. Podobnie jak dla adresu docelowego, format adresu źródłowego pozostaje taki sam we wszystkich implementacjach Ethernetu.
• Długość – następne dwa bajty o numerach 12 i 13 określają długość ramki danych, z pominięciem ciągu wstępnego, 32–bitowej wartości CRC, adresu DLC i omawianego wła- śnie pola opisującego długość. Minimalna długość ramki Ethernet wynosi 64 bajty, zaś maksymalna - 1518 bajtów.
• Punkt dostępu do usługi docelowej (DSAP – Destination Service Access Point) – następny bajt, o numerze 15, wskazuje adres bufora pamięci, w którym wezeł odbiorcy powinien składować odebrane dane. Pole to gra ważną rolę w węzłach posiadających wiele stosów protokołów.
• Punkt dostępu do usługi źródłowej (SSAP – Source Service Access Point) – następny bajt, o numerze 16, wskazuje adres procesu wysyłającego ramkę.
• Bajt kontrolny – następny bajt, o numerze 17, podaje typ ramki LLC.
• Dane – od 43 do 1497 bajtów to dane użytkownika. Długość tego pola jest zmienna.
• Ciąg kontrolny ramki (FCS – Frame Check Sequence) – ostatnie cztery bajty, czyli bajty cyklicznej kontroli nadmiarowej (CRC – Cyclic Redundancy Check). Gdy odbiorca otrzy- muje pakiet, wówczas oblicza jego sumę kontrolną za pomocą złożonego wielomianu, a następnie porównuje otrzymany wynik z czterema ostatnimi bajtami ramki. Jeśli sumy kontrole nie zgadzają się ze sobą, ramka zostaje uznana za uszkodzoną i odrzucona. Za- pewnia to wykrywanie błędów transmisji i zachowanie poprawności odebranych ramek.
Adresy MAC: budowa, unikalność, adres rozgłoszeni owy MAC
Adres MAC (Media Access Control) – to unikalny identyfikator, dołączony do prawie każ- dego urządzenia mającego związek z siecią. Adres MAC jest 48–bitowy i zapisywany jest heksa- decymalnie, w postaci par cyfr rozdzielonych dwukropkami bądź myślnikami. Pierwsze 24 bity oznaczają producenta karty sieciowej, zaś pozostałe 24 bity są unikalnym identyfikatorem da- nego egzemplarza karty. Na przykład adres MAC 90:4c:e5:6e:2d:a7 oznacza, że karta została wyprodukowana przez Broadcom Corporation i producent nadał jej numer 6e:2d:a7. Trywialne jest stwierdzenie, że 48 bitów adresu MAC stanowi 6 bajtów - często rozmiar adresu MAC po- daje się właśnie w bajtach. Pierwsze 3 bajty oznaczają producenta, pozostałe 3 bajty oznaczają unikalny egzemplarz karty. Nowoczesne karty Ethernetowe pozwalają na zmianę nadanego im adresu MAC.
Adres mający wszystkie bity ustawione na jeden (szesnastkowo ff:ff:ff:ff:ff:ff) – to tak zwa- ny adres rozgłoszeniowy - oznaczający, że ramka jest przeznaczona dla wszystkich odbiorników w danym fragmencie sieci. Natomiast adres mający wszystkie bity wyzerowane (szesnastkowo 00:00:00:00:00:00) – informujący, że ramka nie zawiera danych, lecz jest jedynie ramką organi- zacyjną protokołu warstwy łącza.
Działanie urządzeń sieciowych: koncentratora (hub), przełącznika (switch), mostu (bridge), rutera, przełącznika warstwy trzeciej
Hub, czyli koncentrator – posiada wiele gniazd sieciowych. W podstawowej wersji urządzenie to jest wyposażone w niewielkie diody LED sygnalizujące status połączenia, oraz zestaw gniazd typu RJ45 – najczęściej 8, w tym dwa opcjonalne gniazda skrosowane zwane inaczej ”cross over”
lub ”UPLINK”. Należy pamiętać że gniazda te nie mogą być wykorzystywane jednocześnie z pozostałymi sześcioma gniazdami. Jednoczesne ich użycie może nawet spowodować zniszcze- nie urządzenia. Można zatem użyć jednego gniazda UPLINK na HUB. Troszkę kosztowniejsze rozwiązania sieciowe takich firm jak D–Link, 3Com bądź Intel posiadają w wyposażeniu standar- dowym również gniazda zezwalające na połączenie za pośrednictwem przewodów AUI, Optical, oraz BNC. Liczba gniazd RJ45 w jakie jest wyposażony HUB jest potęgą liczby 2 o wykładniku naturalnym i maksymalna ich liczba w standardowych i znormalizowanych urządzeniach tej klasy wynosi 64. Huby wykorzystują również technologię wykrywania chwilowego obciążenia połączeń oraz wykrywania pakietów kolizyjnych, jak i stabilności połączenia chwilowego. Sygnalizowane jest to odpowiednimi diodami umieszczonymi w obudowie huba i mrugającymi według odgórnie spreparowanego kodu, z którego wynika częstotliwość zdarzeń sieciowych oraz ich rozmiar. O tych warunkach dyktuje norma połączeń sieciowych sieci Fast Ethernet IEEE 802.1
Switch (przelącznik) to, jak nazwa wskazuje, urządzenie przełączające ruch sieciowy między łączami. Jego budowa niewiele się różni od budowy huba. Jedyną różnicą jest to, iż switch potrafi kierować pakiety do konkretnych odbiorców, charakteryzujących się konkretnymi i ustalonymi adresami IP. Posiada również możliwość ustalania połączenia sieciowego 10 bądź 100 Mb/s w obrębie jednej sieci. Oznacza to, że jeżeli następuje połączenie między dwiema kartami sieciowe 100 Mb/s, to uzyskane zostanie połączenie o wysokiej przepustowości. Jeżeli natomiast przy- najmniej jedna z kart ma słabsze możliwości techniczne, parametry połączenia zostają do niej dostosowane. Różnica pomiędzy switchem a hubem w zasadzie polega na kierunkowaniu pakie- tów i rozpoznawaniu IP.
W celu ustalenia fizycznego adresata, omawiane urządzenia używają docelowego adresu MAC, zawartego w nagłówku ramki Ethernet. Jeśli switch nie wie, do którego portu powi- nien wysłać konkretną ramkę, następuje zalanie (flooding) - dane zostają wysłane na wszystkie porty za wyjątkiem tego jednego, z którego ramka została otrzymana. Switche utrzymują tablicę mapowań adres MAC¡–¿port fizyczny, której maksymalna pojemność jest zwykle określona na 4096, 8192 lub 16384 wpisów. Po przepełnieniu tej tablicy, nowe wpisy nie są już dodawane (chyba, że któryś stary wygaśnie), a ramki ”zalewane” są do wszystkich portów (za wyjątkiem portu, poprzez który ramka dotarła do switcha).
Switche ograniczają domenę kolizyjną do pojedynczego portu, dzięki czemu są w stanie zapewnić każdemu hostowi podłączonemu do portu osobny kanał transmisyjno–nadawczy, a nie współdzielony, tak jak huby.
Na switchach zarządzalnych można również wydzielać sieci VLAN, czyli wirtualne podsieci LAN. Porty należące do różnych podsieci VLAN nie ingerują ze siebie nawzajem – do wymiany informacji pomiędzy różnymi sieciami VLAN używa się routerów. Porty do VLAN przypisywane są statycznie lub na podstawie adresu MAC podłączonej stacji (opisuje to protokół GVRP, Generic VLAN Registration Protocol, dostępny na większych switchach). Sieci VLAN pomiędzy dwoma podłączonymi do siebie switchami przenosi specjalny rodzaj połączenia – określany jako trunk. W standardzie IEEE 802.1Q każda ramka wysyłana przez trunk opatrzona zostaje 4–
bajtowym polem, w ramach którego przenoszony jest dodatkowo identyfikator konkretnej sieci VLAN (tak, by odbierający ramki przełącznik był w stanie wysłać ramkę do odpowiedniego VLANu). W związku z tym ramki tzw. tagowane, czyli oznaczane, mogą mieć maksymalnie długość do 1522 bajtów.
Obecnie na rynku obecne są również switche routujące (tzw. przełączniki 3 warstwy modelu OSI).
Przekazywanie ramek przez switcha może się odbywać w różnych trybach. W przełącznikach zarządzalnych istnieje możliwość wyboru odpowiedniego trybu. Dostępne tryby to:
• Cut–through – tryb ten wprowadza najmniejsze opóźnienie, jednakże brak w nim spraw- dzania poprawności ramek.
• Store and forward – wprowadza największe opóźnienie, gdyż sprawdza sumy kontrolne (CRC) ramek.
• Fragment free – rozwiązanie pośrednie sprawdzające tylko poprawność nagłówka ramki.
• Przełączanie adaptacyjne – na podstawie ruchu wybierany jest jeden z powyższych trybów.
Protokół CSMA/CD, domeny kolizyjne i domeny rozgłoszeniowe, tryby half- duplex i full-duplex
Halfduplex można najkrócej wyjaśnić w ten sposób, że w jednym momencie stacja może albo tylko nadawać albo tylko odbierać. W przypadku jak poniżej:
Komputer1———Hub———Komputer2
Jeżeli Komputer1 wyśle pakiet informacji do Komputera2 i w tym samym czasie Kompu- ter2 spróbuje wysłać pakiet – nastąpi kolizja (jest to często spotykane zjawisko w środowisku hubów) i Komputer2 przestanie nadawać. Na tym polega half–duplex – nie jest możliwe jedno- czesne odbieranie i nadawanie informacji. Full–duplex oznacza brak tego ograniczenia, możliwa jest jednoczesna transmisja i odbiór danych. Tryb ten występuje w sieci zawierającej switche zamiast hubów.
Protokół CSMA/CD służy temu, aby nakazać urządzeniom sieciowym nasłuch nośników transmisji przed nadaniem sygnału, co pomaga urządzeniom wykrywać kolizje. Gdy kolizja zo- stanie wykryta, wszystkie urządzenia w sieci powstrzymują się od nadawania danych przez pe- wien określony czas. Po jego upłynięciu urządzenia zaczynają rywalizować o nośnik.
Segmenty kolizyjne bądź domeny kolizyjne (Collision Domain) – to takie segmenty sieci, w których może dojść do kolizji pomiędzy stacjami przyłączonymi do tegoż segmentu podczas transmisji danych. Kolizja to próba jednoczesnego nadawania przez wiele urządzeń. Wzrost liczby kolizji powoduje spadek wydajności pracy sieci. Segmentacja sieci polega na podzieleniu dużej domeny kolizyjnej na kilka mniejszych. Podział taki dokonywany jest za pomocą mostów lub przełączników.
Jako przykład, rozważmy sytuację w której hub zostanie podłączony do jednego portu swit- cha, zaś do huba wpiętych zostanie kilka komputerów. W tym przypadku port nadal reprezentuje domenę kolizyjną – występują w niej kolizje pomiędzy komputerami wpiętymi do huba i jednym portem switcha, do którego wpięty jest hub.
Zapytania ARP, wykrywanie zdublowanych adresów IP
ARP (Adress Resolution Protocol), to protokół rozwiązywania (zamiany) adresów siecio- wych. Brak informacji na temat fizycznego adresu komputera docelowego uniemożliwia wysy- łanie do niego datagramów. Musi zatem istnieć metoda zamiany adresów IP, dostarczonych
przez aplikację, na adresy fizyczne sprzętu łączącego komputery z siecią (przekazanie danych do warstwy niższej).
Metoda trywialna polega na utworzeniu na każdym komputerze tabeli konwersji. Aplikacja wysyłająca badałaby następnie znajdującą się na bieżącym urządzeniu tabelę pod kątem okre- ślonych adresów fizycznych. Z metodą tą wiąże się wiele problemów, więc prawie w ogóle nie jest stosowana. Główna jej wada to ciągła konieczność uaktualniania tabel w przypadku zmian.
Cały impas rozwiązywany jest dzięki protokołowi ARP. Jego zadaniem jest konwersja adre- sów IP na adresy fizyczne (sieciowe i lokalne), w sposób eliminujący wymóg znajomości adresów fizycznych przez same aplikacje. W uproszczeniu, protokół ARP jest tabelą konwersji adresów IP na odpowiadające im adresy MAC. Tabela ta nosi nazwę tabeli ARP. Jej zawartość jest generowana automatycznie, ale w trakcie analizowania problemów z siecią można wprowadzać wpisy statyczne.
W tabeli ARP pojedynczy wiersz reprezentuje jedno buforowane urządzenie. Protokół ARP przechowuje w pamięci także bufor pozycji (ARP cache). Podczas szukania adresu zwykle naj- pierw sprawdzany jest bufor, a dopiero potem tabela. Wpisy generowane dynamicznie ulegają wymazaniu po upływie czasu zapisanego w konfiguracji bufora. Wpisy statyczne nie są ograni- czone limitem czasu.
Każdy wiersz bufora ARP odpowiada jednemu urządzeniu i zawiera na jego temat następu- jące informacje:
• INDEKS IF – port fizyczny (przyłącze)
• ADRES FIZYCZNY – adres fizyczny urządzenia
• ADRES IP – adres IP odpowiadający adresowi fizycznemu
• TYP – typ pozycji Typ może mieć jedną z czterech wartości:
– 1 żadne z poniższych – 2 pozycja niepoprawna
– 3 odwzorowanie dynamiczne (może ulec zmianie) – 4 odwzorowanie statyczne (nie może ulec zmianie)
Po otrzymaniu adresu IP, protokół ARP szuka dopasowania w buforze i tabeli. Jeśli zostanie ono znalezione, adres fizyczny zwracany jest obiektowi dostarczającemu adres IP. Jeśli poszuki- wanie się nie powiedzie, do sieci rozgłaszany jest komunikat. Komunikat ten nosi nazwę żądania (zapytania) ARP.
Żądanie jest komunikatem rozgłaszania, odbieranym przez wszystkie urządzenia sieci lokal- nej.
Zapytanie ARP zawiera adres IP zamierzonego urządzenia odbierającego. Urządzenie, które rozpozna adres jako swój, wysyła do komputera żądającego odpowiedź, zawierającą swój adres fizyczny. Komputer umieszcza otrzymane informacje w tabeli i buforze ARP, w celu późniejszego korzystania z nich. W ten sposób protokół ARP określa adres fizyczny dowolnego komputera na podstawie adresu IP.
Pakiet służący do komunikacji w protokole ARP ma następującą postać:
Typ sprzętu ( 16 bitów ) Typ protokołu ( 16 bitów )
Długość Długość adresu adresu sprzętowego protokołu
Kod operacji ( 16 bitów ) Adres sprzętowy nadawcy Adres protokołowy nadawcy
Adres sprzętowy odbiorcy Adres protokołowy odbiorcy Gdzie odpowiednie pola mają następujące znaczenia:
1. Typ sprzętu (Hardware Type) – określa typ interfejsu sprzętowego. Dopuszczalne są war- tości z zakresu 1 – 21.
2. Typ protokołu (Protocol Type) – określa typ protokołu wykorzystywanego przez urządze- nie wysyłające. Dla TCP/IP są to zwykle protokoły EtherType.
3. Długość adresu sprzętowego (Hardware Address Length) – Długość adresów sprzętowych w datagramie, wyrażona w bajtach. Dla sieci Ethernet wynosi 4.
4. Długość adresu protokołowego (Protocol Address Length) – Długość adresu protokołu warstwy wyższej w datagramie, wyrażona w bajtach. Dla protokołu IP wynosi 4.
5. Kod operacji (Opcode) – Wskazuje na to, czy datagram jest żądaniem (wartość 1), czy odpowiedzią ARP (wartość 2).
6. Adres sprzętowy nadawcy (Sender Hardware Address) – Adres sprzętowy urządzenia wy- syłającego.
7. Adres protokoły nadawcy (Sender Protocol Address) – Adres IP urządzenia wysyłającego.
8. Adres sprzętowy odbiorcy (Recipient Hardware Address) – Adres sprzętowy urządzenia odbierającego.
9. Adres protokołowy odbiorcy (Recipient Protocol Address) – Adres IP urządzenia odbie- rającego.
Istotnym problemem jest wykrywanie ewentualnych zdublowanych adresów IP. Przypisania adresów IP w sieci muszą być jednoznaczne, jednak w procesie przypisywania adresów IP zawsze istnieje możliwość ich powielenia. Skutkiem zakłócenia pracy stacji sieciowych.
Przeanalizujmy jak może przebiegać konflikt IP klientów TCP/IP. Rozważmy następującą sytuację: niech dwa klienty TCP/IP: stacja1 oraz stacja2, komunikują się z serwerem TCP/IP o adresie 133.7.42.11, podczas gdy adres sprzętowy serwera to 08:00:20:02:15:45. Niech obie stacje klienckie korzystają z tego samego adresu IP, 133.7.42.1. Ich adresy sprzętowe to 00:00:C0:08:51:21 (stacja 1) i 00:00:C0:08:51:22 (stacja 2).
Niech stacja 1 rozpocznie sesję FTP z serwerem TCP/IP. Wcześniej jeszcze generowane jest żądanie rozgłoszeniowe ARP, mające na celu doprowadzić do rozpoznania adresu sprzętowego serwera. Po odebraniu żądania serwer oddaje wpis stacji 1 do własnej tabeli ARP i wysyła odpowiedź ARP. Po otrzymaniu odpowiedzi stacja 1 dodaje do lokalnej tabeli ARP wpis serwera.
Zawartość buforów ARP jest wówczas następująca:
Serwer TCP/IP
Adres IP Adres sprzętowy
133.7.42.1 00:00:C0:08:51:21
Stacja 1
Adres IP Adres sprzętowy
133.7.42.11 08:00:20:02:15:45
Kolejnym krokiem jest dokonana przez stację 2. próba ustanowienia sesji TCP/IP (np.:
kolejnej sesji FTP ) z tym samym serwerem.
Przed utworzeniem połączenia stacja 2. musi rozpoznać adres sprzętowy serwera. Wysyła więc żądanie ARP. Po odebraniu tego żądania serwer ma dodać wpis stacji 2. do tabeli ARP i odesłać odpowiedź nadawcy. W trakcie pierwszej z tych czynności zostaje odnaleziony wpis wcześniejszy, dotyczący adresu 133.7.42.1. Jak nakazuje dokument RFC 826, serwer musi za- stąpić starszy wpis danymi odczytanymi z odebranego komunikatu. Większość implementacji TCP/IP wykonuje to automatycznie, nie generując, żadnych ostrzeżeń (nie jest to reguła, lecz po prostu oczekiwane zachowanie). Drugą czynnością jest przesłanie odpowiedzi na żądanie sta- cji 2. Po odebraniu odpowiedzi stacja 2. dodaje wpis serwera do własnej tabeli ARP. Wówczas tabele ARP serwera i stacji 2 zawierają dane:
Serwer TCP/IP
Adres IP Adres sprzętowy
133.7.42.1 00:00:C0:08:51:22
Stacja 2
Adres IP Adres sprzętowy
133.7.42.11 08:00:20:02:15:45
Kiedy następnie serwer ma wysłać dane do stacji 1., wyszukuje w tabeli ARP jej adres sprzętowy, skojarzony z wpisem adresu IP 133.7.42.1. Serwer pobiera adres sprzętowy z tabeli i rozpoczyna transmisję. Niestety, adres sprzętowy jest teraz adresem stacji 2 i do niej kierowane są dane z serwera. Z powodu braku oczekiwanych odpowiedzi serwera stacja 1 ponawia pró- by transmisji. Serwer natomiast w dalszym ciągu wysyła odpowiedź do stacji 2. Sytuacja taka utrzymuje się do czasu przekroczenia pewnego limitu czasowego stacji 1., lub przerwania połą- czenia przez użytkownika (lub restartowania oprogramowania klienta). Spowoduje to przerwanie prób ponawiania transmisji, ale bynajmniej nie przywróci możliwości komunikacji z serwerem.
Stacja 2. po otrzymaniu nieoczekiwanych danych, przeznaczonych dla stacji 1., prawdopo- dobnie będzie je ignorować. Może również wyświetlić komunikat o błędzie. Można też oczekiwać, że będzie kontynuować rozpoczętą sesję komunikacyjną. Nieoczekiwane dane mogą jednak nie- kiedy prowadzić zawieszenie systemu.
Jeżeli użytkownik stacji 1. ponownie uruchomi komputer i spróbuje nawiązać połączenie z serwerem, wpis ARP stacji 2, zostanie zastąpiony wpisem stacji 1. Wówczas sytuacja ulegnie odwróceniu. Stacja 2. utraci możliwość komunikacji z serwerem aż do ponownego uruchomienia.
Przeanalizujmy z kolei do czego może doprowadzić konflikt IP serwerów TCP/IP. Rozważ- my następującą sytuację: do serwera 1. i serwera 2. został przypisany identyczny adres IP:
133.7.42.11. Adresy sprzętowe obu serwerów to odpowiednio, 08:00:20:02:15:45 oraz 08:00:20:02:15:46.
Stacja o adresie IP 133.7.42.1 podejmuje próbę połączenia z serwerem o adresie 133.7.42.11.
Adres sprzętowy stacji to 00:00:C0:08:51:21.
Zamierzeniem użytkownika stacji jest nawiązanie łączności z serwerem 1. Przed rozpoczęciem właściwej komunikacji TCP/IP, stacja wysyła rozgłoszeniowe żądanie ARP, dążąc do uzyskania adresu sprzętowego serwera. Adres docelowy rozgłoszenia został przypisany dwóm serwerom. Po
odebraniu żądania każdy z nich dołącza wpis stacji do lokalnej tabeli ARP i wysyła odpowiedź.
Stacja odbiera pierwszą z nich, całkowicie ignorując drugą. Jeżeli komunikat ARP serwera 2.
dotrze do stacji jako pierwszy, wpis tego właśnie serwera znajdzie się w jej tabeli ARP.
Stacja nawiązuje więc łączność z serwerem 2. w miejsce oczekiwanego serwera 1. Jeżeli na serwerze 2. nie została uruchomiona wskazana przez klienta usługa, połączenie nie dojdzie do skutku, a użytkownik otrzyma komunikat o tym, że serwer nie obsługuje wymaganego protokołu aplikacji.
Jeżeli natomiast na serwerze 2. dostępna jest wywoływana przez stację usługa, kolejnym krokiem może być logowanie. Jeżeli usługą jest telnet bądź FTP, wymagane jest wówczas po- danie nazwy użytkownika i hasła. Możliwa jest wtedy odmowa dostępu z powodu, że serwer nie dysponuje kontem danego użytkownika.
Jeżeli serwer jest stacją o wielu przyłączach sieciowych, która pracuje jako router, mogą poja- wić się jeszcze trudniejsze do rozpoznania komplikacje – pakiety kierowane do sieci zewnętrznych mogą zostać niedostarczone lub skierowane inną od oczekiwanej trasą. Przyczyną jest oczywiście przekazywanie pakietów do niewłaściwego routera.
Jak zatem rozwiązywany jest problem wykrywania zdublowanych adresów IP? Wiele im- plementacji TCP/IP rozsyła żądania ARP przy uruchamianiu, umieszczając w polu docelowego adresu IP adres własny. Celem takiej inicjalizacji jest rozpoznanie węzłów o identycznym adresie IP. Jeżeli po wysłaniu żądania zostanie odebrana odpowiedź ARP, oznacza to, że inny węzeł w sieci (ten, który odpowiedział) ma ten sam adres IP, co stacja uruchamiana. W takim wypadku stacja informuje użytkownika o zdublowaniu adresu IP w sieci. Węzeł odpowiadający na żądanie, może sprawdzić czy adres w polu IP to taki jak jego własny, a jeżeli tak jest - powiadamia o tym problemie administratora. Przy wyszukiwaniu zdublowanego adresu można posiłkować się także poleceniem arp, pozwalającym na wyświetlenie wpisów tabeli ARP. Za pomocą polecenia
‘arp –a‘ wyświetlamy bieżącą tabele ARP i na podstawie listy właściwych adresów (zwłaszcza adresów Ethernet) szukamy będącej źródłem problemu stacji.
Automatyczna konfiguracja adresów IP: BOOTP, DHCP
BOOTP (Bootstrap Protocol), czyli prosty protokół rozruchu wstępnego, wykorzystuje parę protokołów UDP i IP do przesłania komputerom danych konfiguracyjnych. Komputery, które generują żądania BOOTP określa się jako klienty BOOTP, a komputery przesyłające odpowiedzi - jako serwery BOOTP. Żądanie klienta BOOTP ma na celu uzyskanie wartości parametrów IP przeznaczonych dla komputera, na którym oprogramowanie klienta jest uruchomione.
Komunikat BOOTP jest kapsułkowany w datagramie UDP, określającym numer portu proce- su BOOTP. Tak utworzony datagram podlega kapsułkowaniu w pakiecie IP. Nagłówek protokołu IP zawiera jedynie adresy IP źródłowy i docelowy. Generując zapytanie klient nie zna swojego adresu IP. Adresem używanym w takich sytuacjach jest 0.0.0.0. Jeżeli klient BOOTP ma już przypisany adres IP, jest on oczywiście stosowany. Klient BOOTP nie posiada zazwyczaj in- formacji na temat adresu serwera, jeżeli jednak stacja ma możliwość przechowywania takiego adresu, klient BOOTP przewiduje także taką możliwość. W przypadku braku adresu serwera stosowany jest lokalny adres rozgłoszania. Ma on uniwersalną wartość: 255.255.255.255. Pakiety opisane za pomocą lokalnego adresu rozgłoszaniowego odbierane są przez wszystkie stacje w sieci lokalnej. Po rozpoznaniu zawartości, wszystkie stacje poza serwerami BOOTP odrzucają pakiet.
Gdy serwer BOOTP pracuje w innej podsieci, oddzielonej routerem, rozgłoszenie lokalne nie zostanie przekazane przez router. W takich przypadkach w systemie routera musi znaleźć się agent przekazywania BOOTP. Rozpoznaje on, określony w nagłówku UDP rozgłoszenia lokalne- go numer portu docelowego BOOTP – 67. Jest to port zarezerwowany dla protokołów BOOTP i
DHCP. Agent przekazywania zapewnia przesyłanie rozgłoszenia lokalnego pomiędzy przyłączami routera.
Serwer BOOTP w sieci lokalnej udziela odpowiedzi bezpośrednio klientowi. To, czy serwer może skorzystać z adresu IP i wysłać odpowiedź skierowaną, zależy wyłącznie od implementacji wykorzystywanej po stronie serwera.
Wysłanie do klienta komunikatu skierowanego jest pewnym problemem, gdyż serwer wyszu- kuje jego adres IP we własnej bazie danych BOOTP. Żądanie ARP, mające prowadzić do roz- poznania sprzętowego adresu klienta, pozostanie przecież wówczas bez odpowiedzi. Sam klient także nie zna swojego adresu IP. Jednak serwer BOOTP dysponuje adresem sprzętowym klienta, przesłanym doń w nagłówku warstwy łącza sieciowego komunikatu żądania BOOTP. Oprogra- mowanie serwera może na tej podstawie utworzyć wpis w tabeli ARP. Jeżeli taki mechanizm jest używany, to odpowiedź serwera może mieć charakter komunikatu skierowanego. Jeżeli natomiast serwer nie modyfikuje tabeli ARP, wysyła odpowiedź jako rozgłoszenie.
Rozważmy do czego mogą doprowadzić zakłócenia przy protokole BOOTP. Protokół BOOTP opiera swoje działanie na protokołach UDP i IP. Nie gwarantują one dostarczania komunikatów.
Mogą więc zostać nie dostarczone, opóźnione, powielone lub dostarczone w zmienionej kolej- ności. Ponieważ mechanizm IP zapewnia wyłącznie mechanizm sum kontrolnych, umożliwiony jest nadzór nad poprawnością transmisji nagłówka IP, ale nie samych danych. Oprogramowanie BOOTP może zatem wymagać korzystania z sum kontrolnych UDP. Rozwiązują one problem kontroli poprawności całego komunikatu.
Żądania wysyłane przez klienta BOOTP mają ustawiony znacznik DF (zakaz fragmentacji).
Upraszcza to przetwarzanie odpowiedzi, zwłaszcza gdy klient nie dysponuje pamięcią wystar- czającą do ponownego złożenia podzielonych datagramów. W protokole BOOTP stosowana jest metoda limitów czasowych retransmisji. Klient wysyłający żądanie rozpoczyna zliczanie cza- su oczekiwania. Odebranie odpowiedzi kończy procedurę, ale w przypadku gdy określony limit czasowy zostanie przekroczony, żądanie BOOTP jest wysyłane ponownie.
Większa liczba jednocześnie uruchamianych klientów może doprowadzić do zdławienia ko- munikacji sieciowej wskutek tzw. powodzi rozgłoszeń BOOTP. Aby później uniknąć takiego zjawiska, specyfikacja BOOTP zaleca wprowadzenie losowych opóźnień retransmisji w zakresie do czterech sekund.
Każda kolejna retransmisja podwaja czas oczekiwania. Wartość graniczna rosnącego opóź- nienia jest zazwyczaj znacznie większa, rzędu 60 sekund. Po osiągnięciu tej wartości limit czasu oczekiwania przestaje być podwajany, w dalszym ciągu jednak jest stosowane losowe opóźnie- nie, nie większe niż wartość graniczna. Ma to na celu uniknięcie kierowania do sieci zbyt wielu jednoczesnych żądań BOOTP, które mogą doprowadzić do przeciążenia serwera i powodować kolizje pakietów w sieci Ethernet.
Podwajanie losowo dobieranego czasu oczekiwania ma zapewnić uniknięcie przekroczenia przepustowości sieci w sytuacjach, gdy z rozgłoszeniowej komunikacji protokołu BOOTP korzy- sta jednocześnie wielu klientów.
Podobnie jak BOOTP, protokół DHCP przydziela pełne dane konfiguracyjne do uruchamia- nego urządzenia sieciowego. Jest jednak znacznie przydatniejszy od BOOTP, ponieważ dodat- kowo pozwala urządzeniom automatycznie pobierać adresy IP. W rezultacie klient DHCP może być przenoszony bez konieczności ręcznej zmiany konfiguracji. Ta zdolność do automatycznej rekonfiguracji ma znaczenie zwłaszcza w przypadku tymczasowych przenosin, gdy host przeno- szony jest do innej lokalizacji na bardzo krótki czas (na przykład, na kilka godzin lub dzień).
Oprócz dynamicznego przydzielania adresu IP, DHCP posiada wbudowane mechanizmy służące do zarządzania lokalnymi klientami w sieci, rejestracji ruchu sieciowego, oraz podstawowe zabez-
pieczenia. Równie ważna jest łatwość instalacji, konfiguracji i utrzymywania DHCP. Dzięki tym wszystkim zaletom zadanie zarządzania siecią TCP/IP z pomocą DHCP staje się stosunkowo łatwe.
Protokół DHCP nie tylko rozwiązuje problem dynamicznego przydzielania adresów IP klien- tom w sieci TCP/IP, lecz również pozwala zredukować problem szybko kurczącej się puli uni- katowych adresów IP. W statycznym środowisku sieciowym administrator nadaje unikatowe adresy IP kolejno wszystkim urządzeniom w sieci. Nawet jeśli urządzenie używane jest rzadko (lub tymczasowo), żadne inne urządzenie nie może korzystać z jego adresu IP, choćby był bar- dzo potrzebny. Dzięki zastosowaniu protokołu DHCP, który dynamicznie przydziela adresy IP, adresy te są przyznawane tylko w miarę potrzeby i zwalniane, gdy nie są potrzebne, co pozwala oszczędzić cenna przestrzeń adresów IP.
Serwer DHCP utrzymuje pulę poprawnych adresów IP, które może przydzielać klientom.
Pula adresów IP nosi nazwę zakresu (scope). Klient w trakcie uruchamiania rozgłasza zadanie adresu IP. Wszystkie serwery DHCP, które otrzymają zadanie, zwracają w odpowiedzi adres IP i związane z nim dane konfiguracyjne, dzięki czemu klient może otrzymać wiele odpowiedzi na zadanie. Następnie klient wybiera do swojego użytku odpowiedni adres IP i dzierżawi go od ser- wera DHCP. Dzierżawa (lease) określa czas, przez który serwer DHCP pozwala klientowi używać określonego adresu IP. Po potwierdzeniu dzierżawy klient staje się częścią funkcjonującej sieci.
Gdy ustalony czas upłynie, dzierżawa jest unieważniana przez serwer DHCP. W dynamicznym środowisku sieciowym dzierżawy są ważne, ponieważ zapobiegają zagarnianiu przez klienty adre- sów na długi czas. Po wygaśnięciu dzierżawy adres IP wraca do puli (zakresu) adresów serwera, z które j adresy mogą być dzierżawione potrzebującym ich klientom. Jeśli jednak klient nadal używa adresu po upłynięciu terminu, serwer może odnowić dzierżawę i pozwolić klientowi używać tego samego adresu. W niektórych przypadkach nieużywane dzierżawy mogą być automatycz- nie zwracane do puli adresów. Czas trwania dzierżawy zależy od sieci i wymogów klientów. Na przykład, w sieci przedsiębiorstwa dzierżawa może trwać dzień lub nawet tydzień, zależnie od wykonywanych zadań. Z drugiej strony, dzierżawy w kafejkach internetowych mogą trwać za- ledwie godzinę. Z tego powodu specyfikacja DHCP nie zaleca określonego czasu dzierżawy. Jej długość zależy od administratora sieci. DHCP pozwala również na dzierżawy na czas nieokre- ślony (np. jeśli w polu Lease Duration znajduje się wartość 0xffffffff). Przyznawanie trwałych dzierżaw przypomina statyczny przydział adresów IP.
Proces dzierżawy DHCP, obejmuje następujące kroki:
1. Klient zostaje uruchomiony i rozgłasza w lokalnej podsieci tzw. komunikat odkrycia DHCP (DHCPDISCOVER). Ta faza nosi nazwę stanu inicjacji. Jeśli po drodze pomiędzy klientem i serwerem znajduje się router, komunikat rozgłoszenia może być przesyłany do innych podsieci. Do tego celu potrzebne są routery obsługujące protokół BOOTP.
2. Wszystkie serwery, które otrzymały komunikat odkrycia i mogą wydzierżawić adres IP odpowiadają wysalając komunikat oferty DHCP (DHCPOFFER). Komunikat ten zawiera adres IP i związane z nim dane konfiguracyjne.
3. Klient może otrzymać wiele ofert dzierżawy, w zależności od liczby serwerów DHCP, które odpowiedziały na komunikat odkrycia. Klient wchodzi następnie w stan wyboru, w którym przegląda komunikaty ofert i wybiera jedną z nich.
4. Klient wchodzi w stan zadania – wysyła do odpowiedniego serwera komunikat zadania (DHCPREQUEST), zadając konfiguracji zaoferowanej przez serwer.
5. Serwer wysyła komunikat pozytywnego potwierdzenia (DHCPACK) komunikatu zadania, wysłanego przez klienta. Oprócz adresu IP i danych konfiguracyjnych komunikat ten za- wiera informacje o dzierżawie.
6. Klient po otrzymaniu potwierdzenia wchodzi w stan powiązania, w którym wydzierżawiony adres IP jest związany z klientem, a klient staje się częścią sieci. W stanie powiązania klient używa trzech liczników czasu, które kontrolują wygaśniecie, odnowienie i ponowne nawiązanie dzierżawy.
7. W zależności od ustawień licznika czasu wygaśnięcia, po upływie 50% czasu dzierżawy – lub po jej wygaśnięciu – klient usiłuje odnowić dzierżawę, wysyłając komunikat DHC- PREQUEST do serwera, który adres wydzierżawił. Klient może tez usiłować zakończyć dzierżawę przed czasem, wysyłając komunikat zwolnienia (DHCPRELEASE).
8. Po wysłaniu do serwera komunikatu DHCPREQUEST, klient wchodzi w stan odnowienia i w tym stanie oczekuje na odpowiedz od serwera. Serwer może w odpowiedzi albo przy- jąć zadanie (potwierdzając przez DHCPACK), albo je odrzucić (DHCPNACK). W razie odrzucenia zadania, klient zwalnia adres i wraca do stanu inicjacji.
9. Jeśli klient nie otrzyma od serwera odpowiedzi w określonym czasie, to serwer zostaje uznany za wyłączony lub niedostępny. W tym przypadku klient po upływie 87,5% czasu dzierżawy wchodzi w stan ponowienia powiązania. W tym stanie klient zaczyna ponownie rozgłaszać komunikat DHCPREQUEST do wszystkich dostępnych serwerów DHCP.
10. Jeśli klient otrzyma choćby jedną pozytywną odpowiedź, to wraca do stanu powiązania, natomiast jeśli wszystkie serwery odpowiedzą negatywnie, klient powróci do stanu inicjacji.
0.1 Podsłuchiwanie w sieciach opartych o koncentratory, podsłuchiwanie w sieciach opartych o przełączniki
Najłatwiej jest prowadzić sniffing w sieciach standardu Ethernet (są to sieci rozgłoszeniowe używające protokołu CSMA/CD), które oparte są na fizycznej topologii magistrali lub gwiaz- dy (także topologii mieszanej, np. drzewa). W drugim przypadku do organizacji sieci muszą być jednak wykorzystane urządzenia zwane koncentratorami (huby), które działają w pierwszej warstwie (fizycznej) modelu referencyjnego OSI. Ich zadaniem jest wzmacnianie transmitowa- nego sygnału i przekazywanie go do wszystkich portów, do których mogą być podłączone inne urządzenia sieciowe (np. komputery, kolejne koncentratory). W normalnym trybie pracy karty sieciowe są w stanie odfiltrować wszystkie takie pakiety, które skierowane były do innego inter- fejsu sieciowego, sprawdzając swój adres MAC z zapisanym w pakiecie adresem MAC odbiorcy.
Możliwe jest jednak przełączenie karty sieciowej w tzw. bezładny tryb pracy (promiscuous mode – nazywany także trybem podsłuchu). Wówczas karta sieciowa przekazuje do wyższych warstw (chodzi o model referencyjny OSI) wszystkie odebrane pakiety, nawet jeżeli nie były one do niej adresowane. Z możliwości tej korzystają programy zwane snifferami, dzięki którym jesteśmy w stanie podsłuchiwać ruch sieciowy (czyli przechwytywać pakiety, które są jego elementami składowymi). Poszczególne pakiety mogą być zapisane przez sniffer do pliku, co pozwoli oso- bie korzystającej z programu na dokładniejszą analizę ruchu w dowolnym czasie. Takie działanie umożliwia zebranie wielu informacji, które mogą być przydatne w celu przeprowadzenia np. inne- go ataku lub uzyskania nieautoryzowanego dostępu do określonych zasobów. Sniffing w sieciach bez przełączników można uznać za działanie pasywne, gdyż atakujący musi jedynie programo- wo przestawić tryb pracy swojej karty sieciowej na bezładny, uruchomić sniffer i określić jakie pakiety ma on wychwytywać. Nie jest konieczna żadna interakcja z innymi urządzeniami pra- cującymi w sieci. Oczywiście warunkiem koniecznym jest, aby maszyna, na której prowadzony jest sniffing, była podpięta do dowolnego portu koncentratora. Ten po odebraniu pakietu wyśle
go na wszystkie swoje porty i w rezultacie pakiet trafi do każdego spiętego z koncentratorem urządzenia (komputera lub kolejnego koncentratora). Każda z kart sieciowych – za wyjątkiem karty prawdziwego odbiorcy oraz karty pracującej w trybie bezładnym (używanej przez w celu dokonania sniffingu) – odfiltruje pakiet po adresie MAC. W ten sposób możliwe jest podsłuchi- wanie całej komunikacji odbywającej się w sieci.
Rozważmy możliwości podsłuchiwania ruchu sieciowego w sieciach opartych o przełączniki.
Typowe przełączniki spotykane w sieciach lokalnych są urządzeniami działającymi w drugiej warstwie modelu referencyjnego OSI. Z tego względu funkcjonują one w bardziej złożony sposób niż huby. W trakcie pracy, przełączniki budują tablicę adresów MAC urządzeń przyłączonych do ich portów i zapisują ją we własnej pamięci (w postaci tablic CAM – Content Addressable Me- mory). Dzięki temu każdy przełącznik po odebraniu pakietu przesyła go nie na wszystkie porty, a jedynie do jednego z nich, do którego podpięte jest urządzenie o odpowiednim adresie MAC. To z kolei oznacza, że do karty sieciowej odbiorcy trafiają wyłącznie pakiety dla niej przeznaczone oraz pakiety rozgłoszeniowe. Wówczas przełączenie karty w tryb bezładny i uruchomienie sniffera nie przyniesie pożądanego efektu. Zjawisko to jest źródłem błędnego przekonania, że przełączniki uniemożliwiają podsłuchiwanie ruchu. Jakkolwiek ograniczają one możliwości ataku, wystarczy zastanowić się nad kilkoma szczegółami związanymi z zasadami działania przełączników, aby do- strzec potencjalne drogi obejścia tego problemu. Okazuje się, że właśnie pamięć wykorzystywana przez przełączniki do przechowywania odwzorowań portów na adresy MAC przyłączonych do nich urządzeń stanowi pierwszą drogę ataku. Po pierwsze warto pamiętać, że dopóki przełącznik nie wybuduje aktualnej tablicy odwzorowań MAC/port, rozsyła os pakiet przeznaczony dla nie- określonego odbiorcy (może to być np. nowy komputer podpięty do wolnego portu, który jeszcze nie wygenerował żadnego ruchu) – i pakiet ten jest przekazywany do wszystkich portów. Wów- czas urządzenie to działa jak typowy koncentrator. Tworzenie tablicy odwzorowań MAC/port polega na tym, że kiedy na porcie przełącznika pojawia się pakiet, ten odczytuje informację o nadawcy pakietu i zapisuje ją w pamięci, łącząc odkryty adres MAC z określonym portem.
Ten proces ma charakter dynamiczny, gdyż w przeciwnym razie nie byłoby możliwe przepinanie urządzeń na inne porty. Po drugie, pamięć przełącznika, w której przechowywana jest tablica od- wzorowań MAC/port ma ograniczony rozmiar, w związku z czym często stosowaną techniką jest dążenie do jej przepełnienia. Pojedynczy adres MAC zajmuje 6 bajtów (np. 00:11:22:33:44:55) – nie jest to dużo biorąc pod uwagę pamięć urządzenia, jednak stosując technikę MAC flooding można przesłać odpowiednią ilość fałszywych pakietów i spowodować przepełnienie tablicy. Po trzecie, większość producentów kart sieciowych pozwala na zmianę adresu MAC przypisanego danemu urządzeniu, a to daje możliwość podszycia się pod inną maszynę. Nie jest to jednak działanie konieczne, ponieważ istnieje wiele narzędzi pozwalających na manipulację pakietami ARP, a to otwiera już kilka możliwych dróg rozwiązania problemu.
Wirtualne segmenty VLAN
Pojecie wirtualnych sieci lokalnych (ang. VLAN – Virtual LAN) nie znalazło do tej pory ofi- cjalnej, uniwersalnej definicji. Interpretacji jest wiele, najczęściej zależnie od producenta sprzętu implementującego sieci wirtualne.
Wirtualna sieć lokalna to podzbiór urządzeń pracujących w sieci lokalnej. Wirtualna sieć lo- kalna zapewnia urządzeniom przynależność do wyodrębnionej domeny rozgłoszeniowej. Z punktu widzenia stacji roboczych zapewnia to im takie działanie, jakby należały do fizycznie wydzie- lonej sieci lokalnej. W sieci lokalnej może istnieć jednocześnie kilka wirtualnych sieci lokalnych.
Zakładając dla uproszczenia, że sieć lokalna tworzy jedną domenę rozgłoszeniową, następuje jej podział na poszczególne wirtualne sieci lokalne. Urządzeniem realizującym podział domeny roz- głoszeniowej na wirtualne sieci lokalne jest najczęściej przełącznik. Przynależność podłączonych
do niego urządzeń do danej wirtualnej sieci lokalnej może następować na podstawie różnych kryteriów. Przynależność stacji do sieci wirtualnej może być realizowana na podstawie:
1. Numeru portu przełącznika (jako port rozumiany jest fizyczny interfejs przełącznika). Je- żeli do portu przełącznika podłączone jest kilka urządzeń, wszystkie one należą do tej samej sieci wirtualnej.
2. Adresu MAC urządzenia. W przełączniku konfigurowana jest przez administratora tabe- la zawierająca numery sieci wirtualnych i należące do nich adresy MAC. Zgodnie z idea działania przełączników, przełącznik posiada informacje, o porcie na którym ostatnio wy- stępowała stacja o danym adresie MAC. Na wypadek odebrania przez przełącznik ramki o nieznanym adresie MAC lub adresie rozgłoszeniowym, możliwe są dwa rozwiązania:
• Można założyć, że nie może wystąpić w sieci adres MAC poza zdefiniowanymi. Wów- czas precyzyjnie określone są porty dla ramek rozgłoszeniowych, zaś ramki nieznanego przeznaczenia są gubione.
• Alternatywnie można zaakceptować możliwość wystąpienia nieznanego adresu MAC.
Wówczas rozgłoszenia oraz ramki nieznanego przeznaczenia rozsyłane są na wszystkie porty. Podział domen rozgłoszeniowych nie jest wówczas zachowany.
3. Typu protokołu warstwy trzeciej modelu OSI. Aby ramki rozgłoszeniowe danego proto- kołu nie były wysyłane do sieci, wirtualnej odpowiadającej innemu protokołowi, stacje podłączone do jednego portu przełącznika powinny wszystkie posługiwać się tym samym protokołem.
4. Znacznika dodawanego do ramki w warstwie drugiej. Dokumentem opisującym miejsce jego umieszczenia oraz zawartość jest standard IEEE 802.1Q.
Zadania praktyczne
Zbadać własny adres MAC za pomocą polecenia ipconfig oraz adres MAC bra- my domyślnej poprzez a) podsłuchanie programami windump i/lub ethereal komunikacji z bramą, b) poprzez wygenerowanie zapytania ARP programem ArpCacheWatch
Własny adres MAC badamy odpowiednim poleceniem:
root@Kardon :˜# i f c o n f i g wlan0
wlan0 Link encap : E t h e r n e t HWaddr 0 0 : 1 f : 3 b : 9 c : f 5 : 8 d
i n e t addr : 1 9 2 . 1 6 8 . 0 . 2 B c a s t : 1 9 2 . 1 6 8 . 0 . 2 5 5 Mask : 2 5 5 . 2 5 5 . 2 5 5 . 0 i n e t 6 addr : f e 8 0 : : 2 1 f : 3 b f f : f e 9 c : f 5 8 d /64 Scope : Link
Do podsłuchania użyliśmy programu Wireshark. Oglądając nagłówki ethernetowe otrzymu- jemy: Adres własny: 01:1f:3b:9c:f5:8d Adres bramy domyślnej: 00:1f:33:02:07:ba
Drugi adres potwierdzamy odpowiednim zapytaniem ARP:
root@Kardon :˜# a r p i n g −I wlan0 −f 1 9 2 . 1 6 8 . 0 . 1 ARPING 1 9 2 . 1 6 8 . 0 . 1 from 1 9 2 . 1 6 8 . 0 . 2 wlan0
U n i c a s t r e p l y from 1 9 2 . 1 6 8 . 0 . 1 [ 0 0 : 1 F : 3 3 : 0 2 : 0 7 :BA] 1 . 5 5 5 ms
S e n t 1 p r o b e s ( 1 b r o a d c a s t ( s ) ) R e c e i v e d 1 r e s p o n s e ( s )
Ustalić producenta karty sieciowej w komputerze własnym i bramie domyślnej.
Ustalenie producentów możemy wykonać ręcznie - wykorzystując odpowiednią listę (np.
http://www.digipedia.pl/mac):
Adres MAC: 0 0 : 1 F : 3B: 9C : F5 : 8D Kod p r o d u c e n t a : 0 0 : 1 F : 3B Kod produktu : 9C : F5 : 8D
O r g a n i z a c j a : I n t e l C o r p o r a t Adres MAC: 0 0 : 1 F : 3 3 : 0 2 : 0 7 :BA Kod p r o d u c e n t a : 0 0 : 1 F : 3 3 Kod produktu : 0 2 : 0 7 :BA
O r g a n i z a c j a : N e t g e a r I n c .
Za pomocą polecenia arp zbadać i wyczyścić zawartość pamięci podręcznej (cache) protokołu ARP.
g r z e s iu @ K a r d o n : ˜ / P u l p i t $ arp
A d d r e s s HWtype HWaddress F l a g s Mask
I f a c e
1 9 2 . 1 6 8 . 0 . 1 e t h e r 0 0 : 1 f : 3 3 : 0 2 : 0 7 : ba C wlan0
1 9 2 . 1 6 8 . 0 . 4 e t h e r 0 0 : 1 a : 4 d : 5 7 : d7 : 9 3 C wlan0
W wypadku systemu GNU/Linux polecenie arp pozwala usunąć maksymalnie 1 wpis z pa- mięci cache. W wypadku systemu windows polecenie arp przyjmuje wieloznacznik co pozwala na wyczyszczenie cache jednym poleceniem.
Na dwóch komputerach ustawić ten sam adres IP i ”wykryć” tę sytuację generując zapytanie ARP.
Samo ustawienie adresu ip nie będzie powodowało zbyt wielu konfliktów - większość pakietów będzie opatrzona adresem MAC prawdziwego posiadacza adresu. Aby wykryć zaistnienie takiej sytuacji musimy wysłać zapytanie ARP z pytaniem o własne IP - odpowiedź oznacza, iż ktoś już posługuje się tym adresem.
Za pomocą programu windump i/lub ethereal prześledzić proces otrzymywa- nia adresu IP poprzez DHCP przez inny komputer w czasie uruchamiania oraz proces zwalniania adresu IP poprzez DHCP przez inny komputer w czasie za- mykania.
Otrzymywanie adresu ip odbywa się dwuetapowo - najpierw klient wysyła pakiet DHCP Discover do sieci. W odpowiedzi oczekuje na pakiety DHCP Offer z możliwymi adresami IP (w wypadku ich braku ponawia próbę bądź wybiera adres samodzielnie). Następnie za pomocą zapytań ARP sprawdza czy adres na pewno jest dostępny.
Drugim etapem jest zarezerwowanie adresu za pomocą pakietu DHCP Request. W odpo- wiedzi otrzymuje pakiet DHCP Ack, zaś sam wysyła pakiety ARP informujące o swoim nowym adresie IP. Pakiet DHCP Request służy również do przedłużenia dzierżawy adresu IP.
W wypadku zwolnienia dzierżawy wysyłany jest pakiet DHCP Release - informacje o zwal- nianym adresie IP nie są jednak zawarte w tym pakiecie, zaś są ustalane na podstawie adresu MAC nadawcy tego pakietu.
Odnowić i zwolnić dzierżawę DHCP korzystając z polecenia ipconfig.
Parametrami wykorzystywanymi w tym celu są /renew i /release. Sama czynność zwykle przebiega bezproblemowo i kończy się uzyskaniem adresu ip oraz maski i bramy domyślnej.
W wypadku Linuksa należy użyć programu klienckiego dhcp - w wypadku dhcpcd parame- trami są odpowiednio -n oraz -k.
We właściwościach sterownika karty sieciowej ustawić adres MAC taki sam, jaki ma karta sieciowa innego komputera w laboratorium, po czym odnowić dzierżawę DHCP i zaobserwować skutek.
Ustawienie takiego samego adresu MAC sprawia, że 2 komputery stają się nierozróżnialne.
Tak długo jak komputery uzyskują adres ip przez DHCP konsekwencją takich samych adresów MAC będą takie same adresy IP co znacznie wpłynie na stabilność połączeń.
Zaobserwować różnicę w działaniu programów windump i ethereal w trybie z interpretacją adresu MAC oraz z ignorowaniem adresu MAC (tzw. tryb rozwiązły, ang. promiscuous mode).
Tryb promiscuous sprawia, że interfejs odbiera wszystkie pakiety - nawet takie, które nie są skierowane do naszego adresu MAC. Powoduje to obciążenie procesora - gdyż wszystkie pakiety są analizowane na poziomie oprogramowania. Widocznym efektem jest zwiększona ilość pakietów wyświetlanych przez sniffera.
Bibliografia
1. Karol Krysiak, Sieci komputerowe. Kompendium., Wydanie II, Helion 2005.
2. Peter Norton, W sercu PC, Helion 2003.
3. Różne hasła z angielskiej oraz polskiej Wikipedii.
