zad_1_grupa

Sprawozdanie z laboratorium

Wprowadzenie do sieci komputerowych

Grupa 5: Alicja Lenart nr indeksu:138827,
Piotr Pliszka nr indeksu:138839.

Treść :

Zagadnienia teoretyczne:

•

Protokół IP (wersja 4): połoŜenie w modelu ISO/OSI, budowa pakietu, parametry
pakietu.

•

Protokół ICMP: rodzaje i znaczenie komunikatów.

•

Adresy IP: adres, podział na podsieci, klasy podsieci, maska podsieci, dopasowanie
adresu do podsieci, tablica rutingu, pojęcie bramy domyślnej. Adresy specjalne (pętla
zwrotna, broadcast, adres podsieci). Tzw. prywatne klasy adresów, translacja adresów
(NAT). Zarządcy adresów IP - RIPE, ICANN.

•

Protokoły TCP i UDP: połoŜenie w modelu ISO/OSI, parametry, flagi. Połączenie
TCP: nawiązywanie, rozwiązywanie, zrywanie, mechanizm okna, potwierdzanie,
składanie pakietów. Datagramy UDP.

Zadania praktyczne:

•

Za pomocą programów ping, pathping, tracert zbadać komputery: a) z sieci
laboratoryjnej, b) z sieci SZSK poza laboratorium, c) w dowolnym miejscu w Polsce,
d) w dowolnym miejscu poza Polską. Ustalić zarządców tych adresów.

•

Zbadać i zmodyfikować ustawienia protokołu IP na własnym stanowisku korzystając
zarówno z narzędzi Panelu Sterowania Windows, jak i polecenia ipconfig.

•

Zbadać tablicę rutingu (w szczególności bramę domyślną) na własnym stanowisku
korzystając z polecenia route.

•

Zbadać nasłuchujące porty TCP i UDP oraz nawiązane połączenia TCP wykorzystując
polecenie netstat. Utworzyć połączenie TCP (np. przeglądarką WWW, klientem
poczty, telnet czy ssh) i wykazać jego obecność poleceniem netstat.

Część teoretyczna

Model OSI dzieli procesy sesji komunikacyjne na siedem rozłącznych warstw
funkcjonalnych. Odpowiadają one pewnemu naturalnemu ciągowi zdarzeń występującemu w
trakcie sesji.

|----------------|----------------|

| Nazwa modelu | Numer |

| odniesienia | warstwy |

| OSI | OSI |

|----------------|----------------|

| Aplikacji | 7 |

|----------------|----------------|

| Prezentacji | 6 |

|----------------|----------------|

| Sesji | 5 |

|----------------|----------------|

| Transportowa | 4 |

|----------------|----------------|

| Sieci | 3 |

|----------------|----------------|

| Łącza danych | 2 |

|----------------|----------------|

| Fizyczna | 1 |

Warstwa 1 - fizyczna - najniŜsza warstwa zwana warstwą fizyczną odpowiedzialna jest za
wysyłanie lub odbieranie strumienia bitów. Warstwa ta dosłownie rozróŜnia tylko zera i
jedynki , nie określa znaczenia wysyłanych lub otrzymywanych bitów.

Warstwa 2 - łącza danych- pakowanie instrukcji, danych itd. w ramki. Ramka jest strukturą
charakterystyczną dla warstwy łacza danych. Ramka jako taka zawiera informacje
gwarantujące pomyślne przesłanie danych przez sieć do miejsca przeznaczenia. Dotarcie
ramki do miejsca docelowego w stanie nienaruszonym oznacza pomyślne dostarczenie ramki.
W takim razie musi być sprawdzana integralność zawartości ramki po jej dostarczeniu.

Warstwa łącza danych odpowiada za:
+ wykrywanie i naprawę błędów powstałych podczas procesu przesyłania + składanie ramek
z binarnych strumieni danych odbieranych z warswty fizycznej

Warstwa 3 - sieciowa - odpowiedzialna za ustalanie drogi ( trasy ) między komputerem
wysyłającym a docelowym.

Warstwa 4 - transportowa - odpowiada za integralność transmisji między dwoma punktami
końcowymi. Badanie integralności przesłanych danych upodabnia tą wartwę do warstwy 2,
jednak warstwa transportowa wysyła Ŝądania ponownej transmisji danych, które zostały
uznane za błędne, ustala takŜe kolejność pakietów, których porządek dostarczenia moŜe być
naruszona z powodu przesłania ich róŜnymi trasami.

Warstwa 5 - sesji - odpowiada za zarządzanie przepływem komunikacji w trakcie połączenia
dwóch systemów komputerowych. Przepływ danych między systemami nosi właśnie nazwę
sesji.

Warstwa 6 - prezentacji - odpowiada za zarządzanie sposobem kodowania danych, np.:

tłumaczy dane zapisane w systemie kodowania ASCII na system kodowania EBCDIC, moŜe
takŜe wykonywać usługi szyfrowania danych.

Warstwa 7 - aplikacji - mimo , iŜ ma nazwę pozwalającą sądzić iŜ związana jest z aplikacją
uŜytkownika tak nie jest, tworzy zaś interfej między nim a usługami sieciowymi

Protokół IP - Skrót IP tłumaczony jest jako "protokół internetowy" lub według opracowań
"protokół międzysieciowy".  MoŜna powiedzieć, Ŝe protokół IP jest pierwszym poziomem
abstrakcji, dzięki czemu protokoły wyŜszych warstw takie jak TCP czy UDP mogą traktować
sieć jako pewne środowisko w którym komunikacja między komputerami opiera się tylko i
wyłącznie o moŜliwości jakie udostępnia protokół IP. Protokół IP zapewnia usługę
bezpołączeniowego dostarczania pakietów przy uŜyciu dostępnych moŜliwości. Protokół IP
nie bierze pod uwagę zawartości pakietu, ale wyszukuje ścieŜkę do miejsca docelowego.
Budowa pakietu- pakiety IP składają sie z danych z wyŜszych warstw oraz nagłówka IP.
Nagłówek IP zawiera następujące pola:
Wersja — określa format nagłówka pakietu IP. 4-bitowe pole wersji
zawiera liczbę 4, jeśli jest to pakiet IPv4, a liczbę 6, jeśli jest to pakiet
IPv6. Pole to nie jest jednak stosowane do rozróŜniania pomiędzy
pakietami IPv4 a IPv6 - taką rolę pełni pole typu protokołu obecne w
ramce warstwy drugiej.
Długość nagłówka IP (HLEN) — określa długość nagłówka datagramu
jako wielokrotność słów 32-bitowych. Jest to całkowita długość wszystkich
informacji znajdujących sie w nagłówku, obejmująca dwa pola nagłówka o
zmiennych długościach.
Typ usługi(TOS, ang. Type-of-service) — określa poziom waŜności, który
został przypisany przez protokół wyŜszej warstwy; osiem bitów.
Całkowita długość — określa długość całego pakietu w bajtach z
uwzględnieniem danych i nagłówka; 16 bitów. Aby uzyskać długość pola
danych, od długości całkowitej naleŜy odjąć wartość HLEN.
Identyfikacja — zawiera liczbę całkowitą identyfikująca bieŜący datagram;
16 bitów. Jest to numer sekwencyjny.
Flagi — pole o długości trzech bitów, w którym bity sterują fragmentacją.
Jeden bit określa, czy pakiet moŜe zostać podzielony na fragmenty,
kolejny czy pakiet jest częścią fragmentowaną, a trzeci słuŜy do
oznaczenia ostatniego pakietu w serii podzielonych pakietów.

