r23 05 (2)


Rozdział 23.
Rozwiązywanie problemów z siecią i łącznością

W tym rozdziale:

W świecie idealnym wszystko działa przez cały czas. Żyjemy jednak w świecie rzeczywistym, w którym urządzenia się psują, a błędy ludzkie są przyczyną wypadków. W obliczu tych niedoskonałości naszym jedynym wyjściem jest lokalizacja źródła problemów i znalezienie środków zaradczych.

Mówiąc prosto, rozwiązywanie problemów (troubleshooting) to proces ustalania, dlaczego określona procedura lub produkt nie działa. Istnieją dwie metody rozwiązywania problemów: pierwsza polega na znalezieniu problemu z nowym produktem lub procesem, którego nie możemy uruchomić; druga na ustaleniu, dlaczego coś, co działało, przestało działać. Typ wykonywanej pracy — instalatora, administratora sieci lub programisty — decyduje o metodach rozwiązywania problemów. W większości przypadków, aby zmusić coś do działania po raz pierwszy, wystarczy przeczytać podręcznik. Może zaskakiwać fakt, iż tylko około 4 procent ludzi pracujących w dziedzinach technicznych czyta podręcznik, zanim spróbuje zainstalować nowy produkt.

Ogólnie mówiąc, pomyślne rozwiązanie problemu wymaga dokładnego zrozumienia systemu, w którym rozwiązujemy problemy; nieważne, czy jest to tak prosty system jak np. brak połączenia w komputerze, czy skomplikowany — na przykład nowa siedmiopoziomowa aplikacja, która zawodzi w określonej funkcji. Jeśli wiemy, jakie kroki aplikacja wykonuje i jak są one powiązane ze sobą, znalezienie problemu polega po prostu na prześledzeniu po kolei tych kroków oraz identyfikacji (zwykle przez obserwację), gdzie procedura ulega przerwaniu.

W przypadku TCP/IP proces rozwiązywania problemów jest taki sam. TCP/IP jest systemem składników programowych i sprzętowych, a każdy z nich musi funkcjonować poprawnie, aby cały proces zadziałał. Na początek zajmiemy się podstawowym procesem rozwiązywania problemów.

Proces rozwiązywania problemów

Połączenie dwóch komputerów może wydawać się prostą sprawą, lecz to tylko pozory — łączność wymaga bezawaryjnego działania wielu elementów, a także wykonania przez administratora szeregu konkretnych operacji. Na przykład, jeśli próbujemy połączyć się z witryną WWW innej firmy, nasz komputer musi posiadać adres IP, co oznacza, iż nasz serwer DHCP musi działać poprawnie. Aby pakiety DHCP dostały się do naszego komputera, rutery muszą je przekazywać, agent przekazujący DHCP musi działać lub komputer musi być podłączony do tej samej podsieci co serwer DHCP. Dysponując już adresem, musimy dostać się z lokalnej podsieci do bramy zewnętrznej, co oznacza, iż nasz lokalny ruter i wszystkie rutery po drodze muszą działać, oraz iż protokół wyboru tras używany w naszej sieci musi funkcjonować. Dochodząc do bramy zewnętrznej, możemy przechodzić przez serwer proxy, który musi działać, oraz być może przez zaporę firewall. Zapora może być powiązana z systemami uwierzytelniającymi, które również muszą działać.

Gdy żądanie opuści już naszą sieć przez zaporę, jesteśmy na łasce i niełasce Internetu. Ta część podróży obejmuje ruter, który łączy naszą firmę z ISP, sieć wewnętrzną ISP oraz wewnętrzną sieć i rutery docelowego ISP, które wszystkie muszą działać. Łącze pomiędzy dostawcami usług internetowych istnieje dzięki temu, iż dostawca usług lub operator telefonii na wyższym poziomie posiada oprócz ruterów i wewnętrznych sieci działające linie lub satelity. Wymaga to również funkcjonujących protokołów wyboru tras we wszystkich trzech systemach, zapewniających znalezienie ruterów od punktu A do punktu B. W sieci mieszczącej serwer WWW, z którym chcemy się połączyć muszą działać: zapora, wewnętrzne trasowanie, koncentrator lub przełącznik, zdalny komputer serwera WWW oraz oprogramowanie serwera WWW. Ponieważ wiele witryn obecnie jest sterowanych danymi, serwer bazy danych na odległym końcu również musi działać.

Idąc trochę dalej w scenariuszu z dwóch poprzednich akapitów, wszystkie systemy muszą komunikować się na podstawowym poziomie, co oznacza, iż wszystkie warstwy stosu TCP/IP każdego systemu muszą funkcjonować poprawnie. Warstwa aplikacji musi bezpośrednio „rozmawiać” z portami, które powinny być w stanie przesłać dane do TCP lub UDP bez zniekształceń. Protokoły te wykorzystują IP, który polega na ARP i musi współpracować z ICMP i IGMP. I, oczywiście, karty sieciowe muszą być sprawne.

Ostatnie trzy akapity zawierają przegląd procesów, które zachodzą za każdym razem, gdy odwiedzamy stronę WWW. Jak widać, komunikacja przez TCP/IP nie jest ani prosta, ani wyjątkowo wydajna, aczkolwiek wydaje się działać całkiem nieźle. „Tysiącmilowa podróż zaczyna się od pierwszego kroku”, tak też odbywa się proces rozwiązywania problemów. W naszym przypadku pierwszym krokiem jest system lokalny. Zaczniemy od niego.

Sprawdzenie konfiguracji IP

Jednym z najbardziej oczywistych miejsc, od których można zacząć rozwiązywanie problemu, jest konfiguracja TCP/IP. Obejmuje ona adres IP i maskę podsieci, określające tożsamość systemu. Konfiguracja zawiera również adres bramy, potrzebny do przekazywania pakietów do innych sieci, wskaźniki do serwerów DNS i WINS, niezbędnych do rozwiązywania nazw, oraz adresy portów, potrzebne przy łączeniu się z systemem zdalnym. Proszę pamiętać, iż działający system zwykle działa dopóty, dopóki nie „zadziała” na niego użytkownik; zaś użytkownicy czasem zmieniają konfigurację.

Kontrola konfiguracji IP dla Microsoft Windows

Sposób sprawdzania konfiguracji IP zależy od określonego systemu operacyjnego (Microsoftu lub Unix i jego pochodne), którego używamy. Ponieważ więcej komputerów biurkowych zawiera systemy operacyjne Microsoftu, zaczniemy od nich.

Narzędzie ipconfig

Systemy Windows 95 i Windows 98 zawierają narzędzie graficzne o nazwie WINIPCFG, które pozwala skontrolować konfigurację IP. Narzędzie to można uruchomić z menu Start poleceniem Uruchom. W zestawie narzędzi dla Windows 95 i 98 znajdziemy również kopię ipconfig — narzędzia uruchamianego z wiersza poleceń, które daje takie same informacje, jak WINOPCFG. Ponieważ narzędzie ipconfig jest dostępne na wszystkich platformach Windows, przyjrzymy mu się bardziej szczegółowo.

Program ipconfig pozwala przejrzeć konfigurację systemu. Wyjście tego programu wygląda następująco:

Windows 98 - konfiguracja IP

0 Ethernet karta :

