Rozdział 4

Konfigurowanie TCP/IP

Po zainstalowaniu TCP/IP najprawdopodobniej konieczne będzie
dokonanie konfiguracji pewnych dodatkowych parametrów - istotny jest
zwłaszcza sposób realizacji usług nazewniczych w sieci. Niniejszy
rozdział omawia podstawowe zagadnienia związane z określaniem nazw
komputerów, w tym strukturę plików LMHOSTS i HOSTS oraz cel ich
stosowania.

Potrzebne być może także skonfigurowanie innych usług TCP, jak np.
FTP, drukowania sieciowego, SNMP oraz WWW. Konfigurowanie usług
FTP i drukowania opisano w tym rozdziale; SNMP omówiono w roz-
dziale 11, "Zarządzanie sieciami Microsoft za pomocą SNMP".

Konfigurowanie usług określania nazw w Windows NT

W rozdziale 3 "Instalowanie protokołu i usług TCP" opisano, jak można
określić serwery WINS i DNS oraz parametry IP używane przez
komputer Windows NT. Usługi WINS i DNS służą do określania nazw
w sieci Windows. Dodatkową metodą określania nazw jest użycie dwóch
plików: LMHOSTS i HOSTS.

Usługi NetBIOS

NetBIOS zapewnia trzy rodzaje usług: usługi nazewnicze, usługi data-
gramowe oraz usługi sesji (patrz tabela 4.1). Usługi nazewnicze
i datagramowe używają portów 137 i 138 protokołu warstwy transportu -
UDP. Użycie UDP podyktowane jest tym, że usługi nazewnicze i data-
gramowe pracują w trybie żądanie-odpowiedź; co więcej, usługi nazew-
nicze czynią częsty użytek z trybu rozgłoszeniowego (broadcast), obsłu-
giwanego lepiej przez UDP niż przez TCP. W dużych sieciach transmisje
w trybie rozgłoszeniowym mogą prowadzić do powstania tzw. burz roz-
głoszeniowych (broadcast storms), dlatego wiele routerów domyślnie blo-
kuje rozgłoszenia.

Rozdział 4

100

Usługi sesji NetBIOS używają protokołu TCP, który w przeciwieństwie
do UDP gwarantuje dostarczenie danych; poza tym model sesji TCP dość
wiernie odpowiada modelowi sesji NetBIOS. Oba protokoły używają
pierwotnych funkcji "otwórz" w celu otworzenia połączenia i "zamknij"
w celu jego zamknięcia.

Początkowo NetBIOS obsługiwał tylko nazwy komputerów. Na każdym
komputerze pracował pojedynczy użytkownik, do którego trafiały
wszystkie komunikaty wysyłane do komputera.

Wraz z

rozrastaniem się sieci i

liczby ich użytkowników dodano

w NetBIOS możliwość definiowania nazw użytkowników i

grup

roboczych (lub domen). Nazwa użytkownika NetBIOS pozwalała na
skierowanie komunikatów do konkretnego użytkownika. Jeśli istniało
kilka instancji pojedynczej nazwy użytkownika (użytkownik zalogował
się więcej niż raz), wówczas komunikat był kierowany tylko do nazwy
użytkownika zarejestrowanej jako pierwsza.

Możliwość zgrupowania różnych systemów pod jedną nazwą grupy
roboczej (domeny) ułatwia przeglądanie, zarządzanie i zabezpieczenie
domen Windows NT. Nazwy grup są rejestrowane w sieci jako nazwy
NetBIOS.

W pojedynczym komputerze może pracować kilka procesów. Procesy
świadczące usługi nazywamy usługami aplikacyjnymi. Niektóre z usług
aplikacyjnych są rejestrowane jako nazwy NetBIOS. Windows NT umoż-
liwia zarejestrowanie do 250 nazw NetBIOS na pojedynczym kompute-
rze. Przykładami usług aplikacyjnych w komputerze Windows mogą
być:

„

Usługa serwera. Zazwyczaj odnosi się do usługi działającej aplikacji
umożliwiającej dzielenie plików i drukarek w komputerze.

Tabela 4.1 Usługi NetBIOS

Nazwa usługi Port

Protokół Krótka

nazwa

Usługa nazewnicza NetBIOS

137 UDP nbname

Usługa datagramowa NetBIOS

138 UDP nbdatagram

Usługa sesji NetBIOS

139 TCP nbsession

„

Usługa stacji roboczej. Umożliwia stacji roboczej pracowanie jako
klient i korzystanie z usług aplikacji serwera pracującej na innym
komputerze.

„

Usługa doręczyciela. Odbiera i wyświetla komunikaty skierowane do
zarejestrowanych w komputerze nazw.

Konfigurowanie TCP/IP

101

Maksymalną długością nazw NetBIOS jest 16 znaków. Pierwszych 15
definiuje nazwę NetBIOS, a ostatni znak jest bajtem określającym typ
nazwy, mogącym przybierać wartości od 0 do 255. Poniższa lista przed-
stawia nazwy niektórych usług, które mogą zostać zarejestrowane. Szes-
nastkowe liczby w nawiasach kwadratowych są jednobajtowymi identy-
fikatorami typu nazwy.

„

Nazwa komputera (Computername) [0x00]. Jest to usługa stacji roboczej
zarejestrowana dla tego komputera.

„

Nazwa komputera (Computername) [0x03]. Jest to usługa doręczyciela
zarejestrowana dla tego komputera.

„

Nazwa użytkownika (Username) [0x03]. Jest to nazwa użytkownika
zarejestrowana przez doręczyciela dla zalogowanego użytkownika.

„

Nazwa komputera (Computername) [0x20]. Jest to usługa serwera
zarejestrowana dla tego komputera.

„

Nazwa domeny (Domainname) [0x00]. Rejestruje komputer jako
członka grupy roboczej (domeny o danej nazwie).

„

Nazwa domeny (Domainname) [0x1E]. Używana do ułatwienia
przeglądania.

„

Nazwa domeny (Domainname) [0x1B]. Rejestruje komputer jako
główną przeglądarkę domeny.

„

Nazwa domeny (Domainname) [0x1C]. Rejestruje komputer jako
kontroler domeny.

„

Nazwa domeny (Domainname) [0x1D]. Rejestruje komputer jako
główną przeglądarkę lokalnej podsieci.

Jeśli np. użytkownik Phylos na stacji roboczej Windows NT o nazwie
WS1, znajdującej się w domenie KINETD, chce pobrać plik z serwera
Windows NT o nazwie NTS, wówczas Phylos[0x03] używa usługi stacji
roboczej o

nazwie NetBIOS WS1[0x00], aby zostać wstępnie

uwierzytelnionym przez kontroler domeny o nazwie KINETD[0x1C]. Po
uwierzytelnieniu, usługa stacji roboczej WS1[0x00] komunikuje się
z usługą serwera NTS[0x20] w celu pobrania plików.

Metody określania nazw

Metody używane przez Windows NT do określania nazw można
podzielić na dwie kategorie:

„

standardowe określanie nazw

Rozdział 4

102

„

specyficzne określanie nazw

Kolejne podrozdziały opisują te metody.

Standardowe określanie nazw

Metoda standardowego określania nazw używana jest w systemach
UNIX i w oprogramowaniu przeniesionym z UNIX na platformę Win-
dows. Określanie nazw odbywa się w następującej kolejności:
1. Lokalna nazwa komputera
2. Użycie pliku HOSTS
3. Użycie DNS
4. Jeśli DNS zawiedzie, nazwy określane są poprzez NetBIOS.

Najpierw sprawdza się, czy określana nazwa nie jest nazwą lokalnego
komputera. Jeśli nie, wówczas sprawdzany jest plik HOSTS. Plik HOSTS
zawiera tablicę odwzorowania nazw hostów na adresy IP; jego format
zaczerpnięto z pliku hostów systemu BSD UNIX 4.3. Korzystają z niego
takie aplikacje jak Telnet, FTP i

PING. Plik HOSTS nie jest

przechowywany centralnie - każdy z komputerów korzysta z własnego
pliku HOSTS. W przypadku zmian w pliku HOSTS trzeba ich dokonać
na każdym komputerze w sieci.

Jeśli plik HOSTS nie zawiera określanej nazwy, wówczas wysyłane jest
zapytanie do serwera DNS. Serwery DNS utrzymują m.in. informacje
o odwzorowaniu nazw na adresy IP, w postaci rozproszonej w sieci bazy
danych. Większość serwerów DNS w Internecie pracuje w systemie
UNIX, aczkolwiek dostępne są również implementacje DNS na platformę
Windows NT.

Specyficzne określanie nazw

Metoda specyficznego określania nazw jest używana tylko w sieciach
Windows. Stanowi kombinację następujących technik:
„

Lokalna transmisja w trybie broadcast

„

Usługa określania nazw w Windows WINS (Windows Internet Name
Service)

„

Użycie pliku LMHOSTS.

Lokalna transmisja w trybie broadcast jest rozsyłanym w lokalnej sieci
żądaniem podania adresu IP dla określanej nazwy. Komputer, który roz-
pozna w żądaniu swoją nazwę, zwraca swój adres IP. Jeśli w sieci nie ma
komputera o takiej nazwie, wówczas nie nadchodzi żadna odpowiedź
i lokalna transmisja nie jest w stanie przypisać nazwie adresu IP. Metodę
tę nazywa się również określaniem nazwy w trybie b-węzła (b-node).

