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-odpowiedz; 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ć:
serwera. Zazwyczaj odnosi się do usługi działającej aplikacji
Usługa
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
stacji roboczej. Umożliwia stacji roboczej pracowanie jako
Usługa
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.
użytkownika (Username) [0x03]. Jest to nazwa użytkownika
Nazwa
zarejestrowana przez doręczyciela dla zalogowanego użytkownika.
komputera (Computername) [0x20]. Jest to usługa serwera
Nazwa
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
określania nazw w Windows WINS (Windows Internet Name
Usługa
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 odpowiedz
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 zró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 znalezć 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 znalezć 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:
# #INCLUDE
# #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:" tag will associate
the
# entry with the domain specified by . 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 is always preloaded although it
will not
# be shown when the name cache is viewed.
#
# Specifying #INCLUDE " will force the RFC NetBIOS (NBT)
# software to seek the specified and parse it as if it
were
# local. 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 Plik o podanej nazwie zostanie przetworzony jako plik
nazwa_pliku 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 Używane do zaznaczenia początku bloku poleceń #INCLUDE.
E 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 znalezć 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 zródło pliku LMHOSTS
#INCLUDE \\NTBC1\ETC\LMHOSTS # Zapasowe zródło 1
#INCLUDE \\NTBC2\ETC\LMHOSTS # Zapasowe zró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.
zamierzamy przeglądać inną domenę, musimy upewnić się, że
Jeśli
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).
domeny pozostajÄ… w zwiÄ…zku wzajemnego zaufania (trust
Jeśli
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:
pliku HOSTS nie można używać żadnych specjalnych dyrektyw,
W
jak #PRE, #DOM itp.
zdefiniować kilka zamienników nazw dla danego adresu IP,
Można
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:
#
# [aliases...] [#]
#
# 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:
#
# [aliases...]
[#]
#
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:
#
# / [aliases...]
[#]
#
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
Rrlogin
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
Rpassing
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ózniej. 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)
ikonach anonimowych użytkowników pojawia się znak
Przy
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
znalezć 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 Rysunek 4.9
Okno Add Printer Wizard. 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.
Wyszukiwarka
Podobne podstrony:
Rozdział 04 System obsługi przerwań sprzętowych
04 Rozdział III Od wojennego chaosu do papieża matematyka
04 rozdział 03 wtcjpb3t4i6ahedwpeqbi526b4gndq3qkbqtbaq
04 Rozdzial 2
06 Rozdział 04 Twierdzenie o funkcji uwikłanej i jego konsekwencje
Mari Mancusi Bractwo Krwi 04 Zła Krew Rozdziały 1 2
04 Rozdzial 2
04 ROZDZIA 4 Zegarek, a co to takiego , czyli poznawanie i oswajanie si z tym, co nieuniknione
kopczewska (pliki z kodami) Rozdział 04 Statystyki globalne i lokalne
Feehan Christine Mroczna Magia 04 rozdział 14
więcej podobnych podstron