Sieci komputerowe to w dużym uproszczeniu nic innego jak zbiór współgrających ze sobą protokołów. To właśnie interakcje między nimi pozwalają nam na przeprowadzenie skutecznej komunikacji w obu kierunkach.
We wczesnych fazach nauki sieci poznajemy zazwyczaj modele sieciowe OSI oraz TCP/IP i dowiadujemy się, że najpowszechniejszym protokołem warstwy drugiej stosu sieciowego jest Ethernet. Ethernet z kolei opiera swoje działanie w bardzo dużym stopniu na ARP, któremu dziś przyjrzymy się nieco bliżej.
Omówienie praktyczne i teoretyczne
ARP, czyli Address Resolution Protocol to jeden z kluczowych protokołów umożliwiających nam komunikację w sieciach rozgłoszeniowych, których to koronnym przedstawicielem jest Ethernet. Technologia ta mocno wyewoluowała od momentu powstania w 1976 roku lecz podstawowe zasady nadal pozostają te same. Zaczęliśmy od łączenia naszych urządzeń kablami koncentrycznymi, zastępując je następnie hubami aż doszliśmy do stanu obecnego, w którym główny punkt przyłączeniowy do sieci stanowią przełączniki (switche). We wszystkich tych scenariuszach używany jest protokół ARP. Ba! Stosowany on jest nawet wtedy gdy połączymy dwa komputery kablem bezpośrednio ze sobą. Spójrzmy na przykład:
Upraszczamy nasz scenariusz jak tylko się da. Nie mamy tutaj do czynienia z serwerem DHCP, a adresy IP ustawione są statycznie. W obu przypadkach jako adres bramy domyślnej wpisano 192.168.1.10, ale jest to w tym przykładzie nieistotne ponieważ oba te urządzenia znajdują się w tej samej podsieci. Komunikacja za pośrednictwem bramy domyślnej nie będzie zatem wymagana. Ponadto adresy MAC zostały uproszczone w sposób, który pozwoli nam swobodniej analizować przykładowy scenariusz.
Gdy komputery zechcą się ze sobą skomunikować to wiemy, że zostanie utworzony pakiet IP zawierający adres źródłowy Klienta 1 oraz adres docelowy Klienta 2 (zawsze wychodzimy z założenia, że adres warstwy 3 – IP – jest znany). Pakiet IP następnie zostanie zenkapsulowany w ramkę Ethernet w celu dostarczenia jej za pośrednictwem segmentu sieci w warstwie drugiej. Stworzona ramka będzie zawierała adres źródłowy Klienta 1 oraz adres docelowy Klienta 2.
I tutaj pojawia się pytanie – skąd Klient 1 wie jaki jest docelowy adres MAC Klienta 2? W tym momencie z odpowiedzią przychodzi właśnie protokół ARP. Spójrzmy na przykład, w którym Klient 1 chce spingować Klienta 2:
Wiadomość ICMP Echo (niebieska) jest w takiej sytuacji enkapsulowana w pakiet IP (zielony) – oba adresy (źródłowy i docelowy) są znane. Pakiet IP jest z kolei enkapsulowany w ramkę Ethernet (żółty) gdzie Klient 1 zna jedynie swój własny źródłowy adres MAC. Spróbujmy spingować Klienta 2:
I widzimy, że ping działa! Ale jak? W jaki sposób Klient 1 poznał adres MAC Klienta 2?
W tle zadziałał ARP. Przyjrzyjmy się jego działaniu.
Każde urządzenie sieciowe (router, switch, komputer, drukarka, telefon…) posiada w pamięci strukturę nazywaną tabelą ARP. Tabela ta jest bardzo prosta i zawiera mapowania adresów IP na odpowiadające im adresy MAC. Większość wpisów w tej tabeli będzie się pojawiała dynamicznie w procesie, który omówimy sobie już za chwilę. Mamy natomiast również możliwość umieszczania wpisów w tej tabeli ręcznie – będą to wtedy wpisy statyczne.
Na dowolnym hoście z systemem Windows możemy wyświetlić tablicę ARP za pomocą komendy arp -a:
Na przełącznikach i routerach Cisco działających na systemie IOS odpowiednikiem tej komendy będzie zazwyczaj show ip arp:
Wróćmy do naszego przykładu. W momencie, w którym chcemy spingować Klienta 2, Klient 1 sprawdza zawartość swojej tabeli ARP. Jeżeli jest to pierwsza od dłuższego czasu próba komunikacji między tymi hostami to tabela ta nie będzie zawierała odpowiedniego wpisu, który powiedziałby nam jaki jest adres MAC Klienta 2:
W takiej sytuacji Klient 1 wysyła w sieć ramkę ARP Request na adres docelowy MAC FF:FF:FF:FF:FF:FF. Widzimy zatem, że jest to ramka rozgłoszeniowa (broadcast). Ramka ta trafi więc do wszystkich hostów w domenie rozgłoszeniowej (jeżeli mamy sieć zbudowaną w oparciu o przełączniki to ramka ta rozpropaguje się po całej sieci LAN). Od tego momentu zacznę przedstawiać adresy MAC w formie skróconej żeby się nam wszystko ładnie zmieściło na obrazkach. ARP Request w naszym przykładzie będzie wyglądał następująco:
Komunikat ARP Request (czerwony) zawiera w sobie informację o tym dla jakiego adresu IP (Target IP) poszukujemy odpowiadającego adresu MAC. Zauważ proszę, że pole Target MAC jest wypełnione na tym etapie samymi zerami.
Tak sformatowany ARP Request trafia do wszystkich hostów w danej domenie rozgłoszeniowej. W naszym przykładzie sprawa jest prosta, albowiem odbiorca może być tylko jeden. Każdy host, który otrzyma ARP Request zagląda w jego zawartość i sprawdza czy Target IP jest jego własnym adresem IP. Jeżeli są one identyczne to host ten zwróci odpowiedź – ARP Reply. Klient 2 otrzymując ARP Request zauważy w polu Target IP swój własny adres IP więc wygeneruje ARP Reply, wyglądający następująco:
Widzimy powyżej, że wygenerowana zostaje ramka od Klienta 2 do Klienta 1 (kolor żółty). Ramka ta zawiera komunikat ARP Reply (kolor czerwony), w którym mamy uzupełnioną informację o adresie MAC Klienta 2. Powoduje to, że gdy Klient 1 otrzymuje ARP Reply to dodaje on stosowne mapowanie do swojej tablicy ARP:
Dzięki protokołowi ARP Klient 1 posiada teraz kompletną informację potrzebną do wysłania pakietu ICMP Echo i spingowania Klienta 2:
Podsumowanie
Zauważ proszę, że Klient 2 będzie w stanie z powodzeniem natychmiast wysłać odpowiedź na pinga (ICMP Reply) ponieważ najprawdopodobniej będzie już posiadał w swojej tablicy ARP mapowanie IP na adres MAC dla Klienta 1. Jakim cudem? Dowiedział się tego mapowania w momencie gdy otrzymał omawiany w tym artykule ARP Request od Klienta 1 😉 Ponadto wszystkie potrzebne informacje do udzielenia odpowiedzi zwrotnej na pinga znajdują się również w otrzymanym ICMP Echo. Jak widzisz, urządzenia sieciowe non stop analizują to co otrzymują i wyłuskują potrzebne im informacje, w dynamiczny sposób wypełaniając m.in. tabelę ARP.
Na koniec ważna informacja: wpisy w tabeli ARP wygasają po czasie, który określamy jako cache timeout. Wartość ta może się różnić w zależności od urządzenia więc warto ją sprawdzić, ale generalnie w przypadku systemu IOS jest to 240 minut. Urządzenie sieciowe odlicza zatem czas dla każdego wpisu od 0 do 240 minut, a w przypadku pojawienia się na porcie jakiegoś ARP requestu licznik dla odpowiadającego mu wpisu się zeruje (źródło).
W tym miejscu bardzo istotna przestroga – nie mylmy wygasania wpisów w tablicy adresów MAC (aging-time – na większości urządzeń domyślnie 300 sekund) z wygasaniem wpisów w tablicy ARP (cache timeout). Dlaczego o tym piszę? Ano dlatego, że sam popełniłem te faux pas w tym artykule, na co zwrócił uwagę w komentarzach Leon (dziękuję!).
Hej, a może wspomnisz coś o Gratuitous ARP chyba że będziesz jeszcze rozwijał ten temat ?
Hej, temat ARP będę na pewno jeszcze rozwijał, natomiast postaram się na dniach coś dopisać do tego artykułu na temat gratuitous ARP 🙂 Dzięki
Artykuł uzupełniony o Gratuitous ARP 🙂
Good Job 😉
Bardzo dobre artykuły. Super strona.
Dzięki! Cieszymy się, że się podoba 🙂
Źródło skąd zostało przepisane informacje odnośnie GARP-a:
https://wiki.wireshark.org/Gratuitous_ARP
Przepisane? Serio? Link do źródła jest dobry, faktycznie z tej wiki zaczerpnąłęm informacje dotyczące działanie GARPa bo było to najlepsze podsumowanie jakie znalazłem. Całość przełożyłem na polski oraz zobrazowałem przykładem. Także z tym \”przepisywaniem\” to bym się mimo wszystko zastanowił. Gdyby tak podchodzić do tematu to nie pownniśmy w ogóle pisać o sieciach – wszystko już zostało kiedyś opisane, takimi czy innymi słowami.
Hej, pomyliles czas aging-time mac z ARP cache timeout. Dla arp wynosi z tego co pamietam 240 min.
Hej Leon, dziękuję za wyłapanie tego bardzo poważnego błędu i poinformowanie mnie o tym! Poprawiłem stosowny fragment w artykule.
Cześć 🙂
GARP nie jest wykorzystywany do wykrywania duplikatów adresów. Do tego są używane zapowiedzi i sondy ARP (probe i announcement ARP). Książkowy błąd powielany w szkołach i po forach.
Pozdrawiam!
Dziękujemy za feedback! Staramy się unikać błędów jak tylko się da, ale na szczęście gdzie Autor nie może tam Czytelnik pomoże 🙂
Co w przypadku jeżeli ustawie na routerze w ARP inny IP do adresu MAC a w serwerze DHCP przypisze do tego samego MACa inne IP? Mam router TP-LINK Archer C2 i mam tam mozliwość ustawienia stałego IP w DHCP i powiązania w ARP dla MAC/IP.
Hej Mariusz! Pozwolę sobie sparafrazować pytanie bo chciałbym się upewnić czy je dobrze zrozumiałem: mamy komputer o adresie MAC AA:AA (dla uproszczenia) i na serwerze DHCP dajemy mu statyczne przypisanie IP 192.168.0.1. Z kolei na routerze dajemy statyczny wpis w ARP, który wiąże MAC AA:AA z innym IP – 192.168.0.2. Tak to rozumiem.
W takiej sytuacji wg mnie nie będzie to miało wpływu na działanie w sytuacji kiedy inne hosty będą chciały spingować 192.168.0.1 – każdy host ma wszakże własną tablicę ARP (odpyta się sieci \”Who has 192.168.0.1?\” i AA:AA odpowie). Natomiast jeżeli byśmy chcieli spingować 192.168.0.1 z routera, to router również powinien wysłać ARP request i w tablicy ARP routera obok statycznego tłumaczenia 192.168.0.2 na AA:AA powinien się pojawić dynamiczny wpis asocjujący ze sobą IP 192.168.0.1 i MAC AA:AA. Generalnie wydaje mi się, że to zadziała, ale żeby potwierdzić musiałbym to przeładować.
Dlaczego komputery nie mogą się komunikować po adresie IP tylko potrzebują do wysłania pakietu adresu MAC? Przecież wysyłają ramkę do wszystkich hostów i ten właściwy się odzywa podając swój adres MAC. Czy nie wystarczyłaby odpowiedź, że został znaleziony bez podawania adresu MAC?
Cześć Darek. Bardzo celne pytanie. W zasadzie obylibyśmy się dziś bez adresacji w warstwie drugiej. Pamiętajmy, że jest to konstrukt z czasów gdy współdzielone segmenty sieci Ethernet były powszechne. Zachował się on do dziś tylko dlatego, że cały czas staramy się utrzymać kompatybilność wstecz 🙂
To nie do końca prawda jeśli w ogóle jakaś prawda. MAC ma głebsze znaczenie. Akceptacją ipków zajmuje się system operacyjny, mac leży nizej i pozwala ominąć ten problem. Czy np ICMP używa adresu IP? Pisanie że mac się uzywa tylko z powodów kompatybilości jest niezrozumieniem tematyki sieci.
tfu omawiany arp miał być nie icmp
Polemizowałbym. Mój argument odnosi się do tego, że gdyby dziś projektować działanie sieci od podstaw, to najprawdopodobniej doszlibyśmy do wniosku, że adresacja w warstwie drugiej jest zbędna. Nie twierdzę, że jest zbędna w obecnych realiach – L2 ma zbyt szerokie zastosowanie i jest \”wplątane\” w zbyt wiele mechanizmów działania sieci by się go pozbyć. Ale marzyć zawsze można 🙂 Wydaje mi się, że powyższe przemyślenia wynikają właśnie ze zrozumienia tematyki sieci 😉
A to nie jest tak, że MAC określa hop czyli zmienia się za każdym razem gdy przechodzi przez kolejne urządzenia a IP określa end to end czyli określa adresację początkową i końcową? Wybaczcie za małą precyzyjność ale jestem początkujący w tym temacie a nie było to wspomniane w dyskusji.
A da się w drugą stronę? Czyli znająć MAC dostać IP urządzenia?
Pytam, bo z tego co zauważyłem np. z Mikrotick można się połączyć w sieci nie znająć jego IP, a jedynie adres MAC.
Da się. Jest do tego używany mechanizm Reverse ARP (RARP)
Trochę inne pytanie, ale odnośnie przykładu. Wysłanie pinga tworzy wpis arp na te 240 min. Ale czemu nie tworzy się wpis, jak pingujemy inną podsieć czy sieć globalną?
Pingując sieć zdalną potrzebujemy w tablicy ARP wpis dla gateway’a – i to on zostanie użyty (jeśli istnieje). Jeśli go nie ma to urządzenie wyśle ARP, ale o gateway. Można to też zrozumieć tak, że ARP jest w zasadzie tablicą next-hopów w warstwie drugiej.