Protokół ICMP-- jest integralną częścią protokołu IP, jego zadaniem jest sygnalizacja błędów
oraz diagnostyka sieci. Komunikat ICMP jest zapakowany w datagram IP, dlatego teŜ jak
UDP jest protokołem bezpołączeniowym i nie gwarantuje dostarczenia komunikatu. Widać
wyraźnie pewną sprzeczność bowiem protokół ICMP wykorzystuje wsparcie protokołu IP tak
jakby był "wysokopoziomowym" protokołem lecz jest jego integralną częścią.
Typy komunikatów ICMP oraz ich opis:

* Echo Reply ( Typ 0 ) oraz Echo Request ( Typ 8 ) - słuŜą do testowania kanału
komunikacyjnego pomiędzy dwoma komputerami. Odbiorca datagramu ICMP Echo Request
jest proszony o odpowiedź na tzw. ping. Odpowiedź jest formułowana za pomocą datagramu
ICMP Echo Reply. Dzięki temu nadawca moŜe stwierdzić czy jest moŜliwość nawiązania
połączenia z odbiorcą, oraz sprawdzić bieŜącą kondycję połączenia z odbiorcą.

* Destination Unreachable ( Typ 3) - tego typu komunikatu uŜywa się w sytuacjach gdy:

router lub bramka nie potrafią ustalić kierunku w którym powinien być wysłąny pakiet, gdy
parametr TTL zostanie zmniejszony do 0, gdy pakiet musi zostać podzielony na fragmenty,
ale ma ustawioną flagę Don't Fragment, gdy określony protokół lub aplikacja w miejscu
przeznaczenia pakietu jest nieaktywna, gdy odległość do sieci docelowej wynosi
nieskończoność. Kody jakie w tym wypadku będzie mogł zawierać komunikat ICMP to:
+ 0 = net unreachable ( sieć nieosiągalna )
+ 1 = host unreachable ( docelowa stacja robocza nieosiągalna )
+ 2 = protocol unreachable ( protokół niedostępny )
+ 3 = port unreachable ( port nieosiągalny )
+ 4 = fragmentation needed and DF set ( potrzeba fragmentacji, ustawiona flaga DF )
+ 5 = source route failed

* Source Quench ( Typ 4 ) - gdy bufor odebranych danych wypełni się, to pakiet, który się w
nim nie zmieści, zostanie porzucony. Dla kaŜdego takiego pakietu wygenerowywany jest
datagram ICMP Source Quench, który dla nadawcy porzuconych pakietów jest sygnałem do
zwolnienia strumienia wysyłanych danych.

* Route Redirect ( Typ 5 ) - informacje o bieŜącej topologii sieci są co pewien czas
odświeŜane i wysyłane do sąsiednich sieci, co pozwala na zachowanie aktualnych tablic
routingu. Gdy tylko router zidentyfikuje nadawcę uŜywającego niewłaściwej trasy dla swoich
pakietów, po przetworzeniu pakietu wysyła do nadawcy datagram ICMP Route Redirect
informujący o istnieniu lepszej trasy dla jego pakietów.

* Datagram Time Exceeded ( Typ 11 ) komunikat ten jest wysyłany przez router albo bramkę
w sytuacji gdy napotkają one datagram z parametrem TTL równym 0. Urządzenie
napotykające datagram TTL = 0 ma obowiązek go porzucić, a następnie wysłać do nadawcy
komunikat ICMP Datagram Time Exceeded. Gdy urządzenie składające sfragmentowane
datagramy nie moŜe złoŜyć datagramu w czasie na to przewidzianym. Kody jakie zawiera ten
komunikat ICMP:
+ 0 = time to live exceeded in transit ( podczas przesyłania pakietu TTL został obniŜony do 0
- wysyłane przez router lub bramkę )
+ 1 = fragment reassembly time exceeded ( czas na złoŜenie pakietu minął - wysyłane przez
stacje roboczą )

* Datagram Parameter Problem ( Typ 12 ) uŜywany jest w wyniku napotkania datagramu,
którego nagłówek utrudnia, lub uniemoŜliwia jego dalsze przetwarzanie. W tym przypadku
datagram jest porzucany, a jego nadawcy zwracany jest komunikat ICMP Datagram
Parameter Problem. Potencjalnym powodem takiego komunikatu, mogą być niewłaściwe
argumenty w opcjach nagłówka IP. Komunikat zwraca wskazanie na parametr pakietu, który
spowodował problem.

* Timestamp Request ( Typ 13 ) i Timestamp Reply ( Typ 14 )- uŜywa się ich do
synchronizowania zegarów komputerów w sieci.

* Information Request ( Typ 15 ) oraz Information Reply ( Typ 16 ) - za ich pomocą
komputer moŜe uzyskać adres IP w sieci, w której się znajduje. W celu realizacji
rozprzestrzeniany jest datagram ICMP Inforamtion Request zawierający jedynie część adresu
opisującą sieć do której naleŜy komputer, oczekując odpowiedzi w postaci ICMP Information
Reply zawierającą pozostałą część adresu IP tego komputera. Jest to sposób dla komputera do
poznania sieci w której się znajduje.

* Adress Mask Request ( Typ 17 ) oraz Adress Mask Reply ( Typ 18 ) - komunikaty te
uŜywane są do otrzymania maski podsieci w której znajduje się komputer. ICMP Adress
Mask Request moŜe być wysyłany bezpośrednio do urządzenia, które udzieli tej informacji
(router, bramka) lub teŜ jest rozprzestrzeniany w całej sieci lokalnej.

Adres-pierwotna czwarta wersja protokołu IP opiera się na 32 bitowych adresach
dwójkowych. KaŜdy adres składa się z 4 liczb 8 bitowych rozdzielonych kropkami. Liczby te
noszą nazwę oktetów. Przyjęto konwersję adresów dwójkowych na przyjazne dla człowieka,
zdefiniowane za pomocą notacji dziesiętnej z kropkami. Wynika stąd, iŜ adresy IP miesza się
w przedziale 0.0.0.0 - 255.255.255.255 Te graniczne wartości są jednak zarezerwowane i nie
moŜna przypisywać ich Ŝadnym systemom końcowym.

Klasy-adresy IP podzielono na klasy przystosowane do obsługi sieci duŜych, średnich i
małych (5 klas od A do E). Adres IP dzielony jest bowiem na fragment odpowiedzialny za
adres sieci i za adres stacji.
+ Adresy klasy A - w adresie klasy A adres sieci zajmuje pierwszy oktet. Pierwszy bit adresu
klasy A jest zgaszony ( zawsze równy 0 ). Ogranicza to największą liczbę sieci IP klasy A do
127. Dopuszczalny zakres jest nod 1.0.0.0 do 126.255.255.255
+ Adresy klasy B - pierwsze dwa bity tego oktetu wynoszą 10 co oznacza, Ŝe zakres tej klasy
obejmuje adresy od 128.0.0.0 do 191.255.255.255
+ Adresy klasy C - pierwsze trzy bity pierwszego oktetu wynoszą 110 to daje zakres adresów
od 192.0.0.0 - 223.255.255.255
+ Adresy klasy D - Pierwsze 4 bity pierwszego oktetu wynoszą 1110 co daje zakres adresów
od 224.0.0.0 do 239.255.255.254
+ Adresy klasy E - eksperymentalna klasa zarezerwowana przez IETF do badań naukowych.
Zakres od 240.0.0.0 do 255.255.255.255

