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
i
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
Nr
Nazwa
Typ danych O pis
DHCP, WINS i DNS
475
1
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
menu
DHCP Options
.
3
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.
6
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.
Nr
Nazwa
Typ danych O pis
15
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.
44
WINS/NBNS
tablica
adresów IP
Określa w preferowanej kolejności listę
serwerów nazw NetBIOS-u (NBNS).
46
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
47
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.
50
Żądany adres
adres IP
Określa, że ma być używany predefinio-
wany adres IP klienta.
51
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
menu
DHCP
Options
.
53
T yp
komunikatu
DHCP
bajt
Określa typ komunikatu DHCP, przy
czym: 1 -
DHCPDISCOVER,
2
- DHCPOFFER,
3
- DHCPREQUEST,
4
- DHCPDECLINE,
5
- DHCPACK,
6
- DHCPNAK,
7
- DHCPRELEASE.
Nr
Nazwa
Typ danych O pis
54
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.
58
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
59
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.
61
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
Nr
Nazwa
Typ danych O pis
0
Wypełnienie
bajt
Podaje, że dalsze pola z danymi będą wy-
równane do granicy słowa (16-bitowego).
2
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
4
Serwery czasu tablica
adresów IP
Określa w preferowanej kolejności listę
serwerów czasu dla klienta.
5
Serwery nazw tablica
adresów IP
Określa w preferowanej kolejności listę
serwerów nazw dla klienta.
7
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.
8
Serwery
„cookie”
tablica
adresów IP
Określa w preferowanej kolejności listę
serwerów „cookie” (zdefiniowanych
w RFC 865) dla klienta.
9
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.
10
Serwery
Impress
tablica
adresów IP
Określa w preferowanej kolejności listę
serwerów Imagen Impress dla klienta.
11
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.
12
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.
Nr
Nazwa
Typ danych O pis
13
Wielkość
pliku
startowego
słowo
Określa domyślną wielkość obrazu pliku
uruchomieniowego w
blokach 512-
oktetowych.
14
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.
16
Serwer
wymiany
adres IP
Podaje adres IP serwera wymiany (swap)
dla klienta.
17
Ścieżka do
katalogu
głównego
łańcuch
znakowy
Określa (w ASCII) ścieżkę dostępu do
katalogu głównego klienta.
18
Ś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.
19
Przekazywani
e warstwy IP
bajt
Określa, czy pakiety IP powinny być dla
klienta dozwolone (1) lub niedozwolone
(0).
20
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).
21
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.
22
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.
Nr
Nazwa
Typ danych O pis
23
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.
24
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.
25
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.
26
Opcja MT U
słowo
Określa wielkość znalezionego MT U.
Uwaga: wartością minimalną jest 68.
27
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.
28
Adres
rozgłaszania
adres IP
Określa adres IP, dla rozgłaszania którego
należy używać w lokalnej podsieci klienta.
29
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
Nr
Nazwa
Typ danych O pis
30
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ć .
31
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 .
32
Adres do
negocjowania
o ruter
adres IP
Określa adres IP, pod który klient
wysyłać będzie żądania negocjowania
(solicitation) o ruter.
33
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
w
przypadku, gdy z
ustawienia tego
korzystają nie-microsoftowi klienci
DHCP.
34
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”.
35
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.
Nr
Nazwa
Typ danych O pis
36
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.
37
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).
38
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).
39
Keepalive
Garbage
bajt
Włącza (1) lub wyłącza (0) wysyłanie ko-
munikatów
keepalive
z
oktetem
danych garbage dla kompatybilności
z aplikacjami odziedziczonymi.
40
Nazwa
domeny NIS
łańcuch
znakowy
Łańcuch znaków ASCII określający
domenę NIS (Network Information
Service).
41
Serwery NIS
tablica
adresów IP
Określa w preferowanej kolejności listę
adresów IP serwerów NIS dla klienta.
42
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.
43
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.
Nr
Nazwa
Typ danych O pis
45
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.
48
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.
49
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.
64
Nazwa
domeny NIS+
łańcuch
znakowy
Określa w preferowanej kolejności listę
nazw domen NIS+.
65
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
.
3.
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
OK
. 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
OK
, 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
OK
. 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
To
(Ograniczony do). Jeśli wybierzemy
Limited
to
, 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
OK
. 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
OK
.
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
OK
.
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
OK
.
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
OK
.
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:
IP
Address.....................: 128.0.0.254
Subnet
Mask....................: 255.255.255.0
Default
Gateway................:
Ethernet
adapter NDISLoop9:
IP
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
IP
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
OK
.
9. Powtarzamy kroki 3 - 7 dla każdej rezerwacji, którą
zamierzaliśmy zmodyfikować. Gdy zmodyfikujemy już wszystkie
rezerwacje, klikamy
OK
.
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
z
nośnika
źródłowego,
zrestartować usługę serwera DHCP i uzgodnić bazę danych,
wybierając
Scope\Active
Leases
i
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
i
%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).
3.
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
OK
.
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
i
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
w
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
OK
. 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
do
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
i
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
To
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
i
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
OK
. 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
i
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
OK
. 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
OK
.
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
OK
.
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
OK
.
5. Na liście rekordów domeny pojawi się teraz nowy rekord .
Pliki konfiguracyjne usługi DNS
W
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
directory
%SystemRoot%\System32\dns
cache
.
cache
primary
xyzcorp.com
xyzcorp.dom
primary
127.in-addr.arpa
arpa.127.rev
primary
128.1.1.in-addr.arpa
arpa.128.rev
554
Rozdział 12
Tabela 12.6. Polecenia dla pliku BOOT
Polecenie
Wymagan
e
O pis
Uwagi
;
nie
Rozpoczyna komentarz.
Należy unikać zbędnych ko-
mentarzy, ponieważ plik jest
analizowany kolejnymi wier-
szami. Każdy komentarz, do-
dany do pliku, spowalnia
rozwiązywanie tych nazw,
których nie ma w cache'u.
Directory
Pathname
nie
Opisuje lokalizację pliku
konfiguracyjnego;
Pathname
jest w pełni
kwalifikowaną ścieżką do-
stępu. Wartość domyślna,
jeśli nie została określona
inaczej, ma postać
%SystemRoot%\
System32\DNS
.
Jeśli katalogu tego nie uda
się odnaleźć, usługa DNS nie
wystartuje.
Cache
FileName
tak
Opisuje lokalizację pliku
cache'a, używanego do od-
szukiwania dodatkowych
serwerów nazw; File
Name
jest nazwą tego
pliku.
Jeśli pliku tego nie uda się
odnaleźć, usługa DNS nie
wystartuje.
Primary
DomainName
FileName
tak
Określa nazwę domeny,
dla której dany serwer
DNS jest autorytatywny
i nazwę pliku konfigu-
racyjnego, zawierajacego
informacje o domenie.
Secondary
DomainName
HostList
[FileName]
nie
Określa nazwę domeny
i związaną z
nią tablicę
adresów IP, z
których
ściągana będzie informacja
o strefie.
Jeśli podana została nazwa
pliku, to informacja o strefie
zostanie ściągnięta i
użyta
tylko wtedy, gdy nie uda się
znaleźć serwera DNS dla tej
domeny lub serwera alterna-
tywnego.
DHCP, WINS i DNS
555
CACHE
Plik cache'a wykorzystywany jest do dodatkowego rozwiązywania
nazw. Jeśli właściwy serwer DNS nie może rozwiązać jakiejś nazwy,
kieruje zapytanie do dodatkowych serwerów nazw, wyliczonych
w tym pliku. Jeśli serwera DNS używamy do rozwiązywania nazw
w Internecie, wówczas plik ten powinien wyglądać podobnie jak
poniższy:
;
PLIK
CACHE'A DNS
;
Początkowe
dane cache'a dla serwerów domeny głównej.
;
NALEŻY
ZMIENIĆ:
;
-
nic, jeśli jesteś podłączony do
Internetu.
Plik ten wolno
;
modyfikować
tylko wtedy, gdy wydana
zostanie
lista uaktualnień ;głównych
serwerów
nazw.
;
LUB
;
-
jeśli NIE jesteś podłączony do
Internetu,
usuń te rekordy i
;
zastąp
je rekordami NS i A dla serwera
DNS
autorytatywnego dla ;domeny głównej
w
twoim miejscu.
;
Rekordy
dla głównych serwerów nazw Internetu:
;
ostatnie
uaktualnienie: 1 paźdz. 1995
;
związana
z nim wersja strefy głównej:
1995090100
;
poprzednio
NS.INTERNIC.NET
.
3600000
IN
NS A.ROOT-
SERVERS.NET.
A.ROOT-SERVERS.NET.
3600000
A
198.41.0.4
;
poprzednio NS1.ISI.EDU
.
3600000
NS
B.ROOT-
SERVERS.NET.
B.ROOT-SERVERS.NET.
3600000
A
128.9.0.107
;
poprzednio C.PSI.NET
.
3600000
NS
C.ROOT-
SERVERS.NET.
C.ROOT-SERVERS.NET.
3600000
A
192.33.4.12
;
poprzednio TERP.UMD.EDU
.
3600000
NS
D.ROOT-
SERVERS.NET.
D.ROOT-SERVERS.NET.
3600000
A
128.8.10.90
;
poprzednio NS.NASA.GOV
.
3600000
NS
E.ROOT-
SERVERS.NET.
E.ROOT-SERVERS.NET.
3600000
A
192.203.230.10
;
poprzednio NS.ISC.ORG
.
3600000
NS
F.ROOT-
SERVERS.NET.
F.ROOT-SERVERS.NET.
3600000
A
39.13.229.241
;
poprzednio NS.NIC.DDN.MIL
.
3600000
NS
G.ROOT-
SERVERS.NET.
G.ROOT-SERVERS.NET.
3600000
A
192.112.36.4
;
poprzednio AOS.ARL.ARMY.MIL
.
3600000
NS
H.ROOT-
SERVERS.NET.
556
Rozdział 12
H.ROOT-SERVERS.NET.
3600000
A
128.63.2.53
;
poprzednio NIC.NORDU.NET
.
3600000
NS
I.ROOT-
SERVERS.NET.
I.ROOT-SERVERS.NET.
3600000
A
192.36.148.17
;
Koniec pliku
Uwaga: Aktualną wersję tego pliku znaleźć można w FTP-owym
miejscu InterNIC-u pod adresem:
ftp.rs.internic.net
.
Wystarczy zalogować się anonimowo, przejść do katalogu
domain
i ściągnąć plik
named.root
.
Jeśli dany serwer DNS nie będzie używany do rozwiązywania nazw
Internetu, to rekordy serwerów nazw (NS) i adresów (A) należy
zastąpić odpowiednimi wpisami dla serwera DNS, autorytatywnego
dla danej domeny.
PLACE.DOM
PLACE.DOM
stanowi rdzeń całej działalności serwera DNS. Zawiera
on kilka typów rekordów, zestawionych w tabeli 12.7, za pomocą
których realizuje się funkcje rozwiązywania nazw w domenie.
Ponieważ przykładowy plik, dołączony do usługi Microsoft DNS,
zawiera dane dla domeny nie istniejącej, należy zmienić jego nazwę
i zmodyfikować go odpowiednio do warunków w rzeczywistej
domenie. Poniżej zamieszczamy kopię pliku o
nazwie
xyzcorp.dom
. Zastoso-waliśmy więc konwencję nazewniczą typu
NazwaDomeny.dom
i
zalecamy ją wszystkim Czytelnikom,
ponieważ jest bardzo wygodna przy administrowaniu wieloma
domenami.
@
IN
SOA
primus.xyzcorp.com.admin.primus.
xyzcorp.com. (;
host
źródłowy adres emailowy
1
;seryjny
numer pliku
10800
;okres
odświeżania
3600
;
okres ponawiania
604800
;
okres wygaśnięcia
86400)
;
minimalny czas życia
@
IN
NS
primus.xyzcorp.com.
;serwer
nazw dla domeny
primus
IN
A
128.1.1.1
;
adres IP serwera nazw
@
IN
WINS
128.1.1.1
128.1.1.2
;
adresy IP serwerów WINS
localhost
IN
A
127.0.0.1
;pętla
zwrotna
(loop
back)
@
IN
MX
10
primus
;serwer
pocztowy
primus
IN
A
128.1.1.1
;adres
IP serwera
pocztowego
ftp
IN
CNAME
primus
;nazwa
alias dla
usługi
FTP
DHCP, WINS i DNS
557
www
IN
CNAME
primus
;nazwa
alias dla
usługi
www
gopher
IN
CNAME
primus
;nazwa
alias dla usługi
Gopher
Pierwszą pozycją w pliku musi być rekord SOA (Start of
Authority
). Rekord ten zawiera parametry opisujące hosta
źródłowego (na którym plik został utworzony); adres email-owy
administratora pliku; numer seryjny (lub numer wersji) pliku; okres
odświeżania (w sekundach), używany przez serwery wtórne do
określania, kiedy należy ściągnąć poprawiony plik; okres
ponawiania (w sekundach), czyli czas, jaki serwery wtórne
odczekują przed ponowną próbą ściągnięcia pliku w
razie
niepowodzenia pierwszej; oraz okres wygaśnięcia (w sekundach),
który serwerom wtórnym służy do określenia, kiedy odrzucić strefę,
jeśli w ogóle nie mogła być ściągnięta. Następnie należy wymienić
serwery nazw (lub serwery DNS) dla danej domeny i za każdym
dodać jego adres IP. Po nich dołącza się identyfikator
LocalHost
, używany przy testowaniu w pętli zwrotnej, nazwy
i adresy wszystkich serwerów pocztowych i aliasy nazw hostów.
Alias nazwy zaopatruje hosta w więcej niż jedną nazwę hosta. Jest
to szczególnie użyteczne wówczas, gdybyśmy chcieli nasze miejsce
WWW udostępniać w
powszechnie używanym formacie
WWW.NazwaDomeny.COM
(na przykład www.xyzcorp.com),
a nie jako
NazwaSerwera.NazwaDomeny.COM
(np.
primus
.
xyzcorp. com
).
Uwaga: Jeśli podajemy w pełni kwalifikowaną nazwę domeny
(FQDN,
Fully
Qualified
Domain
Name
), to trzeba ją
dodawać z kropką na końcu; w przeciwnym razie w procesie
rozwiązywania nazwa domeny zostanie dołączona do nazwy hosta
i spowoduje, że zapytanie o nazwę nie powiedzie się. Na przykład,
gdybyśmy nazwę naszej domeny w
wierszu 7 podali jako
xyzcorp.com,
zamiast
xyzcorp.com.
, wówczas przy próbie
rozwiązania nazwy hosta
primus.xyzcorp.com
nazwa
domeny
xyzcorp.com
zostałaby dołączona ponownie
(
primus.xyzcorp.com.xyzcorp.com
). Ponieważ nie ma
oczywiście hosta o tej nazwie, zapytanie nie dałoby rezultatu.
558
Rozdział 12
Tabela 12.7. Dozwolone rekordy dla nazw domeny
Identyfikato
r
Typ rekordu
O pis
A
adres
Określa adres IP związanego z nim
hosta.
CNAME
nazwa klasy
Określa alias dla związanego z nim
hosta.
MX
poczta
Określa nazwy hostów będących
serwerami pocztowymi.
NS
serwer nazw
Określa serwery nazw w domenie.
SOA
początek strefy
wpływu (autorytetu)
Pierwszy rekord w każdym pliku
konfiguracyjnym, używany do
określenia nazwy.
WINS
WINS
Określa adresy IP serwerów WINS
używanych do dodatkowego
rozwiązywania nazw.
ARPA-###.REV
ARPA-###.REV
używany jest do odwrotnego wyszukiwania nazw
hostów w obrębie domeny. Zamiast tłumaczyć nazwę na adres IP,
wyszukiwanie odwrotne (reverse lookup) przekształca adres IP
w nazwę hosta. Na przykład, dla domeny autora, która ma tylko
jedną podsieć (128.0.0.0), plik wyszukiwania odwrotnego wygląda
następująco:
@
IN
SOA
primus.xyzcorp.com.
admin.primus.xyzcorp.com.
(; host źródłowy adres
emailowy
1
;seryjny
numer pliku
10800
;okres
odświeżania
3600
;okres
ponawiania
604800
;okres
wygaśnięcia
86400)
;minimalny
czas życia
@
IN
NS
primus.xyzcorp.com.
;serwer
nazw dla domeny
@
IN
NBSTAT
xyzcorp.com.
;nazwa
domeny doczepiana
przy
wyszukiwaniu NBSTAT
1
IN
PTR
primus.xyzcorp.com.
;primus
pod 128.1.1.1
99
IN
PTR
winbookxp5.xyzcorp.com
;WinBook
XP5 pod
128.1.1.99
DHCP, WINS i DNS
559
T utaj także pierwszy rekord powinien być rekordem SOA.
Następny podaje serwer nazw (lub DNS) dla domeny, po nim rekord
NBST AT , a następnie po jednym rekordzie PT R dla każdego hosta
w domenie. Rekordy te i sposób ich użycia zestawiono w tabeli
12.8. Na ogół najbardziej niezrozumiale są rekordy PT R. Zamiast
podawania pełnego adresu IP (takiego jak 128.1.1.1) dla hosta,
określamy tylko ostatnią cyfrę adresu IP (w tym przykładzie 1),
a po niej w pełni kwalifikowaną nazwę hosta (nazwa hosta + nazwa
domeny).
Tabela 12.8. Rekordy dozwolone dla wyszukiwania odwrotnego
Identyfikat
or
Typ rekordu
O pis
NBST AT
NBST AT
Określa nazwę domeny, „doczepianą” do
każdej nazwy hosta przy wyszukiwaniu
NBST AT .
NS
serwer nazw
Określa serwery DNS w domenie.
PT R
wskaźnik
Określa adres IP hosta.
SOA
początek strefy
wpływu (autorytetu)
Pierwszy rekord w każdym pliku
konfiguracyjnym, używany do określania
nazwy.