Konfigurowanie TCP/IP

103

Usługa określania nazw w Windows WINS (Windows Internet Name Service)
jest implementacją serwera NBNS (NetBIOS Name Server). Sposób okre-
ślania nazw przez NBNS definiują dokumenty RFC 1001 i RFC 1002.

Plik LMHOSTS zawiera tablicę odwzorowania nazw NetBIOS na adresy
IP. Struktura pliku LMHOSTS przypomina plik HOSTS, z tym że zawiera
pewne dodatkowe wskazówki ułatwiające konfigurację określania nazw.
Windows NT sprawdza plik LMHOSTS tylko wtedy, jeśli zawiodą inne
metody.

Kolejność używania poszczególnych metod określania nazw zależy od
konfiguracji komputera Windows NT. Możliwe są cztery tryby określania
nazw: tryb b-węzła (b-node), p-węzła (p.-node), m-węzła (m-node) oraz h-
węzła (h-node). Poniżej opisano wszystkie cztery metody:

„

Podczas określania nazw w trybie b-węzła (węzeł broadcast) do reje-
stracji i określania nazw używa się wyłącznie pakietów rozsyłanych
w trybie broadcast. Ponieważ transmisje broadcast mogą doprowa-
dzić do zablokowania sieci, metody tej należy używać tylko w małych
sieciach lokalnych nie posiadających serwera WINS. Aby sieć używała
trybu b-węzła należy upewnić się, że nie ma w niej żadnych serwerów
WINS i że komputery Windows są skonfigurowane tak, aby nie uży-
wały WINS (tzn. że podczas konfiguracji klienta Windows nie należy
wpisywać adresu IP serwera WINS).

„

Podczas określania nazw w trybie p-węzła (węzeł równorzędny)
używa się wyłącznie serwerów WINS. Jeśli nie można określić nazwy
poprzez WINS, wówczas nie używa się innych metod.

„

Podczas określania nazw w trybie m-węzła (węzeł mieszany) używa
się kombinacji trybów b-węzła i p-węzła. Najpierw próbuje się okre-
ślić nazwę w trybie b-węzła, a jeśli to nie skutkuje, wówczas klient
używa trybu p-węzła. Metoda ta używa najpierw transmisji w trybie
broadcast, a następnie serwera WINS. Sprawdza się w niewielkich
sieciach posiadających serwer WINS, którego baza danych od jakiegoś
czasu nie była uzupełniana o nowe wpisy z nazwami hostów.

„

Podczas określania nazw w trybie h-węzła (węzeł hybrydowy) rów-
nież używa się kombinacji trybów b-węzła i p-węzła z tym, że naj-
pierw próbuje się określić nazwę w trybie p-węzła. Jeśli to nie skutku-
je, wówczas klient używa trybu b-węzła. Metoda ta tylko
w ostateczności powoduje transmisje w trybie broadcast, ponieważ
najpierw korzysta z serwera WINS. Jest najbardziej wydajną z opisa-
nych metod; sprawdza się w większych sieciach posiadających nieza-
wodny serwer WINS, którego baza danych jest systematycznie uzu-
pełniana o nowe wpisy z nazwami hostów.

Rozdział 4

104

Konfigurowanie bufora nazw NetBIOS

Komputer Windows NT określający nazwę sprawdza najpierw specjalny
obszar w pamięci, nazywany buforem nazw NetBIOS. Obszar ten zawie-
ra listę nazw komputerów i ich adresów IP. Ponieważ informacje te są
przechowywane w podręcznej pamięci, dostęp do nich jest szybki. Za-
wartość bufora nazw pochodzi z dwóch źródeł:

„

odpowiedzi na poprzednie żądania określenia nazwy

„