Podział na podsieci - dwupoziomowa struktura sieci Internet okazała się zbyt przestarzała .
RóŜne organizacje zaczęły mieć więcej niŜ jedną sieć, dlatego nie wystarczało im tylko jedno
połączenie do internetu. Zaproponowano podział na podsieci. Od tej pory kaŜda sieć tworzona
przez jakąś organizację mogła być traktowana jako podsieć.
W środowiskach wielosieciowych kaŜdą podsieć moŜna podłączyć do Internetu za pomocą
routera. Podział na podsieci pozwala na podział sieci IP ( dowolnej klasy: A, B l ub C ) na
mniejsze jednostki organizacyjne.
Adres IP w podsieci składa się z :
- adresu sieci
- adresu podsieci
- adresu stacji
MoŜliwość podziału na podsieci zaleŜy od typu wykorzystywanego adresu IP. Im więcej
bitów stacji w adresie IP, tym więcej moŜliwych podsieci do uzyskania. Określanie w ten
sposób podsieci zmniejsza liczbę moŜliwych do zaadresowania stacji. Podsieci identyfikuje
się za pomocą maski podsieci.

Maska podsieci - 32 bitowa liczba dwójkowa wyraŜana takŜe w przyjaznej notacji dziesiętnej.
Maska informuje o liczbie bitów adresów IP stosowanych do identyfikacji sieci i podsieci.
Bity nazywane są rozszerzonym przedrostkiem sieci. Reszta bitów identyfikuje stacje w
podsieci. Bity maski identyfikujące część sieciową zawierają jedynki, natomiast bity
określające stacje zawierają zera.
Weźmy przykład:

Maska 255.255.255.192 w postaci dwójkowej 1111 1111.1111 1111.1111 1111.1100 0000
daje nam 64 teoretycznie moŜliwe adresy stacji, gdyŜ jeśli przyjrzymy się bliŜej 4 oktetowi :
1100 0000 to zauwaŜymy, Ŝe taka jest suma wartości 6 bitów ustawionych na 0 czyli 2 ^5+
2^4 + 2^3 + 2^2 + 2^1 + 2^0 = 64 adresy. Jednak korzysta sie 62 adresów, bowiem dwa
adresy 1100 0000 oraz 1111 1111 są zarezerwowane.

Brama domyślna - jeśli komputer ma się komunikować z sieciami zdalnymi lub z segmentami
sieci LAN oddzielonymi routerem , powinien posiadać adres domyślnej bramy . Jest to router
przekazujący pakiety do odpowiedniego miejsca przeznaczenia lub następnego miejsca w
trasie

Tablica routingu - jak zapewne łatwo się domyślić jedną z najwaŜniejszych funkcji sieci IP
jest wyznaczanie tras ( routing ), proces ten polega na odkrywaniu, porównywaniu i wyborze
ś

cieŜek prowadzących do Ŝądanego adresu IP. Do wyznaczania tras słuŜą dwie metody:

+ statyczne wyznaczanie tras
+ dynamiczne wyznaczanie tras

Najprościej mówiąc, jest to obszar pamięci na routerze (komputerze łączącym co najmniej
dwie sieci fizyczne i przekazującym datagramy miedzy nimi), w którym to obszarze
przechowywane są adresy IP sieci oraz odległość do nich (ilość routerów na drodze do danej
sieci). Dzięki tej tablicy router wie dokąd kierować przychodzące datagramy. Podstawowa
tablica routingu znajduje się na kaŜdej stacji roboczej.

Adresy specjalne - część adresów z puli specjalnej IP została wydzielona jako adresy
zarezerwowane. Dokument RFC o numerze 1700 opisuje te adresy za pomocą

Adres - IP : := { < Numer - sieci >, < Numer_stacji > }

Wartość numeru sieci lub numeru stacji określana jest za pomocą:

•

"-1" - identyfikator złoŜony w całości z samych binarnych jedynek

•

"0" - identyfikator złoŜony z samych zer

•

Adres sieci - nie moŜe być przypisany identyfikator złoŜony z samych zer, poniewaŜ
tak są zbudowane identyfikatory oznaczające całą sieć. Składnia adresu IP jest
następująca:

{ < Numer - sieci >, 0 }

•

Adres 137.53.0.0 ( klasy B ) w klasie B < Numer - sieci > zbudowany jest z 16 bitów
( czyli 2 oktety ) i nie moŜe być uŜywany jako źródłowy lub docelowy adres IP.

•

Ukierunkowany adres rozgłaszania ( directed broadcast ) - moŜe to być docelowy
adres komunikacji. Format adresu:

{ < Numer - sieci >, -1 }

•

Adres 137.53.255.255 - odbiorcami wiadomości wysłanej pod ten adres są wszystkie
stacje w sieci.

•

Lokalny adres rozgłaszania - ( local lub limited broadcast address ) czyli
255.255.255.255 - w uŜytej przez nas notacji został ten adres zapisany jako:

{ -1, -1 }
Rozgłoszenia lokalne są propagowane w sieci lokalnej i ignorowane przez routery. Adres ten
moŜe być wykorzystywany jako adres docelowy komunikatów.

•

Adres zerowy - jest to adres o postaci:

{ 0,0 }

< Numer - sieci > ma wartość zero co oznacza sieć lokalną < Numer stacji > to równieŜ 0, co
oznacza sieć lokalną. Wykorzystywane przez stacje nawiązujące komunikacje IP w celu
pobrania przydzielonego im adresu określane były dawniej jako lokalny adres rozgłaszania.

•

Adres sieci lokalnej - w naszej notacji oznaczony jest jako:

{ 0, < Numer - sytuacji > }.
Dzięki takiej konstrukcji pakiety mogą być przesyłane wyłącznie wewnątrz sieci lokalnej.

•

Pętla zwrotna ( loopback address ) - adres specjalny opisany jako

{ 127, < dowolny > }

KaŜdy pakiet przesyłany na adres 127.X.X.X ( X - dowolna wartość z zakresu 0 do 255 ) jest
zwracany do aplikacji wysyłającej bez przekazywania do sprzętowej warstwy sieci. Wynika z
tego, iŜ pakiet jest jedynie kopiowany pomiędzy buforem nadania a buforem odbierania tego
samego komputera. Adres ten słuŜy do testowania poprawności konfiguracji
oprogramowania, serwerów etc.

