13 Rozdzial 12 PHHJ6MRRUZXKRYO3 Nieznany

Rozdział 12

DHCP, WINS i DNS

Microsoft był pierwszą firmą, która wprowadziła na rynek produkty
oparte na propozycjach obu standardów internetowych, ale nie jest
ona ich prawnym właścicielem ani też zakres ich przydatności nie
ogranicza się wcale do środowisk windowsowych. DNS już od dawna
zajmuje w świecie T CP/IP poczesne miejsce.

DHCP i WINS są ściśle spokrewnionymi usługami ze świata sieci
Microsoft T CP/IP. Dlatego też omówimy je jako pierwsze. Potem
zajmiemy się usługą serwera DNS dla systemu Microsoft Windows
NT Server 4 i pokażemy, jak jej zintegrowanie z serwerem WINS
tworzy dynamiczny DNS.

Windows Internet Naming Service (WINS), czyli usługa nazw
internetowych dla Windows, oraz Dynamic Host Configuration
Protocol (DHCP), czyli protokół dynamicznej konfiguracji hosta,
są usługami typu klient/serwer, co oznacza, że w sieci istnieje
przynajmniej jeden serwer, świadczący owe usługi sieciowym
klientom. Swoje pierwsze serwery WINS i DHCP Microsoft
wprowadził w roku 1994 w serwerze Windows NT 3.5. Oczywiście,
nic nie stoi na przeszkodzie, by zarówno serwer, jak i stacja robocza
NT były klientami WINS i DHCP. T akże Windows 95, Windows
for Workgroups 3.11 z 32-bitowym stosem T CP/IP Microsoftu
(znanym również jako Wolverine) i Windows 3.1 z DOS-em,
korzystające z klienta Microsoft Network Client 3.0 lub LAN
Manager 2.2c, mogą działać jako klienci DCHP/WINS.

Na razie wymieniliśmy tylko produkty Microsoft, lecz są i inne.
Nowy stos sieciowy dla komputerów Macintosh, zwany
OpenT ransport, obsługuje DHCP; podobnie nowsze, wyposażone
w T CP/IP drukarki Apple. Ponadto liczne stosy T CP/IP dla
środowiska Windows/DOS od producentów trzecich, jak choćby PC-
T CP firmy FT P Software, wspierają DHCP i WINS. DHCP wspiera
również wiele systemów unixowych, na przykład HP/UX Hewletta
Packarda i IRIX firmy SGI.

464

Rozdział 12

Do czego służy WINS i DHCP ? Ujmując rzecz krótko, DHCP służy
do dynamicznego przydzielania informacji konfiguracyjnej T CP/IP
klientom sieciowym, zaś WINS rejestruje i rozwiązuje nazwy dla
klientów NetBIOS-owych opartych na T CP/IP. Wyjaśnienie takie
jest bardzo uproszczone, ponieważ każda z tych usług zapewnia
wiele innych korzyści. W rozdziale tym przyjrzymy się bliżej
zastosowaniom każdej z nich i poznamy zalecenia odnośnie ich
implementacji.

Uwaga: Usługa DNS Microsoftu pojawiła się po raz pierwszy
w narzędziach Resource Kit dla Windows NT 3.51. Była jednak
trudna w

konfiguracji, niezbyt solidna, wręcz uważana za

niestabilną. W porównaniu z nią serwer DNS dla NT Server 4,
przeznaczony do pracy przy dużym obciążeniu, stanowi zupełnie
nową jakość. Jest poza tym dużo łatwiejszy w konfiguracji, a to
dzięki nowemu graficznemu narzędziu o nazwie DNS Manager.

Serwer DNS, dołączony do serwera NT 4, pozwala temu ostatniemu
działać w charakterze standardowego serwera systemu nazw domeny
(DNS), kojarzącego nazwy hostów z adresami IP. Choć jest to
zwykle najbardziej odpowiedzialną funkcją serwera DNS, ma on
i

inne zastosowania. Mamy tutaj na myśli np. odwrotne

rozwiązywanie nazw, w którym klient żąda nazwy hosta należącego
do określonego adresu IP (oraz informacji o

poczcie

elektronicznej) - po to, by znaleźć lokalizacje hostów pocztowych
dla maszyn, wchodzących w skład domeny DNS. Serwer DNS,
należący do Windows NT , świadczy wszystkie standardowe usługi
tego typu, zaś jego specyficzną cechą jest integracja DNS i WINS,
zrealizowana jako wbudowany interfejs, pozwalający usłudze serwera
DNS przeglądać nazwy w bazie danych WINS. Uzyskane w ten
sposób informacje może następnie wykorzystać do przekształcania
nazw w adresy IP.

Celem niniejszego rozdziału jest poinformowanie Czytelnika o tych
usługach w zakresie koniecznym do poprawnego wdrożenia DHCP
i WINS w jego sieci. Rozdział omawia więc ich przeznaczenie,
instalowanie, konfigurację oraz zarządzenie, co w istocie obejmuje
większość zagadnień administracyjnych. Oddzielne omówienia
dotyczą współpracy z istniejącymi usługami unixowymi, sposobów

DHCP, WINS i DNS

465

na optymalne wykorzystanie ich możliwości oraz unikania
pewnych problemów-pułapek.

DHCP – Protokół dynamicznej konfiguracji hosta

Protokół dynamicznej konfiguracji hostów - DHCP - nie jest wcale
nowym wynalazkiem. W istocie jest on rozszerzeniem protokołu
BOOT P (zdefiniowanego pierwotnie w RFC 951), który stał się
standardem dla dynamicznego przydzielania adresów IP i zdalnego
ładowania bezdyskowych stacji roboczych. Wbrew powszechnemu
mniemaniu, DHCP nie został oficjalnie opracowany przez
Microsoft, a

przez grupę roboczą pod auspicjami Internet

Engineering T ask Force (IET F). Choć Microsoft był głównym
promotorem DHCP, to już wcześniej w społeczności internetowej
zaistniała ogólna zgoda co do tego, że jakaś wymyślniejsza metoda
dynamicznego przydzielania jest w IP niezbędna. Usługa taka nie
tylko uprościłaby wstępne konfigurowanie komputerów klientów,
lecz i znacznie obniżyłaby nakład pracy na administrowanie
adresami IP i związanymi z nimi informacjami, takimi jak maski
podsieci czy domyślne bramy. A są to tylko niektóre z przesłanek,
jakie złożyły się na to, że DHCP ujrzał światło dzienne. Pełna
definicja DHCP zamieszczona została w następujących Request for
Comments (RFC):

RFC 1533: Opcje DHCP i rozszerzenia firmowe BOOT P

RFC 1534: Współpraca między DHCP a BOOT P

RFC 1541: Protokół dynamicznej konfiguracji hostów (DHCP)

RFC 1542: Wyjaśnienia i rozszerzenia protokołu Bootsrap

Protocol (BOOT P)

Uwaga: Najbardziej interesującym z nich jest RFC 1541, który
definiuje bazową strukturę i podstawową funkcjonalność DHCP.
Dokument ten można znaleźć pod:

ftp://ds.internic.net/rfc/ rfc1541.txt

Ponieważ DHCP jest systemem klient/serwer, trzeba mieć
przynajmniej jedną maszynę z działającą usługą serwera DHCP
i jedną maszynę ze stosem T CP/IP obsługującym DHCP, by

466

Rozdział 12

otrzymać układ w pełni funkcjonalny. W większości przypadków,
z omawianym tu włącznie, serwer DHCP będzie serwerem Windows
NT korzystającym z usługi DHCP Server.

Uwaga: Ilość dostępnych na rynku serwerów DHCP rośnie nader
szybko. Wielu niezależnych sprzedawców produktów TCP/IP
opracowuje oprogramowanie dla serwerów DHCP w Windows NT,
Windows 3.x, Novella, a nawet dla systemów unixowych.

Omówienie usługi DHCP rozpoczniemy od niektórych jej założeń
projektowych, po czym przejdziemy do planowania instalacji,
instalowania usługi i

sposobu użycia Menedżera DHCP do

administrowania usługą. Administracja usługą DHCP polega na
tworzeniu oraz usuwaniu zakresów i na konfigurowaniu właściwości
poszczególnych zakresów. Zakres (scope) to zbiór adresów IP
zgrupowanych w jednym miejscu dla ułatwienia administracji.
Zakres może w razie potrzeby obejmować wszystkie adresy IP
w pojedynczej podsieci; można też podsieć podzielić na kilka
zakresów. W rozdziale zajmiemy się też obsługą bazy danych
DHCP, którą dla zachowania efektywności DHCP trzeba od czasu
do czasu wykonywać. Dowiemy się również czegoś o tych kluczach
Rejestru (Registry), których w samym Menedżerze DHCP nie da się
konfigurować.

Podstawowe założenia protokołu M icrosoft DHCP

Wśród celów, jakie Microsoft chciał osiągnąć wypuszczając na
rynek protokół DHCP, najważniejszym był ten, by administrację
sieci bazujących na T CP/IP uczynić

łatwiejszą do

zaimplementowania i utrzymania, co usprawniłoby m.in. MPS (
Microsoft Product Support) (służbę wsparcia technicznego), jako
że T CP/IP jest jednym z

najbardziej rozpowszechnionych

protokołów. Protokół T CP/IP jest zalecany dla średnich i dużych
sieci lokalnych (LAN), najkorzystniejszym dla sieci rozległych
(WAN) i

niezbędnym dla integracji z

sieciami UNIX-a lub

z Internetem.

A oto niektóre z

założeń projektowych microsoftowej

implementacji DHCP:

DHCP, WINS i DNS

467

Scentralizowana administracja podsieciami TCP/IP.

Wszystkie adresy IP, a wraz z nimi parametry konfiguracyjne
dla każdego z nich, przechowywane są w centralnej bazie danych
umieszczonej na serwerze DHCP.

Automatyczne przydzielanie adresów IP i konfiguracja

TCP/IP. W chwili, gdy komputer klienta startuje i uzyskuje
pierwszy dostęp do sieci, automatycznie otrzymuje swój własny
adres IP, maskę podsieci, domyślną bramę i adres IP serwera
WINS. Gdy komputer taki przeniesie się później do innej
podsieci, jak w

przypadku użytkownika z

komputerem

przenośnym, pierwotny adres IP i związane z nim informacje
konfiguracyjne są zwracane do pierwotnej puli dostępnych
adresów IP, a klientowi - w momencie ponownego uruchomienia
- przyznany zostaje nowy adres IP i nowa (związana z nim)
informacja konfiguracyjna.

Zwracanie niewykorzystanych adresów IP do puli

dostępnych adresów. Normalnie adresy IP przydzielane są
statycznie przez administratora sieci; tak przydzielone,
przechowywane są na kawałku papieru lub w lokalnej bazie
danych. Często lista ta dezaktualizuje się w miarę, jak klienci
przenoszą się do innych podsieci lub przydzielane są nowe adresy
IP bez zaznaczania tego na liście adresów IP. Oznacza to, że
niektóre z adresów zostaną stracone i nigdy nie będą użyte
ponownie. DHCP natomiast używa tu mechanizmu ściśle
ograniczonego czasowo, zwanego lease (dzierżawą), którą klient
musi odnawiać w dokładnie określonych odstępach czasu. Jeśli
dzierżawa wygaśnie i klient jej nie odnowi, jego adres zostanie
zwrócony do puli dostępnych adresów IP.

Zasada działania dzierżawy DHCP

Dzierżawy są fundamentalnym składnikiem całego procesu DHCP.
Każdy adres IP, oferowany przez serwer DHCP, ma związany z nim
lease period (okres dzierżawy). "Dzierżawa" jest tu odpowiednim
określeniem, ponieważ serwer DHCP nie daje klientowi adresu na
własność, a jedynie pozwala mu używać tej informacji przez
określony czas. Ponadto serwer lub klient może w dowolnej chwili
dzierżawę wypowiedzieć.

468

Rozdział 12

Ponieważ jednym z założeń DHCP było dynamiczne przydzielanie
adresów IP, to musi także istnieć metoda zwracania adresów do puli,
zwanej także scope (zakresem). Okres dzierżawy definiowany jest
niezależnie dla każdego zakresu, i może sięgać od kilku minut do
kilku miesięcy, a nawet (bardzo rzadko) na stałe.

W procesie ustalania swego adresu IP, korzystający z DHCP
komputer klienta przechodzi przez sześć poniższych stadiów:

Inicjalizacja: W momencie, gdy klient uruchamia swój stos

T CP/IP, wiąże się z adresem 0.0.0.0, ponieważ każda
maszyna w sieci IP musi mieć jakiś adres. Następnie do swej
lokalnej podsieci wysyła pakiet DHCP Discover. Jest to
pakiet rozgłoszeniowy (broadcast), skierowany do portu UDP
67, będącego portem serwera DHCP/BOOT P.

Wybieranie: Każdy serwer DHCP w lokalnej podsieci odbiera

ów pakiet DHCP Discover. Każdy z

serwerów, który

otrzymał to żądanie, sprawdza, czy ma jakiś wolny adres dla
zgłaszającego się klienta. Jeśli tak, to odpowiada pakietem DHCP
Offer

, zawierającym oferowany adres IP, maskę podsieci,

adres IP serwera DHCP, okres dzierżawy i wszelkie inne
szczegóły konfiguracji, określone dla danego zakresu DHCP.
Wszystkie serwery, które wysłały ofertę DHCP Offer,
rezerwują zaproponowane adresy. Dopóki rezerwacja nie
zostanie usunięta, nie można ich przydzielić innym klientom.
Pakiety DHCP Offer rozgłaszane są do portu UDP 68, który
jest portem DHCP/BOOT P klienta. Odpowiedź taka musi być
przesłana przez rozgłaszanie, ponieważ klient nie ma jeszcze
adresu IP, niezbędnego do adresowania bezpośredniego.

Zgłoszenie: Klient wybiera zwykle ofertę, która nadeszła jako

pierwsza, i odpowiada rozgłoszeniem pakietu DHCP Request.
Pakiet ten mówi serwerowi "T ak, chcę, byś mnie obsłużył.
Przyjmuję dzierżawę DHCP, którą mi dajesz". A ponieważ jest
to rozgłaszane, „słyszą” to wszystkie serwery DHCP w sieci.
Każdy z pozostałych serwerów, które przedstawiły ofertę nie
zaakceptowaną przez klienta, zwraca zarezerwowany dla niego
adres IP do puli adresów dostępnych. Klient może również użyć
żądania DCHP Request, aby poprosić serwer o dodatkowe
opcje konfiguracyjne, takie jak adres DNS lub bramy.

DHCP, WINS i DNS

469

Związanie: Gdy serwer otrzyma pakiet DHCP Request,

odpowiada klientowi pakietem DHCP Acknowledge, dostar-
czającym dodatkowych informacji, jakich klient mógłby
potrzebować. Również i on jest wysyłany przez rozgłaszanie.

O dnawianie: Gdy klient spostrzeże, że upłynęło już 50%

terminu dzierżawy, próbuje ją odnowić. Robi to wysyłając
ukierunkowany pakiet UDP do tego serwera, od którego
początkowo otrzymał informacje. Jest to pakiet DHCP
Request

- pytający, czy można nadal zachować informację

konfiguracyjną T CP/IP i odnowić dzierżawę. Jeśli serwer ten jest
osiągalny, na prośbę odpowie raczej pozytywnie, odsyłając
klientowi pakiet DHCP Acknowledge.

Ponowne związanie: Gdy dzierżawa osiągnie w przybliżeniu

87,5% okresu do wygaśnięcia, klient raz jeszcze próbuje ją
odnowić (jeśli nie została odnowiona przy poprzedniej próbie).
Jeśli i ta próba spełznie na niczym, klient spróbuje skontaktować
się z dowolnym innym serwerem DHCP w celu otrzymania
nowego adresu IP. Jeśli jakiś DHCP jest w stanie przydzielić mu
ważny adres IP, klient ponownie wchodzi w stan związania.
W przeciwnym razie, gdy dzierżawa jego aktualnego adresu IP
wygaśnie całkowicie, klient musi go zwrócić i ponownie wejść
w stan inicjalizacji, powtarzając cały proces od nowa.

Uwaga: Gdy klient DHCP usiłuje po raz pierwszy otrzymać adres
IP, poprzez sieć wymieniane są tylko cztery pakiety:

DHCP

Discover

DHCP

Offer

DHCP

Request

DHCP

Acknowledge

. Każdy z nich nie przekracza 400 bajtów. Widać

więc, że obciążenie nieinformacyjne, związane z

DHCP, jest

stosunkowo niskie.

Planowanie instalacji DHCP

Gdy dysponujemy niewielką siecią, w której wszystkie hosty
T CP/IP mogą korzystać z DHCP, to zainstalowanie serwera DHCP
będzie stosunkowo proste. Lecz to nie oznacza bynajmniej, że
można po prostu zainstalować składniki serwera DHCP
i pozostawić je samym sobie. Rozpoczynając planowanie, trzeba
wziąć pod uwagę dwa typy konfiguracji sieci. Pierwszy, to prosta

470

Rozdział 12

sieć z jedną tylko podsiecią, drugi - to sieć z wieloma podsieciami.
Najpowszechniejsza jest konfiguracja z wieloma podsieciami i na
niej właśnie skupimy naszą uwagę.

Najłatwiej jest pracować z jedną podsiecią. Wszystkie serwery
DHCP i WINS są wtedy zlokalizowane w tym samym segmencie,
niewiele więc potrzeba pracy administracyjnej. Utrzymywanie pliku
LMHOSTS

nie jest trudne, jeśli tylko klientów MS-DOS lub

Windows 3.x z oprogramowaniem Microsoft Network Client 3.0
nie ma zbyt wielu. Ponieważ wszystkie komputery są w jednej
podsieci, można użyć rozgłaszanego rozwiązywania nazw
i całkowicie zrezygnować zarówno z konfigurowania usługi WINS,
jak i utrzymywania pliku LMHOSTS. Jednak ze względu na
wydajność opłaca się skorzystać i tutaj z takich samych technik,
jak te, które zastosujemy w naszej przykładowej sieci - tak
jakbyśmy mieli kilka segmentów. Opłaci się to również wtedy, gdy
sieć się rozrośnie i trzeba ją będzie podzielić na oddzielne segmenty.

W przypadku sieci wielosegmentowej, czyli sieci z podsieciami,
przed zainstalowaniem DHCP na serwerze i zaimplementowaniem
DHCP na stacjach klientów konieczne jest zaplanowanie
następujących elementów:

Rutery: Jeśli nie planujemy instalowania serwera DHCP

w każdej z podsieci, to użyte rutery muszą obsługiwać RFC 1542,
co określane jest powszechnie jako wsparcie przekazywania
(relay) BOOT P/DHCP. Oznacza ono, że ruter potrafi poprawnie
przekazywać pakiety DHCP z podsieci bez serwera DHCP - do
tej odległej podsieci, która potrafi odpowiedzieć na wywołanie
DHCP. Dla niektórych starszych ruterów może to oznaczać
uaktualnienie. Jeśli nasze rutery nie wspierają tego RFC, to będą
one odrzucały pakiety sieciowe potrzebne do działania DHCP.
Jeśli rutery wspierają ów RFC, lecz mają problemy
z przyłączeniowością, to trzeba sprawdzić w dokumentacji, czy
konfiguracja domyślna przepuszcza lub odrzuca ten rodzaj
pakietów.

DHCP, WINS i DNS

471

Wskazówka: Jeśli nasze rutery nie wspierają RFC 1542, można
użyć DHCP Relay Agent (agenta przekazującego DHCP),
dołączonego do serwera NT. Więcej informacji o przekazywaniu
BOOTP/DHCP znajduje się w samym RFC 1542, który znaleźć
można pod adresem

ftp://ds.internic.net/rfc/rfc1542.txt

Konfiguracja WINS: Jeśli planujemy użycie DHCP do