wstępnego załadowania bufora nazwami z pliku LMHOSTS (przy
użyciu dyrektywy #PRE)

Oprócz wpisów wstępnie załadowanych z pliku, wszystkie inne wpisy są
po pewnym czasie usuwane z bufora nazw. Standardowo jest to 10
sekund. Czytelnicy znający Protokół Określania Adresu ARP (Address
Resolution Protocol) zauważą, że bufor NetBIOS działa w zbliżony sposób.

W celu oczyszczenia bufora nazw i załadowania go ponownie używamy
następującego polecenia:

nbtstat -R

Opcja -R musi być napisana dużą literą. Istnieje także opcja -r, która
podaje statystykę określania nazw.

Konfigurację parametrów bufora nazw umożliwiają dwa wpisy
w Rejestrze Windows. Można je znaleźć pod następującym kluczem:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters

Wpisy dotyczące bufora nazw wyglądają następująco:

„Size/Small/Medium/Large

. Parametru tego używa się do określenia

ilości nazw przechowywanych w buforze. Rozmiar bufora można
ustawić na mały, średni lub duży. Liczba 1 oznacza mały bufor,
mogący przechowywać 16 nazw. Liczba 2 oznacza średni bufor,
mogący przechować 64 nazwy. Liczba 3 oznacza duży bufor, mogący
przechować 128 nazw. W wielu sieciach standardowa wartość 1 jest
wystarczająca. Parametr jest typu REG_DWORD.

„CacheTimeout.

Parametru tego używa się do określenia liczby sekund,

przez którą wpis pozostanie w buforze nazw. W wielu sieciach
standardowa wartość 0x927C0 (600 000 sekund, czyli 10 minut) jest
wystarczająca. Parametr jest typu REG_DWORD.

„

Rysunek 4.1 pokazuje omawiane parametry wraz z innymi wpisami
dotyczącymi NetBT.

Konfigurowanie TCP/IP

105

Rysunek 4.1

Klucz rejestru
NetBT/Parameters.

Konfigurowanie określania nazw poprzez transmisje w trybie
broadcast

Jeśli proces określający nazwę nie odnajdzie jej w buforze nazw, wówczas
może wysłać żądanie w trybie broadcast (o ile jest skonfigurowany jako
b-węzeł, m-węzeł lub p-węzeł). NetBIOS rozsyła pakiet NameQuery (zapy-
tanie o nazwę) do węzłów lokalnej sieci poprzez port 137 UDP (patrz
tabela 4.1). Każdy z komputerów przetwarza otrzymany pakiet. Jeśli
komputer używa protokołu NetBT, wówczas pakiet jest przekazywany
do modułu NetBIOS. Moduł NetBIOS porównuje nazwę w żądaniu
z zarejestrowaną nazwą komputera. Jeśli są one zgodne, wówczas wysyła
pakiet z pozytywną odpowiedzią na NameQuery.

Nadejście więcej niż jednej odpowiedzi oznacza, że w

sieci są

zduplikowane nazwy NetBIOS; sytuacja taka jest raportowana na konsoli
komputera odbierającego odpowiedzi. Trzeba zauważyć, że pakiety
NameQuery

wysłane w trybie broadcast są przetwarzane we wszystkich

komputerach w sieci aż do warstwy sesji, niezależnie od tego, czy
komputer potrafi udzielić odpowiedzi, czy też nie. Transmisje takie
powodują więc nie tylko wzmożenie ruchu w sieci, ale także w wielu
przypadkach marnotrawstwo czasu.

Rozdział 4

106

Parametry zapytań o nazwę w trybie broadcast są określone przez dwa
wpisy w Rejestrze. Można je znaleźć pod następującym kluczem:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters

Wpisy dotyczące trybu broadcast wyglądają następująco:

„BcastNameQueryCount

. Parametru tego używa się do określenia, ile

razy system będzie próbował wysłać zapytanie NameQuery. W wielu
sieciach standardowa wartość 3 jest wystarczająca. Parametr jest typu
REG_DWORD

.

„BcastQueryTimeout

. Parametr ten określa liczbę sekund, po której

można ponowić wysłanie zapytania NameQuery. Standardową
wartością jest 7,5 sekundy. Parametr jest typu REG_DWORD i jest
mierzony w 1/100 sekundy.

Konfigurowanie pliku LMHOSTS

W małych sieciach Windows NT używających NetBIOS ponad TCP/IP,
do określania nazw komputerów zazwyczaj używa się pliku LMHOSTS.
Jeśli w sieci znajduje się serwer WINS, wówczas używanie pliku
LMHOSTS nie jest potrzebne (pełni tylko rolę rezerwową). Z pliku
LMHOSTS można korzystać w małych sieciach, w których transmisje
w trybie broadcast zazwyczaj nie sprawiają problemów. W większych
sieciach transmisje takie mogą jednak zająć znaczną szerokość dostępne-
go pasma, więc konstruktorzy sieci starają się ich unikać.

Składnia pliku LMHOSTS

Plik LMHOSTS zawiera informację o odwzorowaniu nazw NetBIOS
komputerów Windows NT na ich adresy IP. Plik jest umieszczony
w katalogu

\%KatalogSystemowy%\SYSTEM32\DRIVERS\ETC

, a

jego

składnia jest kompatybilna ze składnią pliku LMHOSTS używanego
przez Microsoft LAN Manager 2.x.

Poniżej przedstawiono przykładowy plik LMHOSTS, instalowany na
komputerach Windows NT:

# Copyright (c) 1993-1995 Microsoft Corp.
#
# This is a sample LMHOSTS file used by the Microsoft TCP/IP for
Windows NT.
#
# This file contains the mappings of IP addresses to NT
computernames
# (NetBIOS) names. Each entry should be kept on an individual
line.
# The IP address should be placed in the first column followed by
the

Konfigurowanie TCP/IP

107

# corresponding computername. The address and the computername
# should be separated by at least one space or tab. The “#"
character
# is generally used to denote the start of a comment (see the
exceptions
# below).
#
# This file is compatible with Microsoft LAN Manager 2.x TCP/IP
lmhosts
# files and offers the following extensions:
#
# #PRE
# #DOM:<domain>
# #INCLUDE <filename>
# #BEGIN_ALTERNATE
# #END_ALTERNATE
# \0xnn (non-printing character support)
#
# Following any entry in the file with the characters “#PRE“ will
cause
# the entry to be preloaded into the name cache. By default,
entries are
# not preloaded, but are parsed only after dynamic name resolution
fails.
#
# Following an entry with the “#DOM:<domain>" tag will associate
the
# entry with the domain specified by <domain>. This affects how the
# browser and logon services behave in TCP/IP environments. To
preload
# the hostname associated with #DOM entry, it is necessary to also
add a
# #PRE to the line. The <domain> is always preloaded although it
will not
# be shown when the name cache is viewed.
#
# Specifying “#INCLUDE <filename>" will force the RFC NetBIOS (NBT)
# software to seek the specified <filename> and parse it as if it
were
# local. <filename> is generally a UNC-based name, allowing a
# centralized lmhosts file to be maintained on a server.
# It is ALWAYS necessary to provide a mapping for the IP address of
the
# server prior to the #INCLUDE. This mapping must use the #PRE
directive.
# In addition the share “public" in the example below must be in
the
# LanManServer list of “NullSessionShares" in order for client
machines
# to be able to read the lmhosts file successfully. This key is
under
# \machine\
# system\currentcontrolset\services\lanmanserver\parameters\
Ânullsessionshares
# in the Registry. Simply add “public" to the list found there.
#
# The #BEGIN_ and #END_ALTERNATE keywords allow multiple #INCLUDE
# statements to be grouped together. Any single successful include
# will cause the group to succeed.
#
# Finally, non-printing characters can be embedded in mappings by
# first surrounding the NetBIOS name in quotations, then using the

Rozdział 4

108

# \0xnn notation to specify a hex value for a non-printing
character.
#
# The following example illustrates all of these extensions:
#
102.54.94.97 rhino #PRE #DOM:networking #net group’s
DC
102.54.94.102 “appname \0x14" #special app
server
102.54.94.123 popular #PRE #source server
102.54.94.117 localsrv #PRE #needed for
the Âinclude
#
# #BEGIN_ALTERNATE
# #INCLUDE \\localsrv\public\lmhosts
# #INCLUDE \\rhino\public\lmhosts
# #END_ALTERNATE
#
# In the above example, the “appname" server contains a special
# character in its name, the “popular" and “localsrv" server names
are
# preloaded, and the “rhino" server name is specified so it can be
used
# to later #INCLUDE a centrally maintained lmhosts file if the
“localsrv"
# system is unavailable.
#
# Note that the whole file is parsed including comments on each
lookup,
# so keeping the number of comments to a minimum will improve
performance.
# Therefore it is not advisable to simply add lmhosts file entries
onto
# the end of this file.

Komentarze są poprzedzone znakiem #. Jeśli pierwszych kilka znaków
następujących po # odpowiada którejś z dyrektyw objaśnionych w tabeli
4.2, wówczas linia traktowana jest jako specjalne polecenie. Ponieważ
dyrektywy umieszczone są za znakiem komentarza, plik LMHOSTS jest
kompatybilny z plikiem HOSTS, używanym przez aplikacje Windows
Sockets i UNIX.

W przedstawionym powyżej przykładowym pliku LMHOSTS znajduje
się następujący wpis:

102.54.94.102 "appname \0x14" #special app server

Pomiędzy nazwą a znakiem specjalnym jest osiem spacji wypełnienia;
całkowita długość nazwy wynosi 16 znaków.

Kod 0x14 jest jednobajtowym identyfikatorem usługi aplikacyjnej.

Tabela 4.2 Dyrektywy w LMHOSTS

Dyrektywa Opis

Konfigurowanie TCP/IP

109

Dyrektywa Opis

#PRE Dyrektywę tę umieszcza się po wpisie w pliku LMHOSTS, aby

wstępnie załadować wpis do bufora nazw. Wpisy, po których
nie następuje dyrektywa #PRE nie są ładowane do bufora nazw,
przetwarza się je tylko wtedy, jeśli serwer WINS i broadcast
NameQuery nie są w stanie określić nazwy. Wszystkie wpisy
dodawane przez dyrektywę #INCLUDE muszą być wstępnie
ładowane do bufora nazw. Należy zatem umieścić #PRE po
każdym wpisie w pliku dołączanym przez #INCLUDE -
w innym przypadku wpis zostanie zignorowany.

#DOM: nazwa_domeny Dyrektywa ta oznacza, że komputer o danej nazwie jest

kontrolerem domeny (albo podstawowym, albo zapasowym)
zdefiniowanej przez nazwę_domeny. Dyrektywa #DOM
zmienia sposób działania usług przeglądania i logowania
w sieciach, które składają się z segmentów połączonych przez
routery.

#INCLUDE
nazwa_pliku

Plik o podanej nazwie zostanie przetworzony jako plik
odwzorowania nazw na adresy IP. W nazwie_pliku można
używać konwencji UNC, co umożliwia umieszczenie pliku
odwzorowań na zdalnym komputerze. Jeśli komputer
wskazywany przez nazwę UNC znajduje się poza obszarem
dostępnym dla transmisji w trybie broadcast, wówczas przed
dyrektywą #INCLUDE należy umieścić odwzorowanie jego
nazwy na adres IP. Po nazwie UNC komputera można umieścić
dyrektywę #PRE, aby załadować nazwę do bufora nazw. Wpisy
umieszczone w pliku dołączanym przez #INCLUDE muszą być
wstępnie załadowane do bufora, gdyż w innym przypadku
zostaną zignorowane.

#BEGIN_ALTERNAT
E

Używane do zaznaczenia początku bloku poleceń #INCLUDE.
Komputer określający nazwę kolejno próbuje dołączyć
wymienione pliki #INCLUDE. Po pierwszej udanej próbie
pozostałe pliki #INCLUDE nie są przetwarzane. Jeśli nie uda
się dołączyć żadnego z wymienionych w bloku plików,
wówczas do dziennika zdarzeń dodawany jest komunikat
o nieudanej próbie dołączenia bloku plików. Plik dziennika
można obejrzeć przy pomocy programu Event Viewer.

#END_ALTERNATE

Zaznacza koniec bloku poleceń #INCLUDE. Każda dyrektywa
#BEGIN_ALTERNATE musi posiadać odpowiadającą jej
dyrektywę #END_ALTERNATE.

\0xnn Kod

służący do włączania niedrukowalnych znaków w nazwy

NetBIOS. Nazwy NetBIOS używające takich znaków muszą
być umieszczone w cudzysłowie. Kodu tego należy używać
tylko dla specjalnych nazw urządzeń i własnych aplikacji.
Używając tej notacji trzeba pamiętać, że nazwa NetBIOS
w cudzysłowie jest dopełniana spacjami do długości 16
znaków.

Rozdział 4

110

Sposób przetwarzania pliku LMHOSTS

Plik LMHOSTS jest przydatny zwłaszcza wtedy, kiedy w segmencie sieci,
w którym znajduje się klient Windows NT, nie istnieje serwer WINS -
wówczas do określania nazw służą transmisje w trybie
broadcast. Taki sposób określania nazw korzysta z pakietów typu
broadcast warstwy IP, które zazwyczaj są blokowane przez routery IP.
Określanie nazw przez transmisję w trybie broadcast nie jest więc
przekazywane poza router. Windows NT rozwiązuje ten problem
w następujący sposób:

1. Windows NT utrzymuje lokalny bufor nazw, inicjalizowany podczas

startu komputera. Podczas określania nazw bufor nazw jest
sprawdzany w pierwszej kolejności.

2. Jeśli nie znaleziono odpowiedniego wpisu w buforze, Windows NT

używa do określenia nazwy transmisji w trybie broadcast. Sposób ten,
udokumentowany w RFC 1001 i RFC 1002, nazywany jest określaniem
nazw w trybie b-węzła.

3. Jeśli zawiedzie transmisja w trybie broadcast, wówczas w poszuki-

waniu odpowiedniego wpisu przetwarza się plik LMHOSTS.

4. Jeśli w pliku LMHOSTS nie ma odpowiedniego wpisu, wówczas nie

da się określić nazwy. Generowany jest komunikat o błędzie.

Bufor nazw jest inicjalizowany wpisami oznaczonymi w pliku LMHOSTS
dyrektywą #PRE. Plik może np. zawierać następujące wpisy, z których
jedynie niektóre oznaczono dyrektywą #PRE:

144.19.74.1 uziel
144.19.74.2 zadkiel #PRE
144.19.74.3 gabriel
144.19.74.4 uriel
144.19.74.5 michael #PRE
144.19.74.6 chamuel

Bufor można wstępnie załadować wpisami dla hostów takich jak serwe-
ry, które są zazwyczaj stale włączone.

W omawianym przykładzie, odwzorowania dla hostów zadkiel i michael
są wstępnie ładowane do bufora nazw podczas startu systemu. Jeśli
komputer szuka adresu hosta zadkiel lub michael, wówczas nie generuje
żadnych transmisji w trybie broadcast, ponieważ bufor nazw zawiera
odpowiednie odwzorowanie. Jeśli komputer określa nazwy uziel, gabriel,
uriel lub chamuel, wówczas używa transmisji w trybie broadcast. Jeśli to
zawiedzie, nazwę określa się przetwarzając plik LMHOSTS, przy czym
przez pewien czas znalezione odwzorowanie jest przechowywane
w buforze nazw na wypadek, gdyby wkrótce miało zostać ponownie

Konfigurowanie TCP/IP

111

użyte. Nazwy określone przez broadcast są również przechowywane
w buforze nazw przez określony czas.

Bufor nazw jest ograniczony limitem 100 wstępnie ładowanych wpisów.
Jeśli plik LMHOSTS zawiera więcej niż 100 wpisów oznaczonych
dyrektywą #PRE, wówczas ładowane jest tylko pierwsze 100 wpisów.
Pozostałe wpisy nie są ładowane do bufora, ale bierze je się pod uwagę
podczas przetwarzania pliku LMHOSTS.

Jeśli w pliku dokonano zmian, oznaczając niektóre wpisy dyrektywą
#PRE, wówczas można wyczyścić bufor nazw i załadować go ponownie
przy użyciu następującego polecenia:

nbtstat -R

Zaletą tego polecenia jest możliwość załadowania bufora bez
restartowania komputera.

Używanie wspólnego pliku LMHOSTS

Plik LMHOSTS jest przechowywany w lokalnym komputerze Windows
NT w katalogu \%KatalogSystemowy%\SYSTEM32\DRIVERS\ETC. W przy-
padku dokonywania częstych zmian, utrzymanie plików na różnych
komputerach w spójnej postaci może być trudne.

Używanie dyrektywy #PRE upraszcza utrzymanie porządku w pliku
LMHOSTS. Można umieścić pojedynczy plik odwzorowań na serwerze
o nazwie np. NTKS, a w plikach LMHOSTS pozostałych komputerów
wpisać dyrektywę:

#INCLUDE \\NTKS\ETC\

LMHOSTS

W tym przykładzie ETC jest nazwą dzielonego katalogu \%Katalog
Systemowy%\SYSTEM32\DRIVERS\ETC

w

komputerze NTKS.

Rozwiązanie takie ma tę zaletę, że nazwy wstępnie ładowane do bufora
są przechowywane we wspólnym pliku. Jeśli komputer NTKS znajduje
się poza obszarem dostępnym dla trybu broadcast, należy przed użyciem
dyrektywy #INCLUDE podać odwzorowanie jego nazwy na adres IP. Jeśli
NTKS posiada np. adres IP 134.21.22.13, wówczas pliki LMHOSTS
w innych komputerach mogą zawierać następujące wpisy:

134.21.22.13 NTKS #PRE
#INCLUDE \\NTKS\ETC\LMHOSTS

Aby zapewnić, że wspólny plik LMHOSTS będzie zawsze dostępny,
można umieścić jego kopie na innych komputerach Windows NT
używając usługi replikacji Windows NT. Wspólny plik LMHOSTS musi
znajdować się na serwerze Windows NT, ponieważ tylko on może służyć
jako serwer eksportujący podczas replikacji.

Rozdział 4

112

Dyrektywy #BEGIN_ALTERNATE i #END_ALTERNATE przydają się,
aby wskazać, że wspólny plik LMHOSTS można znaleźć także na
zapasowych serwerach. Jak stwierdzono w tabeli 4.1, dyrektywy te
zaznaczają blok poleceń #INCLUDE; komputer może użyć
któregokolwiek z dołączanych przez #INCLUDE plików.

W poniższym przykładzie przedstawiono sposób określenia
alternatywnych plików LMHOSTS:

#BEGIN_ALTERNATE
#INCLUDE \\NTKS\ETC\LMHOSTS # Główne źródło pliku LMHOSTS
#INCLUDE \\NTBC1\ETC\LMHOSTS # Zapasowe źródło 1
#INCLUDE \\NTBC2\ETC\LMHOSTS # Zapasowe źródło 2
#END_ALTERNATE

W przykładzie tym zakłada się, że plik LMHOSTS jest replikowany
w zapasowych komputerach Windows NT, przy czym we wszystkich
trzech komputerach nazwą dzielonego katalogu:
\%KatalogSystemowy%\SYSTEM32\DRIVERS\ETC

jest ETC. Blokowe

dołączanie plików kończy się pomyślnie, jeśli dostępny jest którykolwiek
z wymienionych plików. Jeśli żaden z plików nie jest dostępny, ponieważ
np. komputery są wyłączone albo podano niewłaściwą ścieżkę, wówczas
do dziennika zdarzeń dodawany jest komunikat o błędzie.

Określanie kontrolerów domen w pliku LMHOSTS

Kontrolery domeny posiadają bazę danych z kontami użytkowników, do
której często odwołują się klienci z danej domeny. Oprócz uwierzytelnia-
nia logowania, kontrolery domen zajmują się synchronizacją baz danych
z kontami użytkowników, zmianami haseł, synchronizacją listy głównej
przeglądarki i innymi zmianami w domenie. W dużych sieciach kontrole-
ry domen mogą znajdować się w innym segmencie sieci, oddzielonym
routerem od odwołującego się do nich komputera Windows NT.

Dyrektywa #DOM w pliku LMHOSTS oznacza, że umieszczona przed nią
nazwa jest nazwą kontrolera domeny Windows NT. Wpisy oznaczone
dyrektywą #DOM są ładowane do specjalnego internetowego bufora
nazw grup, którego używa się do ograniczenia żądań dostępu do
lokalnego kontrolera domeny.

Jeśli kontroler domeny znajduje się w lokalnym segmencie sieci, dostęp
do niego umożliwiają żądania określenia nazw w trybie broadcast. Jeśli
jednak jest poza granicą routera, np. w innej podsieci, wówczas nie jest
osiągalny dla żądań w trybie broadcast. Oznaczając wpis w pliku
LMHOSTS dyrektywą #DOM sprawiamy, że protokół TCP/IP używa
datagramów IP z adresem przeznaczenia określającym kontroler dome-
ny. Ponieważ te datagramy nie są wysyłane w trybie broadcast, lokalne

Konfigurowanie TCP/IP

113

routery mogą je przekazać do właściwego miejsca przeznaczenia. Na
rysunku 4.3 wpis dla kontrolera domeny NTS1 nie jest oznaczony przez
#DOM

, podczas gdy wpis dla NTS2 definiuje, że jest to kontroler domeny

KINETD:

192.12.60.2 NTS2 #DOM:KINETD

W przykładzie z rysunku 4.3, żądanie określenia nazwy NTS1 w trybie
broadcast jest blokowane przez router IP, podczas gdy żądanie
określenia nazwy NTS2 jest przez niego przekazywane dzięki użytej
dyrektywie #DOM.

Jeśli żądanie określenia nazwy jest związane z kontrolerem domeny,
którego nazwa znajduje się w internetowym buforze nazw grup,
wówczas używa się najpierw serwera WINS (jeśli istnieje) lub transmisji
w trybie broadcast. Jeśli ta metoda określania nazwy zawiedzie, wówczas
datagram jest wysyłany do kontrolera domeny wymienionej
w internetowym buforze nazw grup, po czym jest on lokalnie rozsyłany
w trybie broadcast.

Ponieważ domeny mogą obejmować wiele podsieci IP, w

celu

zapewnienia poprawnego określania nazw należy stosować się do
poniższych wskazówek:

Rozdział 4

114

Rysunek 4.3

Używanie dyrektywy
#PRE w pliku
LMHOSTS.

„

Wszystkie nazwy kontrolerów domen zawarte w lokalnych plikach
LMHOSTS komputerów Windows NT muszą być oznaczone
dyrektywą #DOM, aby możliwy był dostęp do nich poprzez routery.

„

Wszystkie kontrolery domen muszą posiadać w swoich plikach
LMHOSTS odwzorowania nazw wszystkich pozostałych kontrolerów
domen. Dzięki temu po przejęciu zadań podstawowego kontrolera
domeny (PDC) przez kontroler zapasowy (BDC), nazwy nadal będą
określane poprawnie. Odwzorowanie to umożliwia również
poprawną komunikację pomiędzy kontrolerami domen.

„

Jeśli zamierzamy przeglądać inną domenę, musimy upewnić się, że
w lokalnym pliku LMHOSTS zawarte jest odwzorowanie nazwy na
adres IP podstawowego kontrolera tej domeny (oraz kontrolerów
zapasowych, gdyby któryś z nich miał przejąć funkcje kontrolera
podstawowego).

„

Jeśli domeny pozostają w związku wzajemnego zaufania (trust
relationship), wówczas należy upewnić się, że nazwy kontrolerów
tych domen są wymienione w pliku LMHOSTS.

Konfigurowanie TCP/IP

115

Konfigurowanie pliku HOSTS

Plik HOSTS jest używany przez aplikacje narzędziowe przeniesione
z sytemu UNIX (np. PING lub NETSTAT) do odwzorowania nazw kom-
puterów na adresy IP.

Składnia pliku HOSTS jest podobna do składni pliku LMHOSTS. Plik
HOSTS znajduje się w tym samym katalogu (\%KatalogSystemowy\
SYSTEM32\DRIVERS\ETC

), co plik LMHOSTS. Poniżej wymieniono

różnice w składni obu plików:

„

W pliku HOSTS nie można używać żadnych specjalnych dyrektyw,
jak #PRE, #DOM itp.

„

Można zdefiniować kilka zamienników nazw dla danego adresu IP,
umieszczając je w tej samej linii i rozdzielając spacjami.

Ogólną składnię każdej linii pliku HOSTS można przedstawić
następująco:

AdresIP Nazwa1 [Nazwa2 ... NazwaN] # Komentarz, albo
# Komentarz

Nazwa2

do NazwaN są to opcjonalne zamienniki nazwy Nazwa1. Tak jak

w przypadku pliku LMHOSTS, wszystkie znaki następujące po # są
traktowane jako komentarz.

Poniżej przedstawiono przykładowy plik HOSTS:

# Copyright (c) 1993-1995 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows
NT.
#
# This file contains the mappings of IP addresses to hostnames.
Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding
hostname.
# The IP address and the hostname should be separated by at least
one
# space.
#
# Additionally, comments (such as these) may be inserted on
individual
# lines or following the machine name denoted by a ‘#’ symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host

127.0.0.1 localhost
199.245.180.1 ntws1

199.245.180.2 ntws2
199.245.180.3 ntws3
199.245.180.4 ntws4

Rozdział 4

116

199.245.180.5 ntws5
199.245.180.6 ntws6 phylos anzimee

Dodatkowe pliki związane z usługami TCP/IP

Jak wspomniano wcześniej, plik HOSTS jest potrzebny do pracy
aplikacjom przeniesionym na platformę Windows NT z systemu UNIX.
Oprócz pliku HOSTS istnieją trzy inne pliki używane przez tego rodzaju
aplikacje. Są to pliki NETWORKS, PROTOCOL i SERVICES, znajdujące
się w katalogu \%KatalogSystemowy\SYSTEM32\DRIVERS\ETC. Zazwyczaj
edycja tych plików jest niepotrzebna, o ile nie zamierzamy nadać sieciom
symbolicznych nazw lub przenieść nowych protokołów i usług do
środowiska Windows.

Plik NETWORKS

Plik NETWORKS jest używany do identyfikacji poszczególnych sieci
tworzących sieć złożoną. Jest zbliżony koncepcją do pliku HOSTS - plik
HOSTS określa związki pomiędzy adresami i nazwami komputerów,
a plik NETWORKS związki pomiędzy adresami i nazwami sieci.

Każda linia pliku NETWORKS zawiera informacje w następującym
formacie:

nazwa_sieci numer_sieci[/maska_podsieci] zamiennik # komentarz

nazwa_sieci

jest identyfikatorem reprezentującym nazwę sieci,

a numer_sieci jest częścią adresu IP identyfikującą sieć. Nazwa sieci nie
może zawierać znaków tabulacji, spacji ani znaku # i może występować
tylko raz w całym pliku HOSTS.

maska_podsieci

jest maską używaną dla danej sieci. Można podać ją

w kropkowanej notacji dziesiętnej lub szesnastkowej. Nawiasy
kwadratowe w podanej wyżej składni oznaczają, że wprowadzenie maski
podsieci jest opcjonalne. Jeśli maska podsieci nie zostanie wprowadzona,
oznacza to, że nie jest używana.

Opcjonalny zamiennik definiuje inne nazwy, pod którymi znana jest sieć.
Nazwa_sieci

jest zazwyczaj pisana małymi literami, a zamiennik określa

świadczone przez nią usługi i jest pisany dużymi literami.

# komentarz

służy do umieszczania komentarzy w pliku. Wszystkie znaki

pomiędzy # i końcem linii są ignorowane. # komentarz może wystąpić
w oddzielnej linii.

Nazwy sieci wyszczególnione w pliku NETWORKS mogą być przydatne
podczas posługiwania się narzędziami konfiguracyjnymi i poleceniami

Konfigurowanie TCP/IP

117

używającymi adresów sieci. Nazwa sieci może być wówczas używana
zamiennie z jej adresem. Ponieważ nazwy są łatwiejsze do zapamiętania
niż adresy, administrator systemu może dokonać zmian w tym pliku.

Poniżej przedstawiono przykładowy plik NETWORKS:

# Copyright © 1993-1995 Microsoft Corp.
#
# This file contains network name/network number mappings for
# local networks. Network numbers are recognized in dotted decimal
form.
#
# Format:
#
# <network name> <network number> [aliases...] [#<comment>]
#
# For example:
#
#

oopback

127

# campus

284.122.107

# ondon

284.122.108

loopback 127
Kinet

199.245.180

SCSNet

200.24.4.0

MyNet

144.19

Plik PROTOCOL

Plik PROTOCOL jest używany do określenia nazw protokołów
i odpowiadających im numerów. Numer protokołu odpowiada wartości
pola identyfikatora protokołu w nagłówku IP. Pole to jest używane do
określenia protokołu wyższej warstwy korzystającego z usług IP.

Plik PROTOCOL towarzyszy modułowi TCP/IP i zawiera numery
wszystkich rozpowszechnionych protokołów; jego edycja nie powinna
być potrzebna.

Każda linia pliku PROTOCOL zawiera informacje w następującym
formacie:

nazwa_protokołu numer_protokołu [zamiennik] # komentarz

nazwa_protokołu

jest identyfikatorem reprezentującym nazwę protokołu,

a numer_protokołu jest wartością określającą używany protokół
w nagłówku IP. Nazwa protokołu nie może zawierać znaków tabulacji,
spacji ani znaku # i może występować tylko raz w całym pliku
PROTOCOL.

Opcjonalny zamiennik definiuje inne nazwy, pod którymi znany jest
protokół. Nazwa_protokołu jest zazwyczaj pisana małymi literami,
a zamiennik określa świadczone przez niego usługi i jest pisany dużymi
literami.

Rozdział 4

118

# komentarz

służy do umieszczania komentarzy w pliku. Wszystkie znaki

pomiędzy # i końcem linii są ignorowane. # komentarz może wystąpić
w oddzielnej linii.

Poniżej przedstawiono przykładowy plik PROTOCOL:

# Copyright © 1993-1995 Microsoft Corp.
#
# This file contains the Internet protocols as defined by RFC 1060
# (Assigned Numbers)
#
# Format:
#
# <protocol name> <assigned number> [aliases...]
[#<comment>]
#

ip

0

IP

# Internet protocol

icmp

1

ICMP

# Internet control message protocol

ggp

3

GGP

# Gateway-gateway protocol

tcp

6

TCP

# Transmission control protocol

egp

8

EGP

# Exterior gateway protocol

pup

12

PUP

# PARC universal packet protocol

udp

17

UDP

# User datagram protocol

hmp

20

HMP

# Host monitoring protocol

xns-idp 22

XNS-IDP

# Xerox NS IDP

rdp

27

RDP

# ‘reliable datagram’ protocol

rvd 66 RVD

#

Plik SERVICES

Plik SERVICES służy do określenia:
„

Nazw usług

„

Protokołu transportowego

„

Numeru portu używanego przez usługę

Nazwy usług określają programy pracujące w warstwie procesu/aplika-
cji modelu DoD (Department of Defense). Przykładami takich usług mogą
być Telnet, FTP, SMTP, SNMP itp. Usługi te korzystają z protokołów
transportowych, jak np. TCP i UDP. Plik konfiguracyjny SERVICES defi-
niuje rodzaj używanego protokołu transportowego. Niektóre z usług
mogą korzystać zarówno z TCP, jak i UDP. W takim przypadku usługa
jest wymieniana dwukrotnie: raz dla protokołu TCP i raz dla UDP. Nu-
mery portów określają używany przez usługi aplikacyjne port protokołu
transportowego.

Plik PROTOCOL towarzyszy modułowi TCP/IP i zawiera wszystkie
rozpowszechnione usługi TCP/IP; jego edycja nie powinna być
potrzebna.

Każda linia pliku SERVICES zawiera informacje w

następującym

formacie:

Konfigurowanie TCP/IP

119

usługa port/protokół transportowy [zamiennik] # komentarz

usługa jest identyfikatorem reprezentującym nazwę usługi. Może to być
np. Telnet, FTP, FTP-DATA, SMTP albo SNMP. Nazwa usługi nie może
zawierać znaków tabulacji, spacji ani znaku # i może występować tylko
raz w całym pliku SERVICES.

Opcjonalny zamiennik definiuje inne nazwy, pod którymi znana jest
usługa

# komentarz

służy do umieszczania komentarzy w pliku. Wszystkie znaki

pomiędzy # i końcem linii są ignorowane. # komentarz może wystąpić
w oddzielnej linii.

Poniżej przedstawiono przykładowy plik SERVICES:

# Copyright (c) 1993-1995 Microsoft Corp.
#
# This file contains port numbers for well-known services as
defined by
# RFC 1060 (Assigned Numbers).
#
# Format:
#
# <service name> <port number>/<protocol> [aliases...]
[#<comment>]
#

echo 7/tcp
echo 7/udp
discard 9/tcp

sink

null

discard 9/udp

sink

null

systat 11/tcp
systat 11/tcp

users

daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp

quote

qotd 17/udp

quote

chargen 19/tcp

ttytst

source

chargen 19/udp

ttytst

source

ftp-data 20/tcp
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp

mail

time 37/tcp

timeserver

time 37/udp

timeserver

rlp

39/udp

resource

# resource location

name 42/tcp

nameserver

name 42/udp

nameserver

whois

43/tcp

nicname

# usually to sri-nic

domain

53/tcp

nameserver

# name-domain server

domain 53/udp

nameserver

nameserver

53/tcp

domain

# name-domain server

nameserver 53/udp domain
mtp 57/tcp

#

deprecated

bootp

67/udp

# boot program server

tftp 69/udp
rje 77/tcp

netrjs

finger 79/tcp

Rozdział 4

120

link 87/tcp

ttylink

supdup 95/tcp
hostnames

101/tcp

hostname

# usually from sri-nic

iso-tsap 102/tcp
dictionary 103/tcp webster
x400

103/tcp

# ISO Mail

x400-snd 104/tcp
csnet-ns 105/tcp
pop 109/tcp

postoffice

pop2

109/tcp

# Post Office

pop3 110/tcp

postoffice

portmap 111/tcp
portmap 111/udp
sunrpc 111/tcp
sunrpc 111/udp
auth 113/tcp

authentication

sftp 115/tcp
path 117/tcp
uucp-path 117/tcp
nntp

119/tcp

usenet

# Network News Transfer

ntp

123/udp

ntpd ntp

# network time protocol

(exp)
nbname 137/udp
nbdatagram 138/udp
nbsession 139/tcp
NeWS 144/tcp

news

sgmp 153/udp

sgmp

tcprepo 158/tcp

repository

#

PCMAIL

snmp 161/udp

snmp

snmp-trap 162/udp

snmp

print-srv

170/tcp

# network PostScript

vmnet 175/tcp
load 315/udp
vmnet0 400/tcp
sytek 500/udp
biff 512/udp

comsat

exec 512/tcp
login 513/tcp
who 513/udp

whod

shell

514/tcp

cmd

# no passwords used

syslog 514/udp
printer

515/tcp

spooler

# line printer spooler

talk 517/udp
ntalk 518/udp
efs

520/tcp

# for LucasFilm

route 520/udp

router

routed

timed 525/udp

timeserver

tempo 526/tcp

newdate

courier 530/tcp

rpc

conference 531/tcp chat
rvd-control 531/udp MIT

disk

netnews 532/tcp

readnews

netwall

533/udp

# for emergency broadcasts

uucp

540/tcp

uucpd

# uucp daemon

klogin

543/tcp

# Kerberos authenticated

Œrlogin
kshell

544/tcp

cmd

# and remote shell

new-rwho 550/udp

new-who #

experimental

remotefs

556/tcp

rfs_server rfs

# Brunhoff remote

filesystem
rmonitor 560/udp

rmonitord

#

experimental

monitor 561/udp

#

experimental

garcon 600/tcp

Konfigurowanie TCP/IP

121

maitrd 601/tcp
busboy 602/tcp
acctmaster 700/udp
acctslave 701/udp
acct 702/udp
acctlogin 703/udp
acctprinter 704/udp
elcsd 704/udp

#

errlog

acctinfo 705/udp
acctslave2 706/udp
acctdisk 707/udp
kerberos

750/tcp

kdc

# Kerberos authentication—

tcp
kerberos

750/udp

kdc

# Kerberos authentication—

udp
kerberos_master 751/tcp

#

Kerberos

authentication
kerberos_master 751/udp

#

Kerberos

authentication
passwd_server 752/udp

# Kerberos passwd server

userreg_server 753/udp

# Kerberos userreg server

krb_prop

754/tcp

# Kerberos slave propagation

erlogin

888/tcp

# Login and environment

Œpassing
kpop

1109/tcp

# Pop with Kerberos

phone 1167/udp
ingreslock 1524/tcp
maze 1666/udp
nfs

2049/udp

# sun nfs

knetd

2053/tcp

# Kerberos de-multiplexor

eklogin

2105/tcp

# Kerberos encrypted rlogin

rmt 5555/tcp

rmtd

mtb

5556/tcp

mtbd

# mtb backup

man

9535/tcp

# remote man server

w 9536/tcp
mantst

9537/tcp

# remote man server, testing

bnews 10000/tcp
rscs0 10000/udp
queue 10001/tcp
rscs1 10001/udp
poker 10002/tcp
rscs2 10002/udp
gateway 10003/tcp
rscs3 10003/udp
remp 10004/tcp
rscs4 10004/udp
rscs5 10005/udp
rscs6 10006/udp
rscs7 10007/udp
rscs8 10008/udp
rscs9 10009/udp
rscsa 10010/udp
rscsb 10011/udp
qmaster 10012/tcp
qmaster 10012/udp

Instalowanie i konfigurowanie serwera FTP

Systemy operacyjne Windows NT Server i Windows NT Workstation
można skonfigurować jako serwery FTP, co umożliwia klientom FTP

Rozdział 4

122

dostęp do znajdujących się na nich plików. Klientami FTP mogą być za-
równo inne komputery Windows NT, jak i

komputery UNIX,

DOS/Windows, Macintosh, VMS itd.

Serwer FTP w Windows NT obsługuje wszystkie polecenia klienta FTP.
Jest napisany jako wielowątkowa aplikacja Win32 i stosuje się do
wymagań zawartych w dokumentach RFC 959 i RFC 1123, definiujących
protokół i usługi FTP.

Serwery FTP korzystają z kont użytkowników systemu. W Windows NT
oprócz zdefiniowanych przez serwer FTP kont użytkowników istnieje
także konto użytkownika anonimowego

Serwer FTP jest częścią Microsoft Internet Information Server (IIS). Kolej-
ny podrozdział zawiera ogólne informacje dotyczące jego instalacji
i zastosowań.

Instalowanie i konfigurowanie serwera FTP w Windows NT Server

Serwer FTP i

inne usługi internetowe można zainstalować wraz

z

systemem Windows NT. W

tym celu podczas instalacji należy

zaznaczyć pole wyboru Microsoft Internet Information Server. Serwer
FTP, będący częścią IIS, zostanie wówczas zainstalowany automatycznie.

Jeśli system zainstalowano bez Internet Information Server, można dodać
IIS później. Serwer FTP potrzebuje do pracy protokołu TCP/IP, więc
TCP/IP należy zainstalować przed FTP.

Możliwe jest także zainstalowanie serwera FTP w

Windows NT

Workstation, jednakże liczba licencjonowanych, jednoczesnych połączeń
z Windows NT Workstation nie może przekroczyć 10. Z tego względu
serwer FTP instaluje się zazwyczaj w Windows NT Server, który nie ma
ograniczeń licencyjnych do 10 jednoczesnych połączeń.

Poniżej podano procedurę instalacji serwera FTP w Windows NT Server:

1. Zalogować się na komputer Windows NT (Server lub Workstation)

jako administrator.

2. Kliknąć podwójnie na ikonie Network w Control Panel, aby wyświetlić

okienko dialogowe Network.

3. Wybrać zakładkę Services i kliknąć przycisk Add.

4. Z listy w okienku dialogowym Add Network Services wybrać Microsoft

Internet Information Server

i kliknąć OK. Wprowadzić ścieżkę do plików

instalacyjnych.

Konfigurowanie TCP/IP

123

Pojawi się ekran powitalny instalacji Microsoft Internet Information Se-

rver

5. Zaznaczyć pole opcji FTP Service i kliknąć OK.

6. Następnie ukaże się okienko Publishing directories. Kliknąć OK, aby

zaakceptować domyślny katalog, albo wprowadzić inną nazwę
katalogu.

7. Ukaże się okienko obrazujące postępy w kopiowaniu plików na

komputer Windows NT.

Po zakończeniu kopiowania ponownie pojawi się zakładka Services.

Kliknąć przycisk Close, aby opuścić okienko dialogowe Sieć.

8. Aby skonfigurować serwer FTP należy kliknąć na ikonie Microsoft

Internet

Server w folderze Programs i wybrać Internet Service Manager.

Kliknąć podwójnie na serwerze FTP aby wywołać okienko dialogowe
FTP Service Properties

(patrz rysunek 4.4).

Rysunek 4.4

Okienko dialogowe FTP
Service Properties.

9. W polu Maximum Connections podać dopuszczalną liczbę

jednoczesnych sesji na serwerze FTP. Standardową wartością jest 20,
a maksymalną 32 767. Jeśli poda się wartość 0, wówczas nie istnieje
żaden limit i dopuszczalna jest dowolna liczba połączeń z serwerem.
Pola tego używa się w celu regulacji dopuszczalnego obciążenia
serwera FTP. Często praktykowane jest ograniczenie liczby połączeń
w granicach od 50 do 250, co pozwala uniknąć nadmiernego
obciążenia serwera.

Rozdział 4

124

10. W polu Connection Timeout podać, jak długo użytkownik może uży-

wać połączenia bez żadnej aktywności ze swej strony, zanim zostanie
odłączony. Wartością standardową jest 10 minut, a maksymalną 60
minut. Wartość 0 oznacza dowolnie długi czas braku aktywności. Po-
la tego używa się głównie ze względów bezpieczeństwa, aby zmniej-
szyć zagrożenie ze strony nienadzorowanych sesji FTP.

11. Zaznaczyć opcję Allow Anonymous Connections, aby umożliwić

użytkownikom o nazwie anonymous zalogowanie się na serwer FTP.
Użytkownik logujący się anonimowo na serwer FTP nie musi
podawać hasła, chociaż proszony jest o wpisanie adresu e-mail.
Nazwa użytkownika anonymous jest w

systemie Windows

zarezerwowana do logowania anonimowego, nie można więc
stworzyć konta użytkownika o nazwie anonymous. Standardowo
anonimowe logowanie jest niedozwolone, więc opisywana opcja jest
wyłączona.

12. W polu Username określić nazwę konta Windows NT, na które

logować się będą anonimowi użytkownicy - ich prawa dostępu będą
takie same, jak zdefiniowane dla tego konta. Standardowo od
anonimowego dostępu wykorzystywane jest konto o nazwie Guest.

13. W polu Password należy podać hasło dla konta użytkownika

określonego w polu Username.

14. Zaznaczyć pole wyboru Allow Only Anonymous Connections, jeśli

użytkownicy mają logować się na serwer FTP tylko anonimowo, nie
używając swoich nazw użytkownika i haseł. Ponieważ hasła FTP nie
są szyfrowane, ich używanie podczas dostępu do serwera FTP może
być zagrożeniem dla bezpieczeństwa. Standardowo opcja ta jest
wyłączona.

Dostęp do okienka dialogowego FTP User Sessions uzyskać można klikając

przycisk Current Sessions.

Pozostałe opcje konfiguracyjne znajdują się na innych zakładkach FTP Service

Properties

.

15. Kliknąć OK, aby zapisać konfiguracje usług FTP.

Konfigurowanie TCP/IP

125

Rysunek 4.5

Okienko FTP User Sessions

Zarządzanie usługami FTP

Po zainstalowaniu i

skonfigurowaniu usług FTP są one zawsze

uruchamiane podczas startu komputera. Aby zarządzać serwerem FTP,
należy zalogować się na komputer jako administrator.

Polecenia NET STOP i NET START służą zatrzymywania i uruchamiania
usług FTP. Jeśli chcemy wyłączyć usługi FTP, wówczas możemy użyć
następującego polecenia:

NET STOP FTPSVC

Polecenie to natychmiast odłącza wszystkich użytkowników od serwera
FTP. Jeśli chcemy sprawdzić, czy jacyś użytkownicy są podłączeni do
serwera, możemy kliknąć na ikonie FTP Server w Control Panel.

Zamiast natychmiastowego odłączania wszystkich użytkowników
poleceniem NET STOP, możemy czasowo zawiesić usługi FTP przy
pomocy następującego polecenia:

NET PAUSE FTPSVC

Zawieszenie usług FTP uniemożliwia zalogowanie się nowych
użytkowników na serwer, ale nie przerywa bieżących sesji. Nowi
użytkownicy, próbujący dostać się na serwer, otrzymają następujący
komunikat:

421-Service not available, closing control connection.

Po zakończeniu sesji przez zalogowanych użytkowników można
zatrzymać usługi FTP, nie zrywając żadnej sesji.

Do uruchamiania, zatrzymywania i zawieszania usług FTP można oprócz
programu Internet Service Manager użyć ikony Services w Control Panel.

Rozdział 4

126

Internet Service Manager umożliwia zarządzanie aktualnymi sesjami
FTP. Okienko dialogowe FTP User Sessions wyświetla następujące infor-
macje:

„

Nazwę podłączonego użytkownika

„

Adres IP podłączonego komputera

„

Czas połączenia

„

Hasło anonimowego użytkownika (zazwyczaj jego adres e-mail)

„

Przy ikonach anonimowych użytkowników pojawia się znak
zapytania (?), którego nie ma przy ikonach użytkowników
uwierzytelnionych przez Windows NT.

Przy pomocy okienka dialogowego FTP User Sessions można odłączyć
pojedynczego lub wszystkich użytkowników.

Zaawansowana konfiguracja serwera FTP

Opisana powyżej konfiguracja serwera FTP w większości przypadków
jest wystarczająca. Niniejszy podrozdział omawia dodatkowe parametry
konfiguracyjne serwera FTP, które zawarte są w programie Internet
Service Manager dla serwera FTP. Zaawansowane parametry FTP można
także zmieniać bezpośrednio edytując Rejestr.

Wszystkie parametry usług FTP omawiane w tym rozdziale można
znaleźć pod następującym kluczem Rejestru:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSFTPSRV\Paramet
ers

Na rysunku 4.6 przedstawiono standardowe wpisy znajdujące się pod
tym kluczem. Jeśli wpis nie istnieje, używana jest jego standardowa
wartość. Aby podać inną wartość, trzeba najpierw dodać wpis do
Rejestru. W rozdziale tym opiszemy poszczególne wpisy oraz typy ich
wartości.

Edycja Rejestru pozwala na zmianę wszystkich parametrów
konfiguracyjnych FTP. Dostęp do niektórych jest możliwy poprzez
okienko dialogowe Network Settings:

Konfigurowanie TCP/IP

127

Rysunek 4.6

Parametry FTP
w Rejestrze

„AllowAnonymous
„AllowNonAnonymous

„AnonymousUserName

„ConnectionTimeout

„HomeDirectory

„MaxConnections

Podane niżej wpisy można ustawić klikając ikonę FTP Server w Control
Panel

, a następnie klikając przycisk Security:

„ReadAccessMask

„WriteAccessMask

Definiowanie dołączanych opisów katalogów

Kiedy użytkownik zmieni katalog na serwerze FTP, można wyświetlić
dla niego plik tekstowy –FTPSVC-.CKM, zawierający opis katalogu.
Zazwyczaj dobrze jest oznaczyć ten plik jako ukryty, aby jego nazwa nie
pojawiała się w

listingu katalogu; w

tym celu można skorzystać

z programu File Manager albo użyć następującego polecenia:

ATTRIB +H -FTPSVC-.CKM

Wielu klientów FTP daje możliwość włączania i wyłączania opisów
katalogów poleceniem CKM:

Rozdział 4

128

QUOTE SITE CKM

Parametr AnnotatedDirectories definiuje, czy opisy katalogów będą
wyświetlane łączącym się z serwerem użytkownikom. Parametr jest typu
REG_DWORD

i może przybierać wartość 0 lub 1. Wartość 1 oznacza, że

opisujący katalog plik -FTPSVC-.CKM jest wyświetlany użytkownikom.
Standardową wartością jest 0, co wyłącza wyświetlanie opisów
katalogów.

Definiowanie komunikatów powitalnych i pożegnalnych

Kiedy użytkownik loguje się na serwer FTP, można wyświetlić dla niego
założenia dotyczące użytkowania serwera albo inne informacje.
Komunikat powitalny nie jest wysyłany, jeśli użytkownik loguje się
anonimowo wpisując znak minusa (-) przed nazwą użytkownika.

Komunikat powitalny jest przechowywany we wpisie GreetingMessage.
Wpis ten jest typu REG_SZ i może zawierać dowolne znaki tekstowe.
Standardowo wpis GreetingMessage jest pusty.

Kiedy użytkownik wylogowuje się z serwera, można przesłać mu
komunikat pożegnalny. Definiuje się go we wpisie ExitMessage. Wpis ten
jest typu REG_SZ i standardowo zawiera tekst "Goodbye".

Zapisywanie połączeń FTP do dziennika zdarzeń

Po odpowiednim ustawieniu wartości parametrów LogAnonymous
i LogNonAnonymous można zapisywać połączenia FTP w systemowym
dzienniku zdarzeń.

Parametr LogAnonymous jest typu REG_DWORD i może przybierać
wartości 0 lub 1. Wartość 1 oznacza, że anonimowe połączenia są
rejestrowane w dzienniku zdarzeń; wartość 0 oznacza wyłączenie
rejestrowania. Standardową wartością jest 0.

Parametr LogNonAnonymous jest podobny do LogAnonymous, z tym że
stosuje się do użytkowników nieanonimowych, jak np. posiadaczy kont
systemu Windows NT. Parametr LogNonAnonymous jest typu
REG_DWORD

i może przybierać wartości 0 lub 1. Wartość 1 oznacza, że

nieanonimowe połączenia są rejestrowane w dzienniku zdarzeń; wartość
0 oznacza wyłączenie rejestrowania. Standardową wartością jest 0.

Parametr LogFileAccess steruje zapisem do pliku dziennika
FTPSVC.LOG. FTPSVC.LOG znajduje się w

katalogu

\%KatalogSystemowy%\SYSTEM32

; rejestruje się w nim dostęp do plików.

Parametr LogFileAccess jest typu REG_DWORD i może przybierać warto-
ści 1 lub 0. Wartość 1 oznacza, że dostęp do plików jest rejestrowany
w dzienniku FTPSVC.LOG; wartość 0 oznacza wyłączenie rejestrowania.

Konfigurowanie TCP/IP

129

Standardową wartością jest 0. Poniżej przedstawiono przykładową za-
wartość pliku FTPSVC.LOG:

************** FTP SERVICE STARTING Fri July 10 11:05:00 am 1998
132.12.23.13 kss opened d:\FTP\sample.txt Fri July 10 11:10:03 am
1998
132.12.23.13 kss appended d:\FTP\sample.txt Fri July 10 11:22:12 am
1998
132.12.23.13 kss created d:\FTP\readme.txt Fri July 10 11:55:32 am
1998
************** FTP SERVICE STARTING Fri July 10 11:59:56 am 1998

W podanym wyżej przykładzie widać, że plik dziennika zawiera wpisy
określające adres IP połączonego komputera, nazwę użytkownika,
operację przeprowadzoną na pliku (stworzenie, usunięcie, otwarcie,
dopisanie), ścieżkę do pliku oraz datę i czas dostępu.

Konfigurowanie formatu wyświetlania zawartości katalogów

Następujące polecenie FTP przełącza pomiędzy wyświetlaniem
zawartości katalogów w formacie MS-DOS i UNIX:

QUOTE SITE DIRSTYLE

Format wyświetlania zawartości katalogów może mieć znaczenie
w niektórych aplikacjach, które zakładają istnienie specyficznego formatu
(większość z nich pochodzi z systemu UNIX).

Początkowy format wyświetlania zawartości katalogu jest zdefiniowany
przez wartość parametru MsdosDirOutput. Parametr ten jest typu
REG_DWORD

i może przybierać wartości 0 lub 1. Jeśli ustawiony jest na

1, wówczas zawartość katalogu wyświetlana jest tak, jak czyni to
polecenie dir w MS-DOS; w innym przypadku zawartość katalogu
wyświetlana jest tak, jak czyni to polecenie ls w UNIX. Standardową
wartością jest 1 (format MS-DOS). Przy wartości 1 w poleceniu FTP pwd
używane są znaki \, a przy wartości 0 znaki /.

Innym parametrem modyfikującym format wyświetlania zawartości
katalogów jest LowercaseFiles. Parametr ten jest typu REG_DWORD
i może przybierać wartości 0 lub 1. Jeśli ustawiony jest na 1, wówczas
nazwy plików zwracane przez polecenia list i nlst są odwzorowywane na
małe litery, co jest potrzebne w przypadku systemów plików nie
rozróżniających wielkości liter, jak np. FAT. Jeśli ustawiony jest na zero,
wówczas nie przeprowadza się takiego odwzorowania. Wartość
parametru nie ma wpływu na nazwy plików w HPFS i NTFS, ponieważ
te systemy plików rozróżniają wielkość liter.

Rozdział 4

130

Zmienianie komunikatu wyświetlanego przy osiągnięciu
maksymalnej liczby klientów

Jeśli osiągnięty został zdefiniowany limit sesji FTP na serwerze, wówczas
nowi użytkownicy otrzymują następujący komunikat:

Maximum clients reached, service unavailable.

Można zmienić ten domyślny tekst edytując parametr MaxClientsMessage.
Jest on typu REG_SZ i może zawierać dowolne znaki tekstowe.

Konfigurowanie TCP/IP w celu umożliwienia drukowania
z Windows NT na drukarkach UNIX

Kolejnym aspektem konfiguracji TCP/IP jest umożliwienie drukowania
z Windows NT na sieciowych drukarkach UNIX. Zlecenia wydruku
przesyła się przy pomocy protokołu TCP/IP. Sposób drukowania
z Windows NT na drukarkach UNIX jest zgodny z zaleceniami zawarty-
mi w dokumencie RFC 1179.

Aby możliwe było drukowanie na komputerze UNIX, jeden
z komputerów Windows NT w sieci (stacja robocza lub serwer) musi
mieć zainstalowany protokół TCP/IP oraz Microsoft TCP/IP Printing
Service. Może on wówczas pracować jako bramka wydruku dla innych
klientów Microsoft (patrz rysunek 4.7). Pozostali klienci Microsoft nie
muszą obsługiwać protokołu TCP/IP, aby móc używać bramki wydruku.
Rysunek 4.7 przedstawia komputer o

nazwie NTKS, w

którym

zainstalowano obsługę wydruku poprzez TCP/IP i zdefiniowano dwie
dzielone drukarki: \\NTKS\Unix_PR1 oraz \\NTKS\Unix_PR2. Pierwsza
z nich oznacza drukarkę UNIX podłączoną bezpośrednio do sieci,
a druga drukarkę podłączoną do komputera UNIX. Pozostali klienci
Microsoft mogą używać dzielonych drukarek tak, jakby posiadały
sterowniki wydruku firmy Microsoft. Zlecenie wydruku wysyłane do
dzielonych drukarek o nazwach \\NTKS\Unix_PR1 oraz \\NTKS\Unix_PR2
jest przekierunkowywane przez NTKS do odpowiedniej drukarki UNIX.

Instalowanie i konfigurowanie drukowania poprzez TCP/IP

Poniżej podano procedurę instalowania i konfigurowania drukowania
poprzez TCP/IP:

1. Zalogować się jako administrator na komputer Windows NT (Server

lub Workstation)

Konfigurowanie TCP/IP

131

2. Kliknąć podwójnie na ikonie Network w Control Panel, aby wyświetlić

okienko dialogowe Network.

3. W okienku dialogowym Network wybrać zakładkę Services.

4. Kliknąć przycisk Add. Podświetlić Microsoft TCP/IP Printing na liście

Select Network Service

i kliknąć przycisk OK.

5. Wprowadzić ścieżkę do plików instalacyjnych systemu operacyjnego

i kliknąć Next. Ukaże się okienko obrazujące postępy w kopiowaniu
plików na komputer Windows NT.

6. Po zakończeniu kopiowania ponownie pojawi się okienko Network

Services

. Kliknąć przycisk Close.

7. W okienko dialogowym Network Settings Change pojawi się pytanie,

czy ponownie uruchomić komputer, aby zostały uwzględnione nowe
ustawienia. Wybrać Yes.

Rysunek 4.7

Drukowanie
poprzez
TCP/IP
z Windows
NT.

Po ponownym uruchomieniu komputera należy utworzyć drukarkę
TCP/IP, aby klienci Microsoft mogli używać jej jako bramki do
komputerów UNIX. Poniżej podano sposób jej tworzenia.

8. Kliknąć podwójnie na ikonie Printers w Control panel i kliknąć przycisk

Add Printer

. Pojawi się okno Add Printer Wizard (patrz rysunek 4.8).

Aby zainstalować drukarkę TCP/IP, należy wybrać drukarkę
lokalną, po czym dodać port LPR określający komputer UNIX
i kolejkę wydruku.

9. Wybrać drukarkę spośród oferowanych przez Windows NT Internet

Printing (patrz rysunek 4.9). Na serwerach tych zazwyczaj pracuje
proces lpd (line printer daemon).

Rozdział 4

132

10. Postępować według wskazówek na ekranie, aby zdefiniować nową

drukarkę. Należy tu podać producenta drukarki i jej właściwości.

11. Po zakończeniu konfiguracji drukarki w okienku Printers pojawi się

nowa ikona.

Drukowanie z komputera UNIX na komputerze Windows NT

Poprzedni podrozdział opisywał procedurę konfiguracji drukowania na
drukarkach UNIX przez klientów Microsoft. W mieszanej sieci, składają-
cej się z komputerów UNIX i klientów Microsoft, może zaistnieć potrzeba
drukowania z komputerów UNIX na drukarkach Windows NT.

Rysunek 4.8

Okno Add Printer Wizard.

Rysunek 4.9

Okno Add Printer.

Aby można było drukować z klienta UNIX na komputerze Windows NT,
w Windows NT muszą być zainstalowane usługi drukowania TCP/IP.
Klienci UNIX podczas drukowania spodziewają się, że ich dane zostaną
odebrane przez proces lpd. Należy więc uruchomić w Windows usługę
Lpdsvc

, która emuluje ten proces. Rysunek 4.10 przedstawia sposób dru-

kowania przez klientów UNIX na komputerze Windows NT.

Usługę Lpdsvc można uruchomić, wstrzymać, przywrócić lub zatrzymać
przy użyciu następujących poleceń:

„NET START LPDSVC

„NET PAUSE LPDSVC

„NET CONTINUE LPDSVC

„NET STOP LPDSVC

Konfigurowanie TCP/IP

133

Rysunek 4.10

Drukowanie poprzez
TCP/IP
z komputerów UNIX
na serwerach wydru-
ku Windows NT

Można w

tym celu skorzystać również z

programu Microsoft

Management Console (MMC). Aby uruchomić MMC, należy wybrać
Start/ Programs/Administrative Tools/System Service Management

. Lpdsvc

w MMC jest nazywany TCP/IP Print Server (patrz rysunek 4.11).
Standardowo usługę tę włącza się ręcznie, poprzez kliknięcie na jej
nazwie prawym klawiszem myszy i wybranie opcji Startup. W taki sam
sposób wybiera się opcję Properties, gdzie można ustawić automatyczne
uruchamianie usługi podczas startu systemu.

Aby wysłać zlecenie wydruku do komputera Windows NT z komputera
UNIX, należy użyć odpowiedniego polecenia - zazwyczaj jest to lpr.
Dokumentacja UNIX zawiera szczegóły dotyczące tego polecenia. Ogólna
składnia polecenia lpr jest następująca:

lpr –s KomputerNT –P DrukarkaNT nazwa_pliku

KomputerNT

jest nazwą DNS komputera Windows NT, na którym pracuje

usługa lpdsvc, DrukarkaNT jest nazwą drukarki Windows NT
zainstalowanej na KomputerzeNT, a nazwa_pliku jest nazwą pliku UNIX,
który należy wydrukować.

Rozdział 4

134

Rysunek 4.11

Serwer wydruku
TCP/IP w okienku
dialogowym System
Services.