NAT - sieć prywatna, która chroniona jest zaporą ogniową nie musi stosować się do
unikatowości globalnej adresów. Specjalny mechanizm translacji adresów sieciowych
( NAT ) zastępuje w pakietach przekazywanych przez zaporę adresy prywatne adresem
przyłącza publicznego. Dla sieci prywatnych wyróŜnione zostały odrębne pule adresów:
+ A ( 10.0.0.0 ) - jedna sieć
+ B ( 172.16.00 - 172.31.0.0 ) - 16 sieci
+ C ( 192.168.00 - 192.168.255.0 ) - 256 sieci

Zarządcy adresów IP - stabilność internetu zaleŜy od niepowtarzalności publicznie
stosowanych adresów sieci. Opiekę nad tym sprawuje korporacja ICANN. ICANN ( Internet
Corporation for Assigned Names and Numbers ) - Korporacja Internetowa ds.
Przypisywanych Numerów i Nazw. Powstanie takiej korporacji jest próbą
umiędzynarodowienia administrowania domenami. Drugą organizacją o podobnym zakresie
działań jest RIPE ( Reseaux IP Europeens )co moŜna dosłownie przetłumaczyć na Europejski
Ośrodek Koordynacji Sieci.

Protokół TCP- jest bardzo waŜną usługą, metodą gwarantowanego dostarczenia danych.
Mechanizm niezawodnościowy komunikacji TCP obejmuje całą drogę transmisji danych
pomiędzy dwoma procesami aplikacyjnymi, pracującymi w dwóch róŜnych systemach
komputerowych. Jego realizacja opiera się na usługach będących nadbudową funkcji
protokołu IP. Protokół IP ma charakter bezpołączeniowy i nie gwarantuje dostarczenia
pakietów. Architektura TCP opiera się na dość słusznym załoŜeniu, Ŝe protokół IP jest
zawodny i obudowuje go w usługi zapewniające powodzenie komunikacji. Podczas gdy
protokół IP jest implementowany na stacjach i routerach, protokół TCP jest standardowo
obsługiwany wyłącznie przez stacje - jako punkty końcowe wymagające niezawodnego
mechanizmu transmisji. Protokoły TCP i UDP połoŜone są w ISO/OSI w warstwie 4 -
transportowej.

Połączenie - zanim jakiekolwiek dane zostaną przesłane przy uŜyciu protokołu TCP, proces
aplikacyjny musi ustanowić połączenie. W kilku słowach połączenia "łączą" numery portów
nadawcy i odbiorcy - jest to pewien mechanizm identyfikacji punktów końcowych
połączenia, więc punkt końcowy połączenia definiowany jest jako para wartości, obejmująca
adres IP i numer portu ( słuŜy on do identyfikacji aplikacji ). Dane pary punktów końcowych

całkowicie identyfikują połączenie, kaŜde połączenie moŜe przenosić dane w obu kierunkach
- jest więc połączeniem pełnodupleksowym.

Aplikacje komunikują się z modułem TCP przy uŜyciu następujących wywołań
systemowych:
+ OPEN- otwórz połączenie
+ CLOSE - zamknij połączenie
+ SEND - wyślij dane przez otwarte połączenie
+ RECEIVE - odbieraj dane przez otwarte połączenie
+ STATUS - podaj informacje o połączeniu

Wywołania te implementowane są przez system operacyjny, dostęp do modułu TCP
realizowany jest jak dostęp do plików, na takim modelu oparty jest interfejs Sockets systemu
BSD i nowe generacje interfejsu Winsock firmy Microsoft. Dane połączenia są przekazywane
funkcji OPEN, operującej na lokalnym porcie TCP. Opisują one zdalny punkt końcowy
komunikacji,. Funkcja zwraca krótką wartość całkowitą - uchwyt wykorzystywany przez
proces aplikacyjny w kolejnych wywołaniach. Dane połączenia przechowywane są w
strukturze danych : TCB ( Transmission Control Block ) - Blok Sterowania Transmisją.
Uchwyt umoŜliwa dostęp do informacji w bloku TCB.

Protokół TCP przewiduje dwa rodzaje wywołań OPEN Active oraz Passive. Otwarcie
aktywne wymaga zainicjowania ustanawiania połączenia. Otwarcie pasywne sygnalizuje
zamiar odebrania połączenia inicjowanego przez drugi punkt końcowy. JeŜeli oba procesy
wywołają funkcje otwarcia aktywnego jednocześnie, równieŜ zostaną poprawnie połączone,
bowiem oba składniki mogą pracować wzajemnie asynchronicznie.

Dla całego procesu nawiązywania i zamykania połączeń istotne są znaczniki ( URG, ACK,
PSH, RST, SYN, FIN ).
- Ustawiony znacznik ACK informuje, Ŝe pole numeru potwierdzenia zostało wykorzystane
- Ustawiony znacznik SYN sygnalizuje otwieranie obwodu wirtualnego połączenia
- Znacznik FIN słuŜy do zakończenia połączenia
- Bit RST słuŜy do zamykania obwodu wirtualnego ze względu na niemoŜliwe do
skorygowania błędy.
- Ustawienie znacznika PSH nakazuje TCP natychmiastowe dostarczenie komunikatu do
procesu warstwy wyŜszej.
- Znacznik URG słuŜy do przesyłania danych pozapasmowych, bez oczekiwania na
przetwarzanie przez odbiorcę oktetów włączonych juŜ do strumienia danych.

Otwarcie połączeń TCP wymaga trójstopniowej procedury wymiany potwierdzeń. Kolejno
wykorzystywane są następujące kombinacje znaczników SYN i ACK:
SYN = 1 i ACK = 0 - Pakiet otwarcia połączenia
SYN = 1 i ACK = 1 - Potwierdzenie Ŝądania połączenia
SYN = 0 i ACK = 1 - Pakiet danych lub pakiet ACK ( potwierdzenia )

Zamykanie połączenia - Kiedy połączenie TCP ma być zamknięte, przesyłany jest znacznik
FIN, nie powoduje to natychmiastowego rozłączenia. Znacznik przesłany przez obie strony
jako sygnał zgody na zakończenie komunikacji. Taki sposób zakończenia połączenia określa
się jako zamknięcie łagodne ( graceful close ) co podkreśla Ŝe obie strony uzgodniły zamiar.
Gdyby jeden z uczestników komunikacji zakończył połączenie nie informując drugiego,
tamten mógłby w nieskończoność podejmować próby retransmisji danych, które nigdy nie

zostałby odebrane.

Przerwanie połączenia TCP - moŜe nastąpić to kiedy komputer zdalny lub łącze ulegają
awarii, jak wygląda wykrycie i zwolnienie zasobów, otóŜ moŜe zostać odebrany komunikat
ICMP, informujący o braku komunikacji ze stacją docelową. Przed zgłoszeniem aplikacji, Ŝe
doszło do takiej sytuacji moduł TCP kilkakrotnie ponawia próby transmisji. Co się dzieje, gdy
komunikaty ICMP nie zostaną odebrane z powodu zakłóceń przesyłania? Moduł TCP
ponawia próby komunikacji do czasu osiągnięcia pierwszego progu ograniczającego liczbę
retransmisji. Wówczas do modułu IP przekazywane jest powiadomienie, prowadzące do
ustalenia, czy problem spowodowało przerwanie trasy lub awaria routera. Warstwa IP
ponownie próbuje ustalić trasę. W tym samym czasie moduł TCP ponawia próby transmisji aŜ
do drugiej wartości progowej liczby retransmisji. Wówczas połączenie zostaje uznane za
przerwane. W takiej sytuacji zwalniane są wszystkie związane z nim zasoby, bufor i blok
sterowania transmisją.