automatycznego konfigurowania klientów WINS, należy ustawić
opcje 44 i 46 (omówione w podrozdziale "Praca z zakresami
DHCP" w dalszej części rozdziału). Opcja 44 określa adresy IP
serwerów WINS, które zostaną przydzielone klientom WINS,
podczas gdy opcja 46 podaje typ węzła T CP/IP, jaki zostanie
użyty. T yp węzła decyduje o mechanizmie, jaki protokół
T CP/IP zastosuje do obsługi żądania przekształcenia nazwy
NetBIOS-u w

adres IP protokołu T CP/IP. Dozwolonymi

nazwami węzłów są:

B-node (tryb rozgłaszania (Broadcast)): Rozwiązuje nazwy

korzystając z komunikatów rozgłaszanych. Jest to najgorsza
z możliwych opcji, ponieważ może dosłownie „zalać” segment
sieciowy komunikatami, pogarszając zdolność sieci do
przenoszenia właściwych danych i

skutecznie zmniejszając

szerokość pasma transmisyjnego w

danym segmencie.

Rozgłaszanie nie jest także przekazywane przez rutery, jeśli
zatem potrzebny zasób znajduje się po drugiej stronie rutera, to
nie zostanie odnaleziony. T en rodzaj węzła zalecamy dla małych
sieci o jednej podsieci - takiej, której nie obsługuje specjalnie
przydzielony administrator (korzystanie z rozgłaszania pozwala
w zasadzie wyeliminować konieczność utrzymywania pliku
LMHOSTS

lub bazy danych WINS, a

dla małych sieci

rozgłaszanie pochłania bardzo niewielką część szerokości
pasma). Inny, poważny argument za użyciem B-node wynika
z faktu, iż nawet wówczas, gdy serwer WINS lub DNS będzie
wyłączony lub nieosiągalny, komputery umieszczone w tym
samym segmencie nadal będą mogły odnaleźć siebie nawzajem.

P-node (tryb Point-to-point): Do rozwiązywania nazw używa

serwera nazw NetBIOS-owych (NBNS), takiego jak WINS,
korzystając przy tym z komunikacji typu point-to-point. T en

472

Rozdział 12

rodzaj komunikacji opiera się na bezpośrednich powiązaniach
adresów IP z innymi adresami IP. Mechanizm ten jest bardzo
efektywny, lecz jeśli NBNS przestanie działać, klienci zostaną
pozbawieni jakiegokolwiek sposobu zlokalizowania innych
maszyn w sieci.

M-node (tryb mieszany (Mixed)): Rozwiązując nazwy, używa

wpierw B-node (rozgłaszania), a jeśli ten zawiedzie, korzysta
z P-node (zapytań o nazwy). Metoda ta funkcjonuje w praktyce,
lecz ma tę samą wadę, co B-node - może „zalać” sieć
rozgłaszanymi komunikatami.

H-node (tryb hybrydowy (Hybrid)): Jest to domyślny typ

węzła przy ręcznym konfigurowaniu T CP/IP, o ile nie zostawi
się pustego pola adresu IP serwera WINS. Rozwiązując nazwy,
wpierw korzysta z P-node (zapytań o nazwy), a następnie - jeśli
usługa nazw jest niedostępna lub dana nazwa nie jest
zarejestrowana w bazie danych serwera WINS - z B-node
(rozgłaszania). Zalecamy ten właśnie typ węzła, ponieważ dla
znalezienia adresu IP zasobu używa wpierw połączenia point-to-
point, a dopiero gdy to się nie uda, odszukuje zasób korzystając
z rozgłaszania. Jest to najbardziej efektywny typ węzła, który
w praktyce gwarantuje odnalezienie żądanego zasobu nawet
wtedy, gdy plik LMHOSTS lub baza danych WINS nie zawiera
jego adresu.

Kilka serwerów DHCP: Jeśli planujemy zaimplementować

kilka serwerów DHCP (co w dużej sieci jest zalecane ze względu
na równomierne rozłożenie obciążenia i redundancję), to każdy
z nich musi mieć statycznie przydzielony adres IP. Adresy takie
trzeba wyłączyć z tworzonej dziedziny DHCP. Nie musimy mieć
obowiązkowo serwera DHCP w każdej podsieci. Wystarczy, by
nasz ruter był w stanie przekazywać wywołania DHCP poprzez
granice podsieci; jeśli nie obsługuje on wspomnianego wyżej
RFC, należy albo uaktualnić jego firmware, albo skorzystać
z DHCP Relay Agent (agenta przekazującego DHCP),
dostarczanego wraz z serwerem NT 4.

Statyczne adresy IP: Wszelkie adresy statyczne - takie jak

używane przez inne serwery DHCP, komputery bez DHCP,
rutery i przez nie-microsoftowych klientów RAS (Remote
Access Service), nie wspierających dynamicznego przydzielania

DHCP, WINS i DNS

473

adresów, a do podłączania się do naszej sieci używających PPP
(protokołu Point-to-Point) - muszą zostać wyłączone z zakresu
DHCP. Jeśli zapomnimy adresy te wykluczyć, to
najprawdopodobniej powstanie konflikt adresów,
uniemożliwiający naszym klientom komunikowanie się lub
nawet powodujący zawieszenie całej sieci (jeśli dotyczy to np.
rutera).

Replikacja bazy danych serwera DHCP: Funkcji takiej nie

ma w aktualnej implementacji, jeśli więc instalujemy kilka
serwerów DHCP obsługujących pojedynczy segment, to zakres
DHCP trzeba także podzielić na rozłączne dziedziny IP.

Kopiowanie zapasowe bazy danych serwera DHCP:

Ponieważ baza danych DHCP zawiera wszystkie zakresy DHCP
dla danego serwera oraz parametry konfiguracyjne, zalecane jest
wdrożenie jakiejś procedury kopiowania zapasowego. Normalnie
usługa DHCP automatycznie utrzymuje zapasową kopię bazy
danych i korzysta z niej, jeśli oryginał zostanie uszkodzony. Nie
należy jednak polegać wyłącznie na tym mechanizmie, lecz
regularnie zachowywać samą bazę danych, jak i pliki z katalogu
%SystemRoot%\

System32\DHCP\Backup\Jet.

Wskazówka: Jeśli mamy uszkodzony podstawowy plik bazy danych
i nie zostało to wykryte przez usługę DHCP, możemy wymusić
użycie kopii zapasowej redagując

Registry

Key

(Klucz

Rejestru).

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\

Services\DHCPServer\Parameters\RestoreFlag

ustawiamy na 1. Następnie restartujemy usługę DHCP za pomocą
następującego polecenia:

net

stop

dhcpserver

net

start

dhcpserver

Wygaśnięcie dzierżawy: Minimalny okres wygaśnięcia

dzierżawy powinien być dwukrotnie dłuższy od maksymalnego,
przewidywanego czasu wyłączenia serwera. Jeśli na przykład
planujemy rozbudować serwer w

ciągu weekendu, to czas

wygaśnięcia musi wynieść przynajmniej cztery dni. Zapobiegnie
to utracie przez klienta jego dzierżawy i

adresu IP, co

474

Rozdział 12

uniemożliwiłoby mu z

kolei komunikowanie się z

innymi

zasobami w sieci.

Wskazówka: Bezpieczne minimum dla czasu dzierżawy powinno
zależeć od fluktuacji w danej sieci. Jeśli mamy wielu użytkowników
z przenośnymi komputerami, częste rozbudowy komputerów lub
wiele przenosin pomiędzy podsieciami, to czas dzierżawy powinien
wynieść około dwóch tygodni. Pozwala to szybko zwracać adresy IP
do puli,

od razu udostępniając je do ponownego przydzielenia. Jeśli nasza
sieć jest raczej statyczna, można by użyć sześciomiesięcznego czasu
dzierżawy. Należy jedynie unikać dzierżaw nieograniczonych,
ponieważ adresy takie nigdy nie zostaną automatycznie zwolnione
i zwrócone do puli adresów IP.
Innym czynnikiem, jaki trzeba wziąć pod uwagę przy określaniu
czasu trwania dzierżawy, jest stosunek liczby komputerów do liczby
adresów IP. Jeśli na przykład mamy w sieci więcej maszyn niż
adresów, to należy rozważyć użycie znacznie krótszych dzierżaw,
takich jak godzina lub 30 minut. Sytuacja taka może wystąpić
wówczas, gdy podłączamy nasze biuro do Internetu i dysponujemy
ograniczoną ilością adresów IP, które trzeba udostępnić wszystkim
maszynom w sieci.

Jeśli planujemy implementację usługi Microsoft DHCP Server
w środowisku mieszanym (np. takim, w którym działa usługa
unixowego serwera DHCP innego producenta), to trzeba mieć na
uwadze, że klient Microsoftu nie wspiera wszystkich opcji
konfiguracyjnych DHCP. Dokładniej, klienci Microsoft DHCP
dysponują jedynie opcjami wymienionymi w tabeli 12.1 - wszelkie
inne, otrzymywane przez klienta opcje, są ignorowane i odrzucane.

Tabela 12.1. Opcje konfiguracyjne klienta DHCP Microsoftu

Nazwa

Typ danych O pis

DHCP, WINS i DNS

475

Maska
podsieci

adres
podsieci

Określa maskę podsieci T CP/IP, która
będzie używana przez klientów DHCP.
Uwaga: wartość tę można zadać jedynie
przy tworzeniu zakresu lub w opcji

Scope

Properties

DHCP Options

Ruter

tablica
adresów IP

Określa w preferowanej kolejności listę
adresów IP ruterów, które klient będzie
używał. Brama zdefiniowana lokalnie ma
nad nią pierwszeństwo.

Serwery DNS

tablica
adresów IP

Określa w preferowanej kolejności listę
serwerów nazw DNS dla klienta. Uwaga:
komputer wielobazowy (komputer
z więcej niż jedną zainstalowaną kartą
sieciową) ma tylko jeden taki adres; nie
może mieć po jednym adresie IP na każdą
z kart.

Nazwa

Typ danych O pis

Nazwa
domeny

łańcuch
znakowy

Określa nazwę domeny DNS, której klient
powinien używać przy rozwiązywaniu
nazw hostów z użyciem DNS-u.

WINS/NBNS

tablica
adresów IP

Określa w preferowanej kolejności listę
serwerów nazw NetBIOS-u (NBNS).

T yp węzła
WINS/NBT

bajt

Określa typ węzła dla konfigurowalnych
klientów NetBIOS-owych
(zdefiniowanych w

RFC 1001/1002).

Wartość: 1 określa B-node, 2 - P-node, 4
- M-node, 8 - H-node.
Uwaga: w

komputerach wielobazowych

typ węzła przydzielany jest komputerowi
jako całości, nie zaś poszczególnym
kartom sieciowym.

476

Rozdział 12

Identyfikator
zakresu
NetBIOS-u

łańcuch
znakowy

Określa identyfikator zakresu (scope
ID

) dla NetBIOS-u opartego na T CP/IP

(NBT ), zgodnie z

definicją w

RFC

1001/1002. Uwaga: w

komputerach

wielobazowych identyfikator zakresu jest
zasobem globalnym i nie jest przydzielany
poszczególnym kartom sieciowym.

Żądany adres

adres IP

Określa, że ma być używany predefinio-
wany adres IP klienta.

Okres
dzierżawy

adres IP

Określa w

sekundach czas od

początkowego przydzielenia adresu IP do
wygaśnięcia klientowi dzierżawy na ten
adres. Uwaga: wartość tę można ustawiać
tylko w opcji

Scope

Properties

DHCP

Options

T yp
komunikatu
DHCP

bajt

Określa typ komunikatu DHCP, przy
czym: 1 -

DHCPDISCOVER,

- DHCPOFFER,

- DHCPREQUEST,

- DHCPDECLINE,

- DHCPACK,

- DHCPNAK,

- DHCPRELEASE.

Nazwa

Typ danych O pis

Identyfikator
serwera

adres IP

Używany przez klientów DHCP do
wskazania, która z kilku ofert dzierżawy
została zaakceptowana, poprzez
włączenie tej opcji do komunikatu

DHCPREQUEST

wraz z

adresem IP

zaakceptowanego serwera DHCP.

Wartość
okresu
odnowienia
(T 1)

długie słowo

Określa w

sekundach czas od

początkowego przydzielenia adresu IP do
momentu, w którym klient musi przejść
do stanu odnawiania. Uwaga: wartości tej
nie można zadawać ręcznie, ponieważ
zależy ona od czasu dzierżawy
ustawionego dla całego zakresu.

DHCP, WINS i DNS

477

Wartość
okresu
ponownego
wiązania (T 2)

długie słowo

Określa w

sekundach czas od

początkowego przydzielenia adresu IP do
momentu, w którym klient musi przejść
do stanu ponownego wiązania. Uwaga:
wartości tej nie można zadawać ręcznie,
ponieważ zależy ona od czasu dzierżawy
ustawionego dla całego zakresu.

Identyfikator
klienta

słowo

Określa niepowtarzalny identyfikator
klienta DHCP.

Zarówno klient, jak i serwer DHCP Microsofta nie wspierają
nakładania opcji (option overlay). Jest to technika polegająca na
umieszczaniu dodatkowych opcji w niezajętym obszarze pakietu
DHCP. Jeśli zatem zamiast serwera DHCP Microsofta używamy
serwera DHCP innego producenta, to najważniejsze z naszego
punktu widzenia opcje konfiguracyjne należy umieścić na początku
listy - w przeciwnym bowiem wypadku mogłyby zostać odrzucone.
Klienci Microsofta wykazują także ograniczenia odnośnie wielkości
pakietów, które mogą poprawnie przetwarzać. Ograniczenie to
wynosi 312 bajtów, zatem wszystkie wybrane opcje muszą zmieścić
się w takim obrębie. T o samo odnosi się do przypadku, gdy
używamy serwera DHCP Microsofta do obsługi klientów DHCP
innych producentów: najważniejsze opcje konfiguracyjne należy
wybierać najpierw. Chociaż do wspierania klientów DHCP innych
wytwórców można użyć jeszcze dodatkowych opcji (wyliczonych
w T abeli 12.2), to ich z kolei nie będą wykorzystywać klienci
Microsoft DHCP.

Tabela 12.2. Opcje konfiguracyjne dla klientów DHCP innych

wytwórców

Nazwa

Typ danych O pis

Wypełnienie

bajt

Podaje, że dalsze pola z danymi będą wy-
równane do granicy słowa (16-bitowego).

Czas

długie słowo

Określa dla lokalnej podsieci różnicę
czasu względem UCT , Universal
Coordinate Offset Time) (uniwersalnego
czasu skoordynowanego) (w sekundach).

478

Rozdział 12

Serwery czasu tablica

adresów IP

Określa w preferowanej kolejności listę
serwerów czasu dla klienta.

Serwery nazw tablica

adresów IP

Określa w preferowanej kolejności listę
serwerów nazw dla klienta.

Serwery
kroniki

tablica
adresów IP

Określa w preferowanej kolejności listę
serwerów kroniki dla protokołu MIT _LCS
(Massachusetts Insitute of Technology,
Laboratory of Computer Science) UDP
(User Datagram Protocol) dla klienta.

Serwery
„cookie”

tablica
adresów IP

Określa w preferowanej kolejności listę
serwerów „cookie” (zdefiniowanych
w RFC 865) dla klienta.

Serwery LPR

tablica
adresów IP

Określa w preferowanej kolejności listę
serwerów zdalnego drukowania Line
Printer Remote (zdefiniowanego w RFC
1179) dla klientów.

Serwery
Impress

tablica
adresów IP

Określa w preferowanej kolejności listę
serwerów Imagen Impress dla klienta.

Serwery
lokalizacji
zasobów

tablica
adresów IP

Określa w preferowanej kolejności listę
zgodnych z RFC 887 serwerów lokalizacji
zasobów (Resource Location) dla klienta.

Nazwa hosta

łańcuch
znakowy

Określa nazwę hosta (maks. 63 znaki) dla
klienta. Uwaga: nazwa musi zaczynać się
od litery alfabetu, kończyć znakiem
alfanumerycznym i

może zawierać

jedynie litery, cyfry i kreski łączące.
Nazwa taka może być jeszcze uzupełniona
nazwą domeny DNS.

Nazwa

Typ danych O pis

Wielkość
pliku
startowego

słowo

Określa domyślną wielkość obrazu pliku
uruchomieniowego w

blokach 512-

oktetowych.

Plik zrzutu
post mortem

łańcuch
znakowy

Określa (w ASCII) ścieżkę dostępu do
pliku, w którym umieszczany będzie zrzut
pamięci klienta w wypadku awarii systemu

DHCP, WINS i DNS

479

lub aplikacji.

Serwer
wymiany

adres IP

Podaje adres IP serwera wymiany (swap)
dla klienta.

Ścieżka do
katalogu
głównego

łańcuch
znakowy

Określa (w ASCII) ścieżkę dostępu do
katalogu głównego klienta.

Ścieżka do
rozszerzeń

łańcuch
znakowy

Określa plik, zawierający informację
interpretowaną w taki sam sposób, jak
pole rozszerzeń firmowych w odpowiedzi

BOOTP

, z wyjątkiem tego, że odwołania

do etykiety (tag) 18 są ignorowane.
Uwaga: plik ten musi być dostępny dla
T FT P.

Przekazywani
e warstwy IP

bajt

Określa, czy pakiety IP powinny być dla
klienta dozwolone (1) lub niedozwolone
(0).

Nielokalny
ruting
źródłowy

bajt

Określa, czy pakiety datagramów
przekazywane według nielokalnej trasy
źródłowej powinny być dla klienta
dozwolone (1) lub niedozwolone (0).

Maska filtrów
reglamentacyj
nych

tablica
adresów IP

Określa w preferowanej kolejności listę
par złożonych z docelowych adresów IP
i

masek. Stosowana do filtrowania

nielokalnych tras źródłowych. Każdy
datagram z trasą źródłową, dla którego
adres następnego przeskoku nie zgadza się
z żadną pozycją listy, jest przez klienta
odrzucany.

Maksymalna
wielkość
ponownie
składanego
datagramu

słowo

Określa maksymalną wielkość datagramu,
który klient może na powrót złożyć.
Uwaga: wielkością minimalną jest 576
bajtów.

Nazwa

Typ danych O pis

Domyślny

bajt

Określa T T L, Time to Live (czas życia),

480

Rozdział 12

czas życia

jaki klient nadawać będzie wychodzącym
datagramom. Wartość ta musi być
zawarta pomiędzy 1 a 255 przeskoków.

Czas
dezaktualizacji
MT U dla
ścieżek

długie słowo

Określa w sekundach limit czasowy dla
dezaktualizacji wartości MT U (Maximum
Transmission Unit) dla ścieżek. Uwaga:
wartości MT U znajdowane są przy użyciu
mechanizmu zdefiniowanego w

RFC

1191.

T ablica „grup”
dla scieżek
Path MTU

tablica słów

Określa tablicę wartości MT U
(maksymalnej jednostki transmisyjnej),
która będzie używana przy wykonywaniu
operacji Path MTU (znajdowania MT U,
zdefiniowanej w

RFC 1191). Uwaga:

tablica jest uporządkowana od wartości
minimalnej (68) do maksymalnej.

Opcja MT U

słowo

Określa wielkość znalezionego MT U.
Uwaga: wartością minimalną jest 68.

Wszystkie
podsieci są
lokalne

bajt

Określa, czy klient ma zakładać, że
wszystkie podsieci w danej sieci używać
będą tej samej wartości MT U, jaka została
zdefiniowana dla podsieci lokalnej. Opcja
ta może być włączona (1) lub wyłączona
(0) - ten ostatni przypadek oznacza, że
niektóre podsieci mogą

używać

mniejszych wartości MT U.

Adres
rozgłaszania

adres IP

Określa adres IP, dla rozgłaszania którego
należy używać w lokalnej podsieci klienta.

Dowiedz się
o maskę

bajt

Wartość 1 określa, że klient powinien
użyć ICMP (Internet Control Message
Protocol) - w celu poinformowania się
o masce podsieci, natomiast 0 oznacza,
że klient nie powinien do tego celu
używać ICMP.

DHCP, WINS i DNS

481

Nazwa

Typ danych O pis

Dostawca
maski

bajt

Wartość 1 określa, że klient powinien
odpowiedzieć na pytanie ICMP o maskę
podsieci, natomiast wartość 0 oznacza, że
klient nie powinien na nie odpowiadać .

Dowiedz się
o ruter

bajt

Wartość 1 określa, że klient powinien
użyć mechanizmu zdefiniowanego w RFC
1256 w

celu poinformowania się

o ruterze. Wartość 0 oznacza, że klient
nie powinien korzystać z

tego

mechanizmu .

Adres do
negocjowania
o ruter

adres IP

Określa adres IP, pod który klient
wysyłać będzie żądania negocjowania
(solicitation) o ruter.

T rasa
statyczna

tablica
adresów IP

Określa w preferowanej kolejności listę
par adresów IP, jakie klient powinien
zainstalować w

swym cache'u rutingu.

Uwaga: wszystkie alternatywne trasy do
tego samego celu podawane są
w kolejności malejącej lub w kolejności
priorytetu. Pary te zdefiniowane są jako
adres IP celu/adresy IP ruterów.
Domyślny adres 0.0.0.0 jest dla trasy
statycznej adresem nielegalnym
i powinien

zostać zmieniony

przypadku, gdy z

ustawienia tego

korzystają nie-microsoftowi klienci
DHCP.

Kapsułkowani
e typu
„trailer”

bajt

Wartość 1 określa, że klient powinien
negocjować użycie „przyczep” (ang.
trailer, zdefiniowanych w RFC 893), czyli
nagłówków dołączanych z

tyłu

komunikatu, przy korzystaniu
z protokołu ARP. Wartość 0 oznacza, że
klient nie powinien używać „przyczep”.

Limit czasu

długie słowo

Określa w

sekundach czas

482

Rozdział 12

dla cache'a
ARP

przechowywania wpisów w cache'u ARP.

Nazwa

Typ danych O pis

Kapsułkowani
e Ethernetu

bajt

Określa, że klient powinien używać
kapsułkowania dla wersji 2 Ethernetu
(zdefiniowanej w RFC 894) lub IEEE
802.3 (zdefiniowanej w RFC 1042), jeśli
interfejsem sieciowym jest Ethernet.
Wartość 1 oznacza kapsułkowanie według
RFC 1042, zaś wartość 0 - według RFC
894.

Domyślny
czas życia

bajt

Określa domyślny T T L, jakiego klient
powinien używać przy wysyłaniu
segmentów T CP. (Uwaga: minimalną
wartością oktetu jest 1).

Okres
powtarzania
komunikatu
keepalive

długie słowo

Określa w sekundach czas, jaki klient musi
odczekać, nim wyśle komunikat keep-
alive

(podtrzymuje połączenie) do

połączenia T CP. (Uwaga: wartość 0
oznacza, że klient powinien wysłać
komunikat keep-alive tylko wtedy,
gdy zażąda tego aplikacja).

Keepalive
Garbage

bajt

Włącza (1) lub wyłącza (0) wysyłanie ko-
munikatów

keepalive

oktetem

danych garbage dla kompatybilności
z aplikacjami odziedziczonymi.

Nazwa
domeny NIS

łańcuch
znakowy

Łańcuch znaków ASCII określający
domenę NIS (Network Information
Service).

Serwery NIS

tablica
adresów IP

Określa w preferowanej kolejności listę
adresów IP serwerów NIS dla klienta.

Serwery NT P

tablica
adresów IP

Określa w preferowanej kolejności listę
adresów IP serwerów NT P (Network Time
Protocol) dla klienta.

Informacje

tablica

Informacja binarna, używana przez

DHCP, WINS i DNS

483

specyficzne
dla producenta

bajtów

klientów i

serwery do przekazywania

danych specyficznych dla producentów.
Serwery, które nie potrafią informacji tej
zinterpretować, ignorują ją, natomiast
klienci, którzy danych takich nie
otrzymują, próbują działać bez nich.

Nazwa

Typ danych O pis

NBDD dla
NetBIOS-u
opartego na
T CP/IP

tablica
adresów IP

Określa w preferowanej kolejności listę
adresów IP serwerów NBDD (NetBIOS
Datagram Distribution) dla klienta.

Czcionka
systemowa dla
X Windows

tablica
adresów IP

Określa w preferowanej kolejności listę
adresów IP serwerów czcionek X
Windows dla klienta.

Okno
systemowe X
Windows

tablica
adresów IP

Określa w preferowanej kolejności listę
adresów IP serwerów menedżerów okien
systemowych X Windows dla klienta.

Nazwa
domeny NIS+

łańcuch
znakowy

Określa w preferowanej kolejności listę
nazw domen NIS+.

Serwer NIS+

tablica
adresów IP

Określa w preferowanej kolejności listę
serwerów NIS+.

255 Koniec

bajt

Określa koniec pakietu DHCP.

Instalowanie usługi DHCP

Usługę DHCP Server można zainstalować poprzez aplet

Netw ork

w Panelu sterowania. Jednak przed rozpoczęciem instalowania jej
na własnym serwerze należy sprawdzić, czy w sieci istnieją jeszcze
inne serwery DHCP. Mogą to być serwery Windows NT lub UNIX-
a.

Uwaga: Aby zainstalować usługę

DHCP

Server

, trzeba być

członkiem grupy Administrators komputera, na którym usługa
będzie instalowana.

Podczas instalacji należy wykonać następujące czynności:

484

Rozdział 12

1. Wywołujemy aplet

Netw ork

Panelu sterowania.

2. Wybieramy kartę

Serv ices

i klikamy przycisk

Add

Z wyświetlonej listy usług wybieramy

Microsoft DHCP Serv er.

Uwaga: Jeśli TCP/IP niej jest jeszcze zainstalowany, to zostanie on
dodany automatycznie w trakcie instalowania usługi serwera
DHCP.

Wskazówka: By umożliwić zdalne konfigurowanie DHCP za
pośrednictwem SNMP, należy zainstalować również usługę SNMP.

4. Klikamy

. Gdy pojawi się odpowiedni monit, wprowadzamy

ścieżkę dostępu do plików dystrybucyjnych (na przykład
f:\i386

) i klikamy przycisk

Continue

. Program instalacyjny

ostrzeże, że serwery DHCP nie mogą być jednocześnie klientami
DHCP i że każda karta sieciowa, skonfigurowana jako klient
DHCP, musi być zrekonfigurowana. Komunikat ten pokazano
na rysunku 12.1.

5. Klikamy

, po czym zamykamy okno konfiguracyjne

Netw ork

(Sieæ) przyciskiem

Close

6. Jeśli jedna lub więcej kart sieciowych w serwerze zostało tak

skonfigurowanych, by pobierały swe adresy IP z serwera DHCP,
lub gdy jednocześnie z

usługą serwera DHCP instalujemy

T CP/IP, zostaniemy poproszeni o skonfigurowanie ustawień dla
T CP/IP w każdej karcie sieciowej systemu.

7. Restartujemy system. W trakcie jego ponownego uruchamiania

usługa serwera DHCP powinna zostać uaktywniona.
W

przeciwnym razie należy przeanalizować komunikaty

o błędach w dzienniku zdarzeń (event log) systemu.

Rys. 12.1. Karty

sieciowe

w serwerze DHCP

nie mogą być

skonfigurowane

dla dynamicznego

otrzymywania

adresów IP.

DHCP, WINS i DNS

485

Zarządzanie serwerem DHCP za pomocą DHCP M anager

Interfejs do zarządzania usługą DHCP zapewnia DHCP Manager.
Jego podstawowym zadaniem jest praca z zakresami (scope).
W podrozdziale tym omówimy tworzenie, usuwanie, uaktywnianie
i deaktywowanie zakresów. Następnie pokażemy, jak zarządzać
klientami DHCP, a więc jak zarządzać dzierżawami i rezerwacjami
naszych klientów, a także jak dla zarezerwowanych klientów
ustawiać indywidualne właściwości DHCP, czyli właściwości,
odmienne od analogicznych, zdefiniowanych dla zakresu jako
całości. Na zakończenie omówimy niezbędne administrowanie bazą
danych DHCP. Wszystko to powinno wystarczająco przygotować
do obowiązków administratora dobrze zarządzanej sieci T CP/IP.

