Odwzorowanie adresów IP i nazw logicznych

Odwzorowanie adresów IP na adresy MAC

Aby dwa komputery mogły nawiązać komunikację, ich karty sieciowe muszą mieć możliwość wzajemnego odnalezienia się. W sieci TCP/IP każdej stacji przypisuje się reprezentujący ją adres IP. Protokołem używam do odwzorowania adresu IP do adresu MAC karty sieciowej jest ARP. Chociaż teraz zajmiemy się przypisywaniem logicznych nazw stacjom, warto pamiętać, że faktyczne zaistnienie komunikacji zawsze wymaga również tego kroku.

Odwzorowanie nazw logicznych
na adresy IP

Wyższość oznaczania stacji nazwami pochodzącymi z języka naturalnego w porównaniu z korzystaniem z adresów IP nie wymaga chyba uzasadnienia. W sieciach TCP/IP wykorzystywane są dwie techniki odwzorowywania nazw:

• Odwzorowywanie hostnames.

• Odwzorowywanie nazw NetBIOS.

Proces odwzorowywania nazw logicznych odbywa się na poziomie aplikacji w modelu warstw TCP/IP

Jak widać na rysunku, do odwzorowania nazwy wykorzystuje się jedną z dwóch metod. Jej wybór należy do aplikacji korzystającej z usługi odwzorowania. Aplikacje NetBIOS używają odwzorowania nazw NetBIOS, aplikacje Winsock - odwzorowania hostnames.

Po określeniu dla danej nazwy adresu IP wykorzystywany jest protokół ARP w celu uzyskania adresu MAC. Rezultat tego procesu zależy od tego, czy poszukiwana stacja znajduje się w sieci lokalnej, czy odległej. W pierwszym przypadku ARP zwraca adres MAC stacji docelowej. Jeżeli jednak stacja znajduje się w sieci odległej, protokół ARP określi adres MAC routera wykorzystywanego do przesyłania danych do tej sieci. Ramka zostaje przesłana do bramy domyślnej, która przekaże ją dalej do sieci zawierającej stację docelową.

Odwzorowanie hostnames

Metoda odwzorowania nazw określana jako hosmame resolution towarzyszyła Inter­netowi od jego początków. Wówczas informacje
o nazwach stacji (czyli host names) były przechowywane w jednym centralnym pliku HOSTS.TXT.

Sieciowe Centrum Informacyjne (NIC) rejestrowało w tym pliku nazwy i adresy IP wszystkich pojawiających się w Internecie stacji.

Każda z połączonych w sieć stacji tworzyła kopię głównego pliku HOSTS.TXT w swoim systemie. Wraz z rozszerzaniem się Internetu, coraz wyraźniejsza stawała się potrzeba odejścia od tak scentralizowanego systemu. Pojawiły się m.in. następujące problemy:

• Szybkość rozrostu sieci wymuszała codzienne aktualizacje pliku.

• Sieć Instytutu Badawczego Stanforda (gdzie przechowywana była główna ko­pia pliku nazw) stała się prawdziwym "wąskim gardłem" Internetu.

• "Płaska'' struktura nazw stacji powodowała, że określona nazwa stacji
  w całej dużej sieci nie mogła zostać nigdzie powtórzona.

• Zaktualizowanie informacji o nazwach stacji w skali całego Internetu wyma­gało kilku dni.

Stało się wówczas jasne, że nowy system odwzorowywania nazw musi opierać się na strukturze hierarchicznej. Drugą istotną przesłanką nowego rozwiązania była potrzeba zastąpienia centralnej bazy danych rozwiązaniem typu rozproszonego. Miało ono poz­wolić każdej organizacji na zarządzanie własnym systemem nazw stacji.

Przestrzeń nazw domen

Przestrzeń nazw domen (ang. Domain Name Space) jest drzewiastą strukturą obejmu­jącą wszystkie domeny tworzące przestrzeń nazw Internetu. Początkiem drzewa jest do­mena określana angielskim terminem root, czyli korzeń

Rysunek Przestrzeń nazw domen

W odróżnieniu od pozostałych domen, domenie root nie odpowiada żadna występująca w nazwach stacji etykieta. Do jej określenia stosuje się czasem znak kropki (.).

Poniżej domeny root znajdziemy domeny pierwszego poziomu (ang. top-level domains). Są one dwojakiego rodzaju: pierwsza ich grupa odpowiada typom działalności korzystających z nich organizacji, druga oparta jest na dwuliterowych oznaczeniach krajów, w których po­szczególne organizacje się znajdują.

Kolejny poziom hierarchii, zawierający konkretne stacje i dalsze poddomeny, tworzą domeny drugiego poziomu (ang. second-level domains).