Adres IP. . . . . . . . . . : 192.168.0.1

Maska podsieci . . . . . . . : 255.255.255.0

Domyślna brama . . . . . . :

1 Ethernet karta :

Adres IP. . . . . . . . . . : 48.53.66.7

Maska podsieci . . . . . . . : 255.255.192.0

Domyślna brama . . . . . . : 48.53.66.1

Za jego pomocą możemy szybko sprawdzić adres IP, maskę podsieci i bramę domyślną. W powyższym przykładzie adres IP i maska podsieci są poprawne, zaś domyślna brama jest dla systemu zdefiniowana.

W nowszych wersjach Windows jest kilka określonych adresów, na które należy zwracać uwagę. W pierwszej kolejności spójrzmy na dowolny system z adresem z zakresu 169.145.x.x. Ten zakres jest używany do automatycznej konfiguracji IP klientów DHCP. Gdy klient próbuje bez powodzenia otrzymać adres IP od serwera DHCP, wówczas systemy Windows 2000 i Windows Me przydzielają adres z tego zakresu. Mogłoby to oczywiście prowadzić do powielania adresów IP, więc Microsoft wprowadził kontrolę adresu przed przydzieleniem przez pingowanie, aby uniknąć podwójnych adresów IP. Gdy system przechodzi na automatyczne adresowanie IP, nie informuje o tym użytkownika. Zazwyczaj użytkownik dowiaduje się o problemie, gdy nie może się zalogować, a kończy się to telefonem do pomocy technicznej.

Powinniśmy też zwracać uwagę na adres 192.168.0.1. Jedną z nowych możliwości Windows 2000 jest udostępnianie połączenia, które pozwala na posiadanie jednego połączenia poprzez dostawcę usług (na przykład z Internetem) oraz drugiego z siecią lokalną; w ten sposób przez kliknięcie przycisku nasz komputer staje się prostym ruterem pomiędzy łączem do dostawcy usług i wewnętrzną siecią 192.168.0.0. Użytkownik eksperymentujący w systemie może zignorować pojawiające się duże ostrzeżenie i spróbować udostępniania połączeń. I nagle jedna z kart sieciowych otrzymuje niewłaściwy adres, a system przestaje się komunikować.

Zarówno automatyczne adresowanie IP, jak i udostępnianie połączeń to część planu Microsoftu, by ułatwić tworzenie i konfigurację sieci użytkownikom domowym i małym biurom przy minimum wiedzy technicznej. Wyłącznik tych funkcji jest jednakże trudny do znalezienia i trudno nim operować.

Rozwiązywanie problemów z DHCP za pomocą ipconfig

Microsoft promuje protokół DHCP od wielu lat. Jednakże DHCP nie jest nieomylny i kilka problemów, które stwarza możemy naprawić z pomocą polecenia ipconfig.

Automatyczne adresowanie IP, omówione przed chwilą, jest przyczyną podstawowego problemu — host albo otrzymał niewłaściwe informacje, albo nie otrzymał żadnych. Aby sprawdzić status DHCP w adapterze, możemy użyć polecenia ipconfig /all, którego wynik przedstawiliśmy poniżej.

Konfiguracja IP systemu Windows NT

Nazwa hosta . . . . . . . . . : hydra.scrimtech.com

Serwery DNS . . . . . . . . . : 207.236.145.41

207.236.145.40

Typ węzła . . . . . . . . . . : Hybryda

ID zakresu NetBIOS. . . . . . :

Routing IP włączony . . . . . : Tak

WINS Proxy włączone . . . . . : Nie

NetBIOS Resolution używa DNS. : Tak

Karta Ethernet 0

Opis. . . . . . . . . . . . . : NDIS 5.0 driver

Adres fizyczny. . . . . . . . : 00-E0-18-C4-1A-56

DHCP włączone . . . . . . . . : Nie

Adres IP. . . . . . . . . . . : 192.168.0.1

Maska podsieci. . . . . . . . : 255.255.255.0

Domyślna brama. . . . . . . . :

Podstawowy serwer WINS. . . . :

Zapasowy serwer WINS. . . . . :

Dzierżawa otrzymana . . . . . :

Dzierżawa wygasa. . . . . . . :

Karta Ethernet 1:

Opis. . . . . . . . . . . . . : Realtek RTL8029 (AS)

Adres fizyczny. . . . . . . . : 00-40-05-5B-C6-A5

DHCP włączone . . . . . . . . : Nie

Adres IP. . . . . . . . . . . : 24.112.82.45

Maska podsieci. . . . . . . . : 255.255.252.0

Domyślna brama. . . . . . . . : 24.112.92.1

Podstawowy serwer WINS. . . . :

Zapasowy serwer WINS. . . . . :

Dzierżawa otrzymana . . . . . :

Dzierżawa wygasa. . . . . . . :

W tym przypadku musimy sprawdzić wpis DHCP włączone i upewnić się, czy jest poprawny. Jeśli host ma mieć DHCP włączone, a nie ma, przypuszczalnie konfiguracja IP jest błędna. Nawet jeśli klient jest poprawnie skonfigurowany, system może nie funkcjonować właściwie, więc być może trzeba będzie usunąć istniejące informacje i spróbować ponownie.

Możemy wydać polecenie ipconfig /release, aby wyczyścić informacje, a następnie ponowić próbę uzyskania przez system nowego adresu poleceniem ipconfig /renew. Jeśli czynności te zostaną zakończone pomyślnie, komputer będzie gotów do komunikacji. Jeśli nie, należy ręcznie sprawdzić konfigurację IP, ponieważ wszelkie wartości skonfigurowane lokalnie będą blokować wartości z serwera DHCP. Jeżeli nie jesteśmy w stanie uzyskać adresu DHCP przy próbie odnowienia, problem nie leży w konfiguracji, lecz w podstawowej łączności.

Kontrola konfiguracji IP w systemach uniksowych

Podobnie jak środowisko Windows, środowisko uniksowe zawiera interfejsy graficzne. Niektóre z tych narzędzi pozwalają sprawdzić konfigurację IP, a niektóre nie. Niniejszy punkt zajmuje się poleceniem ifconfig, które jest podobne do ipconfig, lecz ma większe możliwości.

Podstawowe polecenie ifconfig zwraca większość potrzebnych danych konfiguracyjnych. Na przykład:

[root@www3 /etc]# ifconfig

eth0 Link encap:Ethernet HWaddr 00:90:27:DC:89:5D

inet addr: 48.53.66.9 Bcast:24.255.255.255 Mask:255.255.192.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:1185636154 errors:38 dropped:0 overruns:0 frame:0

TX packets:1379083270 errors:7 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:100

Interrupt:19 Base address:0xb000

Ponownie chcemy sprawdzić podstawowy adres IP i maskę podsieci. Chcemy też upewnić się, czy interfejs jest załączony (UP). Jak widać, w tym miejscu nie można sprawdzić bramy domyślnej. Musimy użyć polecenia route:

[root@www3 /etc]# route

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

48.53.64.0 * 255.255.192.0 U 0 0 0 eth0

127.0.0.0 * 255.0.0.0 U 0 0 0 lo

default 48.53.64.1 0.0.0.0 UG 0 0 0 eth0