Mechanizm Okna - W schemacie formatu komunikatu TCP występuje pole rozmiaru okna,
które jest elementem mechanizmu kontroli przepływu, wypełnia to pole odbiorca. To
informacja dla nadawcy o moŜliwościach odbiorczych modułu TCP.

Protokół UDP- nie zapewnia niezawodności tak jak TCP, ale stosowany jest wszędzie tam
gdzie potrzebny jest jedynie protokół transportowy, który poprawnie zidentyfikuje aplikację
docelową i przeprowadzi podstawową kontrolę poprawności transmisji. Protokół UDP
pracuje w trybie datagramowym, wysyłanie więc polega na opatrzeniu danych nagłówkiem
UDP i przekazaniu do warstwy IP. UDP nie zapewnie sekwencjonowania danych znaczy to
tyle, Ŝe mogą one dotrzeć do odbiorcy w innej kolejności niŜ zostały wysłane. UDP ma
zastosowanie w aplikacjach pracujących w trybie polecenie odpowiedź i w takich, w których
kaŜde polecenie lub odpowiedź mogą zostać przesłane jako pojedynczy datagram. Protokół
UDP świetnie nadaje się do dystrybucji rozgłoszeniowej danych, bowiem do 1000 stacji nie
musi nawiązywać 1000 połączeń, kończyć ich itd. Co powodowało by większe narzuty czasu
jeŜeli wykorzystany byłby protokół TCP.

Nagłówek protokołu UDP:

+--------+--------+--------+--------+
|  Port źródłowy  |   Port docelowy |
+--------+--------+--------+--------+
|     Długość     |  Suma kontrolna |
+--------+--------+--------+--------+
|                Dane               |
+--------+--------+--------+--------+

Nagłówek ma stałą długość 8 oktetów. Port źródłowy to pole 16 bitowe i nie musi być
wypełnione. Zasadniczo moŜna przyjąć następujące znaczenie tego pola:
+ jest tam przechowywany port procesu wysyłającego
+ na ten numer portu powinna zostać wysłana odpowiedź ( o ile inne dane nie wskazują
innego portu )

Trzeba zauwaŜyć, Ŝe wartość 0 tego pola sygnalizuje, Ŝe port nie został podany. Proces
pracujący na stacji docelowej na porcie docelowym otrzyma przesyłane w pakiecie dane.
JeŜeli do niewykorzystywanego portu zostanie wysłany datagram, wygenerowany zostanie
komunikat ICMP nieosiągalności portu, a sam datagram zostanie odrzucony.

Pole długości zawiera liczbę oktetów datagramu UOP (razem oktety nagłówka i danych).
NajniŜszą wartością tego pola moŜe być 8. Oznacza to, iŜ nie ma pola danych. Tworzony jest
takŜe pseudonagłówek dołączony do obliczenia sumy kontrolnej.

0      7 8     15 16    23 24    31
+--------+--------+--------+--------+
|          adres źródłowy           |
+--------+--------+--------+--------+
|          adres docelowy           |
+--------+--------+--------+--------+
|  zero  |protokół| długosć nag. UDP|
+--------+--------+--------+--------+

Uwzględnianie tych dodatkowych danych z pseudonagłowka pozwala na wykrycie
datagramów dostarczonych do niewłaściwych stacji. Pseudonagłówek ma stałą długość 12
oktetów.
Mimo iŜ TCP i UDP wykorzystują adresowanie i powiązanie z procesami aplikacyjnymi za
pomocą portów to jednak przestrzeń adresowa portów UDP jest niezaleŜna od przestrzeni
adresów portów TCP.

Część praktyczna

•

Badanie komputera :

a)  z sieci akademickiej

C:\Documents and Settings\Administrator>ping localhost

Badanie 112_ala [127.0.0.1] z uŜyciem 32 bajtów danych:

Odpowiedź z 127.0.0.1: bajtów=32 czas<1 ms TTL=64
Odpowiedź z 127.0.0.1: bajtów=32 czas<1 ms TTL=64
Odpowiedź z 127.0.0.1: bajtów=32 czas<1 ms TTL=64
Odpowiedź z 127.0.0.1: bajtów=32 czas<1 ms TTL=64

Statystyka badania ping dla 127.0.0.1:
    Pakiety: Wysłane = 4, Odebrane = 4, Utracone = 0 (0% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
    Minimum = 0 ms, Maksimum = 0 ms, Czas średni = 0 ms

C:\Documents and Settings\Administrator>tracert localhost

Trasa śledzenia do 112_ala [127.0.0.1]
przewyŜsza maksymalną liczbę przeskoków 30

  1    <1 ms    <1 ms    <1 ms  localhost [127.0.0.1]

Ś

ledzenie zakończone.

C:\Documents and Settings\Administrator>pathping localhost

ledzenie trasy do 112_ala [127.0.0.1]

z maksymalną liczbą 30 przeskoków:
  0  localhost [127.0.0.1]
  1  localhost [127.0.0.1]

Wyliczanie statystyk dla 25 sekund...
            Źródło   Ten węzeł/Łącze
Przeskok  RTT    Zgubione/wysłane = Pct  Zgubione/wysłane = adres Pct
  0                                           localhost [127.0.0.1]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  localhost [127.0.0.1]

Ś

ledzenie zakończone.

b)  z sieci SZSK poza laboratorium

C:\Documents and Settings\Administrator>ping zsks.zsk.p.lodz.pl

Badanie zsks.zsk.p.lodz.pl [212.51.220.11] z uŜyciem 32 bajtów danych:

Odpowiedź z 212.51.220.11: bajtów=32 czas=2ms TTL=61
Odpowiedź z 212.51.220.11: bajtów=32 czas=1ms TTL=61
Odpowiedź z 212.51.220.11: bajtów=32 czas=1ms TTL=61
Odpowiedź z 212.51.220.11: bajtów=32 czas=1ms TTL=61