DHCP Manager instalowany jest grupie programów

Administrativ e

Tools

(Narzędzia administracyjne) w czasie instalowania usługi

DHCP i

wymaga uprawnień administracyjnych. Za pomocą

Menedżera DHCP można robić wszystko, z

wyjątkiem

zatrzymywania i uruchamiania samej usługi DHCP - czynimy to
w aplecie

Serv ices

Panelu sterowania, wybierając jako obiekt

sterowany usługę

Microsoft

DHCP

Serv er

. Alternatywnie,

z wiersza poleceń wydajemy następujące polecenia:

net

stop dhcpserver

net

start dhcpserver

Zarządzanie zakresami DHCP

Zanim serwer DHCP zacznie naszym klientom DHCP przydzielać
adresy IP i odpowiednie opcje konfiguracyjne, trzeba mu stworzyć
tak zwany zakres DHCP. Zakres ten jest sercem usługi serwera
DHCP i określany bywa albo w oparciu o grupę adresów IP, albo
w oparciu o podsieć. W najprostszym przypadku może obejmować
tylko jedną podsieć, lecz w jej obrębie można zdefiniować grupę
adresów IP, które będą wykorzystywane jako podstawa do
przydzielania klientom DHCP adresów IP, a także maskę podsieci,
adresy IP wyłączone z zakresu, czas trwania dzierżawy, nazwę
zakresu i komentarz opisujący zakres. Opiszemy tutaj, jak tworzyć,
usuwać, uaktywniać i deaktywować zakresy DHCP, a następnie
przechodzi do konfigurowania globalnych, lokalnych i domyślnych
właściwości zakresu.

486

Rozdział 12

Gdy po raz pierwszy uruchamiamy Menedżera DHCP, nie ma on
żadnych zdefiniowanych zakresów, a jego okno z listą serwerów
DHCP zawiera tylko pozycję odpowiadającą maszynie lokalnej.
Sugerujemy, by przed przystąpieniem do tworzenia zakresów dodać
do Menedżera DHCP inne istniejące w sieci serwery DHCP.
Wówczas w oknie tym pojawi się lista wszystkich serwerów DHCP
w naszej sieci (rysunek 12.2). Zapewni to możliwość zarządzania
innymi zakresami; poza tym takich dodatkowych zakresów można
użyć jako punktu odniesienia do tworzenia nowych.

Aby dodać serwer DHCP do naszego lokalnego Menedżera DHCP:

1. Wybieramy

Add

z menu

Serv er

lub nacisnąwszy CT RL+A

wyświetlamy okno dialogowe

Add DHCP Serv er to Serv er List

(Dodaj serwer DHCP do listy serwerów).

2. Wprowadzamy adres IP serwera DHCP do pola serwera DHCP

i klikamy

. Adres ten pojawi się w oknie

DHCP Serv ers

Uwaga: Menedżer DHCP posługuje się nazwami hostów zgodnymi
z FQDN TCP/IP, czyli Fully Qualified Domain Name (w pełni
kwalifikowanymi nazwami domen), i nie rozpoznaje nazw NetBIOS-
u. Pogłębiony opis różnic między nazwami NetBIOS-u
a

standardowymi nazwami hostów TCP/IP przedstawiono

w podrozdziale "WINS kontra DNS", w dalszej części rozdziału.

3. T e same kroki powtarzamy dla każdego serwera DHCP, który

chcielibyśmy dodać do swego lokalnego Menedżera DHCP.

Rys. 12.2.

Menedżer

Microsoft DHCP

z kilkoma

serwerami

i zakresami

DHCP.

DHCP, WINS i DNS

487

Uwaga: Ponieważ usługa serwera DHCP nie replikuje swej bazy
danych i informacji konfiguracyjnych do innych serwerów DHCP,
to – by wszystkimi zakresami protokołu DHCP można było
zarządzać z dowolnego komputera z zainstalowanym Menedżerem
DHCP – ten ostatni musi być skonfigurowany na każdym serwerze
z osobna.

Praca z zakresami DHCP

Praca z zakresami DHCP obejmuje cztery czynności:

Tworzenie zakresu: Jest to proces wstępny, warunkujący

możliwość automatyzacji konfigurowania T CP/IP w kliencie
DHCP.

Uaktywnienie zakresu: By nowo utworzonego zakresu

można było używać, trzeba go uaktywnić. Dopiero gdy zakres
jest aktywny, klientom DHCP mogą być przydzielane, należące
do niego adresy IP, wraz z

odpowiednią informacją

konfiguracyjną T CP/IP.

Deaktywacja zakresu: Przed usunięciem zakresu trzeba go

uczynić nieaktywnym. Deaktywacja uniemożliwi klientom
odnowienie bieżących dzierżaw i zmusi do uzyskania ich z innego
zakresu DHCP. Jest to wygodny sposób na samoczynne
przenoszenie klientów do nowego zakresu bez interwencji
bezpośredniej.

Usuwanie zakresu: Gdy z zakresu DHCP już nikt nie

korzysta, można go usunąć.

Aby utworzyć zakres, trzeba wykonać następujące czynności:

1. W oknie serwerów DHCP wybieramy ten, na którym chcemy

utworzyć nowy zakres. Jeśli nowy zakres tworzony jest na
komputerze, na którym działa nasza usługa serwera DHCP,
będzie to Local Machine (Maszyna lokalna); w przeciwnym
razie - adres IP.

2. Z menu

Scope

wybieramy

Create

. Pojawi się okno dialogowe

Create Scope

, pokazane na rysunku 12.3.

488

Rozdział 12

1. W polu

Start Address

(Adres pocz¹tkowy) wpisujemy

pierwszy adres IP danej podsieci.

2. W polu

End Address

wpisujemy ostatni adres IP danej

podsieci.

Wskazówka: Jeśli nie planujemy dzielenia podsieci między dwa
serwery DHCP, to należy wpisać pełny zakres adresów IP,
obowiązujących w danej podsieci. Jeśli jednak zamierzamy ją
podzielić, to w pola

Start Address

(Adres początkowy) i

End

Address

(

Adres końcowy) należy wpisać jedynie połowę zakresu

adresów IP. Dzięki temu łatwiej jest pracować i unika się konfliktów
z zakresem zdefiniowanym w drugim Menedżerze DHCP.

5. W polu

Subnet Mask

(Maska podsieci) wprowadzamy maskę

podsieci, która będzie przydzielana klientom DHCP.

6. Jeśli dany zakres obejmuje adresy przydzielane statycznie, jak

choćby przydzielone kartom sieciowym w konfigurowanym
właśnie komputerze lub usłudze zdalnego dostępu (RAS), to
należy je wprowadzić do grupy Exclusion Range (Obszaru
wykluczenia). Aby wykluczyć pojedynczy adres, wpisujemy go
do pola

Start

Address

i klikamy przycisk

Add

. By wprowadzić

kilka sąsiadujących adresów przeznaczonych do wykluczenia,
w polu

Start

Address

(Adresu początkowego) wpisujemy

pierwszy adres IP, w polu

End

Address

(Adresu końcowego)

Rys. 12.3. Okno
dialogowe Create
Scope ( Utwórz
zakres).

DHCP, WINS i DNS

489

ostatni i

klikamy

Add

. Spowoduje to umieszczenie tak

zdefiniowanej grupy w polu

Excluded

Addresses

(Adresów

wykluczonych). Aby zmodyfikować lub usunąć grupę adresów,
zaznaczamy ją w polu

Excluded Addresses

i klikamy przycisk

Remov e

(Usuń). Wskutek tego znajdzie się on w polach

Exclusion

Range

(Obszaru wykluczenia), gdzie można ją będzie

zmodyfikować i dodać ponownie do pola

Exluded

Addresses

(

Adresów wykluczonych).

7. W grupie

Lease Duration

(Okresu dzierżawy) określamy rodzaj

dzierżawy, wybierając przycisk

Unlimited

(Nieograniczony) lub

Limited

(Ograniczony do). Jeśli wybierzemy

Limited

, czyli

domyślny, podajemy okres, w ciągu którego klienci DHCP
zachowywać będą przydzielone im adresy IP. T ermin
wygaśnięcia dzierżawy ustawiony jest domyślnie na 3 dni. Okres
dzierżawy należy wybierać kierując się częstotliwością, z jaką
komputery są rozbudowywane, wymieniane lub przenoszone
pomiędzy podsieciami. Jeśli fluktuacja komputerów jest duża,
najlepiej wybrać dzierżawę mniej więcej dwutygodniową. Gdy
natomiast ruchliwość komputerów jest bardzo mała, wybiera się
dzierżawy miesięczne, kwartalne lub półroczne.

Ostrzeżenie: Nie przyznawajmy dzierżawy Unlimited
(Nieograniczonej), jeśli nie jesteśmy absolutnie pewni, że żaden
komputer nie będzie nigdy rozbudowywany, wymieniany lub
przenoszony. Zapewniamy, że sytuacja taka jest bardzo mało
prawdopodobna. Gdy wybierzemy dzierżawę nieograniczoną, nie
będziemy mogli bez osobistej interwencji odzyskać adresów IP,
przydzielonych już klientom DHCP.

8. W polu

Name

wpisujemy nazwę wybraną dla danego zakresu.

Może to być piętro lub lokalizacja budynku, lub opis rodzaju
podsieci. Nazwa ta wyświetlana jest wraz z adresem zakresu
w oknie

DHCP Serv ers

. Może mieć do 120 znaków.

9. W polu

Comment

podajemy opis zakresu zawierający

maksymalnie 120 znaków. Powinien być jak najbardziej
opisowy.

490

Rozdział 12

Wskazówka: W

celu zmodyfikowania właściwości istniejącego

zakresu wystarczy kliknąć go dwukrotnie. Spowoduje to
wyświetlenie okna dialogowego

Scope Properties

(Właściwości

zakresu), nie różniącego się funkcjonalnie niczym od okna
dialogowego

Create

Scope

(Utwórz zakres). Można w nim zmienić

dowolną z opcji, opisanych w poprzednich punktach.

10. Klikamy

. Pojawi się okno komunikatów, polecające

uaktywnić zakres. Nie należy jednak robić tego teraz, chyba że
wszystkie domyślne właściwości zakresu są poprawnie ustawione,
tak jak to opisano w podrozdziale "Konfigurowanie opcji
zakresu DHCP".

11. Powyższe kroki należy powtórzyć dla każdego z zaplanowanych

zakresów.

Ostrzeżenie: Zakres wolno uaktywnić dopiero po jego
skonfigurowaniu; w przeciwnym razie klienci mogliby otrzymać
niepoprawne informacje konfiguracyjne. Należy też upewnić się, czy
przed uaktywnieniem dokonane zostały wszelkie niezbędne
rezerwacje dzierżaw; w przeciwnym razie zarezerwowany adres IP
mógłby uzyskać klient inny niż ten, dla którego był przewidziany.

Aby uaktywnić zakres, należy wybrać

Scope\Activ ate

(Zakres\Uaktywnij).

Przed usunięciem zakresu należy go zdeaktywować. Robimy to,
wybierając

Scope\Deactiv ate

. Dopiero gdy czas dzierżawy zakresu

wygaśnie i upewnimy się, że żaden z

klientów nie korzysta

z należącej do zakresu dzierżawy, możemy zakres skasować.

Aby skasować zakres, wykonujemy poniższe czynności:

1. W oknie serwerów DHCP wybieramy serwer zawierający zakres,

który chcielibyśmy usunąć. Jeśli usuwamy zakres z komputera,
na którym działa nasza własna usługa serwera DHCP, to będzie
to

Local Machine

; w przeciwnym razie będzie to adres IP.

2. Wyświetlone zostaną zakresy dla danego serwera. Zaznaczamy

ten, który zamierzamy usunąć.

DHCP, WINS i DNS

491

3. Z menu

Scope

wybieramy

Delete

. Pojawi się komunikat

ostrzegawczy z informacją, że klienci mogą mieć jeszcze
aktywne dzierżawy. Aby usunąć zakres, klikamy

4. Czynności te powtarzamy dla każdego zakresu przeznaczonego

do skasowania.

Wskazówka: Gdy usuwamy zakres z aktywnymi klientami, możemy
klientów zmusić do rezygnacji z

ich aktualnych dzierżaw

i otrzymania nowych- z innego serwera DHCP, wydając z wiersza
poleceń na stacji roboczej klienta rozkaz

IPCONFIG

/RENEW

. Na

komputerze z Windows 95 można użyć programu

WINIPCFG

klikając przycisk

Renew

(Odnów) zwalniamy aktywną dzierżawę

i otrzymujemy nową.

Konfigurowanie opcji zakresu DHCP

Istnieją dwie możliwości konfigurowania opcji zakresu: jako
ustawienie globalne, które dotyczy wszystkich zakresów dla danego
serwera DHCP, jak i jako ustawienie lokalne, dotyczące jedynie
konkretnego zakresu. Lokalne właściwości zakresu są nadrzędne
w stosunku do właściwości zdefiniowanych globalnie. Zasada ta
pozwala definiować wspólne właściwości, nadawane wszystkim
nowo tworzonym zakresom, a następnie dowolnie je dostosowywać.
Przypuśćmy, że używając podsieci zdefiniowaliśmy globalne
ustawienie dla rutera - tak by zawierało adresy IP dla wszystkich
naszych ruterów. Utworzywszy nowy zakres możemy skasować
pierwszą pozycję na liście i następnie dodać ją z powrotem.
Spowoduje to umieszczenie jej adresu IP na końcu listy, czyli
w istocie zmieni kolejność preferencji ruterów - tak by najbliższy
użytkownikowi wywoływany był jako pierwszy. Procedurę tę
można powtarzać, przestawiając adresy ruterów dla każdej
tworzonej podsieci bez konieczności ręcznego wpisywania adresu
każdego rutera.

By zmodyfikować pewną właściwość zakresu, należy wykonać
następujące czynności:

1. W oknie serwerów DHCP wybieramy serwer zawierający zakres,

który chcemy zmodyfikować. Jeśli usuwamy zakres
z komputera, na którym działa aktualna usługa serwera DHCP,

492

Rozdział 12

będzie to

Local

Machine

; w przeciwnym razie będzie to adres

IP.

2. Po nawiązaniu połączenia z

wybranym serwerem DHCP

pokazane zostaną jego zakresy. Wybieramy z nich ten, który
chcemy zmodyfikować.

3. Z menu

DHCP Options

wybieramy opcję

Global

, pozwalającą na

ustawianie globalnych właściwości dla wszystkich zakresów, lub
opcję

Scope

, służącą do ustawania lokalnych właściwości

zakresów.

Uwaga: Okno dialogowe wyświetlane w razie wybrania

DHCP

Options\Scope

wygląda tak samo, jak okno dla opcji

Global

z tegoż menu.

4. W rozwijanej liście

Unused Options

zaznaczamy opcję, którą

chcemy zmodyfikować, i klikamy przycisk

Add

- by przenieść

podświetlenie do pola listy

Activ e Options

(Aktywnych opcji).

5. Klikając przycisk

Value

(Wartość) powiększamy okno

dialogowe o pole edycyjne, w którym można wybrać przycisk

Edit

Array

(Redaguj tablice), by zmodyfikować całą tablicę

adresów IP, lub - w

przypadku pojedynczego wpisu -

modyfikować go wprost w polu edycyjnym.

6. Powtarzamy kroki 3 - 5 dla każdej opcji, która powinna być

zmieniona. Po dokonaniu wszystkich modyfikacji klikamy

Wskazówka: By zmodyfikować istniejącą opcję, zaznaczamy ją
w rozwijanej liście

Active Options

, po czym rozwijamy pole

edycyjne klikając przycisk

Value

Tworzenie nowych opcji zakresów DHCP

Przy pomocy Mened¿era DHCP można nie tylko modyfikować
predefiniowane właściwości zakresów, lecz także zmieniać nazwę,
unikatowy identyfikator i

komentarz istniejących opcji

konfiguracyjnych. Można nawet tworzyć zupełnie nowe opcje
zakresów, przydzielane potem klientom DHCP, o ile oczywiście ci
ostatni potrafią z

nich skorzystać. Jednakże możliwość

DHCP, WINS i DNS

493

modyfikowania istniejących opcji konfiguracyjnych lub tworzenie
nowyche nie oznacza wcale, że wolno to robić arbitralnie. W istocie
jest to dozwolone tylko w razie absolutnej konieczności.

Aby zmienić wartość domyślną dla istniejącej opcji konfiguracyjnej,
wykonujemy następujące czynności:

1. Z menu

DHCP Options

wybieramy

Defaults

(Domyœlne), co

wyświetli okno dialogowe

DHCP Options

Default Values

(Opcje DHCP: Wartości domyślne), pokazane na rysunku 12.4.

1. W liście rozwijanej

Option Class

(Klasy opcji) wybieramy klasę

opcji, którą zamierzamy zmodyfikować. Klasą domyślną są

DHCP

Standard Options

(Standardowe opcje DHCP).

2. W liście rozwijanej

Option Name

wskazujemy te, z należących

do wybranej klasy pozycji, które zamierzamy zmodyfikować.

3. W grupie

Value

(Wartoœæ) podajemy nową wartość opcji.

Aby zmienić nazwę, niepowtarzalny identyfikator lub opis opcji
konfiguracyjnej, wykonujemy następujące kroki:

1. Powtarzamy czynności 1 - 3 poprzedniej procedury.

2. Wyświetlamy okno dialogowe

Change Option Type

(Zmień typ

opcji), klikaj¹c przycisk

Change

3. W polu

Name

zmieniamy nazwę opcji, w polu

Identifier

(Identyfikator) zmieniamy liczbową wartość niepowtarzalnego
identyfikatora DHCP, a w polu

Comment

- opis opcji.

Rys. 12.4. Okno

dialogowe

domyślnych

wartości opcji

DHCP.

494

Rozdział 12

Ostrzeżenie: Zmiana nazwy lub identyfikatora może uniemożliwić
poprawne funkcjonowanie klienta DHCP. Każde z tych ustawień
może być zmieniane jedynie przez świadomego konsekwencji
specjalistę.

4. Po dokonaniu wszystkich zmian klikamy

5. Czynności te wykonujemy dla wszystkich opcji, które

zamierzamy zmienić.

Aby dodać nową opcję konfiguracyjną, przeprowadzamy poniższe
operacje:

1. Powtarzamy kroki 1 - 3 procedury modyfikowania domyślnych

wartości istniejących opcji konfiguracyjnych.

2. Wyświetlamy okno dialogowe

Change Option Type

, klikając

przycisk

New

3. W polu

Name

(Nazwa) wpisujemy nazwę nowej opcji.

4. W polu

Data Type

(T yp danych) podajemy jako typ danej jedną

z następujących możliwości:

Binary: tablica bajtów

Byte: 8.bitowa liczba całkowita bez znaku

Encapsulated: tablica bajtów bez znaku

IP address: adres IP (4 bajty) w

postaci

###.###.###.###

Long: 32.bitowa liczba całkowita ze znakiem

Long integer: 32.bitowa liczba całkowita bez znaku

String: łańcuch tekstowy ASCII

Word: 16.bitowa liczba całkowita bez znaku

Jeśli typ danych jest tablicą elementów, należy zakreślić pole
opcji

Array

(T ablica).

5. W polu

Identifier

wprowadzamy nie powtarzającą się liczbę

z zakresu 0 do 255.

6. W polu

Comment

(Komentarza) wprowadzamy opis nowej

opcji.

DHCP, WINS i DNS

495

Ostrzeżenie: Dodawanie nowych 9582*12*163]\=74 opcji
konfiguracyjnych winno być wykonywane jedynie przez
świadomego konsekwencji specjalistę. Powinny one wspierać nie-
microsoftowych klientów DHCP, którzy takich dodatkowych opcji
wymagają.

7. Po dokonaniu wszystkich zmian klikamy

8. Czynności te powtarzamy dla każdej opcji, którą należy

zmienić.

Zarządzanie klientami DHCP

Zarządzanie klientami DHCP polega na manipulowaniu na serwerze
DHCP dzierżawami i rezerwacjami dla klientów oraz na wymuszaniu
na klientach zwalniania lub odnawiania dzierżaw dla ich stacji
roboczych. Po stronie klienta głównym sposobem konfigurowania
DHCP jest użycie działającego z

wiersza poleceń programu

IPCONFIG.EXE

Składnia dla IPCONFIG jest następująca:

IPCONFIG

[adapter] /all /release /renew

A oto objaśnienie składni polecenia:

[adapter]: opcjonalny składnik, oznaczający konkretną

kartę sieciową, której konfiguracja DHCP zostanie wyświetlona
lub zmieniona. By zobaczyć nazwy kart, trzeba użyć
IPCONFIG

baz parametrów.

/all: listowanie całej informacji konfiguracyjnej, obejmującej

nazwę hosta, serwery DNS, typ węzła, identyfikator zakresu
NetBIOS-u, czy uaktywniony jest ruting IP, czy komputer jest
agentem proxy WINS i

czy komputer używa DNS do

rozwiązywania nazw (zamiast WINS). Obejmuje ona również
statystykę dla każdej karty sieciowej, zawierającą nazwę i opis
karty, adres fizyczny (adres ethernetowy karty sieciowej),
informację, czy uaktywniony jest klient DHCP, adres IP, maskę
podsieci, domyślną bramę oraz adresy IP podstawowego
i zapasowego serwera WINS.

496

Rozdział 12

/release: zwalnia bieżącą dzierżawę DHCP. Jeśli podana

zostanie dla wszystkich kart sieciowych (lub gdy jest tylko jedna
taka karta), zablokowane zostaje działanie T CP/IP.

/renew: odnawia dzierżawę. Jeśli nie jest osiągalny żaden

serwer DHCP, z którego można by otrzymać nową dzierżawę,
przestaje działać T CP/IP.

Wskazówka: Użyj opcji

/renew

, aby ręcznie zmusić klienta do

pobrania nowej dzierżawy z nowego serwera DHCP lub nowego
zakresu DHCP.

Uwaga: Windows 95 nie zawiera

IFCONFIG

; zamiast niego jest

aplikacja graficzna o nazwie

WINIPCFG.EXE

Wykonywany bez parametrów IPCONFIG wyświetla bieżącą
konfigurację DHCP. Może to posłużyć do sprawdzenia, jakie karty
sieciowe są zainstalowane i jakie mają adresy IP. Na przykład,
WinBook XP autora podaje następujące informacje:

Windows

NT IP Configuration

Ethernet

adapter Elnk31:

Address.....................: 128.0.0.254

Subnet

Mask....................: 255.255.255.0

Default

Gateway................:

Ethernet

adapter NDISLoop9:

Address.....................: 129.0.0.1

Subnet

Mask....................: 255.255.255.0

Default

Gateway................:

Zarządzanie dzierżawami klientów

Zarządzanie dzierżawami klientów DHCP polega w głównej mierze
na przeglądaniu okien informacyjnych. Gdy zaznaczymy aktywny
zakres i wybierzemy

Activ e Leases

z menu

Scope

, pojawi się

okno dialogowe

Activ e Leases

, pokazane na rysunku 12.5.

DHCP, WINS i DNS

497

W oknie tym można wykonywać następujące czynności:

O glądać aktywne lub zarezerwowane dzierżawy dla

danego zakresu. Domyślnie w oknie dialogowym wyświetlane
są wszystkie dzierżawy. Jeśli jednak uaktywnimy pole opcji

Show

Reserv ations

Only

(Pokaż tylko rezerwacje),

wyświetlone zostaną jedynie dzierżawy zarezerwowane.

O glądać właściwości klienta. Na liście

Client

wybieramy

adres

IP/nazw ê komputera

i klikamy przycisk

Properties

Pojawi się okno dialogowe

Client

Properties

, pokazane na