Domeny krajowe

http://www.amu.edu.pl - ujednolicony adres zasobu

(ang. URL - universal resource locator)

Nazwa stacji obejmująca pełną nazwę domeny jest określana jako zupełna lub w pełni kwalifikowana nazwa domenowa (ang. FQDN - fully qualified domain name) .

Nazwy domen drugiego poziomu muszą być zarejestrowane

w InterNIC (ang. Internet Network Information Center)

http://www.internic.net

Proces odwzorowywania nazw stacji

Proces prowadzący do określenia adresu IP na podstawie nazwy stacji przebiega wg. algorytmu:

1. Czy przedmiotowa nazwa jest nazwą stacji, na której aktualnie pracujesz?

2. Czy przedmiotowa nazwa występuje w pliku HOSTS?

3. Czy serwer DNS posiada wpis odpowiadający poszukiwanej stacji?

4. Czy nazwa stacji została zarejestrowana na serwerze WINS?

5. Czy nazwa stacji może zostać odwzorowana za pośrednictwem lokalnego rozgłoszenia?

6. Czy nazwa stacji została zapisana w pliku LMHOSTS?

7. Kiedy żadna z tych metod określania adresu IP stacji docelowej nie zakończy się powodzeniem, aplikacja zwraca komunikat informujący, że nazwa stacji nie została odnaleziona.

Podział ról w systemie DNS

W procesie odwzorowania nazwy, jaki zachodzi w systemie przestrzeni nazw domen, biorą udział trzy rodzaje podstawowych elementów:

• przestrzeń nazw domen,

• klienci odwzorowania,

• serwery nazw.

Przestrzeń nazw domen zapewnia rozproszoną, hierarchiczną bazę danych, która zawiera wszystkie przyporządkowania nazw stacji do adresów IP w Internecie. Pozwala więc odwzorować dowolną nazwę stacji w jej adres IP.

Klienci odwzorowania to oprogramowanie klienckie, które wymaga odwzorowania nazw na adres IP. Funkcje klienta odwzorowania są albo częścią aplikacji wywołującej, albo też uruchomione są w systemie operacyjnym stacji jako część stosu protokołu TCP/IP.

Serwery nazw to obecne w sieci stacje przyjmujące zapytania od klientów odwzorowania i zwracające adresy IP poszukiwanych stacji.

W zależności od konfiguracji i przyjętego zapytania serwer nazw może zwracać adres IP odpowiadający nazwie stacji, nazwę odpowiadającą adresowi IP, odpowiedź informującą o tym, że nazwa stacji nie zostali odnaleziona, lub wskazanie innego serwera nazw, który może zrealizować zapytanie.

Każdy z serwerów nazw może występować w następujących rolach:

• podstawowy serwer nazw,

• pomocniczy serwer nazw,

• główny serwer nazw,

• serwer nazw buforujący.

Podstawowy serwer nazw

Podstawowy serwer nazw (ang. primary name server) zarządza strefą danych. Termin strefa oznacza część przestrzeni nazw domen, za który odpowiedzialny jest konkretny serwer nazw. Pliki danych dla strefy są przechowywane lokalnie na podstawowym serwerze nazw.

Wszystkie modyfikacje w tych plikach mogą być przeprowadzane wyłącznie na tym serwerze. Strefa obsługiwana przez podstawowy serwer nazw może obejmować więcej niż jedną domenę. Może on zarządzać poddomenami
w określonej domenie albo też przechowywać pliki związane z kilkoma różnymi domenami drugiego poziomu.

Rysunek 7.4.

Strefy serwerów nazw

Zależność pomiędzy strefami a domenami

Wielu użytkowników zakłada, że plik strefy odpowiada zawsze dome­nie.

Nie musi to jednak być prawdą. Załóżmy, że firma XYZ, korzysta­jąca z domeny XYZ.com, rejestruje poddomeny sprzedaż, badania i marketing. Strefa może obejmować domenę XYZ.com i trzy poddomeny. Można jednak utworzyć osobne strefy dla wszystkich lub jedy­nie wybranych poddomen

Rysunek 7.5. Trzy pliki stref w jednej domenie

Pomocniczy serwer nazw

Pomocniczy serwer nazw (ang. secondary name server) uzyskuje informacje o strefie z innego serwera posiadającego plik strefy; owym "innym serwerem" może być inny serwer pomocniczy lub też serwer podstawowy. Operacja przesłania informacji o strefie jest zwięźle określana terminem przesłanie strefy.

Przesłankami wprowadzenia serwera pomocniczego są:

· Potrzeba rozłożenia obsługi ruchu sieciowego na dodatkowy serwer z tymi sa­mymi danymi strefy.