Statystyka badania ping dla 212.51.220.11:
    Pakiety: Wysłane = 4, Odebrane = 4, Utracone = 0 (0% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
    Minimum = 1 ms, Maksimum = 2 ms, Czas średni = 1 ms

C:\Documents and Settings\Administrator>tracert zsks.zsk.p.lodz.pl

Trasa śledzenia do zsks.zsk.p.lodz.pl [212.51.220.11]
przewyŜsza maksymalną liczbę przeskoków 30

  1    <1 ms    <1 ms    <1 ms  10.4.11.1
  2     1 ms     1 ms    <1 ms  pc-212-51-207-205.p.lodz.pl [212.51.207.205]
  3    <1 ms    <1 ms    <1 ms  ck-6500.p.lodz.pl [212.51.207.26]
  4     2 ms     2 ms     1 ms  zsks.zsk.p.lodz.pl [212.51.220.11]

Ś

ledzenie zakończone.

C:\Documents and Settings\Administrator>pathping zsks.zsk.p.lodz.pl

Ś

ledzenie trasy do zsks.zsk.p.lodz.pl [212.51.220.11]

z maksymalną liczbą 30 przeskoków:
0 112_ala.czworka.lan [10.4.1.112]
1 10.4.11.1

  2  pc-212-51-207-205.p.lodz.pl [212.51.207.205]
  3  ck-6500.p.lodz.pl [212.51.207.26]
  4  zsks.zsk.p.lodz.pl [212.51.220.11]

Wyliczanie statystyk dla 100 sekund...
            Źródło   Ten węzeł/Łącze
Przeskok  RTT    Zgubione/wysłane = Pct  Zgubione/wysłane = adres Pct
  0                                           112_ala.czworka.lan [10.4.1.112]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  10.4.11.1
                                0/ 100 =  0%   |
  2    0ms     0/ 100 =  0%     0/ 100 =  0%  pc-212-51-207-205.p.lodz.pl [212.5
1.207.205]
                                0/ 100 =  0%   |
  3    0ms     0/ 100 =  0%     0/ 100 =  0%  ck-6500.p.lodz.pl [212.51.207.26]

                                0/ 100 =  0%   |
  4    1ms     0/ 100 =  0%     0/ 100 =  0%  zsks.zsk.p.lodz.pl [212.51.220.11]

ledzenie zakończone.

Dane zarządcy:

person:          Pawel Szychowski
address:         Technical University of Lodz, Computer Centre
address:         ul. Wolczanska 175
address:         PL 90-924 Lodz, POLAND
phone:           +48 42 6312835
fax-no:          +48 42 6312839
e-mail:          domain@p.lodz.pl
e-mail:          psz@p.lodz.pl
nic-hdl:         PS2749-RIPE
source:          RIPE # Filtered

c)  w dowolnym miejscu w Polsce

C:\Documents and Settings\Administrator>ping onet.pl

Badanie onet.pl [213.180.138.148] z uŜyciem 32 bajtów danych:

Odpowiedź z 213.180.138.148: bajtów=32 czas=8ms TTL=53
Odpowiedź z 213.180.138.148: bajtów=32 czas=8ms TTL=53
Odpowiedź z 213.180.138.148: bajtów=32 czas=8ms TTL=53
Odpowiedź z 213.180.138.148: bajtów=32 czas=8ms TTL=53

Statystyka badania ping dla 213.180.138.148:
    Pakiety: Wysłane = 4, Odebrane = 4, Utracone = 0 (0% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
    Minimum = 8 ms, Maksimum = 8 ms, Czas średni = 8 ms

C:\Documents and Settings\Administrator>tracert onet.pl

Trasa śledzenia do onet.pl [213.180.138.148]
przewyŜsza maksymalną liczbę przeskoków 30

  1    <1 ms    <1 ms    <1 ms  10.4.11.1
  2    <1 ms    <1 ms     1 ms  pc-212-51-207-205.p.lodz.pl [212.51.207.205]
  3     1 ms    <1 ms    <1 ms  ck-6500.p.lodz.pl [212.51.207.26]
  4     1 ms     1 ms     1 ms  e-gw.man.lodz.pl [212.191.0.5]
  5     3 ms     3 ms     4 ms  z-lodmana.warszawa-gw.10gb.rtr.pionier.gov.pl
[212.191.226.37]
  6     7 ms     7 ms     7 ms  z-warszawa-gw.krakow.10gb.rtr.pionier.gov.pl
[212.191.226.26]
  7     7 ms     8 ms     7 ms  gvkcyf.cyfro.net [195.150.1.166]
  8     8 ms     7 ms     7 ms  gwk.cyfro.net [195.150.1.238]
  9     8 ms     8 ms     8 ms  195.150.96.10
10     9 ms     8 ms     8 ms  jun4v7.onet.pl [213.180.143.44]
11     9 ms     8 ms     9 ms  sg.m1.onet.pl [213.180.138.148]

Ś

ledzenie zakończone.

C:\Documents and Settings\Administrator>pathping onet.pl

Ś

ledzenie trasy do onet.pl [213.180.138.148]

z maksymalną liczbą 30 przeskoków:
  0  112_ala.czworka.lan [10.4.1.112]
  1  10.4.11.1
  2  pc-212-51-207-205.p.lodz.pl [212.51.207.205]
  3  ck-6500.p.lodz.pl [212.51.207.26]
  4  e-gw.man.lodz.pl [212.191.0.5]
  5  z-lodmana.warszawa-gw.10gb.rtr.pionier.gov.pl [212.191.226.37]
  6  z-warszawa-gw.krakow.10gb.rtr.pionier.gov.pl [212.191.226.26]
  7  gvkcyf.cyfro.net [195.150.1.166]
  8  gwk.cyfro.net [195.150.1.238]
  9  195.150.96.10
10  jun4v7.onet.pl [213.180.143.44]
11  sg.m1.onet.pl [213.180.138.148]

Wyliczanie statystyk dla 275 sekund...
            Źródło   Ten węzeł/Łącze
Przeskok  RTT    Zgubione/wysłane = Pct  Zgubione/wysłane = adres Pct
  0                                           112_ala.czworka.lan [10.4.1.112]
                                8/ 100 =  8%   |
  1    0ms    15/ 100 = 15%     7/ 100 =  7%  10.4.11.1
                                0/ 100 =  0%   |
  2    0ms     9/ 100 =  9%     1/ 100 =  1%  pc-212-51-207-205.p.lodz.pl [212.5
1.207.205]
                                0/ 100 =  0%   |
  3    0ms    10/ 100 = 10%     2/ 100 =  2%  ck-6500.p.lodz.pl [212.51.207.26]

                                0/ 100 =  0%   |
  4    1ms     9/ 100 =  9%     1/ 100 =  1%  e-gw.man.lodz.pl [212.191.0.5]
                                0/ 100 =  0%   |
  5    4ms    14/ 100 = 14%     6/ 100 =  6%  z-lodmana.warszawa-gw.10gb.rtr.pio
nier.gov.pl [212.191.226.37]
                                0/ 100 =  0%   |
  6    8ms    14/ 100 = 14%     6/ 100 =  6%  z-warszawa-gw.krakow.10gb.rtr.pion
ier.gov.pl [212.191.226.26]
                                0/ 100 =  0%   |
  7    7ms    10/ 100 = 10%     2/ 100 =  2%  gvkcyf.cyfro.net [195.150.1.166]
                                0/ 100 =  0%   |
  8   13ms    12/ 100 = 12%     4/ 100 =  4%  gwk.cyfro.net [195.150.1.238]
                                0/ 100 =  0%   |
  9    8ms    17/ 100 = 17%     9/ 100 =  9%  195.150.96.10
                                0/ 100 =  0%   |
10    8ms    10/ 100 = 10%     2/ 100 =  2%  jun4v7.onet.pl [213.180.143.44]
                                0/ 100 =  0%   |
11    8ms     8/ 100 =  8%     0/ 100 =  0%  sg.m1.onet.pl [213.180.138.148]

Ś

ledzenie zakończone.

Dane zarządcy:

role:            ONET-PL NETWORK TEAM
address:         Onet.pl SA
address:         ITOperations
address:         ul. Zapolskiej 44
address:         30-126 Krakow
address:         Poland
phone:           +48 12 2774630

d)  w dowolnym miejscu poza Polską

