[ Pobierz całość w formacie PDF ]
.Protoko³y te, wrazz RIP-em, zosta³y zaimplementowane w demonie gated napisanym na Uniwersyte-cie Cornella.WartoSci metrykiMo¿na skorzystaæ z rutingu dynamicznego, je¿eli trzeba znalexæ najlepsz¹ trasê dohosta docelowego lub sieci na podstawie liczby hopów.Hopy oznaczaj¹ liczbê gate-wayów, przez które datagram musi przejSæ, zanim dotrze do hosta lub sieci.Imkrótsza jest trasa, tym lepiej radzi sobie z ni¹ RIP.Bardzo d³ugie trasy (ponad 16 ho-pów) s¹ traktowane jako bezu¿yteczne i s¹ usuwane.RIP obs³uguje informacje o rutingu wewn¹trz twojej sieci lokalnej, ale na wszystkichhostach musisz uruchomiæ demona gated.W czasie startu komputera gated sprawdzawszystkie aktywne interfejsy sieciowe.Je¿eli jest aktywny wiêcej ni¿ jeden interfejs(nie licz¹c interfejsu pêtli zwrotnej), demon zak³ada, ¿e host przekazuje pakiety po-miêdzy kilkoma sieciami i czynnie wymienia oraz rozg³asza informacje o rutingu.W przeciwnym razie jedynie pasywnie odbiera uaktualnienia RIP i odSwie¿a lo-kaln¹ tablicê rutingu.Przy rozg³aszaniu informacji z lokalnej tablicy rutingu, gated liczy d³ugoSæ trasy napodstawie tak zwanej wartoSci metryki (ang.metric value) zwi¹zanej z wpisem w tabli-cy.Ta wartoSæ jest ustawiana przez administratora podczas konfigurowania rutingui powinna odpowiadaæ rzeczywistemu kosztowi trasy*.Dlatego metryka trasy dopodsieci, do której host jest pod³¹czony bezpoSrednio, zawsze powinna wynosiæ ze-ro, natomiast trasa prowadz¹ca przez dwa gatewaye powinna mieæ metrykê o war-toSci dwa.Nie musisz przejmowaæ siê metryk¹, je¿eli nie u¿ywasz protoko³u RIP-aani gated.Internetowy protokó³ komunikatów kontrolnych (ICMP)IP ma protokó³ towarzysz¹cy, o którym jeszcze nie mówiliSmy.Jest nim ICMP (Inter-net Control Message Protocol) u¿ywany przez kod sieciowy j¹dra do przesy³aniakomunikatów o b³êdach do innych hostów.Na przyk³ad za³Ã³¿my, ¿e jesteS znów naerdosie i chcesz zrealizowaæ po³¹czenie telnet z portem 12345na quarku, ale na tymporcie nie ma procesu nas³uchuj¹cego.Gdy pierwszy pakiet TCP zaadresowany naten port nadejdzie do quarka, warstwa sieciowa rozpozna, ¿e coS przysz³o i natych-miast zwróci do erdosa komunikat ICMP o treSci Port Unreachable (port nie-osi¹galny).* Koszt trasy to, w prostych sieciach, liczba hopów wymaganych do dotarcia do celu.W bardziej skom-plikowanych sieciach poprawne obliczenie kosztu trasy mo¿e byæ trudne. Rozwi¹zywanie nazwy hosta 29Protokó³ ICMP udostêpnia ró¿ne komunikaty, g³Ã³wnie z informacjami o b³êdach.Jednak istnieje jeden ciekawy komunikat, tak zwany komunikat przekierowania(ang.redirect message).Jest on generowany przez modu³ rutingu, gdy wykryje on, ¿einny host u¿ywa naszego hosta jako gatewaya, mimo ¿e istnieje krótsza trasa.Naprzyk³ad po uruchomieniu systemu tablica rutingu na sophusie mo¿e byæ niepe³na.Mo¿e zawieraæ trasy do sieci wydzia³u matematyki, do szkieletu FDDI i domySln¹trasê do gatewaya centrum obliczeniowego Groucho (gcc1).Tak wiêc pakiety adre-sowane do quarka bêd¹ wysy³ane do gcc1, a nie do nielsa gatewaya wydzia³u fizy-ki.Po odebraniu takiego datagramu gcc1 zauwa¿y, ¿e jest to nieoptymalna trasai przeka¿e pakiet do nielsa, zwracaj¹c równoczeSnie do sophusa komunikat prze-kierowania ICMP z informacj¹ o lepszej trasie.Wydaje siê, ¿e w ten sposób mo¿na ³atwo unikn¹æ rêcznej konfiguracji wszelkichtras poza podstawowymi.Trzeba jednak zdawaæ sobie sprawê, ¿e poleganie naschematach rutingu dynamicznego, czy to bêdzie RIP, czy komunikat przekierowa-nia ICMP, nie zawsze jest dobre.Przekierowanie ICMP i RIP daj¹ ci niewielk¹ mo¿li-woSæ (lub wrêcz nie daj¹ ci ¿adnej szansy) weryfikowania pokrywaj¹cych siê infor-macji o rutingu.Ta sytuacja mo¿e prowadziæ do zak³Ã³cenia pracy ca³ej twojej siecilub jeszcze gorszych rzeczy.W rezultacie kod sieciowy Linuksa traktuje komunikatyprzekierowania sieci tak, jakby to by³y przekierowania hosta.Minimalizuje to znisz-czenia w przypadku ataku, które dotkn¹ wówczas jeden host, a nie ca³¹ sieæ.Z dru-giej strony oznacza to, ¿e w przypadku legalnej sytuacji generowany jest nieco wiêk-szy ruch, gdy¿ ka¿dy host wysy³a komunikat przekierowania ICMP.Obecnie opie-ranie siê na przekierowaniach ICMP nie jest dobrze widziane i uznaje siê je raczej zaz³¹ praktykê.Rozwi¹zywanie nazwy hostaJak wczeSniej napisaliSmy, adresowanie w sieci TCP/IP, przynajmniej tam, gdziekorzysta siê z IP w wersji 4, opiera siê na liczbach 32-bitowych.Nie ukrywamy, ¿ezapamiêtywanie takich liczb nie jest ³atwe.Dlatego hosty wystêpuj¹ równie¿ pod zwyk³ymi nazwami, takimi jak gauss czy strange.Znalezienie adresu IP odpo-wiadaj¹cego nazwie to obowi¹zek aplikacji.Proces ten jest nazywany rozwi¹zywan-iem nazwy hosta.Gdy aplikacja chce znalexæ adres IP danego hosta, korzysta z funkcji bibliotecznejgethostbyname(3) i gethostbyaddr(3).Tradycyjnie te i inne zwi¹zane z nimi proceduryby³y zgrupowane w oddzielnej bibliotece o nazwie resolverlibrary.W Linuksie funk-cje te s¹ czêSci¹ standardowej biblioteki libc.Potocznie zestaw tych funkcji jest nazy-wany resolverem .Konfiguracjê mechanizmu rozwi¹zywania nazw opisano szc-zegó³owo w rozdziale 6, Us³ugi nazewnicze i konfigurowanie resolvera.W przypadku ma³ej sieci Ethernet czy nawet grupy takich sieci, nie jest trudno utrzy-mywaæ tablice odwzorowuj¹ce nazwy hostów na adresy.Informacja ta jest zwykleprzechowywana w pliku o nazwie /etc/hosts.Podczas dodawania lub usuwania hos-tów albo zmiany przypisania adresów, wystarczy uaktualniæ plik hosts na wszystkich 30 Rozdzia³ 2: Wybrane problemy sieci TCP/IPhostach.OczywiScie staje siê to uci¹¿liwe przy sieciach, które sk³adaj¹ siê z wiêcej ni¿kilku maszyn.Jednym z rozwi¹zañ jest NIS (Network Information System system informacji siecio-wej) stworzony przez firmê Sun Microsystems, potocznie nazywany YP lub YellowPages.NIS przechowuje plik hosts (i inne informacje) w bazie danych na hoScie g³Ã³w-nym, z którego klienty mog¹ go w razie potrzeby odczytywaæ.Rozwi¹zanie takiejest odpowiednie jedynie dla Sredniej wielkoSci sieci typu LAN, poniewa¿ wymagautrzymania centralnej bazy danych hosts i dystrybuowania jej do wszystkich serwerów.Instalacja i konfiguracja NIS-a zosta³a omówiona w rozdziale 13, System informacjisieciowej.W Internecie informacje adresowe by³y pierwotnie przechowywane tak¿e w plikubazy danych HOSTS.TXT.Plik ten by³ utrzymywany przez NIC (Network InformationCenter centrum informacji sieciowej) i musia³ byæ stamt¹d pobierany i instalowanyprzez wszystkie oSrodki pod³¹czone do Internetu.Gdy sieæ siê rozros³a, takie roz-wi¹zanie sta³o siê niewygodne.Poza uci¹¿liwym w administracji regularnym insta-lowaniem pliku HOSTS.TXT, niebezpiecznie wzros³o obci¹¿enie dystrybuuj¹cychgo serwerów.Co wiêcej, wszystkie nazwy musia³y byæ rejestrowane w NIC, abymieæ pewnoSæ, ¿e ¿adna siê nie powtarza.Dlatego w 1994 roku przyjêto nowy schemat rozwi¹zywania nazw: system nazw do-men (Domain Name System DNS) autorstwa Paula Mockapetrisa.System nazw do-men omawiamy szczegó³owo w rozdziale 6
[ Pobierz całość w formacie PDF ]