· Potrzeba przyspieszenia odwzorowywania w ośrodku odległym przez utworze­nie w nim dodatkowego serwera nazw.

· Potrzeba zmniejszenia awaryjności układu przez utworzenie dodatkowego ser­wem zapewniającego utrzymanie możliwości odwzorowywania nawet w przy­padku utraty funkcjonalności przez jeden z serwerów nazw.

· Utworzenie serwera pomocniczego jest warunkiem zarejestrowania domeny w InterNIC.

Pliki stref przechowywane na serwerach pomocniczych nie są nigdy aktualizowane bez­pośrednio - są jedynie kopiami plików przechowywanych na serwerach podstawowych. Stąd też stosowane niekiedy określenie serwer podległy (ang. slave name server)

Główny serwer nazw

Główny serwer nazw (ang. master name server) to serwer nazw, który przesyła swoje pliki stref do serwera pomocniczego. Chociaż mogłoby się wydawać, że jedynie podsta­wowe (primary) serwery nazw pracują jako serwery główne (master), również serwer pomocniczy (secondary) może pełnić tę rolę. Sytuacja taka może wyniknąć z możliwości wykorzystywanych łączy sieciowych.

Rysunek 7.6 przedstawia sieć, w której korzy­stniejsze będzie, gdy serwer pomocniczy będzie pełnił rolę głównego.

Rysunek 7.6. Sytuacja, kiedy pomocniczy serwer nazw powinien funkcjonować jako główny serwer

W konfiguracji serwera pomocniczego wskazywany jest adres IP serwera głównego (master). Podczas inicjalizacji komunikuje się on ze wskazanym serwerem głównym i inicjuje przesyłanie danych DNS strefy.

Buforujące serwery nazw

Buforujący serwer nazw (ang. caching-only name server) nie przechowuje informacji strefowej na lokalnych nośnikach danych. Kiedy stacja przesyła zapytanie do serwera buforującego, przekazuje on je dalej "w imieniu" tej stacji, buforuje wynik i zwraca klientowi adres IP poszukiwanej stacji. Kiedy później odbiera takie samo zapytanie od innej stacji, odpowiedź jest przekazywana na podstawie danych wciąż trzymanych w buforze.

Tego rodzaju rozwiązanie staje się użyteczne, gdy łącza sieci rozległej posiadają sto­sunkowo niewielką przepustowość. Zamiast serwera pomocniczego, który wymaga regu­larnego przesyłania pełnej informacji o strefie, może zostać utworzony jedynie serwer buforujący. Przesyłane są wówczas jedynie faktycznie użyteczne dane. W buforze prze­chowywane są wtedy informacje o najczęściej odwiedzanych miejscach i skorzystanie z nich nie wymaga żadnego ruchu na łączach sieci WAN.

Rodzaje zapytań DNS

Klient odwzorowania może kierować do serwera nazw następujące rodzaje zapytań:

• rekurencyjne,

• iteracyjne,

• odwrotne.

Zapytania rekurencyjne

W przypadku zapytania rekurencyjnego serwer nazw może zwrócić wyłącznie adres IP odpowiadający wskazanej stacji albo informację o błędzie. Często wymaga to pełnienia przezeń roli klienta odwzorowania i przekazania zapytania do dalszego wskazanego w konfiguracji serwera nazw (patrz rysunek 7.7).

Tego rodzaju konfiguracja będzie wykorzystywana m.in. w przypadku sieci lokalnej od­dzielonej od Internetu zaporą firewall. Wówczas konieczne staje się skonfigurowanie wewnętrznego systemu DNS tak, aby zapytania były przekazywane do serwera DNS zapory. Ich kierowanie poza zaporę nie jest dopuszczalne. Jedynym komputerem, który może kierować zapytania do sieci zewnętrznej, jest sama zapora. Użycie zapytania reku­rencyjnego pozwala systemowi firewall przekazać je do wskazanego w konfiguracji serwera nazw, a następnie zwrócić odpowiedź w postaci adresu IP do stacji inicjującej.

Rysunek 7.7. Zapytanie rekurencyjne za pośrednictwem zapory firewall

Zapytania iteracyjne

Zapytanie iteracyjne nakłada na serwer nazw wymóg podania klientowi jedynie naj­lepszej dostępnej odpowiedzi. Odpowiedzią może być zarówno adres IP poszukiwanej stacji (lub informacja o braku możliwości odwzorowania), jak i wskazanie innego ser­wera DNS, który może dostarczyć adres IP odpowiadający poszukiwanej nazwie.

Rysunek 7.8.

Iteracyjne zapytanie DNS

Rysunek 7.8 przedstawia w zasadzie połączenie zapytań rekurencyjnych i iteracyjnych. W celu odwzorowania nazwy www.altavista.digital.com wykonane zostały na­stępujące kroki:

1. Klient DNS wysyła do swojego serwera DNS rekurencyjne zapytanie o adres IP odpowiadający nazwie www.altavista.digital.com

2. Serwer DNS nie ma odpowiedzi w swoim buforze ani też wskazania w konfi­guracji, pozwalającego kontynuować zapytanie rekurencyjne. Wysyła więc do serwera root zapytanie iteracyjne o adres odpowiadający nazwie www.alta­vista.digital.com.

3. Serwer root zwraca wysyłającemu zapytanie lokalnemu serwerowi DNS adres IP serwera domeny pierwszego poziomu COM.

4. Lokalny serwer DNS wysyła do serwera nazw domeny COM kolejne zapytanie iteracyjne, również
   o nazwę www.altavista.digital.com.

5. Serwer nazw domeny COM zwraca w odpowiedzi adres IP kompetentnego serwera nazw domeny DIGITAL.COM.

6. Lokalny serwer DNS ponawia zapytanie o adres stacji www.altavista.digital.com , kierując je do serwera nazw domeny DIGITAL.COM.

7. Jeżeli dane dotyczące poddomeny ALTAVISTA.DIGITAL.COM są przecho­wywane w osobnym pliku strefy na osobnym serwerze nazw, serwer DNS domeny DIGITAL.COM zwróci adres serwera nazw odpowiadającego za do­menę ALTAVISTA.DIGITAL.COM.

8. Lokalny serwer nazw wysyła do serwera nazw ALTAVISTA.DIGITAL.COM zapytanie o www.altavista.digital.com .

9. Serwer ALTAVISTA.DIGITAL.COM zwraca adres IP stacji www.altavis­ta.digital.com , a jeżeli nazwa taka nie istnieje w tej domenie - informację o nieprawidłowej nazwie stacji.

10. Lokalny serwer nazw przede wszystkim zapisuje adres IP stacji www.altavista.digital.com w swojej pamięci podręcznej.
    Po utworzeniu odpowiedniego wpisu przekazuje adres IP do klienta, który zainicjował procedurę.

Zapytania odwrotne

Zapytanie odwrotne (ang. inverse query) służy do odnalezienia pełnej kwalifikowanej nazwy domeny (FQDN) odpowiadającej określonemu adresowi IP. Zamiast określania adresu na podstawie nazwy stacji, wyszukujemy więc nazwę stacji odpowiadającą zna­nemu adresowi IP.

Jest to czynność powszechnie wykonywana przez osoby analizujące bezpieczeństwo sieci, kiedy próbują odwzorować adres IP stacji zapisanej w dzienniku bezpieczeństwa na jej internetową nazwę.

Jest to również wykorzystywane przy ustalaniu reguł ograniczających dostęp do okreś­lonych ośrodków dla zapory firewall.

Jeżeli zostało ustalone, że użytkownicy nie po­winni uzyskiwać dostępu do ośrodka www.głupie-strony.com , zapora może zostać dodatkowo skonfigurowana do przeprowadzania wyszukiwań odwrotnych. Zabezpieczy to przed omijaniem przez użytkowników wprowadzonego ograniczenia przez bezpośre­dnie wpisanie adresu IP, jak 198.168.5.67.

Poprawianie wydajności DNS

Kluczowym czynnikiem decydującym o wydajności serwera DNS jest zdolność buforowania odwzorowywanych nazw. Kiedy serwer odwzorowuje nazwę dla klienta, zapisuje ją wraz z adresem w swojej pamięci podręcznej. Gdy zapytanie o tę samą nazwę zostaje powtórzone, wykorzystanie odpowiedzi przechowywanej w buforze pozwala uniknąć powtórnego uruchamiania procesu odwzorowywania.

Buforowanie DNS jest oparte na polu TTL (ang. time-to-live - czas życia), które jest częścią odpowiedzi przekazywanej przez serwer nazw. Pole to określa, po jakim czasie zapis DNS powinien zostać usunięty z pamięci podręcznej serwera nazw.

Pole TTL jest również uwzględniane, gdy zapis zostaje uzyskany z pamięci podręcznej innego serwera.

Rysunek 7.9 przedstawia zasadę, zgodnie z którą następuje przeniesie­nie informacji zapisanej w polu TTL podczas procesu odwzorowywania DNS.

Rysunek 7.9,