C:\Documents and Settings\Administrator>ping wikipedia.org

Badanie wikipedia.org [208.80.152.2] z uŜyciem 32 bajtów danych:

Odpowiedź z 208.80.152.2: bajtów=32 czas=152ms TTL=49
Odpowiedź z 208.80.152.2: bajtów=32 czas=154ms TTL=49
Odpowiedź z 208.80.152.2: bajtów=32 czas=151ms TTL=49
Odpowiedź z 208.80.152.2: bajtów=32 czas=150ms TTL=49

Statystyka badania ping dla 208.80.152.2:
    Pakiety: Wysłane = 4, Odebrane = 4, Utracone = 0 (0% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
    Minimum = 150 ms, Maksimum = 154 ms, Czas średni = 151 ms

C:\Documents and Settings\Administrator>tracert wikipedia.org

Trasa śledzenia do wikipedia.org [208.80.152.2]
przewyŜsza maksymalną liczbę przeskoków 30

  1    <1 ms    <1 ms    <1 ms  10.4.11.1
  2    <1 ms    <1 ms    <1 ms  pc-212-51-207-205.p.lodz.pl [212.51.207.205]
  3    <1 ms    <1 ms    <1 ms  ck-6500.p.lodz.pl [212.51.207.26]
  4    <1 ms    <1 ms    <1 ms  e-gw.man.lodz.pl [212.191.0.5]
  5     5 ms     5 ms     6 ms  z-lodmana.poznan-gw1.10gb.rtr.pionier.gov.pl
[212.191.224.5]
  6     6 ms     6 ms     6 ms  pzn-b3-link.telia.net [213.248.83.129]
  7    24 ms    23 ms    23 ms  ffm-bb1-link.telia.net [80.91.254.171]
  8    34 ms    33 ms    33 ms  prs-bb1-link.telia.net [80.91.248.69]
  9   115 ms   115 ms   114 ms  ash-bb1-link.telia.net [80.91.252.36]
10   128 ms   128 ms   129 ms  atl-bb1-link.telia.net [80.91.248.137]
11   144 ms   143 ms   145 ms  mai-bb1-link.telia.net [80.91.251.29]
12   142 ms   144 ms   150 ms  hostway-115911-mai-b1.c.telia.net [213.248.81.10]
13   146 ms   149 ms   147 ms  e1-11.pr0.tpax.hgtn.net [66.113.197.41]
14   153 ms   151 ms   153 ms  ge8-1.csw5-pmtpa.wikimedia.org [66.113.197.94]
15   150 ms   151 ms   151 ms  rr.pmtpa.wikimedia.org [208.80.152.2]

Ś

ledzenie zakończone.

C:\Documents and Settings\Administrator>pathping wikipedia.org

Ś

ledzenie trasy do wikipedia.org [208.80.152.2]

z maksymalną liczbą 30 przeskoków:
  0  112_ala.czworka.lan [10.4.1.112]
  1  10.4.11.1
  2  pc-212-51-207-205.p.lodz.pl [212.51.207.205]
  3  ck-6500.p.lodz.pl [212.51.207.26]
  4  e-gw.man.lodz.pl [212.191.0.5]
  5  z-lodmana.poznan-gw1.10gb.rtr.pionier.gov.pl [212.191.224.5]
  6  pzn-b3-link.telia.net [213.248.83.129]
  7  ffm-bb1-link.telia.net [80.91.254.171]
  8  prs-bb1-pos7-0-0.telia.net [213.248.64.110]
  9  ash-bb1-link.telia.net [80.91.251.98]
10  atl-bb1-link.telia.net [213.248.80.142]
11  mai-b1-link.telia.net [80.91.252.58]
12  hostway-115911-mai-b1.c.telia.net [213.248.81.10]
13  e1-11.pr0.tpax.hgtn.net [66.113.197.41]
14  ge8-1.csw5-pmtpa.wikimedia.org [66.113.197.94]
15  rr.pmtpa.wikimedia.org [208.80.152.2]

Wyliczanie statystyk dla 375 sekund...
            Źródło   Ten węzeł/Łącze
Przeskok  RTT    Zgubione/wysłane = Pct  Zgubione/wysłane = adres Pct
  0                                           112_ala.czworka.lan [10.4.1.112]
                                0/ 100 =  0%   |

  1    0ms     0/ 100 =  0%     0/ 100 =  0%  10.4.11.1
                                0/ 100 =  0%   |
  2    1ms     0/ 100 =  0%     0/ 100 =  0%  pc-212-51-207-205.p.lodz.pl [212.51.207.205]
                                0/ 100 =  0%   |
  3    0ms     0/ 100 =  0%     0/ 100 =  0%  ck-6500.p.lodz.pl [212.51.207.26]
                                0/ 100 =  0%   |
  4    1ms     0/ 100 =  0%     0/ 100 =  0%  e-gw.man.lodz.pl [212.191.0.5]
                                0/ 100 =  0%   |
  5    6ms     0/ 100 =  0%     0/ 100 =  0%  z-lodmana.poznan-gw1.10gb.rtr.pionier.gov.pl
[212.191.224.5]
                                0/ 100 =  0%   |
  6    6ms     0/ 100 =  0%     0/ 100 =  0%  pzn-b3-link.telia.net [213.248.83.129]
                                0/ 100 =  0%   |
  7   24ms     0/ 100 =  0%     0/ 100 =  0%  ffm-bb1-link.telia.net [80.91.254.171]
                                0/ 100 =  0%   |
  8   33ms     0/ 100 =  0%     0/ 100 =  0%  prs-bb1-pos7-0-0.telia.net [213.248.64.110]
                                0/ 100 =  0%   |
  9  115ms     1/ 100 =  1%     1/ 100 =  1%  ash-bb1-link.telia.net [80.91.251.98]
                                0/ 100 =  0%   |
10  130ms     0/ 100 =  0%     0/ 100 =  0%  atl-bb1-link.telia.net [213.248.80.142]
                                0/ 100 =  0%   |
11  145ms     0/ 100 =  0%     0/ 100 =  0%  mai-b1-link.telia.net [80.91.252.58]
                                0/ 100 =  0%   |
12  145ms     0/ 100 =  0%     0/ 100 =  0%  hostway-115911-mai-
b1.c.telia.net[213.248.81.10]
                                0/ 100 =  0%   |
13  142ms     1/ 100 =  1%     1/ 100 =  1%  e1-11.pr0.tpax.hgtn.net [66.113.197.41]
                                0/ 100 =  0%   |
14  147ms     0/ 100 =  0%     0/ 100 =  0%  ge8-1.csw5-pmtpa.wikimedia.org
[66.113.197.94]
                                0/ 100 =  0%   |
15  151ms     0/ 100 =  0%     0/ 100 =  0%  rr.pmtpa.wikimedia.org [208.80.152.2]

Ś

ledzenie zakończone.

Dane zarządcy:

organisation:    ORG-WFI1-RIPE
org-name:        Wikimedia Foundation Inc.
org-type:        OTHER
address:         P.O. Box 78350
address:         San Francisco
address:         CA 94107-8350
address:         USA
abuse-mailbox:

abuse@wikimedia.org

•

Badanie ustawień protokołu IP z narzędzi Panelu Sterowania Windows, jak i
polecenia ipconfig.

C:\Documents and Settings\Administrator>ipconfig

Konfiguracja IP systemu Windows

Karta Ethernet Połączenie lokalne:

        Sufiks DNS konkretnego połączenia : czworka.lan
        Adres IP. . . . . . . . . . . . . : 10.4.1.112
        Maska podsieci. . . . . . . . . . : 255.255.0.0
        Brama domyślna. . . . . . . . . . : 10.4.11.1

Karta Ethernet Połączenie sieci bezprzewodowej:

        Stan nośnika . . . .  . . . . . . : Nośnik odłączony

C:\Documents and Settings\Administrator>ipconfig/all

Konfiguracja IP systemu Windows

        Nazwa hosta . . . . . . . . . . . : 112_ala
        Sufiks podstawowej domeny DNS . . . . . . :
        Typ węzła . . . . . . . . . . . . : Hybrydowy
        Routing IP włączony . . . . . . . : Nie
        Serwer WINS Proxy włączony. . . . : Nie
        Lista przeszukiwania sufiksów DNS : czworka.lan

Karta Ethernet Połączenie lokalne:

        Sufiks DNS konkretnego połączenia : czworka.lan
        Opis . . . . . . . . . . . . . . :  VIA Rhine II Fast Ethernet Adapter
        Adres fizyczny. . . . . . . . . . : 00-14-0B-0E-3B-70
        DHCP włączone . . . . . . . . . . : Tak
        Autokonfiguracja włączona . . . . : Tak
        Adres IP. . . . . . . . . . . . . : 10.4.1.112
        Maska podsieci. . . . . . . . . . : 255.255.0.0
        Brama domyślna. . . . . . . . . . : 10.4.11.1
        Serwer DHCP . . . . . . . . . . . : 10.4.11.1
        Serwery DNS . . . . . . . . . . . : 10.4.11.2
                                            10.4.13.2
                                            10.4.11.1
        Podstawowy serwer WINS. . . . . . : 10.4.11.2
        DzierŜawa uzyskana. . . . . . . . : 5 marca 2009 11:11:43
        DzierŜawa wygasa. . . . . . . . . : 5 marca 2009 17:11:43

Karta Ethernet Połączenie sieci bezprzewodowej:

        Stan nośnika . . . .  . . . . . . : Nośnik odłączony

        Opis . . . . . . . . . . . . . . :  Atheros AR5005G Wireless Network Ada
pter
        Adres fizyczny. . . . . . . . . . : 00-C0-A8-DA-DC-0B

C:\Documents and Settings\Administrator>ipconfig/all

Konfiguracja IP systemu Windows

        Nazwa hosta . . . . . . . . . . . : 112_ala
        Sufiks podstawowej domeny DNS . . . . . . :
        Typ węzła . . . . . . . . . . . . : Hybrydowy
        Routing IP włączony . . . . . . . : Nie
        Serwer WINS Proxy włączony. . . . : Nie

Karta Ethernet Połączenie lokalne:

        Sufiks DNS konkretnego połączenia :
        Opis . . . . . . . . . . . . . . :  VIA Rhine II Fast Ethernet Adapter
        Adres fizyczny. . . . . . . . . . : 00-14-0B-0E-3B-70
        DHCP włączone . . . . . . . . . . : Nie
        Adres IP. . . . . . . . . . . . . : 10.4.1.111
        Maska podsieci. . . . . . . . . . : 255.255.0.0
        Brama domyślna. . . . . . . . . . : 10.4.11.1

Karta Ethernet Połączenie sieci bezprzewodowej:

        Stan nośnika . . . .  . . . . . . : Nośnik odłączony
        Opis . . . . . . . . . . . . . . :  Atheros AR5005G Wireless Network Ada
pter
        Adres fizyczny. . . . . . . . . . : 00-C0-A8-DA-DC-0B

•

Badanie tablicy rutingu korzystając z polecenia route.

C:\Documents and Settings\Administrator>route print
===================================================================
========
Lista interfejsów
0x1 ........................... MS TCP Loopback interface
0x2 ...00 14 0b 0e 3b 70 ...... VIA Rhine II Fast Ethernet Adapter - Sunbelt Sof
tware Firewall NDIS IM Filter Miniport
0x3 ...00 c0 a8 da dc 0b ...... Atheros AR5005G Wireless Network Adapter - Sunbe
lt Software Firewall NDIS IM Filter Miniport
===================================================================
========
===================================================================
========
Aktywne trasy:
Miejsce docelowe w sieci Maska sieci Brama Interfejs Metryka

          0.0.0.0          0.0.0.0        10.4.11.1      10.4.1.112       20
         10.4.0.0      255.255.0.0       10.4.1.112      10.4.1.112       20
       10.4.1.112  255.255.255.255        127.0.0.1       127.0.0.1       20
   10.255.255.255  255.255.255.255       10.4.1.112      10.4.1.112       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
        224.0.0.0        240.0.0.0       10.4.1.112      10.4.1.112       20
  255.255.255.255  255.255.255.255       10.4.1.112               3       1
  255.255.255.255  255.255.255.255       10.4.1.112      10.4.1.112       1
Domyślna brama:        10.4.11.1.
===================================================================
========
Trasy trwałe:
  Brak

•

Badanie portów TCP i UDP oraz nawiązane połączenia TCP wykorzystując polecenie
netstat.

C:\Documents and Settings\Administrator>netstat

Aktywne połączenia

  Protokół  Adres lokalny          Obcy adres        Stan
  TCP    112_ala:1025           localhost:50300        USTANOWIONO
  TCP    112_ala:1032           localhost:44334        USTANOWIONO
  TCP    112_ala:1035           localhost:1037         USTANOWIONO
  TCP    112_ala:1037           localhost:1035         USTANOWIONO
  TCP    112_ala:1081           localhost:1082         USTANOWIONO
  TCP    112_ala:1082           localhost:1081         USTANOWIONO
  TCP    112_ala:1083           localhost:1084         USTANOWIONO
  TCP    112_ala:1084           localhost:1083         USTANOWIONO
  TCP    112_ala:44334          localhost:1032         USTANOWIONO
  TCP    112_ala:50300          localhost:1025         USTANOWIONO

C:\Documents and Settings\Administrator>netstat

Aktywne połączenia

  Protokół  Adres lokalny          Obcy adres        Stan
  TCP    112_ala:1149           ip-91-197-13-44.gadu-gadu.pl:8074  USTANOWIONO
  TCP    112_ala:1025           localhost:50300        USTANOWIONO
  TCP    112_ala:1032           localhost:44334        USTANOWIONO
  TCP    112_ala:1035           localhost:1037         USTANOWIONO
  TCP    112_ala:1037           localhost:1035         USTANOWIONO
  TCP    112_ala:1081           localhost:1082         USTANOWIONO
  TCP    112_ala:1082           localhost:1081         USTANOWIONO
  TCP    112_ala:1083           localhost:1084         USTANOWIONO
  TCP    112_ala:1084           localhost:1083         USTANOWIONO