Odwzorowywanie adresów IP i nazw logicznych. Odwzorowanie adresów IP na adresy MAC

Podobne dokumenty
Przestrzeń nazw domen (DNS) - Sieci komputerowe

Ogólnie biorąc, nie ma związku pomiędzy hierarchią nazw a hierarchią adresów IP.

Kierunek: technik informatyk 312[01] Semestr: II Przedmiot: Urządzenia techniki komputerowej Nauczyciel: Mirosław Ruciński

SIECI KOMPUTEROWE - BIOTECHNOLOGIA

Przesyłania danych przez protokół TCP/IP

ARP Address Resolution Protocol (RFC 826)

Plan wykładu. Domain Name System. Hierarchiczna budowa nazw. Definicja DNS. Obszary i ich obsługa Zapytania Właściwości.

Domain Name System. Kraków, 30 Marca 2012 r. mgr Piotr Rytko Wydział Matematyki i Informatyki UJ

Windows Serwer 2008 R2. Moduł 3. DNS v.2

Sieci komputerowe. Wykład 7: Warstwa zastosowań: DNS, FTP, HTTP. Marcin Bieńkowski. Instytut Informatyki Uniwersytet Wrocławski

Protokoły sieciowe - TCP/IP

Praca w sieci z serwerem

MODEL WARSTWOWY PROTOKOŁY TCP/IP

DNS - DOMAIN NAME SYSTEM

Wykład 3 / Wykład 4. Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak

Laboratorium - Przechwytywanie i badanie datagramów DNS w programie Wireshark

Skąd dostać adres? Metody uzyskiwania adresów IP. Statycznie RARP. Część sieciowa. Część hosta

Enkapsulacja RARP DANE TYP PREAMBUŁA SFD ADRES DOCELOWY ADRES ŹRÓDŁOWY TYP SUMA KONTROLNA 2 B 2 B 1 B 1 B 2 B N B N B N B N B Typ: 0x0835 Ramka RARP T

SIECI KOMPUTEROWE Adresowanie IP

Wykład 2: Budowanie sieci lokalnych. A. Kisiel, Budowanie sieci lokalnych

Serwer nazw DNS. Marcin Bieńkowski. Instytut Informatyki Uniwersytet Wrocławski

Plan wykładu. Domain Name System. Definicja DNS. Po co nazwy? Przestrzeń nazw domen Strefy i ich obsługa Zapytania Właściwości.

Instrukcja konfiguracji funkcji skanowania

Akademickie Centrum Informatyki PS. Wydział Informatyki PS

pasja-informatyki.pl

TCP/IP. Warstwa aplikacji. mgr inż. Krzysztof Szałajko

Zadanie1: Wykorzystując serwis internetowy Wikipedii odszukaj informacje na temat usługi WINS.

Protokół sieciowy Protokół

System operacyjny Linux

SMB protokół udostępniania plików i drukarek

Adres IP

ODWZOROWYWANIE NAZW NA ADRESY:

Projektowanie bezpieczeństwa sieci i serwerów

Konfiguracja DNS, część I (Instalacja)

OBSŁUGA I KONFIGURACJA SIECI W WINDOWS

Sieci komputerowe. Wstęp

Wykład Nr Sieci bezprzewodowe 2. Monitorowanie sieci - polecenia

Praca w sieci równorzędnej

Sieci komputerowe - administracja

Za dużo wpisów! Serwer nazw DNS. Marcin Bieńkowski

ABA-X3 PXES v Podręczna instrukcja administratora. FUNKCJE SIECIOWE Licencja FDL (bez prawa wprowadzania zmian)

Laboratorium Sieci Komputerowych - 2

Wykład 4: Protokoły TCP/UDP i usługi sieciowe. A. Kisiel,Protokoły TCP/UDP i usługi sieciowe

Instalacja Active Directory w Windows Server 2003

4. Podstawowa konfiguracja

Współpraca z platformą dokumentacja techniczna

Stos protokołów TCP/IP (ang. Transmission Control Protocol/Internet Protocol)

Forte Zarządzanie Produkcją Instalacja i konfiguracja. Wersja B

Podstawy działania sieci komputerowych

Zadanie z lokalnych sieci komputerowych. 1. Cel zajęć

Akademia Techniczno-Humanistyczna w Bielsku-Białej

Test sprawdzający wiadomości z przedmiotu Systemy operacyjne i sieci komputerowe.

Zarządzanie rolami jakie może pełnić serwer System prosi o wybór roli jaklą ma spełniać serwer.

Autorytatywne serwery DNS w technologii Anycast + IPv6 DNS NOVA. Dlaczego DNS jest tak ważny?

ZiMSK. VLAN, trunk, intervlan-routing 1

Wybrane działy Informatyki Stosowanej

Działanie komputera i sieci komputerowej.

BRINET Sp. z o. o.

Instrukcja 6 - ARP i DNS - translacja adresów

Plan wykładu. 1. Sieć komputerowa 2. Rodzaje sieci 3. Topologie sieci 4. Karta sieciowa 5. Protokoły używane w sieciach LAN 6.

Wybrane działy Informatyki Stosowanej

FTP przesył plików w sieci

Zestaw ten opiera się na pakietach co oznacza, że dane podczas wysyłania są dzielone na niewielkie porcje. Wojciech Śleziak

Protokoły zdalnego logowania Telnet i SSH

Windows W celu dostępu do i konfiguracji firewall idź do Panelu sterowania -> System i zabezpieczenia -> Zapora systemu Windows.

Model sieci OSI, protokoły sieciowe, adresy IP

Instrukcja do panelu administracyjnego. do zarządzania kontem FTP WebAs.

Klient-Serwer Komunikacja przy pomocy gniazd