Serwer DNS1 przekazał zapytanie do serwera DNS2. Ten z kolei przekazał je do serwe­ra DNS3. DNS3 potrafił odwzorować www.yahoo.com na adres 204.71.200.72. W od­powiedzi zawarta jest informacja, że czas życia tego adresu powinien wynosić 45 minut.
Serwer DNS2 dodaje kombinację nazwy stacji i adresu IP do swojej pamięci podręcznej i również ustawia dla nich TTL na 45 minut - mimo że domyślną wartością czasu życia dla wszystkich wpisów jest 120 minut. Powodem takiego postępowania jest to, że serwer DNS3 gwarantuje poprawność rezultatu jedynie na podane 45 minut. Podobna zasada jest przestrzegana przy dodawaniu kombinacji adresu i nazwy stacji do pamięci podręcznej DNS1

Odwzorowanie nazw NetBIOS

RFC 1001 RFC 1002

Alternatywnym systemem przypisywania komputerom i realizowanym przez nie usługom nazw logicznych są nazwy NetBIOS.
Interfejs NetBIOS jest rodzajem interfejsu, programowania aplikacji (API), który umożliwia komunikację między komputerami pracującymi jako klient i serwer przy wykorzystaniu do ich oznaczania nazw pochodzących z języka naturalnego. NetBIOS zapewnia następujące usługi:

• rejestrację i zwalnianie nazw przez klientów,

• odwzorowanie nazw,

• ustanawianie i kończenie sesji,

• obsługę niezawodnej transmisji danych, zorientowanej na połączenie,

• obsługę bezpołączeniowej transmisji datagramów.

Długość nazw NetBIOS jest ograniczona do 16 bajtów. Pierwszych 15 jednoznacznie identyfikuje zasób NetBIOS w sieci. Ostatni bajt wskazuje typ usługi reprezentowany przez zasób NetBIOS. Każda usługa NetBIOS posiada własny identyfikator, który jest wykorzystywany przy rejestracji jej nazwy.

Nazwy NetBIOS a numery gniazd

Zarówno NetBIOS, jak i WinSock posiadają techniki identyfikacji apli­kacji oraz usług uruchomionych na serwerze lub kliencie. W systemie NetBIOS każdej usłudze przypisana jest nazwa zawierająca odpowia­dający jej niepowtarzalny szesnasty znak. Oznaczenia usług są zuni­fikowane. Klient łączy się z usługą, korzystając z jej nazwy NetBIOS.

W systemie WinSock każda usługa lub aplikacja ma określony w swojej konfiguracji (najczęściej standardowy) numer portu, za pośrednictwem którego oczekuje na wywołania połączeń przez klientów. Każdy klient zna numer portu, z którym powinien się połączyć.

W obydwu rozwiązaniach również klient posiada określającą go jedno­znacznie nazwę NetBIOS lub numer gniazda. Zapewniona jest więc identyfikacja obu stron połączenia.

Zasoby NetBIOS mogą obejmować zarówno nazwy identyfikujące pojedyncze kompu­tery, jak i nazwy grup komputerów. Tabela 7.2 przedstawia wybrane z najpopularniejszych nazw NetBIOS.

Popularne nazwy NetBIOS

Nazwa	Przyrostek NetBIOS	Typ	Opis
Nazwa komputera	00	Jednostkowa	Usługa stacji roboczej
Msbrowse_	01	Jednostkowa	Nazwa wykorzystywana przez główną przeglądarkę segmentu do rozgłaszania i odbierania ogłoszeń domen w segmencie
Nazwa komputera	03	Jednostkowa	Nazwa określonego komputera
Nazwa użytkownika	03	Jednostkowa	Nazwa określonego użytkownika
Nazwa komputera	06	Jednostkowa	Serwer RAS
Nazwa domeny	1B	Jednostkowa	Główna przeglądarka domeny
Nazwa domeny	1D	Jednostkowa	Główna przeglądarka w segmencie
Nazwa komputera	1F	Jednostkowa	Usługa NetDDE
Nazwa komputera	20	Jednostkowa	Serwer
Nazwa komputera	21	Jednostkowa	Klient RAS
Nazwa komputera	BE	Jednostkowa	Agent monitora sieci
Nazwa komputera	BF	Jednostkowa	Aplikacja monitora sieci
Nazwa domeny	00	Grupowa	Udział w domenie lub grupie
Nazwa domeny	1C	Grupowa	Wszystkie kontrolery określonej domeny do 25 wpisów; pierwszy wpis określa zawsze podstawowy kontroler domeny (PDC)
Nazwa domeny	1E	Grupowa	Rejestrowana przez wszystkie komputery uczestniczące w wybieraniu usługi przeglądarki

Określenie sposobu odwzorowywania nazw należy do konfiguracji klienta NetBIOS.

Jest to tzw. typ węzła NetBIOS. Można ustawić kilka różnych konfiguracji:

• Klient rozgłoszeniowy (B-pode) wykorzystuje w transakcjach NetBIOS wyłącznie rozgłoszenia (broadcasts). Jeżeli docelowy komputer NetBIOS nie znajduje się w tym samym segmencie sieci, do komunikacji zazwyczaj nie dochodzi.

• Klient równorzędny (P-pode, peer-node) wykorzystuje w transakcjach NetBIOS wyłącznie serwer nazw NetBIOS (NBNS, NetBIOS name server). Serwer NBNS przyjmuje rejestracje nazw i przechowuje bazę danych wszystkich stacji skonfigurowanych do korzystania z jego usług. Jeżeli nie posiada on zapisu odpo­wiadającego poszukiwanej nazwie, klient nie może połączyć się ze stacją noszącą tę nazwę.

• Klient mieszany (M-node) najpierw poszukuje nazwy NetBIOS za pomocą roz­głoszenia. W przypadku niepowodzenia przekazuje zapytanie do serwera nazw, aby sprawdzić, czy ten posiada odpowiedni zapis.

• Klient hybrydowy (H-node) najpierw próbuje odwzorowania za pośrednictwem NBNS. Jeżeli na serwerze nie istnieje zapis odpowiadający wskazanej nazwie, próbuje metody rozgłoszeniowej, w obrębie lokalnego segmentu. Jest to podstawowa konfiguracja w sieci NetBIOS - ogranicza liczbę obciążających sieć rozgłoszeń, zachowując jednocześnie możliwość korzystania z nich w poszukiwaniu nazw nie zarejestrowanych na serwerze NBNS.

Odwzorowywanie według Microsoftu

Oprogramowanie klienckie firmy Microsoft wykorzystuje jeszcze inną metodę odwzorowywania nazw NetBIOS, określaną jako rozszerzony klient rozgłoszeniowy (enhanced B-node). Najpierw następuje próba odwzorowania za pośrednictwem rozgłoszenia. Jeżeli zakończy się ona niepowodzeniem, przeszukiwany jest lokalnie przechowywany i konfigurowany plik o nazwie LMHOSTS.

Proces odwzorowywania nazw NetBiOS

Odwzorowanie nazw NetBIOS prowadzi do określenia adresu IP odpowiadającego okreś­lonej nazwie NetBIOS. Po ustaleniu adresu IP może on zostać zamieniony na adres MAC za pośrednictwem protokołu ARP.

Przykładowy proces odwzorowywania przedstawia rysunek 7.10: klient został w tym przykładzie skonfigurowany hybrydowo.

Rysunek 7.10.

1. Pierwsze sprawdzenie w procesie prowadzi do ustalenia, czy nazwa NetBIOS nie jest nazwą zarejestrowaną lokalnie. W takim przypadku w komunikacji wykorzystywany jest adres IP własny, czyli 127.0.0.1 - łącza sieciowe nie są wówczas wykorzystywane.

2. Przeglądana jest zawartość pamięci podręcznej nazw NetBIOS: Jeżeli dokona­ne wcześniej odwzorowanie nazwy zostanie w niej odnalezione, wykorzysty­wany jest ten sam, co ustalony wcześniej, adres IP.

3. Zgodnie ze wskazaniem w swojej konfiguracji, klient wysyła zapytanie do ser­wera nazw NetBIOS. Jednym z zadań tego serwera jest przyjmowanie automa­tycznych rejestracji nazw NetBIOS wraz z towarzyszącymi im adresami IP, od skonfigurowanych do korzystania z niego klientów. Jeżeli odpowiednia nazwa zostanie odnaleziona w bazie danych serwera, klientowi zwracany jest odpo­wiedni adres IP.

4. Wysłane zostaje lokalne rozgłoszenie. Wzywa ono klienta, na którym została zarejestrowana poszukiwana nazwa, do odpowiedzi wskazującej jego adres.

Techniki odwzorowania według Microsoftu

Oprogramowanie klienckie firmy Microsoft pozwala korzystać z dodat­kowych metod odwzorowywania nazw NetBIOS. Zaczynają się one od przedstawionego tu kroku 5. Oprogramowanie innych firm kończy w tym miejscu próby odwzorowania.

5. Nazwa NetBIOS może zostać odnaleziona w pliku LMHOSTS komputera. Wówczas wykorzystywany jest adres IP odnaleziony w tym pliku.

6. Nazwa NetBIOS może zostać odnaleziona w lokalnym pliku HOSTS kompu­tera. Wówczas wykorzystywany jest adres IP z tego pliku.

7. Ostatnim krokiem jest przesłanie zapytania do serwera DNS, prowadzące do określenia, czy posiada on zapis dotyczący poszukiwanej nazwy NetBIOS. Wówczas będzie wykorzystany adres zwrócony przez serwer DNS.