rysunku 12.6. Okno to może dostarczyć wielce użytecznych
informacji, ponieważ w polu

Unique

Identifier

(Unikatowego

identyfikatora) wyświetla fizyczny adres karty sieciowej (MAC)
(Media Access Control), a istnieje kilka aplikacji serwera
Windows NT , które wymagają podania adresu MAC (np.
Menedżer DHCP przy rezerwowaniu dzierżawy).

Uaktualnić bazę danych DHCP po odtworzeniu

z zapasowej kopii. Jeśli z jakichkolwiek powodów nasza baza
danych DHCP musi zostać odtworzona z

ostatniej kopii

Rys. 12.5. Okno
dialogowe Active
Leases

(

Aktywnyc

h dzierżaw)
Menedżera
DHCP.

Rys. 12.6. Okno

dialogowe Client

Properties

(

W łaściwości

klienta).

498

Rozdział 12

zapasowej (uaktualnianej przez system automatycznie lub
ręcznie przez administratora), to w celu jej uaktualnienia należy
kliknąć przycisk

Reconcile

(Uzgodnij). Powoduje to dodanie

wpisów dla tych wszystkich dzierżaw, których nie ma w bazie
danych.

Wskazówka: Dzierżawę kasujemy wybierając ją na liście

Client

i klikając

Delete

. Czynności tej nie należy jednak wykonywać

mechanicznie, ponieważ może się to skończyć wystąpieniem w sieci
dwóch identycznych adresów IP, jeśli pierwotną dzierżawę zajmie
inny komputer. Przypuśćmy, że kasujemy aktywną dzierżawę, bo
chcemy przenieść klienta pod nowy adres IP. Natychmiast po
usunięciu dzierżawy trzeba ją zarezerwować (w sposób opisany
w podrozdziale "Zarządzanie rezerwacjami dla klientów") - po to,
by zapobiec ponownemu wykorzystaniu tego samego adresu IP
przez klienta. Następnie zmuszamy go do ustanowienia nowej
dzierżawy, wydając polecenie

IPCONFIG

/RENEW

na stacji

roboczej klienta. W

Windows 95 korzystamy z

polecenia

WINIPCFG

- dla uzyskania nowej dzierżawy klikamy w nim

przycisk

Renew

(Odnów).

Zarządzanie rezerwacjami dla klientów

Rezerwacje dla klientów mogą być bardziej użyteczne niż zwykłe
dzierżawy, ponieważ można w nich przydzielić klientowi DHCP
z góry określony adres IP. Klientowi DHCP z zarezerwowaną
dzierżawą można również zmienić opcje konfiguracyjne DHCP. Jest
to bardzo efektywne narzędzie, bo pozwala definiować lokalne
i globalne opcje zakresu dla większości klientów DHCP podczas
tworzenia zakresu, a następnie określać specyficzne opcje DHCP
dla tych nielicznych klientów DHCP, którzy stanowią wyjątki.

By utworzyć rezerwację dla klienta, trzeba wykonać następujące
czynności:

1. W oknie serwerów DHCP wybieramy serwer zawierający zakres,

których chcemy zmodyfikować. Jeśli modyfikujemy zakres na
komputerze, na którym działa aktualna usługa serwera DHCP,
będzie to

Local

Machine

(Maszyna lokalna); w przeciwnym

razie będzie to adres IP.

DHCP, WINS i DNS

499

2. Zaznaczamy zakres, w którym wykonana będzie rezerwacja.

3. Z menu

Scope

wybieramy

Add

Reserv ations

(Dodaj

rezerwacje), by wyświetlić okno dialogowe

Add Reserv ed

Clients

(Dodaj zarezerwowanych klientów).

4. W polu

Address

wprowadzamy adres IP, należący do

aktualnego zakresu DHCP, który ma być przydzielony
klientowi.

5. W polu

Unique

Identifier

(Unikatowego identyfikatora)

wprowadzamy adres MAC (unikatowy identyfikator karty
sieciowej) dla karty sieciowej klienta.

6. W polu

Client

Name

wprowadzamy nazwę komputera klienta.

7. W polu

Client

Comment

(Komentarza klienta) możemy dodać

opis komputera klienta.

8. Klikamy przycisk

Add

9. Powtarzamy kroki 3 - 6 dla każdej rezerwacji, jaką należy dodać

do zakresu.

Zmiana opcji konfiguracyjnych dla zarezerwowanej dzierżawy
wymaga trochę więcej pracy. Oto sposób postępowania:

1. W oknie serwerów DHCP wybieramy serwer zawierający zakres,

który chcemy zmodyfikować. Jeśli modyfikujemy zakres na
komputerze, na którym działa aktualna usługa serwera DHCP,
będzie to

Local

Machine

; w przeciwnym razie będzie to adres

IP.

2. Wybieramy zakres, który chcemy zmodyfikować.

3. Z menu

Scope

wybieramy

Activ e

Leases

, by wyświetlić okno

dialogowe

Activ e

Leases

(Aktywnych dzierżaw).

4. Wybieramy tę zarezerwowaną dzierżawę, którą chcemy

zmodyfikować, i klikamy przycisk

Properties

. Jeśli zbyt duża

ilość dzierżaw utrudnia przewijanie, uaktywniamy opcję

Show

Reserv ations

Only

(Pokaż tylko rezerwacje). Pojawi się okno

dialogowe

Client

Properties

(Właściwości klienta).

5. Klikamy przycisk

Options

, aby wyświetlić okno dialogowe

DHCP

Options

. Jest ono takie samo, jak drugie okno opcji

DHCP.

500

Rozdział 12

6. Na liście rozwijanej

Unused

Options

(Niewykorzystanych

opcji) zaznaczamy opcję, którą chcemy zmodyfikować, i -
klikając następnie przycisk

Add

- przenosimy ją na listę

Activ e

Options

(Aktywnych opcji). Jeśli opcja, która ma być

zmodyfikowana, jest już na liście Aktywnych opcji, wystarczy ją
tylko wybrać.

7. Kliknięciem

Value

rozszerzamy okno dialogowe o dodatkowe

pole edycyjne, w którym możemy kliknąć przycisk

Edit

Array

(Redaguj T ablicę), aby zmodyfikować całą tablicę adresów IP, lub
odpowiednie pole - by zmienić istniejącą wartość.

8. Powtarzamy kroki 4 - 6 dla każdej opcji, która ma być

zmodyfikowana. Gdy zakończymy modyfikowanie, klikamy

9. Powtarzamy kroki 3 - 7 dla każdej rezerwacji, którą

zamierzaliśmy zmodyfikować. Gdy zmodyfikujemy już wszystkie
rezerwacje, klikamy

Zarządzanie bazami danych DHCP

W trakcie nieprzerwanej, wielodniowej pracy serwera DHCP jego
bazy danych mogą rozrastać się lub kurczyć, w miarę dodawania lub
usuwania z

nich rekordów. Bazy te znajdują się w

katalogu

%SysemRoot%\System32\DHCP

i zawierają:

DHCP.MDB: bazę danych DHCP

DHCP.TMP: tymczasowy plik utworzony przez serwer DHCP

pliki JET*.LOG: pliki zawierające rekordy transakcji

SYSTEM.MDB: strukturalne informacje o

bazach danych

DHCP.

Rozrastanie się baz danych wpływa na szybkość działania serwera
DHCP. Dlatego gdy wielkość bazy danych DHCP.MDB zbliży się do
granicy 10 MB, należy ją skompresować.

By skompresować bazę danych, trzeba wykonać następujące
czynności:

1. W aplecie

Serv ice

Panelu sterowania zatrzymujemy usługę

serwera DHCP lub wydajemy polecenie net stop
dhcpserver

z wiersza poleceń na konsoli.

DHCP, WINS i DNS

501

2. Z wiersza poleceń konsoli uruchamiamy program

JETPACK.EXE

, umieszczony w

katalogu

%SystemRoot%\System32

Oto składnia wywołania programu:

JETPACK

DatabaseName TemporaryDatabaseName

DatabaseName

jest nazwą bazy danych, która ma być

skompresowana; może to być w pełni kwalifikowana ścieżka
dostępu.

TemporaryDatabaseName

jest nazwą, jaką otrzyma

tymczasowa baza danych. Może to również być w

pełni

kwalifikowana ścieżka dostępu.

Ostrzeżenie: Nie wolno kompresować pliku

SYSTEM.MDB

. Jeśli

zostanie skompresowany, usługa serwera DHCP nie wystartuje.
Gdyby tak się zdarzyło, należy odtworzyć konfigurację z poprzedniej
kopii zapasowej lub skasować wszystkie pliki z

katalogów

%SystemRoot%System32\DHCP

oraz

%SystemRoot

%System32\DHCP\backup\Jet

. Następnie trzeba

rozpakować plik

SYSTEM.MDB

nośnika

źródłowego,

zrestartować usługę serwera DHCP i uzgodnić bazę danych,
wybierając

Scope\Active

Leases

klikając przycisk

Reconcile

(Uzgodnij).

3. Uruchamiamy usługę serwera DHCP z apletu

Serv ices

Panelu

sterowania lub wydajemy polecenie net start dhcpserver
- z wiersza poleceń konsoli.

Wskazówka: Ponieważ nie można wykluczyć, że kompresja nie
powiedzie się, a dane w partycji

%SystemRoot%

zostaną uszko-

dzone, trzeba regularnie archiwizować bazy danych DHCP, a już
obowiązkowo przed ich skompresowaniem. Wystarczy w tym celu
wstrzymać czasowo usługę serwera DHCP i

skopiować pliki

w katalogach:

%SystemRoot%\Sysem32\DHCP

%SystemRoot%\System32\DHCP\backup\Jet

do innego katalogu, a nawet okazjonalnie na inny komputer.

502

Rozdział 12

Agent przekazujący DHCP

Ponieważ DHCP korzysta szeroko z metody rozgłaszania, to
w środowisku z rutingiem może natknąć się na pewne przeszkody.
Wynika to z faktu, iż rutery zwykle są tak konfigurowane, by
odfiltrowywać komunikaty rozgłaszane, ograniczając ich zasięg do
lokalnej podsieci.

Ponieważ jednak DHCP korzysta z dobrze znanych portów UDP
67 i 68, pierwotnie zarezerwowanych dla BOOT P, to jest on
w korzystniejszej sytuacji. BOOT P jest metodą przesyłania adresów
IP i informacji niezbędnej do uruchomienia bezdyskowych stacji
roboczych z sieci. Ponieważ wsparcia tego trzeba było dostarczać
użytkownikom poprzez granice podsieci, producenci ruterów
zaczęli zaopatrywać je w mechanizmy przekazujące do odległych
podsieci komunikaty adresowane do portów 67 i 68. T ego rodzaju
funkcja rutingu znana jest powszechnie jako wsparcie
przekazywania BOOT P/DHCP i zdefiniowana w RFC 1452. Nie
zapewniają jej wszystkie rutery, a w ruterach, które to robią, może
być domyślnie wyłączona.

Ponieważ nie wszystkie rutery dysponują taką funkcjonalnością (lub
wymagają niezmiernie drogiej rozbudowy), Microsoft dostarcza
agenta przekazującego (rely agent) DHCP. Działa on jako usługa na
serwerze lub stacji roboczej Windows NT 4, nadsłuchując na porcie
UDP 67, czy w lokalnej podsieci nie pojawi się pakiet DHCP
Discover. Gdy pakiet taki wykryje, przekazuje go do jednego lub
kilku serwerów DHCP, skonfigurowanych w trakcie instalowania
agenta przekazującego. Gdy serwer DHCP otrzyma taki pakiet,
odpowiada komunikatem DHCP Offer, lecz zamiast ofertę te
rozgłosić (co zrobiłby normalnie) odsyła ją z powrotem do agenta
przekazującego DHCP. Wówczas agent przekazuje ją do klienta
niejako „z ramienia” serwera DHCP. Faktycznie klient nawet nie
uświadamia sobie, że nie rozmawia bezpośrednio z serwerem,
a tylko z pośrednikiem.

Instalowanie DHCP Realay Agent

By zainstalowanie agenta przekazującego DHCP było w ogóle
możliwe, trzeba być zalogowanym jako członek lokalnej grupy

Administrators

DHCP, WINS i DNS

503

By zainstalować usługę agenta przekazującego DHCP (DHCP Relay
Agent), należy wykonać następujące czynności:

1. Otwieramy aplet

Netw ork

Panelu sterowania.

2. Wybieramy zakładkę

Serv ices

(Usługi).

Klikamy przycisk

Add

i wybieramy

DHCP

Relay

Agent.

4. Gdy program zażąda, wpisujemy ścieżkę dostępu do nośnika

plików dystrybucyjnych (na przykład, f:\i386) i klikamy
przycisk

Continue

. Spowoduje to powrót do okna

konfiguracyjnego

Netw ork

Panelu sterowania, w którym agent

przekazujący DHCP będzie teraz wymieniony jako
zainstalowana usługa.

5. Klikamy

Continue

- aby opuścić okno konfiguracyjne

Netw ork

6. Pojawi się komunikat (rysunek 12.7), który ostrzega, że przed

uaktywnieniem agenta przekazującego DHCP trzeba
skonfigurować przynajmniej jeden adres serwera DHCP.
Klikamy

Yes

, co spowoduje wyświetlenie okna

Microsoft

TCP/IP Properties

7. W oknie

Microsoft TCP/IP Properties

klikamy zakładkę

DHCP

Relay

(Przekazywanie DHCP), co spowoduje wyświetlenie karty

konfiguracyjnej agenta przekazującego DHCP, pokazanej na
rysunku 12.8.

Rys. 12.7.

Program

instalacyjny

ostrzega, że

zanim będzie

można uruchomić

agenta

przekazującego

DHCP, trzeba

skonfigurować

przynajmniej

jeden serwer

DHCP.

504

Rozdział 12

8. Korzystając z przycisku

Add

wprowadzamy adresy serwerów

DHCP, które mają obsługiwać lokalną podsieć.

9. Zmieniamy

Seconds

threshold

(Limit sekund) i

Maximum

hops

(Maksimum przeskoków) - odpowiednio do potrzeb danej

sieci.

Uwaga: Dla większości sieci można pozostawić domyślne wartości
Seconds threshold i Maximum hops bez zmian, czyli odpowiednio -
4 sekundy i 4 przeskoki.

10. Zamykamy okno

Microsoft TCP/IP Properties

klikając

By wprowadzone zmiany odniosły skutek, trzeba zrestartować
komputer.

Posługiwanie się kluczami Rejestru dla serwera DHCP

Podobnie jak dla większości usług Windows NT , również i dla tej
usługi informacja o konfiguracji przechowywana jest w Rejestrze
(Registry). Do jej modyfikowania służy przede wszystkim DHCP
Manager. Jednak wymienione poniżej klucze Rejestru nie dają się
w nim modyfikować i wymagają bezpośredniego użycia Edytora
Rejestrów - Registry Editor (REGEDIT32.EXE). Sam Edytor
Rejestrów jest narzędziem potencjalnie niebezpiecznym (patrz też

Rys. 12.8. Agenta

przekazującego

DHCP

konfiguruje się

w oknie Microsoft

TCP/IP

Properties

( W łaściwości

Microsoft

TCP/IP).

DHCP, WINS i DNS

505

rozdział 18). Jeśli administrujemy zdalnym komputerem, w którego
konfiguracji wystąpił problem tak poważny, że usługa serwera
DHCP nie daje się w

ogóle uruchomić, to trzeba będzie

zmodyfikować Rejestr i

zdalnie odtworzyć konfigurację bazy

danych. Po dokonaniu tych zmian będzie już można - za pomocą
Menedżera serwerów - uruchomić usługę ponownie.

Klucze Rejestru przechowywane są w podkluczu HKEY_LOCAL_
MACHINE\System\CurrentControlSet\Services\DH
CPServer\Parameters

. Jeśli zmodyfikuje się którykolwiek

z nich (poza RestoreFlag), należy zrestartować komputer, by
zmiany odniosły skutek.

Interesujące nas klucze to:

APIProtocolSupport: Wartość tego klucza określa

protokół transportowy wspierany przez serwer DHCP.
Domyślnie jest to 0x1 dla RPC opartego na protokołach
T CP/IP. Może to być jednak i 0x2 - dla RPC opartego na
protokołach nazwanych potoków, 0x4 - dla RPC opartego na
LPC, czyli lokalnych wywołaniach procedur (Local
Procedure

Calls), 0x5 - dla RPC opartego na T CP/IP

i RPC opartego na LPC, oraz 0x7 - dla RPC opartego na
wszystkich trzech protokołach (T CP/IP, nazwanych potokach
i LPC).

BackupDatabasePath: Klucz ten określa lokalizację kopii

zapasowej bazy danych DHCP. Domyślnie jest to
%SystemRoot

%\System32\DHCP\Backup

. Dla

większego bezpieczeństwa można tu podać inny napęd fizyczny
w systemie. (Uwaga: nie można podawać napędów zdalnych,
ponieważ Menedżer DHCP nie obsługuje z nich archiwizowania
i odtwarzania).

BackupInterval: Określa w minutach domyślny odstęp

czasu pomiędzy kopiowaniami awaryjnymi. Wartością domyślną
jest 60 (0x3C).

DatabaseCleanupInterval: Określa w minutach okres,

po jakim z bazy danych usuwane są przeterminowane rekordy
klientów. Wartością domyślną jest 864000 (0x15180) minut,
czyli 24 godziny.

506

Rozdział 12

DatabaseLoggingFlag: Określa, czy rejestrować zmiany

w bazie danych w pliku JET.LOG. Pliku tego używa się do
odtwarzania bazy danych w razie awarii systemu. Domyślnie jest
to 1 (uaktywnione rejestrowanie), lecz jeśli dany system jest
nadzwyczaj stabilny, można wartość tę ustawić na 0,
zatrzymując rejestrowanie i zwiększając nieznacznie szybkość
pracy systemu.

DatabaseName: Określa plik bazy danych, używany przez

usługę serwera DHCP. Domyślnie jest to DHCP.MDB.

DatabasePath: Określa lokalizację plików bazy danych

DHCP. Lokalizacją domyślną jest:

%SystemRoot%\System32\DHCP.

RestoreFlag: Klucz ten określa, czy serwer DHCP

powinien odtworzyć bazę danych DHCP z jej kopii zapasowej.
Aby wymusić odtwarzanie, wartość tę należy ustawić na 1; by
nadal używać dotychczasowego pliku bazy, należy pozostawić 0.
(Uwaga: jeśli wartość ta zostanie zmieniona, trzeba usługę
zatrzymać i ponownie uruchomić, by zmiana odniosła skutek).

WINS – Windows Internet Name Service

Przyjrzawszy się dokładniej DHCP, uzyskaliśmy zarazem lepszy
punkt wyjścia do eksploracji WINS. Chociaż działanie samego
WINS-a nie wymaga DHCP, to obie usługi bardzo dobrze się
uzupełniają. Podstawowym impulsem, który wykreował WINS, było
zapotrze-bowanie na metodę dynamicznego rozwiązywania nazw,
która współpracowałaby z DNS. Ponieważ DNS w swej standardowej
postaci wspiera jedynie statyczne rozwiązywanie nazw, to
skojarzenie takie zapewniłoby tę tak pożądaną funkcjonalność.

A zatem podstawowym zadaniem WINS jest rejestracja i rozwią-
zywanie nazw dla T CP/IP. Omówienie tej usługi rozpoczniemy od
przedstawienia niektórych jego założeń projektowych wraz
z różnymi zagadnieniami, które na pewno wyłonią się w trakcie jej
implemen-towania w

naszej sieci. Następnie przejdziemy do

planowania instalacji serwera WINS, co obejmie także pewne
wskazówki odnośnie ilości instalowanych serwerów WINS i agentów
proxy WINS. Po tym przedstawimy po kolei rzeczywiste kroki

DHCP, WINS i DNS

507

procedury instalowania omawianej usługi. Dalej przejdziemy do
zarządzania i konfigurowania usługi WINS przy pomocy Menedżera
WINS. A

ponieważ przeważająca część WINS dotyczy

administrowania związanego z klientami, zobaczymy, jak z pomocą
Menedżera WINS zarządzać można klientami WINS i poznamy
pewne szczególne osobliwości klientów MS-DOS-owych
korzystających z

oprogramowania klienta Microsoft Network

Client. W końcu przypatrzymy się zarządzaniu bazą danych WINS,
stosowaniu Performance Monitor (Monitora wydajności) - do
monitorowania usługi WINS i posługiwaniu się kluczami Rejestru,
kontrolującymi zachowanie się usługi WINS.

Uwaga: WINS opiera się na RFC 1001 i 1002, które definiują
rozwiązywanie nazw NetBIOS-owych w TCP/IP. WINS może bez
ograniczeń współdziałać z innymi serwerami nazw NetBIOS-u
(NBNS). Wspomniane RFC można znaleźć pod:

ftp://ds.internic.net/rfc/rfc1001.txt

ftp://ds.internic,net/rfc/rfc1002.txt

DNS-u WINS funkcjonalnie może przypominać DNS, lecz
wykonuje też zadania, które są poza zasięgiem możliwości DNS.
O ile DNS przeznaczony jest do przekształcania nazw hostów
T CP/IP w

statyczne adresy IP, to WINS został specjalnie

zaprojektowany z myślą o kojarzeniu nazw NetBIOS-u opartego na
T CP/IP z adresami dynamicznymi przydzielanymi przez DHCP.

Uwaga: Niezmierne ważne jest zrozumienie różnicy pomiędzy nazwą
NetBIOS-ową a nazwą hosta TCP/IP dla komputera. Omówienie
tego zagadnienia znaleźć można w podrozdziale zatytułowanym
"WINS kontra DNS" w dalszej części rozdziału.

Poza tym, o ile DHCP jest usługą w pełni międzyplatformową, to
WINS skupia się przede wszystkim na platformach windowsowych
i dosowych. Przyczyna jest prosta - NetBIOS jest tworem ze świata
Windows i DOS-u.

508

Rozdział 12

Przegląd założeń projektowych usługi WINS

Podstawowym zadaniem usługi serwera WINS jest ulżenie pracy
administratora przez zautomatyzowanie procesu odwzorowywania
nazw komputerów na adresy IP, zachodzącego przy rozwiązywaniu
nazw NetBIOS-owych w sieciach bazujących na T CP/IP. W skrócie
przedstawia się to następująco: WINS utrzymuje na swym serwerze
bazę danych, która procesowi mapowania adresów IP dostarcza
nazwy komputera, pozwalając innym komputerom w

sieci

podłączać się do niego przez zwykłe podanie nazwy maszyny. Pod
wieloma względami WINS przypomina DNS - z wyjątkiem tego, że
służy tylko do rozwiązywania nazw NetBIOS-u. Jednak WINS to
coś więcej, niż sama tylko automatyzacja procesu kojarzenia nazw.

Zadaniami WINS są również:

Scentralizowane zarządzanie: Prócz samej usługi serwera

WINS, Windows NT Server oferuje również WINS Manager. Za
jego zaś pomocą można administrować innymi serwerami WINS
i ustanawiać partnerów replikacyjnych. (O

partnerach

replikacyjnych dowiemy się więcej w

podrozdziale

zatytułowanym "Planowanie instalacji WINS" w dalszej części
rozdziału).

Dynamiczne mapowanie adresów i rozwiązywanie nazw:

Za każdym razem, gdy startuje, a po starcie w określonych
odstępach czasu, klient WINS rejestruje swą nazwę w serwerze
WINS. Gdy klient WINS kończy pracę (jak to ma miejsce na
przykład przy wyłączeniu komputera), informuje o tym serwer
WINS, który zwalnia jego nazwę. Procedura ta zapewnia, że
klient może zmienić swą podsieć lub adres IP, nadal pozostając
dostępnym dla innych komputerów, oraz czyni zbędnym ręczne
modyfikowanie plików hostów, tak uciążliwe w

przypadku