Serwer druku w Windows Server

2014 Electronics For Imaging. Informacje zawarte w niniejszej publikacji podlegają postanowieniom opisanym w dokumencie Uwagi prawne dotyczącym tego

PRZESTRZE NAZW DOMEN DNS

ZiMSK dr inż. Łukasz Sturgulewski, DHCP

Zadanie1: Wykorzystując serwis internetowy Wikipedia odszukaj informacje na temat serwera DNS.

ZPKSoft Synchronizator

INSTRUKCJA OBSŁUGI DLA SIECI

PBS. Wykład Zabezpieczenie przełączników i dostępu do sieci LAN

router wielu sieci pakietów

Wprowadzenie 5 Rozdział 1. Lokalna sieć komputerowa 7

Obsługa poczty elektronicznej w domenie emeritus.ue.poznan.pl

1. Opis. 2. Wymagania sprzętowe:

ZASADY KORZYSTANIA Z PLIKÓW COOKIES ORAZ POLITYKA PRYWATNOŚCI W SERWISIE INTERNETOWYM PawłowskiSPORT.pl

Routing średniozaawansowany i podstawy przełączania

MASKI SIECIOWE W IPv4

Instrukcja dla instalatora systemu SMDP Enterprise/Professional

KONFIGURACJA INTERFEJSU SIECIOWEGO

Programowanie współbieżne i rozproszone

11. Autoryzacja użytkowników

Wykład 5: Najważniejsze usługi sieciowe: DNS, SSH, HTTP, . A. Kisiel,Protokoły DNS, SSH, HTTP,

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Kadry Optivum, Płace Optivum. Jak przenieść dane na nowy komputer?

Podziękowania... xv. Wstęp... xvii

INSTRUKCJA OBSŁUGI USTAWIEŃ DYNAMICZNIE PRZEDZIELANYCH ADRESÓW IP W URZĄDZENIACH SYSTEMU IP-PRO ORAZ REJESTRATORACH MY-DVR

KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED

POLITYKA PRYWATNOŚCI SERWIS:

Warsztaty z Sieci komputerowych Lista 5

Sieci komputerowe. Wykład 5: Warstwa transportowa: TCP i UDP. Marcin Bieńkowski. Instytut Informatyki Uniwersytet Wrocławski

ZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja

Polityka prywatności dla strony ELCEN Sp. z o.o. z siedzibą w Gdyni

System Kancelaris. Zdalny dostęp do danych

Rozwiązywanie nazw w sieci. Identyfikowanie komputerów w sieci

Transkrypt:

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żliwość 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 odwzorowania 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ą 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 hostname resolution towarzyszyła Internetowi 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 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ąpienia centralnej bazy danych rozwiązaniem typu rozproszonego. Miało ono pozwolić każdej organizacji na zarządzanie własnym systemem nazw stacji. Przestrzeń nazw domen Przestrzeń nazw domen (ang. Domain Name Space) jest drzewiastą strukturą obejmującą wszystkie domeny tworzące przestrzeń nazw Internetu. Początkiem drzewa jest domena określana angielskim terminem root, czyli korzeń.

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 poszczególne organizacje się znajdują. Poniżej znajdują się domeny wysokiego poziomu obecnie wykorzystywane. Kolejny poziom hierarchii, zawierający konkretne stacje i dalsze poddomeny, tworzą domeny 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 resource 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ż odwzorowana 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ę 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 kliencie, które wymaga odwzorowania nazwy 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 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. 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. 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.

Wielu użytkowników zakłada, że plik strefy odpowiada zawsze domenie. Nie musi to jednak być prawdą. Załóżmy, że firma XYZ, korzystająca z domeny XYZ.com, rejestruje poddomeny 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 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 samymi danymi strefy. Potrzeba przyspieszenia odwzorowywania w ośrodku odległym przez utworzenie w nim dodatkowego serwera nazw. Potrzeba zmniejszenia awaryjności układu przez utworzenie dodatkowego serwera 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ż 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 podstawowe (primary) serwery nazw pracują jako serwery główne (master), również serwer pomocniczy (seconda/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 (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ą stosunkowo niewielką przepustowość. Zamiast serwera pomocniczego, który wymaga regularnego 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 przechowywane 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. Tego rodzaju konfiguracja będzie wykorzystywana m.in. w przypadku sieci lokalnej oddzielonej 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 rekurencyjnego 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. 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 poszukiwanej stacji (lub informacja o braku możliwości odwzorowania), jak i wskazanie innego serwera DNS, który może dostarczyć adres IP odpowiadający poszukiwanej 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 odpowiadają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 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ą 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, 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ą 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 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 powinni uzyskiwać 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żytkownikó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 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. Zarówno NetBIOS, jak i WinSock posiadają techniki identyfikacji aplikacji oraz usług uruchomionych 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 (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 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 skonfigurowanych 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ł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. 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 (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ś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 - 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 komunikacji 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 dokonane 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 automatycznych 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 odpowiedni adres IP. Wysłane zostaje lokalne rozgłoszenie. Wzywa ono klienta, na którym została zarejestrowana poszukiwana nazwa, do odpowiedzi wskazującej jego adres. Oprogramowanie klienckie firmy Microsoft pozwala korzystać z dodatkowych metod 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 komputera. 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 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ć przeprowadzona 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łączeniowa (MultiHomed). Tego rodzaju niepowtarzalnej nazwie przyporzą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 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 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. Odpowiada 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 rejestrowana 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żytkownika, komunikat o braku potwierdzenia 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 swoją 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óre musi zostać sprawdzone przez każdą z obecnych w nim stacji. Najpowszechniej znaną implementacją serwera nazw NetBIOS jest Windows Internet Name 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 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.