Jeżeli wszystkie te metody zawiodą komunikat o błędzie informuje inicjującego proce­durę klienta, że nazwa NetBIOS nie została odnaleziona.

Transakcje w sieciach NetBIOS

Wykorzystywanie nazw NetBIOS wiąże się z następującymi transakcjami:

· rejestracje nazw,

· odnajdywanie nazw,

· zwolnienia nazw.

Rejestracje nazw NetBIOS

Rejestracja nazw NetBIOS następuje zawsze przy uruchamianiu stacji NetBIOS. Każda nazwa, którą stacja ma zarejestrować, jest albo rozgłaszana w sieci, albo też wysyłana bezpośrednio do serwera NBNS. Zależy to od konfiguracji typu węzła. Jeżeli rejestracja, dotyczy nazwy jednostkowej, nie może ona być taka sama jak jedna z zarejestrowanych wcześniej.
W przypadku wystąpienia takiej sytuacji, stacja rejestrująca nazwę otrzymuje komunikat o braku potwierdzenia czynności.

Serwer nazw NetBIOS pozwala na rejestrowanie czterech typów nazw:

• Jednostkowa (Unique). Rejestracja nazwy tego rodzaju może zostać przepro­wadzona wyłącznie dla jednego adresu IP: Próba powtórzenia jej rejestracji przez inną stację kończy się niepowodzeniem i komunikatem o braku potwierdzenia.

• Grupowa zwykła (Normal Group), Nazwa tego typu nie jest rejestrowana dla określonej stacji czy grupy stacji. Określa ona jedynie, że grupa zwykła istnieje i jest powiązana z adresem ograniczonego rozgłaszania 255.255.255.255.

• Wieloprzyłqczeniowa (MuItiHomed). Tego rodzaju niepowtarzalnej nazwie przy­porządkowana jest pewna liczba adresów. Określa ona stację wyposażoną w kilka kart sieciowych powiązanych z protokołem TCP/IP wyposażonym w obsługę NetBIOS. Każda nazwa wieloprzyłączeniowa może zostać skojarzo­na z co najwyżej 25 adresami IP.

• Nazwa domeny (Domain Name). Również ta nazwa NetBIOS może obejmować do 25 adresów IP. Typ ten jest wykorzystywany do oznaczania stacji, z których wszystkie zapewniają identyczną usługę. Przykładem może być uwierzytelnianie logowania w domenie Windows NT.

Odnajdywanie nazw NetBIOS

Odnajdywanie nazwy NetBIOS następuje za każdym razem, kiedy klient NetBIOS wy­maga odwzorowania nazwy na adres IP. W zależności od konfiguracji typu węzła, żądanie odnalezienia nazwy przekazywane jest do serwera NBNS tub trafia do sieci jako lokalne rozgłoszenie. Odpowiada na nie serwer lub stacja, do której należy odpo­wiednia nazwa.

Zwolnienia nazw NetBIOS

Zwolnienie nazwy NetBIOS następuje wtedy, gdy aplikacja lub usługa, dla której nazwa została zarejestrowana, kończy swoje funkcjonowanie. Czynność ta towarzyszy między innymi wylogowaniu użytkownika z sieci.
W momencie; gdy użytkownik uruchamia proces opuszczania sieci, nazwa NetBIOS, taka jak np. UZYTKOWNIK[03], ulega zwolnieniu, ponieważ użytkownik nie jest już dłużej obecny w sieci. Podczas ponownego logowania, nazwa NetBIOS jest rejestrowana dla adresu IP stacji, z której. użytkownik korzysta. Usługa przenoszenia komunikatów w każdej chwili może odnaleźć użytkow­nika, nawet jeżeli zaloguje się on przez inny komputer.

Serwery nazw NetBIOS

Serwery nazw NetBIOS pełnią rolę punktu rejestracyjnego dla klientów NetBIOS. Klient przesyła określone w swojej konfiguracji nazwy NetBIOS i adresy IP do - również po­danego w jego konfiguracji - serwem nazw. Serwer albo wprowadza kombinacje nazw i adresów do swojej bazy danych, albo zwraca komunikat o braku potwierdzenia reje­stracji (Not Acknowledged). W przypadku otrzymania takiego komunikatu, zadaniem klienta jest odpowiednia do tej sytuacji reakcja. Jeżeli brak potwierdzenia dotyczy naz­wy komputera, ze względu na powtórzenie nazwy w sieci wstrzymywane są wszystkie usługi TCP/IP. Jeżeli dotyczy to jedynie nazwy użytkownika, komunikat o braku twierdzenia może zostać zignorowany. Oznacza to przypadek zalogowania jednego użytkownika na co najmniej dwóch stacjach.