unixowej usługi DNS. T e trzy etapy (rejestracja, zwolnienie
i odnowienie) działają w następujący sposób:

Rejestracja: Do serwera WINS wysyłane jest żądanie

zarejestrowania nazwy w jego bazie danych. Serwer WINS
rejestrację nazwy klienta wykonuje lub odrzuca w zależności od
zawartości jego wewnętrznej bazy danych. Jeśli baza ta zawiera
już rekord dla danego adresu IP z inną nazwą komputera, serwer
WINS rejestrację tę sprawdza. Sprawdzenie polega na zapytaniu

DHCP, WINS i DNS

509

aktualnego posiadacza owego adresu IP, czy nadal go używa. Jeśli
tak, to żądanie nowego klienta zostaje odrzucone. Jeśli jednak
aktualny właściciel adresu IP z niego nie korzysta, to żądanie
nowego klienta zostaje zaakceptowane i - po zaopatrzeniu
w datownik - niepowtarzalny inkrementalny numer wersji i inne
informacje, dodawane szą do bazy danych.

Zwolnienie: Za każdym razem, gdy komputer zostaje przez

użytkownika prawidłowo wyłączony (czyli gdy nie zawiesza się
lub nie ma zaniku zasilania), informuje o tym serwer WINS,
który odpowiadający jego nazwie wpis w bazie danych zaznacza
jako zwolniony. Wpis ten pozostaje tak oznaczony przez
pewien określony czas, po czym jest ponownie oznaczany już
jako przeterminowany i

otrzymuje kolejny numer wersji.

Numery wersji służą do oznaczania rekordów jako zmienionych,
a wszystkie takie zmiany u partnerów WINS propagowane są do
wszystkich pozostałych serwerów WINS. Jeśli rekord oznaczony
jest jako przeterminowany, a do serwera WINS dotrze nowa
rejestracja z taką samą nazwą, lecz odmiennym adresem IP, to
serwer WINS rejestracji tej nie sprawdza, a po prostu przypisuje
ów adres IP nazwie. Może się tak np. dotyczyć obsługującego
DHCP komputera przenośnego (lub innego komputera
z DHCP), który przeniesiono do innej podsieci.

O dnowienie: Gdy upłynie połowa okresu odnowienia, klient

WINS ponownie rejestruje swą nazwę i adres IP w serwerze
WINS. Gdy okres odnowienia upłynie całkowicie, nazwa zostaje
zwolniona, o ile klient nie zarejestruje się w serwerze WINS
ponownie.

Przeglądanie w całej domenie: Jeśli korzystamy z serwerów

WINS, nasi klienci (Windows NT , Windows 95, Windows for
Workgroup, LAN Manager 2.x i

komputery z

MS-DOS

używające klienta Microsoft Network Client 3.0) mogą
przeglądać zasoby komputerów w sieci Microsoft Network
poprzez rutery i

nie jest do tego konieczne posiadanie

kontrolera domeny Windows NT w każdej podsieci.

Redukcja ruchu związanego z rozgłaszaniem: Serwer

WINS zmniejsza ilość rozgłaszanych komunikatów, gdyż
w odpowiedzi na komunikat z żądaniem rozwiązania nazwy
dostarcza adresu IP komputera - albo z lokalnej bazy danych

510

Rozdział 12

w samym serwerze WINS, albo z jego cache'a w agencie proxy
WINS. Rozgłaszanie w lokalnej sieci konieczne jest tylko wtedy,
gdy żądanie rozwiązania nie zapewni odpowiedzi.

Agenci proxy WINS-a

Jak już poprzednio wspomniano, WINS jest usługą stosunkowo
nową. Niewykluczone więc, że nadal będziemy mieć w swej sieci
kilku klientów z NetBIOS-em opartym na T CP/IP, którzy nie
mogą działać jako klienci WINS. Odnosi się to szczególnie do
starszego oprogramowania i

nie-microsoftowych klientów

sieciowych NetBIOS-u, takich jak LAN Manager i inni starsi klienci
dla OS/2. By umożliwić takim nie-WINS-owym klientom
współdziałanie z

usługą WINS, Microsoft daje możliwość

uruchamiania agentów proxy - czyli prokurentów WINS (WINS
Proxy Agent).

Agent proxy WINS nadsłuchuje, czy w lokalnej sieci nie występują
klienci próbujący - za pomocą rozgłaszania - rozwiązać nazwy
NetBIOS-owe. Wówczas agent żądania takie "zdejmuje" z sieci
i przekazuje do serwera WINS, który odpowiada na nie dostarczając
skojarzonych adresów IP. Agent proxy WINS informacje te
dostarcza na powrót do klienta żądającego rozwiązania nazwy.

Istota opisywanego procesu tkwi w tym, że w nie-WINS-owych
klientach nie trzeba dokonywać żadnych zmian i że są oni w istocie
zupełnie nieświadomi faktu, iż rozróżnienia nazw dokonuje usługa
WINS.

Uwaga: Trzeba koniecznie zdawać sobie sprawę z tego, że agent
proxy WINS przeznaczony jest tylko do obsługiwania żądań
rozwiązania nazw wysyłanych przez klientów NetBIOS-owych. Nie
dokonuje on translacji nazw ani dla UNIX-a, ani dla innych
systemów nie używających NetBIOS-u.

Jako agentów proxy WINS używać można Windows NT 3.5
i wyższych oraz Windows for Workgroups.

DHCP, WINS i DNS

511

WINS kontra DNS

Zależność istniejąca pomiędzy DNS i WINS (a nawet DHCP) jest
bardzo skomplikowana, a jej pełne przeanalizowanie wymagałoby
wiele czasu i miejsca. Jednak zrozumienie jej istoty stanowi klucz do
jak najlepszego spożytkowania zalet WINS-a i DNS-u w sieci
Microsoft Network.

Uwaga: W podrozdziale tym objaśniamy podstawowe koncepcje,
tkwiące u podstaw WINS-a, DNS-u, nazw NetBIOS-u, nazw hostów
DNS i tak dalej. By nadać całości aspekt możliwie praktyczny, nie
będziemy się wdawać w

zbędne szczegóły. Tak więc nie

zapominajmy - na razie chodzi nam tylko o ogólny schemat
procesu.

Jak już niejednokrotnie w

przeciągu dotychczasowej lektury

powtarzaliśmy, standardowe narzędzia T CP/IP (takie jak FT P
i T elnet) używają adresów IP do nawiązywania połączeń między
klientem a usługami serwera. Z doświadczenia wiemy również, że
ludzie nie cierpią długich adresów IP, i dlatego opracowano
narzędzia do mapowania nazw hostów na adresy IP, z których to
narzędzi najbardziej popularnymi są lokalne pliki HOST i usługi
DNS.

By zlokalizować hosta w sieci, standardowe narzędzia T CP/IP
muszą przekształcić jego nazwę w adres IP. W sieciach Microsoft
(czyli sieciach NetBIOS-owych) odbywa się to inaczej. T utaj do
znalezienia zasobu sieciowego nie używa się rzeczywistego adresu,
a nazwy NetBIOS-owej. NetBIOS jest protokołem interfejsowym
na poziomie warstwy sesji, opracowanym we wczesnych latach
osiemdziesiątych dla IBM. Udostępnia on zestaw sieciowych API,
które pozwalają aplikacjom użytkownika uzyskiwać i dostarczać
usługi sieciowe.

NetBIOS dostarcza również prymitywnego protokołu
transportowego zwanego NetBIOS Frames Protocol (NBFP), który
kilka lat później rozwinął się w NetBIOS Extended User Interface
(NetBEUI). Jego jedynym zadaniem było efektywne
transportowanie ruchu NetBIOS-owego poprzez małe sieci lokalne.

512

Rozdział 12

NetBEUI jest już od wielu lat standardowym protokołem
transportowym dla sieci Microsoft. Jednak nawet i dzisiaj wielu
ludzi myli role, jakie NetBEUI i NetBIOS odgrywają. O

ile

NetBEUI jest nierozerwalnie związany z NetBIOS-em, to NetBIOS
może być od niego oddzielony i skojarzony z innymi protokołami
transportowymi, takimi jak IPX/SPX i T CP/IP, a to właśnie jest
przedmiotem naszego zainteresowania. Wpierw jednak przyjrzyjmy
się pobieżnie, jak działa NetBIOS oparty na NetBEUI.

Pamiętamy, że NetBIOS jest protokołem warstwy sesji. Mimo tego
nie pokrywa się w pełni z modelem OSI ISO, bo adresowanie
odbywa się w nim całkowicie w obrębie warstwy NetBIOS. Ponadto
adresowanie to realizowane jest poprzez nazwę, a nie adres, jak
w T CP/IP.

By zrozumieć, dlaczego jest to tak ważne, spójrzmy, co się dzieje,
gdy aplikacja zażąda usługi sieciowej od NetBIOS-u opartego na
NetBEUI. Przypuśćmy, że pewna aplikacja decyduje się podłączyć
do zasobu sieciowego. W tym celu musi ona znać NetBIOS-ową
nazwę, identyfikującą zasób w sieci. Aplikacja „mówi”: "Chcę się
podłączyć do zasobu sieciowego zwanego SERWER". Z poleceniem
tym zwraca się do interfejsu API NetBIOS-u. Wówczas warstwa
NetBIOS-u poleca transportowi NetBEUI odszukać zasób w sieci,
co może wyglądać tak: "NetBIOS do NetBEUI. Proszę znaleźć
w sieci zasób sieciowy o nazwie SERWER". NetBEUI wykonuje to
rozgłaszając komunikat z prośbą, by wymieniony zasób sieciowy
zidentyfikował się. "Hej tam! Czy jest tu ktoś, kto nazywa się
SERWER? Jeśli jest, niech odpowie mi podając swój adres MAC".
Jeśli dany zasób rzeczywiście jest w sieci, to odeśle swój adres MAC.
"T ak, to ja jestem SERWER. Mój adres MAC to ...". T eraz
NetBEUI rozpoczyna przekazywanie pakietów tam i z powrotem
pomiędzy obiema maszynami, korzystając z tego właśnie adresu
MAC.

Widzimy wiec, że znajomość NetBIOS-owej nazwy zasobu, do
którego chcemy się podłączyć, jest niezbędna. NetBEUI jest małym
i szybkim protokołem, lecz ponieważ korzysta szeroko
z rozgłaszania i nie obsługuje rutingu międzysieciowego, nie jest
łatwo skalowalny poza małe grupy robocze (mniej niż 100
maszyn). W sumie jest to prawdopodobnie trochę więcej, niż

DHCP, WINS i DNS

513

Czytelnik chciałby się o NetBEUI pomylenia rozwiązywania nazw
przez WINS z rozwiązywaniem ich przez DNS.

Jak już wcześniej wspominaliśmy, Microsoft chciał, by możliwe
było uruchamianie aplikacji NetBIOS-u w oparciu o inne protokoły,
takie jak IPX/SPX i T CP/IP. Pozwoliłoby to użytkownikom
Windows włączyć się szerzej w duże sieci i realizować komunikację
typu WAN. Ponadto użytkownicy, którzy chcieliby podłączać się
do standardowych, opartych na T CP/IP usług, takich jak FT P
i T elnet, musieliby zainstalować sobie tylko jeden stos protokołów,
co znacznie zmniejszyłoby nieproduktywne obciążenie komputera.

Stworzenie dosowej lub windowsowej implementacji T CP/IP, która
działałaby jak normalny stos T CP/IP obsługujący standardową
przyłączeniowość T CP/IP, było proste. Problemem było natomiast,
jak zmusić NetBIOS i T CP/IP do współpracy. Nie zapominajmy, że
chociaż NetBIOS jest protokołem warstwy sesji, to korzysta on ze
swego własnego systemu lokalizacji zasobów, opartego na nazwach
NetBIOS-owych. Z drugiej strony T CP/IP w odszukiwaniu zasobów
polega na adresach IP. T rudność polegała więc na znalezieniu
„płaszczyzny porozumienia” między nimi. Sama idea jest prosta,
lecz metoda realizacji może być kłopotliwa.

Uwaga Wszystkie aktualne stosy Microsoftu wspierają NetBIOS
oparty na TCP/IP. Jednak wiele stosów TCP/IP producentów
trzecich, opracowanych dla środowiska DOS-u lub Windows, nadal
tego nie robi.

A oto w skrócie istota współpracy NetBIOS-u z T CP/IP. Aplikacja
NetBIOS-owa „mówi”: "Chcę podłączyć się do zasobu sieciowego
o

nazwie SERWER". Interfejs API NetBIOS-u pobiera tę

informację i przekazuje ją "pomocniczemu" interfejsowi NetBIOS-
u. T en nazwę NetBIOS-ową przekształca w adres IP, konieczny do
zlokalizowania zasobu w sieci T CP/IP. Zwróćmy uwagę, że etap ten
nie był potrzebny w NetBEUI, ponieważ ten ostatni - do
znalezienia w sieci zasobu - używa prawdziwych nazw NetBIOS-u.

I tutaj właśnie dochodzimy do miejsca, w którym WINS odgrywa
swoją najważniejszą rolę i w którym występuje zarazem owo
wspomniane wcześniej pomieszanie pojęć. Przypomnijmy, że
istnieją cztery podstawowe metody rozwiązywania nazw: B-node,

514

Rozdział 12

P-node, M-node i H-node. Odzwierciedlają one różne metody,
jakich NetBIOS-owy klient może użyć do rejestrowania
i rozwiązywania nazw w sieci T CP/IP. W następnym podrozdziale
przyjrzymy się każdej z nich nieco dokładniej.

Gdy tylko interfejs NetBIOS-T CP/IP przekształci nazwę NetBIOS-
ową w adres IP, cała reszta procesu przebiega identycznie jak
w standardowym T CP/IP. Adres IP tłumaczony jest na adres MAC,
albo faktycznego zasobu, albo rutera, którego można użyć do
zlokalizowania zasobu. Po czym następuje nawiązanie komunikacji.

Zatem rzeczywisty problem sprowadza się do pytania "Jak interfejs
ten przekształca nazwę NetBIOS-ową w

adres IP?". Zanim

opracowano WINS, do wykonywania takiej translacji używano
najczęściej przedstawinych poniżej trzech metod:

Interfejs mógł w celu przekształcenia nazwy w adres IP użyć

rozgłaszania, podobnie jak to robi NetBEUI. Rozgłosiłby on
mianowicie nazwę NetBIOS-ową w całej sieci T CP/IP i czekał na
odpowiedź. Nie jest to jednak dobre rozwiązanie, wystarcza
najwyżej dla małych sieci lokalnych.

Można użyć pliku LMHOSTS. Jest to plik tekstowy, podobny do

HOSTS

, który służy do powiązania nazw NetBIOS-owych

z odpowiadającymi im adresami IP. Gdy aplikacja NetBIOS-owa
prosi o podłączenie do zasobu sieciowego, interfejs pomiędzy
NetBIOS-em a IP wyszukuje NetBIOS-ową nazwę zasobu w pliku
LMHOSTS

i znalezioną nazwę podaje poprzez niższe warstwy.

Historycznie był to najbardziej popularny sposób realizacji
translacji nazw NetBIOS-u w dużych sieciach T CP/IP.

Nowsze stosy T CP/IP Microsoftu mają możliwość użycia usługi

DNS do rozwiązywania nazw NetBIOS-u. Warunkiem jest
jednak, by nazwa NetBIOS-u dla zasobu była identyczna z nazwą
hosta DNS, w przeciwnym bowiem razie pojawią się problemy.
Ponadto działa to tylko przy podłączaniu do maszyn na tym
samym, co klient, poziomie hierarchii DNS. Dla przykładu, jeśli
nasz komputer nazywa się ntserver.xyzcorp.com
i mamy uaktywnioną opcję rozwiązywania DNS-owego, to -
wykorzystując DNS do translacji nazw - możemy, za pomocą
Menedżera plików, podłączyć się do dowolnego zasobu NetBIOS-
owego w domenie

xyzcorp. com

. Działa to w ten sposób, że

DHCP, WINS i DNS

515

aplikacja NetBIOS-owa (w tym przypadku Menedżer plików)
prosi o otwarcie połączenia do zasobu określając jego NetBIOS-
ową nazwę. Warstwa translacji z NetBIOS-u do IP wyszukuje
nazwę zasobu w

serwerze DNS, właściwym dla domeny

xyzcorp.com

i odsyła adres IP.

Chociaż wszystkie te możliwości mają swoje zalety i wady, to
problemem, którego żadna z nich nie rozwiązuje, jest translacja
adresów przydzielanych dynamicznie. I

to jest właśnie

podstawowym celem, dla którego stworzono WINS. Choć WINS
można stosować jako jedyną technikę rozwiązywania nazw, to
znacznie powszechniej używa się go w połączeniu z jedną lub
kilkoma spośród wymienionych wyżej metod.

Gdy w swej sieci używamy WINS-a, to jego klienci rejestrują swoje
aktualne adresy IP i nazwy NetBIOS-owe w serwerze WINS.
Wówczas, jeśli ktoś w sieci zechce przetłumaczyć NetBIOS-ową
nazwę zasobu sieciowego, poprosi o to serwer WINS. Nawet jeśli
przydział IP otrzymany został dynamicznie za pomocą DHCP, to
proces ten działa nadal, gdyż za każdym razem, gdy klient DHCP
otrzyma nowy adres, zmianę tę rejestruje w serwerze WINS.

Pokazaliśmy dotychczas, dlaczego nazwy NetBIOS-u są tak ważne,
i jak działa rozwiązywanie nazw NetBIOS-owych w

sieciach

T CP/IP. Jedynym problemem, wymagającym jeszcze zbadania, jest
sposób integracji WINS i

DNS. WINS działa skutecznie

przypadku translacji nazw NetBIOS-owych. Oznacza to

w praktyce, że do podłączenia się do maszyny zarejestrowanej
w bazie danych WINS można użyć Menedżera plików lub innej
aplikacji NetBIOS-owej (takiej jak przeglądarki Network
ClipBook).

By uzmysłowić sobie potrzebę integracji WINS i DNS, rozważmy
pewien przykład. Mamy serwer NT o nazwie SERWER. Mamy
również stację roboczą Windows for Workgroups (WFW) o nazwie
ST ACJAROBOCZA. Gdyby maszyna WFW chciała podłączyć się
do napędu sieciowego na SERWERZE, to inicjując połączenie
użyłaby NetBIOS-owej nazwy SERWER. Do jej przekształcenia
w

adres IP skorzystałaby z

dowolnej dostępnej metody

rozwiązywania. Jeśli na maszynie zwanej SERWER działa również
serwer FT P i chcielibyśmy się do niego podłączyć, to wszystko
przebiegłoby odmiennie. FT P nie jest aplikacją NetBIOS-ową. By

516

Rozdział 12

utworzyć połączenie, FT P potrzebuje prawdziwego adresu IP hosta.
Oznacza to, że jeśli maszyna o nazwie ST ACJAROBOCZA zechce
podłączyć się do SERWERA używając FT P, to trzeba jej podać
adres IP SERWERA lub nazwę, która po przetłumaczeniu - za
pomocą lokalnego pliku HOSTS (nie LMHOSTS!) lub usługi DNS -
okaże się tym samym adresem IP.

A teraz utrudnijmy nieco zadanie. Powiedzmy, że maszyna
SERWER swój adres IP otrzymała dynamicznie z DHCP. Ani plik
HOSTS

, ani DNS nie są w

stanie przetłumaczyć nazw na

dynamiczne adresy IP. I

pamiętajmy, tylko WINS potrafi

rozwiązywać nazwy NetBIOS-owe!

W tym momencie idea interfejsu WINS-DNS nabiera szczególnej
mocy. Rozbudujmy przykład - tak by zobaczyć, jak działa ten
interfejs. Wyobraźmy sobie, że zawiadujemy w

większości

windowsową siecią 100 klientów z

kilkoma serwerami NT .

Wszystkie zasoby otrzymują swe adresy IP dynamicznie z DHCP
z wyjątkiem jednego serwera NT , który jest serwerem WINS
i DHCP. Na jednym z serwerów NT w sieci działa także serwer
FT P, który tak samo otrzymuje swój adres dynamicznie.
Przypuśćmy, że w innej części świata jest jakiś UNIX, który chce
nawiązać połączenie FT P z tym właśnie serwerem NT . Jednym ze
sposobów uzyskania połączenia jest znalezienie aktualnego adresu
IP serwera i skorzystanie z niego. Jego wadą jest to, że adres ten
może się zmienić i trzeba będzie go za każdym razem na nowo
ustalać.