Musimy znaleźć wpis dla trasy domyślnej (proszę zwrócić uwagę na literę G w kolumnie Flags, która wskazuje na bramę — Gateway). W tym przypadku domyślny wpis znajduje się w ostatnim wierszu i wskazuje na właściwy adres. W niektórych wersjach i pochodnych trasa domyślna może być pokazana jako 0.0.0.0 z maską podsieci 0.0.0.0 lub będziemy musieli wydać polecenie route print zamiast route. Jeśli powyższe wartości nie będą poprawne, trzeba będzie je skorygować.

Zakładając, iż konfiguracja jest w porządku, przechodzimy do następnego kroku — sprawdzenia łączności. Należy zacząć od upewnienia się, czy kabel sieciowy jest podłączony zarówno do gniazda w ścianie, jak i do komputera.

Testowanie łączności

Sprawdzając łączność próbujemy po prostu ustalić, czy komputer jest w stanie nadawać w sieci. Najpierw upewnijmy się, czy świecą się diody LED na karcie sieciowej (większość kart sieciowych posiada wbudowane diody świecące). Należy również sprawdzić, czy sygnalizator kolizji nie świeci się w sposób ciągły. Jeśli tak, możemy mieć poważniejsze problemy, na przykład z nasyceniem sieci.

Podzielmy na kilka punktów funkcje wymagane od systemu lokalnego, aby mógł z powodzeniem komunikować się z innymi hostami:

Najlepszym i najszybszym sposobem przetestowania większości z powyższych funkcji jest polecenie ping. Ping jest prostym narzędziem, wysyłającym pakiet z jednego systemu do drugiego i czekającym na odpowiedź. W większości przypadków sprawdzamy łączność poleceniem ping, zanim nawet skontrolujemy adres IP. Tabela 23.1 wymienia miejsca docelowe, które możemy skontrolować tym poleceniem. Każde z nich wyklucza inny problem (zakładamy, ze lokalny system posiada adres 48.53.66.7 z maską podsieci 255.255.192.0).

Tabela 23.1. Wykorzystanie polecenia ping do testowania TCP/IP

Adres docelowy

Co zostaje sprawdzone:

ping 127.0.0.1 (adres pętli zwrotnej)

Czy warstwa gniazd działa i może komunikować się z warstwą transportową. Sprawdza, czy TCP i UDP mogą komunikować się z warstwą IP i czy warstwa IP jest w stanie odczytać tablicę tras.

ping 48.53.66.7 (adres systemu lokalnego)

Czy warstwa IP jest w stanie odczytać tablicę tras, oraz czy warstwa interfejsu sieciowego prawidłowo zarejestrowała lokalny adres IP w warstwie IP.

ping 48.53.66.9 9 (adres sąsiedniego systemu w tej samej podsieci)

Czy ARP jest w stanie rozwiązać adresy, i czy warstwa IP może wysyłać i odbierać dane przez warstwy interfejsu sieciowego i fizyczną. Upewnia się dodatkowo, czy adres IP jest poprawny dla danej podsieci.

ping 48.53.120.1 (adres dalszego systemu
w tej samej podsieci)

Czy maska podsieci nie jest zbyt restrykcyjna, co powoduje rozpoznawanie przez IP hostów lokalnych jako zdalnych.

ping 48.53.180.22 (adres systemu zdalnego)

Czy maska podsieci nie jest zbyt ogólna, co powoduje rozpoznawanie przez IP hostów zdalnych jako lokalnych. Dodatkowo sprawdza, czy tablica tras jest w użyciu i czy jesteśmy w stanie połączyć się z lokalną bramą, a przy okazji —czy adres bramy jest poprawny.

Większość możliwych problemów, wymienionych wcześniej, można z łatwością spraw­dzić za pomocą polecenia ping. Wyjątkiem jest to, czy usługi używają właściwych por­tów. Możemy skontrolować to dość łatwo, sprawdzając plik usług (w katalogu Windows dla Windows 9x i Me, w katalogu Winnt\system32\drivers\etc dla NT i 2000, lub w katalogu /etc dla większości implementacji Uniksa).

Jeśli mamy problem z określoną usługą, z którą użytkownicy chcą się połączyć, warto sprawdzić plik usług (oprócz innych podstawowych faktów, np. czy usługa jest uruchomiona). Poniższy listing przedstawia początek pliku usług.

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 timserver

time 37/udp timserver

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

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