Zaletą serwera nazw NetBIOS jest obsługa klientów o dynamicznie konfigurowanych adresach IP. W przypadku przypisania klientowi nowego adresu, rejestruje on nazwę wraz ze zmienionym adresem.

Usługi serwera nazw redukują również ruch w sieci. Kiedy pojawia się potrzeba odwzorowania nazwy, klient wysyła pakiet skierowany do serwera. Jest to znacznie bardziej efektywne niż korzystanie z rozgłoszenia obejmującego cały lokalny segment, który musi zostać sprawdzony przez każdą z obecnych w nim stacji.

Najpowszechniej znaną implementacją serwem nazw NetBIOS jest

Windows Internet Name Sernice (WINS) w Windows NT/2000.

Porównanie serwerów NBNS i DNS

Chociaż oba z przedstawionych systemów odwzorowywania nazw prowadzą do określenia adresu IP stacji na podstawie jej nazwy, istnieją między nimi istotne różnice.

· Nazwy NetBIOS podlegają rejestrowaniu w sieci. Jeżeli nazwą rejestrowaną jest jednostkowa nazwa NetBIOS, nie może ona dublować się z zarejestrowaną wcześniej. Jeżeli nazwa się powtarza, rejestracja nie nastąpi.

· Serwery DNS mogą korzystać z aliasów, co pozwala przypisać wiele nazw logicznych do jednego adresu IP dla tej samej usługi.

· Nazwy NetBIOS mogą być automatycznie rejestrowane na serwerze nazw NetBIOS. Serwery DNS wymagają obecnie ręcznego uzupełniania i korygowania wszystkich zapisów.

· Osobna nazwa NetBIOS jest przypisywana każdej usłudze realizowanej przez stację. Pojedynczy komputer może zarejestrować wiele takich nazw.
DNS wymaga pojedynczego wpisu dla pojedynczej stacji. Dodatkowe zapisy (jak Mail Exchanger) wskazują na specjalne usługi realizowane przez stację.

· Po skonfigurowaniu replikacji NBNS, serwery nazw NetBIOS mogą wymieniać jedynie zmodyfikowane zapisy. Serwery nazw wykonują początkowo pełną replikację prowadzącą do synchronizacji utrzymywanych przez nie baz danych. Od tego momentu przesyłane są jedynie zapisy nowe i uaktualnione. Serwery DNS wymagają przesłania całej informacji o strefie
z serwera głównego do serwera podległego przy każdym żądaniu aktualizacji.

· Dzięki funkcji automatycznej rejestracji serwery NetBIOS mogą zapewnić obsługę stacji zmieniających swoje adresy IP w sprawniejszy sposób niż serwery DNS, wymagające ręcznych zmian w konfiguracji.

Niezależnie od przedstawionych różnic, korzystanie w sieci z obu tych systemów od­wzorowywania nazw wiąże się z dodatkowym jej obciążeniem. Obecnie tworzony jest nowy system nazw, który zapewni automatyczną rejestrację i aktualizowanie nazw. Jest on określany jako dynamiczny DNS .

Pliki konfiguracyjne TCP/IP

W trakcie opisywania zasad odwzorowywania logicznych nazw stacji można było zau­ważyć, że w konfiguracji protokołu TCP/IP istotną rolę pełni kitka plików tekstowych.

W systemie LJNIX pliki te są przechowywane w katalogu /etc,
a na klientach Win­dowsNT- w katalogu

%systemroot3\system32\drivers\etc.

Lista plików związanych z opisywanymi tu zagadnieniami obejmuje pliki: · HOSTS,

NETWORKS,

SERVICES,

PROTOCOL,

LMHOSTS (tylko oprogramowanie klientów Microsoft),

RESOLV.CONF.

HOSTS

Plik HOSTS jest wykorzystywany przez TCP/IP do odwzorowywania nazw stacji na adres IP. Jego składnia jest następująca:

127.0.0.1 localhost

102.54.94.97 rhino.acme.com

38.25.63.10 x.acme.com

172.16.2.16 sideshowbri brian instructor

Jak widać z powyższego, stacja o nazwie sideshowbri może zostać odnaleziona pod adresem IP 172.16.2.16. Dodatkowe nazwy w tym samym wierszu konfiguracyjnym to aliasy. Mogą one być wykorzystywane do odwoływania się do tej samej stacji zamiast sideshowbri.

Ostrzeżenie

Jak wcześniej to przedstawiono, HOSTS jest jednym z pierwszych pli­ków wykorzystywanych w procesie odwzorowywania hostnames. Niepra­widłowe podanie w tym pliku adresu IP może doprowadzić do całkowitej utraty możliwości połączenia ze stacją, nawet wówczas, gdy informacja o niej przechowywana na serwerze DNS jest prawidłowa.

---