Łatwiejszemu nawiązaniu tego połączenia służy integracja DNS
z WINS. Polega ona (w uproszczeniu) na uruchomieniu usługi
serwera Microsoft DNS w Windowsie NT . Serwer Microsoft DNS
(omówiony bardziej szczegółowo w

dalszej części rozdziału,

dysponuje specjalnym modułem interfejsowym, który współpracuje
z usługą serwera WINS. Pozwala on serwerowi DNS zażądać od
serwera WINS przepro-wadzenia translacji nazwy na IP.

DHCP, WINS i DNS

517

Uwaga: Poświęciliśmy mnóstwo miejsca na omówienie różnicy
pomiędzy nazwami NetBIOSowymi a nazwami hostów TCP/IP;
jednak po przeczytaniu ostatniego akapitu można by odnieść
wrażenie, że różnica ta znów się zatarła. To prawda, lecz na nasze
szczęście nazwy hostów TCP/IP i nazwy NetBIOSowe korzystają
z kompatybilnego zbioru konwencji, dzięki czemu dla celów tej
usługi można stosować je zamiennie.

Kontynuując nasz przykład załóżmy, że klient unixowy na drugim
krańcu świata próbuje podłączyć się do serwera o

nazwie

NTFTP.xyzcorp.com

. Pamiętamy, że ten serwer NT

otrzymuje dynamiczny adres IP z serwera DHCP. Klient unixowy
prosi swój lokalny serwer DNS o

rozwiązanie nazwy

NTFTP.xyzcorp.com

. Na to lokalny serwer DNS sprawdza

w InterNIC-u, jaki jest adres IP serwera DNS właściwego dla
domeny xyzcorp.com. InterNIC odsyła adres kompetentnego
serwera, którym jest nasz serwer NT z działającym na nim
serwerem DNS i serwerem WINS. T eraz z kolei nasz serwer
Microsoft DNS proszony jest o zidentyfikowanie maszyny zwanej
NT FT P. T en zaś pyta serwer WINS o adres IP maszyny o nazwie
NT FT P. W rezultacie adres IP wędruje w końcu do maszyny
unixowej która – posiadając już adres IP dla
NTFTP.xyzcorp.com

– ustanawia wreszcie połączenie. Jest to,

jak widać, dobitne uzasadnienie integracji WINS-a z DNS-em.

Planowanie instalacji WINS

W niewielkiej sieci, opartej na standardzie Microsoftu, cała
instalacja WINS-a sprowadza się do zainstalowania jego usługi na
każdym kontrolerze domeny. Daje to już możliwość takiego
skonfigurowania bazujących na T CP/IP klientów sieciowych, by
mogły one bez ograniczeń współpracować z

każdym innym

serwerem lub klientem w sieci. Wynika to ze stwierdzonego faktu,
że pojedynczy serwer WINS jest w stanie pomieścić około 1500
zarejestrowanych nazw i obsłużyć 760 żądań translacji nazw na
minutę. W teorii wystarczy więc użyć jednego serwera WINS,
wspomaganego przez jeden serwer zapasowy dla każdego z 10000
klientów.

518

Rozdział 12

Mimo to zalecamy używać serwerów w

oparciu o

logiczne

grupowanie maszyn, zapewniając im podwyższoną odporność na
uszkodzenia i bardziej równomierny rozkład obciążeń.

Uwaga: Tego rodzaju komunikaty z żądaniami rozwiązania nazw
mogą być przekazywane do innych serwerów WINS i agentów proxy
WINS - po to, by któryś z nich w końcu na nie odpowiedział. Jeśli
jednak uaktywnimy replikację naszych baz danych WINS, to każdy
serwer WINS otrzyma pełną listę wszystkich nazw klientów i ich
adresów IP. Wówczas adresy IP, odsyłane w odpowiedzi na żądanie
rozwiązania nazwy, uzyskiwane będą bez rozgłaszania w sieci.
Mechanizm ten przyczyni się do zmniejszenia ruchu
rozgłoszeniowego w sieci.

Wspomniane wcześniej logiczne grupowanie powinno bazować na
fizycznym rozmieszczeniu kontrolerów domeny lub serwerów
Windows NT . Grupa logiczna może, na przykład, opierać się na
kontrolerach domeny lub serwerach w oddzielnym, istniejącym
fizycznie budynku lub piętrze, a nawet na kontrolerach domeny po
drugiej stronie połącze-nia WAN lub czegoś podobnego. Dla
każdych trzech do pięciu kontro-lerów domeny lub serwerów
instalujemy usługę WINS. Zapewnia to odporność na uszkodzenia
w razie konieczności naprawy lub awarii serwera WINS, a także
ogranicza obciążenie przypadające na pojedynczy serwer WINS.
Jako ostateczne minimum można mieć w sieci dwa serwery WINS,
co zapewni rozwiązywanie nazw NetBIOS-u w

razie awarii

pierwotnego serwera WINS - dokładnie tak, jak zapasowy kontroler
domeny zapewnia logowanie z

weryfikacją autentyczności

w przypadku, gdy zawiedzie kontroler podstawowy.

Scenariusz ten sprawdza się dobrze dla sieci Microsoftu,
korzystających ze stosów protokołu Microsoft T CP/IP, lecz
zawodzi, gdy użyjemy stosów protokołu T CP/IP od producentów
trzecich, które nie obsługują WINS w klientach sieciowych. Nie
oznacza to wcale, że w takiej sytuacji nie można używać WINS;
oznacza to tylko, że trzeba prócz tego zainstalować agentów proxy
WINS. Agent taki powinien zostać zainstalowany w

każdej

podsieci, aby zapewnić połączenie między nie-WINS-owymi
klientami i serwerami WINS. Poza tym serwery WINS powinny
współużytkować swą bazę danych, by pokryć całą sieć. T ego

DHCP, WINS i DNS

519

rodzaju proces współużytkowania możliwy jest dzięki replikacji
WINS, omówionej szczegółowo w dalszej części tego podrozdziału.

Uwaga: By obsłużyć klientów nie-WINS-owych, w bazie danych
WINS można dodatkowo utworzyć odwzorowania statyczne, na stałe
wiążące nazwy komputerów z ich adresami IP.

Ponieważ komunikaty rozgłaszane nie są przekazywane przez
rutery, dla każdej podsieci musi istnieć jeden agent proxy WINS.
Gdy klient nie-WINS-owy próbuje odszukać inny komputer, do
uzyskania jego adresu IP używa komunikatu rozgłaszanego. Jeśli
szukany komputer jest w tej samej podsieci, to zapytanie takie jest
skuteczne, lecz jeśli znajduje się poza nią, nasz klient nie otrzyma
żadnej odpowiedzi (chyba że mamy kontrolery domeny po obu
stronach ruterów). W tej sytuacji sprawdza się agent proxy WINS-
a.

Klient nr 1 jest klientem WINS, klient nr 2 - klientem nie-WINS-
owym, klient nr 3 jest agentem proxy WINS-a, a serwer nr 1 -
kontrolerem domeny Windows NT , na którym działa usługa WINS.
Gdy nie-WINS-owy klient nr 2 spróbuje uzyskać dostęp do WINS-
owego klienta nr 1, rozgłaszając zapytanie o adres IP klienta nr 1,
to zapytanie takie nie powiedzie się, ponieważ klient nr 1 i klient
nr 2 są w różnych podsieciach. Jednak rozgłoszony komunikat
zostaje przechwycony przez klienta nr 3, który odnajduje
i umieszcza w swym cache'u poszukiwany adres IP i odpowiadającą
mu nazwę, a prócz tego odsyła do klienta nr 2 adres IP klienta nr 1,
dzięki czemu połączenie T CP/IP może być ustanowione. Jeśli inny
klient WINS-owy w innej podsieci spróbuje skomunikować się
z klientem nr 2, wysyłając zapytanie o nazwę - do pytającego
klienta odesłany zostanie adres IP klienta nr 2, który klient nr 3
umieścił w swoim cache'u.

Agent proxy WINS nie zapisuje informacji, uzyskanej
z rozgłaszania, w bazie danych serwera WINS. Dlatego agentów
proxy musimy mieć w każdej podsieci, która zawiera klientów nie-
WINS-owych. W

tym wypadku agent proxy WINS może

odpowiadać na żądania rozwiązania nazw ze strony klientów lub
serwerów WINS i jednocześnie rozgłaszać komunikaty w swej
własnej podsieci w poszukiwaniu klientów nie-WINS-owych. Po

520

Rozdział 12

znalezieniu nie-WINS-owego klienta, jego adres może być w zwykły
sposób przekazany do tego klienta lub serwera WINS, który wysłał
zapytanie.

Gdy klient WINS chce uzyskać dostęp do innego komputera,
wysyła zapytanie z jego nazwą. Zapytanie to może być przekazane
do innych serwerów WINS, lecz ma to miejsce tylko wówczas, gdy
podstawowy lub zapasowy serwer WINS, właściwy takiemu
klientowi, nie zawiera wpisu dla żądanego komputera. Jeśli tak
rozesłane zapytanie o nazwę nie może być obsłużone przez żaden
z serwerów WINS, to klient WINS rozgłasza komunikat. Zarówno
komunikaty rozgłaszane, jak i

ukierunkowane komunikaty

z żądaniami rozróżnienia nazwy zajmują pewne pasmo
transmisyjne, które mogłoby być wykorzystane do przesyłania
użytecznych danych. Jeśli jednak nasze serwery WINS dysponują
kompletnymi listami nazw komputerów i ich adresów IP, to
podstawowy serwer WINS może wówczas odpowiedzieć na każde
pytanie o adres, zmniejszając ilość komunikatów rozgłaszanych
i zapytań przechodzących przez rutery.

Prowadzi to do kolejnego wniosku, istotnego z punktu widzenia
planowania i efektywności sieci: każdy serwer WINS w

sieci

powinien replikować swą bazę danych do innych serwerów WINS -
tak by każdy z nich dysponował pełną listą nazw i adresów IP dla
wszystkich klientów WINS. Metoda ta zapewnia najszybszy
mechanizm translacji nazw na adresy IP z ograniczeniem ilości
rozgłaszanych komunikatów i

przechodzących przez rutery

zapytań o adresy.

Serwery WINS oferują dwa mechanizmy replikacji:

Partnerów "push", czyli wysyłających: Są to serwery WINS,

które wysyłają powiadomienia o uaktualnieniach do swych
partnerów "pull" (czyli odbierających). Po otrzymaniu
komunikatu o uaktualnieniu, partner "pull" żąda od swego
partnera "push" nadesłania treści zmian. Wówczas partner
"push" wysyła mu replikę swojej bazy danych.

Partnerów "pull", czyli odbierających: Są to serwery WINS,

które żądają uaktualnień od swych partnerów "push", i gdy te
odpowiedzą, odbierają replikę bazy danych.

DHCP, WINS i DNS

521

Jak widać z opisu działania partnera wysyłającego i odbierającego,
stanowią one składniki pewnego zamkniętego procesu. By
zreplikować bazę danych WINS w jedną stronę, jeden serwer WINS
musi być partnerem wysyłającym, drugi zaś odbierającym. By bazę
tę w pełni zreplikować pomiędzy dwoma lub więcej serwerami
WINS, każdy z nich musi być partnerem zarówno wysyłającym, jak
i odbierającym drugiego serwera. Jest to więc dwukierunkowy
łańcuch nielinearny, którego można użyć do replikacji każdej bazy
danych WINS do dowolnej innej bazy danych WINS. Niektóre
serwery WINS otrzymują powiadomienia o uaktualnieniach od
więcej niż jednego serwera WINS, co prowadzi do zwiększenia ruchu
w sieci.

Metodą lepszą, choć nieco wolniejszą, jest utworzenie łańcucha
linearnego, w którym jeden i tylko jeden serwer WINS jest
partnerem wysyłającym lub odbierającym innego serwera WINS.
T ylko w łączu WAN reguła ta zostaje naruszona, gdyż obsługujący
je po stronie sieci lokalnej serwer WINS jest partnerem
wysyłającym i

odbierającym właściwego serwera WINS sieci

lokalnej, i

jednocześnie jest on partnerem wysyłającym

i odbierającym serwera WINS w łączu WAN. Prowadzi to do
następnego zagadnienia: jak często replikować? Istnieje metoda,
która uzależnia to od odległości między punktami replikacji
i prędkości łącza. Dla typowej sieci LAN 10 - 15 minut jest
okresem optymalnym, zważywszy na sporą prędkość transmisji.
W przypadku lokalnych, silnie obciążonych łączy WAN okres
replikacji należy zwiększyć do 30 - 60 minut. Zmniejszyć go
można tylko przy silnej fluktuacji uczestników sieci. Dla dłuższych
łączy WAN należy wybierać wartości rzędu 45 - 60 minut. Zaś dla
międzykontynentalnych łączy WAN wybieramy 6 - 12 godzin i to
w czasie najmniejszego natężenia ruchu. Ogólną zasadą jest, że im
silniej łącze jest obciążone, tym mniejsza jest częstotliwość
replikacji (czyli planuje się większą liczbę minut pomiędzy
kolejnymi próbami replikacji).

Instalowanie usługi WINS

Usługę serwera WINS instalujemy z apletu Network w Panelu
sterowania.

522

Rozdział 12

Uwaga: By zainstalować usługę serwera WINS, trzeba być
członkiem grupy Administrators na komputerze, na którym jest ona
instalowana.

Podczas instalacji wykonujemy następującą procedurę:

1. Uruchamiamy aplet

Netw ork

w Panelu sterowania.

2. Klikamy kartę

Serv ices

(Us³ugi), a następnie przycisk

Add

3. Z listy usług sieciowych wybieramy

Window s Internet Name

Serv ice

(

Usługę nazw internetowych dla Windows).

Uwaga: Jeśli nie mamy jeszcze TCP/IP, to zostanie on
automatycznie zainstalowany podczas instalowania usługi serwera
WINS.

Wskazówka: By do zdalnego konfigurowania usługi serwera WINS
używać SNMP, należy oprócz tego zainstalować usługę SNMP.

4. Klikamy

. Po wyświetleniu odpowiedniego polecenia

wpisujemy ścieżkę dostępu do plików dystrybucyjnych (na
przykład, f:\i386) i klikamy

Continue

5. Zamykamy okno konfiguracyjne

Netw ork

, klikaj¹c

Close

6. Po pojawieniu się odpowiedniego komunikatu restartujemy

system. Po ponownym jego uruchomieniu usługa serwera WINS
powinna wystartować. W

przeciwnym razie analizujemy

komunikaty o błędach w dzienniku zdarzeń systemu.

Konfigurowanie usługi WINS z użyciem M enedżera WINS

Przy pierwszym użyciu Menedżer WINS wyświetla jedynie serwery
WINS w lokalnej sieci. By dodać do niego inny serwer WINS,
należy wybrać

Serv er\Add WINS Serv er

i w oknie dialogowym

Add

WINS

Serv er

(Dodaj serwer WINS) podać adres IP lub nazwę

komputera. Aby usunąć serwer WINS z listy Menedżera WINS,
trzeba go zaznaczyć i wybrać

Serv er\Delete WINS Serv er

. Serwer,

świeżo dodany do lokalnego menedżera WINS, należy
zoptymalizować pod względem wydajności. Obejmuje to

DHCP, WINS i DNS

523

modyfikowanie konfiguracji serwera WINS, konfiguracji jego
partnerów replikacyjnych oraz preferencji. Każda z tych opcji
realizuje nieco inne zadanie (omówione w tym podrozdziale).

Opcją, którą najlepiej wybrać jako pierwszą, jest

Serv er\

Configuration

(Serwer\Konfiguracja). Wyświetla ona okno

dialogowe

WINS Serv er Configuration

(Konfiguracji Serwera

WINS) (patrz rysunek 12.9).

W oknie tym można ustawić następujące opcje:

Renew al Interv al

(Okres odnawiania): Określa, jak często

klient WINS musi rejestrować swoją nazwę w serwerze WINS.
Okresem domyślnym jest 6 dni.

Extinction Interv al

(Okres wygaśnięcia): Określa odstęp czasu

od momentu, gdy rekord zostaje oznaczony jako zwolniony - do
chwili, gdy zostaje oznaczony jako wygasły. Okresem
domyślnym i zarazem maksymalnym jest 6 dni.

Extinction Timeout

(Limit czasowy do wygaśnięcia): Określa

odstęp czasu od momentu, gdy rekord zostaje oznaczony jako
wygasły - do chwili, gdy zostaje usunięty z bazy danych.
Okresem domyślnym jest 6 dni, minimalnym 1 dzień.

Uwaga: Okres wygaśnięcia i domyślny limit czasu dla wygaśnięcia
są, w przypadku w pełni skonfigurowanego serwera WINS, oparte
na czasie odnawiania i tym, czy serwer WINS ma partnerów
replikacyjnych w sieci.

Rys. 12.9.
Rozwinięte okno
dialogowe W INS
Server
Configuration
( Konfiguracji
serwera W INS).

524

Rozdział 12

Wskazówka: Bazę danych można wyczyścić ręcznie, wybierając

Mapping\Initiate Scavenging

(Mapowania\Zainicjuj czyszczenie).

Proces ten usuwa przeterminowane rekordy z bazy danych.

Verify Interv al

(Okres weryfikacji): Określa odstęp czasu, po

upływie którego serwer WINS musi sprawdzić, czy stare nazwy
posiadane przez inny serwer WINS są nadal ważne. Wartość
domyślna (24 dni) zależy od okresu wygaśnięcia. Wartością
maksymalną jest 24 dni.

Pull Parameters

(Parametry odbierania): Okres replikacji dla

partnera odbierającego (pull partner) ustawiany jest w oknie
dialogowym

Preferences

, tak jak to opisano w dalszej części

podrozdziału. Jeśli chcielibyśmy, by replikacja była uaktywniana
w chwili uruchomienia usługi serwera WINS, należy zakreślić
pole opcji

Initial Replication

(Replikacja początkowa) i w polu

listy

Retry Count

(Licznik ponowień) wpisać odpowiednią liczbę.

Push Parameters

(Parametry wysyłania): By określić

konfigurację partnerów wysyłających (push partners),
mamy do dyspo-zycji następujące opcje:

Initial Replication

(Replikacja początkowa): Gdy ustawienie to

jest uaktywnione, partnerzy wysyłający zostają w momencie
uruchomienia usługi serwera WINS poinformowani, że nastąpiła
zmiana.

Replicate on Address

Change

(Replikacja przy zmianie

adresu): Gdy ustawienie to jest uaktywnione, partnerzy
wysyłający zostają poinformowani o każdej zmianie lub dodaniu
nowego wpisu w bazie danych.

Adv anced

(Zaawansowane): Rozszerzywszy okno dialogowe

WINS Serv er Configuration

kliknięciem przycisku

Adv anced

uzyskujemy dostęp do następujących opcji:

Logging Enabled

(Rejestrowanie włączone): Określa, że usługa

serwera WINS będzie rejestrować zmiany w

bazie danych

i informować o najważniejszych błędach w dzienniku zdarzeń
systemu. Domyślnie uaktywniona.

Log Detailed Ev ents

(Rejestruj zdarzenia szczegółowo):

Określa, że do dziennika zdarzeń systemu wpisywane będą

DHCP, WINS i DNS

525

wszystkie zdarzenia. Opcji tej należy używać tylko przez ściśle
ograniczony czas (gdy np. badamy usterki w pracy serwera
WINS), ponieważ może ona zaangażować znaczne zasoby
i pogorszyć wydajność systemu. Domyślnie wyłączona.

Replicate Only w ith Partners

(Replikuj tylko z partnerami):

Pozwala na replikację tylko z

partnerami wysyłającymi

i odbierającymi. Gdy opcja ta jest nieczynna, dane można
replikować z każdego, nie umieszczonego na liście, serwera
WINS. Domyślnie uaktywniona.

Backup on Termination

(Kopiowanie zapasowe przy zatrzyma-

niu): Powoduje, że przy zatrzymywaniu usługi serwera WINS
jego baza danych zostaje automatycznie zarchiwizowana. Nie
wykonuje jednak archiwizacji wtedy, gdy zatrzymywany jest cały
system. Domyślnie uaktywniona.

Migrate On/Off

(Migracja włączona/wyłączona): Umożliwia

traktowanie rekordów statycznych lub wielobazowych jako
dynamicznych wówczas, gdy są w konflikcie z nową rejestracją
lub repliką (danymi skopiowanymi z innego serwera WINS).
Opcję tę należy uaktywnić przy przechodzeniu z systemu nie-
windowsowego (jak serwer LAN Manager ) do serwera Windows
NT . Domyślnie wyłączona.

Starting Version Count

(Wyjściowy numer wersji): Określa

najwyższy numer wersji bazy danych. Wartości tej normalnie nie
trzeba zmieniać; jeśli jednak odtwarzamy bazę danych WINS
z kopii zapasowej, ponieważ pierwotna została uszkodzona, to –
aby zapewnić poprawną replikację – należy ją tak zmienić, by
była większa od wartości wersji dla każdej innej kopii u
partnerów serwera WINS.

Uwaga: Jej bieżącą wartość można wyświetlić, wybierając opcję
menu

View\Database

. By zobaczyć numer wersji na innych

serwerach, przed wybraniem opcji należy zaznaczyć serwer WINS.

Database Backup Path

(Ścieżka archiwizowania bazy danych):

Określa pełną ścieżkę dostępu do kopii zapasowych

Zalecamy także określenie ustawień preferencyjnych dla
Menedżera WINS i domyślnych - dla usługi WINS. Do preferencji

526

Rozdział 12

dojść można wybierając

Options\Preferences

(Opcje\Preferencje)

i wyświetlając okno dialogowe pokazane na rysunku 12.10.

W oknie tym można wykonać następujące czynności:

Określić, jak Menedżer WINS wyświetlać będzie nazwy tych

serwerów WINS, z którymi jest połączony, a przy okazji wybrać
mechanizm używany do podłączania się do usługi. Możliwości są
tu następujące:

♦

Computer Name Only

(T ylko nazwa komputera): Określa,

że wyświetlana będzie sama nazwa komputera, a

podłączania się do serwera WINS używane będą nazwane
potoki.

♦

IP Address Only (

T ylko adres IP): Określa, że wyświetlany

będzie sam adres IP, a do podłączania się do serwera WINS
używany będzie T CP/IP.

♦

Computer Name

(

IP Address)(Nazwa komputera (adres IP)):

Określa, że wpierw wyświetlana będzie nazwa komputera,
a po niej adres IP, zaś do podłączania się do serwera WINS
używane będą nazwane potoki.

♦

IP Address

(Computer Name) (Adres IP (nazwa

komputera)): Okresla, że najpierw wyświetlany będzie adres
IP, a po nim nazwa komputera, zaś do podłączania się do
serwera WINS używany będzie T CP/IP.

Określić okres odświeżania, uaktualniającego obraz Menedżera

WINS. Jeśli zakreślone zostanie pole opcji

Auto

Refresh

(Odświeżanie automatyczne), to trzeba także podać wartość
(ilość sekund, jaka ma upłynąć przed kolejnym odświeżeniem
obrazu) w polu

Interv al

(Okres).

Rys. 12.10.

Określanie

preferencji dla

Menedżera W INS

i ustawień

domyślnych dla

usługi serwera

W INS.

DHCP, WINS i DNS

527

Uwaga: Ponadto Obraz Menedżera WINS jest odświeżany
automatycznie za każdym razem, gdy podejmiemy w nim jakąś
akcję.

Określić kompatybilność nazw NetBIOS-owych. Jeśli zakreślone

jest pole opcji

LAN Manager Compatible

(Kompatybilny

z LAN Manager) (ustawienie domyślne), to nazwy NetBIOS-u
ograniczone są do 15 bajtów dla samej nazwy i 16 bajtów - dla
specjalnego kodu określającego mapowania statyczne. Jeśli
korzystamy z

aplikacji, wymagających 16-bitowych nazw

NetBIOS-u (jak choćby z Lotus Notes), to opcja ta powinna być
wyłączona. A oto wspomniane wyżej specjalne kody:

0x0

Oznacza, że ta nazwa NetBIOS-owa używana
jest przez redirektor.

0x1

Oznacza, że ta nazwa NetBIOS-owa używana
jest przez główną przeglądarkę domeny.

0x3

Oznacza, że ta nazwa NetBIOS-owa używana
jest przez usługę wiadomości.

0x20

Oznacza, że ta nazwa NetBIOS-owa używana
jest przez serwer LAN Managera.

0x1B

Oznacza nazwę

głównej przeglądarki

domeny, której winni używać klienci i inne
przeglądarki w

celu skontaktowania się

z przeglądarką główną.

0x1E

Oznacza, że ta nazwa NetBIOS-owa używana
jest przez normalną grupę.

0x1D

Oznacza, że ta nazwa NetBIOS-owa używana
jest do rozwiązywania nazwy klienta, gdy
wykonywana jest próba nawiązania kontaktu
z przeglądarką główną w

celu otrzymania

listy serwerów.

0x1C

Oznacza, że ta nazwa NetBIOS-owa jest
nazwą grupy internetowej. Nazwa takiej
grupy zawiera adres podstawowego
i

zapasowego kontrolera danej domeny

528

Rozdział 12

(ograniczona jest 25 adresów).

Określić rozmaite opcje wsparcia:

♦

Validate Cache of „Know n” WINS Serv er at Startup Time
(

Weryfikacja cache'a "znanych" serwerów WINS w czasie

uruchamiania): Jeśli opcja ta jest uaktywniona, to przy
każdym swym uruchomieniu Menedżer WINS próbuje
podłączyć się do wszystkich serwerów WINS, które dodaliśmy
do jego listy. Jeśli z

którymś z

nich nie może się

skontaktować, zostaniemy popro-szeni o usunięcie go z listy
podłączonych serwerów. Domyślnie wyłączona.

♦

Confirm Deletion of Static Mappings & Cached WINS
serv ers

(Potwierdzanie przy usuwaniu mapowań statycznych

cache'owanych serwerów WINS): Opcja ta, jeśli jest

uaktywniona (co jest jej ustawieniem domyślnym), wyświetla
komunikat z żądaniem potwierdzenia za każdym razem, gdy
próbujemy usunąć odwzorowanie statyczne lub cache'owany
serwer WINS. T e nieustannie powtarzające się komunikaty
mogą być męczące, więc można ustawienie to wyłączyć.
Jednak przed wyłączeniem warto dobrze zaznajomić się
z Menedżerem WINS.

Jeśli klikniemy przycisk Partners, okno dialogowe rozwinie się
i

pozwoli na ustawianie wartości domyślnych dla replikacji

z partnerami. A oto dostępne tam ustawienia:

New Pull Partner Default Configuration (Domyślna

konfiguracja nowego partnera odbierającego): Ustawienia w tej
grupie określają domyślne ustawienia replikacyjne dla nowych
partnerów odbierających, tworzonych dla aktualnie wybranego
serwera WINS. Należą do nich:

♦ Start Time (Czas startu): Czas rozpoczęcia replikacji bazy

danych naszego serwera WINS. Nie ma on wartości
domyślnej.

♦ Replication Interval (Okres replikacji): Czas, po którym

replikacja bazy danych serwera WINS jest powtarzana. Nie
ma wartości domyślnej.

♦ New Push Partner Default Configuration (Domyślna

konfiguracja nowego partnera wysyłającego): Ustawienie

DHCP, WINS i DNS

529

w tej grupie określa ilość zmian, jakie muszą zajść w bazie
danych serwera WINS, zanim do partnerów wysyłających,
tworzonych dla aktualnie wybranych serwerów WINS,
przesłane zostanie powiadomienie o wysyłaniu.

♦ Update Count (Licznik uaktualnień): Określa ilość zmian,

jakie muszą nastąpić, by zostało wysłane powiadomienie
o wysyłaniu. Nie ma wartości domyślnej, optymalną jest
1000.

Zalecamy, by ustawień replikacyjnych dla lokalnego serwera WINS
dokonywać wybierając

Serv er\Replication Partners

. Spowoduje to

wyświetlenie okna dialogowego

Replication

Partners

, pokazanego

na rysunku 12.11. Aby dodać serwery WINS, które będą
skonfigurowane jako lokalni partnerzy wysyłający lub odbierający,
klikamy przycisk

Add

. Można zdecydować się na replikowanie do

dowolnego lub nawet wszystkich serwerów WINS w konfiguracji
nielinearnej, lub też odbierać z jednego serwera WINS i wysyłać do
innego w

układzie linearnym. T echniki te opisano bardziej

szczegółowo w podrozdziale zatytułowanym "Planowanie instalacji
WINS".

Uwaga: Aby usunąć serwer z listy serwerów WINS, należy go wybrać
i nacisnąć klawisz DEL.

Po dodaniu serwerów WINS można wykonać następujące
czynności:

Rys. 12.11.
W ybieranie
partnerów
replikacyjnych
dla serwera
W INS.

530

Rozdział 12

Określić, które serwery WINS będą wyświetlane na liście

WINS

Serv er

, włączając i wyłączając opcje w polu

WINS

Serv ers

List

(Wyświetlanych serwerów WINS). Są to następujące opcje:

♦

Push Partners

(Partnerzy wysyłający): Jeśli jest

uaktywniona (ustawienie domyślne), to wyświetlani są
partnerzy wysyłający danego serwera WINS.

♦ Pull Partners (Partnerzy odbierający): Jeśli jest

uaktywniona (ustawienie domyślne), to wyświetlani są
partnerzy odbierający danego serwera WINS.

♦

Other

(Inni): Jeśli jest uaktywniona (ustawienie domyślne),

wyświetlani są wszyscy nie-partnerzy danego serwera WINS.

Określić w polu Replication O ptions dla aktualnie wybranego

serwera WINS, indywidualne ustawienia jako partnera wysyła-
jącego, odbierającego lub jednocześnie odbierającego i wysyła-
jącego. Jeśli wybierzemy serwer WINS, który już jest skonfi-
gurowany jako partner wysyłający lub odbierający, uaktywnione
zostają następujące przyciski

Configure

♦

Push Partner

: Jego uaktywnienie sygnalizuje, że wybrany

serwer WINS jest partnerem wysyłającym. Jeśli klikniemy
przycisk

Configure

, wyświetlone zostanie okno

Push

Properties

(Właściwości wysyłania), w którym można będzie

odczytać lub ustawić licznik uaktualnień.

♦

Pull Partner

: Jego uaktywnienie sygnalizuje, że wybrany

serwer WINS jest partnerem odbierającym. Jeśli klikniemy
przycisk

Configure

, wyświetlone zostanie okno

Pull

Properties

(Właś-ciwości odbierania), w

którym można

odczytać lub ustawić czas startu i okres replikacji.

Wskazówka: Jeśli w oknie dialogowym Preferences ustawiliśmy
wartości domyślne, to ustawienia te zostaną automatycznie nadane
nowym partnerom odbierającym i

wysyłającym. Jeśli jednak

nowego partnera - wysyłającego lub odbierającego -
konfigurujemy poprzez łącze WAN, należy ustawić większe wartości,
jak to opisano w

podrozdziale zatytułowanym "Planowanie

instalacji WINS".

DHCP, WINS i DNS

531

Zainicjować replikację natychmiast, bez czekania na jej

rozpoczęcie w momencie określonym na podstawie okresu
replikacji ustawio-nego w oknie dialogowym

Configuration

wybierając następujące przyciski w grupie

Send

Replication

Trigger

Now

(T eraz wydaj polecenie replikacji):

♦

Push

(Wysyłanie): Inicjuje on przesłanie polecenia

rozpoczęcia wysyłania do wybranego serwera WINS.

♦

Pull

(Odbieranie): Inicjuje on przesłanie polecenia

rozpoczęcia odbierania do wybranego serwera WINS.

♦

Push w ith Propagation

(Wysyłanie z

propagacją):

Modyfikuje komunikat żądający wysłania - tak, by zmiany,
wysłane do wybranego serwera WINS, rozgłoszone zostały do
wszystkich innych partnerów odbierających wybranych
serwerów WINS.

Wskazówka: Pełną replikację wybranych serwerów WINS można
zainicjować, klikając przycisk

Replicate Now

Zarządzanie klientami nie-WINS-owymi

Zarządzanie klientami nie-WINS-owymi polega na tworzeniu
odwzorowań statycznych, czyli rekordów z trwałymi skojarzeniami
nazw z adresami IP, i na przeglądaniu aktualnych rekordów bazy
danych. Gdy tworzymy odwzorowanie statyczne, dobrze jest
również utworzyć dla danego adresu IP rezerwację (jak to opisano
w podrozdziale "Zarządzenie rezerwacjami dla klientów"), tworząc
sobie tym samym warunki do łatwiejszego zarządzania na
przyszłość. Odwzorowania statyczne dodajemy wybierając

Mappings\Static

Mappings

(Mapowania\Mapowania statyczne),

co wyświetli okno dialogowe, pokazane na rysunku 12.12. Gdy
klikniemy przycisk

Add

Mapping

, pojawi się z

kolei okno

dialogowe

Add Static Mapping

(Dodaj mapowanie statyczne).

Można w nim wpisać nazwę, adres IP i typ komputera, który ma
być dodany do bazy danych serwera WINS. T abela 12.4 wylicza
specjalne nazwy, których serwer WINS przy tej operacji używa
i opisuje ich funkcję. Odwzorowanie statyczne można usunąć,

532

Rozdział 12

zaznaczając je w polu dialogowym

Static Mappings

(Mapowań

statycznych) i klikając przycisk

Delete Mapping

Wskazówka: By zapewnić wsparcie komputerom nie-WINS-owym,
można odwzorowania statyczne importować grupowo, importując
plik

hosts

z serwera DNS.

Tabela 12.4. Nazwy specjalne serwera WINS

Typ

O pis

Unique
(unikatowy)

Nazwa normalna oznaczająca, że z

danym

adresem IP związana będzie tylko jedna nazwa
komputera.

Group
(grupa)

Nie ma odpowiadającego jej adresu IP. Zamiast
tego, jeśli w serwerze WINS zarejestrowana jest
pewna nazwa grupy i otrzymane zostanie zapyta-
nie o tę właśnie nazwę, serwer WINS zwróci adres
rozgłaszania (FFFFFFFF), a

pytający klient

rozgłosi komunikat o poszukiwaniu żądanego
komputera.

Multuhomed
(wielobazowy)

Nazwa, z którą związanych jest kilka adresów IP.
Urządzenie wielobazowe posiada dwie lub więcej
kart sieciowych, które mogą zarejestrować każdy
ze związanych z

komputerem adresów IP,

wysyłając specjalny pakiet rejestracji nazwy.
Wielobazowa nazwa grupowa może zawierać do
25 adresów IP.

Rys. 12.12. Okno
dialogowe Static
Mappin.

DHCP, WINS i DNS

533

Typ

O pis

Internet

Nazwa grupowa, zawierająca adresy IP kontrolera
domeny. WINS udziela preferencji
w

zarejestrowaniu takiej nazwy 25-ciu

najbliższym adresom. Po otrzymaniu zapytania
o domenę, do klienta zwracany jest adres
kontrolera domeny i

dodatkowo 24

(maksymalnie) adresów IP.

Zarządzanie bazami danych WINS

Ponieważ serwer WINS używa tego samego formatu bazy danych
(zmodyfikowanej bazy danych Access) co DHCP, to w dziedzinie
zarządzania nią dotyczą go te same podstawowe zalecenia. W miarę
dodawania i usuwania rekordów, rozmiar bazy rośnie. Bazy danych
WINS umieszczone są w katalogu %SystemRoot%\System32
\WINS

i obejmują następujące pliki:

WINS.MDB: baza danych WINS

WINSTMP.MDB: plik tymczasowy utworzony przez serwer

DHCP

JET.LOG: zawiera rekordy transakcji

SYSTEM.MDB: zawiera informacje strukturalne o

bazach

danych WINS.

T akie rozrastanie się bazy danych wpływa ujemnie na szybkość
pracy serwera WINS. Gdy baza danych WINS.MDB osiągnie granicę
30 MB, należy ją skompresować. By tego dokonać, użyć trzeba
następującej procedury:

1. Zatrzymujemy usługę serwera WINS w aplecie

Serv ices

(Usługi)

Panelu sterowania, albo wydając polecenie net stop wins
z wiersza poleceń konsoli.

2. Z wiersza poleceń konsoli uruchamiamy program

JETPACK.EXE

, znajdujący się w

katalogu

%SystemRoot%\System32\

. Składnia dla programu jest

następująca:

534

Rozdział 12

JETPACK

DatabaseName TemporaryDatabaseName

gdzie:

DatabaseName

jest nazwą bazy danych, która ma być

skompresowana. Może to być w pełni kwalifikowana ścieżka
dostępu.

TemporaryDatabaseName

jest nazwą, jaką otrzyma

tymcza-sowa baza danych. Również i ona może być w pełni
kwalifikowaną ścieżką dostępu.

Ostrzeżenie: Nie wolno kompresować pliku

SYSTEM.MDB

. Gdyby

został skompresowany, usługa serwera WINS nie wystartuje.
W takim wypadku należy odtworzyć konfigurację z poprzedniej
kopii zapasowej.

3. Uruchamiamy usługę serwera WINS z apletu

Serv ices

w Panelu

sterowania, albo wydając polecenie net start wins z wiersza
poleceń konsoli.

Wskazówka: Przed zarchiwizowaniem lub skompresowaniem bazy
danych należy wykonać polecenie

Mappings\Initiate

Scavenging

(Mapowanie\Rozpocznij czyszczenie), aby usunąć z

niej stare,

niepotrzebne rekordy.

Wskazówka: Ze względu na to, że w

przypadku narzędzia

kompresującego istnieje potencjalna możliwość niepowodzenia
kompresji lub nawet zwykłego uszkodzenia danych w partycji

%SystemRoot%

, bazy danych WINS należy archiwizować

regular-nie, a już obowiązkowo przed kompresowaniem. Można to
zrobić wy-bierając

Mappings\Backup Database

(Mapowania

\Archiwizuj bazę danych). Należy bezwzględnie wykonać
archiwizację pełną, wyłącza-jąc opcję

Perform Incremental

Backup

(Wykonaj archiwizację inkrementalną), jeśli otrzymaną

kopię zamierzamy wykorzystać do odtworzenia konfiguracji.

DHCP, WINS i DNS

535

M onitorowanie usługi serwera WINS

Chociaż WINS Manager wyświetla te same statystyki, co
pokazywane przez Monitor wydajności, to Menedżer WINS podaje
je tylko dla aktualnie wybranego serwera WINS. Jeśli natomiast
użyjemy Monitora wydajności, to będziemy mogli monitorować
kilka serwerów jednocześnie, co może stanowić nieocenioną pomoc
przy porównywaniu wydajności kilku serwerów WINS. W tabeli
12.5 wyliczono dostępne w serwerze WINS liczniki wydajności dla
obiektów, które można wykorzystać do monitorowania wybranego
serwera WINS. Więcej szczegółów na temat Monitora wydajności
znaleźć można w rozdziale 19.

Tabela 12.5 Dostępne w Monitorze wydajności typy obiektów i ich

liczniki dla serwera WINS

Licznik obiektu

O pis

Failed Queries/sec
(nieudane zapytania/sek.)

Całkowita ilość nieudanych zapytań
na sekundę.

Failed Releases/sec
(nieudane zwolnienia/sek.)

Całkowita ilość nieudanych zwolnień
na sekundę.

Group Conflicts/sec
(konflikty dla grup/sek.)

Częstotliwość, z

jaką

żądania

rejestracji grup, otrzymywane przez
serwer WINS, wywoływały konflikty
z rekordami w bazie danych.

Group Registrations/sec
(rejestracje grup/sek.)

Częstotliwość, z jaką serwer WINS
otrzymuje żądania rejestracji grup.

Group Renewals/sec
(odnowienia grup/sek.)

Częstotliwość, z jaką serwer WINS
otrzymuje żądania odnowienia grup.

Queries/sec
(zapytania/sek.)

Częstotliwość, z jaką serwer WINS
otrzymuje zapytania.

Releases/sec
(zwolnienia/sek.)

Częstotliwość, z jaką serwer WINS
otrzymuje zwolnienia.

Successful Queries/sec
(udane zapytania/sek.)

Całkowita ilość poprawnie
obsłużonych zapytań na sekundę.

Successful Releases/sec

Całkowita ilość poprawnie

536

Rozdział 12

Licznik obiektu

O pis

(udane zwolnienia/sek.)

obsłużonych zwolnień na sekundę.

T otal Number of
Conflicts/sec
(całkowita ilość
konfliktów/sek.)

Suma konfliktów unikatowości i grup
na sekundę. Jest to całkowita
częstotliwość, z jaką serwer WINS
„widzi” konflikty.

T otal Numer of
Registrations/sec
(całkowita ilość
rejestracji/sek.)

Suma rejestracji unikatowych i grupo-
wych na sekundę. Jest to całkowita
częstotliwość, z jaką serwer WINS
otrzymuje rejestracje.

T otal Numer of
Renewals/sec
(całkowita ilość
odnowień/sek.)

Suma odnowień unikatowych i grupo-
wych na sekundę. Jest to całkowita
częstotliwość, z jaką serwer WINS
otrzymuje odnowienia.

Unique Conflicts/sec
(konflikty unikatowe/sek.)

Częstotliwość, z

jaką rejestracje

i odnowienia

unikatowe,

otrzymywane przez serwer WINS,
powodują konflikty z

rekordami

w bazie danych.

Unique Registrations/sec
(rejestracje unikatowe/sek.)

Częstotliwość, z jaką serwer WINS
otrzymuje rejestracje unikatowe.

Unique Renewals/sec
(odnowienia unikatowe/sek.)

Częstotliwość, z jaką serwer WINS
otrzymuje odnowienia unikatowe.

Wskazówka: Aby uzyskać ogólny obraz wydajności serwera WINS,
najlepiej monitorować całkowitą ilość konfliktów, rejestracji
i odnowień. Należy także monitorować nieudane zapytania
i zwolnienia.

Posługiwanie się kluczami Rejestru dla serwera WINS

Podobnie jak usługa serwera DHCP, także i usługa serwera WINS
swe informacje konfiguracyjne przechowuje w Rejestrze. I podobnie
jak w wypadku DHCP, także i tutaj trzeba niekiedy sięgnąć do
Rejestru, by zmienić jedno lub więcej ustawień konfiguracyjnych,
ale tylko gdy nie możemy ustawić ich przy pomocy Menedżera

DHCP, WINS i DNS

537

WINS lub gdy administrujemy nieaktywnym serwerem WINS.
Zastrzeżenie to przypominamy raz jeszcze, ponieważ w razie
niewłaściwego użycia Registry Editor (Edytora Rejestru) system
można tak uszkodzić, że nie będzie go już można naprawić.
W

rozdziale 18 podano dodatkowe informacje i

wskazówki

odnośnie archiwizowania aktualnego Rejestru przed użyciem
edytora (REGEDIT32.EXE).

Poniższe, podstawowe klucze Rejestru umieszczone są w kluczu
HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\WINS\Parameters

DbFileNm: określa pełną ścieżkę dostępu do miejsca, gdzie

znajduje się plik bazy danych WINS. Domyślnie jest to

%SystemRoot%\System32\WINS\WINS.MDB

DoStaticDataInit: jeśli pozycja ta ustawiona jest na 1,

serwer WINS inicjalizuje swoją bazę danych rekordami z jednego
lub kilku plików w podkluczu DataFiles. Inicjalizacja ta reali-
zowana jest w czasie wykonywania tego procesu lub za każdym
razem, gdy nastąpi zmiana w podkluczu Parameters lub
Datafiles

. Jeśli zostanie ustawiona na wartość domyślną,

wówczas inicjalizacja nie odbywa się.

InitTimePause: jeśli pozycja ta ustawiona jest na 1, to

usługa WINS uruchamia się w trybie wstrzymania. W stanie tym
pozostaje dopóty, dopóki nie dokona replikacji ze swymi
partnerami (wysyłanie lub odbieranie) lub replikacja nie
powiedzie się (przynajmniej raz). Jeśli pozycja ta ustawiona jest
na 1, to dla właściwego działania systemu podklucz
\WINS\Partner\Pull\ InitTimeReplication
powinien mieć wartość 1 lub być usunięty z Rejestru. Wartość 0
(domyślna) wyłącza omawianą opcję. Uwaga: wartość klucza
InitTimeReplication

można ustawić wybierając

Options\Preferences

klikając przycisk

Adv anced

(Zaawansowane), aby rozwinąć okno dialogowe.

LogFilePath: określa położenie plików dziennika dla

serwera WINS. Domyślnie jest to
%SystemRoot%\System32\WINS

McastIntvl: określa w sekundach odstępy czasu, w których

serwer WINS wysyła komunikat grupowy (multicast)

538

Rozdział 12

i oznajmia o sobie innym serwerom WINS. Wartością domyślną
i minimalną zarazem jest 2400 (40 minut).

McastTtl: określa, ile razy ogłoszenie grupowe może przejść

przez określony ruter. Wartością domyślną jest 6, dozwolony
zakres zawiera się w przedziale od 1 do 32.

NoOfWrkThds: określa ilość roboczych wątków (thread),

wykorzystywanych przez serwer WINS. Wartością domyślną
jest jeden wątek na jeden proces w systemie, a dozwolony zakres
sięga od 1 do 40. (Uwaga: wartość tę można zmienić i uaktywnić
bez restartowania usługi WINS).

PriorityClassHigh: jeśli pozycja ta ustawiona jest na 1,

pozwala ona usłudze WINS działać w

klasie wysokiego

priorytetu. Uniemożliwia to innym aplikacjom i

usługom,

działającym z niższym priorytetem, wywłaszczać (preempt)
usługę WINS. Domyślnie jest to 0. (Uwaga: jeśli zdecydujemy się
uaktywnić to ustawienie, należy koniecznie monitorować system
za pomocą Monitora wydajności - dla upewnienia się, że usługa
WINS nie zużywa zbyt wiele czasu procesora, a inne aplikacje
i usługi mogą nadal pracować zadowalająco).

UseSelfFndPnrs: opcja ta służy do takiego

skonfigurowania usługi WINS, by automatycznie wyszukiwała
inne serwery WINS i

konfigurowała je jako partnerów

wysyłających i odbierających. Pozycję tę można ustawić na 1
(uaktywnić) lub 0 (wyłączyć). Domyślnie jest to 0. Jeśli
partnerzy wysyłający i

odbierający zostaną skonfigurowani

ręcznie za pomocą Menedżera WINS, to w razie wystąpienia
zmiany w

partnerstwie informacja o

tym nie jest już

automatycznie uaktualniana.

DHCP, WINS i DNS

539

Uwaga: Jeśli opcja

UseSelfFndPnrs

zostanie uaktywniona, to

usługa WINS tylko wtedy skonfiguruje poprzez rutery serwery WINS
jako partnerów wysyłających i

odbierających, gdy rutery te

obsługiwać będą komunikaty grupowe. W

przeciwnym razie,

w charakterze partnerów skonfigurowane zostaną automatycznie
tylko te serwery, które znajdują się w lokalnej sieci. Jeśli nasze
rutery obsługują komunikaty grupowe, ustawienie

UseSelfFndPnrs

może okazać się bardzo użyteczne, gdyż

uwalnia ono od pracy związanej z ręcznym konfigurowaniem
partnerów wysyłających i odbierających.

Poniższe klucze Rejestru można skonfigurować wybierając

Serv er\Configuration

i modyfikując odpowiednie pola w oknie

dialogowym

WINS Serv er Configuration

BackupDirPath: określa pełną ścieżkę dostępu do miejsca,

które ma być użyte do archiwizowania bazy danych WINS.

DoBackupOnTerm: jeśli klucz ten jest uaktywniony (1), baza

danych WINS jest archiwizowana zawsze, gdy zakończona
zostaje usługa WINS. Gdy jest wyłączony (0), baza danych nie
jest archiwizowana. Domyślnym ustawieniem jest 1. (Uwaga:
archiwizowanie nie odbywa się, gdy zatrzymywany jest cały
system; następuje tylko wtedy, gdy usługa jest zatrzymywana
ręcznie).

LogDetailedEvents: uaktywniony sprawia, że

rejestrowanie zdarzeń WINS-a w dzienniku jest szczegółowe.
Domyślnie wyłą-czony (0).

LoggingOn: gdy jest uaktywniony (1), komunikaty WINS-a

umieszczane są w dzienniku zdarzeń. Gdy jest wyłączony (0),
w dzienniku zdarzeń nie są zapisywane żadne komunikaty.
Domyślnie równy 1.

RefreshInterval: określa w sekundach czas, po upływie

którego klient musi zarejestrować swą nazwę w serwerze WINS.
Domyślnie równy 0x54600 (4 dni).

RplOnlyWCnfPnrs: włącza (1) lub wyłącza (0) zdolność do

replikowania serwera WINS z innego serwera WINS, który nie
jest partnerem. Domyślnie równy 1.

540

Rozdział 12

MigrateOn: włącza (1) lub wyłącza (0) traktowanie rekordów

unikatowych i wielobazowych jako dynamicznych - w przypadku
wykrycia w trakcie rejestracji konfliktu. Domyślnie 0.

TombstoneInterval: określa w sekundach czas pomiędzy

zwolnieniem rekordu klienta a

oznaczeniem go jako

przeterminowany. Domyślnie wynosi 0x54600 (4 dni).

TombstoneTimeout: określa w sekundach czas pomiędzy

oznaczeniem rekordu klienta jako przeterminowanego
a usunięciem go z bazy danych. Domyślnie wynosi 0x54600 (4
dni).

VerifyInterval: określa odstęp czasu, w jakim serwer

WINS musi sprawdzać, czy stare nazwy, których nie jest
właścicielem, są nadal ważne. Domyślnie wynosi 0x1FA400 (24
dni).

W kluczu

HKEY_LOCAL_MACHINE\System\Current

ControlSet

\Services\WINS\Partners

umieszczone są następujące,

związane z replikacją między partnerami, klucze Rejestru:

PersonaNonGrata: określa adres IP serwera WINS,

z którego nie chcemy replikować danych. Klucz ten może
przydać się admini-stratorowi do zablokowania replikacji z tych
serwerów WINS, które nie są pod jego kontrolą.

Pull\<IPAddress>\MemberPrec: określa według

priorytetu kolejność adresów w grupie internetowej. Wartości
wynosić mogą od 0 - dla niskiego priorytetu do 1 - dla
wysokiego. Domyślnie wynosi 0. Uwaga: pozycja ta pojawia się
pod adresem IP (serwera WINS).

Praca z serwerem systemu nazw domeny DNS

Odmiennie niż WINS i DHCP, które liczą sobie zaledwie dwa lata,
DNS jest na arenie T CP/IP prawdziwym weteranem. Jego
podstawowym zadaniem jest umożliwienie lokalizowania zasobów
przy użyciu przyjaznych dla użytkownika nazw komputerów, a nie
liczbowych adresów IP. Proces ten określany jest często jako
rozwiązywanie nazw (name resolution). DNS opracowano kilka lat
temu, w

celu rozwiązania problemu dramatycznego rozrostu

Internetu i zdefiniowano w RFC 1034 i 1035. Ponieważ jego rozwój

DHCP, WINS i DNS

541

koncentrował się wokół Internetu, który nie ma jednego ośrodka
kierowniczego, DNS używa architektury hierarchicznej,
umożliwiającej dystrybucję baz danych z nazwami i decentralizację
zadań administracyjnych.

WINS i DNS wykazują zarówno liczne podobieństwa, jak i wiele
różnic, zarówno w przeznaczeniu jak i praktycznej implementacji.
O ile WINS zapewnia dynamiczne rozwiązywanie nazw, DNS opiera
się na statycznych plikach konfiguracyjnych. Z drugiej jednak
strony, DNS dopuszcza nazewnictwo hierarchiczne, podczas gdy
WINS - ze względu na swój związek z NetBIOS-em - dostarcza
jedynie płaskiej przestrzeni nazw. Głównym zadaniem WINS jest
rejestracja i rozwiązywanie nazw - DNS zapewnia również wiele
innych usług, takich jak dostarczanie informacji o konfiguracji
poczty elektronicznej, umożliwiających poprawny jej ruting w całej
domenie. Na bardziej "bitowym" poziomie, DNS korzysta z portu
UDS o numerze 53, zaś WINS używa UDP, portów 137 i 138,
zarezerwowanych dla usługi nazw NetBIOS-u.

Ostrzeżenie: Nie wolno mylić domeny TCP/IP z domeną NT. DNS
używa hierarchicznego systemu nazewnictwa, w którym pełna
nazwa składa się z nazwy komputera i nazwy domeny. Nazwa
domeny informuje o położeniu komputera. W przeciwieństwie do
tego, domena NT jest jedynie bazą danych zabezpieczeń, służącą
do zarządzania siecią NT. Nazwa komputera w domenie NT,
tworzona według płaskiego schematu nazewnictwa plików, będzie
zawsze inna niż nazwa domeny DNS, która z kolei tworzona jest
według hierarchicznego systemu nazewniczego. Na przykład, system
NT mógłby być członkiem domeny NT o nazwie XYZ-PROCURE,
lecz jego nazwą w domenie DNS byłoby

xyzcorp.com

Założenia projektowe dla usługi M icrosoft DNS

Chociaż w sieci NT możemy używać dowolnych serwerów DNS, to
dostarczana wraz z serwerem NT 4 usługa Microsoft DNS jest
jedyną, która może zintegrować się z usługą WINS, zapewniając
dynamiczny DNS. Na tym polega faktyczna różnica pomiędzy
microsoftową implementacją DNS a

innymi analogicznymi

serwerami, działającymi pod Windows NT . Implementacja

542

Rozdział 12

Microsoftu wspiera w pełni WINS, który z kolei jest „świadomy"
DHCP. Jeśli używamy jednocześnie DHCP, WINS i

DNS,

uzyskujemy następujące możliwości:

Dzięki DHCP klienci automatycznie otrzymują dynamiczne

adresy IP i informację konfiguracyjną T CP/IP. Pozwala to
centralnie administrować przydzielaniem IP, obsługiwać
"wędrówki" po sieci, utrzymywać porządek w przydziałach IP,
zwracając automatycznie niewykorzystane adresy IP do puli
dostępnej do ponownego wykorzystania, i

korzystać

z wszystkich pozostałych dobrodziejstw DHCP.

Dzięki WINS maszyny automatycznie rejestrują swe nazwy

NetBIOS-owe i adresy IP przy każdym uruchomieniu. Jeśli
komputer zostanie przeniesiony do innej podsieci, informacja ta
zostanie automatycznie uaktualniona.

Dzięki DNS klienci mogą odszukać wszelkie nie "rozumiejące"

WINS zasoby poprzez odwzorowania statyczne, przechowywane
w plikach konfiguracyjnych. Działa to i w przeciwną stronę.
Każdy nie-WINS-owy klient, który do rozwiązywania nazw
używa DNS i dysponuje statycznym odwzorowaniem do naszej
usługi DNS, może zlokalizować klienta WINS-owego, nawet jeśli
jego adres IP został przydzielony dynamicznie za pomocą
DHCP.

Kombinacja DHCP, WINS i DNS zapewnia poza tym i inne
korzyści. Dynamiczne przydzielanie adresów oznacza również ich
dynamiczne odzyskiwanie. Gdy nowy adres IP zostaje przydzielony
klientowi w innej podsieci, jego stary adres powraca do puli adresów
w danym zakresie DHCP. Zapobiega to konfliktom wywoływanym
przez istnienie w sieci takich samych adresów IP. Jedyną rzeczą,
której DHCP i WINS nie są w stanie załatwić, to łatwe wejście do
Internetu. Jednym z

wymagań, które trzeba spełnić przy

rejestrowaniu domeny internetowej w InterNIC-u, jest posiadanie
w sieci dwóch lub więcej serwerów DNS - po to, by klienci, którzy
chcieliby podłączyć się do naszego serwera - najprawdopodobniej do
naszej strony WWW - mogli go odnaleźć. Stwierdza się
powszechnie, że wielu usługodawców internetowych (ISP– Internet
Service Provider) nie wie, jak obsługiwać lub dostarczać WINS
z DHCP. Jeśli zatem planujemy podłączenie do Internetu, nie
pozostanie nam nic innego jak przywyknąć do korzystania

DHCP, WINS i DNS

543

z serwera DNS, lecz jeśli przy okazji użyjemy DHCP i WINS, to
oszczędzimy sobie żmudnej pracy ze zmienianiem plików
konfiguracyjnych za każdym razem, gdy klienta przenosimy lub
dodajemy do sieci.

Inną korzyścią z używania serwera DNS są pewne dodatkowe
możliwości w rozwiązywaniu nazw, których WINS nie oferuje.
Serwer DNS zapewnia rozwiązywanie nazw email-owych dzięki
obsłudze rekordów typu MX, wiążących adres poczty elektronicznej
z nazwą hosta. A gdy DNS nie potrafi rozwiązać nazwy lokalnie, to
spróbuje skierować zapytanie o nazwę do innego serwera DNS,
położonego w hierarchii o jeden szczebel wyżej.

Planowanie instalacji DNS

Należy najpierw rozważyć, komu zostanie powierzony obowiązek
utrzymywania plików konfiguracyjnych. DNS nie jest wcale
obiektem prostym i nie wolno traktować go lekceważąco. Na
szczęście, Microsoft dołączył do serwera NT 4 graficzne narzędzie
konfiguracyjne - DNS Manager - przeznaczone do współpracy
z jego usługą DNS. Narzędzie to pozwala uniknąć niemal
archaicznego obecnie procesu ręcznego redagowania plików
konfiguracyjnych.

Ostrzeżenie: Dwie identyczne nazwy hostów lub adresy IP w sieci
mogą wywołać wiele zamieszania. Upewniajmy się więc, czy nasi
administratorzy są tego świadomi i czy wdrożona procedura
rejestracyjna przewiduje konieczność rejestrowania nazwy i adresu
IP, zanim zostanie on ponownie przydzielony. Do przechowywania
takich informacji można użyć Access-owej bazy danych o sieci
(nazwa hosta, adres IP, nazwa pliku i tak dalej), w której trzeba by
sprawdzać, czy dana nazwa hosta i adres IP nie są już zajęte.

W pierwszym rzędzie należy zapewnić, by każdy, kto będzie
dokonywał modyfikacji w usłudze DNS, dysponował wiedzą wystar-
czającą do zrozumienia konsekwencji jego działań.

Istnieją trzy główne sposoby konfigurowania usługi DNS:

Primary Name Server (Pierwotny serwer nazw): Mieści

główną kopię bazy danych z nazwami. Baza ta zawiera rekordy

544

Rozdział 12

dla wszystkich hostów w strefie (zone), oraz rekordy dla
wszystkich poddomen.

Secondary Name Server (Wtórny serwer nazw): Zawiera

bazę danych z

rekordami dla domeny i

poddomen. Gdy

w domenie dokonywane są zmiany, wprowadzane są one do
pierwotnego DNS-u, a jego uaktualniona baza replikowana jest
do wszystkich wtórnych serwerów DNS.

Caching Name Server (Cache’ujący serwer nazw): Nie

przechowuje kopii bazy danych rekordów. Zamiast tego zostaje
skonfigurowany adresem pierwotnego lub wtórnego DNS-u dla
określonej domeny. Gdy cache’ujący serwer nazw otrzyma
zapytanie o nazwę, o obsłużenie żądania poprosi ów drugi serwer
nazw. Następnie informację tę umieści w swym cache'u, dzięki
czemu będzie dostępna natychmiast, gdy tylko ktoś zapyta o nią
ponownie. W rezultacie cache’ujący serwer przechowuje dane
o wszystkich często odwiedzanych miejscach, zaś rozmiar jego
cache'owanej bazy danych rośnie z

upływem czasu

i częstotliwością użycia.

W większej sieci celowe byłoby rozważenie, czy nie opłaca się
uruchomić kilku serwerów DNS, obsługujących różne podsieci.
Dostarcza to skutecznego sposobu na równomierne rozłożenie
obciążenia, odporność na uszkodzenia i poprawę wydajności sieci
wskutek zmniejszenia ruchu sieciowego, generowanego przez
rozwiązywanie nazw.

Instalowanie usługi serwera M icrosoft DNS

Uwaga: By móc zainstalować usługę serwera Microsoft DNS, trzeba
być członkiem grupy Administrators w tym komputerze, na którym
jest ona instalowana.

Podczas instalacji wykonujemy następujące czynności:

1. Uruchamiamy aplet

Netw ork

w Panelu sterowania.

2. Klikamy kartę

Serv ices

(Usługi), a następnie przycisk

Add

3. Z listy oferowanych usług sieciowych wybieramy

Microsoft

DNS

Serv er

DHCP, WINS i DNS

545

Uwaga: Jeśli na komputerze nie mamy jeszcze TCP/IP, to zostanie
on automatycznie zainstalowany w trakcie instalowania usługi
serwera DNS.

4. Klikamy

. Gdy zostanie wyświetlony odpowiedni komunikat,

wprowadzamy ścieżkę dostępu do plików dystrybucyjnych (na
przykład, f:\i386) i klikamy

Continue

5. Zamykamy okno konfiguracyjne

Netw ork

, klikając przycisk

Close

6. Restartujemy system.

Po zrestartowaniu systemu usługa DNS uruchomi się automatycznie.

Zarządzanie serwerem DNS za pomocą M enedżera DNS

Interfejsem do zarządzania usługą DNS jest DNS Manager. Swe
działanie opiera on na strefach (zone) DNS - administracyjnych
jednostkach usługi DNS. W podrozdziale tym omawiamy, jak
utworzyć strefę, jak w jej obrębie tworzyć domeny i poddomeny,
oraz jak zarządzać hostami i

innymi rekordami w

domenie.

Dowiemy się również więcej o

plikach konfiguracyjnych,

stanowiących rdzeń bazy danych DNS, a także zademonstrujemy,
jak skonfigurować usługę serwera Microsoft DNS, by do
rozwiązywania nazw wykorzystywać również serwer WINS.

Manager DNS zostaje zainstalowany w

grupie programów

Administrative T ools, podczas instalowania usługi DNS. By z niego
skorzystać, trzeba mieć uprawnienia administracyjne. Można za
jego pomocą robić wszystko, co dotyczy tej usługi, z wyjątkiem
zatrzymywania i uruchamiania usługi DNS, które odbywa się
w aplecie

Serv ices

Panelu sterowania, poprzez wybranie

Microsoft

DNS

Serv er

- jako sterowanej usługi. Alternatywnie, z wiersza

poleceń konsoli można wydać następujące polecenie:

net

stop dns

net

start dns

546

Rozdział 12

Tworzenie strefy

Strefa jest jednostką administracyjną systemu nazw domeny, zatem
utworzenie strefy jest pierwszą rzeczą, jaką wykonuje się przy
instalowaniu usługi DNS. Reprezentuje ona poddrzewo DNS, takie
jak

xyzcorp.com

Moglibyśmy np. tak skonfigurować nasz system,

by domena

xyzcorp.com

, poddomena

eng.xyzcorp.com

i poddomena

admin.xyzcorp.com

stanowiły części składowej

jednej strefy, utworzonej przez jedną organizację. Inna organizacja
byłaby wówczas odpowiedzialna za utrzymywanie strefy składającej
się z

poddomen

research.xyzcorp.com

testing.xyzcorp.com

. Jest to właśnie jedną z

cech

rozproszonego charakteru DNS.

Interfejs Menedżera DNS jest podobny do interfejsów Menedżera
DHCP i Menedżera WINS. Po pierwszym uruchomieniu Menedżer
DNS pokazuje tylko adres maszyny lokalnej, jak to widać na
rysunku 12.13.

Jeśli w sieci mamy inne serwery NT z działającą usługą DNS,
możemy je dodać do listy Menedżera DNS w następujący sposób:

1. Z menu

DNS

wybieramy

New Serv er

2. Wpisujemy w pełni kwalifikowaną nazwę domeny lub adres IP

serwera NT , którym chcielibyśmy zarządzać.

3. Klikamy

. Wpisany adres IP lub nazwa hosta pojawi się na

Serv er List

(Liœcie serwerów).

Rys. 12.13.
Domyślnie

Menedżer DNS

zajmuje się tylko

maszyną lokalną.

DHCP, WINS i DNS

547

4. Powyższe czynności powtarzamy dla każdego serwera NT , na

którym działa usługa DNS i którym chcemy administrować
z lokalnej maszyny.

Uwaga: Menedżera DNS można używać do administrowania
wyłącznie serwerami NT z działającą usługą DNS.

By utworzyć strefę administracyjną, należy wykonać następujące
czynności:

1. Na Liœcie serwerów klikamy ten serwer DNS, którym chcemy

zarządzać.

2. Z menu

DNS

wybieramy

New Zone

(Nową strefę). Pojawi się

okno

Create New Zone

(Utwórz nową strefę).

3. Wybieramy

Primary

(Pierwotną) i klikamy

Next

4. Nadajemy swej strefie nazwę, na przykład xyzcorp.com.

T rzeba również podać nazwę jej pliku. Wszystkie informacje
o strefie

przechowywane

będą

w %SystemRoot%\System32\dns\ filename, gdzie
filename

jest właśnie nazwą pliku, którą podaliśmy.

5. Klikamy

Next

, a następnie przycisk

Finish

T eraz strefa jest już utworzona i powinna pojawić się na liście pod
naszym serwerem, tak jak to pokazano na rysunku 12.14.

W domenie tworzone są domyślnie dwa rekordy: NS i SOA. Rekord
NS określa wybraną maszynę jako serwer nazw w domenie, zaś
rekord SOA znany jest jako Start of Authority (początek strefy

Rys. 12.14. Strefa

xyzcorp.com

istnieje teraz jako
jednostka
administracyjna
na serwerze
lokalnym.

548

Rozdział 12

wpływów lub autorytetu. Każda domena musi zawierać SOA, który
podaje nazwę serwera, będącego najlepszym źródłem
autorytatywnej informacji o

strefie, a

także adres email dla

kontaktowania się z osobą, odpowiedzialną za domenę.

Dodawanie WINS-owego rozwiązywania nazw do strefy

WINS-owe rozwiązywanie nazw dodaje się do każdej strefy osobno.
Gdy DNS zostaje poproszony o rozwiązanie nazwy DNS i nigdzie
w swej bazie danych nie może odnaleźć wpisu dla tej nazwy, usługa
DNS pobiera z niej lewą część nazwy hosta (znaki do pierwszej
kropki) i przekazuje ją serwerowi WINS. Jeśli ma on w swojej bazie
danych pasującą nazwę NetBIOS-ową, zwraca do usługi DNS
odpowiadający jej adres IP, a ta zwraca go klientowi, który wtedy
może już bez problemów podłączyć się do zasobu. Widzimy więc, że
całość stanowi bardzo skuteczny sposób na to, by usługa DNS mogła
rozwiązywać nawet adresy IP przydzielane dynamicznie, ponieważ -
jak pamiętamy - serwer WINS obsługuje adresowanie dynamiczne.

Uwaga: Serwer DNS próbuje użyć WINS-a do rozwiązania nazwy
tylko wtedy, gdy sam w swej bazie danych nie może odszukać
odpowiedniej nazwy hosta.

Aby dla danej strefy uaktywnić WINS-owe rozwiązywanie nazw,
należy wykonać następujące czynności:

1. Klikamy strefę, w której ma działać WINS-owe rozwiązywanie

nazw.

2. Z menu

DNS

wybieramy

Properties

(Właściwości).

3. Klikamy kartę

WINS

Resolution

4. Zakreślamy pole opcji

Use

WINS

Resolution

(Używać

rozwiązywania WINS).

5. Wpisujemy serwery WINS w kolejności, w jakiej winny być

zapytywane - tak jak to pokazano na rysunku 12.15.

DHCP, WINS i DNS

549

1. Zamykamy okno właściwości strefy, klikając

2. Na liście

Zone

Info

(Informacji o strefie) powinien pojawić się

rekord dla każdego tak skonfigurowanego serwera WINS,
analogicznie jak na rysunku 12.16.

Tworzenie poddomen

DNS jest hierarchicznym systemem nazw. Oznacza to, że można
tworzyć zagnieżdżone domeny, dzielące sieć na oddzielne jednostki
administracyjne. W

większości standardowych konfiguracji,

a zwłasz-cza tych podłączonych do Internetu, nazwa strefy będzie
taka sama, jak nazwa domeny podstawowej. Jeśli na przykład nasza
firma nazywa się XYZ Corporation, to jej domeną będzie
xyzcorp

, a ta z kolei będzie częścią hierarchii .com. Zatem

Rys. 12.15.
W pisujemy
serwery W INS
w kolejności,
w jakiej będą
zapytywane.

Rys. 12.16.
Rekord strefy
tworzony jest dla
każdego serwera
W INS, który
będzie używany
do rozwiązywania
nazw w strefie.

550

Rozdział 12

pełna nazwa naszej domeny brzmieć będzie: xyzcorp.com.
T eraz domenę tę podzielimy na mniejsze jednostki, tworząc
poddomeny. Gdybyśmy dla przykładu chcieli użyć osobnych domen
dla pionu administracyjnego i pionu kontroli, nazwalibyśmy je
admin.xyzcorp.com

i testing. xyzcorp.com.

Aby utworzyć poddomenę, trzeba wykonać następujące czynności:

1. Klikamy strefę, w której chcemy utworzyć poddomenę.

2. Z menu

DNS

wybieramy

New

Domain

(Nową domenę).

3. Wpisujemy nazwę poddomeny - na przykład admin lub testing,

po czym klikamy

Nowa domena pojawi się w Menedżerze DNS w wybranej strefie, jak
pokazano na rysunku 12.17.

Wskazówka: Hostom można nadawać nazwy takie same, jak
poddomenom. Na przykład,

admin.xyzcorp.com

może

odnosić się do maszyny, lecz i do poddomeny, zawierającej inne
maszyny, takie jak

ftp.admin.xyzcrop.com

Dodawanie hostów do domeny

Utworzywszy domenę, trzeba ją "zaludnić" hostami. Aby dodać
hosta, trzeba wykonać następujące czynności:

1. Klikamy domenę (strefę) lub poddomenę, w której host ma

rezydować, na przykład xyzcorp.com.

Rys. 12.17.

Poddomena

pojawia się pod

odpowiadającą

jej strefą.

DHCP, WINS i DNS

551

2. Z menu

DNS

wybieramy

New

Host

3. Wprowadzamy nazwę hosta i jego adres IP - na przykład

secundus

i 128.1.1.2.

4. By utworzyć związany z nim rekord PT R, klikamy przycisk

Create

Associated

PTR

Record

(Utwórz związany rekord

PT R).

5. Klikamy

Add

Host

, a następnie przycisk

Done

6. Dla hosta utworzony zostanie nowy rekord typu A, tak jak to

pokazano na rysunku 12.18 dla hosta secundus.

Dodawanie nowego rekordu

Jak już wcześniej wspomniano, DNS oferuje znacznie więcej usług
niż tylko zwykle tłumaczenie nazw na adresy IP. Pozostałe usługi
uaktywnia się dodając do domeny odpowiednie rekordy. Dla
przykładu, aby wskazać serwer, który dla komputerów w domenie
obsługiwał będzie nadchodzącą pocztę elektroniczną, trzeba
utworzyć rekord MX, identyfikujący serwer pocztowy.

Aby dodać rekord do domeny, należy wykonać następujące
czynności:

1. Klikamy strefę lub poddomenę, w której chcemy utworzyć nowy

rekord.

2. Z menu

DNS

wybieramy

New

Resource

(Nowy zasób). Pojawi

się okno

New

Resource

Record

(Rekord nowego zasobu) .

Rys. 12.18.
Rekord typu
A tworzony jest za
każdym razem,
gdy dodajemy
nowego hosta.

552

Rozdział 12

3. Wybieramy typ rekordu, który chcemy utworzyć, na przykład

rekord MX. Opis wybranego typu rekordu pojawi się u dołu
ekranu, zaś pola po prawej stronie zmienią się w zależności od
wymagań konkretnego typu rekordu, podobnie jak to pokazano
na rysunku 12.19.

Wprowadzamy pozostałe informacje, wymagane dla danego typu
rekordu, jak nazwa DNS dla węzła pocztowego i poziom priorytetu
w przypadku rekordu typu MX.

4. Klikamy

5. Na liście rekordów domeny pojawi się teraz nowy rekord .

Pliki konfiguracyjne usługi DNS

tym podrozdziale Czytelnik może bezpośrednio obejrzeć

i zmodyfikować pliki konfiguracyjne DNS. Przechowywane są one
w katalogu %SystemRoot%\System32\dns. Pliki konfigura-
cyjne używane przez serwer DNS Microsofta mogą być zastąpione
przez analogiczne pliki unixowej instalacji BIND - w przypadku,
gdy współpracujemy lub migrujemy z systemu UNIX - choć może
trzeba będzie zmodyfikować je nieco, jeśli zawierają pewne
przestarzałe polecenia BIND.

Rys. 12.19. Typ

MX rekordu

stosowany jest do

określania węzła

pocztowego dla

domeny.

DHCP, WINS i DNS

553

Uwaga: Przed przystąpieniem do bezpośredniego redagowania
plików DNS należy je uaktualnić, wydając polecenie

Update

Server Data Files

(Uaktualnij pliki danych serwera) z menu

DNS

w Menedżerze DNS.

Pliki konfiguracyjne dla BIND dzielą się na trzy podstawowe typy:

BOOT: Plik ten kontroluje zachowanie się serwera DNS podczas

jego uruchamiania. Zawiera on informacje o

katalogu

domyślnym, w którym mieszczą się pliki konfiguracyjne, nazwie
pliku cache'a, nazwie domeny, którą serwer DNS będzie
obsługiwał, oraz nazwie domeny dla wtórnego serwera DNS.

Uwaga: Usługę Microsoft DNS można tak skonfigurować, by swą
informację uruchamiającą przechowywała albo w pliku ładującym,
umieszczonym w katalogu

%SystemRoot%\System32\dns

albo w Rejestrze.

CACHE: Plik ten zawiera informacje dotyczące

przyłączeniowości do Internetu.

PLACE.DOM: Plik ten zawiera informacje o nazwach hostów

w domenie. Zawiera on także odnośniki z nazwami plików do
odwrotnego wyszukiwania i serwerów WINS.

ARPA-###.REV: Pliki te (po jednym na podsieć) zawierają

informacje pozwalające przekształcić adres IP w nazwę hosta.

BOOT

Plik uruchamiający (boot file) dopuszcza tylko kilka poleceń,
dlatego ich składnię, zestawioną w tabeli 12.6, jest dość łatwo
zapamiętać. Przykładowy plik BOOT dla prostej sieci mógłby
wyglądać następu-jąco:

;PLIK

URUCHOMIENIOWY DNS - Konfiguracja podstawowa dla

usługi

DNS