Format pliku usług jest bardzo prosty — w każdym wierszu po kolei protokół, port i protokół transportowy, a w niektórych przypadkach alias i ewentualny komentarz (po znaku # — na przykład „# ISO Mail”). Pierwsze 1024 porty są pod kontrolą IANA (Internet Assigned Numbers Authority) i są wspólne dla wszystkich platform. Po pierwszych 1024 portach następne numery są określone dla aplikacji, którą chcemy zmusić do pracy.

Powinniśmy również zdawać sobie sprawę, iż porty powyżej numeru 1023 mogą być używane przez klienty łączące się z serwerem. Oprogramowanie klienta zwykle zajmuje dynamiczny port powyżej 1023. Możemy sprawdzić aktywne połączenia poleceniem netstat. Wynik będzie wyglądać mniej więcej tak:

Aktywne połączenia

Protokół Adres lokalny Obcy adres Stan

TCP MEDUSA:1034 cyclops:ms-sql-s ESTABLISHED

TCP MEDUSA:ftp nic-31-c26-199.mm.mediaone.net:3361 CLOSE_WAIT

TCP MEDUSA:ftp as2-5-7.dro.hs.bonet.se:1414 CLOSE_WAIT

TCP MEDUSA:ftp pD953868C.dip.t-dialin.net:3704 CLOSE_WAIT

TCP MEDUSA:3389 cr32507-b.rchrd1.on.wave.home.com:2766 ESTABLISHED

TCP MEDUSA:ftp h24-70-96-200.cg.shawcable.net:61186 ESTABLISHED

TCP MEDUSA:http proxy1-external.hnsn1.on.home.com:3105 ESTABLISHED

TCP MEDUSA:http proxy1-external.hnsn1.on.home.com:11891 ESTABLISHED

TCP MEDUSA:http 1Cust247.tnt4.krk1.da.uu.net:1789 ESTABLISHED

TCP MEDUSA:http 1Cust247.tnt4.krk1.da.uu.net:1790 ESTABLISHED

TCP MEDUSA:http 1Cust247.tnt4.krk1.da.uu.net:1791 ESTABLISHED

TCP MEDUSA:http 1Cust247.tnt4.krk1.da.uu.net:1792 ESTABLISHED

TCP MEDUSA:http frasier.ford.com:25643 ESTABLISHED

TCP MEDUSA:http frasier.ford.com:26175 ESTABLISHED

TCP MEDUSA:http 161.184.2.194:2284 ESTABLISHED

TCP MEDUSA:http 161.184.2.194:2285 ESTABLISHED

TCP MEDUSA:http 206.191.84.251:1843 ESTABLISHED

TCP MEDUSA:http 206.191.84.251:2295 ESTABLISHED

TCP MEDUSA:http ppp-207-193-12-179.hstntx.swbell.net:1843 ESTABLISHED

Możemy sprawdzić porty otwarte w systemie za pomocą polecenia netstat -a, które służy do wyświetlenia wszystkich portów, łącznie ze słuchającymi. Wynik będzie zbliżony do poniższego:

Aktywne połączenia

Protokół Adres lokalny Obcy adres Stan

TCP MEDUSA:ftp MEDUSA:0 LISTENING

TCP MEDUSA:smtp MEDUSA:0 LISTENING

TCP MEDUSA:domain MEDUSA:0 LISTENING

TCP MEDUSA:http MEDUSA:0 LISTENING

TCP MEDUSA:epmap MEDUSA:0 LISTENING

TCP MEDUSA:https MEDUSA:0 LISTENING

TCP MEDUSA:microsoft-ds MEDUSA:0 LISTENING

TCP MEDUSA:1025 MEDUSA:0 LISTENING

TCP MEDUSA:1026 MEDUSA:0 LISTENING

TCP MEDUSA:1029 MEDUSA:0 LISTENING

TCP MEDUSA:1030 MEDUSA:0 LISTENING

TCP MEDUSA:1032 MEDUSA:0 LISTENING

TCP MEDUSA:1033 MEDUSA:0 LISTENING

TCP MEDUSA:1034 MEDUSA:0 LISTENING

TCP MEDUSA:3372 MEDUSA:0 LISTENING

TCP MEDUSA:3389 MEDUSA:0 LISTENING

TCP MEDUSA:1034 cyclops:ms-sql-s ESTABLISHED

TCP MEDUSA:ftp nic-31-c26-199.mm.mediaone.net:3361 CLOSE_WAIT

TCP MEDUSA:ftp as2-5-7.dro.hs.bonet.se:1414 CLOSE_WAIT

TCP MEDUSA:ftp pD953868C.dip.t-dialin.net:3704 CLOSE_WAIT

TCP MEDUSA:netbios-ssn MEDUSA:0 LISTENING

TCP MEDUSA:3389 cr32507-b.rchrd1.on.wave.home.com:2766 ESTABLISHED

TCP MEDUSA:ftp h24-70-96-200.cg.shawcable.net:61186 ESTABLISHED

TCP MEDUSA:http 1Cust247.tnt4.krk1.da.uu.net:1789 ESTABLISHED

TCP MEDUSA:http 1Cust247.tnt4.krk1.da.uu.net:1790 ESTABLISHED

TCP MEDUSA:http 1Cust247.tnt4.krk1.da.uu.net:1791 ESTABLISHED

TCP MEDUSA:http 1Cust247.tnt4.krk1.da.uu.net:1792 ESTABLISHED

TCP MEDUSA:http frasier.ford.com:25643 ESTABLISHED

TCP MEDUSA:http frasier.ford.com:26175 ESTABLISHED

TCP MEDUSA:http aigb35sqy1ue.ab.hsia.telus.net:2041 ESTABLISHED

TCP MEDUSA:http aigb35sqy1ue.ab.hsia.telus.net:2043 ESTABLISHED

TCP MEDUSA:http aigb35sqy1ue.ab.hsia.telus.net:2047 ESTABLISHED

TCP MEDUSA:http aigb35sqy1ue.ab.hsia.telus.net:2048 ESTABLISHED

TCP MEDUSA:http aigb35sqy1ue.ab.hsia.telus.net:2049 ESTABLISHED

TCP MEDUSA:http aigb35sqy1ue.ab.hsia.telus.net:knetd ESTABLISHED

TCP MEDUSA:http 161.184.2.194:2284 ESTABLISHED

TCP MEDUSA:http 161.184.2.194:2285 ESTABLISHED

TCP MEDUSA:http ppp-207-193-12-179.hstntx.swbell.net:1843 ESTABLISHED

UDP MEDUSA:epmap *.*

UDP MEDUSA:microsoft-ds *.*

UDP MEDUSA:1028 *.*

UDP MEDUSA:1031 *.*

UDP MEDUSA:3456 *.*

UDP MEDUSA:domain *.*

UDP MEDUSA:1027 *.*

UDP MEDUSA:domain *.*

UDP MEDUSA:netbios-ns *.*

UDP MEDUSA:netbios-dgm *.*

UDP MEDUSA:domain *.*

UDP MEDUSA:netbios-ns *.*

UDP MEDUSA:netbios-dgm *.*

UDP MEDUSA:domain *.*

UDP MEDUSA:domain *.*

UDP MEDUSA:domain *.*

UDP MEDUSA:domain *.*

Jeśli znaleźliśmy problem za pomocą polecenia ping, następnym krokiem jest ustalenie, co naprawdę jest nie w porządku. Najpierw zweryfikujmy konfigurację hosta, przy którym pracujemy i informacje otrzymywane od DHCP (jeśli host używa tej usługi). Jeśli konfiguracja systemu lokalnego jest prawidłowa, musimy przejść do innych możliwych rozwiązań.

Pierwszym posunięciem podczas rozwiązywania problemów z systemem, który używa interfejsu graficznego, na przykład Windows, jest restart komputera. Graficzne systemy operacyjne zwykle wiążą podstawowe poziomy funkcjonalności systemu ze środowiskiem graficznym. Mają one złą sławę z uwagi na problemy z pamięcią; czasami marnie napisana aplikacja, uruchomiona w jednym z takich systemów operacyjnych, wpłynie na pamięć używaną przez system do konfiguracji lub na inny ważny fragment kodu. W dużym stopniu problemy takie zostały naprawione w Windows NT, który jest wyjątkiem od powyższej reguły.

Zakładając, iż lokalny komputer jest w porządku, musimy przetestować połączenie ze zdalnym hostem. Możemy użyć narzędzia traceroute do sprawdzenia trasy, którą pakiety podążają z lokalnego systemu przez rutery do hosta docelowego. Polecenie traceroute używa tego samego polecenia Echo Request protokołu ICMP, jak ping, lecz zaczyna od pakietu o czasie życia (TTL) równym 1. Zmusza to pakiet do przekroczenia limitu czasu już w pierwszym ruterze, który zwróci do systemu komunikat ICMP o tym zdarzeniu. Wysyłając pakiet po pakiecie i zwiększając dla każdego TTL o 1, traceroute (tracert w systemie Windows) buduje listę ruterów, przez które pakiety przechodzą. traceroute w miarę postępów badania wyświetla trasę. Wynik tego polecenia wygląda mniej więcej tak:

Trasa śledzenia do hungryminds.com [168.215.86.100]
*przewyższa maksymalną liczbę przeskoków 30

1 <10 ms 10 ms <10 ms 207.236.145.33

2 * 10 ms 10 ms 10.30.235.1

3 <10 ms 10 ms 10 ms mtlcorr02-fe0-0-0.in.bellnexxia.net [206.108.105.130]

4 <10 ms 10 ms 10 ms core1-montreal02-pos11-1.in.bellnexxia.net [206.108.97.149]

5 10 ms 20 ms 10 ms Ncore2-newyork83-pos2-0.in.bellnexxia.net [206.108.103.214]

6 10 ms 20 ms 10 ms bx2-newyork83-pos4-0.in.bellnexxia.net [206.108.103.198]

7 10 ms 20 ms 10 ms jfk1-core1-s3-1.atlas.icix.net [165.117.50.253]

8 10 ms 20 ms 10 ms jfk3-core2-pos7-0.atlas.icix.net [165.117.48.165]

9 10 ms 20 ms 10 ms ord2-core2-pos5-0.atlas.icix.net [165.117.48.38]

10 30 ms 40 ms 30 ms ord2-core3-pos7-0.atlas.icix.net [165.117.48.94]

11 30 ms 30 ms 20 ms ord2-core4-pos5-0.atlas.icix.net [165.117.48.98]

12 30 ms 30 ms 30 ms dfw3-core2-pos6-0.atlas.icix.net [165.117.48.69]

13 50 ms 50 ms 50 ms dfw3-core2-pos7-0.atlas.icix.net [165.117.48.122]

14 91 ms 150 ms 90 ms dfw3-core3-pos6-3.atlas.icix.net [165.117.48.126]

15 110 ms 181 ms 120 ms iah2-core2-s3-0-0.atlas.icix.net [165.117.57.81]

16 90 ms 90 ms 90 ms 216.148.209.66

17 226 ms 247 ms 221 ms core-01-ge-0-3-0.chcg.twtelecom.net [168.215.54.29]

18 239 ms 229 ms 229 ms core-02-ge-2-3-0.chcg.twtelecom.net [168.215.53.6]

17 228 ms 228 ms 238 ms dist-01-so-2-0-0.iplt.twtelecom.net [168.215.53.18]

18 234 ms 231 ms 235 ms atagg-01-pos-0-0-0.iplt.twtelecom.net [207.67.94.202]

19 233 ms 229 ms 240 ms 207-67-94-186.gen.twtelecom.net [207.67.94.186]

20 235 ms 231 ms 241 ms websrv.hungryminds.com [168.215.86.100]

Śledzenie zakończone.

Ten ślad z serwera w Montrealu w Kanadzie do serwera WWW wydawnictwa Hungry Minds w Indianie pokazuje, że pakiety niekoniecznie wybrały najkrótszą trasę. Asterisk (*) w drugim wierszu wskazuje na przekroczenie limitu czasu. W istocie, czasami spotkamy przeskoki, dla których wszystkie trzy próby przekroczyły limit czasu. Taka sytuacja wskazuje, iż ruter w ogóle nie odpowiedział w dopuszczalnym czasie. Jeśli będzie to zachodziło raz po raz, znaleźliśmy problem — ruter nie działa.

Kolejny problem występuje wtedy, gdy dwa systemy w sieci posiadają taki sam adres IP. Nie powinno to mieć miejsca, lecz gdy się zdarzy, nasz system może rozwiązać adres docelowy raz na MAC jednego systemu, a raz na MAC drugiego.

Jeśli protokół rozwiązywania adresów nie funkcjonuje prawidłowo, nie będziemy w stanie rozwiązać adresu IP na sprzętowy. Narzędzie Address Resolution Protocol — ARP.EXE — pozwala zweryfikować zdolność do rozwiązywania adresów. Protokół ARP, jak pamiętamy z rozdziałów 4. i 5., rozwiązuje adresy IP na adresy MAC.

Jedynym przypadkiem, w którym możemy mieć problem z ARP, jest sytuacja, gdy do pamięci podręcznej ARP na potrzeby wydajności zostało dodane rozwiązywanie statyczne. Jeśli jednak adapter sieciowy dla systemu, dla którego wprowadzono adres IP, został wymieniony, odwzorowanie może powodować problemy. Możemy sprawdzić, czy ten problem występuje za pomocą narzędzia ARP, szukając w tablicy ARP wpisów statycznych.

Tablica ARP zawiera odwzorowania zdalnych adresów IP na MAC. Niektóre klienty lub serwery posiadają w tablicach ARP wpisy statyczne. Jeśli wpisy statyczne są stosowane, należy sprawdzić rozwiązywanie adresów (a jeśli odwzorowania nie są już ważne, powinny zostać odrzucone). Niemal we wszystkich systemach operacyjnych możemy sprawdzić tablicę ARP poleceniem arp -a. Wynik będzie wyglądał mniej więcej tak:

Interfejs: 24.112.92.45 on Interface 0x2000002

Adres internetowy Adres Fizyczny Typ

24.112.92.1 00-01-4f-16-08-00 dynamiczny

24.112.92.10 00-80-97-ea-e5-67 dynamiczny

24.112.92.11 00-80-c6-df-07-1a dynamiczny

24.112.92.12 00-e0-5f-23-67-a8 dynamiczny

24.112.92.14 00-80-e5-1f-32-0f dynamiczny

24.112.92.16 00-a0-78-a3-a1-ff dynamiczny

24.112.92.17 00-05-c6-15-87-80 dynamiczny

24.112.92.18 00-50-21-f6-43-ec dynamiczny

24.112.92.19 00-e0-09-35-31-d3 dynamiczny

24.112.92.20 00-80-4d-64-5a-45 dynamiczny

24.112.92.21 00-80-dc-a6-0f-72 dynamiczny

24.112.92.23 00-80-cf-1f-f8-c1 dynamiczny

24.112.92.26 00-00-c8-12-d5-09 dynamiczny

24.112.92.28 00-60-85-17-af-3f dynamiczny

24.112.92.31 00-20-29-f6-43-f9 dynamiczny

24.112.92.32 00-80-45-d6-08-85 dynamiczny

24.112.92.34 00-00-45-6d-28-16 dynamiczny

24.112.92.35 00-50-56-a1-23-4f dynamiczny

24.112.92.36 00-e0-4c-08-f1-35 dynamiczny

24.112.92.38 00-80-fe-05-a4-04 dynamiczny

24.112.92.42 00-50-c6-dd-53-22 dynamiczny

24.112.92.47 00-e0-80-45-48-3a dynamiczny

24.112.92.49 00-e0-01-16-0f-45 dynamiczny

24.112.92.50 00-e0-ae-18-24-f6 dynamiczny

24.112.92.51 00-50-04-8f-57-a2 dynamiczny

24.112.92.53 00-03-4f-10-2e-09 dynamiczny

24.112.92.54 00-04-05-de-f8-87 dynamiczny

24.112.92.56 00-05-45-73-0f-20 dynamiczny

24.112.92.58 00-50-37-16-24-2e dynamiczny

24.112.92.59 00-e0-27-45-68-1f dynamiczny

24.112.92.61 00-80-16-88-05-23 dynamiczny

24.112.92.62 00-05-08-ed-f5-fa dynamiczny

24.112.92.64 00-05-1f-a1-a6-e5 dynamiczny

24.112.92.65 00-e0-08-15-0f-1f dynamiczny

W powyższym listingu wszystkie systemy posiadają adresy dynamiczne. Aby oczyścić tablicę, wystarczy zaczekać kilka minut. Wpisy w tablicy ARP zwykle szybko ulegają przedawnieniu, aby zapewnić użycie aktualnego adresu.

Przyjrzeliśmy się już podstawowej łączności; pora zająć się kolejnym ważnym problemem, z którym Czytelnik będzie miał do czynienia — rozwiązywaniem nazw.

Znajdowanie problemów
z rozwiązywaniem nazw

Kluczowym obszarem w znajdowaniu problemów jest rozwiązywanie nazw. Ogólnie mówiąc, mamy do czynienia z dwiema nazwami i każda z nich jest rozwiązywana w inny sposób. Pierwszą jest oczywiście nazwa hosta — albo w postaci prostej nazwy hosta, albo nazwy pełnej złożonej (FQDN); druga jest nazwą NetBIOS dla sieci Microsoftu lub sieci używających narzędzia Samba.

Znajdowanie problemów z rozwiązywaniem nazw hostów

Rozwiązywanie nazw hostów jest zaskakująco proste. W istocie większość błędów powodowanych jest przez literówki: albo w komputerze, który chce się połączyć, albo w bazie danych serwera DNS. Najszybszą metodą ustalenia, czy mamy do czynienia z problemem z rozwiązaniem nazwy jest próba pingowania nazwy. Jeśli możemy pingować serwer według jego nazwy, wszystkie elementy składowe sieci działają poprawnie. Zwykle jest to pierwszy krok w rozwiązywaniu problemów. Jeśli nie możemy skontaktować się z serwerem pingując jego nazwę, należy wykonać kroki opisane w poprzednim podrozdziale. Proste badanie serwera poleceniem ping może wyglądać następująco:

Badanie www.dilbert.com [65.114.4.69] z użyciem 32 bajtów danych:

Odpowiedź z 65.114.4.69: bajtów=32 czas=168ms TTL=235

Odpowiedź z 65.114.4.69: bajtów=32 czas=171ms TTL=235

Odpowiedź z 65.114.4.69: bajtów=32 czas=164ms TTL=235

Odpowiedź z 65.114.4.69: bajtów=32 czas=163ms TTL=235

Statystyka badania dla 65.114.4.69:

Pakiety: Wysłane = 4, Odebrane = 4, Utracone = 0 (0% utraconych),

Szacunkowy czas błądzenia pakietów w milisekundach:

Minimum = 163ms, Maksimum = 171ms, Średnia = 166ms

W tym przypadku serwer jest czynny. Jeśli uzyskamy taką odpowiedź, jak poniżej, możemy mieć problem z rozwiązaniem nazwy:

Nieznany host fred.flintstone.com.

W tym przypadku system daje do zrozumienia, iż nazwy serwera nie można znaleźć, wobec czego serwera nie da się pingować. Innym problemem może być rozwiązanie nazwy na błędny adres. Oto przykład:

Badanie www7.AlzheimerCalgary.com [207.236.154.14] z użyciem 32 bajtów danych:

Upłynął limit czasu żądania.

Upłynął limit czasu żądania.

Upłynął limit czasu żądania.

Upłynął limit czasu żądania.

Statystyka badania dla 207.236.154.14:

Pakiety: Wysłane = 4, Odebrane = 0, Utracone = 4 (100% utraconych),

Szacunkowy czas błądzenia pakietów w milisekundach:

Minimum = 0ms, Maksimum = 0ms, Średnia = 0ms

Możemy podjąć kilka działań, aby ustalić, czy problem jest lokalny, czy występuje w serwerze DNS. Najpierw należy sprawdzić plik hosts i upewnić się, czy nie zawiera wpisu dla hosta, którego chcemy zlokalizować. Standardowo plik hosts jest sprawdzany w pierwszej kolejności, aby zredukować ruch w sieci. Plik ten mieści się w katalogu Windows dla Windows 9x i Me, w katalogu Winnt\system32\drivers\etc dla NT i 2000, lub w katalogu /etc dla większości implementacji Uniksa.

Jeśli host jest wymieniony w pliku hosts, musimy się upewnić, czy nazwa została zapisana prawidłowo, i czy adres IP jest poprawny. Jeżeli tak — a nadal możemy pingować serwer używając IP — problem najprawdopodobniej leży w warstwie aplikacji albo serwer został przeniesiony i inny host zajął jego adres.

Przyjmując, iż nazwa serwera, z którym chcemy się skontaktować, nie znajduje się w pliku hosts, sprawdzimy, czy używamy właściwego adresu serwera DNS i czy jest on osiągalny. Wystarczy znaleźć adres IP używanego serwera DNS i sprawdzić poleceniem ping. W przypadku systemów operacyjnych Windows możemy ponownie użyć polecenia ipconfig /all. Informacje o serwerze DNS zostaną wyświetlone w Windows 2000 w danych adapterów, zaś w pozostałych systemach Windows — w konfiguracji systemu. W przypadku Uniksa i pochodnych najlepiej sprawdzić w dokumentacji (niektóre systemy przechowują adres serwera nazw w pliku, a inne w pamięci).

Zakładając, iż adres serwera nazw jest prawidłowy, musimy sprawdzić w serwerze DNS adres serwera, z którym chcemy się połączyć. Jeśli używany przez nas serwer nazw powinien posiadać dany adres (inaczej mówiąc, jeśli posiada pełnomocnictwa dla strefy), możemy tam sprawdzić, czy nazwa szukanego serwera i jego adres IP są poprawne. Jeśli tak — i nadal możemy pingować serwer za pomocą adresu IP — musimy szukać problemu w warstwie aplikacji. Jeśli nie możemy pingować adresu, zapewne serwer lub część sieci nie działa.

0x01 graphic

W Windows 2000 i niektórych odmianach Uniksa usługa DNS stała się dynamiczna. Inaczej mówiąc, serwery i klienty rejestrują się same w serwerze DNS; administrator nie musi wprowadzać tych informacji ręcznie. Może okazać się konieczne wymuszenie ponownej rejestracji przez serwer odwzorowania nazwy na IP.

Jeśli serwer DNS nie posiada pełnomocnictw dla strefy, funkcjonuje w rozwiązywaniu nazw jak serwer buforujący. Inaczej mówiąc, musi otrzymać adres hosta od innego serwera DNS, z naszej sieci lub z Internetu. W tym przypadku problem może dotyczyć zdalnego serwera DNS lub sieci po drodze do niego. Tutaj warto szybko upewnić się, czy wszystkie części sieci funkcjonują, aż do miejsca, gdzie żądanie rozwiązania nazwy przekracza dopuszczalny czas oczekiwania. Jeśli możemy pingować hosta (musimy znać IP) i tylko rozwiązywanie nazw nie działa, możemy tymczasowo dodać odwzorowanie nazwy na IP do pliku hosts.

0x01 graphic

Ponieważ takie statyczne odwzorowanie może prowadzić do innych problemów, gdy zdalny system zmieni położenie i adres IP, przypisanie adresu IP do nazwy należy jak najszybciej usunąć.

Jeśli nadal nie znaleźliśmy problemu, możemy wykorzystać narzędzie nslookup, które pozwala zobaczyć, jak serwer DNS rozwiązuje poszczególne nazwy. Narzędzie to jest dostępne w Microsoft Windows NT i 2000 oraz większości implementacji Uniksa. Nslookup może działać w dwóch trybach: trybie zapytań, w którym wysyłamy proste zapytanie do serwera, oraz w trybie interaktywnym, który pozwala, między innymi, za pomocą standardowego polecenia ls wyświetlić informacje o zawartości serwera. Poniżej przedstawiony został przykład standardowego trybu zapytań:

nslookup www.GolfCanada.com

Server: localhost

Address: 127.0.0.1

Name: www.GolfCanada.com

Address: 48.53.66.7

Standardowe zapytania obejmują zarówno wyszukiwanie w przód, jak i wstecz. Tryb interaktywny pozwala nieco ściślej zdefiniować, jakiego typu rekordu szukamy. Na przykład, wyszukiwanie rekordu komputera wymieniającego pocztę (MX — mail exchanger) wygląda tak:

> ls -t mx Scrimger.org

[cyclops.scrimtech.com]

Scrimger.org. MX 10 mail.Scrimger.org

>

W większości przypadków, jeśli nazwa hosta nie rozwiązuje się, lecz posiadamy adres IP, możemy po prostu używać adresu IP i nie przejmować się wcale nazwą. Nie jest tak w przypadku nazw NetBIOS. W świecie TCP/IP połączenie adresu IP i numeru gniazda lub portu służy do identyfikacji usługi, której chcemy użyć. Adres IP i port razem tworzą gniazdo, które stanowi jeden z punktów końcowych połączenia (drugim jest adres IP i numer portu klienta). Wyobraźmy sobie próbę dostarczenia przesyłki w centrum Nowego Jorku, gdy dysponujemy jedynie ulicą i numerem budynku — dochodząc do wieżowca szybko zdamy sobie sprawę, iż bez numeru apartamentu nie jesteśmy w stanie wykonać zadania. To samo dotyczy danych przesyłanych do hosta, w którym uruchomionych jest dwadzieścia lub trzydzieści usług.

Nazwa hosta nie jest aż taka ważna (o ile znamy adres IP i numer portu lub gniazdo), ponieważ TCP/IP opracowano do obsługi dużych rozproszonych sieci. W przeciwieństwie do niego, NetBIOS został zaprojektowany do użytku w sieci jednosegmentowej, wobec czego nie działa w ten sposób — dla NetBIOS-u nazwa stanowi tożsamość komputera.

Znajdowanie problemów w rozwiązywaniu nazw NetBIOS

Gdy NetBIOS był opracowywany, nie było zbytniego zapotrzebowania na sieci rozległe, poza istniejącymi rozwiązaniami mainframe. Wobec tego NetBIOS został opracowany tak, by korzystać z przyjaznej nazwy komputera w roli adresu, zamiast czegoś w rodzaju adresu IP lub numeru węzła IPX. Wobec tego, aby dostać się do właściwego serwera, musimy znać jego nazwę.

15-znakowa nazwa NetBIOS stanowi tożsamość sieciową systemu NetBIOS-owego. We wczesnych latach 80. zakładano, że systemy te będą korzystać z NetBEUI (który został zaprojektowany specjalnie do pracy z nazwami NetBIOS) w roli protokołu transportowego. Nazwy NetBIOS posiadają szesnasty bit, który jest numerem usługi. Numer ten identyfikuje usługę, z którą łączymy się w komputerze, podobnie jak numer portu w TCP/IP. Dla każdej nazwy NetBIOS jest dostępnych tylko 256 numerów usług; jednakże pojedynczy komputer może mieć więcej niż jedną zarejestrowaną nazwę NetBIOS. Dochodzimy więc do prostej prawdy, przedstawionej w tabeli 23.2.

Tabela 23.2. Porównanie TCP/IP i NetBIOS-u

Rdzenny TCP/IP

NetBIOS

Identyfikator sieci

Adres TCP/IP

Nazwa NetBIOS

Identyfikator usługi

Numer portu

Numer usługi

Aby uzyskać łączność za pomocą rdzennego TCP/IP, musimy połączyć komputer z właściwym IP używając właściwego portu. Wobec tego w sieci NetBIOS musimy połączyć się z właściwą nazwą komputera i właściwym numerem usługi.

Jest tu jeszcze jeden problem. NetBIOS nie jest przeznaczony, z założenia, do użytku poza pojedynczym segmentem sieci i dokonuje całego rozwiązywania nazw za pomocą rozgłoszeń. Ponieważ rozgłoszenia te zalałyby sieć, gdyby rutery je w ogóle przepuszczały, rutery nie przekazują rozgłoszeń. Wobec tego wszelkie funkcje nazewnicze rdzennego NetBIOS-u są ograniczone do pojedynczego segmentu, co neguje przeznaczenie TCP/IP.

Ponieważ funkcje nazewnicze NetBIOS-u są ograniczone do pojedynczego segmentu, ta usługa w sieci wielosegmentowej musi zostać zmodernizowana przez dodanie nowej funkcjonalności. Do rozwiązania tego problemu wykorzystywano kilka metod. Pierwszą było użycie prostego pliku — podobnego do pliku hostów — o nazwie lmhosts (lm od LAN Manager). Ten prosty plik wymieniał serwery i ich adresy IP oraz posiadał zdolność do wskazania, które z serwerów były serwerami uwierzytelniającymi (kontrolerami domeny). Drugim rozwiązaniem było utworzenie serwera, który zarządzał funkcjonalnością nazw NetBIOS.

Na początku, gdy TCP/IP i NetBIOS były używane razem, zwykle liczba serwerów była na tyle mała, iż utrzymywanie pliku nie sprawiało problemu. To jednak zaczęło się zmieniać — liczba aktualizacji pliku stała się trudna w obsłudze i administracja zaczęła być problemem, przede wszystkim dlatego, że plik lmhosts, podobnie jak hosts, musiał być zapisany w każdym komputerze klienckim.

To doprowadziło do utworzenia scentralizowanego pliku lmhosts. W tym scenariuszu lokalny plik lmhosts w każdym kliencie wymieniał serwery uwierzytelniające i adres serwera centralnego (lub kilku), które posiadały pełną kopię pliku lmhosts. Dzięki temu klient mógł pobierać odwzorowania nazw z serwera centralnego w miarę potrzeb; nie musiał regularnie aktualizować swojej lokalnej kopii pliku lmhosts.

W końcu Microsoft, gdy wydał Windows NT, udostępnił usługę podobną do DNS-u, lecz zajmującą się nazwami NetBIOS. Usługa ta, nosząca techniczną nazwę NetBIOS Name Server (NBNS), w Windows NT otrzymała nazwę Windows Internet Naming Service (WINS). WINS pozwala na dynamiczną rejestrację nazw, jak też na odnawianie, rozwiązywanie i zwalnianie nazw.

Gdy mamy znaleźć problem z rozwiązywaniem nazw NetBIOS, możemy w większości postępować tak, jak w przypadku DNS-u. Ponownie należy sprawdzić konfigurację stacji roboczej i zweryfikować, czy adres IP serwera NBNS (WINS) jest poprawny. Możemy spróbować pingować serwer, aby sprawdzić, czy przynajmniej sam serwer działa oraz skontrolować, czy szukana nazwa jest rzeczywiście zarejestrowana w serwerze.

Jednym z kłopotów ze znajdywaniem problemów z nazwami NetBIOS jest ten, iż sposób użycia przez klienta narzędzi do rozwiązania nazwy nie jest stały. Istnieją w istocie cztery sposoby używania narzędzi do rozwiązywania nazw przez klienta NetBIOS. Konkretna metoda, jakiej klient używa, jest definiowana przez typ węzła i może zostać sprawdzona poleceniem ipconfig /all. W wyniku zobaczymy wiersz, który określi typ węzła: rozgłoszeniowy, równorzędny, mieszany lub hybrydowy. Zazwyczaj będzie to węzeł rozgłoszeniowy (dla komputerów nie posiadających skonfigurowanego adresu serwera WINS) lub hybrydowy (jeśli adres serwera WINS jest skonfigurowany). Typ węzła jest prawdopodobnie pierwszą rzeczą, którą powinniśmy sprawdzić, jeśli podstawowe informacje wydają się poprawne.

Następnie należy sprawdzić pamięć podręczną NetBIOS — czy nie znajdują się w niej wstępnie załadowane wpisy. W pewnych sytuacjach wpisy takie są używane do przyspieszenia połączenia z określonym serwerem, jeśli jednak jego adres IP ulegnie zmianie, zawartość pliku lmhosts (z którego ładowane są informacje) musi również zostać zmodyfikowana. Możemy sprawdzić pamięć podręczną nazw za pomocą polecenia nbtstat -c, które wyświetla zawartość pamięci podręcznej. Wynik może wyglądać następująco:

C:\WINNT\system32\>nbtstat -c

External:

Node IpAddress: [207.236.145.40] Scope Id: []

NetBIOS Remote Cache Name Table

Name Type Host Address Life [sec]

--------------------------------------------------------------

WEB <1C> GROUP 192.168.7.8 -1

MINOTAUR <03> UNIQUE 192.168.7.8 -1

MINOTAUR <00> UNIQUE 192.168.7.8 -1

MINOTAUR <20> UNIQUE 192.168.7.8 -1

Internal:

Node IpAddress: [192.168.1.2] Scope Id: []

NetBIOS Remote Cache Name Table

Name Type Host Address Life [sec]

--------------------------------------------------------------

WEB <1C> GROUP 192.168.7.8 -1

CYCLOPS <03> UNIQUE 192.168.1.1 -1

CYCLOPS <00> UNIQUE 192.168.1.1 -1

CYCLOPS <20> UNIQUE 192.168.1.1 -1

W tym przypadku wartości w kolumnie Life są ustawione na -1, co oznacza, iż wszystkie nazwy zostały wstępnie załadowane. Możemy spróbować usunąć polecenie #PRE z pliku lmhosts i przeładować pamięć podręczną za pomocą polecenia nbtstat -R. Klient użyje serwera WINS do znalezienia serwera, którego szuka, i problem może się rozwiąże. Systemy operacyjne Microsoftu zawierają plik o nazwie lmhosts.sam, który objaśnia wszelkie opcje, które możemy umieścić w pliku lmhosts.

Zakładając, iż cała konfiguracja, którą dotąd sprawdzaliśmy, jest w porządku, mamy jeszcze kilka nowych problemów, którym musimy stawić czoło. W DNS-ie przestrzeń nazw jest zorganizowana w sposób hierarchiczny, to znaczy, istnieją różne poziomy. Gdy chcemy rozwiązać nazwę, możemy dojść do poziomu głównego za pomocą FQDN i przejść poziom po poziomie do systemu, który chcemy znaleźć. Nie dotyczy to serwerów WINS lub NBNS. Zgodnie z założeniami, przestrzeń nazw NetBIOS jest płaska, wobec czego baza danych WINS dla organizacji może zawierać dosłownie dziesiątki tysięcy nazw, zwłaszcza że wszystkie systemy, również klienty nie udostępniające żadnych usług, rejestrują swoje nazwy.

DNS używa hierarchicznej przestrzeni nazw, ponieważ liczba hostów, z którymi musi się uporać, całkowicie przeciążyłaby pojedynczy serwer. WINS stoi przed tym samym wyzwaniem. W przypadku usługi WINS rozwiązaniem jest jednakże dodanie kilku serwerów równorzędnych i skonfigurowanie replikacji pomiędzy nimi. Oznacza to, że częścią rozwiązywania problemów z WINS jest umiejętność rozwiązywania problemów z replikacją.

Znajdowanie problemów z replikacją oznacza sprawdzanie w menedżerze WINS adresów IP dwóch zaangażowanych serwerów i zapewnienie, by przynajmniej jeden był partnerem wypychającym (push), a drugi ściągającym (pull). W praktyce powinny być jednym i drugim — o ile nie zaprojektowaliśmy infrastruktury WINS tak, by działała w konfiguracji satelitarnej.

Gdy wszystko inne zawiedzie, możemy spróbować dodać odwzorowania nazw do pliku lmhosts. Jeśli to rozwiąże problem, powinniśmy przyjrzeć się uważnie serwerom WINS, ponieważ mogą mieć uszkodzoną bazę danych lub nie dokonywać poprawnie replikacji.

Weryfikacja klienta i serwera

Ostatnim elementem procesu rozwiązywania problemów jest kontrola wewnętrzna samego klienta i serwera. Z technicznego punktu widzenia klient jest pakietem oprogramowania uruchomionym w komputerze, zaś serwer pakietem działającym w serwerze, który może być tym samym lub innym komputerem. Jak w przypadku wszelkiego oprogramowania, istnieje możliwość, iż serwer, z którym chcemy się połączyć nie działa, działa nieprawidłowo lub nie jest aktualnie skonfigurowany do przyjmowania połączeń.

Ogólnie mówiąc, szybkim testem sprawdzającym w rdzennym środowisku TCP/IP, czy usługa działa, jest próba skontaktowania się z inną usługą w tym samym systemie. Jeśli potrafimy połączyć się z Telnetem, lecz nie potrafimy z FTP, problem leży po stronie serwera lub klienta FTP. Możemy spróbować połączyć się z usługą FTP z innej stacji roboczej lub z innym serwerem FTP z lokalnego komputera, co pozwoli ustalić, po której stronie są problemy.

Tego samego testu możemy użyć z NetBIOS-em. Jeśli nie potrafimy połączyć się z usługą serwera, spróbujmy do systemu wysłać wiadomość poleceniem net send. Możemy też użyć polecenia net view, aby zobaczyć udziały w innych systemach i ustalić, czy klient działa. Jednym z najczęstszych problemów z NetBIOS-em są uprawnienia, więc możemy sprawdzić, czy mamy z nim do czynienia, próbując przypisać napęd z wiersza poleceń, w którym zobaczymy komunikat o błędzie.

Proszę pamiętać, że problem niekoniecznie musi leżeć po stronie klienta — winien może być serwer. Czytelnik powinien też pamiętać, iż przypuszczalnie ma jako administrator więcej uprawnień od zwykłego użytkownika. Wobec tego po pomyślnym połączeniu warto sprawdzić uprawnienia.

480 Część IV Tworzenie i utrzymanie sieci TCP/IP

Rozdział 23. Rozwiązywanie problemów z siecią i łącznością 465



Wyszukiwarka

Podobne podstrony:
podrecznik 2 18 03 05
regul praw stan wyjątk 05
05 Badanie diagnostyczneid 5649 ppt
Podstawy zarządzania wykład rozdział 05
05 Odwzorowanie podstawowych obiektów rysunkowych
05 Instrukcje warunkoweid 5533 ppt
05 K5Z7
05 GEOLOGIA jezior iatr morza
05 IG 4id 5703 ppt
05 xml domid 5979 ppt
Świecie 14 05 2005
Wykł 05 Ruch drgający
TD 05
6 Zagrozenia biosfery 07 05 05
05 DFC 4 1 Sequence and Interation of Key QMS Processes Rev 3 1 03

więcej podobnych podstron