Odwzorowywanie 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żli- wość wzajemnego odnalezienia się. W sieci TCP/IP każdej stacji przypisuje się reprezentujący ją adres 1P. Protokołem używanym do odwzorowania adresu IP do adresu MAC karty sieciowej jest ARP.
Warto pamiętać, że faktyczne zaistnienie komunikacji zawsze wymaga odwzoro- wania adresu IP do adresu MAC karty sieciowej.
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.
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ą odwzorowa- nia nazw NetBIOS, aplikacje Winsock - odwzorowania hostnames.
Po określeniu dla danej nazwy adresu IP wykorzystywany jest protokół ARP w celu uzy- skania 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 wyko- rzystywanego 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 hostname resolution towarzyszyła Internetowi od jego początków. Wówczas informacje o nazwach stacji (czyli host names) były przechowy- wane w jednym centralnym pliku HOSTS.TXT. Sieciowe Centrum Informacyjne (NIC) rejestro- wał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 sys- temie. 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 kopia 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 wymagał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ąpie- nia centralnej bazy danych rozwiązaniem typu rozproszonego. Miało ono pozwolić każdej orga- nizacji na zarządzanie własnym systemem nazw stacji.
Przestrzeń nazw domen
Przestrzeń nazw domen (ang. Domain Name Space) jest drzewiastą strukturą obejmującą
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 prowadzonych przez organizacje, druga oparta jest na dwuliterowych oznaczeniach krajów, w których poszcze- gólne organizacje się znajdują.
Poniżej znajdują się domeny wysokiego poziomu obecnie wykorzystywane.
Kolejny poziom hierarchii, zawierający konkretne stacje i dalsze poddomeny, tworzą do- meny drugiego poziomu (ang. second-level domains).
ALTAVISTA i ALPHA to poddomeny w domenie drugiego poziomu DIGITAL.COM. Przeglą- danie stron WWW na serwerze w domenie ALTAVISTA wymaga wpisania w przeglądarce www.altavista.digital.com — to tzw. ujednolicony adres zasobu (ang. URL, universal resour- ce locator) odpowiadający temu ośrodkowi.
Nazwa stacji, obejmująca pełną nazwę domeny, jest określana terminem zupeł- nej lub w pełni kwalifikowanej nazwy domeny (ang. FQDN - fully qualified domain name).
Siedząc przy innej stacji w domenie altavista.digital.com, możemy odwoływać się do tego samego serwera, korzystając jedynie z jego samodzielnej nazwy - czyli www. Wykorzystanie nazwy FQDN daje gwarancję, że pełna ścieżka do podanej stacji zostanie poprawnie rozpoznana przez aplikację.
W Internecie nie można używać dowolnych nazw domen drugiego poziomu. Każ- da nazwa musi zostać zarejestrowana w InterNIC. Należy jednocześnie liczyć się z tym, że wybrana nazwa została już wykorzystana.
Proces odwzorowywania nazwy stacji
Proces prowadzący do określenia adresu IP na podstawie nazwy stacji wygląda w sposób następujący:
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?
Dla stacji opartych na oprogramowaniu Microsoftu dostępne są dodatkowe mechanizmy odwzorowywania nazw, opisane w poniższych punktach (zależność od Microsoftu wiąże się z zależnością nazw stacji od nazw NetBIOS'u). W stosunku do stacji-klientów innych producentów metody te sygnalizują niemożność odwzorowania nazwy (jeżeli nie została ona już odwzorowa- na w trzech pierwszych krokach).
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?
Kiedy żadna z tych metod określania adresu IP stacji docelowej nie zakończy się powo- dzeniem, 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 za- wiera wszystkie przyporządkowania nazw stacji do adresów IP w Internecie. Pozwala więc od- wzorować dowolną nazwę stacji w jej adres IP.
Klienci odwzorowania to oprogramowanie kliencie, które wymaga odwzorowania nazwy na adres IP. Funkcje klienta odwzorowania są albo częścią aplikacji wywołującej, albo też uru- chomione 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 została odnaleziona,
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. Ter- min strefa oznacza część przestrzeni nazw domen, za który odpowiedzialny jest konkretny ser- wer nazw. Pliki danych dla strefy są przechowywane lokalnie na podstawowym serwerze.
Wszystkie modyfikacje w tych plikach mogą być przeprowadzane wyłącznie na tym serwe- rze. Strefa obsługiwana przez podstawowy serwer nazw może obejmować więcej niż jedną do- menę. Może on zarządzać poddomenami w określonej domenie albo też przechowywać pliki związane z kilkoma różnymi domenami drugiego poziomu.
Wielu użytkowników zakłada, że plik strefy odpowiada zawsze domenie. Nie musi to jed- nak być prawdą. Załóżmy, że firma XYZ, korzystająca z domeny XYZ.com, rejestruje poddome- ny Sprzedaz, Badania i Marketing. Strefa może obejmować domenę XYZ.com i trzy poddomeny.
Można jednak utworzyć osobne strefy dla wszystkich lub jedynie wybranych poddomen.
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 po- mocniczy 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 samymi danymi strefy.
Potrzeba przyspieszenia odwzorowywania w ośrodku odległym przez utwo- rzenie w nim dodatkowego serwera nazw.
Potrzeba zmniejszenia awaryjności układu przez utworzenie dodatkowego ser- wera zapewniającego utrzymanie możliwości odwzorowywania nawet w przypadku 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 bezpośrednio – są jedynie kopiami plików przechowywanych na serwerach podstawowych. Stąd też stosowa- ne 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 podstawowe (primary) serwery nazw pracują jako serwery główne (master), również serwer pomocniczy (se- conda/y) może pełnić tę rolę. Sytuacja taka może wyniknąć z możliwości wykorzystywanych łączy sieciowych.
Sytuacja, kiedy pomocniczy serwer nazw powinien funkcjonować jako główny serwer.
Łącze T1 - 1544 Mb/s
W konfiguracji serwera pomocniczego wskazywany jest adres IP serwera głównego (ma- ster). Podczas inicjalizacji komunikuje się on ze wskazanym serwerem głównym i inicjuje prze- sył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ą stosun- kowo niewielką przepustowość. Zamiast serwera pomocniczego, który wymaga regularnego przesyłania pełnej informacji o strefie, może zostać utworzony jedynie serwer buforujący. Prze- syłane są wówczas jedynie faktycznie użyteczne dane. W buforze przechowywane są wtedy in- formacje 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 ad- res 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.
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ętrz- nego systemu DNS tak, aby zapytania były przekazywane do serwera DNS zapory. Ich kierowa- nie poza zaporę nie jest dopuszczalne. Jedynym komputerem, który może kierować zapytania
do sieci zewnętrznej, jest sama zapora. Użycie zapytania rekurencyjnego pozwala systemowi firewall przekazać je do wskazanego w konfiguracji serwera nazw, a następnie zwrócić odpo- wiedź w postaci adresu IP do stacji inicjującej.
Zapytania iteracyjne
Zapytanie iteracyjne nakłada na serwer nazw wymóg podania klientowi jedynie najlepszej dostępnej odpowiedzi. Odpowiedzią może być zarówno adres IP po- szukiwanej stacji (lub informacja o braku możliwości odwzorowania), jak i wska- zanie innego serwera DNS, który może dostarczyć adres IP odpowiadający po- szukiwanej nazwie.
W celu odwzorowania nazwy www.altavista.digital.com wykonane zostały następujące kroki:
1. Klient DNS wysyła do swojego serwera DNS rekurencyjne zapytanie o adres IP od- powiadający nazwie www.altavista.digital.com.
2. Serwer DNS nie ma odpowiedzi w swoim buforze ani też wskazania w konfiguracji, 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 itera- cyjne, 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ą przechowywane w osobnym pliku strefy na osobnym serwerze nazw, serwer DNS domeny DIGI- TAL.COM zwróci adres serwera nazw odpowiadającego za domenę ALTAVI- STA.DIGITAL.COM.
8. Lokalny serwer nazw wysyła do serwera nazw ALTAVISTA.DIGITAL.COM zapytanie o www. altavista. digital. com.
9. Serwer ALTAVISTA.D1GITAL.COM zwraca adres IP stacji www.altavista.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.alta-vista, di- gital, com w swojej pamięci podręcznej. Po utworzeniu odpowiedniego wpisu prze- kazuje adres IP do klienta, który zainicjował procedurę.
Zapytania odwrotne
Zapytanie odwrotne (ang. inverse query) służy do odnalezienia pełnej kwalifikowanej na- zwy domeny (FQDN) odpowiadającej określonemu adresowi IP. Zamiast określania adresu na podstawie nazwy stacji, wyszukujemy więc nazwę stacji odpowiadającą znanemu 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 interne- tową nazwę.
Jest to również wykorzystywane przy ustalaniu reguł ograniczających dostęp do określo- nych ośrodków dla zapory firewall. Jeżeli zostało ustalone, że użytkownicy nie powinni uzyski- wać dostępu do ośrodka www.giupie-strony.com, zapora może zostać dodatkowo skonfigurowa-
na do przeprowadzania wyszukiwań odwrotnych. Zabezpieczy to przed omijaniem przez użyt- kowników wprowadzonego ograniczenia przez bezpośrednie wpisanie adresu IP, jak 198.168.5.67.
ODWZOROWANIE NAZW NETBIOS
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 jedno- znacznie identyfikuje zasób NetBIOS w sieci. Ostatni bajt wskazuje typ usługi repre- zentowany przez zasób NetBIOS. Każda usługa NetBIOS posiada własny identyfikator, który jest wykorzystywany przy rejestracji jej nazwy.
Zarówno NetBIOS, jak i WinSock posiadają techniki identyfikacji aplikacji oraz usług uru- chomionych na serwerze lub kliencie. W systemie NetBIOS każdej usłudze przypisana jest nazwa zawierająca odpowiadający jej niepowtarzalny szesnasty znak. Oznaczenia usług są zunifikowane. 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 (naj- częś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 jednoznacznie nazwę NetBIOS lub numer gniazda. Zapewniona jest więc identyfikacja obu stron połączenia.
Zasoby NetBIOS mogą obejmować zarówno nazwy identyfikujące pojedyncze komputery, jak i nazwy grup komputerów.
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-node) 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-node, 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 skonfiguro- wanych do korzystania z jego usług. Jeżeli nie posiada on zapisu odpowiadają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ą rozgło- szenia. 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 konfi- guracja w sieci NetBIOS - ogranicza liczbę obciążających sieć rozgłoszeń, zachowując jednocześnie możliwość korzystania z nich w poszukiwaniu nazw nie zarejestrowa- nych na serwerze NBNS.
Oprogramowanie klienckie firmy Microsoft wykorzystuje jeszcze inną metodę odwzorowy- wania 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 (opisany w dalszej części rozdziału „Pliki konfiguracyjne TCP/IP").
Proces odwzorowywania nazw NetBIOS
Odwzorowanie nazw NetBIOS prowadzi do określenia adresu IP odpowiadającego określo- nej nazwie NetBIOS. Po ustaleniu adresu IP może on zostać zamieniony na adres MAC za po- średnictwem protokołu ARP.
Przykładowy proces odwzorowywania - klient został w tym przykładzie skonfigurowany hybrydowo.
Pierwsze sprawdzenie w procesie prowadzi do ustalenia, czy nazwa NetBIOS nie jest nazwą zarejestrowaną lokalnie. W takim przypadku w komu- nikacji wykorzystywany jest adres IP własny, czyli 127.0.0.1 - łącza sieciowe nie są wówczas wykorzystywane.
Przeglądana jest zawartość pamięci podręcznej nazw NetBIOS. Jeżeli doko- nane wcześniej odwzorowanie nazwy zostanie w niej odnalezione, wykorzystywany jest ten sam, co ustalony wcześniej, adres IP.
Zgodnie ze wskazaniem w swojej konfiguracji, klient wysyła zapytanie do serwera nazw NetBIOS. Jednym z zadań tego serwera jest przyjmowanie automa- tycznych rejestracji nazw NetBIOS wraz z towarzyszącymi im adresami IP, od skonfi- gurowanych do korzystania z niego klientów. Jeżeli odpowiednia nazwa zostanie od- naleziona w bazie danych serwera, klientowi zwracany jest odpowiedni adres IP.
Wysłane zostaje lokalne rozgłoszenie. Wzywa ono klienta, na którym została za- rejestrowana poszukiwana nazwa, do odpowiedzi wskazującej jego adres.
Oprogramowanie klienckie firmy Microsoft pozwala korzystać z dodatkowych me- tod odwzorowywania nazw NetBIOS. Zaczynają się one od przedstawionego tu kroku 5. Oprogramowanie innych firm kończy w tym miejscu próby odwzorowania.
Nazwa NetBIOS może zostać odnaleziona w pliku LMHOSTS komputera.
Wówczas wykorzystywany jest adres IP odnaleziony w tym pliku.
Nazwa NetBIOS może zostać odnaleziona w lokalnym pliku HOSTS kompute- ra. Wówczas wykorzystywany jest adres IP z tego pliku.
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 procedurę 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
Rejestracja nazw NetBIOS następuje zawsze przy uruchamianiu stacji NetBIOS. Każda na- zwa, którą stacja ma zarejestrować, jest albo rozgłaszana w sieci, albo też wysyłana bezpośred- nio 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 przy- padku wystąpienia takiej sytuacji, stacja rejestrująca nazwę otrzymuje komunikat o braku po- twierdzenia czynności.
Serwer nazw NetBIOS pozwala na rejestrowanie czterech typów nazw:
Jednostkowa (Unique). Rejestracja nazwy tego rodzaju może zostać przeprowa- dzona 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 po- wiązana z adresem ograniczonego rozgłaszania 255.255.255.255.
Wieloprzyłączeniowa (MultiHomed). Tego rodzaju niepowtarzalnej nazwie przypo- rzą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ć skojarzona z co najwyżej 25 adresa- mi 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 wszyst- kie 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 wymaga odwzorowania nazwy na adres IP. W zależności od konfiguracji typu węzła, żądanie odnalezienia nazwy przekazywane jest do serwera NBNS lub trafia do sieci jako lokalne rozgłoszenie. Odpo- wiada na nie serwer lub stacja, do której należy odpowiednia 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 rejestro- wana dla adresu IP stacji, z której użytkownik korzysta. Usługa przenoszenia komunikatów w każdej chwili może odnaleźć użytkownika, 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ż podanego w jego konfiguracji - serwera nazw. Serwer albo wprowadza kombinacje nazw i adresów do swojej bazy danych, albo zwraca komunikat o braku potwierdzenia rejestracji (Not Acknowledged). W przypadku otrzymania takiego komunikatu, zadaniem klienta jest odpowiednia do tej sytuacji reakcja. Jeżeli brak potwierdzenia dotyczy nazwy komputera, ze względu na powtórzenie nazwy w sieci wstrzymywane są wszystkie usługi TCP/IP. Jeżeli dotyczy to jedynie nazwy użytkowni- ka, komunikat o braku potwierdzenia może zostać zignorowany. Oznacza to przypadek zalogo- wania jednego użytkownika na co najmniej dwóch stacjach.
Zaletą serwera nazw NetBIOS jest obsługa klientów o dynamicznie konfigurowanych adre-
Usługi serwera nazw redukują również ruch w sieci. Kiedy pojawia się potrzeba odwzoro- wania 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óre musi zostać sprawdzo- ne przez każdą z obecnych w nim stacji.
Najpowszechniej znaną implementacją serwera nazw NetBIOS jest Windows Internet Na- me Service (WINS) w Windows NT. Konfigurowanie i rozwiązywanie problemów z serwerem WINS są opisywane w rozdziale 18., „IP w sieci ATM i konfigurowanie serwerów nazw NetBIOS".
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 jed- nostkowa 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 za- pisów.
Osobna nazwa NetBIOS jest przypisywana każdej usłudze realizowanej przez stację.
Pojedynczy komputer może zarejestrować wiele takich nazw. DNS wymaga pojedyn- czego 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ę prowa- dzą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, wy- magające ręcznych zmian w konfiguracji.
